Hi all,
I am developing a solution on top of a custom RP2040 board, and my code for it uses a special second-stage bootloader that can load another application from the flash and execute it. It also stores data in multiple memory zones of the 16MB flash in the custom board. Here is a simplified memory map of the solution in the Flash memory:
I have also coded a simple Python application that creates a single UF2 file, putting the different pieces together, numbering the UF2 blocks properly, and placing the memory addresses of each block, too. And it works like a breeze with 'picotool'. Picotool understands that there are several sparse memory blocks and loads and allocates them properly. This is a classic output of the 'picotool load' command:
(Since no empty gap exists between the 'parameters' and 'catalog' memory blocks, it loads as a single block)
The problem comes when I try to use the boot ROM's drag-and-drop/copy feature. If I copy the same file used with the 'picotool' (sidecartridge-tos-emutos-192k.uf2 in the example above), it always fails. My guess is that the boot ROM loader does not support empty gaps between the memory blocks in the UF2 file, while 'picotool' does.
After creating a new UF2 file with empty blocks as valid UF2 blocks, it now works. The main difference between this new UF2 file and the previous one is that the empty blocks are now part of the UF2 file, even containing nothing, just to avoid any memory gap in the UF2 file. So, the new file is a huge continuum of memory blocks starting at 0x10000000 and ending at 0x10FFFFFF. Now it works for 'picotool' and the boot ROM loader, but the price is a 32MB file with >95% of space taking minutes to deploy when it could be just seconds.
So my question is: is there any way to make the ROM boot loader load a UF2 file with sparse memory blocks? Is there something I am doing wrong? Any help/hint would be appreciated.
I am developing a solution on top of a custom RP2040 board, and my code for it uses a special second-stage bootloader that can load another application from the flash and execute it. It also stores data in multiple memory zones of the 16MB flash in the custom board. Here is a simplified memory map of the solution in the Flash memory:
Code:
+-------------------------+-------------------------------+-------------+-------------+--------------+| Memory Address | Description | Block Number| Used blocks | Empty blocks |+-------------------------+-------------------------------+-------------+-------------+--------------+| 0x10000000 - 0x1001FFFF | emulator + bootloader app | 1-512 | 1-210 | 211-512 |+-------------------------+-------------------------------+-------------+-------------+--------------+| 0x10020000 - 0x1003FFFF | USB drive app | 513-1024 | 513-804 | 805-1024 |+-------------------------+-------------------------------+-------------+-------------+--------------+| 0x10040000 - 0x10FFDFFF | ROM binaries space | 1025-65504 | 1025-1793 | 1793-65504 |+-------------------------+-------------------------------+-------------+-------------+--------------+| 0x10FFE000 - 0x10FFEFFF | parameters | 65505-65520 | 65505-65520 | None |+-------------------------+-------------------------------+-------------+-------------+--------------+| 0x10FFF000 - 0x10FFFFFF | catalog | 65521-65536 | 65521-65536 | None |+-------------------------+-------------------------------+-------------+-------------+--------------+Code:
➜ sidecartos git:(main) ✗ picotool load ./dist/sidecartridge-tos-emutos-192k.uf2Loading into Flash: [==============================] 100%Loading into Flash: [==============================] 100%Loading into Flash: [==============================] 100%Loading into Flash: [==============================] 100%The problem comes when I try to use the boot ROM's drag-and-drop/copy feature. If I copy the same file used with the 'picotool' (sidecartridge-tos-emutos-192k.uf2 in the example above), it always fails. My guess is that the boot ROM loader does not support empty gaps between the memory blocks in the UF2 file, while 'picotool' does.
After creating a new UF2 file with empty blocks as valid UF2 blocks, it now works. The main difference between this new UF2 file and the previous one is that the empty blocks are now part of the UF2 file, even containing nothing, just to avoid any memory gap in the UF2 file. So, the new file is a huge continuum of memory blocks starting at 0x10000000 and ending at 0x10FFFFFF. Now it works for 'picotool' and the boot ROM loader, but the price is a 32MB file with >95% of space taking minutes to deploy when it could be just seconds.
So my question is: is there any way to make the ROM boot loader load a UF2 file with sparse memory blocks? Is there something I am doing wrong? Any help/hint would be appreciated.
Statistics: Posted by logronoide — Tue Jul 02, 2024 8:41 am