This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Bootloaders (was Re: Memory Layout)



> > 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."


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]