Wishlist

[APrettyButterfly]

Hi,

I just came across your project since I was looking for some kind of SPI emulator or $something to plug in to my mainboard for booting from external flash.
Problem is : I suck at soldering (so do probably others ...) and even if I didn't there is always some risk involved when doing that on some "production" mainboard.

However, some boards have a SPI header where you can connect an external SPI chip. There have been also some tools for attaching things to those like http://shop3.nanobios.cafe24.com/article/Manual/3/24/ or https://www.pcengines.ch/spi1a.htm . The latter one is not really universal while the former looks like it is not available anymore.
Do you see any possibility to kind of merge those with the current hardware of qspimux?

From using a well known search engine I could already find some people making use of qspimux and you seem to also want to sell some of those/setup a crowdfunding campaing.
I think this project would be very interesting for all those Bios modders. There are also more and more talks/presentations for Bios/Firmware security. qspimux would make it much easier to do analysis and gain visibility on layers where the OS can't reliably look into. There have been holes in SecureBoot and just recently TPMs. The only real way to lock down the Bios is just to write protect it after the initial setup. With some kind of external chip this would also be much easier. Early mainboards had a jumper for write protection. So maybe you could add one too ?
For those boards which don't have such kind of external header maybe some SOIC clip could be added, but I'm not sure if this would work in general for attaching to the current SPI and booting from the external chip. Some board also have a socketed chip. Maybe there could also be some kind of qspimux hardware module for those ?

I'm not a hardware guy, more like the average end user so I don't know if there is a feasible/economical solution for all of those items on my wishlist. But (in my biased opinion :D ) I think for a crowd-funding campaign broadening the potential applications and making it easier for the end user to use your device , is not a bad thing.

[felixheld]

Hi!

Yeah, the soldering part does have a certain risk of damaging the board; especially when you don't have suitable soldering equipment. With a hot air rework station it's much easier to remove the flash from the board and less likely to rip off some traces from the board.

Using the special connectors on a board should work, but problem is that probably every vendor or at least every OEM having such a connector in their mainboard design will likely have a different pinout and maybe even a different connector type. Making adapters that only work for certain boards shouldn't be too difficult though.

The write protect pin isn't available when the flash is in quad SPI mode; adding a jumper would break the quad mode. Also in order for the write protect pin to have an effect some flashes need to have some protected range registers written by the firmware. Having a flash adapter with a jumper to either connect the #WP pin of the flash to the trace from the board or to ground might be useful. Oh and on modern platforms you can't write-protect the whole flash anyway without breaking functionality, since for example suspend to RAM won't work when the memory controller settings can't be written to some part of the flash.

Using a SOIC clip to connect to the on board flash only works in the case that the board doesn't use the quad SPI mode and doesn't connect the #HOLD pin directly to the flash's power supply, since you have to pull that pin to ground to disable the on-board flash. Directly connecting that pin externally to ground might damage the target board when the pin is directly connected to the supply voltage on the board. If just some pull-up resistor is used, this should be safe, but this is something that has to be verified before connecting a clip to the on-board flash in order to not fry the board and I doubt that everyone will always do that :/ So I'm not sure if it would be a good idea to offer adapter boards for that; documenting the possibility and the conditions for that is probably a good idea though.

I have a board adapter to plug into DIP8 sockets; that adapter needs some rework though, since it uses normal pin headers that don't fit well into the sockets. Looked into that a few days ago but IIRC the connector I thought about using wasn't in stock.

I'm not sure yet if doing a crowdfunding or getting some company to make and sell qspimux2 boards and the adapters would be the better idea. I primarily want the boards to be available, but didn't really get around to figure out how to do that without having to invest too much time or money. The two main things that aren't easy to have manufactured yourself are the SOIC board adapters (need non-standard manufacturing steps for the contacts on the sides) and the qspimux2 itself (small components that can't be easily soldered without stencil, solder paste and hot air or a soldering oven).

But yeah, the project is currently mostly solving the automatic reflashing without interfering with the board problem I had. I'm not sure if there will be a significant improvement in user-friendliness over the current state, since most possible improvements I thought of are either very specific to some boards or use cases or don't work for some use cases I have.

Hope that helps; if you have any more questions or suggestions, just ask :)

I wanted to write some more documentation and also explain some design decisions, but didn't really get around to do that yet.

[APrettyButterfly]

Thanks for the elaborate reply :)
Yeah from the first link you can already see that you require different pinouts for different vendors.
Regarding the WP pin, sure you would loose some functionality as in most cases where you increase the security. I can only speak for myself but I guess suspend to RAM is mostly used for notebooks and not your average desktop or server system. Or is there anything else which would break?

[felixheld]

Just had a look in the datasheet of the W25Q64FV spi flash (if you're interested in that topic, I'd suggest to read the corresponding sections) and there the #WP pin will only get used for write protection when a certain bit in the status register is set. And then it'll only protect the status register containing some write protection and security register lock bits. So the flash chip needs to be configured first to do what you expect when you pull the #WP pin low; the "write protect" name might be a bit misleading here, since it doesn't causes all flash writes to be ignored without further configuration. The same functionality can also be done from firmware, but needs to be reapplied after the flash lost power. IIRC some platforms did that, but forgot to send the lock command after a suspend-resume cycle...
If you write-protect the whole chip, apart from suspend to RAM I'd expect that some of the embedded microprocessors in the platform might get unhappy when they can't write to their parts of the flash chip. Haven't tried fully write-protecting a flash to see what breaks, but at least on some older Intel platform I looked at the management engine writes to a part of the flash. But yeah, write-protecting things some part of the firmware expects to be writable might break things in possibly non-obvious ways. I don't want to discourage you trying that, but you should be aware that you might hit bugs, features and undefined behavior there ;)