[En-Nut-Discussion] Robust Ethernet bootloader

Dušan dferbas at solarmonitor.cz
Wed Sep 12 12:35:27 CEST 2018 

Hi Philipp,

I agree with you that this is no 100% save, but it was 2009 and 128kB 
flash on ATmega128.
In case of an application malfunction, you still have the serial xmodem 
possibility, but you must be at the site.
There are thousands of units deployed, e.g. Poseidon I and Damocles I 
have this bootloader.

These days we use 16 kB bootloader partition with reading files from SD 
card,
still using the application for firmware upgrade.

With Linux, we also use application to upload firmware,
because it allows us to show to user if a firmware is compatible with 
hardware and previous firmware version,
we can show on web, if u/boot will be upgraded etc.
Just FYI.

*Dusan*

On 12.9.2018 11:51, Philipp Burch wrote:
> Hi Dusan,
>
> thanks for the response. Using parts of the application for the TCP/IP
> stuff is definitely a space-saving approach, but something I wanted to
> avoid. The first reason is that the bootloader should not need to know
> what exactly is in the application and it should also be able to work in
> case the application image is completely screwed up (or just not
> present). Since I use it only on ARMs with hundreds of kilobytes flash
> space, 16kiB for the bootloader are also not that critical. At least it
> already proved quite well, so at least for the moment, I will keep it in
> the current fashion.
>
> In case you are interested: https://hb9etc.ch/hg/tiva_ethloader/
>
> Best regards,
> Philipp
>
> On 11.09.2018 10:17, Dušan wrote:
>> Hi Philipp,
>>
>> now, we are downloading new firmware onto SD card and then bootloader
>> processes it from SD card during power up.
>>
>> In the past, when we have no SD card, we used a TCP stack of the
>> application and from http server, we were calling the bootloader to
>> parse and flash firmware records.
>> The bootloader fits into 2kB and you can upgrade firmware through web.
>> Initially, there was a serial xmodem protocol on uart and
>> once an application was in board, it was accepting a byte stream with
>> API calls from main application.
>> I.e. it was implemented in a following way (assembler is for
>> ATmega128/1281, for 2561 it was done similarly, if you are interested, I
>> can send you some files):
>>
>> This was written in 2009, now we will write it more clearly with some LD
>> script stuff to place code on expected addresses.
>>
>> bootloader:
>> ---------------
>> static void InituP(void) __attribute__ ((naked, section(".init1"), used));
>>
>> void InituP(void)
>> {
>>      asm volatile ("clr    __zero_reg__");
>>      cli();
>>      asm volatile ("rjmp next");
>>      asm volatile ("jmp boot_loader_data_init");
>>      //we assume this will be always at @ 0x1F806
>>      asm volatile ("jmp boot_loader_data_send");
>>      asm volatile ("next:");
>>
>> application:
>> ----------------
>> typedef void Tboot_loader_data_init(unsigned char *);
>> #define boot_loader_data_init ((Tboot_loader_data_init *)0x1F806)
>>
>> typedef int Tboot_loader_data_send(unsigned char *, unsigned char *,
>> unsigned short);
>> #define boot_loader_data_send ((Tboot_loader_data_send *)0x1F80A)
>>
>> *Dusan Ferbas
>> *
>>
>> On 5.6.2018 14:10, Philipp Burch wrote:
>>> Hi Gregor,
>>>
>>> thanks for the update. I've used U-Boot only with Linux kernels so far,
>>> good to know that it also supports bare-metal applications. I'll have a
>>> look at it.
>>>
>>> Regards,
>>> Philipp
>>>
>>> On 05.06.2018 12:59, Gregor Mackenzie wrote:
>>>> It's possible to configure u-boot to automatically execute Nut O/S programs
>>>> on power up. It can also handle tftp and other tcp/ip based transfers.
>>>> U-boot will also allow boot over tftp, so you could make your boards load
>>>> the application from your central server each time they start if you wish
>>>> too.
>>>>
>>>> I did a little experimentation with an Ethernut 5 board to this end a while
>>>> ago using the stock Ethernut 5 u-boot image and replacing the Linux image
>>>> with a Nut O/S executable.
>>>>
>>>> There are various tftp servers around. I think Harald's preferred one at
>>>> the time was tftp32.
>>>>
>>>> On Tue, 5 Jun 2018, 12:00 , <en-nut-discussion-request at egnite.de> wrote:
>>>>
>>>>> Send En-Nut-Discussion mailing list submissions to
>>>>>          en-nut-discussion at egnite.de
>>>>>
>>>>> To subscribe or unsubscribe via the World Wide Web, visit
>>>>>          http://lists.egnite.de/mailman/listinfo/en-nut-discussion
>>>>> or, via email, send a message with subject or body 'help' to
>>>>>          en-nut-discussion-request at egnite.de
>>>>>
>>>>> You can reach the person managing the list at
>>>>>          en-nut-discussion-owner at egnite.de
>>>>>
>>>>> When replying, please edit your Subject line so it is more specific
>>>>> than "Re: Contents of En-Nut-Discussion digest..."
>>>>>
>>>>>
>>>>> Today's Topics:
>>>>>
>>>>>     1. Robust Ethernet bootloader (Philipp Burch)
>>>>>
>>>>>
>>>>> ----------------------------------------------------------------------
>>>>>
>>>>> Message: 1
>>>>> Date: Mon, 4 Jun 2018 15:06:05 +0200
>>>>> From: Philipp Burch <phip at hb9etc.ch>
>>>>> To: "Ethernut User Chat (English)" <en-nut-discussion at egnite.de>
>>>>> Subject: [En-Nut-Discussion] Robust Ethernet bootloader
>>>>> Message-ID: <a0bebd81-2efe-ab8d-802a-b4852fdd49c0 at hb9etc.ch>
>>>>> Content-Type: text/plain; charset=utf-8
>>>>>
>>>>> Hi everyone,
>>>>>
>>>>> I'm in a project where we will soon have to deploy some boards running
>>>>> Nut/OS into "the field". Those boards are all connected to a local
>>>>> computer using Ethernet, but the computer itself is usually only
>>>>> accessible over the net. In the first prototype, we simply put a J-Link
>>>>> into the machine to be able to update the MCU firmware (or even debug
>>>>> it), in case a problem arises, but this definitely is no productive
>>>>> solution. We use Ethernet to have a robust and isolated connection after
>>>>> all, which USB and JTAG is not.
>>>>>
>>>>> Our target platform is a TIVA TM4C1294NCPDT processor, which has an
>>>>> integrated Ethernet MAC and PHY. My primary concern is robustness of the
>>>>> bootloader, it should be rather hard to brick the device. I see that
>>>>> there is some Ethernet-based bootloader functionality in the ROM of this
>>>>> MCU, but as far as I can tell, this must be invoked from the application
>>>>> code. So in case the update fails, there will most likely be no way to
>>>>> re-flash the firmware without local intervention. What I would prefer is
>>>>> a small self-contained bootloader that always runs when the firmware
>>>>> starts (after power-on, watchdog-reset, hard-fault, etc.), validates the
>>>>> firmware image and then starts the application. In case the validation
>>>>> fails, it should sit there and wait for a new image to be downloaded.
>>>>>
>>>>> My questions:
>>>>>
>>>>> - What are your experiences and suggestions for Ethernet bootloaders?
>>>>>
>>>>> - Did I miss anything important?
>>>>>
>>>>> - Does Nut/OS offer some functionality for this?
>>>>>
>>>>> - How do I need to compile the target application, so that it can be
>>>>> started from the bootloader? Especially considering the interrupt vector
>>>>> table and such stuff.
>>>>>
>>>>> Thank you and best regards,
>>>>> Philipp
>>>>>
>>>>>
>>>>> ------------------------------
>>>>>
>>>>> _______________________________________________
>>>>> http://lists.egnite.de/mailman/listinfo/en-nut-discussion
>>>>>
>>>>>
>>>>> End of En-Nut-Discussion Digest, Vol 168, Issue 1
>>>>> *************************************************
>>>>>
>>>> _______________________________________________
>>>> http://lists.egnite.de/mailman/listinfo/en-nut-discussion
>>>>
>>> _______________________________________________
>>> http://lists.egnite.de/mailman/listinfo/en-nut-discussion
>>>
> _______________________________________________
> http://lists.egnite.de/mailman/listinfo/en-nut-discussion

More information about the En-Nut-Discussion mailing list