Copyright © https://mongoose-os.com

Mongoose OS Forum

frame
ATTENTION! This forum has moved to:

https://community.mongoose-os.com

Do not post any new messages.

ROM switching

I have some questions regarding the ROM switching mechanism of the bootloader on a ESP8266.

Example:
- After production I'm using ROM0, ROM1 is empty (due to the fact that I do a full erase before flashing ROM0).
- After an OTA update both of my ROMs contain valid data. The bootloader starts on ROM1 and stays on ROM1 as the function user_init calls mgos_upd_committ.
- So far I could verify all the steps above using the logs.

Now I noticed that when I apply the RESET in the right manner several times in a row that the bootloader decides to switch back from ROM1 to ROM0. As this may be fatal in the field I'm curious about what are the criterias for such a switch? Can I configure the bootloader to not switch back ROMS? Is the bootloader going to switch back from ROM0 to ROM1 at the next restart or is ROM1 marked as bad forever?

Best regards,
Michael

Comments

  • rojerrojer Dublin, Ireland
    edited August 2017

    this is not supposed to happen if ROM1 is committed. can you give details of "the right manner" of applying reset that triggers it?
    also boot loader usually logs activity that leads to rom switches, like deciding to roll back an update. so if you have a console logger attached while you apply resets, this should tell us what happens.

  • mglettigmglettig Switzerland

    Hi Rojer

    Please find the logs attached. On line 140 the bootloader starts to boot from ROM 0 instead ROM 1 after I executed a lot of resets using a reset button. The resets where triggered shortly after each other (stress test).

    When I do another Reset the bootloader stays on ROM 0 now.

    Regards,
    Michael

  • rojerrojer Dublin, Ireland

    Writing default boot config. - so existing boot config could not be read or was read with an error. it happens here and is only intended to be executed on first boot.
    i see that you are using a bit old version of the code. can you update first and see if this still happens?

  • mglettigmglettig Switzerland

    Hi Rojer

    Due to the breaking commit (6879d6b582e9b9f4dd1989b5aeac222162d3272b) I am not able to update the code. Can you outline the relevant change that should avoid the unintended ROM switching?

    Best regards,
    Michael

  • rojerrojer Dublin, Ireland

    i cannot, i still have no idea why it happens.

  • mglettigmglettig Switzerland

    Please have a look here: https://github.com/cesanta/mongoose-os/blob/da1f202a2643cc03112cbfb6df66a6acafb805b6/common/platforms/esp8266/rboot/rboot/rboot.c#L175

    I think the boot configuration is rewritten after every reset of the firmware because updateConfig is initialized with true instead of false! Now if a reset occurs while the boot sector is written it would result with a invalid boot coniguration (at address 0x1000) which would result in "BAD ROM" logs. Do you agree?

    Regards

  • rojerrojer Dublin, Ireland

    yes indeed, you are right! and there was a fix upstream, even.

  • rojerrojer Dublin, Ireland

    @mglettig thanks so much for tracking this down. the fix has been published. i imagine you're interested in rolling this out via OTA?

  • mglettigmglettig Switzerland

    Hi @rojer
    Thank you for immediately publishing the fix. I guess I can't roll out the fix via OTA as it affects the bootloader which can't be updated via OTA... Or is it possible to update the bootloader as well?

    Regards

  • rojerrojer Dublin, Ireland

    @mglettig not at the moment, but i am preparing a change that will make it possible. you will need to update to that version first, and then perform another OTA with a special flag. i'll post the details once the change is submitted.

  • rojerrojer Dublin, Ireland
    edited November 2017

    @mglettig, the change is in. you need to push fw with this change first, and after that, you can build a followup with --build-var MGOS_UPDATE_BOOT_LOADER=true (verify that boot.update is true in build/objs/fw_temp/manifest.json) and do another push.
    of course updating boot loader is inherently risky - there's a short period of time while it is being updated where device can be rendered unbootable, but of course with this bug this happens every single boot, so...

    Thanked by 1mglettig
  • malumalu Zürich

    Hi @rojer
    This feature is very usefull and is indeed used to update alot of devices in the field. thanks for that. One question, just to be sure: The bootloader is only written once after an OTA update? And then not anymore? or how does the update mechanism of BL work?

  • rojerrojer Dublin, Ireland

    @malu boot loader is updated when updating to firmware that was built with MGOS_UPDATE_BOOT_LOADER=true. if your subsequent update is built without this flag, boot loader will not be updated.

  • malumalu Zürich

    @rojer Yes that is understood. I just wanted to make sure that bootloader is only written to flash one time in the subsequent update. And not again after every reset of the device. But why would you ever do something silly like that? ;)

  • rojerrojer Dublin, Ireland

    right. no, we don't do anything like that :)

    Thanked by 1malu
  • malumalu Zürich
    edited October 2018

    @rojer Is there a possibility to read out the current bootloader version from the app (after mgos_app_init)?

  • rojerrojer Dublin, Ireland

    no, currently there isn't an API to retrieve boot loader version.

  • malumalu Zürich

    @rojer Thanks for the confirmation.
    What do you think about the solution to use spi_flash_read from the ESP SDK to read out flash content of where the bootloader is stored and then hash it to identify which version is on the device?
    Or is something like this in the pipeline in further mg versions?

  • rojerrojer Dublin, Ireland

    the medium to long-term solution is to move to unified bootloader on all platforms and introduce proper API to obtain the version.

    Thanked by 1malu
Sign In or Register to comment.