[En-Nut-Discussion] Bootloader
Dave
ethernut at wormfood.org
Fri Aug 12 14:34:29 CEST 2005
Hi Thorsten,
> But this is the only way to keep the bootloader alive if there goes
> something wrong during flashing (wrong image or so).
Yep, you're 100% right, but that is how it is currently designed. Also
don't forget, one of the goals of the bootloader is to be small. The
more features you add, the bigger it gets. Currently it just barely fits
in 4K of space.
> I think a simple idea
> could be to extend the current bootloader with a checksum test:
> In the bootimage's first bytes should be a checksum of the flash content.
> Bootloader reads these bytes and compares it with the current flash. If
> there is no difference it does nothing and starts the application. If there
> are differences it just works like before.
While it may sound simple on the surface, it is slightly more
complicated. Here are a few more things to think about.
1. Where is the checksum stored? I'd think eeprom would be the best
place. You could get it from the server every time, but that is a lot
more overhead than what is needed.
2. How do you decide how much of memory to run through the checksum? If
you checksum all the memory, then you have to be sure all of memory is
erased when you reprogram it. If all of memory is checked, your program
wouldn't be able to store anything in flash at runtime, since it would
break the checksum. You would probably want to record the length of what
to check too.
3. Is the additional time required to do this on every boot, needed?
There are at least 2 different ways to do a normal checksum. A fast
checksum needs a lot of space, and a small checksum is slow. And if you
wanted to do something like a md5 hash, then be prepared to spend about
10K in code space, and it is real slow.
> Could you give me a hint how to configure this? Bootloader gets it's image
> file name from DHCP I thing. How can I tell it that it should use another
> machine for tftp? Since this can become a bit offtopic you can contact me
> privately at <removed>.
I should have included this info in my last message. I don't think this
is off topic, since it directly relates to using the current bootloader
with the ethernut. I just inserted the two following lines into the
'subnet' section of my dhcpd.conf file.
filename "flashimage";
next-server 192.168.0.123;
There are several places those 2 lines can go. The best place to put
them is specific to your network. If you make some 'host' sections, then
you could have different ethernut boards using different servers, and/or
flashrom images. If for some reason, you can't get it to work, then
contact me (info on my web page), and I'll give you a hand.
> > memory, and program it into the FlashROM. Since the Nut/OS application
> > would have to help the bootloader by loading the image into external
> But then again you have the problem that the bootloader needs the
> application. If there is something wrong with the application it can come to
> situations where you cannot remote flash your Ethernut anymore.
Yes, that is definately an issue, but it depends on how and where that
image is stored. If the flashrom image was stored in serial flash, for
example, then the bootloader could recover from a bad programming. I've
used the bootloader well over 100 times (probably closer to 200 times)
and have never had it leave me in a bad state. It only takes 5 to 10
seconds for me to program 64k with the current bootloader, with 6 to 7
seconds being average. That isn't much of a window for something bad to
happen (power failure, network outage, etc).
-Dave
More information about the En-Nut-Discussion
mailing list