Documentation of bootloader example

[phidahl]

I suggest on elaborating more on the pico-examples/bootloaders/encrypted example. As far as I dug into the documentation this example might become a reference implementation for those with the need to execute encrypted code on RP2350 devices. This capability is of great importance for most commercial users here.

The problem I encountered is, that the bootloader often fails with other binaries than the hello_serial example. The encryption and signature worked. But in the very end

rc = rom_chain_image(
        workarea,
        sizeof(workarea),
        SRAM_BASE,
        data_size
    );

returns with a value of -4. This means according to the headers BOOTROM_ERROR_NOT_PERMITTED.

It keeps me puzzled since I have used the bootloader, the partition table etc exactly as in the example. Make the binary bigger sometimes helped and it worked.. The binary should be small enough with 75 kbyte and lots of free space for the heap.

What I also don't understand is that I assumed that the bootloader does not write to the flash, but only to RAM. So why can there be a permission problem?

Having those error codes mentioned in the readme with an explanation would be helpful.

[will-v-pi]

The problem I encountered is, that the bootloader often fails with other binaries than the hello_serial example.

Can you share any of these other binaries, as this sounds like a bug which needs to be fixed

[phidahl]

I'll try to come up with a minimal example reproducing this behaviour. The binaries and keys I cannot share. Sorry.

[will-v-pi]

I've managed to reproduce this with the hello_usb example, and it seems to be an issue in picotool encrypt when there is a gap between the .text and .rodata sections in the ELF file. I will investigate further, but for a temporary fix you can apply this diff to the pico-sdk and it should work.

--- a/src/rp2_common/pico_crt0/rp2350/memmap_no_flash.ld
+++ b/src/rp2_common/pico_crt0/rp2350/memmap_no_flash.ld
@@ -70,10 +70,10 @@ SECTIONS
         *(.dtors)
 
         *(.eh_frame*)
+        . = ALIGN(8);
     } > RAM
 
     .rodata : {
-        . = ALIGN(4);
         *(.rodata*)
         *(.srodata*)
         . = ALIGN(4);

[phidahl]

That is interesting! Thanks! I'm still working on my minimal example. It seems that if I add tinyusb to hello_serial example, causes the error. But only if I add some arrays to bloat the code. But this seem to be consistent with your findings on hello_usb.

[richard9999999999]

I've managed to reproduce this with the hello_usb example, and it seems to be an issue in picotool encrypt when there is a gap between the .text and .rodata sections in the ELF file. I will investigate further, but for a temporary fix you can apply this diff to the pico-sdk and it should work.

--- a/src/rp2_common/pico_crt0/rp2350/memmap_no_flash.ld
+++ b/src/rp2_common/pico_crt0/rp2350/memmap_no_flash.ld
@@ -70,10 +70,10 @@ SECTIONS
         *(.dtors)
 
         *(.eh_frame*)
+        . = ALIGN(8);
     } > RAM
 
     .rodata : {
-        . = ALIGN(4);
         *(.rodata*)
         *(.srodata*)
         . = ALIGN(4);

I have similar problem: when I load encrypted uf2 file (using picotool), it works. However when I load bin variant of the same binary, it fails (rom_chain_image() returns -4). It is my own binary with cca 300kb of size. When I try to load hello_serial_enc example binary it works for both formats (uf2 and bin).. The above workaround seems does not have effect.. ..At the moment it seems it works for bin images of Debug build and does not work for bin images of Release build (however I suppose it is rather related to image size somehow). Uf2 images works from all types of builds.

[lurch]

I have similar problem: when I load encrypted uf2 file (using picotool), it works. However when I load bin variant of the same binary, it fails (rom_chain_image() returns -4). It is my own binary with cca 300kb of size.

Also reported at https://github.com/raspberrypi/pico-sdk/issues/2321 (just adding this comment to keep all the different conversations linked together)

[lurch]

The above workaround seems does not have effect..

Did you delete your build folder after applying @will-v-pi 's patch?

[richard9999999999]

Did you delete your build folder after applying @will-v-pi 's patch?

Yes..