P2 Boot Rom Decision trees, jumpers, Fast Pin Init, etc

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.
«13456

Comments

  • 179 Comments sorted by Date Added Votes
  • Years ago, I suggested using different value pull-ups/pull-downs on a single pin (SDA/MOSI for example) to select different boot options.

    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.
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • @Jmg, you have a valid point with too much pins needed to select chained P2s.

    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
    I am just another Code Monkey.

    A determined coder can write COBOL programs in any language. -- Author unknown.

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this post are to be interpreted as described in RFC 2119.
  • Cluso99 wrote: »
    Years ago, I suggested using different value pull-ups/pull-downs on a single pin (SDA/MOSI for example) to select different boot options.

    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.

    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.
  • But will SPD chips exist for the long lifetime of the P2? Parallax runs long life cycles and putting something into the boot-rom depending on a specific part might be risky.

    Or is that SPD memory as common as flash ?

    Mike
    I am just another Code Monkey.

    A determined coder can write COBOL programs in any language. -- Author unknown.

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this post are to be interpreted as described in RFC 2119.
  • cgraceycgracey Posts: 8,315
    edited October 25 Vote Up0Vote Down
    It's true that we can't test resistor-value boot settings on the FPGA, so putting it into ROM is a no-go. A single resistor would be better than multiple pins, for sure. This would be the domain of a 2nd-stage loader to handle, once silicon is available.

    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?
  • jmgjmg Posts: 10,617
    edited October 25 Vote Up0Vote Down
    msrobots wrote: »
    But will SPD chips exist for the long lifetime of the P2? Parallax runs long life cycles and putting something into the boot-rom depending on a specific part might be risky.

    Or is that SPD memory as common as flash ?
    They are used on DRAM modules, to identify them to BIOS, and are made by ST, OnSemi and Microchip, and others...

    You can always emulate a SPD using one of those i2c slave capable MCUs.
  • cgracey wrote: »
    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?

    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.
  • Thinking more about the Many-P2 designs, as well as serial handling, I see another wave of Flash memory now includes Unique ID.
    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.
  • Cluso99Cluso99 Posts: 12,976
    edited November 2 Vote Up0Vote Down
    Serial Boot

    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.

    P2v24%20BOOT%20HW2.jpg

    565 x 327 - 71K
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • jmgjmg Posts: 10,617
    edited November 2 Vote Up0Vote Down
    Cluso99 wrote: »
    Serial Boot

    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.

    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 ?

    Cluso99 wrote: »
    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

    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.


  • jmg wrote: »
    Cluso99 wrote: »
    Serial Boot

    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.

    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 ?
    Not sure ?

    Cluso99 wrote: »
    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

    I do not see single-pin serial there, I think that is still supported by command ?
    I don't recall seeing this as supported.


    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.
    The P1 already does this. First two instructions in booter.spin are...
                            test    mask_rx,ina     wc      'if rx high, check for host
            if_nc           jmp     #boot                   'else, boot from eeprom
    
    What 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).


    i2c is useful, but rare, so I'd place that in order after SPI boot, to maintain boot speed.
    IMHO we can ditch the EEPROM booting option.

    There are also octal SPI parts now, some thought should be given to how those can connect to P2, and Boot.
    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.


    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • tonyp12tonyp12 Posts: 1,865
    edited November 2 Vote Up0Vote Down
    One pin that you should make a output after boot, but is not used for something that minds it toggles with resets.
    It can have 10K or 100K pull-down or pull-up, using P2 internal pull-up/down you can quickly detect the 4 options.


  • jmgjmg Posts: 10,617
    edited November 2 Vote Up0Vote Down
    Cluso99 wrote: »
    > I do not see single-pin serial there, I think that is still supported by command ?

    I don't recall seeing this as supported.

    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.
    Cluso99 wrote: »
    The P1 already does this. First two instructions in booter.spin are...
                            test    mask_rx,ina     wc      'if rx high, check for host
            if_nc           jmp     #boot                   'else, boot from eeprom
    
    What 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.

    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.
    tonyp12 wrote: »
    One pin that you should make a output after boot, but is not used for something that minds it toggles with resets.
    It can have 10K or 100K pull-down or pull-up, using P2 internal pull-up/down you can quickly detect the 4 options.

    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.


  • Here is the latest documentation:

    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.
  • Thanks for the link Chip.
    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.
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • cgraceycgracey Posts: 8,315
    edited November 2 Vote Up0Vote Down
    Cluso,

    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.
  • Chip, IMHO I would rather see the options to be able to use Quad SPI. There are cheap 4-64MB Quad SPI FLASH chips. All the newer FLASH chips now support quad SPI mode and also the QSPI mode which is a later more universal quad mode.

    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.
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • threadzthreadz Posts: 44
    edited November 2 Vote Up0Vote Down
    I'm in favor of 1 bit AND 4 bit SD/Flash for boot up. If only 1 bit is to be used for boot - which i don't really have a problem with, 52ms boot time is plenty fast for just about everything - I think we need to be sure ahead of time that the bus is capable of transitioning to 4 bit after boot if the user finds it to be necessary. The faster throughput would benefit projects that use most of the RAM for pixel buffering and not all the code can fit in the remaining space so chunks need to be swapped out as it goes.

    I2C eeprom can be dropped for all I care.
  • cgracey wrote: »
    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.
    That 52ms assumed you changed clock speed, which also adds delays, but the biggest issue with excluding Quad, is PCB design.

    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.

    cgracey wrote: »
    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.

    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.

  • Cluso99Cluso99 Posts: 12,976
    edited November 3 Vote Up0Vote Down
    Chip,
    If you must share SI/SO on FLASH, then how about this...

    P2v25%20BOOT%20HW.jpg

    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.
    717 x 319 - 78K
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • Cluso99 wrote: »
    0. Check for pullups/pulldowns on P63..P59 and save
    .. If TXD.P62=Pulldown, goto "1" (Serial)

    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 )

  • Cluso,

    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?
  • jmg wrote: »
    Cluso99 wrote: »
    0. Check for pullups/pulldowns on P63..P59 and save
    .. If TXD.P62=Pulldown, goto "1" (Serial)

    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 )
    Thanks jmg. That was a typo and is now fixed.
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • Cluso99Cluso99 Posts: 12,976
    edited November 2 Vote Up0Vote Down
    deleted
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • Here is an updated schematic

    P2v25b%20BOOT%20HW.jpg
    1421 x 613 - 209K
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • Cluso99 wrote: »
    Here is an updated schematic

    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 ?

  • jmg wrote: »
    Cluso99 wrote: »
    Here is an updated schematic

    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 ?
    The rxd pulldown is tested to determine if an external uart txd is connected. No point in waiting for a uart character(s) if there is no uart connected. This just gives a faster boot from FLASH/SD/EEPROM, nothing more, nothing less.
    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!
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • ozpropdevozpropdev Posts: 1,958
    edited November 2 Vote Up0Vote Down
    @Cluso
    .. if P63/SI/RXD=Pulldown, goto "1" (Serial)
    
    Wouldn't a low on this pin normally indicate no serial idle state present. (therefore goto FLASH/SD?)

    Melbourne, Australia
  • Cluso99 wrote: »
    jmg wrote: »
    Cluso99 wrote: »
    Here is an updated schematic

    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 ?
    The rxd pulldown is tested to determine if an external uart txd is connected.

    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.
  • Cluso99Cluso99 Posts: 12,976
    edited November 3 Vote Up0Vote Down
    ozpropdev wrote: »
    @Cluso
    .. if P63/SI/RXD=Pulldown, goto "1" (Serial)
    
    Wouldn't a low on this pin normally indicate no serial idle state present. (therefore goto FLASH/SD?)
    Thanks. Still incorrect. It is meant to be as per P1 booter. Updated

    .. If P63/SI/RXD=High(no pulldown, else Serial connected), goto "1" (Serial)
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
Sign In or Register to comment.