Check if XIP configuration works.

[rewolff]

When starting to design RP2040 boards I decided I didn't want to mess with second stage bootloaders to get the configuration for other XIP flash chips right, so I'm stuck with using W25Q chips from winbond.

Now we've had a batch of boards made and the vendor substituted a "should work" chip from a different vendor that simply doesn't work.

I've studied the datasheets and the other chip is slower than the winbond. I'm guessing you're not configuring the winbond in a slower mode than what's available. so that explains the problem. :-)

Anyway, this results in the second stage being loaded to RAM, executed, configuring the chip "too fast" and thus "garbage data" being used as instructions, resulting in a crash.

I'm guessing it wouldn't be too hard to simply checksum the running second stage bootsector through the XIP configuration before passing control. This would allow the second stage bootloader to detect this situation and handle it more cleanly.

I think the only option would be to jump back to the USB bootloader. and.... that might not be the best solution: in that case I'd program the chip, see the drive disappear... and reappear. A picotool readout of the flash chip would show: "perfect upload of the binary" and leave users puzzled as to what's wrong.

An ideal solution would somehow be able to get a message to the user. e.g. change the name from "Raspberry pi PICO" to "PICO, XIP NOT working!"

[jannic]

Something like that would indeed be interesting, and a simple checksum wouldn't be difficult to implement - if there was space available for some more code. However, the 2nd stage boot loader must fit in 256 bytes, and for some of the supported flash chips, this space is pretty much used up.