pico-sdk icon indicating copy to clipboard operation
pico-sdk copied to clipboard

Pico program/firmware initialisation uses XIP (crt0.S data_cpy) even though the ROM routines have a much faster flash_read_data() function available.

Open XZCE opened this issue 9 months ago • 4 comments

We are seeing ~4ms per 1KB loaded in a copy to RAM firmware (XIP is doing quite a lot of work sending sequential addresses to the flash chip) which is making start-up time very slow as more code is added to the program. I'm not willing to make this SDK change myself, sorry, it's not my project that's having startup/timing issues, but I'm hoping the Pi guys see merit in a small upgrade to the SDK here?

Even with a no copy-to-RAM program, I can see the crt0.S program is still setting up all the "not in flash" stuff via the slow setup method, so I think this would benefit a lot of users.

XZCE avatar Feb 17 '25 08:02 XZCE

@kilograham Thanks for adding it in to the 2.2.0 release.

I've tested "something" like what I suggested (calling B2 ROM functions directly for flash_put_cmd_addr and flash_put_get at their known locations) but it's more than twice as slow... Single bit transfers, I guess, in this mode.

Then I changed "rosc_hw->div = 0xAA0 + 4;" and the standard code is now twice as fast at loading flash into RAM at the crt0.S early initialisation stage.

I think it would be better to set up the default clock (125MHz/150MHz) before doing anything more... XIP may actually be OK. For your consideration - maybe for an earlier release?

XZCE avatar Feb 19 '25 08:02 XZCE

I think it would be better to set up the default clock (125MHz/150MHz) before doing anything more

Waaay back when I was optimising MicroPython startup times for low power e-ink usage we did something similar to this. It gets mentioned here: https://github.com/raspberrypi/pico-sdk/issues/959

So, yes, agreed, I've been wanting something like this forever. Though with care to set up the user configured clock if it happens to be <> the default.

Gadgetoid avatar Feb 25 '25 15:02 Gadgetoid

I would have easily settled for a .weak external (pre-initialisation) function that I could use to do whatever I feel is necessary early on... Rather than being locked into the nominal 6.5MHz (RP2040) or 11MHz (RP2350) start-up speed for "everything" before main()...

Image

But, the Pico Arduino repo (which I use to make things easy for others) has rejected the latest SDK release - so my months long wait for important fixes I needed will be months more now - so, I'm afraid I'm out. My one RP2040 project is now finished and I've moved on to other more interesting (for me) things.

@Gadgetoid - I'm sorry things took so long for you too, I hope you get what you need.

XZCE avatar Mar 05 '25 11:03 XZCE

@kilograham thanks for getting that sorted quickly in Arduino land.

FYI: This got me 20ms more on the RP2040, I hope you get a laugh out of it:

Image

XZCE avatar Apr 02 '25 08:04 XZCE