For those who reply to 2.a) above "No pins are lost because you don't have to use it". This is not quite so. When I have my FLASH and SD free Prop II permanently attached to an ARM that programs and boots it via normal serial I do not want the Prop flailing pins around trying to find an SD to boot from when the ARM perhaps was not yet ready to provide reset and boot to the Prop. Those pins may be connected to something important.
In reference to Heater's (and others) comments about the P2 "wiggling" pins while finding a place to boot from, is there a way to select, specify, DEMAND a boot ONLY from TX/RX that will not wiggle any other pins? I could see this being useful to developers who wanted something completely different as far as pin assignments and is also in keeping with the Propeller underlying philosophy of soft peripherals and no dedicated pins. It may also be useful to boot device developers who may want to get some code running before "wiggling" any pins they are working with.
Can it be a FUSED option?
I know that some chips just rely on a data or clock line being passively pulled high or low to indicate on power up what type of boot config is in play.
For booting from a host CPU in your design, pull reset LOW and have your host CPU drive it HIGH when it's ready to load the prop.
For boot sequence, serial, flash, USB HID-Class. Why?
Serial has the fewest pin requirements and allows the most pins to be used from a host CPU. If the prop is alone and receives no serial load command, then boot from FLASH. There could be a recovery mechanism where the first sector in flash points to addresses of primary and backup bootloaders. If the first one fails verification, the second one is loaded. It's up the user app to make sure they're in separate flash sectors to support recovery mode. Either one can then check for the presence of an SD card and boot off that if you want to.
Finally, USB HID. At this point, you probably think I'm crazy. USB HID is extremely simple, does not require drivers in any OS, and allows user-mode access to a (limited) custom manufacturer-defined interface. With a bulk out, bulk in, and control, you can have defined commands (over the control line) to support loading ram, reset, and even fuse management if the lock fuse isn't blown.
As for QuadSPI support, did everyone miss this? (emphasis mine)
The boot loader should only support SPI flash. Not quad SPI flash. Please, read what the 0x03 instruction does on whatever SPI part you are looking at. If you notice, the 0x03 instruction only outputs 1-bit at a time. It does not matter what mode you are in.
Long thread, so my input may be buried, but here it is anyway.
I would really like the serial boot to work over Bluetooth, XBee, etc.
I guess I don't understand the big argument over booting from SD. If I want to do field upgrades, put a program in flash that loads a program from the SD card. How is this not equivalent or worse than booting from the SD card?
I did not see the sticky command read continuous stuff. So it is true about what jmg said that the boot loader will need to get the SPI chip out of that state.
As for SD card support. This will require 4 pins...
Its important to anticipate what people will want to use the chip for. Most customers are going to want the P2 for speed. So they will optimize for this. Because of that the boot loader has been setup to assume a quadSPI/octalSPI solution will be used. This means the pins used for the SD card must start after the possible quadSPI/octalSPI pin use.
So, normally the bootloader will only use pins like this:
P91 - RX
P90 - TX
P89 - CS
P88 - CLK
P87 - DI
P86 - DO
When a quadSPI or octalSPI setup is used you will likely see the following setup:
The quadSPI setup will have to preform a bit-reversal on the address to send it properly to the chip when clocking the data out on four pins at once. But, after this you have a garbage-in garbage-out scenario for the data. In octalSPI mode sending the address will be a bit trickier but then after doing that you will have the same garbage-in garbage-out setup. This is why the order reversal on the I/O pins does not matter.
After the above pins you'll have to put SD card pins. So... SD card support is going to more or less dictate that 4 i/o pins will be used from P79 to P76. This will then leave a 6 pin hole from P85 to P80 for quad and octalSPI support.
P79 - SD CS
P78 - SD CLK
P77 - SD DI
P76 - SD DO
So... 10 pins, not 1. Doing anything else will mean that an 8 bit port is not reserved for quadSPI or octalSPI mode stuff. Sharing the flash data bus will mean that a CS pin for the SD card will mess with the alignment of all the pins. Likely usage cases will be to have an SD card and flash. Both will be optimized for speed. So both need separate buses.
Yuo have made XXX hundreds of Systems that Customers RUN. All parts are soldered inclusive FLASH. That run Encrypted program that boots from flash.
You can't say to Customer --- De-solder FLASH -- else You can't upgrade.
That need some other device to be booted instead AS FLASH program You run don't give possibility's to break for start another program if it is loaded.
NOW You need upgrade program.
You need other device that Propeller II can boot from with clean program area.
So You need boot it from Serial else SD with update Program that have new software.
That give me question to Chip on boot order Serial, Flash, SD.
Need be
> Serial, SD, Flash
Long thread, so my input may be buried, but here it is anyway.
I would really like the serial boot to work over Bluetooth, XBee, etc.
I guess I don't understand the big argument over booting from SD. If I want to do field upgrades, put a program in flash that loads a program from the SD card. How is this not equivalent or worse than booting from the SD card?
... fitting multiple threads in is more than just having the space when it comes to the drivers. Timing is often very important while at the same time the mips is often way over the top for the driver using that Cog, and nothing else can use it. Four way slicing provides an opportunity to have effectively up to 32 low latency Cogs and still give out full mips between them. Where as task switching is an either-or situation.
I'm opposed to the feature this late in the game. Better to do it right and clean in the future than to just tack on now, hoping to resolve a kludge in the future. We had this discussion early on and kludge avoidance as well as determinism / code re-use were high on the list. They should remain high now, despite the temptation to do otherwise. We will find, as we did with Prop I, lots of ways to make the thing sing. This one will be no different. And when we do that with a clean, deterministic device, those means and methods will be broadly applicable as they are on this one too. That's worth a lot.
The way the Prop1 sings, when it comes to implementing soft devices, is by getting the timing and speed right. That often involves hogging a whole Cog. I'm just repeating myself I know but the situation of the Prop2 Cogs being way more powerful is a reality. Slicing will make better use of the Cogs even with this flaw.
And, repeating myself again, sliced code reuse will be fine in the future: - Slicing won't be removed in potential future larger designs, that I'm sure of. The corrected hardware won't crash the work-arounds, it'll just run them smoother. The "kludgy" parts will become a bit of dead code that has no effect other than consume some mips. Document them for later removal would be wise.
EDIT: Question: Chip, how much of a stall do the hub instructions create?
I did not see the sticky command read continuous stuff. So it is true about what jmg said that the boot loader will need to get the SPI chip out of that state.
As for SD card support. This will require 4 pins...
Its important to anticipate what people will want to use the chip for. Most customers are going to want the P2 for speed. So they will optimize for this. Because of that the boot loader has been setup to assume a quadSPI/octalSPI solution will be used. This means the pins used for the SD card must start after the possible quadSPI/octalSPI pin use.
So, normally the bootloader will only use pins like this:
P91 - RX
P90 - TX
P89 - CS
P88 - CLK
P87 - DI
P86 - DO
When a quadSPI or octalSPI setup is used you will likely see the following setup:
The quadSPI setup will have to preform a bit-reversal on the address to send it properly to the chip when clocking the data out on four pins at once. But, after this you have a garbage-in garbage-out scenario for the data. In octalSPI mode sending the address will be a bit trickier but then after doing that you will have the same garbage-in garbage-out setup. This is why the order reversal on the I/O pins does not matter.
After the above pins you'll have to put SD card pins. So... SD card support is going to more or less dictate that 4 i/o pins will be used from P79 to P76. This will then leave a 6 pin hole from P85 to P80 for quad and octalSPI support.
P79 - SD CS
P78 - SD CLK
P77 - SD DI
P76 - SD DO
So... 10 pins, not 1. Doing anything else will mean that an 8 bit port is not reserved for quadSPI or octalSPI mode stuff. Sharing the flash data bus will mean that a CS pin for the SD card will mess with the alignment of all the pins. Likely usage cases will be to have an SD card and flash. Both will be optimized for speed. So both need separate buses.
Kye,
Not quite. The now famous Raspberry Pi can only boot from SD card. There is no sight of any boot rom or uboot. Well if there is its also on the SD. Plugging a serial console into a Pi I see no boot loader on boot up to interact with.
Anyway, if boot from SD card requires so many Prop pins I'm dead against it.
If people want to boot from SD a pre-boot in FLASH is small and cheap anyway.
I guess I don't understand the big argument over booting from SD. If I want to do field upgrades, put a program in flash that loads a program from the SD card. How is this not equivalent or worse than booting from the SD card?
Yep, this idea has been suggested many times but gets rejected on the basis of annoying (too many pieces, too costly, confusing, more lame excuses). Even though it can be done as a nice frontend for managing bootable SD cards.
EDIT: That said, If Cluso can pull off fitting something in the remaining 165 longs then I don't have a problem.
Does anyone bother reading the FSRW or FATEngine ASM code for talking to an SD card?
The protocol is VERY complex. It is not simple at all.
...
I understand the desire to have boot capability from the SD card. But, the end result is that even more pins will need to be used by the boot loader statically. Right now the boot loader takes 6 pins. You'll need 7 for SD card boot. You can't share the CS pin between a SPI flash chip and an optional SD card. This will cause problems.
Additionally, for anyone who wants real performance out of the P2 and wants to make a competitive product you'll not want to share the SPI bus between the SPI flash chip and the SD card. If you want to use external flash to store code you'll most likely want to have either quadSPI or octalSPI action going on attached to the P2.
If you don't you will make cache misses very expensive for the C LMM machine (or flexible SPIN interpreter).
SPI mode for SD cards do not support clock rates faster than 25 MHz. This is on purpose by the SD card association to make the SPI bus not suitable for commercial products. With quadSPI or octalSPI parts you can drive the clock up to 100 MHz.
...
It sounds good to have SD card boot. But, the devil is in the details. Ignoring the fact that the SD card boot loader will not likely work with every SD card is not acceptable to build into the hardware. Building SD card boot into the hardware should only be done if Parallax plans to license the SD card protocol from the SD card association and do it right.
And again... most people who want the P2 for speed and performance will not share the SD card with the Flash bus. The performance you can get out of Octal SPI will run circles around an SD card.
...
Did you know that an over-clocked to 100 MHz FSRW driver using the fastest block driver on the P1 hits about the maximum write speed in RAW mode that you can achieve on an SD card. Do you want to be stuck with sub 2 MBs speed limits? With 100 MHz octalSPI flash you can hit 100 MBs a second.
The only way to hit the really fast read and write speeds on an SD card is to have sequential reads and writes (not random reads and writes... which is what is needed for a execute in place setup), use 1.8V signaling and license the SD card spec form the SD card association.
SPI flash memory is actually designed for execute in place (XIP) performance. This means random reads on SPI flash memory are designed to be fast.
...
*An octal SPI flash setup is where you have 2 quadSPI chips hooked up. This setup cost a $1 for about 16 MB of space. An SD card will likely cost you more money. Why pay for a 8 GB SD card when you do not need one and it will not be as fast?*
...
Sorry, for sounding angry in this post. I'm just a bit upset that many people seems to ignore the elephant in the room. Please look at the SD card init code in either the FAT Engine or FSRW and see how complex it is. Then understand that that neither the FATEngine or FSRW is perfect and the P2 needs to be.
This means Chip will have to devote a large portion of his time testing every SD card he can find under the sun for compatibility.
I tried following the code in the SD drivers and have to admit to getting lost going through it!! While I like the idea of being able to "boot" from an SD card I don't think I would care for it overall. In my never humble opinion an SPI boot from flash could load enough code to boot from an SD card. If Chip/Parallax is serious about it there could an option in the the new prop tool (or whatever gets used) that loads a routine in the flash that then loads and runs the cod in the SD card.
Totally disagree Phil. Since the prop has no internal flash, requiring an external flash chip to boot an SD card, if the commercial product has one, is an overhead that will be seen as stupid. I am looking at this solely from a commercial basis, not hobbyist. I have 100,000's of micro based products in the field that I designed and programmed. I do know there are enough detractors for the prop without internal flash, but to impose the requirement of a Flash chip just to boot from SD is insane.
In the application processor world, you're right. In the microcontroller world, you're wrong. All the chips I've seen that implement SD booting have HUGE mask ROMs on-chip. The i.mx28 has 128KB of mask ROM to support all the booting methods, and is an absolute pain to work with. The S3C6410 has a huge ROM as well to support a lot of methods. Clearly, it isn't particularly simple to support such diverse booting methods, so it would be far preferable to require a FLASH or EEPROM on the user's system to support this.
Everyone named below, sorry if I don't quote your messages, but this thread is producing output a little too fast!
@Phil
I said something in favour of a fs-agnostic SD boot, but only because Chip said he had 150 longs free in the current ROM, and that he has a few weeks to look on boot code while other people complete their work.
Personally I don't regard SD boot as an important feature, but merely as a "nice to have" if it can be done SIMPLY, "best-effort" style, and without impacting on whatever is already set in stone.
Please don't consider all people who favor SD boot as "SD evangelists", this is really not the case. If Chip feels that his attention is needed on more important tasks, I'm the first to say "forget all this nonsense and go back to your dungeon"
@David Betz
I was merely proposing linear scan for a long sized signature, but only up to a finite and small number of sectors, i.e. 512. That's 256KB.
And eventually, load 128KB from that point on. So in the worst case, either you read 512 sectors and give up, or if signature is found in sector #511 (unlikely) you read 512+256 sectors, for a total of 768 sectors, even on a 8GB+ sized card. Worst case upper limit would be known and measurable (wrt to time too).
@Kye
Why not using exactly the same 4 pins for flash and SD? I'm confident that if the SPI flash boot sequence is tried on an SD card before it is initialized in SPI mode, it would not raise an eyebrow, and just wait for the proper sequence following later.
@Heater
My personal preferences is AGAINST anything that would erode the amount of HUB ram or available (and I strongly dislike memory in amounts not power of 2! ).
So I agree with you that if it can't be done in the original planned ROM size, it should be dropped (the same for USB or anything else).
@All
Serial -> SPI flash -> bad luck
Serial -> SPI flash -> best effort SD boot (on same pins) -> bad luck
I can't see how the second scenario is worst...
*** provided it can be done in a way that doesn't require additional resources (ROM space or pins) ***
A best effort feature, and that's it. "best effort" should not be scaring for anyone, as the proper and reliable procedure *IS* SPI flash. Expecially as it seems to me that the typical usage would be mutual exclusive anyway:
1 - Bug fixing and (rare) updates (in devices with no SD socket): use SPI flash and update from serial, network techincians still do that all the time on routers :cool:
2 - Field updates in devices that already has an SD slot (i.e. for logging): use SPI flash and put there boot and updating code, choose SD pins freely like it's done on Prop1!
3 - SD only devices (like media players), or tight budget stuff having only the SD slot: use SD boot, but on your own responsibility wrt card adherence to SD-media published standards.
We only require that the SD card has SPI mode, and that reacts to the most basic and common "read sector" command. Not much different from the flash procedure apart from different initialization and seek for starting point.
Hmm... reading it back, it sounds a bit "long and pedantic". Sorry for this too, not intended to be, blame the language barrier!
Question: Chip, how much of a stall do the hub instructions create?
Chip might not see your question so I'll go ahead and answer it. The hub instructions will take between 2 to 9 cycles to execute depending on the aligment with the hub access window.
I thought the whole reason for this is that I2C eeprom is just too slow for the much larger boot code for Prop2...
It's slow on the Prop I mainly because the loader runs in RC mode. In the Prop II, the code fetched by the ROM could easily be a much faster secondary loader that runs from the crystal, if that's what the user wants. Of course, this entails that the ROM loader first read a byte count so it doesn't load any more code than it has to.
An agreement yet?, This sounds like the best solution to me:
SD-card uses same pins as the "missing" SPI flash.
If you want both Spi-flash and SD-card you will use your own fat16 driver (loaded from spi-flash) on any other pins of your choice.
Or use one more pin for CS,
So in case the SPI-Flash is emty or corrupt and no USB serial RX/TX connection is available,
you can boot from SD-Card and you have your program re-burn its program to spi-flash.
Maybe should be a special header for that, like it's now.
The rom should look for a header that says: load and copy to spi-flash.
Use the 150 long to come up with a raw (and slightly dirty) boot loader.
Yeah, I guess you could use the same pins and check for the SPI flash first. The SD card will not respond to any SPI flash commands on the SPI bus... Then if you don't find a SPI flash you then try to look for an SD card.
...
BTW, you can't use the JEDEC read ID command for SPI flash devices because the command code is not the same on all SPI flash devices and because some SPI flash devices do not even implement it. The SPI flash world is not standardized that well. Many devices work similarly, but, have different setups.
Re your P2 pinouts...
rx_pin = 91
tx_pin = 90
spi_cs = 89
spi_ck = 88
spi_di = 87
spi_do = 86 Postedit.. changed recommendation after thinking it through further - possibility of adding second SPI Quad Flash chip
From the W25Q80 the Quad access uses these pins... (I am not sure about other Quad SPi chips)
rx_pin = 91
tx_pin = 90
spi_cs = 89
spi_ck = 88
spi_io3 = 87 = /Hold (not used in boot process)
spi_io2 = 86 = /WP (not used in boot process)
spi_io1 = 85
spi_io0 = 84
This way, the nibble(s) would be aligned to a byte boundary and be in the correct bit order. I know it seems a waste to define these pins, but if the P2 is to support Quad mode efficiently, I would think this would be a better arrangement.
Right on! One thing, though: by letting the d0..d3 pins be perfectly backwards (as well as the other SPI Quad's data pins), we can tuck them up against the top (just below 88). It only takes a single-clock REV instruction to reverse those bits, you know. Then, we can get away with only pins 87 (spi_io0) and 86 (spi_io1) for data at boot-time. If they've got an SPI Quad, or even two SPI Quads, it all still works cleanly.
We need to consider how the SD card's pins can mesh into this, as some have pointed out.
In reference to Heater's (and others) comments about the P2 "wiggling" pins while finding a place to boot from, is there a way to select, specify, DEMAND a boot ONLY from TX/RX that will not wiggle any other pins? I could see this being useful to developers who wanted something completely different as far as pin assignments and is also in keeping with the Propeller underlying philosophy of soft peripherals and no dedicated pins. It may also be useful to boot device developers who may want to get some code running before "wiggling" any pins they are working with.
Question: Chip, how much of a stall do the hub instructions create?
WRxxxx are one clock, if you hit the hub cycle on the head. RDxxxx take two clocks if you hit the hub cycle right. RDxxxxC take 1 clock if cache valid, else like RDxxxx.
Kye,
Not quite. The now famous Raspberry Pi can only boot from SD card. There is no sight of any boot rom or uboot. Well if there is its also on the SD. Plugging a serial console into a Pi I see no boot loader on boot up to interact with.
Anyway, if boot from SD card requires so many Prop pins I'm dead against it.
If people want to boot from SD a pre-boot in FLASH is small and cheap anyway.
Considering how many pins SD could take, after potentially accommodating dual SPI Quad (8 data bits), it seems SD Card position needs to be selected by fuses (maybe SPI Quad, too, to straighten the address). By the way, it seems that serial should always be top priority, to avoid any system becoming unreachable.
How about using weak pullups and pulldowns to decide first boot device? The potentially four data bits would allow for 16 possible boot settings - far more than we need.
If SD support is added, it may be useful to support (at least hardware wise) the 4 bit MMC/SD mode using the same four pins as for QSPI.
Chip, I think I need more coffee today.... why do you want to reverse the order of d0-d3? I know its only one REV instruction, but why is it needed?
Considering how many pins SD could take, after potentially accommodating dual SPI Quad (8 data bits), it seems SD Card position needs to be selected by fuses (maybe SPI Quad, too, to straighten the address). By the way, it seems that serial should always be top priority, to avoid any system becoming unreachable.
Very interesting discussion. I think it has been most useful that we had it. There were many excellent points. It will be interesting to see what Chip chooses to do and how he will implement it (or not).
Comments
For booting from a host CPU in your design, pull reset LOW and have your host CPU drive it HIGH when it's ready to load the prop.
For boot sequence, serial, flash, USB HID-Class. Why?
Serial has the fewest pin requirements and allows the most pins to be used from a host CPU. If the prop is alone and receives no serial load command, then boot from FLASH. There could be a recovery mechanism where the first sector in flash points to addresses of primary and backup bootloaders. If the first one fails verification, the second one is loaded. It's up the user app to make sure they're in separate flash sectors to support recovery mode. Either one can then check for the presence of an SD card and boot off that if you want to.
Finally, USB HID. At this point, you probably think I'm crazy. USB HID is extremely simple, does not require drivers in any OS, and allows user-mode access to a (limited) custom manufacturer-defined interface. With a bulk out, bulk in, and control, you can have defined commands (over the control line) to support loading ram, reset, and even fuse management if the lock fuse isn't blown.
As for QuadSPI support, did everyone miss this? (emphasis mine)
I would really like the serial boot to work over Bluetooth, XBee, etc.
I guess I don't understand the big argument over booting from SD. If I want to do field upgrades, put a program in flash that loads a program from the SD card. How is this not equivalent or worse than booting from the SD card?
John Abshier
I did not see the sticky command read continuous stuff. So it is true about what jmg said that the boot loader will need to get the SPI chip out of that state.
As for SD card support. This will require 4 pins...
Its important to anticipate what people will want to use the chip for. Most customers are going to want the P2 for speed. So they will optimize for this. Because of that the boot loader has been setup to assume a quadSPI/octalSPI solution will be used. This means the pins used for the SD card must start after the possible quadSPI/octalSPI pin use.
So, normally the bootloader will only use pins like this:
P91 - RX
P90 - TX
P89 - CS
P88 - CLK
P87 - DI
P86 - DO
When a quadSPI or octalSPI setup is used you will likely see the following setup:
P91 - RX
P90 - TX
P89 - CS
P88 - CLK
P87 - DI (IO0)
P86 - DO (IO1)
P85 - IO2
P84 - IO3
P83 - IO4
P82 - IO5
P81 - IO6
P80 - IO7
The quadSPI setup will have to preform a bit-reversal on the address to send it properly to the chip when clocking the data out on four pins at once. But, after this you have a garbage-in garbage-out scenario for the data. In octalSPI mode sending the address will be a bit trickier but then after doing that you will have the same garbage-in garbage-out setup. This is why the order reversal on the I/O pins does not matter.
After the above pins you'll have to put SD card pins. So... SD card support is going to more or less dictate that 4 i/o pins will be used from P79 to P76. This will then leave a 6 pin hole from P85 to P80 for quad and octalSPI support.
P79 - SD CS
P78 - SD CLK
P77 - SD DI
P76 - SD DO
So... 10 pins, not 1. Doing anything else will mean that an 8 bit port is not reserved for quadSPI or octalSPI mode stuff. Sharing the flash data bus will mean that a CS pin for the SD card will mess with the alignment of all the pins. Likely usage cases will be to have an SD card and flash. Both will be optimized for speed. So both need separate buses.
I think Ken is right on this one.
Even ARM chips that do boot from SD cards have a large ROM OS that can handle many different things (like U-boot) to make booting reliable.
Scenario.
Yuo have made XXX hundreds of Systems that Customers RUN. All parts are soldered inclusive FLASH. That run Encrypted program that boots from flash.
You can't say to Customer --- De-solder FLASH -- else You can't upgrade.
That need some other device to be booted instead AS FLASH program You run don't give possibility's to break for start another program if it is loaded.
NOW You need upgrade program.
You need other device that Propeller II can boot from with clean program area.
So You need boot it from Serial else SD with update Program that have new software.
That give me question to Chip on boot order Serial, Flash, SD.
Need be
> Serial, SD, Flash
The way the Prop1 sings, when it comes to implementing soft devices, is by getting the timing and speed right. That often involves hogging a whole Cog. I'm just repeating myself I know but the situation of the Prop2 Cogs being way more powerful is a reality. Slicing will make better use of the Cogs even with this flaw.
And, repeating myself again, sliced code reuse will be fine in the future: - Slicing won't be removed in potential future larger designs, that I'm sure of. The corrected hardware won't crash the work-arounds, it'll just run them smoother. The "kludgy" parts will become a bit of dead code that has no effect other than consume some mips. Document them for later removal would be wise.
EDIT: Question: Chip, how much of a stall do the hub instructions create?
Why don't reuse this pins for SD
P88 - CLK
P87 - DI
P86 - DO
and only use this pin for SD CS
P79 - SD CS
Ps. BUT prefered CS pin for SD are
P83 - IO4 (SD-CS)
That simplify SIP send Receive routines and spare 3 pins !!
Not quite. The now famous Raspberry Pi can only boot from SD card. There is no sight of any boot rom or uboot. Well if there is its also on the SD. Plugging a serial console into a Pi I see no boot loader on boot up to interact with.
Anyway, if boot from SD card requires so many Prop pins I'm dead against it.
If people want to boot from SD a pre-boot in FLASH is small and cheap anyway.
Yep, this idea has been suggested many times but gets rejected on the basis of annoying (too many pieces, too costly, confusing, more lame excuses). Even though it can be done as a nice frontend for managing bootable SD cards.
EDIT: That said, If Cluso can pull off fitting something in the remaining 165 longs then I don't have a problem.
-Phil
In that case WHY not stay with small I2C reboot device --- Give only Factory dedicated 4 pins.
All other functions build in stage 2 BIOS located on I2C device
>> that give user mos free usage of PINs
Ps. And then I2C bus can be reused by USER to many other I2C things
-Phil
NOT for me.!!
That is most inexpensive solution
I tried following the code in the SD drivers and have to admit to getting lost going through it!! While I like the idea of being able to "boot" from an SD card I don't think I would care for it overall. In my never humble opinion an SPI boot from flash could load enough code to boot from an SD card. If Chip/Parallax is serious about it there could an option in the the new prop tool (or whatever gets used) that loads a routine in the flash that then loads and runs the cod in the SD card.
@Phil
I said something in favour of a fs-agnostic SD boot, but only because Chip said he had 150 longs free in the current ROM, and that he has a few weeks to look on boot code while other people complete their work.
Personally I don't regard SD boot as an important feature, but merely as a "nice to have" if it can be done SIMPLY, "best-effort" style, and without impacting on whatever is already set in stone.
Please don't consider all people who favor SD boot as "SD evangelists", this is really not the case. If Chip feels that his attention is needed on more important tasks, I'm the first to say "forget all this nonsense and go back to your dungeon"
@David Betz
I was merely proposing linear scan for a long sized signature, but only up to a finite and small number of sectors, i.e. 512. That's 256KB.
And eventually, load 128KB from that point on. So in the worst case, either you read 512 sectors and give up, or if signature is found in sector #511 (unlikely) you read 512+256 sectors, for a total of 768 sectors, even on a 8GB+ sized card. Worst case upper limit would be known and measurable (wrt to time too).
@Kye
Why not using exactly the same 4 pins for flash and SD? I'm confident that if the SPI flash boot sequence is tried on an SD card before it is initialized in SPI mode, it would not raise an eyebrow, and just wait for the proper sequence following later.
@Heater
My personal preferences is AGAINST anything that would erode the amount of HUB ram or available (and I strongly dislike memory in amounts not power of 2!
So I agree with you that if it can't be done in the original planned ROM size, it should be dropped (the same for USB or anything else).
@All
Serial -> SPI flash -> bad luck
Serial -> SPI flash -> best effort SD boot (on same pins) -> bad luck
I can't see how the second scenario is worst...
*** provided it can be done in a way that doesn't require additional resources (ROM space or pins) ***
A best effort feature, and that's it. "best effort" should not be scaring for anyone, as the proper and reliable procedure *IS* SPI flash. Expecially as it seems to me that the typical usage would be mutual exclusive anyway:
1 - Bug fixing and (rare) updates (in devices with no SD socket): use SPI flash and update from serial, network techincians still do that all the time on routers :cool:
2 - Field updates in devices that already has an SD slot (i.e. for logging): use SPI flash and put there boot and updating code, choose SD pins freely like it's done on Prop1!
3 - SD only devices (like media players), or tight budget stuff having only the SD slot: use SD boot, but on your own responsibility wrt card adherence to SD-media published standards.
We only require that the SD card has SPI mode, and that reacts to the most basic and common "read sector" command. Not much different from the flash procedure apart from different initialization and seek for starting point.
Hmm... reading it back, it sounds a bit "long and pedantic". Sorry for this too, not intended to be, blame the language barrier!
I thought the whole reason for this is that I2C eeprom is just too slow for the much larger boot code for Prop2...
-Phil
SD-card uses same pins as the "missing" SPI flash.
If you want both Spi-flash and SD-card you will use your own fat16 driver (loaded from spi-flash) on any other pins of your choice.
Or use one more pin for CS,
So in case the SPI-Flash is emty or corrupt and no USB serial RX/TX connection is available,
you can boot from SD-Card and you have your program re-burn its program to spi-flash.
Maybe should be a special header for that, like it's now.
The rom should look for a header that says: load and copy to spi-flash.
Use the 150 long to come up with a raw (and slightly dirty) boot loader.
...
BTW, you can't use the JEDEC read ID command for SPI flash devices because the command code is not the same on all SPI flash devices and because some SPI flash devices do not even implement it. The SPI flash world is not standardized that well. Many devices work similarly, but, have different setups.
Right on! One thing, though: by letting the d0..d3 pins be perfectly backwards (as well as the other SPI Quad's data pins), we can tuck them up against the top (just below 88). It only takes a single-clock REV instruction to reverse those bits, you know. Then, we can get away with only pins 87 (spi_io0) and 86 (spi_io1) for data at boot-time. If they've got an SPI Quad, or even two SPI Quads, it all still works cleanly.
We need to consider how the SD card's pins can mesh into this, as some have pointed out.
Yes, fuses can determine this!
WRxxxx are one clock, if you hit the hub cycle on the head. RDxxxx take two clocks if you hit the hub cycle right. RDxxxxC take 1 clock if cache valid, else like RDxxxx.
Considering how many pins SD could take, after potentially accommodating dual SPI Quad (8 data bits), it seems SD Card position needs to be selected by fuses (maybe SPI Quad, too, to straighten the address). By the way, it seems that serial should always be top priority, to avoid any system becoming unreachable.
1) serial
2) SD
3) flash
If SD support is added, it may be useful to support (at least hardware wise) the 4 bit MMC/SD mode using the same four pins as for QSPI.
Chip, I think I need more coffee today.... why do you want to reverse the order of d0-d3? I know its only one REV instruction, but why is it needed?
This.idea(good)