Bootloader mcuboot with custom device #401
Comments
|
I had to remove "device_name": "HMC20" in custom targets. Strange that my original application never complained about this. But now I have something like a loop: I was also wondering if I need:
|
|
@lefebvresam this seems like a separate issue around project configuration...
|
|
First point was not comitted yet. If you mean this: There was a complaint that IROM1 was not existing. Point 2: Where is the clash then? versus? |
|
I just pushed my test changes but it is still not compiling. I always have the issue with 'first defined here' To run, just 'sh build.sh -d' |
|
Thank you!
BR, Jan |
|
It compiles when I put this in omment. No clue why you need mbed-core-flags then (also compiling without). It compiles also when I put mbed-baremetal in comment and make mbed-baremetal private in the top level. However I think I best change the dependency to Jamie's version. |
|
From my point of view you should have mbed-os or mbed-baremetal (never both at once) just one time per app.
Agreed. |
|
I updated the project with the new lib and the branch. Why this IROM1 setting is needed? #define MBED_ROM_SIZE 0x100000 // 1MB A macro at custom targets? |
|
What I also do not really understand is if you follow the procedure on AGlass0fMilk you get a file with rsa_pub_key[], and in the example I see enc_priv_key[]. |
|
Sorry I really just started on the mcuboot stuff, I haven't really done anything other than update the build system yet. You should definitely use my fork of mcuboot to fix the link errors, but I still need to actually get a basic example working |
|
In order to make things work properly with the bootloader, you will need to use |
|
I use a custom target inherited from MCU_STM32U575xG. Are there some examples how to change/adapt the linker script? |
|
Actually, yeah! Been working on an update for the K64F here: https://github.com/mbed-ce/mbed-os/tree/dev/k64f-linker-script-refactor |
|
Is it the purpose that this:
Is in line with this:
Or where do you find the right details specific for the controller? |
|
Yeah, you will find this info in the memory map section of the datasheet, or (apparently) in CubeIDE |
|
I see it's essentially renaming stuff. In my case there is no differentiation between RAM1, 2 or 3. I'm I right that the only purpose is to let the compiler believe that the size of the flash is only 0x20000 in order to have the code fit in that part before adding different hex files to create the complete image? I have no clue what .text and .bss and others exaclty mean. |
|
These definitions allow you to change memory settings according to your requirements via configuration without direct intervention to the linker script. It should working probably like that
These are basics how to achieve or understand a simple bootloader and also handy for start with Mcuboot I think. Only a method how to merge both binaries to one is missing. EDIT:
|
|
Thank you very much. I will test this procedure tomorrow. To be honest I never worked with linker scripts and I was starting to read a bit about this topic but it requires a deeper knowledge about ARM architecture I guess. I even didn't know exactly what to change and why. What is missing or wrong in the current linker scripts? Fyi the controller I use is STM32U575RGT6. To merge the hexes my idea is to test the procedure described on mbed-mcuboot-demo. The memory size is exactly the same as in my case (1MB) and my idea is to write a piece of software to transfer a bin file from the SD card to a separate flash chip I already use to store my images in my HMI display application to provide the secondary slot. |
|
I did the whole procedure and it compiles without errors, but the strange this is that I still see: ROM Bank Flash: 80505(+0)/1048576 bytes used, 7.7% (+0.0%) used -> that's still 1MB |
|
This looks better, the "target.memory_bank_config" was not member of the HMC20 custom device. |
Just for clarification. The "target.memory_bank_config" should be just in |
|
Is this still necessary in mbed_app.json5? And why the modficiations are needed in the linker script as you proposed in issuecomment-2526407974? It compiles exactly the same without these modifications. |
Nope, this one was working in ARM Mbed, in MbedCE this is not implemented. |
|
I'm now preparing my main application. Do I also have to switch to bare metal? I currently have: I'm also facing this now: |
|
That is up to you. |
|
I see this error is invoked because of the latest commit in the branch mbed-ce-update-cmakelists, "Start on automation for creating images". Is this something I already have to deal with or do I need to stay on the previous commit? |
|
Sorry, I don't understand your description. Do you mean a commit in Jamie's McuBoot? I do not see any error. |
|
The requirement to define variabele MCUBOOT_SIGNING_KEY is something thas has been added in this recent commit of the mbed-ce-update-cmakelists branch of |
|
Ok, so it is related to McuBoot and Jamie's current work. I have no idea about this, sorry. |
|
After doing all the right configuration for the primary application it looks like the start address is not picked up in the right way: And I get a lot of those messages: Is there something I miss in the configuration? |
|
My test application boots but the first time I cannot confirm, which could be normal. I took over almost everything exactly in my head application and the primary image won't boot: To ensure I have something on the screen I print some text at start: I also tested with printf(...) but no difference. |
|
@lefebvresam did you encrypt your initial image? We shall only encrypt images used for upgrade. |
|
@zhiyong-ft I followed your instructions to add encryption support to the CMake build scripts. Please give it a shot if you get a chance, all the updates are pushed. Unfortunately it is not working on my end, have not had time to debug: |
|
but what I did do is redraw George's diagram to be more accurate to Mbed CE!
|
I don't use ecryption currently, just performed the same steps: I also tested with --align 8 |
|
@multiplemonomials I can confirm that encrypted image works on F767 as well, at least once. The SPIF block device driver for S25FL256L is still a bit funky, so anything related to SPIF doesn't work reliably. We are switching to a known QSPIF chip in next version of PCB, so I will stop fighting it. But encrypted images work reliably on DISCO_F746NG with QSPIF as secondary block device. This test was done with mcuboot as of commit: 0fa393ad641ce651f7380c10dbb6def26e5ffe9e, I will test newer version later. |
The root cause here is because I read version number outside the main function, and after a long chain of calls there is |
|
@multiplemonomials I got encrypted image to work reliably on F767. I made some stupid mistakes when juggling around the erase sector sizes. So as far as I am concerned, mcuboot just works fine. Not sure why you had problems, my guess is that you either encrypted initial image, or there is something related to SD card if you used it as secondary block device. I am still using |
|
I sign a primary image with version 1.1.3+4, then I create a test update merged.bin: signed-update.bin: Reading the flash: |
|
If you call boot_read_image_header() in swap_scratch.c: This seems not to be logical. |
|
@lefebvresam what MCU are you using? The starting address
Keep in mind the region for application header has to be an erasable block or sector. |
|
This is correct. But I'm hunting for the issue. I recuperated a (wrong) piece of code to get the version number. If you don't offer the right data to the calls, the wrong parts in the calls are executed with unexpecting behavior. In the original one, the struct Alternative is skipping the call to Reading out version numbers of images is a very essential feature. I don't know why this is deleted in the current codebase. |
I did the whole procedure to encrypt the images and I get: I also edited the cmake file: |
The update image doesn't seem to have been encrypted. I used the imgtool from mcuboot v1.8.0 to manually sign and encrypt images, only used the latest version as bootloader. |
|
I pulled all the latest upstream updates in my mcuboot branch.
|
Why the update image must not be encrypted? The bootloader won't start the primary image, as at the error point has nothing to do with update image. |
|
mcuboot mbed_app.json |
|
It looks like mcuboot don't know to start an encrypted image. And I did 'full' compiles by deleting the build folder first. |
Image for initial download shall NOT be encrypted. Encryption only applies to update image, to prevent them from being stolen during transportation or being stored in external devices such as SPIF or SD card. Remove `-E enc_key_pub.pem' and try again. I manually signed and encrypted images so I didn't notice this. @multiplemonomials could you remove encryption from signing tool for initial image? |
|
That looks better: I updated my demo project with: Confirming the primary image is not necessary and gives an error: Avoid endless loop: Do automatic reboot: I updated my two test projects: |
|
What I do not understand is why you don't need to append application trailer TLV's in the update image during signing while they are a part of the secundary slot. |
|
And also, how to protect against copycat? Can you still do mcuboot updates when you protect the flash for readout? |
I didn't particularly look into this. My understanding is that this is mostly a workflow issue. Supposedly primary image will need to do some verification after acquiring/noticing the existence of image in secondary slot, then add necessary TLVs before handing it to bootloader. I actually padded update image as well to work around some other issues. The caveat is that once reboot, bootloader will always try to upgrade. If the update image is not padded, primary application needs to call But my understanding above is based on MCUBoot v1.8.0 and reading documentation from Mr. Beckstein's repo. In a later discussion with Mr. Smith, he mentioned that we shall/can use the same un-padded image for both initial download and upgrade, at least with the latest version of MCUBoot. So I might be wrong/out of dated. Please do some investigation and report back. |
That's what is encryption is for. Bootloader has a copy of private key, stored in |
Do you mean that primary image is adding some TLV's in the secundary slot after calling 'boot_set_pending'? |
So it means that the update image is deccrypted by the bootloader |
That's my understanding. When I tested on DISCO_F746NG, without calling this function, bootloader will ignore image stored in secondary slot, even it is a newer version. I treat this as some kind of feature, because sometimes you do want user's input/approval and just blindly update whatever image in the secondary slot. |
|
And is there a way to allow only upgrade and not downgrade or do you need to program it by yourself in your application by using my new function to read-out image versions? |
MCUboot will decrypt encrypted image stored in secondary slot chunk by chunk before writing decrypted chunks into primary slot. There is some discussion about treatment of scratch/swap in the MCUboot documentation but I don't recall. For this and your other question, you will have to consult documentation of MCUboot. My understanding is once image chunk is decrypted and stored in primary slot, MCUboot will think it is secure and don't do anything about it. You will have to do something to prevent people from reading the entire internal flash through JTAG or similar. |
I'm doing an attempt to create a project with mcu-bootloader as described on mbed-mcuboot-demo
But with the new toolchain (git submodules, cmake, etc..)
After creating a project, importing the libs and producing the necessary files, I try to do sh build.sh -d and I get
'missing MCU description' and I have a custom_targets.json5
I made to project temporary public for testing purposes:
bitbucket.org/saleconix/mcuboot.gitAdding this
or this
is not helping
The text was updated successfully, but these errors were encountered: