Add RP2350 support

[soypat]

Seeks to solve #4452.

Notes:

• gen-device-svd.go Changed to support multiline Metadata descriptions such as the one found for the RP2350.
• rp2350.ld takes rust version as reference. Ideally I'd like a minimal version, I've left it all in so people with more experience can note of what is required and what is "extra"
• There's two packages, QFN-60 with 30 GPIOs and QFN80 with 48 GPIOs. I imagine we could expose all 48 GPIOs for the rp2350 and avoid making the distinction at the package level. Board would expose GP* pins.
• Pico-sdk's second stage bootloader is spagghetified from what I can tell. Not sure which is the assembly we should be running... that said:
• Likely candidate is boot2_generic_03h which is apparently what Rust uses. I've tried adding it as best as I could

[github-actions]

Size difference with the dev branch:

Binary size difference

not the same command!
    tinygo build -size short -o ./build/test.hex -target=feather-rp2040 ./examples/adafruit4650
    go: downloading tinygo.org/x/tinyfont v0.3.0
drivers/sizes-dev.txt has more commands than drivers/sizes-pr.txt
    tinygo build -size short -o ./build/test.hex -target=itsybitsy-m0 ./examples/bh1750/main.go
 flash                          ram
 before   after   diff          before   after   diff
  16712   16712      0   0.00%    4172    4172      0   0.00% tinygo build -size short -o ./build/test.hex -target=feather-rp2040 ./examples/adafruit4650
  61416   61416      0   0.00%    6180    6180      0   0.00% tinygo build -size short -o ./build/test.hex -target=itsybitsy-m0 ./examples/adt7410/main.go
   9568    9568      0   0.00%    4748    4748      0   0.00% tinygo build -size short -o ./build/test.hex -target=itsybitsy-m0 ./examples/adxl345/main.go
  13564   13564      0   0.00%    6788    6788      0   0.00% tinygo build -size short -o ./build/test.hex -target=pybadge ./examples/amg88xx
   8680    8680      0   0.00%    4740    4740      0   0.00% tinygo build -size short -o ./build/test.hex -target=itsybitsy-m0 ./examples/apa102/main.go
  11828   11828      0   0.00%    6580    6580      0   0.00% tinygo build -size short -o ./build/test.hex -target=nano-33-ble ./examples/apds9960/proximity/main.go
   9760    9760      0   0.00%    4752    4752      0   0.00% tinygo build -size short -o ./build/test.hex -target=itsybitsy-m0 ./examples/apa102/itsybitsy-m0/main.go
   8368    8368      0   0.00%    2320    2320      0   0.00% tinygo build -size short -o ./build/test.hex -target=microbit ./examples/at24cx/main.go
 139896  139896      0   0.00%   40280   40280      0   0.00%

[deadprogram]

This is great @soypat thank you for getting going on it!

Please see tinygo-org/cmsis-svd-data#1 for some related supporting work.

[soypat]

Yes! I've looked at it and generated the device definitions. I just added a new commit with stubs for machine and runtime and am getting the following error during linking:

$ tinygo build -target=rp2350 -serial=none  examples/blinky1 
ld.lld: error: unable to insert .start_block after .vector_table
ld.lld: error: no memory region specified for section '.ARM.exidx'
ld.lld: error: no memory region specified for section '.text'

[deadprogram]

I'm not too sure that the ld file you added will actually work with TinyGo. You probably need to have mostly the same symbols in same order as other platforms.

[soypat]

OK, blinky1 now compiles. I am afraid of flashing the resulting .uf2 😅

[soypat]

I've noticed the bootloader is not included in the build pipeline. I can write invalid assembly in it and everything still compiles...

[rminnich]

my main concerns:
absolutely, make sure serial out is functional
make sure panic works
empty functions should panic
make sure all that stuff in ldscript is right
#if should have no defaults, there should always be a value, and the default should be "something was not set that is expected to be set"

[rminnich]

Are these known to match the machine hardware? This is one of the places you really want to get it right, or you'll be in Debug Hell forever.

[rminnich]

I would make the #else have an actual value, #elseif arm and have the fallthrough #else do a #error. Maybe that's too picky, but I've been burned by default behavior.

[soypat]

@rminnich I'll leave all functions so far in panic("unimplemented") state. We should focus on getting the bootloader working and setting the LED pin high/low.

[soypat]

@deadprogram @aykevl I'm melding the RP2040 and RP2350 APIs... it's got some design decisions that some may consider questionable. I've managed to reuse a lot of logic between them at the cost of some magic constant weirdness. There are a few cases where code reuse was just not worth it though such as with the peripheral reset. Love to hear your input on how it is coming along.

[soypat]

OK I feel like I've gotten the hang of writing Cortex assembler and understand what is going on with the linker scripts. I cannot however get to the point of flashing the RP2350 correctly- after I flash it the RP2350 enters bootoader mode and appears as a mass storage device ready to get flashed again.

[soypat]

Aha, looks like things have changed since the RP2040. We now have to build a valid IMAGE_DEF, which is a binary blob with specific format.

[soypat]

Working on a a pico binary encoder/decoder https://github.com/soypat/picobin. Raspberry Pi's picotool is missing lots of features to inspect binaries, which makes sense- it's not designed to reverse engineer their stuff.

Also RP2350 documentation on pico binary layout is VERY lackluster compared to their hardware documentation so having code to describe the layout gives me confidence on what exactly is going on.

[soypat]

OK. I've run into a limitation of the debug/elf package. I need to patch the bootloader by extending its length. I'm thinking of adding a elf implementation that can get the job done to https://github.com/soypat/tinyboot.

Note: @aykevl This PR would add aforementioned tinyboot as a dependency of tinygo compiler. I'm in favor of third partying build tools so that others can use the package and find bugs in parallel to the TinyGo compiler.

Edit: progress here: https://github.com/soypat/tinyboot/tree/main/build/xelf

[cibomahto]

Thanks for all you great work on this! I was able to bodge together enough fixes to build a working RP2350 GPIO out example here: Blinkinlabs@fbb5234

I cheated in several ways to get it to work so it isn't pullable as-is. The main changes were:

• remove the second stage bootloader- the documentation suggests that it's no longer needed unless you have a weird spi flash chip, and elf files generated by the pico 2 sdk don't seem to include it. The functionality has been moved into the boot rom.
• add a stub embedded block right after the isr vector table, so that the boot rom can identify the image. I borrowed this from the rp2350 datasheet. A more complete system like you are describing would include a second block at the end of the image. The elf files generated by the pico 2 sdk include this second block. I think the only function it serves is to verify that the entire image was written into flash, as the default block doesn't include an image checksum.

After disabling some other initialization bits which were causing the image to hang, I succeeded in running a very short that just turns the LED on and off repeatedly.

package main

import (
        "machine"
)

func main() {

    led := machine.LED
    led.Configure(machine.PinConfig{Mode: machine.PinOutput})

    for {
        led.Low()
        led.High()
    }
}

[cibomahto]

Here's also a very basic python tool for extracting IMAGE_BLOCKs from rp2350 ELF files: https://gist.github.com/cibomahto/790c1a34d6001a088de9bfba6e27ed23

[aykevl]

I need to patch the bootloader by extending its length.

@soypat What do you mean by this? It's generally not possible to move stuff in the firmware file after linking.

[aykevl]

Would it be possible to write binaries in a similar way that ESP8266/ESP32 binaries are created? So the ELF file is not modified, instead the ELF file is converted to a binary in a custom way that adds the special header.

[cibomahto]

@aykevl Looking at the esp builder:

I think not, because for the RP2350, the pico SDK generates a normal ELF image, just with some magic headers embedded in it.

For RP2350 ELF output, the pico SDK generates a normal ELF file directly, with one info block tucked between the isr table and the start of program image, and another in a second ELF section, at the end of the program image. The first one needs to include an offset to the second one (which needs to be calculated after the program image size is determined), but the second one points back to the memory address of the first one, which should be fixed. If this is done as a post-processing step, it does require rewriting the ELF file in order to make those two changes. Perhaps the builder could insert a dummy section for the second block, and then patch it with elfpatch? At a glance, this seems like it should also allow UF2 files to be generated from the patched ELF.

However, the datasheet also gives an example of a minimum implementation that doesn't need any post processing, just a simple header that needs to be placed in the first 4k of the image. I've chosen this approach to get a basic output working. The disadvantage of this is that it won't support any of the fancier validation options that the rp2350 boot rom offers, such as image signing or partition support.

[aykevl]

However, the datasheet also gives an example of a minimum implementation that doesn't need any post processing, just a simple header that needs to be placed in the first 4k of the image.

That looks like a much simpler way to do it!
This doesn't require any patching or rewriting of the ELF file, right? Just a way to tell the linker to put that magic block at the right position (presumably after the interrupt table).

The first one needs to include an offset to the second one (which needs to be calculated after the program image size is determined),

This can probably also be done by the linker, with some special assembler magic.

[cibomahto]

However, the datasheet also gives an example of a minimum implementation that doesn't need any post processing, just a simple header that needs to be placed in the first 4k of the image.

That looks like a much simpler way to do it! This doesn't require any patching or rewriting of the ELF file, right? Just a way to tell the linker to put that magic block at the right position (presumably after the interrupt table).

Correct. These 'blocks' each contain a pointer to the next block, in the form of an offset. The rp2350 bootrom uses the offsets to walk through the block chain, and to verify that they form a closed loop back to the first block. The trick is that if you only have one block, you can point it back to itself by specifying a zero offset, so no calculation needs to be done.

For the proof of concept, I gave it an explicit position by modifying the arm linker file: Blinkinlabs@fbb5234#diff-2048f2f7e5dcd7f7efd321f90018d841b002168ec4aa103d33363f4f4f316171R12 .

This is very straightforward, but seems a little invasive to add that for all ARM targets. Another straightforward option is to include a modified version of arm.ld just for the rp2350, but I don't see any other examples that do that and it's probably more difficult to maintain. Maybe there's an assembler directive to put something at the beginning of .text?

[aykevl]

For the proof of concept, I gave it an explicit position by modifying the arm linker file: Blinkinlabs@fbb5234#diff-2048f2f7e5dcd7f7efd321f90018d841b002168ec4aa103d33363f4f4f316171R12 .

Actually in my opinion it's fine, if the name is slightly different. Something more generic/descriptive. What about KEEP(*(.after_isr_vector))? Maybe with a short note like /* for the RP2350 */.

[soypat]

What do you mean by this? It's generally not possible to move stuff in the firmware file after linking.

Not without great effort, which I was motivated to do at one point but no longer- Seeing @cibomahto PR that works looks like a good starting point. Let me know what I can do to get this merged ASAP.

[cibomahto]

I sent a pull request for the changes that I knew how to add properly. I know of at least these issues that are remaining:

• GPIO: Set the new 'isolation' bit for the RP2350 only: Blinkinlabs@fbb5234#diff-92842a5fcd6e32b41bc401586ea33fd04c1cfc107babed817b12118f08372667L129
• Decide what to do for resets- the behavior of the frceoff/frceon bits has changed in rp2350. Commenting them out at least let the image boot: Blinkinlabs@fbb5234#diff-a7f56abb731d6475be3a5d0641c86fe6fd50b065ff75b2d5d5fbf21a71fcb30cL28
• Figure out why the clock init hangs. Commenting it out allowed the image to boot: Blinkinlabs@fbb5234#diff-9e41e0242756386de153301b40712f687ae1925d01da8c6ec477d770c18bc4d8L61