rp2040 / rp2350 xoscFreq setting is nonfuctional

[cibomahto]

The RP2040 and 2350 board files all specify a parameter for the external crystal frequency, xoscFreq. This appears to be so that a different external crystal could be used on a particular board.

Unfortunately, the PLL configurations for the system and USB clock are hard-coded to assume a 12MHz input clock, so this setting doesn't actually work. Finding an optimal setting for the PLL is complicated, and it's probably best not to do this on the fly during the startup code.

I can think of two straightforward solutions:

1. Remove the xoscFreq setting. The majority of RP2040 or RP2350 designs should be expected to use a 12MHz crystal.
2. Add the two PLL configurations to the board (or target) configuration, so that a custom crystal frequency can be used correctly.

I think option 1 better, unless someone has a board with a nonstandard clock that they need to support. I couldn't find examples of other machines/boards that support a similar feature. If either of these sound reasonable, I'd be happy to make a pull request.

cc @soypat @deadprogram

[cibomahto]

I created a clock configuration structure, made a default in machine_rp2_2xxx.go, then modified the board files to create a new object based on the default.

This appears to work if I build a target locally, however the CI test fails because it appears to be building a test for WASM based on the board file, but not including the machine backend. So I imagine that this wasn't the right way to do this :-)

If anyone has an example of a TinyGo way to achieve this let me know. Otherwise I'm out of guesses.

[deadprogram]

Looking into this today...

[cibomahto]

@deadprogram thanks! See #4674 for some more discussion about this

[soypat]

I believe this was addressed in #4768

xoscfreq is now functional and CPU frequency is calculated at compile time, huge wins! RP2040 is now running at 200MHz in dev :)

[deadprogram]

Now closing with 0.37.0 release. Thanks!