Core clock initialization

[9names]

I've ported some of the core clock initialization code from https://github.com/pine64/bl_iot_sdk and https://github.com/bouffalolab/bl_iot_sdk

Only the Strict API for clocks has been implemented. Still not 100% happy with the names in the API for Freeze, but they reasonably consistent with other HALs.

The private functions that implement the separate phases of initialization still have the same names as those in the SDK repos mentioned above. This was to make it easier to do side-by-side comparison to verify that they were functionally identical - this may help with review as well.

You can spin up the PLL independently of using it as the system clock, but if it's enabled it always gets used as the UART clock source. I have tested the UART at a few frequencies while using different system clock frequencies. The CH340 on the Doiting module doesn't work well with all baud rates under Linux, other USB-UARTs/OSes may work better with arbitrary baud rates.

[luojia65]

Look good to me :) Nice work

[9names]

I was going to merge but then I ran into some issues when trying to run from internal flash with this clock init code. Some of it was bugs, but there's a problem I haven't diagnosed when running from flash once the PLL gets disabled (which you need to do to enable it). To work around that, we're now calling the ROM function to do it, since it's safe to keep executing from ROM/RAM. We can now do clock config while running from flash or from RAM! I've left a todo to get back to it later, once we've got more documentation around XIP flash.

[mkroman]

Looking good.. Can't speak for the functionality of the code, as I haven't tested it.

Don't forget to run it through rustfmt before merging, as there's quite a lot of syntax inconsistencies. And please squash and merge, or rebase and merge, when done, to clean up the commit history.

[9names]

will do that shortly, thanks for the reminder

[9names]

Alright, going to merge this now. Thanks for the feedback folks.