I HATE the idea of 3 pin only, 4 pin with resistor is far more flexible with two more pins following for four bit mode
I know, but I don't like using 4+ pins and leaving a big door open to uncertainty. Keeping the fundamentals simple keeps the tools and documentation simple. Less to deal with in these departments is probably a net gain, overall, as they can be sources of geometric need-to-remind-and-explain. Simple is good.
I think once this thing is all working, there will be so much fun stuff to do, that nobody's going to be wishing we had a more complex pin map to support seldom-desired pin/speed trade-offs. Just my opinion, of course.
I know, but I don't like using 4+ pins and leaving a big door open to uncertainty. Keeping the fundamentals simple keeps the tools and documentation simple. Less to deal with in these departments is probably a net gain, overall, as they can be sources of geometric need-to-remind-and-explain. Simple is good.
100% agreed, which is exactly why the the Mode-exit housekeeping stuff is needed, to keep this simple to the end user.
It will reboot, as expected, no matter what they are doing.
Much Harder to explain, is to limit their choices, and say they cannot use the Chip in the way other vendors allow.
If you are pin-usage focused, and yet also want to keep things standard, (NB: 3 pins is NOT standard) then I'd suggest
Serial Boot (1 & 2 pins)
i2c Boot (2 pins) (<< this saves 1 pin, and allows removal of the non-standard 3P connect)
SPI Boot - 100% standard 4 pin SPI connection, with D-Q-Mode exit 'invisible' housekeeping included.
Forgive me Chip, but 3 pins is non-standard, and basically disallows 2 bit and 4 bit mode, so in my opinion, it is not simpler.
Just because *some* QSPI chip's won't easily reset we should not dump the standard 4 pin SPI.
With 4 pins reserved for SPI, and one resistor, you can have your 3 pin boot mode, and people who want to use two bit mode or four bit mode can switch the flash chips to those modes after the initial boot state.
With four pins reserved for SPI, it is easy to use the next two bits down for QSPI.
It is easy to use other pins for additional chip selects, yet share CLK/MISO/MOSI.
With 3 pins, we *CANNOT* use SPI peripherals that use full duplex transfers.
Frankly, I think you are worrying too much about some edge cases with some flash chips.
If people use 4 bit mode, without using a chip on the "known good" list, it is their problem. Cavet Emptor.
I HATE the idea of 3 pin only, 4 pin with resistor is far more flexible with two more pins following for four bit mode
I know, but I don't like using 4+ pins and leaving a big door open to uncertainty. Keeping the fundamentals simple keeps the tools and documentation simple. Less to deal with in these departments is probably a net gain, overall, as they can be sources of geometric need-to-remind-and-explain. Simple is good.
I think once this thing is all working, there will be so much fun stuff to do, that nobody's going to be wishing we had a more complex pin map to support seldom-desired pin/speed trade-offs. Just my opinion, of course.
Bill, are there any SPI chips that use full-duplex transfers?
And you CAN use other SPI parts by connecting their DI or DO to the shared SPI flash DI/DO, since only when the SPI flash's CSn is low, could that DI/DO signal ever be driven by the flash. It really doesn't have any effect on what other SPI device you'd want to connect to the CLK pin and flash DI/DO pin, as you'd have to give it a unique CSn pin, anyway.
All this three-pin scheme does is lock the boot flash footprint to three fixed pins, dissuading dual and quad usage in the process.
Bill, are there any SPI chips that use full-duplex transfers?
I think Bill was meaning other SPI parts, which users may connect in the standard DI-DO format, and then expect to use standard SPI libraries to connect to, using separate CS.
With a mix of 3P and 4P SPI, you have forced users to further split their software. More explaining...
Bill, are there any SPI chips that use full-duplex transfers?
I think Bill was meaning other SPI parts, which users may connect in the standard DI-DO format, and then expect to use standard SPI libraries to connect to, using separate CS.
With a mix of 3P and 4P SPI, you have forced users to further split their software. More explaining...
Use other pins, maybe?
Three dedicated pins assure a solid boot using any SPI flash with any Prop2 variant.
Three dedicated pins assure a solid boot using any SPI flash with any Prop2 variant.
- but that claim is proven incorrect ?
Users will expect to share those pins, and they will expect to use Quad modes & will design that way.
If you really want to support future, smaller P2s in this one's ROM, then include i2c boot, which is LESS than 3 pins.
( & I'd also suggest One-pin serial, to really prune that pin-cost on smaller P2's )
I still think this scheme can work with QPI as long as %11 is outputted before boot to exit quad mode...
Agreed, the 8,16,2 clock simple preambles given in #1, should give a very wide range of usable FLASH parts, with (re) boot possible.
Very simple to prove on a board, if the code is included in the next build.
Chip,
The others are right, forcing 3pin doesn't really provide the protection you are thinking, and it does block sharing the SPI pins with other devices (a very common thing).
Does it really block sharing SPI pins for other devices?
If you wanted to hook up another SPI device, couldn't you just provide one extra pin for DO and one extra pin for CS? In that case, don't you wind up using the same # of total pins?
If there really is going to be a 16-pin I/O P2, it might be good to be as conservative as possible with I/O pins. 5 out of 16 for boot is already a lot, but less than a third...
Ray, I guess you are right, but you need different code to access the flash (connected via 3pin) verses the other device (hooked up via 4pin) on the same pins (except cs).
I think worrying about smaller P2 devices, that may never materialize, in this one's ROM is a bad plan. The ROM can change for those possibly maybe devices in the future.
I really wish SPI flash commands/protocols were more rigidly defined so this would not be a problem.
I'm not really seeing any significant problem here ?
There are hundreds of possible FLASH parts that can be used, and all P2 needs, is a decent subset of those.
I started with the cheapest and recent, and it certainly works with those.
It does not have to work with all corner/fringe cases, just like NXP have chosen to target the main-sweet spot.
If there really is going to be a 16-pin I/O P2, it might be good to be as conservative as possible with I/O pins. 5 out of 16 for boot is already a lot, but less than a third...
Any 16 i/o P2, is a serious candidate for One-Pin serial, or i2c boot.
I don't understand all these "scare issues" that are being pushed long and hard. There's no need for any of us to clutter and obscure the thread with our opinions as if we should talk down every other opinion. The P2 family will be used in a very wide variety of applications and to force pin usage based on what some may have us believe to be necessary and proper is not the way to go. I like to see the minimum number of dedicated pins and if I want to do something fancy with QSPI then it is quite probable that this would not be a minimal system with one CPU and one memory anyway and I don't mind having a separate chip just for that then.
Also for the sake of ensuring that the Prop tool can program the memory it might mean that we specify certain brands or chips for this to work correctly.
I also still like (but not require) the idea of I2C EEPROM being supported as there is no problem writing to these devices plus they provide a convenient non-volatile memory that can be written to as single bytes if necessary.
@cgracey - I will get onto this SD boot along with testing various cards etc. I think too that I can issue a command for the card to use a different block size as well or even use multi-block reads and this may speed things up a lot as normally waiting for a data read token can take just as long as it takes to read a block anyway. Throughput is more important than raw speed. I also agree with Cluso99 in regards to not being tied to any format in particular for many reasons but not forgetting that FAT32 is just not all that Flash friendly anyway and 24/7 embedded systems hammering away second by second may have a more custom format, perhaps even embedded in a large FAT32 file, but not limited by it.
The problem is that you have to do a bunch of different things in an attempt to handle possible state of the different flash chips. For example, if it was required that all chips to a reset from receiving a $ff command on 1bit SPI mode (no matter what mode they are in), then we'd be done already.
Instead we have to have a series of sending and checking to handle various cases, and have a limited set of compatible parts instead of just working with any of them.
The problem is that you have to do a bunch of different things in an attempt to handle possible state of the different flash chips. For example, if it was required that all chips to a reset from receiving a $ff command on 1bit SPI mode (no matter what mode they are in), then we'd be done already.
Instead we have to have a series of sending and checking to handle various cases, and have a limited set of compatible parts instead of just working with any of them.
Three-pin hookup strongly discourages any dual-mode or quad-mode use. Yes, someone could give it a command to go into XIP mode that spits out nibbles, but with the DI=DO wiring scheme, it would be severely compromised. How low-Z would your DI-to-DO resistor need to be, given the high-speed AC signalling needing to get through? The docs would explain why this decision was made, too, not hiding anything, but giving the rationale for why it is only 3 pins, and always the same three pins.
I think we get so hung up thinking about what is possible, that practicality gets downgraded. A 17-cent 512KB chip can be the boot device on three pins. The Prop2 is probably going to cost $8.00. As the one who makes the chip and tools, and must deal with customer tech issues, I'd like to have the basic framework be simple and consistent, before users introduce complexities of their own.
I don't understand all these "scare issues" that are being pushed long and hard. There's no need for any of us to clutter and obscure the thread with our opinions as if we should talk down every other opinion. The P2 family will be used in a very wide variety of applications and to force pin usage based on what some may have us believe to be necessary and proper is not the way to go. I like to see the minimum number of dedicated pins and if I want to do something fancy with QSPI then it is quite probable that this would not be a minimal system with one CPU and one memory anyway and I don't mind having a separate chip just for that then.
Also for the sake of ensuring that the Prop tool can program the memory it might mean that we specify certain brands or chips for this to work correctly.
I also still like (but not require) the idea of I2C EEPROM being supported as there is no problem writing to these devices plus they provide a convenient non-volatile memory that can be written to as single bytes if necessary.
@cgracey - I will get onto this SD boot along with testing various cards etc. I think too that I can issue a command for the card to use a different block size as well or even use multi-block reads and this may speed things up a lot as normally waiting for a data read token can take just as long as it takes to read a block anyway. Throughput is more important than raw speed. I also agree with Cluso99 in regards to not being tied to any format in particular for many reasons but not forgetting that FAT32 is just not all that Flash friendly anyway and 24/7 embedded systems hammering away second by second may have a more custom format, perhaps even embedded in a large FAT32 file, but not limited by it.
If you guys can come up with an SD booting scheme that is simple and works, we can put it into the ROM. Booting from SD would be fantastic.
The problem is that you have to do a bunch of different things in an attempt to handle possible state of the different flash chips. For example, if it was required that all chips to a reset from receiving a $ff command on 1bit SPI mode (no matter what mode they are in), then we'd be done already.
Instead we have to have a series of sending and checking to handle various cases, and have a limited set of compatible parts instead of just working with any of them.
Three-pin hookup strongly discourages any dual-mode or quad-mode use. Yes, someone could give it a command to go into XIP mode that spits out nibbles, but with the DI=DO wiring scheme, it would be severely compromised. How low-Z would your DI-to-DO resistor need to be, given the high-speed AC signalling needing to get through? The docs would explain why this decision was made, too, not hiding anything, but giving the rationale for why it is only 3 pins, and always the same three pins.
I think we get so hung up thinking about what is possible, that practicality gets downgraded. A 17-cent 512KB chip can be the boot device on three pins. The Prop2 is probably going to cost $8.00. As the one who makes the chip and tools, and must deal with customer tech issues, I'd like to have the basic framework be simple and consistent, before users introduce complexities of their own.
The problem is that you have to do a bunch of different things in an attempt to handle possible state of the different flash chips. For example, if it was required that all chips to a reset from receiving a $ff command on 1bit SPI mode (no matter what mode they are in), then we'd be done already.
Instead we have to have a series of sending and checking to handle various cases, and have a limited set of compatible parts instead of just working with any of them.
I believe I already covered that.
The majority of parts will respond to a simple preamble set, if the niche ones do not - so what ?
NXP has decided users are happy with a significant majority, P2 should use the same simple pragmatism.
There is little point lamenting the real world, "Engineering is the art of making what you want, from what you can get"
I also still like (but not require) the idea of I2C EEPROM being supported as there is no problem writing to these devices plus they provide a convenient non-volatile memory that can be written to as single bytes if necessary.
Agreed, i2c has many appeals
* It is a common standard, and likely users will have other i2c devices
* It satisfies Chip's desire for minimal pin solutions, and should allow the 3-Pin non-std option to be retired, as the main appeal of that was low pin count.
* i2c Parts come in small packages, but large enough to contain USB or RF or other secondary boot firmware.
I also still like (but not require) the idea of I2C EEPROM being supported as there is no problem writing to these devices plus they provide a convenient non-volatile memory that can be written to as single bytes if necessary.
Agreed, i2c has many appeals
* It is a common standard, and likely users will have other i2c devices
* It satisfies Chip's desire for minimal pin solutions, and should allow the 3-Pin non-std option to be retired, as the main appeal of that was low pin count.
* i2c Parts come in small packages, but large enough to contain USB or RF or other secondary boot firmware.
Remember, though, that they are slow. at 400KHz, you're only able to read 50KB/second. With SPI flash we can read 10MB/second. That's 200x faster! I see that new I2C parts can go to 1MHz, so they are only 80x slower than SPI.
I see you can get a 64KB I2C EEPROM from Digikey for 71 cents, qty 1. It would take half a second to read in those 512k bits at 1MHz. Maybe I2C could be a boot option, where no pull-up on pin 61 (SCL), but a pull-up on pin 60 (SDA) could signal I2C present. That would not conflict with the SPI flash boot check.
Maybe I2C could be a boot option, where no pull-up on pin 61 (SCL), but a pull-up on pin 60 (SDA) could signal I2C present. That would not conflict with the SPI flash boot check.
Remember, though, that they are slow. at 400KHz, you're only able to read 50KB/second. With SPI flash we can read 10MB/second. That's 200x faster! I see that new I2C parts can go to 1MHz, so they are only 80x slower than SPI.
I see you can get a 64KB I2C EEPROM from Digikey for 71 cents, qty 1. It would take half a second to read in those 512k bits at
1MHz.
Of course, i2c is never going to displace SPI for large-memory loads, i2c comes second on both speed and price per bit.
i2c wins on Pin Count, simple packages like SOT23-5, and faster erase times.
The appeal is for storing enough P2 code, to load over something that is not in ROM-code - that may be USB, or RF, or some of the new byte-wide serial memories...
So while I2C is slow it is perhaps the only boot method which is sure and certain. In my current designs I include I2C pins on the serial programming header as one of the uses for this is to directly load the EEPROM from a handheld programmer. Of course SPI could be loaded but I2C boot is a no-brainer and the boot rom will always know how to program them too. With 3-pin SPI though I don't need to change my connector either as I normally have a spare pin.
For many applications you won't need to read in 512k code/data into ram from the boot eeprom or flash. Often reading in just 32k or 64k is enough, and you'll use the rest of ram as buffers or whatnot.
I2C support seems like it would be a tiny amount of ROM space, and give more options to designers.
I've been doing quite a bit with SPI in RPi land, and all the chips assume a separate DI and DO.
Most of the C & Python drivers assume separate MISO & MOSI and use the smbus libraries xfer2 routine, which send & receive at the same time.
While it may be possible to use common chips like the MCP3008, MCP3208, MCP27S08, MCP27S17 with a combined DI & DO, I think that the likelyhood of being able to use random SPI parts with a combined DIDO is not great, thus in attempting to prevent using Bi/Quad SPI by enforcing three pin you may be causing issues with far more chips.
The fact is, the SPI standard is /CS, CLK, MOSI, MISO ... not /CS, CLK, MOISIO, thus switching to three pins is asking for trouble.
With a standard four pin interface you can add other devices at one /CS per device, or three pins for eight devices... versus having to add a second SPI "port" of four pins, for saving one pin on the boot flash.
I think going away from the standard four pin SPI is a very bad idea, that will bite us on the Smile.
Frankly, I'd rather have two serial pins, and a two pin I2C boot eeprom, than a three pin SPI as at least that would still be I2C standard.
Bill, are there any SPI chips that use full-duplex transfers?
And you CAN use other SPI parts by connecting their DI or DO to the shared SPI flash DI/DO, since only when the SPI flash's CSn is low, could that DI/DO signal ever be driven by the flash. It really doesn't have any effect on what other SPI device you'd want to connect to the CLK pin and flash DI/DO pin, as you'd have to give it a unique CSn pin, anyway.
All this three-pin scheme does is lock the boot flash footprint to three fixed pins, dissuading dual and quad usage in the process.
It may be a tough call between 3-pin and 4-pin SPI.
With what Chip just said about 3-pin not being compatible with 4-bit mode, I guess I'm in the 4-pin SPI camp now too.
Advantages:
1. Can reuse DI/DO/CLK for other SPI devices and share the bus. Just need one CS pin for each new device.
2. Standard way of doing this, doesn't look like a hack. More compatible, less explaining.
3. Allows for 4-bit flash as long as ROM pushes out $FF on DI/DO before boot.
4. Can think about there being an SD card there instead of flash and boot from same interface.
Also, I think with DI&DO tied together there is a theoretical chance that bad code could lead to pin contention, possibly damaging flash chip, right?
If you made a SPI bus from the existing CLK pin and flash DI/DO pin, using the flash DI/DO pin as the DI and the next pin down as the DO, how is this going to be problematic? Only if the SPI flash's CSn pin is low, could the DI pin possibly be driven. I guess that would just mean that you wouldn't use some standard SPI library to deal with the flash, right?
Also, there's 4x potential electrical contention using quad modes.
Comments
I know, but I don't like using 4+ pins and leaving a big door open to uncertainty. Keeping the fundamentals simple keeps the tools and documentation simple. Less to deal with in these departments is probably a net gain, overall, as they can be sources of geometric need-to-remind-and-explain. Simple is good.
I think once this thing is all working, there will be so much fun stuff to do, that nobody's going to be wishing we had a more complex pin map to support seldom-desired pin/speed trade-offs. Just my opinion, of course.
100% agreed, which is exactly why the the Mode-exit housekeeping stuff is needed, to keep this simple to the end user.
It will reboot, as expected, no matter what they are doing.
Much Harder to explain, is to limit their choices, and say they cannot use the Chip in the way other vendors allow.
If you are pin-usage focused, and yet also want to keep things standard, (NB: 3 pins is NOT standard) then I'd suggest
Serial Boot (1 & 2 pins)
i2c Boot (2 pins) (<< this saves 1 pin, and allows removal of the non-standard 3P connect)
SPI Boot - 100% standard 4 pin SPI connection, with D-Q-Mode exit 'invisible' housekeeping included.
Just because *some* QSPI chip's won't easily reset we should not dump the standard 4 pin SPI.
With 4 pins reserved for SPI, and one resistor, you can have your 3 pin boot mode, and people who want to use two bit mode or four bit mode can switch the flash chips to those modes after the initial boot state.
With four pins reserved for SPI, it is easy to use the next two bits down for QSPI.
It is easy to use other pins for additional chip selects, yet share CLK/MISO/MOSI.
With 3 pins, we *CANNOT* use SPI peripherals that use full duplex transfers.
Frankly, I think you are worrying too much about some edge cases with some flash chips.
If people use 4 bit mode, without using a chip on the "known good" list, it is their problem. Cavet Emptor.
And you CAN use other SPI parts by connecting their DI or DO to the shared SPI flash DI/DO, since only when the SPI flash's CSn is low, could that DI/DO signal ever be driven by the flash. It really doesn't have any effect on what other SPI device you'd want to connect to the CLK pin and flash DI/DO pin, as you'd have to give it a unique CSn pin, anyway.
All this three-pin scheme does is lock the boot flash footprint to three fixed pins, dissuading dual and quad usage in the process.
Problem is, it fails to even do that....
I think Bill was meaning other SPI parts, which users may connect in the standard DI-DO format, and then expect to use standard SPI libraries to connect to, using separate CS.
With a mix of 3P and 4P SPI, you have forced users to further split their software. More explaining...
Use other pins, maybe?
Three dedicated pins assure a solid boot using any SPI flash with any Prop2 variant.
Users will expect to share those pins, and they will expect to use Quad modes & will design that way.
If you really want to support future, smaller P2s in this one's ROM, then include i2c boot, which is LESS than 3 pins.
( & I'd also suggest One-pin serial, to really prune that pin-cost on smaller P2's )
Very simple to prove on a board, if the code is included in the next build.
The others are right, forcing 3pin doesn't really provide the protection you are thinking, and it does block sharing the SPI pins with other devices (a very common thing).
If you wanted to hook up another SPI device, couldn't you just provide one extra pin for DO and one extra pin for CS? In that case, don't you wind up using the same # of total pins?
If there really is going to be a 16-pin I/O P2, it might be good to be as conservative as possible with I/O pins. 5 out of 16 for boot is already a lot, but less than a third...
I think worrying about smaller P2 devices, that may never materialize, in this one's ROM is a bad plan. The ROM can change for those possibly maybe devices in the future.
I'm not really seeing any significant problem here ?
There are hundreds of possible FLASH parts that can be used, and all P2 needs, is a decent subset of those.
I started with the cheapest and recent, and it certainly works with those.
It does not have to work with all corner/fringe cases, just like NXP have chosen to target the main-sweet spot.
Any 16 i/o P2, is a serious candidate for One-Pin serial, or i2c boot.
Also for the sake of ensuring that the Prop tool can program the memory it might mean that we specify certain brands or chips for this to work correctly.
I also still like (but not require) the idea of I2C EEPROM being supported as there is no problem writing to these devices plus they provide a convenient non-volatile memory that can be written to as single bytes if necessary.
@cgracey - I will get onto this SD boot along with testing various cards etc. I think too that I can issue a command for the card to use a different block size as well or even use multi-block reads and this may speed things up a lot as normally waiting for a data read token can take just as long as it takes to read a block anyway. Throughput is more important than raw speed. I also agree with Cluso99 in regards to not being tied to any format in particular for many reasons but not forgetting that FAT32 is just not all that Flash friendly anyway and 24/7 embedded systems hammering away second by second may have a more custom format, perhaps even embedded in a large FAT32 file, but not limited by it.
The problem is that you have to do a bunch of different things in an attempt to handle possible state of the different flash chips. For example, if it was required that all chips to a reset from receiving a $ff command on 1bit SPI mode (no matter what mode they are in), then we'd be done already.
Instead we have to have a series of sending and checking to handle various cases, and have a limited set of compatible parts instead of just working with any of them.
Three-pin hookup strongly discourages any dual-mode or quad-mode use. Yes, someone could give it a command to go into XIP mode that spits out nibbles, but with the DI=DO wiring scheme, it would be severely compromised. How low-Z would your DI-to-DO resistor need to be, given the high-speed AC signalling needing to get through? The docs would explain why this decision was made, too, not hiding anything, but giving the rationale for why it is only 3 pins, and always the same three pins.
I think we get so hung up thinking about what is possible, that practicality gets downgraded. A 17-cent 512KB chip can be the boot device on three pins. The Prop2 is probably going to cost $8.00. As the one who makes the chip and tools, and must deal with customer tech issues, I'd like to have the basic framework be simple and consistent, before users introduce complexities of their own.
That said, I might change my mind.
If you guys can come up with an SD booting scheme that is simple and works, we can put it into the ROM. Booting from SD would be fantastic.
The majority of parts will respond to a simple preamble set, if the niche ones do not - so what ?
NXP has decided users are happy with a significant majority, P2 should use the same simple pragmatism.
There is little point lamenting the real world, "Engineering is the art of making what you want, from what you can get"
Agreed, i2c has many appeals
* It is a common standard, and likely users will have other i2c devices
* It satisfies Chip's desire for minimal pin solutions, and should allow the 3-Pin non-std option to be retired, as the main appeal of that was low pin count.
* i2c Parts come in small packages, but large enough to contain USB or RF or other secondary boot firmware.
Remember, though, that they are slow. at 400KHz, you're only able to read 50KB/second. With SPI flash we can read 10MB/second. That's 200x faster! I see that new I2C parts can go to 1MHz, so they are only 80x slower than SPI.
I see you can get a 64KB I2C EEPROM from Digikey for 71 cents, qty 1. It would take half a second to read in those 512k bits at 1MHz. Maybe I2C could be a boot option, where no pull-up on pin 61 (SCL), but a pull-up on pin 60 (SDA) could signal I2C present. That would not conflict with the SPI flash boot check.
Yes, something like that makes good sense.
Of course, i2c is never going to displace SPI for large-memory loads, i2c comes second on both speed and price per bit.
i2c wins on Pin Count, simple packages like SOT23-5, and faster erase times.
The appeal is for storing enough P2 code, to load over something that is not in ROM-code - that may be USB, or RF, or some of the new byte-wide serial memories...
I2C support seems like it would be a tiny amount of ROM space, and give more options to designers.
I've been doing quite a bit with SPI in RPi land, and all the chips assume a separate DI and DO.
Most of the C & Python drivers assume separate MISO & MOSI and use the smbus libraries xfer2 routine, which send & receive at the same time.
While it may be possible to use common chips like the MCP3008, MCP3208, MCP27S08, MCP27S17 with a combined DI & DO, I think that the likelyhood of being able to use random SPI parts with a combined DIDO is not great, thus in attempting to prevent using Bi/Quad SPI by enforcing three pin you may be causing issues with far more chips.
The fact is, the SPI standard is /CS, CLK, MOSI, MISO ... not /CS, CLK, MOISIO, thus switching to three pins is asking for trouble.
With a standard four pin interface you can add other devices at one /CS per device, or three pins for eight devices... versus having to add a second SPI "port" of four pins, for saving one pin on the boot flash.
I think going away from the standard four pin SPI is a very bad idea, that will bite us on the Smile.
Frankly, I'd rather have two serial pins, and a two pin I2C boot eeprom, than a three pin SPI as at least that would still be I2C standard.
With what Chip just said about 3-pin not being compatible with 4-bit mode, I guess I'm in the 4-pin SPI camp now too.
Advantages:
1. Can reuse DI/DO/CLK for other SPI devices and share the bus. Just need one CS pin for each new device.
2. Standard way of doing this, doesn't look like a hack. More compatible, less explaining.
3. Allows for 4-bit flash as long as ROM pushes out $FF on DI/DO before boot.
4. Can think about there being an SD card there instead of flash and boot from same interface.
Also, I think with DI&DO tied together there is a theoretical chance that bad code could lead to pin contention, possibly damaging flash chip, right?
Also, there's 4x potential electrical contention using quad modes.