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

1246

Comments

  • dMajo,

    Thanks! I read through your Excel sheet and I think I understand it. Somewhat, anyway.

    What you are saying is that 446 bytes (111 longs) will be available in the MBR as executable PASM instructions. And that code will be sufficient to finish booting the application stored in the SD card. It may need to use some subroutines from my ROM code.

    The way SPI flash works now is that I load the first 256 longs right into cog registers $000..$0FF and if they look correct and serial does not preempt things, I just do a 'JMP #0' to execute them.

    You are saying we could do the same with SD card, but load in 128 longs at an initial 2-byte offset into the low cog registers ($000..$07F, +1 for 2 extra bytes). That would keep the MBR data long-aligned and we would have our PASM instructions identically aligned. And the enveloped 111 longs of PASM code would be sufficient to evaluate the MBR data (within nearby cog registers) and finish the loading process. Is that right?

    So, if that will be sufficient, I just need to know what steps to are needed to get that data out of the SD card. I know there is some initialization sequencing, like Cluso99 was talking about, and then I must give some command to start reading. Well, probably a few commands before that to make sure the SD card is not busy and is in the proper mode to give us that data, right?
  • cgraceycgracey Posts: 8,306
    edited November 5 Vote Up0Vote Down
    jmg wrote: »
    cgracey wrote: »
    Here is "THE PINOUT" for memory booting.

    Can you expand that pinout, to include the streamer-compatible pins for QuadSPI and OctaSPI ?

    Can you also give the tests applied, Pin/jumper straps used, shortest possible times taken, & timeouts, for each of
    * Serial UART boot, one pin
    * Serial UART boot, two pin
    * SPI memory boot
    * SD Card boot
    * Whatever applies after all 3 were tried..

    The ideal for users, is very fast skip of undesired stages, and minimal pin impact, on any unused/skipped pins.

    To be streamer-compatible, QuadSPI could use any set of 4 pins which are nibble-aligned (%xxxx00..%xxxx11). OctaSPI could use any set of 8 pins which are byte-aligned (%xxx000..%xxx111). The user would need to connect his 4 or 8 data pins accordingly, aside from the initial DO/DI pins being connected to P59/P58.

    At first P61 (CS) is checked for a pull-up. If there's no pull-up, serial is tried for one minute before powering down. If there is a pull-up and the data loads okay, it is immediately executed if P60 (CLK) also has a pull-up; otherwise serial is given a 100ms window of opportunity before the loaded flash/SD code is executed.

    I think determining whether we have good code in either SPI flash or SD card will take 5ms, total, barring any delays from the SD card state machine.

    It would be good to have a test to determine if, indeed, an SD card is actually present before we spend several ms trying to load from it. I check to see if a SPI flash is connected before bothering to load from it. The P61 (CS) pull-up just asks us to see what's there.
  • cgracey wrote: »
    Cluso99 wrote: »
    Chip,
    Can we use the SmartPins in a really basic way?

    I ask because I wonder if we can use the smartpins to reorder the data pins?
    They have a reach of +/-3 pins.

    Whoa! Yes, you can use them to reorder inputs, but not outputs.

    Hadn't thought about the fact that the outputs are fixed. Not going to work then :(

    I guess this means we cannot use SmartPins for Octal SPI, or DRAM ???

    I haven't been really following the SmartPins capabilities.

    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)
  • cgracey wrote: »
    To be streamer-compatible, QuadSPI could use any set of 4 pins which are nibble-aligned (%xxxx00..%xxxx11). OctaSPI could use any set of 8 pins which are byte-aligned (%xxx000..%xxx111). The user would need to connect his 4 or 8 data pins accordingly, aside from the initial DO/DI pins being connected to P59/P58.

    Can you give some examples, of QuadSPI and Octal SPI wiring connections, that would work with Streamer ?
    I think you are saying two extra pins are needed, wired in parallel ? (costs 8 pins for Quad, and 12 pins for octal)

    cgracey wrote: »
    At first P61 (CS) is checked for a pull-up. If there's no pull-up, serial is tried for one minute before powering down. If there is a pull-up and the data loads okay, it is immediately executed if P60 (CLK) also has a pull-up; otherwise serial is given a 100ms window of opportunity before the loaded flash/SD code is executed.

    That sounds like immediate UART load is possible by removal of that pullup, and that could be handshake controlled, from the host - (eg connect pullup R to one of RTS/DTR, instead of Vdd, and handshake low forces serial instead of SPI)

    For someone with a bad-SPI load, knowing when the 'window of opportunity' is open is not going to be so easy, as they do not know when SPI attempt started (ie reset exit is invisible).
    With no RX yet, the booter also cannot send a failed-spi-load char....

    Maybe the SPI_CS can wire to another uart signal, to allow polling for SPI phase ?
  • Cluso99 wrote: »
    I guess this means we cannot use SmartPins for Octal SPI, or DRAM ???

    I think they can be used, for all of Quad and Octal, but it costs more pins than you/users might expect.
    DRAM hopefully can be supported, including DTR, that depends on the Streamer and a separate clock pin timing and interaction.


  • To test if an SD Card is present, and at least working to some extent, this is the sequence that produces the first card response...

    * Wait >1ms (after power settles - I presume the P2 will have spent this delay in configuring and loading the ROM.
    * send >74 Clocks at < 400KHz (I use 96 clocks at 100KHz IIRC)
    * short delay (currently 1ms)
    * Send Command 0 (7 bytes), wait for reply (1-9 bytes); slight delay if no reply and retry > 9 times
    * If we get a reply, even if it's an error, we know if there is a card present.

    I am doing the ROM code, then I will do the SD MBR code. Then I will know whether it will fit into the 111 longs in the MBR.
    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: »
    To test if an SD Card is present, and at least working to some extent, this is the sequence that produces the first card response...

    * Wait >1ms (after power settles - I presume the P2 will have spent this delay in configuring and loading the ROM.
    * send >74 Clocks at < 400KHz (I use 96 clocks at 100KHz IIRC)
    * short delay (currently 1ms)
    * Send Command 0 (7 bytes), wait for reply (1-9 bytes); slight delay if no reply and retry > 9 times
    * If we get a reply, even if it's an error, we know if there is a card present.

    I am doing the ROM code, then I will do the SD MBR code. Then I will know whether it will fit into the 111 longs in the MBR.

    Super, Cluso99!

    I think this is going to be great.
  • I hope there is a plan for a method/system to write the MBR boot code along with the user binary to the SD card from the P2. So we can have a similar workflow to the P1 now, where you can send your binary to the P1 over serial and it will program the eeprom so that it can boot your code.
    This, of course, doesn't need to go in the ROM, since it can be pushed over serial in front of the binary to be written. It just needs to be planned for and written, probably, along side what you are doing now.
  • Roy Eltham wrote: »
    I hope there is a plan for a method/system to write the MBR boot code along with the user binary to the SD card from the P2. So we can have a similar workflow to the P1 now, where you can send your binary to the P1 over serial and it will program the eeprom so that it can boot your code.
    This, of course, doesn't need to go in the ROM, since it can be pushed over serial in front of the binary to be written. It just needs to be planned for and written, probably, along side what you are doing now.

    Yes, it must work this way. Fortunately, the booter doesn't need to worry about how all that happens. It just needs to get the initial data out.
  • jmg wrote: »
    ...
    Can you give some examples, of QuadSPI and Octal SPI wiring connections, that would work with Streamer ?
    I think you are saying two extra pins are needed, wired in parallel ? (costs 8 pins for Quad, and 12 pins for octal)
    ...

    I think the various boot connections look like that (in addition to serial boot):
    FlashConn5.png
    Andy
    627 x 437 - 20K
  • That looks right, Andy.
  • jmgjmg Posts: 10,611
    edited November 5 Vote Up0Vote Down
    Ariba wrote: »
    I think the various boot connections look like that (in addition to serial boot):
    Yes, that's my understanding.

    If we label Streamer Hardware compatible, as .HW, & Software bit-manage as .SW, then
    * first connection is both Dual.HW & Dual.SW (can be used with either SW or Streamer)
    * last two are Quad.HW & Octal.HW
    * There are two more possible connections, Quad.SW and Octal.SW, that do not use bridged pins.

    That's a lot of combinations, all with differing software compatibility, and as well as losing two pins by simple bridging, it also spawns a couple of orphan pins at P56,P57

    To me it is better to focus on the Streamer first, as that is high performance hardware users WILL want to use

    Doing that, produces this
    Streamer Compatible BOOT Pin-out (top down allocated)
    
    P63   D7
    P62   D6
    P61   D5
    P60   D4
    P59   D3
    P58   D2
    P57   D1
    P56   D0     Data path, Streamer aligned, for Single/Dual/Quad/Octal
    P55   RXD   <- Single pin Serial Load     -or-   P55   CSn   <- SPI/SD
    P54   TXD   <- Duplex Serial Load                P54   CLK   <- SPI/SD
    P53   CSn   <- SPI/SD                            P53   TXD   <- Duplex Serial Load 
    P52   CLK   <- SPI/SD                            P52   RXD   <- Single pin Serial Load
    

    Plenty of advantages :

    * Compared with above, the maximum pin cost is 12 pins for octal/uart, no orphans, vs 16 pins cost (2 orphans).
    * It is also much easier to explain, with no saying ".SW .HW variants, where .SW saves pins, but is slower"

    * Serial-only load designs, leaves a whole byte unconnected, which is still a useful and streamer compatible block.

    * Quad connected SPI, streamer compatible PCBs are encouraged in this pinout, which gives the best performance for mainstream low cost memory.

    * Octal is easy and natural to add, as that memory will ramp in volume over time.

    Other MCUs will be slow to support OctalSPI, P2 can catch this wave nicely.

    Variant with RXD,TXD moved down, group SPI pins together for easier PCB layout, and helps separate the 'hot' spi CLK from possible analog user pins. Single pin serial load, here gives 11 contiguous spare pins.
  • TonyB_TonyB_ Posts: 245
    edited November 5 Vote Up0Vote Down
    The maximum possible simplicity and ease of use after booting is what users will be looking for and the boot pins should be chosen to give them that.
    Formerly known as TonyB
  • TonyB_ wrote: »
    The maximum possible simplicity and ease of use after booting is what users will be looking for and the boot pins should be chosen to give them that.

    Agreed, which is what the improved streamer-focus pin-out delivers. Users can boot, then use their streamer-size-of-choice.

  • SD SPI Boot Code

    Shortly I will be posting test code on the P1 forum for users to try. I would like to try as many SD cards as possible.

    My code currently is for P1 instructions and uses CNT, DIRA, OUTA, INA, and I use PAR for debugging to two other cogs.

    FWIW Here are some timing figures using P1 (96MHz) reading CSD & CID registers and Sectors 0 & 1...
    (There are some debug instructions included)

    1GB microSD Card SD-C01G JAPAN (no brand name - came with an old phone)
    Initial Boot 25ms
    Second Boot 17ms

    8GB microSD Card SDHC C4 SanDisk
    Initial Boot 83ms
    Second Boot 17ms


    8GB microSD Card SDHC U1 TOHAOLL MIXZA (Taiwan) bought cheap on eBay
    Initial Boot 166ms
    Second Boot 9ms

    64GB microSD Card SDXC C10 U1 OU (Korea) bought cheapon eBay
    Initial Boot 44ms
    Second Boot 8ms

    This is the debug info produced...
    SD testing v110b
    SD card type: 3 = SDHC/SD V2(block)  (passed)
    4404: CS1 CLK0 ;
    4408: CS1 CLK0 ;
    4410: CS1 CLK0 ;
    4418: ;
    441C: CS1 CLK0  0 00000040 00000000 00000095 CS0 CLK0 0000003F ;
    443C: CS1 CLK0  0 00000040 00000000 00000095 CS0 CLK0 000000FF (1) 000000C1 ;
    4468: CS1 CLK0  0 00000040 00000000 00000095 CS0 CLK0 000000FF (1) 00000001 ;
    4494: CS1 CLK0  8 00000048 000001AA 00000087 CS0 CLK0 000000FF (1) 00000001 000001AA ;
    44C4: CS1 CLK0 55 00000077 00000000 00000087 CS0 CLK0 000000FF (1) 00000001 ;
    44F0: CS0 CLK0 41 00000069 40000000 00000087 CS0 CLK0 000000FF (1) 00000000 (1125) (7253956 clocks) 75ms ;
    452C: CS1 CLK0 58 0000007A 00000000 00000087 CS0 CLK0 000000FF (1) 00000000 C0FF8000 ;
    455C: CS1 CLK0 16 00000050 00000200 00000087 CS0 CLK0 000000FF (1) 00000000 ;
    4588: CS1 CLK0  9 00000049 00000000 00000087 CS0 CLK0 000000FF (2) 00000000 000000FF (1) 000000FE ;
    45C4:      (16 bytes) CRC: 00000044 00000016 CS0 CLK0 CS1 CLK0 ;
    45DC: CS1 CLK0 10 0000004A 00000000 00000087 CS0 CLK0 000000FF (2) 00000000 000000FF (1) 000000FE ;
    4618:      (16 bytes) CRC: 000000AD 000000FD CS0 CLK0 CS1 CLK0 ;
    4630: CS1 CLK0 17 00000051 00000000 00000087 CS0 CLK0 000000FF (2) 00000000 000000FF (75) 000000FE ;
    466C:     (512 bytes) CRC: 0000002F 0000009B CS0 CLK0 CS1 CLK0 ;
    4684: CS1 CLK0 17 00000051 00000001 00000087 CS0 CLK0 000000FF (2) 00000000 000000FF (73) 000000FE ;
    46C0:     (512 bytes) CRC: 00000000 00000000 CS0 CLK0 CS1 CLK0 ;
    46D8: <eof>      (8003236 clocks) 83ms
    CSD register...
    0000: 40 0E 00 32 5B 59 00 00 3C DC 7F 80 0A 40 40 C5  @..2[Y..<....@@.
    CID register...
    0000: 03 53 44 53 55 30 38 47 80 20 9C 0B 27 00 7C 23  .SDSU08G. ..'.|#
    MBR/VBR sector 0 ...
    0000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    0020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    0030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    0040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    0050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    0060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    0070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    0080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    0090: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    00A0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    00B0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    00C0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    00D0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    00E0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    00F0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    0100: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    0110: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    0120: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    0130: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    0140: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    0150: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    0160: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    0170: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    0180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    0190: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    01A0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    01B0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 82  ................
    01C0: 03 00 0B 26 C5 E1 00 20 00 00 00 54 F3 00 00 00  ...&... ...T....
    01D0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    01E0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    01F0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 AA  ..............U.
    Valid MBR
    proposed use--> 01AE: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    PTN 0: Typ=$0B  01BE: 00 82 03 00 0B 26 C5 E1 00 20 00 00 00 54 F3 00  .....&... ...T..
    PTN 1: Typ=$00  01CE: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    PTN 2: Typ=$00  01DE: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    PTN 3: Typ=$00  01EE: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    VOL sector 1 ...
    0000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    0020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    0030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    0040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    0050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    0060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    0070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    0080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    0090: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    00A0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    00B0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    00C0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    00D0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    00E0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    00F0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    0100: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    0110: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    0120: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    0130: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    0140: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    0150: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    0160: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    0170: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    0180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    0190: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    01A0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    01B0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    01C0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    01D0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    01E0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    01F0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    
    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)
  • This is great, Cluso99.
  • ElectrodudeElectrodude Posts: 1,111
    edited November 8 Vote Up0Vote Down
    Why don't you have it load and run Tachyon bytecode out of the MBR, instead of relying on offsets remaining the same or putting a FAT-only driver in ROM? A single-byte Tachyon instruction to read a cluster from the SD card would probably save enough space to make it possible to fit in the MBR a Tachyon program capable of finding and loading a boot image.

    This would allow booting off of virtually any filesystem (e.g. ext2/3/4) or partition table type (e.g. GPT) without needing to put it in ROM, while allowing fragmented files and such.
  • potatoheadpotatohead Posts: 8,951
    edited November 9 Vote Up0Vote Down
    I'm just gonna watch with interest. If it all works, and respects, partitions, etc. Great!

    If not, I'll just put a loader into one of the boot options that does those things and call it good. :D

    Do not taunt Happy Fun Ball! @opengeekorg ---> Be Excellent To One Another SKYPE = acuity_doug
    Parallax colors simplified: http://forums.parallax.com/showthread.php?123709-Commented-Graphics_Demo.spin<br>
  • Peter JakackiPeter Jakacki Posts: 6,623
    edited November 9 Vote Up0Vote Down
    I've taken a back seat for now due to the lack of coordination I suppose and I am bringing Forth up on a variety of ARM cores. I don't want to waste my time at the moment working on a boot ROM version of Tachyon to find out that it was replaced with another last minute alternative. We can pick "a" direction and sail with it or just be blown about by the wind and hopefully get there (eventually).

    If Tachyon and SD drivers (and FAT32) are in ROM it means we can have direct loading of a named FAT32 file (drag and drop from any PC) and still have the option of loading a small Tachyon program from the MBR to read whatever. Best of both worlds, a sail, wind, and a motor!
    Tachyon Forth - compact, fast, forthwright and interactive
    useforthlogo-s.png
    Tachyon Forth News Blog
    TACHYON DEMONSTRATOR
    Brisbane, Australia
  • I've taken a back seat for now due to the lack of coordination I suppose and I am bringing Forth up on a variety of ARM cores. I don't want to waste my time at the moment working on a boot ROM version of Tachyon to find out that it was replaced with another last minute alternative. We can pick "a" direction and sail with it or just be blown about by the wind and hopefully get there (eventually).

    If Tachyon and SD drivers (and FAT32) are in ROM it means we can have direct loading of a named FAT32 file (drag and drop from any PC) and still have the option of loading a small Tachyon program from the MBR to read whatever. Best of both worlds, a sail, wind, and a motor!
    I vote for Tachyon in ROM! Of course, I don't really get a vote.

  • So, if you use a single pin for DI/DO
    David Betz wrote: »
    I've taken a back seat for now due to the lack of coordination I suppose and I am bringing Forth up on a variety of ARM cores. I don't want to waste my time at the moment working on a boot ROM version of Tachyon to find out that it was replaced with another last minute alternative. We can pick "a" direction and sail with it or just be blown about by the wind and hopefully get there (eventually).

    If Tachyon and SD drivers (and FAT32) are in ROM it means we can have direct loading of a named FAT32 file (drag and drop from any PC) and still have the option of loading a small Tachyon program from the MBR to read whatever. Best of both worlds, a sail, wind, and a motor!
    I vote for Tachyon in ROM! Of course, I don't really get a vote.

    If we're not getting votes, then I vote for KISS.
  • Seairth wrote: »
    So, if you use a single pin for DI/DO
    David Betz wrote: »
    I've taken a back seat for now due to the lack of coordination I suppose and I am bringing Forth up on a variety of ARM cores. I don't want to waste my time at the moment working on a boot ROM version of Tachyon to find out that it was replaced with another last minute alternative. We can pick "a" direction and sail with it or just be blown about by the wind and hopefully get there (eventually).

    If Tachyon and SD drivers (and FAT32) are in ROM it means we can have direct loading of a named FAT32 file (drag and drop from any PC) and still have the option of loading a small Tachyon program from the MBR to read whatever. Best of both worlds, a sail, wind, and a motor!
    I vote for Tachyon in ROM! Of course, I don't really get a vote.

    If we're not getting votes, then I vote for KISS.
    We already had KISS but that left 14k of ROM unused so we started talking about how to fill it up.
  • Why don't you have it load and run Tachyon bytecode out of the MBR, instead of relying on offsets remaining the same or putting a FAT-only driver in ROM? A single-byte Tachyon instruction to read a cluster from the SD card would probably save enough space to make it possible to fit in the MBR a Tachyon program capable of finding and loading a boot image.

    This would allow booting off of virtually any filesystem (e.g. ext2/3/4) or partition table type (e.g. GPT) without needing to put it in ROM, while allowing fragmented files and such.

    The boot ROM code will not know anything about the SD Card. It will just load some code from a sector(s) on the SD and use that to load more code. It will not know about Tachyon, Spin, or anything else, other than...

    1. Detect and Initialise an SD Card (microSD or full size) using SPI (/CS,CLK,DI,DO = 4pins)
    2. Determine if the SD (byte)/SDHC(byte/block)/SDHC(block)
    3. Read in sector(s) 0+ and extract P2 PASM code to continue

    The P2 PASM code on the SD/microSD card will be user programmable, so apart from a working sample, you are free to write your own. I am sure Peter will do a boot to Tachyon, and I will be doing my Prop OS.

    You decide how you want to run Partitions, Filesystems, or anything else you can think of. We are not locked into anything here. SDXC(block) supports up to 2TB currently. Provided anything newer that comes along has backward initialisation to read compatiblity, we are safe ;)

    Totally flexible :)

    Minimum risk :)

    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)
  • David Betz wrote: »
    Seairth wrote: »
    So, if you use a single pin for DI/DO
    David Betz wrote: »
    I've taken a back seat for now due to the lack of coordination I suppose and I am bringing Forth up on a variety of ARM cores. I don't want to waste my time at the moment working on a boot ROM version of Tachyon to find out that it was replaced with another last minute alternative. We can pick "a" direction and sail with it or just be blown about by the wind and hopefully get there (eventually).

    If Tachyon and SD drivers (and FAT32) are in ROM it means we can have direct loading of a named FAT32 file (drag and drop from any PC) and still have the option of loading a small Tachyon program from the MBR to read whatever. Best of both worlds, a sail, wind, and a motor!
    I vote for Tachyon in ROM! Of course, I don't really get a vote.

    If we're not getting votes, then I vote for KISS.
    We already had KISS but that left 14k of ROM unused so we started talking about how to fill it up.

    I know. I still prefer KISS.
  • Cluso99 wrote: »
    Why don't you have it load and run Tachyon bytecode out of the MBR, instead of relying on offsets remaining the same or putting a FAT-only driver in ROM? A single-byte Tachyon instruction to read a cluster from the SD card would probably save enough space to make it possible to fit in the MBR a Tachyon program capable of finding and loading a boot image.

    This would allow booting off of virtually any filesystem (e.g. ext2/3/4) or partition table type (e.g. GPT) without needing to put it in ROM, while allowing fragmented files and such.

    The boot ROM code will not know anything about the SD Card. It will just load some code from a sector(s) on the SD and use that to load more code. It will not know about Tachyon, Spin, or anything else, other than...

    1. Detect and Initialise an SD Card (microSD or full size) using SPI (/CS,CLK,DI,DO = 4pins)
    2. Determine if the SD (byte)/SDHC(byte/block)/SDHC(block)
    3. Read in sector(s) 0+ and extract P2 PASM code to continue

    The P2 PASM code on the SD/microSD card will be user programmable, so apart from a working sample, you are free to write your own. I am sure Peter will do a boot to Tachyon, and I will be doing my Prop OS.

    You decide how you want to run Partitions, Filesystems, or anything else you can think of. We are not locked into anything here. SDXC(block) supports up to 2TB currently. Provided anything newer that comes along has backward initialisation to read compatiblity, we are safe ;)

    Totally flexible :)

    Minimum risk :)

    This sounds perfect.
  • I think, since SD boot time is variable, we will need to attempt it AFTER the serial window of 100ms, or start it up in another cog at the start of the serial window.

    SPI flash takes a constant ~4ms, and it will receive priority.

    We could abort the serial window if SD loads okay and there's a pull-up on the clock. Then, we run the SD right away. Otherwise, if there's no serial, but SD loaded okay, we run it at the end of the serial window.
  • cgracey wrote: »
    Cluso99 wrote: »
    Why don't you have it load and run Tachyon bytecode out of the MBR, instead of relying on offsets remaining the same or putting a FAT-only driver in ROM? A single-byte Tachyon instruction to read a cluster from the SD card would probably save enough space to make it possible to fit in the MBR a Tachyon program capable of finding and loading a boot image.

    This would allow booting off of virtually any filesystem (e.g. ext2/3/4) or partition table type (e.g. GPT) without needing to put it in ROM, while allowing fragmented files and such.

    The boot ROM code will not know anything about the SD Card. It will just load some code from a sector(s) on the SD and use that to load more code. It will not know about Tachyon, Spin, or anything else, other than...

    1. Detect and Initialise an SD Card (microSD or full size) using SPI (/CS,CLK,DI,DO = 4pins)
    2. Determine if the SD (byte)/SDHC(byte/block)/SDHC(block)
    3. Read in sector(s) 0+ and extract P2 PASM code to continue

    The P2 PASM code on the SD/microSD card will be user programmable, so apart from a working sample, you are free to write your own. I am sure Peter will do a boot to Tachyon, and I will be doing my Prop OS.

    You decide how you want to run Partitions, Filesystems, or anything else you can think of. We are not locked into anything here. SDXC(block) supports up to 2TB currently. Provided anything newer that comes along has backward initialisation to read compatiblity, we are safe ;)

    Totally flexible :)

    Minimum risk :)

    This sounds perfect.
    So you've rejected the idea of putting a Tachyon monitor in the remaining 14K of the boot ROM?

  • David Betz wrote: »
    cgracey wrote: »
    Cluso99 wrote: »
    Why don't you have it load and run Tachyon bytecode out of the MBR, instead of relying on offsets remaining the same or putting a FAT-only driver in ROM? A single-byte Tachyon instruction to read a cluster from the SD card would probably save enough space to make it possible to fit in the MBR a Tachyon program capable of finding and loading a boot image.

    This would allow booting off of virtually any filesystem (e.g. ext2/3/4) or partition table type (e.g. GPT) without needing to put it in ROM, while allowing fragmented files and such.

    The boot ROM code will not know anything about the SD Card. It will just load some code from a sector(s) on the SD and use that to load more code. It will not know about Tachyon, Spin, or anything else, other than...

    1. Detect and Initialise an SD Card (microSD or full size) using SPI (/CS,CLK,DI,DO = 4pins)
    2. Determine if the SD (byte)/SDHC(byte/block)/SDHC(block)
    3. Read in sector(s) 0+ and extract P2 PASM code to continue

    The P2 PASM code on the SD/microSD card will be user programmable, so apart from a working sample, you are free to write your own. I am sure Peter will do a boot to Tachyon, and I will be doing my Prop OS.

    You decide how you want to run Partitions, Filesystems, or anything else you can think of. We are not locked into anything here. SDXC(block) supports up to 2TB currently. Provided anything newer that comes along has backward initialisation to read compatiblity, we are safe ;)

    Totally flexible :)

    Minimum risk :)

    This sounds perfect.
    So you've rejected the idea of putting a Tachyon monitor in the remaining 14K of the boot ROM?

    No. I'm just biting off what I can chew, for now.
  • Tachyon is much denser than PASM if the interpreter is in ROM (like everyone has been talking about). If the second-stage bootloader that gets loaded out of sector 0 is Tachyon bytecode rather than PASM, it will be able to do a lot more with the 466 bytes before the MBR partition table. Of course, the second-stage bootloader will normally coginit itself with the payload when it's done, regardless of whether it's written in Tachyon, PASM, or something else.

    What added risk is there? The SD block routines used by Tachyon would be the same PASM routines that would be used if Tachyon isn't used.
  • Peter, I'm sorry if my approach seems a little schizophrenic. I'm spread pretty thin right now. I'm working a lot with the layout people to try to get everything straightened up for the production silicon, while getting things in order for OnSemi's work, while trying to ESD test our last test chip and discovering my ESD generator seems to have busted while resting in its case for 12 years. My ability to think strategically is just down at the moment. It's all tactical, right now.
Sign In or Register to comment.