P2 Boot Decision Tree Suggestions

jmgjmg Posts: 14,563
edited 2016-09-28 - 19:19:16 in Propeller 2
Now the ROM is finalising, with SerialLoad and FlashLoad core parts done, it is a good time to step back and look at how the decision tree could work, to give users the most flexible P2 they expect...

Here is some pseudo code, that merges suggestions from the SPI thread.

To keep code compact & simple, the pin map step selects the pins uses within Serial and Flash code.
ie sometimes OUT and IN are on the same pin, sometimes they are separate pins.

This allows any Boot-cost from 1-pin, up. A critical aspect of this, is Other-Mode exit, at Boot.
ie even if the part is in Quad/Dual mode, when RST applies, Boot needs to still succeed.
Suggested preambles, 
Function Send_1b_CS (NClocks, DataLJ)            ' sends N clocks, Data DIO0, with std CS frame 
Function Send_1b_CLK (NClocks, CS,DataIO0)  ' non frame send, SD clears

Send_1b_CS(8,$ff)         ' classic M4 exit Quad command, as in NXP etc
Send_1b_CS(16,$ffff)     ' classic M4 exit Dual command
Send_1b_CS(2,$ff)         ' nibble coverage, in case any parts lack the above, assumes Pullups on DIO3..DIO0. Parts listed below do not need this.
' <<  by here, BUS should be back in Single-bit mode.
PollBusy                        ' confirm device connected, and confirm is not Busy

' Optional firm reset - for some newer, larger parts.
Send_1b_CS(8,$66)         ' newer 66H,99H command pair
Send_1b_CS(8,$99)         ' newer 66H,99H command pair
Wait(>40us)                   ' does more than a pin-mode change
PollBusy                         ' unclear if poll busy can be used for 40us timing

' check device ID for <> 00,ff as connected device.

SD: tbf
Above covers DIO0 data, if a SPI part is quad-wired, and flipped into 1-SPI mode, HOLD# and WP# need to be Hi, managed either by external pullups, or internal pullups, or (less desirable) hard CMOS drive to 1.



SD is included, assumes code can fit & test.
( Failing ROM fit or test pass on SD, a user could use 1-pin mode to load any SD driver, from a ~28c MCU)
// Proposed Boot-Tree for P2, has just 2 main routines, SerialLoad and FlashLoad
// Pin mapping selects the pin-impacts of those routines
// Can vary from a smallest possible 1-pin, to 3 pins (Flash3P only) to 4 pins (FlashQuad connected)
// plus possible Combination of 2 pins for RXD.TXD & +2 on QSPI user choice.
// 
// Simple, fast echo-read-back type tests determine which branch to use.
// The physical connection is detected and that determines the branch chosen.
//
//
if Test_Present_OnePin      // Echo? => Minimal 1-Pin useage Boot mode, external cheap MCU
  SelectMap TXD,RXD OnePin  // MCU's own boot handles update path
  SerialLoad
elseif PinMode=SkipFlash    // No flash, or overrule flash cases (debug, updates)
  SelectMap TXD,RXD TwoPin
  SerialLoad  
elseif Test_Present_i2c        // Optional ? i2c step ?
  SelectMap SCL,SDA TwoPin 
  i2cLoad
elseif Test_Present_Flash3P // Lowest pin-count flash, 3 pins, _Excludes_ QSPI
  SelectMap SDI,SDO OnePin 
  FlashLoad
elseif Test_Present_Flash4P // _Allows_ PCB layout for QSPI(6p), boots in 1b SPI
  SelectMap SDI,SDO TwoPin 
  FlashLoad
elseif Test_Present_SD      // 
  SelectMap SDI,SDO SDPin 
  FlashLoadSD
else
  DefaultLoad               // No flash found (SerialLoad2Pin?)
                            // also DefaultLoads on Blank/fail load of present flash
						
						
Test_Present_Flash3P        // Nothing coming back on SDO=SDI ?
  SWResetPreamble (0xff,0xffff,0x66,0x99,{SIO3=\_/=},wait,0xAB,wait)
  return (ReadID(3P,0x90) <> 0x0000,0xffff)

Test_Present_Flash4P       // Reads in std 4 pin SPI, HOLD/WP = pullups, drives just 3 pins
  SWResetPreamble (0xff,0xffff,0x66,0x99,{SIO3=\_/=},wait,0xAB,wait)
  PulseNominated RST pin, wait    // for those subset parts that _do_ have RST
  return (ReadID(4P,0x90) <> 0x0000,0xffff)

FlashLoad
  uses READ_STATUS ($05)
  uses READ_DATA ($03)

«13456710

Comments

  • jmgjmg Posts: 14,563
    edited 2016-09-27 - 23:20:19
    Post 2 for Minimal 1-Pin useage Boot mode, external cheap MCU candidates

    Application usage of 1-Pin Boot via small MCU :
    * Maximal P2 smart pin usage, a design can now use 63 pins
    * Low impact load of USB or SD or RF-Link (etc) boot2 drivers, for future Soft-boot-updates
    * Can include a Watchdog for free
    * Can augment ADC/DAC of P2
    * Can use without, or with, SPI flash, with no change to P2 pin count. (MCU bridges SPI-1P)

    Small pin count, low cost simple MCUs, for Serial 1P memory emulation.
    (Focus on Memory size, then package size)
    Most include a serial boot loader, so can also do 1Pin to UART bridge.
    Vendor   CodeSize Part number  fOscMhz,Tol  Capture   MaxBaud   Package       Appx price, 1k
    Nuvoton  16kB     N79E715      22.118,3%VT  T2_f/4    691200    SO16N         28c
    Nuvoton  16kB     N76E885      22.118,2%VT  T2_f/1    1.38M     TSSOP28,20    42c (28p)
    Nuvoton  16kB     N76E003      tbf          tbf       1.38M     tbf           tbf (<< 42c)
    SyncMOS  16kB     SM39R16A3                           1.38M     MSOP10        tbf 
    SiLabs   2kB      EFM8BB1      24.5,2%VT    PCA_f/1   ~3M       QFN20 3mm     33c   
    SiLabs   8kB      EFM8BB1      24.5,2%VT    PCA_f/1   ~3M       SO16N         42c   
    SiLabs   16kB     EFM8BB2      40,2%VT      PCA_f/1   ~6M       QFN20 3mm     55c   
    SiLabs   64kB     EFM8BB3      48,2%VT      PCA_f/1   ~6M       QFN24 3mm     0.99   +12b ADC, 12b DAC
    Infineon 64kB     XMC1100                     tbf               TSSOP16       1.12
    
    
    Price climbs with code size, as RAM & peripherals tend to climb too, but there is Serial Flash
    which can be added to extend the 1P loader, for modest amounts ...
    
                                                                           Reset Via 1-bit
    Fremont  4Mbit      FT25H04S-RT              SO8           13.5c/3k    0xff/0xffff
    Fremont  16Mbit     FT25H16S-RT              SO8           18.6c/3k    0xff/0xffff
    Adesto   4Mbit      AT25SF041-SSHD-T         SO8           18.7c/3k    0xff/0xffff
    Winbond  32Mbit     W25Q32                   SO8           40c/3k      0x66+0x99
    Micron   32Mbit     N25Q032A                 SO8           38c/3k      0xff (XIP confirmation bit) 
    Macronix 16MB       MX25R1635F               USON2x3       76c/3k      0x66+0x99
    
    
    SST      16Mbit     SST26VF016B              SO8           1.28/3k          ok 5.8, (fails 5.5)
    

    Added: one older part, which would exclude itself on price alone, also excludes on failing to specify 100% 1-bit exit coverage.
    Wait..SST26VF016B Data is contradictory, digging further it does have a XIP M4 confirmation bit, so 0xff should exit QuadMode, using just DIO0.
    "When M[7:0] is any value other than 0AXH, the device expects the next instruction initiated to be a command instruction. To reset/exit the Set Mode configuration, execute the Reset Quad I/O command, FFH. "


    Data sheet links:

    SiLabs:
    http://www.silabs.com/Support Documents/TechnicalDocs/EFM8BB1-DataSheet.pdf
    http://www.silabs.com/Support Documents/TechnicalDocs/EFM8BB3-DataSheet.pdf

    Nuvoton:
    http://www.nuvoton.com/hq/products/microcontrollers/8bit-8051-mcus/low-pin-count-8051-series/Data-Sheet/?__locale=en&resourcePage=Y

    SyncMOS:
    http://www.syncmos.com.tw/products_file/ISSFD-M065_G_SM39R16A3-Datasheet(EN).pdf
    http://www.syncmos.com.tw/paper_file/ISSFA-0249_I_SyncMos-Products-Selection Guide(EN).pdf

    Addit: Handshake and AutoBAUD notes
    Most MCUs have calibrated Osc, but the value varies 16MHz / 22.1184Mhz / 24.5MHz
    The P2 defaults at roughly 20MHz during boot.

    A single-bit pulse from P2 is all that is needed to wakeup and Echo, but that may constrain later baud choices.

    Better may be Two chars adjacent eg 0xfe x 2, will allow a choice of Hi-Time capture, (8 Baud times), or inter-char time, 10 baud times. Two bits low, is highly baud-deviation tolerant, & 2 chars gives enough time to measure each sides clocks with reasonable precision.

    Default phase 1 boot would be 115200 or 57600 region, but supporting a gear-change once PLL is enabled, gives more choices.

    eg P2 sends 0xfe,0xfe, and waits. 1-Wire echos 0x55* (or whatever P2 expects as AutoBaud char) on second 0xfe, and the baud can be derived from that interchange.

    P2 side, 20M is /174 for 115200, for appx 0.57% baud granularity.

    PLL of 80M supports ~800k with 1% Baud granularity, or higher with NCO Fractional Baud links.
    1.38MHz seems a reasonable PLL baud speed ?

    * Expanding : A first fixed char of 0xfe gives a nice 8b high pulse, for possible timing, and a 10b Char interspace.
    The second byte does not have to be 0xfe, it can be maybe 0xff..0xfc, for some degree of mode flip.
    eg Baud-speed change, or 1-wire pgm from P2, are possible.

    --- P2 Crystal-less designs, with better precision

    P2 Osc Cal options: A 2 char One-Pin serial trigger can resolve to
    (1/50M)/(10/115200) = 230ppm /SysCLK
    (1/24.5M)/(10/115200) = 470ppm /SysClk 10 sysclks is ~0.5%
    Measurement precision is good, meaning scope is there to Calibrate the P2 20MHz against MCU CalOsc, for crystal-less designs, if needed.
    Many MCUs can also CLKOUT, which allows the CalOsc to drive the PLL, to the CalOsc precision (added above)
  • Neat idea about the 1-pin loader. I think I see the light now.

    The way to get half-duplex/one-wire operation is to use slightly different textual commands that tell the loader to use pin 63, instead of pin 62 as a serial output for response.
  • jmgjmg Posts: 14,563
    cgracey wrote: »
    Neat idea about the 1-pin loader. I think I see the light now.

    The way to get half-duplex/one-wire operation is to use slightly different textual commands that tell the loader to use pin 63, instead of pin 62 as a serial output for response.
    Sounds cool, I figured it would be something that could be configured outside of the Serial Loader, allowing code-share.
    Some small checks on timing would be needed to ensure the reply does not arrive on top of an incomming char, & enough turn-around time is allowed for.

  • Another option...
    Use EEPROM 24C32 (4KB) or 24C64(8KB). These are now available in SOT23-5 and WSC4 (4pin BGA 0.8mm square) and TSSOP8 (8pin 0.65mm pitch).
    Pricing from 0.19c upwards. These are pin/software compatible with 24C256 and 24C512.

    OnSemi make these too, so perhaps Parallax could get a good deal on them with the P2.

    Some of the SOT23-5 and WSC4 are new releases. There is also DFN8 parts too.
  • jmgjmg Posts: 14,563
    Cluso99 wrote: »
    Another option...
    Use EEPROM 24C32 (4KB) or 24C64(8KB). These are now available in SOT23-5 and WSC4 (4pin BGA 0.8mm square) and TSSOP8 (8pin 0.65mm pitch).
    Pricing from 0.19c upwards. These are pin/software compatible with 24C256 and 24C512.

    Yes, that gives a 2-pin choice, I've added that to the tree.

    This adds i2cLoad code, and requires more code space for i2c layer, so it may be down to a ROM size question.

  • This seems really complicated. :/
  • jmgjmg Posts: 14,563
    Roy Eltham wrote: »
    This seems really complicated. :/

    Complicated ? - Only to those who have never seen an elseif .. ;)
    It's actually quite a simple, fall-thru tree, if you read it carefully.


  • lol, you are funny.
  • jmgjmg Posts: 14,563
    Roy Eltham wrote: »
    lol, you are funny.
    I wasn't sure you were being serious, given it is as simple as counting 1-2-3-4.

    It is a simple reflection of the way users may expect to use Prop2.

    Some will want lowest-pin-cost Boot, perhaps to a USB loader, others will want fastest Memory bandwidth, and still others may want Serial-only operation. Many will be content with 3 Pin SPI.
    All can be quite simply covered.

    Optional to me are i2c and SD, but that's likely more from ROM-Space effects.
  • jmg wrote: »
    Roy Eltham wrote: »
    lol, you are funny.
    I wasn't sure you were being serious, given it is as simple as counting 1-2-3-4.

    It is a simple reflection of the way users may expect to use Prop2.

    Some will want lowest-pin-cost Boot, perhaps to a USB loader, others will want fastest Memory bandwidth, and still others may want Serial-only operation. Many will be content with 3 Pin SPI.
    All can be quite simply covered.

    Optional to me are i2c and SD, but that's likely more from ROM-Space effects.

    For the next FPGA release, I'm going to have just serial and 3-wire SPI flash support. It's easiest for now. This whole boot matter could take a lot of development time to do right. What I have now is working and solid.
  • jmg,
    You can claim all you want that it's simple. You are clearly glossing over many things and making many assumptions. Your scheme cannot be made 100% bullet proof. Especially in a reasonable time frame. This is unsafe to put into a boot ROM of a LONG lifetime MCU.

    No vender supports QSPI the same way, even within their own products. Even if Chip did work out all the various things that need to be done to reset all the current chips, next week some vender will come out with yet another new way. This is something that should be in software not hardware or the fixed ROM.

    You proposal is much more complex than what Chip already has working. It IS complicated compared to what Chip wants to do.

    But what do I know, you seem to think I'm an idiot that doesn't understand elseif chains or can't read your posts.
  • Respect please.
  • I appreciate your doggedness, jmg. Much of your input has gone into this project.

    We'll see about the boot tree. For now, I've got what I described all working. One thing I'd like to add is the half-duplex serial. I think if a "*" follows a command, I can key off that and go half-duplex.
  • I think we're at risk of overlooking perhaps the most important two details at this moment.

    1. Chip has the responsibility of making design decisions around the P2, whether they are right or wrong, ideal or not. While we all get to be involved and see this chip get made, he needs to follow his instincts and come up with the right approach. Make decisions, Chip! jmg has made many useful contributions and will hopefully continue to do so.

    2. The project needs to be finished. This is an overriding consideration. Usually, at the end of a design process, we're removing specifications instead of adding them in order to meet the release schedule. I'm not involved in any real deep engineering like the P2, but it's still clear to me that any engineering vision must also be financially productive. To me, this seems like something new again.

    Ken Gracey
  • jmgjmg Posts: 14,563
    edited 2016-09-25 - 20:44:34
    Ken Gracey wrote: »
    1. Chip has the responsibility of making design decisions around the P2, whether they are right or wrong, ideal or not. While we all get to be involved and see this chip get made, he needs to follow his instincts and come up with the right approach.

    Of course, but Chip cannot be everywhere. Some of the coverage stuff can be looked at by others, and is.

    Ken Gracey wrote: »
    ... I'm not involved in any real deep engineering like the P2, but it's still clear to me that any engineering vision must also be financially productive. To me, this seems like something new again.

    This is not really 'new', but it certainly is focused on end markets and P2 adoption.

    The P2 already has a Boot Decision tree, just a very limited one.
    Certainly one worth testing as-is, as Chip proposed above.

    The Boot tree here, simply takes what users will reasonably expect, and applies that to the code Chip has already developed.

    It is really the just interface between the real world, and the core boot code.
    It uses simple, Physical connected tests to determine what the user actually has connected.

    The core code already supports both SPI and Serial, and that code is easily shared (as Chip has mentioned, Serial is already essentially half duplex)

    i2c and SD are more optional, but they have been suggested by others, so I added those.
    (Some are working on SD code, so I think that should at least have a place-keeper in the ROM.)

    One-Pin boot is a simple pin-remap variant of the existing Serial Loader.
    It is easily and quickly 'Are you connected' tested. No => Simple continue to next Connected test.

    Likewise, 3P and 4P SPI, are pin-remap's of the same SPI code, with the same preambles.
    What they allow, is a clean means to connect a QuadSPI part, in Quad mode, for User-code to use Quad.

    A critical shortcoming of the 3P only Boot, is that excludes QuadSPI, and to me P2 QuadSPI use, is commercially significant.
    Note the ESP8266 can support QuadSPI flash devices. Users will expect this in P2.


    I am less worried about corner cases, than about supporting the mainstream QuadSPI parts, and those most likely to be used by P2 customers are the ones I've focused on.

    It is quite common for MCU vendors to give a list of compatible and tested parts, and the code I document above is enough for most designer to check if their new (not listed) QuadSPI part, should work.

    Most will choose the 'most-available and cheapest larger than P2 image Flash' .
    ( & it will certainly be QSPI capable) Those I believe I have covered.
    Roy Eltham wrote: »
    No vender supports QSPI the same way, even within their own products. Even if Chip did work out all the various things that need to be done to reset all the current chips, next week some vender will come out with yet another new way. This is something that should be in software not hardware or the fixed ROM.
    ... and yet ESP8266 manages what you claim is 'too difficult' for ROM ?
    (Note that the present 3Pin proposal, excludes even your 'should be in software', without consuming more pins, or bumping the BOM - Reality: some band-aids cannot be applied later )

    Sure, reset varies, but I have already included above, common reset preambles, tested by others.
    Chip does not need to 'work this out'.

    As for future divergence fears, my reading of data clearly differs from yours. I see a trend to a more common reset scheme, not any divergence. (very) older parts tend to not document this. Newer ones do.


  • jmgjmg Posts: 14,563
    edited 2016-09-25 - 20:43:52
    cgracey wrote: »
    We'll see about the boot tree. For now, I've got what I described all working. One thing I'd like to add is the half-duplex serial. I think if a "*" follows a command, I can key off that and go half-duplex.
    Sounds good.
    A small MCU can do pretty much anything, "*" is easy.

    I used an Echo-Response variant above, as that allows smallest pin impact (just 1 pin), and fastest Skip
    - it is done before the SPI code, and uses one SPI pin for the half-duplex.

    I guess if you use one SPI pin for the currently included Skip-SPI-Boot tree decision, and then use Standard Serial RX, that costs 2 pins, which is better than what we have now.

    Maybe the MCU can drive that Skip-SPI Boot, to give something less that a totally lost pin.
    If that Skip-SPI Boot pin is pulsed briefly, as part of the Skip-test, the MCU can even be ready with a command, for fastest loading.

    Addit: If you include the software reset preambles above, even in 3 Pin mode, that allows some testing of QSPI parts on real P2 boards. No flow changes, or new Tree branches needed :)

    Users can deliberately place the parts into quad/dual/power down modes, then reboot, and check what happens.
    For a part not in Quad mode, the preambles are merely redundant.
  • Without taking anything away from Ken's reality check, here are some other "out there" suggestions. Something may just "gel" from this???

    1. I don't like the requirement of external parts. As I intend to always have SD on my designs, this is the reason for wanting direct boot from SD. A socket is ~35c and 8GB microSD <$4.

    2. If a FLASH chip must be used, then a small package is a priority. QSPI connection layout is a preference, even if the boot code does not use it, hence the pin out suggestions of D0:D3 on P56:P59, CLK on P60, /CS on P61. This also works for SD (and allows for the fast mode later).

    3. P62:P63 are SO:SI (TXD:RXD)

    Now for some "out there" thinking...

    * As I suggested, cheap I2C EEPROMs are available in tiny packages (smaller to same as P1). Perhaps they could co- exist with SPI/QSPI or SD - need to think about the hardware as I currently share P1I2C pins.

    * A cheap micro has been suggested as containing the boot code. While I don't like another brand (and code) micro on my board, I considered this years ago on P1.

    There are really cheap micros out there with reasonable FLASH and USB. Maybe this is an avenue to sell a pre-programmed (or partially programmed) micro. Maybe this is for another thread topic to find an appropriate micro? This could make a simple loader and minimal pin count booter.
  • jmg,
    unsafe != too difficult.

    Also, I'd be careful saying the ESP8266 has it solved.

    Ken,
    We are in 1000% agreement.

  • Roy Eltham wrote: »
    jmg,
    unsafe != too difficult.

    Also, I'd be careful saying the ESP8266 has it solved.

    Ken,
    We are in 1000% agreement.
    It may very well be that the ESP8266 limits the chips that can be used. Many ESP8266s are sold as modules with an onboard flash chip.
  • jmgjmg Posts: 14,563
    Roy Eltham wrote: »
    Also, I'd be careful saying the ESP8266 has it solved.
    Oh, I am sure their support comes with caveats, but the vital detail is they do support it.
    The path you advocate, excludes it. - Which rather contradicts Ken's "any engineering vision must also be financially productive."
    David Betz wrote: »
    It may very well be that the ESP8266 limits the chips that can be used. Many ESP8266s are sold as modules with an onboard flash chip.
    Yup, exactly. See above note.
  • Regarding QPI, I don't think trading 3 pins for what will most likely be an imperceptible decrease in boot time for most projects is a good idea. Keeping the door open for SD cards would be way more important.
  • jmgjmg Posts: 14,563
    Some general comments :
    Cluso99 wrote: »
    1. I don't like the requirement of external parts. As I intend to always have SD on my designs, this is the reason for wanting direct boot from SD. A socket is ~35c and 8GB microSD <$4.

    I have also seen web blogs, around reflow mounting of (micro?) SD Cards, so they are trending to become 'just another part'.
    Cluso99 wrote: »
    * As I suggested, cheap I2C EEPROMs are available in tiny packages (smaller to same as P1). Perhaps they could co- exist with SPI/QSPI or SD - need to think about the hardware as I currently share P1I2C pins.
    Do you mean someone would connect to both i2c and Flash, on common pins ?
    I was expecting an either/or usage in the above decision tree, which I sequence test-connect based on Pin-Count order.
    That means i2c is presence tested, after 1-Pin, but before 3-Pin SPI.
    Cluso99 wrote: »
    * A cheap micro has been suggested as containing the boot code. While I don't like another brand (and code) micro on my board, I considered this years ago on P1.

    Agreed, it is a little more admin, but I see it as a solution for those who really want 1-Pin boot, and they will take a little more effort to get that. The One-Pin code is going to be small, and stable.
    I've done a proof of concept here, that comes in at just 20 bytes to Stream-Out, and ~53 bytes including Serial/Clk Inits.

    Cluso99 wrote: »
    There are really cheap micros out there with reasonable FLASH and USB. Maybe this is an avenue to sell a pre-programmed (or partially programmed) micro. Maybe this is for another thread topic to find an appropriate micro? This could make a simple loader and minimal pin count booter.
    Sure, once the Simplex Serial option is in there, there are plenty of options for what goes into that Micro.
    It can also connect to SPI Flash, allowing 1-pin SPI booting, for example.

    I have tried to allow for Baud-rate changes in the 1-Pin link, as first-boot is from 20MHz, low spec Osc, but later links can be PLL, higher accuracy allowing quite a boost in Baud. A choice of 2 seems simplest. Boot ROM needs only work on one.




  • cgracey wrote: »
    Regarding QPI, I don't think trading 3 pins for what will most likely be an imperceptible decrease in boot time for most projects is a good idea. Keeping the door open for SD cards would be way more important.
    Can the SD card share the same pins as the SPI boot flash if you tie DI to DO as you've been suggesting?

  • jmgjmg Posts: 14,563
    cgracey wrote: »
    Regarding QPI, I don't think trading 3 pins for what will most likely be an imperceptible decrease in boot time for most projects is a good idea. Keeping the door open for SD cards would be way more important.
    The QSPI parts are used for much more than just boot, there are image, font, and XIP uses all out there, waiting for user code...
    In that sense, the larger QSPI Flash parts, are very similar to SD, as they will have a lot more than just a 1-page P2 code image.


  • jmg wrote: »
    cgracey wrote: »
    Regarding QPI, I don't think trading 3 pins for what will most likely be an imperceptible decrease in boot time for most projects is a good idea. Keeping the door open for SD cards would be way more important.
    The QSPI parts are used for much more than just boot, there are image, font, and XIP uses all out there, waiting for user code...
    In that sense, the larger QSPI Flash parts, are very similar to SD, as they will have a lot more than just a 1-page P2 code image.

    Is XIP even possible on the P2? One could create an XMM mode but it would have to use LMM and not hubexec.

  • jmg,
    I think you are taking my support of what Chip wants to do as me only wanting that. I personally would be fine with 4 pin mode being used, but still only doing what Chip has done so far in the ROM code. The only difference from Chips plan, is that Chip feels 3 pin mode discourages people using QPI mode more. So, they won't get into bad states which require power cycling to recover. 4 pin mode allows for people to do QPI if they want, and they have to deal with the reset situations themselves if they have the flash in QPI mode and a reset happens.

    It's less than ideal, but it works reliably for SPI, and is essentially done. We can get a chip made with it and people can start using it. Later in the P2 family we can have more flushed out ROM code that handles more including QSPI recover, SD card, etc.

  • jmgjmg Posts: 14,563
    cgracey wrote: »
    ... Keeping the door open for SD cards would be way more important.

    Even if you could connect SD SDI to SDO (which I would be wary of..), I find this on SE, re SDIO modes...

    ["An SD card comes up by default in 1-bit SD mode, but can be changed into 4-bit mode after startup. If necessary, the card can also be switched into SPI mode, which is always 1-bit wide. The bus width in SD mode can be anywhere from 1 to 4-bits (see 6.2.1). There isn't any 8-bit SD mode, because there aren't enough pins on the SD card to support it. There is an 8-bit SD mode for MMC (MultiMediaCard) cards which have more pins.

    I don't see where anyone would want to run in SD mode with less than four data lines, unless they were limited for I/O lines. So let's forget about that."]


    To me that says you do need to cover Quad-mode-exit commands, in order to support SD-Boot, and you get QuadSPI mode for free then.
  • jmgjmg Posts: 14,563
    David Betz wrote: »
    Is XIP even possible on the P2? One could create an XMM mode but it would have to use LMM and not hubexec.
    I'm sure many variants will be designed, that keep some code in Flash, and run as needed.

    I'd expect most to use some sort of cache read, mainly because of the overhead of an address-change in SPI.

    For this, I would expect a dual-focus of developers supporting both HyperRAM/HyperFLASH, for top performance, and QuadSPI for mid-level performance.

    16MB QuadSPI parts are sub 20c, and that is already much larger than P2 RAM, so many will start thinking about how they can best get at that memory, just sitting there....


  • jmg wrote: »
    David Betz wrote: »
    Is XIP even possible on the P2? One could create an XMM mode but it would have to use LMM and not hubexec.
    I'm sure many variants will be designed, that keep some code in Flash, and run as needed.

    I'd expect most to use some sort of cache read, mainly because of the overhead of an address-change in SPI.

    For this, I would expect a dual-focus of developers supporting both HyperRAM/HyperFLASH, for top performance, and QuadSPI for mid-level performance.

    16MB QuadSPI parts are sub 20c, and that is already much larger than P2 RAM, so many will start thinking about how they can best get at that memory, just sitting there....

    But you can't execute code directly from flash. You can't even execute it from a cache since that would require address remapping. Seems like the best you could do is some sort of XMM with a cache. Of course, you can certainly do overlays but that's not XIP.

  • jmgjmg Posts: 14,563
    Roy Eltham wrote: »
    I think you are taking my support of what Chip wants to do as me only wanting that. I personally would be fine with 4 pin mode being used, but still only doing what Chip has done so far in the ROM code.

    That last bit, is where the fish-hooks lie.....
    Roy Eltham wrote: »
    The only difference from Chips plan, is that Chip feels 3 pin mode discourages people using QPI mode more. So, they won't get into bad states which require power cycling to recover. 4 pin mode allows for people to do QPI if they want, and they have to deal with the reset situations themselves if they have the flash in QPI mode and a reset happens.
    Only you can't actually kick the can down the road, as you advocate.

    "deal with the reset situations themselves" is easy to say, but the reality is, you cannot fix later in SW, what you cannot boot from!!

    Quad exists already in the real world, users will expect it, and the part I find hardest to comprehend here is, adding the Quad reset preambles is not rocket science!!.
    Peter tested some, in less time than it took me to type this. Quite the opposite of 'complicated', or 'unsafe'.




Sign In or Register to comment.