RP2350 - no_flash option generates duplicated 512 block within flash memory range

[bgolab]

Described here: https://forums.raspberrypi.com/viewtopic.php?p=2255127#p2255127

Probably E10 workaround is used here but this is against the idea of no_flash option (=do not touch the flash).

[bgolab]

Reading E10 description: "This is handled for you automatically by picotool in the SDK, which adds this block when generating UF2s if the --abs-block flag is specified"

Maybe we can disable this behavior using by removing " --abs-block flag"?

But probably the best way would be not to generate this flash targeted block when no_flash option is used.

[kilograham]

@will-v-pi i think this may already be fixed?

[will-v-pi]

Yes, already fixed in picotool develop - the flag still gets passed for no_flash binaries, but picotool correctly doesn’t add the abs-block

[bgolab]

Theoretical questions: could the drag & drop approach (I mean the approach without picotool used) work for SRAM targeted UF2 files (when no_flash used) provided that there no flash targeted block added at the beginning of the file (the one added as a fix for E10)?

If yes we need to remove this E10 fix from the UF2 file when no_flash option is selected - on only on the fly when the picotool is involved...

[will-v-pi]

Yes - it’ll work even with the abs-block in place

[bgolab]

I am thinking about drag & drop approach when the E10 is not placed in the UF2. Just wonder if the removal of the E10 for the UF2 file makes sense when no_flash is selected.

[will-v-pi]

The E10 block is only required for flash targeting UF2s which are going into a partition table, as detailed in E10. They’re not required for SRAM targeting UF2s, and therefore picotool should not add them to those.

It’s simpler for the SDK to always pass the flag and picotool to ignore it when not required, as this works better for things like packaged SRAM binaries, where the SDK compiles an SRAM binary and picotool packages it into a UF2 which targets flash

[bgolab]

So the drag & drop option is not supported for the SRAM-targeted builds as they always contain flash targeted block (the E10 fix) and as a results will do re-flashing...?

I believe the RPI still wants to support this option: "still plug the USB in and drag and drop their UF2 files"

https://www.raspberrypi.com/news/whats-new-in-pico-2/

[will-v-pi]

No, SRAM targeting (ie no_flash) binaries created by the SDK will work perfectly fine with drag & drop.

If they have an E10 abs-block then when you drag & drop, that abs-block will be written to flash before the binary is then written to SRAM and the chip reboots to execute that binary. Currently RP2350 SRAM binaries produced by the SDK have an E10 abs-block present - this is a bug in picotool and has been fixed in the develop branch, but the SRAM binaries will still work perfectly fine with drag & drop, even if there is no flash chip connected to the RP2350. The only downside is that this drag & drop will unnecessarily erase the last 4KiB of connected flash.

If they do not have an E10 abs-block then when you drag & drop the binary will be written to SRAM and the chip reboots to execute that binary. To get this behaviour now you can build and install picotool from the develop branch, or wait till the next SDK release - the develop branch of the SDK is not required for this fix.

[will-v-pi]

Also, just to clarify, as there may be a misunderstanding - picotool has replaced elf2uf2 in the 2.0.0 SDK, so it is used to create the UF2 files. It has been fixed in the develop branch to not add the E10 abs-block to no_flash UF2 files when creating them.

Separately from this, picotool is also a tool that can be used to load binaries onto a device. When loading UF2 files onto a device using picotool it will ignore any E10 abs-blocks in the UF2 files.