I know it is maybe BAD idea
BUT why not use CUSTOM fuses to have them decide what type and PINS of device them will use as BOOT.
And have only Serial as default in not preprogrammed Propeller II !!
Here is an off-the-wall boot question. Could I use one of those cheap AVR-USB chips in place of an FTDI chip and have it act as the serial interface to the P2? The idea would be to then hook some of the AVR pins to the SPI boot pins on the P2 and use the AVR flash as the boot device. The AVR could emulate a SPI flash. That way you wouldn't need the SPI flash boot chip at all if you were going to have a USB2serial interface. Actually, I guess the same thing could be done with P1 but having the AVR emulate an I2C EEPROM.
I know it is maybe BAD idea
BUT why not use CUSTOM fuses to have them decide what type and PINS of device them will use as BOOT.
No, that is a very good idea, provided the fuses are proven enough.
It should default to on, and a zapped fuse disables that load option, with all zapped (doofus!) perhaps giving SPI ?
(or, a back to the default ? gives more oops useful silicon, but does allow hacking/tamper attacks..)
I can see some users would want hacking/tamper protection @ loader, and Serial-load-first has delays and risks...
Also those who worry about pins-waggling unexpectedly can manage that via the fuses.
Here is an off-the-wall boot question. Could I use one of those cheap AVR-USB chips in place of an FTDI chip and have it act as the serial interface to the P2?
Emulating a SPI slave in a AVR is non-trivial - there is no 'wait' handshake, and the Prop will not know the AVR is waiting on Windows...
...why do you want to reverse the order of d0-d3? I know its only one REV instruction, but why is it needed?
Because it limits pin creep going downwards. If you have a single-bit SPI flash, a Quad SPI flash, or even two Quad SPI flash chips, they can all boot the same by only using pins 87 (din) and pins 86 (dout) for the data paths in single-bit mode.
I know it is maybe BAD idea
BUT why not use CUSTOM fuses to have them decide what type and PINS of device them will use as BOOT.
And have only Serial as default in not preprogrammed Propeller II !!
I'm kind of glad to be getting away from I2C chips, as they are not only slow, but take a ton of code to talk to. Here's from the Prop I loader:
'**************************************
'* I2C routines for 24x256/512 EEPROM *
'* assumes fastest RC timing - 20MHz *
'* SCL low time = 8 inst, >1.6us *
'* SCL high time = 4 inst, >0.8us *
'* SCL period = 12 inst, >2.4us *
'**************************************
'
'
' Begin eeprom read
'
ee_read mov address,#0 'reset address
call #ee_write 'begin write (sets address)
mov eedata,#$A1 'send read command
call #ee_start
if_c jmp #shutdown 'if no ack, shutdown
mov count,h8000 'set count to $8000
ee_read_ret ret
'
'
' Begin eeprom write
'
ee_write call #ee_wait 'wait for ack and begin write
mov eedata,address 'send high address
shr eedata,#8
call #ee_transmit
if_c jmp #shutdown 'if no ack, shutdown
mov eedata,address 'send low address
call #ee_transmit
if_c jmp #shutdown 'if no ack, shutdown
ee_write_ret ret
'
'
' Wait for eeprom ack
'
ee_wait mov count,#400 ' 400 attempts > 10ms @20MHz
:loop mov eedata,#$A0 '1 send write command
call #ee_start '132+
if_c djnz count,#:loop '1 if no ack, loop until done
if_c jmp #shutdown ' if no ack, shutdown
ee_wait_ret ret
'
'
' Start + transmit
'
ee_start mov bits,#9 '1 ready 9 start attempts
:loop andn pina,mask_scl '1(!) ready scl low
or dira,mask_scl '1! scl low
nop '1
andn dira,mask_sda '1! sda float
call #delay5 '5
or pina,mask_scl '1! scl high
nop '1
test mask_sda,pina wc 'h?h sample sda
if_nc djnz bits,#:loop '1,2 if sda not high, loop until done
if_nc jmp #shutdown '1 if sda still not high, shutdown
or dira,mask_sda '1! sda low
'
'
' Transmit/receive
'
ee_transmit shl eedata,#1 '1 ready to transmit byte and receive ack
or eedata,#%00000000_1 '1
jmp #ee_tr '1
ee_receive mov eedata,#%11111111_0 '1 ready to receive byte and transmit ack
ee_tr mov bits,#9 '1 transmit/receive byte and ack
:loop test eedata,#$100 wz '1 get next sda output state
andn pina,mask_scl '1! scl low
rcl eedata,#1 '1 shift in prior sda input state
muxz dira,mask_sda '1! sda low/float
call #delay4 '4
test mask_sda,pina wc 'h?h sample sda
or pina,mask_scl '1! scl high
nop '1
djnz bits,#:loop '1,2 if another bit, loop
and eedata,#$FF '1 isolate byte received
ee_receive_ret
ee_transmit_ret
ee_start_ret ret '1 nc=ack
'
'
' Stop
'
ee_stop mov bits,#9 '1 ready 9 stop attempts
:loop andn pina,mask_scl '1! scl low
nop '1
or dira,mask_sda '1! sda low
call #delay5 '5
or pina,mask_scl '1! scl high
call #delay3 '3
andn dira,mask_sda '1! sda float
call #delay4 '4
test mask_sda,pina wc 'h?h sample sda
if_nc djnz bits,#:loop '1,2 if sda not high, loop until done
ee_jmp if_nc jmp #shutdown '1 if sda still not high, shutdown
ee_stop_ret ret '1
'
'
' Cycle delays
'
delay5 nop '1
delay4 nop '1
delay3 nop '1
delay2
delay2_ret
delay3_ret
delay4_ret
delay5_ret ret '1
Compare that to the SPI code in the loader I posted a few pages back. Where we once had mere calls to these I2C routines, we now have minor bit twiddling to do the whole task.
In that case WHY not stay with small I2C reboot device --- Give only Factory dedicated 4 pins.
This has pros and cons, and diminishing returns.
Cheapest-possible i2c come in SOT23 (a plus), but only 256 bytes (64 longs) at 9c@6K
So you need to bump to a larger i2c, still in SOT23, to just over 20c in the some-thousands column.
A far larger storage SPI flash part is already under 40c, so you can see the diminishing returns effect.
Chip has indicated Fuses can manage boot choices, and they give a good solution, but here I would caution that the Fuse handler/reader needs to be proven with confidence, as you really want to avoid a drop-dead situation.
Some 'safety nets' should be in the SW that checks fuses...eg loader does a sanity-check on fuses, before applying the details.
I'm kind of glad to be getting away from I2C chips, as they are not only slow, but take a ton of code to talk to. Here's from the Prop I loader:
'**************************************
'* I2C routines for 24x256/512 EEPROM *
'* assumes fastest RC timing - 20MHz *
'* SCL low time = 8 inst, >1.6us *
'* SCL high time = 4 inst, >0.8us *
'* SCL period = 12 inst, >2.4us *
'**************************************
'
'
' Begin eeprom read
'
ee_read mov address,#0 'reset address
call #ee_write 'begin write (sets address)
mov eedata,#$A1 'send read command
call #ee_start
if_c jmp #shutdown 'if no ack, shutdown
mov count,h8000 'set count to $8000
ee_read_ret ret
'
'
' Begin eeprom write
'
ee_write call #ee_wait 'wait for ack and begin write
mov eedata,address 'send high address
shr eedata,#8
call #ee_transmit
if_c jmp #shutdown 'if no ack, shutdown
mov eedata,address 'send low address
call #ee_transmit
if_c jmp #shutdown 'if no ack, shutdown
ee_write_ret ret
'
'
' Wait for eeprom ack
'
ee_wait mov count,#400 ' 400 attempts > 10ms @20MHz
:loop mov eedata,#$A0 '1 send write command
call #ee_start '132+
if_c djnz count,#:loop '1 if no ack, loop until done
if_c jmp #shutdown ' if no ack, shutdown
ee_wait_ret ret
'
'
' Start + transmit
'
ee_start mov bits,#9 '1 ready 9 start attempts
:loop andn pina,mask_scl '1(!) ready scl low
or dira,mask_scl '1! scl low
nop '1
andn dira,mask_sda '1! sda float
call #delay5 '5
or pina,mask_scl '1! scl high
nop '1
test mask_sda,pina wc 'h?h sample sda
if_nc djnz bits,#:loop '1,2 if sda not high, loop until done
if_nc jmp #shutdown '1 if sda still not high, shutdown
or dira,mask_sda '1! sda low
'
'
' Transmit/receive
'
ee_transmit shl eedata,#1 '1 ready to transmit byte and receive ack
or eedata,#000000_1 '1
jmp #ee_tr '1
ee_receive mov eedata,#111111_0 '1 ready to receive byte and transmit ack
ee_tr mov bits,#9 '1 transmit/receive byte and ack
:loop test eedata,#$100 wz '1 get next sda output state
andn pina,mask_scl '1! scl low
rcl eedata,#1 '1 shift in prior sda input state
muxz dira,mask_sda '1! sda low/float
call #delay4 '4
test mask_sda,pina wc 'h?h sample sda
or pina,mask_scl '1! scl high
nop '1
djnz bits,#:loop '1,2 if another bit, loop
and eedata,#$FF '1 isolate byte received
ee_receive_ret
ee_transmit_ret
ee_start_ret ret '1 nc=ack
'
'
' Stop
'
ee_stop mov bits,#9 '1 ready 9 stop attempts
:loop andn pina,mask_scl '1! scl low
nop '1
or dira,mask_sda '1! sda low
call #delay5 '5
or pina,mask_scl '1! scl high
call #delay3 '3
andn dira,mask_sda '1! sda float
call #delay4 '4
test mask_sda,pina wc 'h?h sample sda
if_nc djnz bits,#:loop '1,2 if sda not high, loop until done
ee_jmp if_nc jmp #shutdown '1 if sda still not high, shutdown
ee_stop_ret ret '1
'
'
' Cycle delays
'
delay5 nop '1
delay4 nop '1
delay3 nop '1
delay2
delay2_ret
delay3_ret
delay4_ret
delay5_ret ret '1
Compare that to the SPI code in the loader I posted a few pages back. Where we once had mere calls to these I2C routines, we now have minor bit twiddling to do the whole task.
It is not as I will have it --- BUT others postuladed simpler solution --- That was my answer
BUT have You read my post on use CUSTOM fuses du decide what device's will be used with BOOT and what pins them will be connected to ??
Yes, we could do something like that, but it would be good to minimize risk and, better yet, come up with a plan that is simple, robust, and constant.
How about trying to boot an SD card after flash fails, using the same pins (someone suggested this, above)? This would not increase the pin footprint at boot-up, and if customers wanted to have both SD and flash, they could put the boot medium on the dedicated pins, and locate the other elsewhere.
Does anyone know (sorry I haven't discovered this myself), whether there is mutual exclusion between SD and flash SPI commands? If there is separation in commands, we could have a policy of SD 1st / flash 2nd or flash 1st / SD 2nd, or even make it selectable through a fuse bit. Any suggestions on this?
For them that need update theirs programs in field by customer from SD that is not good as it will be always Flash that override SD bootind
SD for that need be first in chain
BUT how if I have other things connected to pins BOOT scan for its devices --- And disturb them ??
Ps. Not mention That that can simplify for designers placement of components !!
Yes, we could do something like that, but it would be good to minimize risk and, better yet, come up with a plan that is simple, robust, and constant.
How about trying to boot an SD card after flash fails, using the same pins (someone suggested this, above)? This would not increase the pin footprint at boot-up, and if customers wanted to have both SD and flash, they could put the boot medium on the dedicated pins, and locate the other elsewhere.
Does anyone know (sorry I haven't discovered this myself), whether there is mutual exclusion between SD and flash SPI commands? If there is separation in commands, we could have a policy of SD 1st / flash 2nd or flash 1st / SD 2nd, or even make it selectable through a fuse bit. Any suggestions on this?
You could put the fuse settings in one of those 9-cent EEPROMS that jmg mentioned and use a separate programming protocol for setting them.
Some vendors bond two die into one package. I wonder if a smallest-die EEPROM would fit ?
If the Prop 2 Fuses work 100%, (and cost less than 9c to implement) then they are a good option.
Only minus is the OTP nature, tho for some security/ID options, that is a plus.
...And maybe a fuse bit could optionally reorder #2 and #3.
This way, booter pin use is tightly limited and if you wanted BOTH flash and SD, you could relocate the non-booting one's CS to another pin.
How would this be?
I can see that some would want to skip #1, as it has a time cost, and an attack risk.
#2 would also have some risks - if there is a flash connected, that somehow triggers on a SD load, you are dead.
So the least-reliable boot I think should be last, and all 3 should have options to skip.
Default shipping would be all enabled ( I would do Serial/Flash/SD), and users could flip off.
An all-off case would need to default to something other than nothing. - I'd choose SPI Flash, as that can always re-enable serial.
I think I agree with jmg that SD should be last (especially in case it doesn't wind up working right...)
Also, I think I'd try to make the serial more forgiving that Prop I... People seem to often have trouble connecting...
I put SD in the middle just for this reason. If it doesn't work right, your P2 powered widget can fail gracefully rather than just let the user keep resetting it with a bad SD.
There's ONE thing you guys might not be considering:
Everything is authenticated by SHA-256 HMAC before it is allowed to run. This way, there is no way anyone can slip in any unauthorized code, since it must be signed using the secret 128 fuse bits dedicated to this purpose. So, all that matters is the boot *sequence*, not what boots are attempted. If any authentic code is found on any medium, YOU put it there.
pin 89 = SPI CS
pin 88 = SPI CLK
pin 87 = SPI DI
pin 86 = SPI DO
*** THAT'S IT ***
....
How would this be?
Don't forget you need to define the QuadSPI pins, and at least internal Pull-Up-Resistor/ Light drive Hi the unused D1..D3 during Boot preamble, in order to KNOW you have placed any QuadSPI device, into 1 bit mode for the Boot process, from any reset action. (as you mentioned before)
Boot is one-bit, but the connected Flash Chip may not be ( and is less likely to be 1 bit over time).
A small stub loader would slip into 4 bit mode, and likely all Eval Boards / ref designs would do this, but that code is in Flash, not ROM.
This allows coverage of OctalSPI ** and even DDR spi, for those that want it.
** an OctalSPI user would have to do their own Reset preamble on the upper nibble device, prior to read.
Looks good for BOOT ---
BUT not for reusing Flash and SD in other systems activities to its full capablitys
If You need have SPI for boot on this pins
pin 89 = SPI CS
pin 88 = SPI CLK
pin 87 = SPI DI
pin 86 = SPI DO
so with fuse swap it need have at least fuse to add one more pin group to possibility to run SD from other pins that this ones.
I know You will made it simple --- BUT I think that usability counts to.
I put SD in the middle just for this reason. If it doesn't work right, your P2 powered widget can fail gracefully rather than just let the user keep resetting it with a bad SD.
If you want "fail gracefully " you must have SPI flash installed, and then your 2) SPI Flash can 'short-boot' skip to SD read, and so you get the best of both worlds.
I guess you can either call the default ROM SD loader, if that works for you, or have your own, revisable, in the SPI flash.
Don't forget you need to define the QuadSPI pins, and at least internal Pull-Up-Resistor/ Light drive Hi the unused D1..D3 during Boot preamble, in order to KNOW you have placed any QuadSPI device, into 1 bit mode for the Boot process, from any reset action. (as you mentioned before)
Boot is one-bit, but the connected Flash Chip may not be ( and is less likely to be 1 bit over time).
A small stub loader would slip into 4 bit mode, and likely all Eval Boards / ref designs would do this, but that code is in Flash, not ROM.
This allows coverage of OctalSPI ** and even DDR spi, for those that want it.
** an OctalSPI user would have to do their own Reset preamble on the upper nibble device, prior to read.
The saving grace with all SPI parts is that commands are sent on DI (io0), only, regardless of 1-, 2-, or 4-bit modes. So, you needn't worry about pulling the initially-unused pins high. You WOULD want to pull any other flash's DI(io0) high, though, if it was sharing the CS and CLK pins with the booting device.
The saving grace with all SPI parts is that commands are sent on DI (io0), only, regardless of 1-, 2-, or 4-bit modes. So, you needn't worry about pulling the initially-unused pins high. You WOULD want to pull any other flash's DI(io0) high, though, if it was sharing the CS and CLK pins with the booting device.
I think you do need to pull D2 and D3 high because they are /WE and /HOLD when in single bit mode. The /HOLD will be a problem if it happens to float low won't it?
I think you do need to pull D2 and D3 high because they are /WE and /HOLD when in single bit mode. The /HOLD will be a problem if it happens to float low won't it?
It doesn't have to be. Those SPI flash's have a non-volatile config bit which causes those /WE and /HOLD pins to be ignored. When programming the flash chip, the loader doing the programming would set this bit for you (while driving /WE and /HOLD high), along with loading the code into the device. It won't matter after that, as those /WE and /HOLD pins will be don't-care.
The saving grace with all SPI parts is that commands are sent on DI (io0), only, regardless of 1-, 2-, or 4-bit modes. So, you needn't worry about pulling the initially-unused pins high.
Have you confirmed that in tests, as that is not what the data sheets I have here say ?
(Add: Also as #632 says, those pins are /WE /HOLD in 1 bit mode and are now connected to Prop Pins )
QuadSPI is designed for speed, so some modes are 'sticky'.
Yes, a cold reset is to 1 bit mode, but a user may be in a Quad mode when a reset arrives.....
Comments
That's right, plus they cost a lot more for the amount of storage you get. Here are the cheapest two 128k x 8 parts from Digikey, of each type:
I2C (2 pins), 1MHz, "CAT24M01WI-GT3", $0.94/1k units
SPI, (4 pins), 104MHz, "MX25L1006EMI-10G", $0.37/1k units
I know it is maybe BAD idea
BUT why not use CUSTOM fuses to have them decide what type and PINS of device them will use as BOOT.
And have only Serial as default in not preprogrammed Propeller II !!
No, that is a very good idea, provided the fuses are proven enough.
It should default to on, and a zapped fuse disables that load option, with all zapped (doofus!) perhaps giving SPI ?
(or, a back to the default ? gives more oops useful silicon, but does allow hacking/tamper attacks..)
I can see some users would want hacking/tamper protection @ loader, and Serial-load-first has delays and risks...
Also those who worry about pins-waggling unexpectedly can manage that via the fuses.
Emulating a SPI slave in a AVR is non-trivial - there is no 'wait' handshake, and the Prop will not know the AVR is waiting on Windows...
Because it limits pin creep going downwards. If you have a single-bit SPI flash, a Quad SPI flash, or even two Quad SPI flash chips, they can all boot the same by only using pins 87 (din) and pins 86 (dout) for the data paths in single-bit mode.
All SPI:
89 = cs
88 = clk
Single SPI:
87 = din
86 = dout
Quad SPI:
87 = io0/din
86 = io1/dout
85 = io2
84 = io3
For additional Quad SPI:
83 = io0
82 = io1
81 = io2
80 = io3
I'm kind of glad to be getting away from I2C chips, as they are not only slow, but take a ton of code to talk to. Here's from the Prop I loader:
Compare that to the SPI code in the loader I posted a few pages back. Where we once had mere calls to these I2C routines, we now have minor bit twiddling to do the whole task.
This has pros and cons, and diminishing returns.
Cheapest-possible i2c come in SOT23 (a plus), but only 256 bytes (64 longs) at 9c@6K
So you need to bump to a larger i2c, still in SOT23, to just over 20c in the some-thousands column.
A far larger storage SPI flash part is already under 40c, so you can see the diminishing returns effect.
Chip has indicated Fuses can manage boot choices, and they give a good solution, but here I would caution that the Fuse handler/reader needs to be proven with confidence, as you really want to avoid a drop-dead situation.
Some 'safety nets' should be in the SW that checks fuses...eg loader does a sanity-check on fuses, before applying the details.
It is not as I will have it --- BUT others postuladed simpler solution --- That was my answer
BUT have You read my post on use CUSTOM fuses du decide what device's will be used with BOOT and what pins them will be connected to ??
Yes, we could do something like that, but it would be good to minimize risk and, better yet, come up with a plan that is simple, robust, and constant.
How about trying to boot an SD card after flash fails, using the same pins (someone suggested this, above)? This would not increase the pin footprint at boot-up, and if customers wanted to have both SD and flash, they could put the boot medium on the dedicated pins, and locate the other elsewhere.
Does anyone know (sorry I haven't discovered this myself), whether there is mutual exclusion between SD and flash SPI commands? If there is separation in commands, we could have a policy of SD 1st / flash 2nd or flash 1st / SD 2nd, or even make it selectable through a fuse bit. Any suggestions on this?
For them that need update theirs programs in field by customer from SD that is not good as it will be always Flash that override SD bootind
SD for that need be first in chain
BUT how if I have other things connected to pins BOOT scan for its devices --- And disturb them ??
Ps. Not mention That that can simplify for designers placement of components !!
Even for mass production You need program Flash to every entity
OK --- Maybe other solution.
Use one fuse that instruct BOOT loader to override its standards and use preprogrammed in fuses.
-Phil
Some vendors bond two die into one package. I wonder if a smallest-die EEPROM would fit ?
If the Prop 2 Fuses work 100%, (and cost less than 9c to implement) then they are a good option.
Only minus is the OTP nature, tho for some security/ID options, that is a plus.
pin 91 = Serial RX
pin 90 = Serial TX
pin 89 = SPI CS
pin 88 = SPI CLK
pin 87 = SPI DI
pin 86 = SPI DO
*** THAT'S IT ***
Boot sequence:
1) Serial
2) SPI SD
3) SPI Flash
...And maybe a fuse bit could optionally reorder #2 and #3.
This way, booter pin use is tightly limited and if you wanted BOTH flash and SD, you could relocate the non-booting one's CS to another pin.
How would this be?
I can see that some would want to skip #1, as it has a time cost, and an attack risk.
#2 would also have some risks - if there is a flash connected, that somehow triggers on a SD load, you are dead.
So the least-reliable boot I think should be last, and all 3 should have options to skip.
Default shipping would be all enabled ( I would do Serial/Flash/SD), and users could flip off.
An all-off case would need to default to something other than nothing. - I'd choose SPI Flash, as that can always re-enable serial.
What happens on boot failure ? A POST LED ?
Also, I think I'd try to make the serial more forgiving that Prop I... People seem to often have trouble connecting...
I put SD in the middle just for this reason. If it doesn't work right, your P2 powered widget can fail gracefully rather than just let the user keep resetting it with a bad SD.
Everything is authenticated by SHA-256 HMAC before it is allowed to run. This way, there is no way anyone can slip in any unauthorized code, since it must be signed using the secret 128 fuse bits dedicated to this purpose. So, all that matters is the boot *sequence*, not what boots are attempted. If any authentic code is found on any medium, YOU put it there.
Don't forget you need to define the QuadSPI pins, and at least internal Pull-Up-Resistor/ Light drive Hi the unused D1..D3 during Boot preamble, in order to KNOW you have placed any QuadSPI device, into 1 bit mode for the Boot process, from any reset action. (as you mentioned before)
Boot is one-bit, but the connected Flash Chip may not be ( and is less likely to be 1 bit over time).
A small stub loader would slip into 4 bit mode, and likely all Eval Boards / ref designs would do this, but that code is in Flash, not ROM.
This allows coverage of OctalSPI ** and even DDR spi, for those that want it.
** an OctalSPI user would have to do their own Reset preamble on the upper nibble device, prior to read.
Looks good for BOOT ---
BUT not for reusing Flash and SD in other systems activities to its full capablitys
If You need have SPI for boot on this pins
pin 89 = SPI CS
pin 88 = SPI CLK
pin 87 = SPI DI
pin 86 = SPI DO
so with fuse swap it need have at least fuse to add one more pin group to possibility to run SD from other pins that this ones.
I know You will made it simple --- BUT I think that usability counts to.
If you want "fail gracefully " you must have SPI flash installed, and then your 2) SPI Flash can 'short-boot' skip to SD read, and so you get the best of both worlds.
I guess you can either call the default ROM SD loader, if that works for you, or have your own, revisable, in the SPI flash.
The saving grace with all SPI parts is that commands are sent on DI (io0), only, regardless of 1-, 2-, or 4-bit modes. So, you needn't worry about pulling the initially-unused pins high. You WOULD want to pull any other flash's DI(io0) high, though, if it was sharing the CS and CLK pins with the booting device.
It doesn't have to be. Those SPI flash's have a non-volatile config bit which causes those /WE and /HOLD pins to be ignored. When programming the flash chip, the loader doing the programming would set this bit for you (while driving /WE and /HOLD high), along with loading the code into the device. It won't matter after that, as those /WE and /HOLD pins will be don't-care.
Have you confirmed that in tests, as that is not what the data sheets I have here say ?
(Add: Also as #632 says, those pins are /WE /HOLD in 1 bit mode and are now connected to Prop Pins )
QuadSPI is designed for speed, so some modes are 'sticky'.
Yes, a cold reset is to 1 bit mode, but a user may be in a Quad mode when a reset arrives.....