understanding the generation of firmware0.bin and 1.bin

General discussions and questions abound development of code with MicroPython that is not hardware specific.
Target audience: MicroPython Users.
Post Reply
lnsri22
Posts: 67
Joined: Fri Aug 17, 2018 12:16 pm
Location: India

understanding the generation of firmware0.bin and 1.bin

Post by lnsri22 » Fri Feb 15, 2019 7:25 am

Hello Everyone!!


I'm so curious to know what the are source files that (when the contents changed) contributes to modification of firmware0.bin and what those does so to firmware1.bin.

FYI : I have been using STM32 port of micropython.

Thanks in advance!!
lnsri22 :)

Online
User avatar
dhylands
Posts: 3204
Joined: Mon Jan 06, 2014 6:08 pm
Location: Peachland, BC, Canada
Contact:

Re: understanding the generation of firmware0.bin and 1.bin

Post by dhylands » Fri Feb 15, 2019 4:34 pm

firmware0.bin and firmware1.bin is the entire firmware image of MicroPython so almost all of the files contribute in one way or another. To see a complete list of object files that contribute you can example the firmware.map file.

The reason there are 2 bin files is just due to the way flash is laid out and it allows the filesystem to be larger by splitting the firmware into 2 pieces.

If you run make with V=1 it will show all of the commands including the commands that generate the 2 bin files from the firmware.elf file.

lnsri22
Posts: 67
Joined: Fri Aug 17, 2018 12:16 pm
Location: India

Re: understanding the generation of firmware0.bin and 1.bin

Post by lnsri22 » Sat Feb 16, 2019 4:54 am

Dave!!

Thank you for the reply.

I am getting this weird EINVAL22 at times while using SD Card in my custom hw(uses stm32 port).

I have been basically trying to do a FOTA with the GSM module as described below

1. Download firmware0.bin to 0x08020000 and firmware1.bin to 0x08040000 in-house using STM32-STVLINK
2. make some changes in source files, build the firmwares (0.bin and 1.bin as usual)
3. Then I do a ota update for the file firmware1.bin alone. would this be leading to this kind of behaviour?

I may sound in a wrong sense yet I tried the below to identify the scenario when this EINVAL22 occurs

1. Load firmware0.bin and firmware1.bin of the same builds
2. Load firmware0.bin and firmware1.bin of different builds

At times this error vanishes and at times this shows up. Yet the fix being loading the respective firmware0.bin and firmware1.bin.

If in case , I need the firmware to a single binary image, shall I build using "USE_MBOOT=1"? will this work If make appropriate changes ?

Please advise!!
lnsri22 :)

Online
User avatar
dhylands
Posts: 3204
Joined: Mon Jan 06, 2014 6:08 pm
Location: Peachland, BC, Canada
Contact:

Re: understanding the generation of firmware0.bin and 1.bin

Post by dhylands » Sat Feb 16, 2019 5:02 am

You can only use firmware0.bin from the exact same build. Mixing from different builds can cause crashes. I'm pretty sure that when updating flash you can't be also running code from flash, you need to make sure that the code is running from SRAM.

lnsri22
Posts: 67
Joined: Fri Aug 17, 2018 12:16 pm
Location: India

Re: understanding the generation of firmware0.bin and 1.bin

Post by lnsri22 » Sat Feb 16, 2019 5:10 am

Dave, while updating falsh, I'm not running the firmware from it.

I have a separate bootloader to get this done @0x08000000 of (32 K size)

Thanks again for the hint there.

Shall I still use "USE_MBOOT=1" to get a single firmware image and use that to be uploaded ota?

I'm assuming that the space occupied by mboot will be done instead by my bootloader that resides @0x08000000

For this to work, what are the files , that I might need to modify.

Please advise!!
lnsri22 :)

Online
User avatar
dhylands
Posts: 3204
Joined: Mon Jan 06, 2014 6:08 pm
Location: Peachland, BC, Canada
Contact:

Re: understanding the generation of firmware0.bin and 1.bin

Post by dhylands » Sat Feb 16, 2019 6:21 am

I took a look at the datasheet, and the CPU stalls while the flash writes are happening, but otherwise execution continues normally.

The reason to have 2 firmware bin files is because one firmware file is needed at 0x08000000 to have the reset vector, and then the rest of the code lives at 0x08020000 and the filesystem lives between them. With a bootloader that stays in low flash there isn't really any reason to split the firmware.

All of this layout is controlled by the .ld files.

The mpconfigboard.mk file determines which .ld files is used, and also determine whether 1 or 2 firmware bin files are created (If TEXT1_ADDR is defined then a second bin file is created).

You can have your board definition use whichever .ld files make the most sense. USE_MBOOT is used by the PYBV11 mpconfigboard.mk but there's no reason that your mpconfigboard.mk needs to use USE_MBOOT.

lnsri22
Posts: 67
Joined: Fri Aug 17, 2018 12:16 pm
Location: India

Re: understanding the generation of firmware0.bin and 1.bin

Post by lnsri22 » Sat Feb 16, 2019 7:39 am

Dave,

Let me put things in clear manner so that you could really get to know what am I doing actually.

1. I have a custom bootloader written in C that resides @ 0x08000000.
2. I have modified the linker script to consider the flash starting address to be 0x08008000, where I have put up the file system for 96 K (have modified flashbdev.c as you have suggested below)
dhylands wrote:
Thu Jan 31, 2019 4:25 pm
You'll also need to modify flashbdev.c
https://github.com/micropython/micropyt ... lashbdev.c
to tell it the new location of the flash blocks for the filesystem, keeping in mind that you can only include 16K or 64K blocks.
Now on every reset or when power is cycled , the custom bootloader tries to detect and mount the sd card and if it finds a file named "fw.bin" in the sd card, it erases the flash from 0x08020000 to 0x080E0000 (leaving the file system @0x08008000 intact) Then it loads the firmware from sd card starting @ 0x08020000 to 0x080E0000


I'm not actually erasing the flash from within micropython i.e (when micropython is running). It is done by the custom bootloader written in c and it has no relationship with the micropython firmware.

I have modified the mpconfigboard.mk as per micropython/micropython origin so that it assigns TEXT0_ADDR and TEXT1_ADDR based on whether or not USE_MBOOT is specified during make.

It is basically for me, a bit difficult to update both firmware0.bin and firmware1.bin Over The Air and hence I thought I could have a single firmware file (this way I could handle only one upload and relevant failures during download and update).

I thought of using "USE_MBOOT=1" during make , hence it seem to bind both "firmware0.bin" and "firmware1.bin" into a single file named"firmware.bin" (I auume that it actually has both ISR and TEXT as per the mboot documentation given below)

https://github.com/micropython/micropyt ... -on-pybv1x


Also the catch here is that I have been developing my custom hardware based on stm32 port close to pyb class. Hence I believe that using "USE_MBOOT=1" will make sense.


Please advise !!
lnsri22 :)

Post Reply