Porting FSRW SD Reading routines to P2: Now boots from SD!

kwinn

potatohead wrote: »

Yeah, that is what Chip told us. There is a little state machine that just blasts the contents of the ROM into RAM at boot.

I was thinking, since COG ID is where some chip configuration is done, like fuse access, etc, maybe it could also write mask that 16k for the "treat it like ROM" use case.

Ram copy is fine, but can get trashed pretty easy.

Having that 16K ram default to write protected at boot up and being able to change that after would be useful. A bit like the 8080/Z80 systems where an area of memory was paged to be eprom for booting and ram when desired.

Rayman

It's interesting to thing about...

One the one hand, it seems like a waste somehow to have SD reading routines on the chip that you can't get to.

On the other hand, you can just load up your own, customized, version after boot.

I have feeling that the ROM version of SD reading is going to be so crippled compared to what you could load later, that you would rarely want it...

potatohead

Another reason why block read write support might make the best sense for ROM.

Filesystems are tough, because partial support is often worse than no support.

Cluso99

IMHO supporting anything other than the absolute minimum is a waste.

After the initial booting sequence, then...
run the ROM SD routine that needs to:
* Initialise the SD card (mount)
* Read MBR and check for some identifier (Peters method)
* If found, read that data into hub/cog and run it
* Else, locate a file (fixed filename, say "bootp2.bin")
* Read that file into hub/cog and run it
* Else, run a monitor program (that also allows simple serial download protocol)

So, it needs to be able to
* initialise the SD card (mount)
* support read block (sector)
* support locating files 8.3 in FAT32

Do we need to bother with older formats FAT16 (or even FAT12)?
Do we need to bother with MMC cards?
Do we need to bother with previous SD types prior to SDHC/SDXC ?

The smallest and cheapest microSD card available at OfficeWorks in Australia is now the SanDisk SDHC 8GB Class 10. So is there any point is supporting anything older???

Cluso99

BTW my 8GB SanDisk SDHC is formatted as 32KB clusters. I think this is the norm and therefore any initial boot program would fit into this meaning no need to search for further clusters. ie the boot file would be contiguous which makes it simple.

Rayman

Dropping FAT16 support from the code I posted would reduce size a little.
Not a whole lot, but some. It would also make the code easier to understand.
On the other hand, you remove a limitation with just a bit of extra code...
I think I'd be OK with dropping FAT16 support.

I have an old 2GB FAT16 uSD I've been testing with.
I just checked and it looks like Windows10 will let me format it as FAT32, so could still use it...

Cluso99

Rayman wrote: »

Dropping FAT16 support from the code I posted would reduce size a little.
Not a whole lot, but some. It would also make the code easier to understand.
On the other hand, you remove a limitation with just a bit of extra code...
I think I'd be OK with dropping FAT16 support.

I have an old 2GB FAT16 uSD I've been testing with.
I just checked and it looks like Windows10 will let me format it as FAT32, so could still use it...

Yes I have been reformatting to FAT32 from 1GB onwards IIRC. Use 32KB Allocation Unit Size (2GB and below seem to default to 16KB while 8GB seem to default to 32KB) and we can ensure the whole 32KB file will be contiguous which will make the code simpler again.

Attached is my version of Kye's PASM section - I have been shrinking it and reorganising it a bit. Some of the variables can be remapped over the initialisation code.
I have added a document file that I made while following his code - it might be useful to you, or you might notice something incorrect.

Cluso99

Thinking a little deeper, the boot code will ultimately need to execute using the internal RC oscillator and Chip will need to decide which pins the SD card will be on - we can recommend this to him.

Tubular

It would probably share the same SPI lines as the SPI boot Flash, plus one pin lower for the Chip Select, I would think

Rayman

There can be an issue sharing MISO with SD... Sometimes it can get stuck outputting...

Think I've heard that clocking out a bunch of zeros can fix that though...

ozpropdev

On the subject of pin assignment I note that the current ROM_Booter.spin shows

  rx_pin = 63
  tx_pin = 62
  spi_cs = 61
  spi_ck = 60
  spi_di = 59
  spi_do = 58

and the current P123_A9 image has the buttons over lapping some of these pins

	pb0 = 56
	pb1 = 57
	pb2 =58
	pb3 = 59

An easy pin assignments tweak fixes this issue.

Cluso99

Rayman wrote: »

There can be an issue sharing MISO with SD... Sometimes it can get stuck outputting...

Think I've heard that clocking out a bunch of zeros can fix that though...

The problem was solved by sending out a number of clocks.

I share the pins on my RamBlades so I have resolved the issues.

Cluso99

ozpropdev wrote: »

On the subject of pin assignment I note that the current ROM_Booter.spin shows

  rx_pin = 63
  tx_pin = 62
  spi_cs = 61
  spi_ck = 60
  spi_di = 59
  spi_do = 58

and the current P123_A9 image has the buttons over lapping some of these pins

	pb0 = 56
	pb1 = 57
	pb2 =58
	pb3 = 59

An easy pin assignments tweak fixes this issue.

SD booting is for when there is no flash. So it would probably be reasonable to use the same pins as the flash. ie Either flash or SD, not both.

For the case of both, the flash will have code to drive the SD and it can be anywhere.

Otherwise, 57 could be SD CS and 56 some other CS.

jmg

Cluso99 wrote: »

SD booting is for when there is no flash. So it would probably be reasonable to use the same pins as the flash. ie Either flash or SD, not both.

There may be future patch cases, where you do want both.
i2c also tends to be cheaper, and smaller, in the smallest memory sizes, and is easy to do a presence-test on, so the most flexible BOOT order is then UART-Small Boot devices(i2c) - larger Boot devices(spi) - largest Boot devices.(SD)

Cluso99

jmg,
When you have flash, the SD can be anywhere because it will always boot from flash. Hence the boot code could look for sd on the flash pins.

jmg

Cluso99 wrote: »

jmg,
When you have flash, the SD can be anywhere because it will always boot from flash. Hence the boot code could look for sd on the flash pins.

Yes, but it makes sense to have one PCB artwork, that has build options with/without flash.

Rayman

This version uses the FAT table to see what clusters the boot file uses (instead of assuming that they are sequential).

Code still all fits in one cog! (but just barely)

The serial I/O routines are still there.

If I do anything else with this version, it will just be to remove the extraneous stuff and maybe clean it up a bit.

Coley

Rayman wrote: »

This version uses the FAT table to see what clusters the boot file uses (instead of assuming that they are sequential).

Code still all fits in one cog! (but just barely)

The serial I/O routines are still there.

If I do anything else with this version, it will just be to remove the extraneous stuff and maybe clean it up a bit.

Hi Ray,
How does this boot exactly?
How do you make the P2BOOT.BIN file?

I made a text file and renamed it P2BOOT.TXT and this is what I get from the serial console...

!0000000400000004Passed FAT block check (Last 2 bytes are $55AA)
Passed FAT block check (Last 2 bytes are $55AA)
Sector size confirmed to be 512 bytes

Two copies of FAT confirmed
P2P2BOOT BIN
Target file found !

Coley

Never mind, I've sorted it.
When you compile in PNUT the resultant .obj file is the binary

Baggers

Finally have a breakout SD card attached it to the Prop1-2-3 board and it works a treat

I think this ( or something similar i.e. minus serial output ) would be a great addition to the ROM for boot up.

Baggers

Great work Rayman as always!