applet.memory._25x_passthrough: new applet

[purdeaandrei]

This has now been implement based on two datasheets:

• Winbond W25Q80DVUXIE
• Macronix MX25L6436F

These chips implement incompatible ways to enter XIP mode. Not all the commands have been tested, only the following:

• Non-quad/non-dual commands that go directly to "Wait-Cs-Deassert", and never change the IO directions
• Command 0xEB that reads data over 4 i/o pins, and this has only been tested in XIP mode.
• Going directly back into XIP mode after CS deassert-assert.
• I can get an RP2040 to run through the passthrough, by using the RX_SAMPLE_DLY functionality at up to 77.5MHz SPI clock. Higher speeds are not possible on the RP2040, because RX_SAMPLE_DLY can only be set up to 4, but the applet may be capable of more with other systems.

[whitequark]

After a very brief skim, the impression I get is that this applet isn't really stable or well understood enough to qualify for inclusion in the main branch. I can see quite a lot of "debug-quality" code and code which isn't sure of exactly what it is doing, and given the support commitment of "essentially forever" that's difficult to accept.

[purdeaandrei]

I have extensively tested the applet's capabilities with the combination of a Winbond chip and an RP2040.

I can see quite a lot of "debug-quality" code and code which isn't sure of exactly what it is doing

Could you point some of it out?

I know I have one "TODO" comment, which is basically I need to go searching for more Macronix datasheets, because in the datasheet I found a comment saying that my chip doesn't support command E3. So I need to see what type of command it might be on other Macronix chips, to see if I need to add a switch to tell the applet which one to support.

But the rest of the code I'm fairly confident in, the only thing is missing is testing all of it. I have the ability to do more testing,
but it's going to be a lot of effort because it would involve me developing second stage bootloader variants for RP2040. But if you see issues with code quality I would be happy to improve on it before it's all tested.

I wrote this applet specifically to be useful for others.
If it was just for me, then I wouldn't even need the dynamic direction switching, cause by Kaby Lake motherboard only ever sends non-quad SPI commands, so all the features I have worked to implement are really there to make it usable as a generic tool, especially since you mentioned you wanted to include a pass-through applet.

[whitequark]

The two things that I found concerning were:

• uncertainty in the command set block at the top ("Winbond?" for example, which looks gone now);
• a lot of trial-and-error in the applet description, which to me seemed like it suggested that the applet would work questionably.

If you are confident in it then I will need to take a proper look instead.

[purdeaandrei]

uncertainty in the command set block at the top ("Winbond?" for example, which looks gone now);

Yeah, I left some question marks there that I forgot to remove before, apologies.

a lot of trial-and-error in the applet description, which to me seemed like it suggested that the applet would work questionably.

The Works/Fails: stuff? That's the extensive testing I have done. It gives examples to attempt to describe the limits one might face because of the large turn-around latency introduced by glasgow, and how someone might be able to work around them. Fail doesn't mean that the applet fails but it means that the system cannot handle the latency with those particular settings. Just saying that it supports up to x MHz on the test jig is a bit misleading. Even if you say, you aren't allowed to hack on the pico-sdk which hard-codes an intial system clock frequency of 125MHz, then I could say it does up to 19.25MHz 30MHz, if you set PICO_FLASH_SPI_CLKDIV to 2, and change the system clock frequency to 60MHz. But even that is not going to be fully true, because the default for the w25q080 and boot2_at25sf128a 2'nd stage bootloaders set RX_SAMPLE_DLY to 1, but the others leave it at 0, so for other bootloaders the experience is going to be different (i.e. it will only go to about 15MHz). So only giving the lowest common denominator frequency would look bad, while I got the system to run at 77.5MHz, just by understanding how the settings affect maximum frequency of the system. Maybe I am giving too much information in the description, and I can shorten the list of examples.

Edit: newer SDK doesn't hardcode it anymore
Edit2: fixed frequency

[whitequark]

I think I need to understand the applet better before commenting on it further.

[purdeaandrei]

I found a datasheet of a chip that supports command E3, but this chip is completely different.
I think my initial intent to do a common state-machine, and only tweak differences is going to be misleading and hard to maintain in the future.
I am going to modify the code so that each instance of a state machine only supports one chip type. And I think I'll modify the args to pick a specific chip instead of mentioning which xip mode I'm supporting.

[purdeaandrei]

I have refactored the code, most of the state machine states are now generated based on a chip specification, which should make it a lot more easier to expand it in the future to support more chips.
I have also gotten rid of the pass/fail section, and simplified a lot of the information in it, made it into a list argparse can recognize.