Skip to content

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

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
XZCE opened this issue Feb 17, 2025 · 4 comments
Milestone

Comments

@XZCE
Copy link

XZCE commented Feb 17, 2025

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.

@kilograham kilograham added this to the 2.2.0 milestone Feb 17, 2025
@XZCE
Copy link
Author

XZCE commented Feb 19, 2025

@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?

@Gadgetoid
Copy link
Contributor

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: #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.

@XZCE
Copy link
Author

XZCE commented Mar 5, 2025

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
Copy link
Author

XZCE commented Apr 2, 2025

@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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants