fix(linker): IAP_Binary_Template length not shrunk after bootloader offset (STM32H743I-EVAL)#346
Open
94xhn wants to merge 2 commits into
Open
Conversation
Found by cross-checking each example's GCC (STM32CubeIDE)/IAR (EWARM)/ Keil (MDK-ARM) linker scripts against each other and against known-good Templates sibling projects, following the same audit already done for STM32CubeG4/WB/WL/U5/F7/F4/L4 in this repo family. 1. CM7 core of 18 dual-core (CM7+CM4) examples across STM32H745I-DISCO, STM32H747I-DISCO, and STM32H747I-EVAL (STM32H745/H747xI, 2MB flash physically split into two 1MB banks - bank1 0x08000000-0x080FFFFF for CM7, bank2 0x08100000-0x081FFFFF for CM4): both IAR's `.icf` and Keil's `.uvprojx` (CM7 target) declared the CM7 core's flash region as the full 2MB (0x08000000-0x081FFFFF), giving CM7 access to bank2 - the flash bank that's supposed to belong exclusively to CM4. GCC's `.ld` for the same 18 examples, and the board's own Templates project (e.g. `Templates/BootCM4_CM7/EWARM/stm32h7xx_CM7_FLASH.icf`), all correctly restrict CM7 to 1MB (bank1 only). This is a "2-of-3-toolchains-wrong" case - a naive majority vote here would have picked the wrong answer. NUCLEO-H745ZI-Q's equivalent examples were checked and are all correct, so this isn't a family-wide defect, just these two DISCO/EVAL boards. Fixed all 18 IAR `.icf` files' ROM_end from 0x081FFFFF to 0x080FFFFF, and all 18 Keil `.uvprojx` files' CM7-target OCR_RVCT4 Size from 0x200000 (2MB) to 0x100000 (1MB) - using a precise multi-line match on the CM7 target's specific StartAddress/Size pair so the sibling CM4 target block (already correct, different StartAddress) is left untouched. 2. IAP_Binary_Template (STM32H743I-EVAL): Keil's `.uvprojx` correctly offsets the app's flash start address to leave room for the bootloader, but never shrinks the length to compensate - OCR_RVCT4 still declares 2048K as if starting from 0x08000000, running past the chip's actual end of flash by exactly the size of the reserved bootloader region. IAR/GCC in the same project both correctly use 1920K. Fixed Keil's OCR_RVCT4 Size to 0x1E0000 (1920K). No local ARM toolchain (arm-none-eabi-gcc/IAR/Keil) available to compile/link-test these changes; verification relied on address-arithmetic cross-referencing against multiple independent references per finding (sibling toolchain files of the same project, Templates gold standards, and NUCLEO-H745ZI-Q's unaffected equivalent examples as a cross-board sanity check). Signed-off-by: 94xhn <87560781+94xhn@users.noreply.github.com>
|
I'm afraid this is wrong. |
The previous commit's finding STMicroelectronics#1 ("CM7 core given access to CM4's flash bank") was based on a mistaken premise. Per maintainer feedback (see RM0399 Table 2, "Bus-master-to-bus-slave interconnect"), both Flash bank 1 and Flash bank 2 are marked as accessible ("X") from the Cortex-M7 master (AXIM) as well as from the Cortex-M4 master (S-bus). There is no hardware access restriction preventing CM7 from using bank2 - the PR's description of bank2 as "exclusively meant for CM4" was incorrect, and the 36-file change (18 boards x IAR .icf + Keil .uvprojx) built on that incorrect premise should not have been made. This commit reverts all 36 files touched by that specific finding back to their pre-PR state, leaving only finding STMicroelectronics#2 (IAP_Binary_Template on STM32H743I-EVAL, a single-core H743 device unrelated to this dispute - Keil's OCR_RVCT4 length not shrunk after the bootloader offset) as the remaining, unaffected content of this PR. Signed-off-by: 94xhn <87560781+94xhn@users.noreply.github.com>
Author
|
Thank you for the correction and the reference, Xavier - you're right, and I apologize for the mistake. RM0399 Table 2 ("Bus-master-to-bus-slave interconnect", p.108) explicitly marks both Flash bank 1 and Flash bank 2 as accessible ("X") from the Cortex-M7 master (AXIM) as well as from the Cortex-M4 master (S-bus). There's no hardware access restriction preventing CM7 from using bank2, so describing it as "the bank exclusively meant for CM4" and treating IAR/Keil's 2MB declaration for the CM7 target as a bug was incorrect on my part. I've pushed a commit that reverts all 36 files from that finding back to their original state. The PR now only contains the other, unrelated finding ( Sorry for the noise, and thanks again for catching this. |
94xhn
changed the title
ALABSTM
added
bug
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Update: this PR originally contained a second finding (CM7 given "access" to CM4's flash bank on 18 dual-core examples) that was based on a mistaken premise - see the discussion below. That part has been reverted; only the finding below remains.
Not tied to a specific existing issue - found by cross-checking each example's GCC (STM32CubeIDE)/IAR (EWARM)/Keil (MDK-ARM) linker scripts against each other and against known-good
Templatessibling projects for the same chip.IAP_Binary_Template(STM32H743I-EVAL)Keil's
.uvprojxcorrectly offsets the app's flash start address to leave room for the bootloader, but never shrinks the length to compensate -OCR_RVCT4still declares 2048K as if starting from0x08000000, running past the chip's actual end of flash by exactly the size of the reserved bootloader region. IAR/GCC in the same project both correctly use 1920K. Fixed Keil'sOCR_RVCT4Sizeto0x1E0000(1920K).Test plan
No local ARM toolchain (arm-none-eabi-gcc/IAR/Keil) available to compile/link-test this change, so verification relied on address-arithmetic cross-referencing against IAR's and GCC's already-correct values in the same project.
Disclosure
Generative AI (Claude) was used to help investigate this (systematic cross-toolchain linker script comparison) and implement/verify the fix. All changes were reviewed by me before submission.