Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

disco_l475_iot1 default CONFIG_BOOT_MAX_IMG_SECTORS should be 512 not 256 #44777

Closed
vincemulhollon opened this issue Apr 11, 2022 · 7 comments
Closed
Assignees
Labels
bug The issue is a bug, or the PR is fixing a bug platform: STM32 ST Micro STM32 priority: low Low impact/importance bug

Comments

@vincemulhollon
Copy link

Describe the bug

If you look in bootloader/mcuboot/boot/zephyr/boards/disco_l475_iot1.conf as installed by West, you can see the line:
CONFIG_BOOT_MAX_IMG_SECTORS=256

That will result in "mcuboot: Failed reading sectors; BOOT_MAX_IMG_SECTORS=256 - too small?" upon boot.

The error messages disappear if you change that line to:
CONFIG_BOOT_MAX_IMG_SECTORS=512

This is trivially verifiable by plugging in a STM32 Cube Programmer and going to "Erasing and Programming" tab and simply scrolling thru the list of 512 sectors.

Also if you obtain a copy of "RM0351 STM32L47xxx, STM32L48xxx, STM32L49xxx and STM32L4Axxx advanced Arm®-based 32-bit MCUs" from ST around page 97 you can read all about the 1 meg flash having 2 K sectors which would imply 512 sectors on board and also see ST manual RM0351 table 8 1 MB dual bank organization" which lays out the sectors in the last column, admittedly labeled as "page" not "sector" but whatever.

I am aware of previous bug your number #24243 where the sector count was bumped from 128 to 256 and am somewhat mystified that I have hardware requiring 512 sectors.

I would theorize that old versions of the IOT board shipped with 512K chips and the product was updated at some point to 1M chips? Or perhaps ST changed from 4K sector size to 2K sector size at some point.

I ran a "west build -b disco_l475_iot1 -d build_mcuboot bootloader/mcuboot/boot/zephyr -p" configured with 256 sectors and obtained:

Memory region Used Size Region Size %age Used
FLASH: 51436 B 64 KB 78.49%
SRAM: 27680 B 96 KB 28.16%
IDT_LIST: 0 GB 2 KB 0.00%

Then I configured bootloader/mcuboot/boot/zephyr/boards/disco_l475_iot1.conf for 512 sectors and recompiled with the following results:

Memory region Used Size Region Size %age Used
FLASH: 51436 B 64 KB 78.49%
SRAM: 33824 B 96 KB 34.41%
IDT_LIST: 0 GB 2 KB 0.00%

So this change would cost 6144 bytes of RAM, which is a struct with 24 bytes per sector.

Please also mention any information which could help others to understand
the problem you're facing:

disco_l475_iot1.conf, an admittedly ancient board using a 2015 chip from seven years ago and only having 128K of ram.

To Reproduce
Steps to reproduce the behavior:

Simply compile MCUboot on a disco_l475_iot1 and boot it and observe the error message.

Expected behavior
A clear and concise description of what you expected to happen.

No error message.

Impact
What impact does this issue have on your progress (e.g., annoyance, showstopper)

annoyance, some level of comedy.

Logs and console output
If applicable, add console logs or other types of debug information
e.g Wireshark capture or Logic analyzer capture (upload in zip archive).
copy-and-paste text and put a code fence (```) before and after, to help
explain the issue. (if unable to obtain text log, add a screenshot)

W: Failed reading sectors; BOOT_MAX_IMG_SECTORS=256 - too small?

Environment (please complete the following information):

Installed in a WSL, but I don't think it would matter; you have a flash chip with 512 sectors and a config file saying it has 256 sectors; going to get an error for that regardless of compilation environment.

Additional context

No additional context I can think of.

Best of luck to you and thanks for your time.

@vincemulhollon vincemulhollon added the bug The issue is a bug, or the PR is fixing a bug label Apr 11, 2022
@carlescufi
Copy link
Member

@vincemulhollon could you open a Pull Request with the suggested fix?

@FRASTM FRASTM added the platform: STM32 ST Micro STM32 label Apr 12, 2022
@nordicjm
Copy link
Collaborator

This should be updated in the upstream mcuboot repo https://github.com/mcu-tools/mcuboot

@mbolivar-nordic mbolivar-nordic added the priority: low Low impact/importance bug label Apr 12, 2022
@mbolivar-nordic mbolivar-nordic assigned erwango and FRASTM and unassigned erwango Apr 12, 2022
@vincemulhollon
Copy link
Author

vincemulhollon commented Apr 12, 2022

This should be updated in the upstream mcuboot repo https://github.com/mcu-tools/mcuboot

Correct in that mcuboot is a 3rd party module with its own repo, however the file specifying 256 sectors was added by Zephyr not McuBoot.

Edited comment to include that the exact filename under discussion is bootloader/mcuboot/boot/zephyr/boards/disco_l475_iot1.conf which is not in MCUBoot repo.

@nordicjm
Copy link
Collaborator

@vincemulhollon
Copy link
Author

You mean this file, in the upstream zephyr repo, https://github.com/mcu-tools/mcuboot/blob/main/boot/zephyr/boards/disco_l475_iot1.conf

LOL sorry you are indeed completely correct.

@erwango
Copy link
Member

erwango commented Apr 29, 2022

@vincemulhollon Can you close this issue an open it in https://github.com/mcu-tools/mcuboot ?

@vincemulhollon
Copy link
Author

OK I opened

mcu-tools/mcuboot#1361

and will close this issue.

Thanks for your time!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug The issue is a bug, or the PR is fixing a bug platform: STM32 ST Micro STM32 priority: low Low impact/importance bug
Projects
None yet
Development

No branches or pull requests

6 participants