Robust Ethernet bootloader

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Robust Ethernet bootloader

Gregor Mackenzie
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 , <[hidden email]> wrote:

> Send En-Nut-Discussion mailing list submissions to
>         [hidden email]
>
> 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
>         [hidden email]
>
> You can reach the person managing the list at
>         [hidden email]
>
> 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 <[hidden email]>
> To: "Ethernut User Chat (English)" <[hidden email]>
> Subject: [En-Nut-Discussion] Robust Ethernet bootloader
> Message-ID: <[hidden email]>
> 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
Reply | Threaded
Open this post in threaded view
|

Re: Robust Ethernet bootloader

Philipp Burch-2
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 , <[hidden email]> wrote:
>
>> Send En-Nut-Discussion mailing list submissions to
>>         [hidden email]
>>
>> 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
>>         [hidden email]
>>
>> You can reach the person managing the list at
>>         [hidden email]
>>
>> 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 <[hidden email]>
>> To: "Ethernut User Chat (English)" <[hidden email]>
>> Subject: [En-Nut-Discussion] Robust Ethernet bootloader
>> Message-ID: <[hidden email]>
>> 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
Reply | Threaded
Open this post in threaded view
|

Re: Robust Ethernet bootloader

Philipp Burch-2
Hi everyone,

I've now implemented a bootloader for the TIVA microcontroller. It's an
implementation from scratch, this seemed to be less work than trying to
adapt some existing solution... The bootloader exposes a simple
UDP-based interface to control it. It grew a bit larger than I initially
expected, the binary amounts to approx. 27kB now, so that the
application image can start at an offset of 0x8000 (32768 bytes).
When the MCU starts, the bootloader first configures the Ethernet
interface and then broadcasts an advertisement packet. It then waits for
a short time for a response and if nothing follows, it tries to boot the
application. In case this fails, the MCU resets and the bootloader
starts over. The application image is checked for sanity by examining
the first two words (the initial SP must point to RAM and the initial PC
to flash) and a CRC over the full image to check if it is valid.

A Python script is used to listen for the advertising packet and then
download and boot the new image.

You can find all the code in

https://hb9etc.ch/hg/tiva_ethloader/

mcu/ contains the bootloader code itself that should go to the MCU.
pc/ contains the Python frontend.
sample_app/ contains a simple application that can be flashed using the
bootloader to test it.

When compiling the application, it is required to tell the linker to
place all code after the bootloader. This can be done by slightly
modifying the linker file:

MEMORY
{
    FLASH0 (rx) : ORIGIN = DEFINED(bootloader_offset) ?
bootloader_offset : 0, LENGTH = 1024K - (DEFINED(bootloader_offset) ?
bootloader_offset : 0)
    SRAM0 (rwx) : ORIGIN = 0x20000000, LENGTH = 256K
}

The application Makefile should then appropriately define the
bootloader_offset symbol for compiler and linker:

# Add the bootloader information to move the application image further back.
ifdef USE_BOOTLOADER
        CFLAGS += -DBOOTLOADER_OFFSET=0x8000
        LDFLAGS += -Wl,--defsym=bootloader_offset=0x8000
endif


Possible future improvements:

- Update interface_init() to wait for a link to be established (with a
timeout) instead of waiting for a fixed delay. See my other thread
concerning the detection of link establishment.

- Add the required code to Ethernut, so that the bootloader does not
need to use MCU-specific stuff but can be converted to a pure Ethernut
application. It currently uses the following unabstracted MCU features:
Flash writing (FLASH peripheral), internal EEPROM to store the
application image size and CRC (EEPROM peripheral), hardware CRC
calculator (CCM0 peripheral, could easily be replaced by a
zlib-compatible software implementation in pure C) and the watchdog
(WATCHDOG1 peripheral). Additionally, there is a short block of inline
assembler to actually boot the application image in
mcu_boot_application() that is specific to ARM Cortex-M cores.

- Add security features like encryption, authentication and signed
images; required if such a device is connected to an untrusted network.


Feel free to use the bootloader for your own projects. In case anyone
feels like improving it, just let me know :)

Many thanks especially to Uwe for his support!

Best regards,
Philipp
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Robust Ethernet bootloader

Dušan-2
In reply to this post by Philipp Burch-2
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 ,<[hidden email]>  wrote:
>>
>>> Send En-Nut-Discussion mailing list submissions to
>>>          [hidden email]
>>>
>>> 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
>>>          [hidden email]
>>>
>>> You can reach the person managing the list at
>>>          [hidden email]
>>>
>>> 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<[hidden email]>
>>> To: "Ethernut User Chat (English)"<[hidden email]>
>>> Subject: [En-Nut-Discussion] Robust Ethernet bootloader
>>> Message-ID:<[hidden email]>
>>> 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
Reply | Threaded
Open this post in threaded view
|

Re: Robust Ethernet bootloader

Philipp Burch-2
In reply to this post by Philipp Burch-2
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 , <[hidden email]> wrote:
>>>
>>>> Send En-Nut-Discussion mailing list submissions to
>>>>         [hidden email]
>>>>
>>>> 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
>>>>         [hidden email]
>>>>
>>>> You can reach the person managing the list at
>>>>         [hidden email]
>>>>
>>>> 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 <[hidden email]>
>>>> To: "Ethernut User Chat (English)" <[hidden email]>
>>>> Subject: [En-Nut-Discussion] Robust Ethernet bootloader
>>>> Message-ID: <[hidden email]>
>>>> 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
Reply | Threaded
Open this post in threaded view
|

Re: Robust Ethernet bootloader

Dušan-2
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 , <[hidden email]> wrote:
>>>>
>>>>> Send En-Nut-Discussion mailing list submissions to
>>>>>          [hidden email]
>>>>>
>>>>> 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
>>>>>          [hidden email]
>>>>>
>>>>> You can reach the person managing the list at
>>>>>          [hidden email]
>>>>>
>>>>> 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 <[hidden email]>
>>>>> To: "Ethernut User Chat (English)" <[hidden email]>
>>>>> Subject: [En-Nut-Discussion] Robust Ethernet bootloader
>>>>> Message-ID: <[hidden email]>
>>>>> 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

_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion