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?
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.
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)
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 ?
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.
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.
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.
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.
...
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):
Andy
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.
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.
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'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.
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.
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
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
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.
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?
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?
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.
Comments
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?
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.
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.
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)
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 ?
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.
* 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.
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.
I think the various boot connections look like that (in addition to serial boot):
Andy
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
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.
Agreed, which is what the improved streamer-focus pin-out delivers. Users can boot, then use their streamer-size-of-choice.
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...
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.
If not, I'll just put a loader into one of the boot options that does those things and call it good.
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!
If we're not getting votes, then I vote for KISS.
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
I know. I still prefer KISS.
This sounds perfect.
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.
No. I'm just biting off what I can chew, for now.
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.