Hi
I have to admit that the MCF5282 is the next closest to the supported devices due to the fact that it is a real single-chip device (with 64k RAM (+2k Cache) + 512k FLASH).
The Ethernet controller looks compatible, as are probably most peripherals.
This means that it may already run a simple test - like blinking LED, UART or maybe even ping (depending on the PHY used).
The first difference that is however obvious is that it uses a different FLASH technology. Rather than the 2k or 4k (Kirin3) Flash granularity that is known form the other devices, the granularity is 16k (32 x 16k sectors). This possibly means that the programming algorithm is a bit different but it certainly means that the use of the FLASH sometimes requires a different strategy:
1) The
uParameterSystem (usually used to save IP settings and MAC address) may be wasteful of memory (it uses one or 2 sectors - when swap block is active. Possibly small parameter storage may even be better in an external EEPROM (?)
2) The large granularity is not so suitable for the
uFileSystem since a file will occupy multiples of the flash granularity. In this case there is however the LARGE-GRANULARITY mode which is used by the NXP and STR91 project and described here:
http://www.utasker.com/docs/STR91XF/FileSystemSTR91X.PDFKeeping goals specifically fixed on a boot loader, it seems that the best method would be to configure the uTasker project as simple web server with build in default web page which allows firmware upload via HTTP post. This will require 2 x 16k sectors of internal FLASH but leaves the rest free for application code, The application code can be from a completely different project and, if there is large external memory, even ucLinux based, for example.
The boot needs to be able to detect whether there is a valid application loaded. If not (or if a defined port input is in a certain state [forced loading mode]) it can run the uTasker project code so that the application can be installed. If a valid application is detected (exactly how it detects it needs to be defined depending on exact requirements but could be as simple as checking that the code at 0x8000 has a valid SP value and a realistic PC value or even checking a check-sum of its image) it can simply jump to it as the bare-minimum boot loader, or the SREC UART loaders do.
To prepare for a new upload either the input forces the board to start in loader mode or the application can delete itself (or at least make itself invalid so that the boot loader is started - one other method used was also to reserve a magic number at a define location in RAM so that the boot loader recognises that the application is signaling that it should start after a reset).
The biggest jobs that I see are ensuring that the FLASH driver works correctly for the internal FLASH. If the application is large and needs to be also stored in external FLASH a corresponding second driver will need to be added to handle the programming and deletion in that area.
Another important detail with Ethernet based loaders is where the IP and MAC comes from. Often this is managed by the application but the boot loader may need to know where the information is to allow it to use the correct values. When no application and no settings a default set may be used (or DHCP) but usually at least the MAC should be unique...
Looking forward to some feedback from people who have actually used the chip together with the uTasker project ;-)
Regards
Mark
P.S. Although I don't have a board for this device I expect that it would be possible to get a good first show using the uTasker simulator .
P.P.S. Since these devices are only available in MAPBGA there are some restrictions due to patent issues and they don't seem to be available everywhere - I don't know whether EVBs can be obtained by everyone...(?)