P2 Boot Rom Decision trees, jumpers, Fast Pin Init, etc
jmg
Posts: 15,173
in Propeller 2
Reading the discussions around Boot ROM, and what can, and cannot, fit into that, and ideas around included higher level support, & languages & Parallax software resources.... & it got me thinking...
Right now, there are pre-wired jumpers to select boot decision choices, for faster boot, but those need added parts, explanation, and are not easily changed.
These also limit the choices, as there are a finite number of pins.
Then the idea occurred to pull those jumpers into a compact/cheap memory.
This eliminates manual jumper provision and selection, and can make a PCB smaller and easier to document.
This also expands the choices, as there is no longer pin-limits.
Along with Rapid Boot-source choice, you can now include a Library index.
Parallax could ship a P2-resource-image, with ALL of Spin-P2, Forth-P2, Prop2-Basic, Python-P2....
The 'electronic jumper' can easily say 'Boot from SPI', and select a library item number. Gives the appearance of Spin in ROM..
Some users have asked for OTP serial numbers, & if P2 is not going to have OTP, that's a usage issue.....
Looking for suitable memory, I can find
* Small MCUs, eg STC8F04 (SO8) (still quite new, but appears to be very low cost and secure, with i2c ability) or also new STM8S001J3M3 (SO8)
* Serial Presence Detect memory (SPD), (eg 34C02) looks close to ideal. Can come as small as 2x3mm, and Digikey lists from 3.1c
eg
34C02, has 128 bytes of OTP are, that can be written and OTP-locked, for those wanting product serial numbers, and customer config information.
Many MCUs have fuse options for default port settings - a Fast-read SPD memory, could init the port-pins in Boot, before the whole program is loaded.
That should slash the time from RESET-to-known-pin values, and makes that time not depend on code size. eg 16 Bytes can fast-define OUT and DIR.
This can also give a Physical P2 identity, removing/augmenting the need for Physical Pin Masks in the loader-preamble.
(someone who wants to use 16,32,64 P2's is not going to be keen on losing 4,5,6 pins on each part, just for the ID )
The 34C02 is made in large volumes, multisourced, (includes OnSemi) and is i2c read, and has 128 bytes of EEPROM, that becomes the jumper area, and 128 bytes of Permanent Software Write Protection
The suggestion is that Boot ROM adds code to check for connected SPD (eg) 34C02, and if found, & not blank, it uses that info for the next boot decisions, rapid Pin Init, and other housekeeping tasks...(PLL clk set?) etc
People are used to having such Config memory on every DIMM module, so Parallax could plan to include this on every P2 module.
Serial Flash parts are low cost, 20c gets you 2MBytes, a small portion of which can be Parallax Software libraries.
All of this reduces the impact of not having OTP in the P2 itself.
Right now, there are pre-wired jumpers to select boot decision choices, for faster boot, but those need added parts, explanation, and are not easily changed.
These also limit the choices, as there are a finite number of pins.
Then the idea occurred to pull those jumpers into a compact/cheap memory.
This eliminates manual jumper provision and selection, and can make a PCB smaller and easier to document.
This also expands the choices, as there is no longer pin-limits.
Along with Rapid Boot-source choice, you can now include a Library index.
Parallax could ship a P2-resource-image, with ALL of Spin-P2, Forth-P2, Prop2-Basic, Python-P2....
The 'electronic jumper' can easily say 'Boot from SPI', and select a library item number. Gives the appearance of Spin in ROM..
Some users have asked for OTP serial numbers, & if P2 is not going to have OTP, that's a usage issue.....
Looking for suitable memory, I can find
* Small MCUs, eg STC8F04 (SO8) (still quite new, but appears to be very low cost and secure, with i2c ability) or also new STM8S001J3M3 (SO8)
* Serial Presence Detect memory (SPD), (eg 34C02) looks close to ideal. Can come as small as 2x3mm, and Digikey lists from 3.1c
eg
34C02, has 128 bytes of OTP are, that can be written and OTP-locked, for those wanting product serial numbers, and customer config information.
Many MCUs have fuse options for default port settings - a Fast-read SPD memory, could init the port-pins in Boot, before the whole program is loaded.
That should slash the time from RESET-to-known-pin values, and makes that time not depend on code size. eg 16 Bytes can fast-define OUT and DIR.
This can also give a Physical P2 identity, removing/augmenting the need for Physical Pin Masks in the loader-preamble.
(someone who wants to use 16,32,64 P2's is not going to be keen on losing 4,5,6 pins on each part, just for the ID )
The 34C02 is made in large volumes, multisourced, (includes OnSemi) and is i2c read, and has 128 bytes of EEPROM, that becomes the jumper area, and 128 bytes of Permanent Software Write Protection
The suggestion is that Boot ROM adds code to check for connected SPD (eg) 34C02, and if found, & not blank, it uses that info for the next boot decisions, rapid Pin Init, and other housekeeping tasks...(PLL clk set?) etc
People are used to having such Config memory on every DIMM module, so Parallax could plan to include this on every P2 module.
Serial Flash parts are low cost, 20c gets you 2MBytes, a small portion of which can be Parallax Software libraries.
All of this reduces the impact of not having OTP in the P2 itself.
Comments
This is still a valid way, and only requires a single resistor to Vcc or GND. Implementation can be a 3 pad 0603 resistor, centre pad to the io pin and side pads to Vcc and GND. Just place the resistor in either position for pull-up or pulldown. The value can be determined by trying different internal pull-up and pulldown values operating as voltage dividers.
To be useful and marketable it makes no sense for say 2/4/8 P2s if one can not connect say 64 without loosing 6 pins on each Chip. Could smart pins help there lke @Cluso99 suggested?
@Cluso99, I missed it the first time you mentioned that. But you are perfectly right. One could use a single pin in ADC mode to preselect the preferred boot option.
Mike
Yes, but to test, that has to work with a FPGA IO pin, which is pretty much limited to present/absent testing.
It also needs physical access and soldering-iron-modify of the board, as well as careful reading of the DOCs...
SPD memory can be checked by software, to readily can confirm what you have defined - no DOCs needed, just the SW.
Or is that SPD memory as common as flash ?
Mike
Do you think we should keep the masked-pin sensitivity in the loader for loading multiple P2's from a common RX? One thing that diminishes its viability, somewhat, is the always-driven full-duplex TX from the chips. I'd have to make a protocol option for only driving TX during response messages and require that for multiple chips, there'd be a pull-up resistor on the common TX signal. We could automatically go into this common-TX-with-pull-up/only-drive-during-response-message mode when the INA/INB mask values were non-0. Any thoughts?
You can always emulate a SPD using one of those i2c slave capable MCUs.
Seems to make sense to have a simpler a variant command, with no masks/addr at all that is always-driven for 1:1 and then a masks/addr version that allows wired-or replies to 1:N arrays.
Being able to load many P2's is certainly a useful feature, whether it is done from Pin-connect-Address, or an address it finds in a SPD-EE is more open..
My feeling is users will not like losing some number of P2 pins, merely to set an address.
If someone wants to make an array of standard P2 Modules, that's getting messy, but if every module has a SPD-EE, it becomes simpler.
Allocate of those address values in a clean first build would be a challenge, pogo pins for the i2c may be required on first bring-up. After that, not needed.
It might be an elevation to this level of Flash, can save the SPD ?
If I go to Winbond's store, and find a part about the price-knee, (~38c) it gives...
7.2.26 Read Unique ID Number (4Bh) The Read Unique ID Number instruction accesses a factory-set read-only 64-bit number that is unique to each W25Q80EW device.
and this ..
* Advanced Security Features
– Software and Hardware Write-Protect
– Top/Bottom, 4KB complement array protection
– Lock-Down and Special OTP array protection
– 64-Bit Unique Serial Number for each device
– Discoverable Parameters (SFDP) Register
– 3X256-Byte Security Registers with OTP locks
– Volatile & Non-volatile Status Register Bits
You would need some means to read the 64-Bit Unique Serial Number, and user maps those to their physical P2, but from there you could personalize a loader command, with zero pin cost, for ANY number of connected P2's.
I think a moderate baud, Enquire_ID command could use the WIRED OR TX feature, as arbitration similar to CAN.
After reset, all P2s read their unique ID, and an Enquire_ID command can request that.
All P2s start sending, and check shared OpenDrain TX, if another P2 has that low, it releases and waits. Most-leading L's wins, and successful sends tag-off as done. (No reply until next reset)
An All_done query, replies 0xff (from everyone) for none left to find.
Anything that encourages use of large arrays of P2, has to be good for Parallax
Addit: looks like 04bh command is common, but 64b is one choice(winbond), others do 128b (ISSI,Gigadevice), so an 'EnquireID N' that read N bytes may be smarter.
Addit2: The most flexible form for this, could be a SPI_Bridge command, that does not try to be too smart - has TxCount, RxCount, and payloads.
eg SPI_Bridge, SPI_Bridge_OD pass thru commands and echos everything, including dummy bytes. The OD version is open drain arbitration for multiple P2s, used for serial ID read.
That future proofs the SPI, & allows anything to be connected. OTP areas, or n-Bit unique IDs can be read.
I am not comfortable with the SO/TXD/P62 pin being OD (open drain)...
1. It will require a pullup resistor (either internal or external) to work.
2. It will reduce the serial speed (everyone seems to want exceptionally high speed)
3. IMHO it's a burden for single P2 boards, just to provide a method for the few possible multiple P2 boards.
Boot Sequence and Pinouts
I am not comfortable that the FLASH boot sequence shares/joins SO & SI pins...
1. This prohibits the option to use Dual/Quad SPI.
2. The pinout arrangement of P58..P61 do not support D0..D3 in the correct orientation. The additional time (instructions) wasted to rearrange the nibble bits b0..b3 in correct order will likely render the advantage of QSPI worthless.
3. The D0..D3 problem also applies to the SD Card interface, should SD 4-bit be used later.
Suggested Pinout & Boot Sequence
You will note in the diagram below...
1. The D0..D3 bits are located as P56..P59. This permits a 4bit shift to assemble the two nibbles into a byte simply.
2. It is possible to skip/order the boot sequence simply by checking for pullups (pulldown for serial SI as per Prop P1).
3. I included I2C EEPROM as a boot option (just in case anyone wanted to argue for it).
4. For the SD, I marked the 10K pullup as "internal???" (internal to the SD Card) as Peter (Tachyon fame) does not use an external pullup,relyingon the internal pullup.
I have spent a lot of time testing microSD Cards without any problems of late. I believe I have the initialisation sequence 100% reiable, at least with named brand cards anyway.
I am also interested to try SD 1-bit mode out (not SPI) as from what I have read recently, this has been resolved too. That may lead to SD 4-bit mode working too.
As a number of you know, my P8XBlade2 tiny prop boards come with a pre-programmed EEPROM that is write protected by default. It boots a microSD Card loaded with my Prop OS. The OS supports running Prop Binaries, as well as upload and download of files on a FAT16/32 microSD Card. I have no problems with my SD Boot code, which was based on Kye's FAT Driver, plus mods.
I thought that OD only applied when the Pin-Masks are NON 0 0 0 0 - ie only when talking to multiple P2 ?
Otherwise, it is normal PushPull drive ?
I do not see single-pin serial there, I think that is still supported by command ?
Fastest possible SPI boot, should always be a focus.
The fast-skip of serial is important, but needs care.
Some systems will have SPI and connected UARTS, so a RX pulldown might not be practical.
Also, a host MCU may be sending data polling P2, at P2 reset exit, so it's not easy to reliably test for pulldown...
You could place sense on TX pin, but then you generate a pulse on reset-exit, also less than ideal..
More robust is a Series R to UART on P63 and another series R linking P63 to SPI.CLK pin P60 ?
At Boot, P2 pulses P63 and looks for edges on P60, if P60 changes when P63 does, there is a Skip-resistor present, and SPI starts immediately.
Compatible with 1 pin boot schemes, as ONLY P63 is driven to check.
i2c is useful, but rare, so I'd place that in order after SPI boot, to maintain boot speed.
There are also octal SPI parts now, some thought should be given to how those can connect to P2, and Boot.
test mask_rx,ina wc 'if rx high, check for host if_nc jmp #boot 'else, boot from eepromWhat this means, is that if no UART is connected, then the SI/P63 pulldown resistor will result in the pin being low. If a UART is connected, then the SI/P63 pin (uart) will override the pulldown, and the serial will not be skipped.I don't like linking pins with resistors, particularly as there is no need for it.
To determine whether a FLASH chip or SD Card is present, it is just a matter for the boot software to check for a pullup on the FLASH nCS pin. FWIW a pullup should be present to prevent the FLASH from inadvertantly getting a CS pulse. We don't want the FLASH getting corrupted.
If FLASH is not present, the boot should try to boot an SD Card. If it fails, then the P2 stops (just like the P1).
IMHO we can ditch the EEPROM booting option. If an Octal SPI is connected, then P52..P55 can be connected to D4..D7. I believe there is an instruction to rearrange nibbles, so it's possible to send the D0..3 nibble to b3..0, and D4..7 to b4..7 in one instruction.
It can have 10K or 100K pull-down or pull-up, using P2 internal pull-up/down you can quickly detect the 4 options.
P2 Docs say:
Commands can be made half-duplex by inserting an asterisk (“*”) between the command keyword and the INAmask value.
When the asterisk is present, all serial responses will be sent on P63, instead of P62.
Single pin serial gives the lowest-pin-cost loader, and can use the super-cheap MCUs that are sub 30c, as modest code-loaders.
The 'need for it', is to avoid the limitations of the P1 approach, which is simply too primitive to use on P2.
* You cannot fast-boot with a Serial Port connected
* if you exit reset (eg WDOG) during a data packet, with such a single-point test, you can make the wrong choice.
Linking pins with resistors is really no different to linking Vcc or ground
- what you are trying to do is craft a reliable sense scheme that does not impact the pin-count if unused.
That could be easy to explain, but does consume one dedicated pin for boot-choice, and it is also not very FPGA-test friendly.
Perhaps ideally P2 should have been designed with a 65th pin for this boot-choice selection, but was not... so we need a minimal-pin solution.
https://docs.google.com/document/d/1hLLw4pU1uwOo1mHtF17oB91KNTsZv4zbC6nGSYbJi-o/edit?usp=sharing
I'm getting a new release together, but discovered some bug involving smart pins and more than one cog. I've been working on it all day.
I have been reading the boot process.
Chip, I really think you need to rethink the boot pinouts for FLASH. Your current method of joining SO & SI precludes using the Quad SPI mode on the FLASH. The same applies to the pins being used for SO & SI which become D1 & D0 respectively.
I would like to have a boot option for SD Cards in ROM as an alternative to FLASH. As you can see from my diagram a few posts back, SD Card fits into the boot pinout easily, and can be operated in SD 1-pin & 4-pin modes by the use if required. SPI FLASH vs SPI SD can be determined easily by where pull-ups are located.
If you want to include an SD boot option in ROM, I can write the P2 SD boot code, liaising with Peter Jakacki so that it works with Tachyon too. I am just waiting for the go ahead from you as I don't want to waste my time otherwise.
How robust is your SD approach? It sure would be nice to be able to insert an SD card and have a system.
I know the DI+DO arrangement precludes others, but for many systems it's just so simple and keeps the remaining pins most free and clean in the layout. When it only takes 52ms to load 512KB over one pin at 80MHz, is quadSPI really that important when it eats three more pins? Can you give me a few examples? I'm open to being convinced. I'm just not seeing it, yet.
I think I2C is too slow/small/expensive to bother with. What do you think?
Serial, SD, and 3-pin SPI flash seem most important.
To support single SPI flash just needs to leave two pins vacant, which I see as preferable. I don't believe P2 Boot needs to support quad SPI.
The same applies to SD Cards. There is a lot more interest out there on other micros for implementing the SD 1bit and 4bit modes.
As for reliable SD use, both Peter and I have P1 boards in the field that have fixed eeprom boot code to use the SD cards in SPI mode. There is a lot of miss-information out there about problems. IMHO many of these arose because of miss understanding of the SD SPI specs, and likely also because of cheap fake SD Cards on eBay too.
If you would like to see what is possible, I sent one of my P8XBlade2 pcbs to Ken about two years ago. You will need any microSD card (I prefer SanDisk as they have proven to be the most reliable although all the different brands that I have here all work (1GB..32GB)). If you want to try this, I can email you the files to copy to a formatted microSD card. Files are also in the thread links in my signature. The SD will then go straight into my Prop OS.
I2C eeprom can be dropped for all I care.
Users want to be able to use Quad in their own code, just like the new xSPI standard. (which is also DDR optionally)
It is not so important that Boot use Quad, so much as that it allows a Quad-Connected part to boot.
That's why I suggested i2c is 'moved-right' ..
If it falls right of the end, I'd not lose too much sleep
The appeal of i2c is compact memories (sg SOT23-5) and being able to share the bus, after boot, but the cost per bit of i2c is not great.
Small MCUs can also do i2c slaves, better than they can do SPI slaves.
If you must share SI/SO on FLASH, then how about this...
0. Check for pullups/pulldowns on P63..P59 and save
.. If P62=PulldownP63/SI/RXD=PulldownHigh(no pulldown, else Serial connected), goto "1" (Serial)
.. If P61=Pullup & P60=Pullup, goto "4" (I2C EEPROM)
.. If P61=Pullup (& P60=No-Pullup), goto "2A" (SPI FLASH)
.. If P59=Pullup, goto "3" (SPI SD)
.. Else goto "1" with bigger timeout???
1. Serial: Wait for boot
Need to work out how long to wait. Need to ensure we can override other options in case bug in FLASH/EEPROM/SD. Further discussion required!
2A. FLASH: SI/SO shared (P61=nCS w pullup, P60=CLK, P59=SI w resistor to SO)
.. Try initialisation command on P59 and check for ACK back on P59
.. If ACK on P59, continue to load, else goto "2B"
2B. FLASH: SPI/QSPI (P61=nCS w pullup, P60=CLK, P56=SI/D0, P57=SI/D1, P58 & P59 reserved for QSPI)
.. Try initialisation command on P56 and check for ACK back on P57
.. If ACK on P57, continueto load, else goto "1" (Serial)
3. SD Card: SPI/SD (P59=nCS w pullup, P60=CLK, P61=DI, P56=DO, P57 & P58 reserved for SD 4bit)
.. Try initialisation command on P61and check for ACK on P56
.. If ACK on P56, continue to load, else goto "1" (Serial)
4. EEPROM: I2C (P61=SDA w pullup, P60= SCL w pullup)
.. Try to load EEPROM and run, else goto "1" (Serial)
The above minimises pins, doesn't transmit on wrong pins, gives a number of boot options, and permits expansion to QSPI/QSD modes with correct D0..D3 orientation.
This will send a wide TX during any reset and so risks playing havoc with connected serial systems.
( that's why I chose RXD as the test pin, not TXD - target is minimal ripple effects during boot )
I don't think there's a need for that 3.3k resistor, as the SPI flash only drives SO when CS is low and it's been configured to output data. The Prop2 controls that, so there's no possibility of a conflict.
How realistic is it and what advantage is there in running the SD in 4-data-wire mode? Are you using 4-wire mode in your projects, or are you in SPI mode using just DI/DO? And do you know if DI and DO could be tied together for the same reasons that make it work with SPI flash chips?
How do you test for that RXD pulldown, given RXD is likely connected to a driving UART, or MCU - which can be either CMOS out, or Pullup designs ?
This what is done on the P1 and it works fine.
jmg,
What happens if the FLASH/SD/EEPROM code has a bug or is damaged?
How do you force a serial boot to fix this???
The above is how P1 handles it!
AH, you mean the pin is actually tested for Hi, not 'tested for pulldown' ?
ie a LOW on the pin, is assumed to be no-uart connected (but Low might be due to a sending/polling char).
A problem with that, is systems could have connected UART and want fast SPI boot.
Any sense design should allow that combination.
.. If P63/SI/RXD=High(no pulldown, else Serial connected), goto "1" (Serial)