From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Lewin A.R.W. Edwards" To: ecos-discuss@sourceware.cygnus.com Subject: [ECOS] Bootloaders (was Re: [ECOS] Memory Layout) Date: Thu, 19 Apr 2001 17:53:00 -0000 Message-id: <4.3.2.7.2.20010419204059.00b00f90@mail.larwe.com> References: <000701c0c932$28f70900$c408aa0a@inc.inventec> X-SW-Source: 2001-04/msg00242.html > > with it, why would you _not_ want RedBoot, even in the final product? > Second, it will require extra flash memory to hold it. > Third, I want to replace redboot with my hardware check code in final >product. when power on, it will run code to check hardware, if the hardware >is all OK, then load eCos to RAM from flash memory and run eCos >automatically. it seems RedBoot doesn't support it. Good points. Our application is exactly the same. The flash device we are using has a 16Kword (32Kbyte) bootblock. In this 32K resides my power-on self-test code, manufacturing test code (LCD test patterns, serial/USB test, switch test, storage device test and so on) and also the code that can be used for re-flashing the remainder of the device from serial port or removable media if the power-on checksum test fails. I think this is a very standard and normal way of implementing a field-upgradable embedded system. The constraint of the typical sizes of flash bootblocks (or in evenly-sectored devices, the sector size) is a *very* important consideration, and overall flash budget is a not-too-distant second. RedBoot for EDB7212 is >80K which is way too big for my bootblock, and anyway I want the bootloader in my board to contain a lot of custom functionality (the aforementioned manufacturing support code). In a second case we are working with an absolutely bare-minimum size bootable OTP EPROM that loads the main application from cheap NAND flash or hard disk. Again, size of the bootloader, and custom functionality, is paramount. I haven't had time to study in depth what has changed now that RH has moved towards RedBoot, but I agree with comments Grant Edwards made some months ago on the topic. Essentially the thing we want to do is (once the app is debugged) compile for RAM startup, manually stuff the resultant binary together with the custom bootloader into a flash chip, and have the custom bootloader copy [decompress] from the ROM image into RAM. === Lewin A.R.W. Edwards (Embedded Engineer) Work: http://www.digi-frame.com/ Personal: http://www.zws.com/ and http://www.larwe.com/ "... a man who is endowed with real qualities of leadership will be tempted to refrain from taking part in political life; because [...] the situation does not call for a man who has a capacity for constructive statesmanship but rather for a man who is capable of bargaining for the favour of the majority. Thus the situation will appeal to small minds and will attract them accordingly."