Add all metadata blocks to info #173

will-v-pi · 2024-11-12T13:50:17Z

This adds the -m, --metadata option to picotool info to print out details of all the metadata blocks in a binary.

Also standardise the indent for the whole picotool info command, so you don't get different sections with different indents.

For example, with the encrypted bootloader example it prints out:

$ picotool info -m enc_bootloader.uf2 
File enc_bootloader.uf2 family ID 'absolute':

Metadata Block 1
 address:               0x1000015c
 next block address:    0x10004e2c
 block type:            image def
 target chip:           RP2350
 image type:            ARM Secure
 vector table:          0x20070000

Metadata Block 2
 address:               0x10004e2c
 next block address:    0x10004ea0
 block type:            partition table
 partition table:       non-singleton
 un-partitioned space:  S(rw) NSBOOT(rw) NS(rw), uf2 { absolute }
 partition 0 (A):       00010000->00080000 S(rw) NSBOOT(rw) NS(rw), id=0000000000000000, "A", uf2 { rp2350-arm-s }, arm_boot 1, riscv_boot 1
 partition 1 (B w/ 0):  00080000->000f0000 S(rw) NSBOOT(rw) NS(rw), id=0000000000000001, "B", uf2 { rp2350-arm-s }, arm_boot 1, riscv_boot 1
 version:               1.0

Metadata Block 3
 address:               0x10004ea0
 next block address:    0x1000015c
 block type:            image def
 target chip:           RP2350
 image type:            ARM Secure
 load map entry 0:      Clear 0x20000000->0x20082000
 load map entry 1:      Copy 0x10000000->0x10004e2c to 0x20070000->0x20074e2c
 load map entry 2:      Copy 0x10004e2c->0x10004ea0 to 0x20074e2c->0x20074ea0
 vector table:          0x20070000
 hash:                  verified
 hash value:            C3591E6E0AB0E0213803CADEF0F1CEA4CE2D887FCD47CDE2FB5271A957B994F8
 signature:             verified
 signature value:       561075BB5B6C962382CC5D7331C4ED5967D8E42BAD17643CCE46BA15FD3D49555E754DABDC7DF5A61318287F95B19C0929E44D23EB00B3F984013A0C9D0BC6E4
 public key:            61826D3101465B8001F78B54DEEFD08ABE6C45C62305832A09AFBC831B1877D3B0312DDDA962AC9D5073772CBB6C559D2735C331BF68DB4C5145DE7B43DC5263

whereas the basic info only contains the metadata of the "best" block (the chosen block when performing an Arm boot)

$ picotool info enc_bootloader.uf2 
File enc_bootloader.uf2 family ID 'absolute':

Program Information
 name:          enc_bootloader
 web site:      https://github.com/raspberrypi/pico-examples/tree/HEAD/bootloaders/encrypted
 features:      UART stdin / stdout
 binary start:  0x10000000
 target chip:   RP2350
 image type:    ARM Secure
 hash:          verified
 signature:     verified

All info contains the metadata info, plus all the usual info

$ picotool info -a enc_bootloader.uf2 
File enc_bootloader.uf2 family ID 'absolute':

Program Information
 name:                  enc_bootloader
 web site:              https://github.com/raspberrypi/pico-examples/tree/HEAD/bootloaders/encrypted
 features:              UART stdin / stdout
 binary start:          0x10000000
 target chip:           RP2350
 image type:            ARM Secure
 hash:                  verified
 signature:             verified

Fixed Pin Information
 0:                     UART0 TX
 1:                     UART0 RX

Build Information
 sdk version:           2.0.1-develop
 pico_board:            pico2
 build date:            Nov 20 2024
 build attributes:      Debug

Metadata Block 1
 address:               0x1000015c
 next block address:    0x10004e2c
 block type:            image def
 target chip:           RP2350
 image type:            ARM Secure
 vector table:          0x20070000

Metadata Block 2
 address:               0x10004e2c
 next block address:    0x10004ea0
 block type:            partition table
 partition table:       non-singleton
 un-partitioned space:  S(rw) NSBOOT(rw) NS(rw), uf2 { absolute }
 partition 0 (A):       00010000->00080000 S(rw) NSBOOT(rw) NS(rw), id=0000000000000000, "A", uf2 { rp2350-arm-s }, arm_boot 1, riscv_boot 1
 partition 1 (B w/ 0):  00080000->000f0000 S(rw) NSBOOT(rw) NS(rw), id=0000000000000001, "B", uf2 { rp2350-arm-s }, arm_boot 1, riscv_boot 1
 version:               1.0

Metadata Block 3
 address:               0x10004ea0
 next block address:    0x1000015c
 block type:            image def
 target chip:           RP2350
 image type:            ARM Secure
 load map entry 0:      Clear 0x20000000->0x20082000
 load map entry 1:      Copy 0x10000000->0x10004e2c to 0x20070000->0x20074e2c
 load map entry 2:      Copy 0x10004e2c->0x10004ea0 to 0x20074e2c->0x20074ea0
 vector table:          0x20070000
 hash:                  verified
 hash value:            94C03FAF7D950F73D39F1BDC7B8426720884ACD146ACE39E5858AE13FB4EFF89
 signature:             verified
 signature value:       0B0A853CB5064F2809E0FC8E4286F713C2EF1FAD3ABD0CC358D927F12DCF02AE1B6C02D323253CB26D36FB7061DA184C29E35D2AD056CFD3377C290694F1C90B
 public key:            61826D3101465B8001F78B54DEEFD08ABE6C45C62305832A09AFBC831B1877D3B0312DDDA962AC9D5073772CBB6C559D2735C331BF68DB4C5145DE7B43DC5263

lurch · 2024-11-18T11:12:41Z

Are these "metadata blocks" equivalent to the "blocks" from the "block loop" described in section 5.1.5 of the RP2350 datasheet? I wonder if it'd also be useful to print the item_type of each block?

will-v-pi · 2024-11-18T11:21:23Z

Are these "metadata blocks" equivalent to the "blocks" from the "block loop" described in section 5.1.5 of the RP2350 datasheet? I wonder if it'd also be useful to print the item_type of each block?

Yes, that’s what these blocks are - the item_type is per item in the block (eg vector_table_item, image_def_item), but I can add a print for the block type (image_def, partition_table or ignored)

lurch · 2024-11-18T11:26:52Z

 load map entry 1:      Copy 0x10000000+0x4e2c to 0x20070000

So from what little I understand of section 5.9 of the RP2350 datasheet, I think this means "copy 0x4e2c bytes from 0x10000000 to 0x20070000", but I guess a naive interpretation might think that the + is indicating an offset, and so this line might be misinterpreted as "copy 0x10004e2c to 0x20070000" ?
The best non-ambiguous alternative I can come up with off the top of my head is:

 load map entry 1:      Copy 0x10000000:0x10004e2c to 0x20070000:0x20074e2c

to indicate that a range of bytes (which I assume is Flash) is being copied to some other range of bytes (which I assume is SRAM) ?

Similarly, perhaps

 load map entry 0:  Clear 0x20000000+0x82000

would be less ambiguous if written as

 load map entry 0:  Clear 0x20000000:0x20082000

? 🤷‍♂️

EDIT: Ah, I've just noticed that you're already using 00010000->00080000 in the partition info, so for consistency perhaps it makes sense to use -> instead of : in my "range" examples above. But also for consistency, perhaps it makes sense to add the 0x prefixes to the addresses in the partition info!

lurch · 2024-11-18T11:28:35Z

Are these "metadata blocks" equivalent to the "blocks" from the "block loop" described in section 5.1.5 of the RP2350 datasheet? I wonder if it'd also be useful to print the item_type of each block?

Yes, that’s what these blocks are - the item_type is per item in the block (eg vector_table_item, image_def_item), but I can add a print for the block type (image_def, partition_table or ignored)

Right, I guess I meant "block type" rather than "item type" 🙂

will-v-pi · 2024-11-19T15:47:16Z

Ah, I've just noticed that you're already using 00010000->00080000 in the partition info, so for consistency perhaps it makes sense to use -> instead of : in my "range" examples above. But also for consistency, perhaps it makes sense to add the 0x prefixes to the addresses in the partition info!

I've improved the load_map printouts to be 0xstart->0xend rather than 0xstart+0xsize - I think I'll leave the partition printouts for now because those are flash addresses, whereas the load_map addresses are in the RP2xxx address space, so it's fine to have some differences between them

lurch · 2024-11-19T16:27:49Z

I've improved the load_map printouts to be 0xstart->0xend rather than 0xstart+0xsize

Just for reference, could you update the examples in the first post please? 🙂

kilograham · 2024-11-19T20:45:20Z

This is all very nice, but I think:

$ picotool info enc_bootloader.uf2 
File enc_bootloader.uf2 family ID 'absolute':

Program Information
 name:              enc_bootloader
 web site:          https://github.com/raspberrypi/pico-examples/tree/HEAD/bootloaders/encrypted
 features:          UART stdin / stdout
 binary start:      0x10000000
 target chip:       RP2350
 image type:        ARM Secure
 load map entry 0:  Clear 0x20000000->0x20082000
 load map entry 1:  Copy 0x10000000->0x10004e2c to 0x20070000->0x20074e2c
 load map entry 2:  Copy 0x10004e2c->0x10004ea0 to 0x20074e2c->0x20074ea0
 vector table:      0x20070000
 hash value:        verified
 signature:         verified

load map/vector table should be guarded by -a/--all I think (possibly the hash/sig, though I'm happy with them if they are always succinct). Note, i just looked and i see they only have "verified/incorrect"; might be worth displaying something for present (or perhaps include the full hash/sig values on -a

lurch · 2024-11-19T23:41:52Z

I think I agree with Graham - probably makes sense to show the load map stuff when doing picotool info -m (as you're explicitly asking for extra-info), but not when doing just a picotool info (which should just provide basic info).

will-v-pi · 2024-11-20T14:42:40Z

Note, i just looked and i see they only have "verified/incorrect"; might be worth displaying something for present

It will only display that line if it's present, and then say verified or incorrect depending on whether the verification succeeded.

I can add verbose printout of the raw signature/hash bytes and public key when using -m or -a

will-v-pi · 2024-11-20T14:53:56Z

I think I've made all those changes - I've updated the description to the current state

main.cpp

lurch · 2024-11-20T15:08:09Z

I've updated the description to the current state

Looks good! 🙌

For bootloaders with embedded partition tables, now prints bootloader details before the partitions

Use start->end instead of start+size

…or -a) Also add full hash and sig bytes printouts when verbose

kilograham · 2024-11-20T17:11:18Z

cam you update the comment with -a too so we can see

will-v-pi · 2024-11-20T17:32:46Z

cam you update the comment with -a too so we can see

Added to the description - -a just prints the output of basic info combined with the -m output, plus the usual stuff

lurch · 2024-11-20T18:36:01Z

Only a small nitpick, but I wonder if it might make sense to reorder these rows slightly:

 hash:                  verified
 hash value:            C3591E6E0AB0E0213803CADEF0F1CEA4CE2D887FCD47CDE2FB5271A957B994F8
 signature:             verified
 signature value:       561075BB5B6C962382CC5D7331C4ED5967D8E42BAD17643CCE46BA15FD3D49555E754DABDC7DF5A61318287F95B19C0929E44D23EB00B3F984013A0C9D0BC6E4
 public key:            61826D3101465B8001F78B54DEEFD08ABE6C45C62305832A09AFBC831B1877D3B0312DDDA962AC9D5073772CBB6C559D2735C331BF68DB4C5145DE7B43DC5263

so that you get the "verified" after the values?

 hash value:            C3591E6E0AB0E0213803CADEF0F1CEA4CE2D887FCD47CDE2FB5271A957B994F8
 hash:                  verified
 signature value:       561075BB5B6C962382CC5D7331C4ED5967D8E42BAD17643CCE46BA15FD3D49555E754DABDC7DF5A61318287F95B19C0929E44D23EB00B3F984013A0C9D0BC6E4
 public key:            61826D3101465B8001F78B54DEEFD08ABE6C45C62305832A09AFBC831B1877D3B0312DDDA962AC9D5073772CBB6C559D2735C331BF68DB4C5145DE7B43DC5263
 signature:             verified

🤷

will-v-pi · 2024-11-20T19:03:17Z

Only a small nitpick, but I wonder if it might make sense to reorder these rows slightly:

 hash:                  verified
 hash value:            C3591E6E0AB0E0213803CADEF0F1CEA4CE2D887FCD47CDE2FB5271A957B994F8
 signature:             verified
 signature value:       561075BB5B6C962382CC5D7331C4ED5967D8E42BAD17643CCE46BA15FD3D49555E754DABDC7DF5A61318287F95B19C0929E44D23EB00B3F984013A0C9D0BC6E4
 public key:            61826D3101465B8001F78B54DEEFD08ABE6C45C62305832A09AFBC831B1877D3B0312DDDA962AC9D5073772CBB6C559D2735C331BF68DB4C5145DE7B43DC5263

so that you get the "verified" after the values?

 hash value:            C3591E6E0AB0E0213803CADEF0F1CEA4CE2D887FCD47CDE2FB5271A957B994F8
 hash:                  verified
 signature value:       561075BB5B6C962382CC5D7331C4ED5967D8E42BAD17643CCE46BA15FD3D49555E754DABDC7DF5A61318287F95B19C0929E44D23EB00B3F984013A0C9D0BC6E4
 public key:            61826D3101465B8001F78B54DEEFD08ABE6C45C62305832A09AFBC831B1877D3B0312DDDA962AC9D5073772CBB6C559D2735C331BF68DB4C5145DE7B43DC5263
 signature:             verified

🤷

I actually prefer it this way round - so you can see the important bit first (that the sig/hash is verified), and then the extra info comes after

kilograham · 2024-11-20T22:28:37Z

i agree with above; one last nit though can we put the -m info after everything else; the info is kind of in the order of what user cares about most

will-v-pi · 2024-11-21T13:47:08Z

i agree with above; one last nit though can we put the -m info after everything else; the info is kind of in the order of what user cares about most

Done - I've moved it to just before device info

kilograham

nice

will-v-pi added this to the 2.1.0 milestone Nov 12, 2024

lurch reviewed Nov 20, 2024

View reviewed changes

main.cpp Outdated Show resolved Hide resolved

will-v-pi added 7 commits November 20, 2024 15:46

Add info for all metadata blocks

8be175e

Add metadata info for partition tables

5b2e4c4

Add printing of bootloader info

d4d62cf

For bootloaders with embedded partition tables, now prints bootloader details before the partitions

Improve load_map printout

8bf1e6c

Use start->end instead of start+size

Add image type info items

0c43730

Make load_map, rwd, vtor and entry_point only print when verbose (-m …

107b87f

…or -a) Also add full hash and sig bytes printouts when verbose

Rename best_block to current_block

0cae6b0

will-v-pi force-pushed the mb-info branch from 9633a0e to 0cae6b0 Compare November 20, 2024 15:46

will-v-pi mentioned this pull request Nov 20, 2024

add support for binaries behind boot loaders on device #82

Open

Move metadata info to end

69b52ba

kilograham approved these changes Nov 21, 2024

View reviewed changes

will-v-pi merged commit 4a403bb into develop Nov 21, 2024
35 checks passed

will-v-pi deleted the mb-info branch November 21, 2024 16:10

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add all metadata blocks to info #173

Add all metadata blocks to info #173

will-v-pi commented Nov 12, 2024 •

edited

Loading

lurch commented Nov 18, 2024

will-v-pi commented Nov 18, 2024

lurch commented Nov 18, 2024 •

edited

Loading

lurch commented Nov 18, 2024

will-v-pi commented Nov 19, 2024

lurch commented Nov 19, 2024

kilograham commented Nov 19, 2024

lurch commented Nov 19, 2024

will-v-pi commented Nov 20, 2024

will-v-pi commented Nov 20, 2024

lurch commented Nov 20, 2024

kilograham commented Nov 20, 2024

will-v-pi commented Nov 20, 2024

lurch commented Nov 20, 2024

will-v-pi commented Nov 20, 2024

kilograham commented Nov 20, 2024

will-v-pi commented Nov 21, 2024

kilograham left a comment

Add all metadata blocks to info #173

Add all metadata blocks to info #173

Conversation

will-v-pi commented Nov 12, 2024 • edited Loading

lurch commented Nov 18, 2024

will-v-pi commented Nov 18, 2024

lurch commented Nov 18, 2024 • edited Loading

lurch commented Nov 18, 2024

will-v-pi commented Nov 19, 2024

lurch commented Nov 19, 2024

kilograham commented Nov 19, 2024

lurch commented Nov 19, 2024

will-v-pi commented Nov 20, 2024

will-v-pi commented Nov 20, 2024

lurch commented Nov 20, 2024

kilograham commented Nov 20, 2024

will-v-pi commented Nov 20, 2024

lurch commented Nov 20, 2024

will-v-pi commented Nov 20, 2024

kilograham commented Nov 20, 2024

will-v-pi commented Nov 21, 2024

kilograham left a comment

Choose a reason for hiding this comment

will-v-pi commented Nov 12, 2024 •

edited

Loading

lurch commented Nov 18, 2024 •

edited

Loading