You have some good points, but I don't totally see it your way. If we can figure out a way to do intrinsic booting from an SD card as a third boot pathway (after serial RAM & SPI EEPROM), then that is a good thing because it offers some additional flexibility and the ability to modify an application without having to reflash an EEPROM or make a serial connection. Field upgrades could be a snap.
While I agree that booting from an SD card is a good thing, I think there are too many things that can go wrong (and will). Without a way to "tell" the user (who may or may not be knowledgeable about the technical aspects of troubleshooting an SD boot) that there has been an error. I learned very quickly that file systems are fragile (I've trashed many a filesystem with glitchy code). I DOUBT there will be enough room in ROM to implement a robust boot from SD. And I would NOT be willing to lose ANY hub-ram. Also, imagine trying to get a 486 to boot from CD WITHOUT BIOS... I GUESS it could be done, but is it worth it? NO.
Kye made an excellent point about the complications with just getting an SD card working. I've been through FSRW and FAT a few times trying to get things to work... What a MESS. And I'm not saying that the code is bad, these are BRILLIANT implementations. I just think there are WAY more important things to spend time on. I think that ALL the mechanisms to this point have inherent weaknesses that limit the usefulness. Using the EEPROM to implement a BIOS is a WAY better idea, and the current Prop1 project does something to this effect. In-field upgrades ARE as simple as copying the new program to the card. The current "bios" is quite a bit more bloated than a simple 2nd stage boot-loader, but could be stripped down if desired. And there's plenty of functionality by this point, displaying an error message is trivial. The point is there are more important fish to fry.
That said, having an EEPROM with more robust code (as a default capability) for SD card is a minor additional cost for a hobbyist board and there are lots of pins anyway. I won't loose sleep if we still need to keep the EEPROM.
The question for me is if it can be done or not in the remaining ROM space? It is worth asking now because the decision Chip makes is one we will live with for years. Is there anything else that is compelling that we can do with the ROM space?
Now this is what I want to know. Who can think of stuff to fill that hole with? I wouldn't mind having a character map again. This has made debugging a SNAP because I have a character set from boot. I know there's WAY better uses for this "extra" ROM. Now what's Chip going to fill it with?
I TOTALLY agree with Phil.. But let me re-iterate,
I LOVE HAVING THE ROM FONT, PLEASE KEEP IT
Now, can anyone come up with requests for ROM code that will be useful? OTHER than sd boot?
I will write the code tonight for you. Unfortunately I am busy today (now ~13:00 here). I have virtually done this all before with the only difference being that I used the FAT to locate the file data rather than a pointer in the MBR. All my ZiCog SD file accesses are done using raw mode relative to this/these file base sectors (i.e. disregards the FAT system). So I do know what I am talking about.
So it looks a bit like handling i2c, where you send 16 clocks, with All Data Hi, and (hopefully) get into a known state.
(note in Quad mode, you need
There may be fish-hooks in this, as I see the Winbond RST mode overlays valid address in one mode, so maybe it needs
a CS de-assert after exactly 16 clocks ?
Microchip only shows two clocks for QSPI reset, (4 for DSPI), but does not say what happens if more are used ?
Would this mean that we need to drive all 4 QuadSPI data pins high and give clock pulses? It looks like we might as well commit to QuadSPI and wire up all four bits, if so.
Again, we are not talking about the support for FAT (or anything else) in ROM, just the ability to locate a set of sectors containing P2 boot code.
Exactly! Using the conventions that are already used, such as the MBR, make it easy to make it interoperable with PCs. Your suggestion outlined in your previous post is ideal, IMHO. It's simple, it inter operates with PCs, and allows for flexibility to operate without depending on a specific file system, like FAT.
There seems to be a lot of concern regarding some SD cards that may prove to not operate correctly with the boot code. However, it's not like this isn't a potential issue with objects such as FSRW or Kye's FAT Engine. One way or another, an engineer/customer must be aware that there are SD cards that just flat out will not work. Supporting all SD cards is going to be impossible, but that doesn't make it not worth pursuing. Because if one goes by that logic, we shouldn't be using any of the available SD objects either.
Would this mean that we need to drive all 4 QuadSPI data pins high and give clock pulses? It looks like we might as well commit to QuadSPI and wire up all four bits, if so.
Yes, I think that is the best solution, to give a known recovery from a non power cycle reset, for a wide range of devices.
If users want to 'borrow' the QSI pins later, they can.
I see the SST parts ( SST26VF016/032) also say this :
RSTQIO Reset Quad I/O FFH
Would this mean that we need to drive all 4 QuadSPI data pins high and give clock pulses? It looks like we might as well commit to QuadSPI and wire up all four bits, if so.
Chip, while it's great that we can connect QuadSPI devices as Kye verified, the technology is only a year old. Please stick with SPI type devices for booting (SPI Flash, SD card, etc...). Can you support EEPROM? I've seen that mentioned several times here.
Chip, while it's great that we can connect QuadSPI devices as Kye verified, the technology is only a year old. Please stick with SPI type devices for booting (SPI Flash, SD card, etc...). Can you support EEPROM? I've seen that mentioned several times here.
QuadSPI dates from way back in 2007, so it is hardly "only a year old".
The SPI parts are a subset of QuadSPI, but the issue here covers a user with QuadSPI, who does a fresh download, or a watchdog reset...(etc).
You DO want that to work, which means you need to exit Quad SPI mode, in case they are still in that mode.
So it is a just small preamble, it does not exclude Std SPI, but I would expect those subset parts to quietly phase out in all but the smallest sizes.
We can give, at the application level, some functionality that enables the Prop II to appear as a USB storage device to a host. This way, files can be dropped on it and read off it via host GUI's, giving it bigger-system interoperability, without needing to plunge into the SD card abyss.
You DO want that to work, which means you need to exit Quad SPI mode, in case they are still in that mode.
So it is a just small preamble, it does not exclude Std SPI, but I would expect those subset parts to quietly phase out in all but the smallest sizes.
I'm happy to see it work and would like things to be as general as possible, but the requirements list certainly seems to be growing. Best to not leave anything out I guess, but we've already seen SRAM start to shrink, and that is painful too.
We can give, at the application level, some functionality that enables the Prop II to appear as a USB storage device to a host. This way, files can be dropped on it and read off it via host GUI's, giving it bigger-system interoperability, without needing to plunge into the SD card abyss.
That would be nice, but what about someone who has an isolated, or non-working system, or who couriers a new SD card ?
Layers that make usage easier are always nice, but the lowest level still has to work on a minimal system.
We can give, at the application level, some functionality that enables the Prop II to appear as a USB storage device to a host. This way, files can be dropped on it and read off it via host GUI's, giving it bigger-system interoperability, without needing to plunge into the SD card abyss.
I can't help but feel this has less practical use than SD boot support. Think about it this way - if you choose, you can have a fully integrated system using SD and no SPI flash, but the same can't be said if you replace SD with USB.
Another thing is, the P2 will have a lot of multimedia capabilities, which is well suited to large capacity of SD. In these cases, it might be nice to not have put an SPI flash chip in the product.
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.
Changing the status register to enable quadSPI operation does just that... it enables it. This means the quadSPI read instructions will work afterward. It does not mean that every instruction will suddenly work in quadSPI mode.
Because of this. The reset problem on quadSPI memory is not a problem because when the CS pin goes high during reset (assuming you pull it up - which you should), the chip will abandon the current instruction. After which the bootloader can issue the 0x03 "read-slow" instruction and work again in 1-bit mode.
The user's application can then make the SPI chip go to quadSPI mode.
---
Please do not compare the prop chip 150 long ROM space to other competitor solutions. Other chips have dedicated hardware to communicate to the SD card and are using paid for SD card spec material. If Parallax chooses to go this route then I agree for SD card support.
As I have been saying, committing to SD card support in ROM means that no functionality can be upgraded and bugs cannot be worked out. A lot of functionality has to be put into a small space for true SD card support.
Also, SST (microchip) is not the only vendor in the market.
Please understand that SPI flash memory devices are not all compatible. Many of the instructions for SPI flash are different. I spent a great deal of time researching this and you will only be able to find compatibility across the 0x03 "read (slow) instruction".
The flash vendors are Atmel, Microchip (SST), Winbond, Micron, Macronix, and Spansion.
Because of this. The reset problem on quadSPI memory is not a problem because when the CS pin goes high during reset (assuming you pull it up - which you should), the chip will abandon the current instruction. After which the bootloader can issue the 0x03 "read-slow" instruction and work again in 1-bit mode.
That is not what the Winbond, or Microchip, or SST data says.
These devices are designed for fast, execute in place, and having to re-assert QuadSPI every cycle, defeats that.
Winbond has a sticky opcode mode, and that can only ex exited via the reset opcode.
Microchip ( 23A1024/23LC1024 FIg 4-5) and SST (SST26VF016 / SST26VF032 Fig 11) show a nibble-mode opcode, straight after CS=\_ , so the opcode is NOT guaranteed to always be 1 bit/8 clocks.
That is why you need a deliberate exit-quad action, on QuadSPI parts, and that is more than CS=H.
We can give, at the application level, some functionality that enables the Prop II to appear as a USB storage device to a host. This way, files can be dropped on it and read off it via host GUI's, giving it bigger-system interoperability, without needing to plunge into the SD card abyss.
Gee Chip... That is one big can of worms at this late stage. But it still does not satisfy the SD boot problem where Flash is not required. Why require Flash if it is not required. Parallax best be able to answer this on a professional level on the P2 because it will definately be asked.
There is no SD card abyss - just a lot of negativity from those who don't care for it. But as you know, there are likely to be a lot of professional uses requiring SD cards. This can be seen everywhere now. Anyway, I wil post working P1 code tonight so you should have it in the morning tomorrow your time. Then you can see how simple it should be.
I have to agree with Kye on the SPI Flash. Just use 1-bit mode. The vast majority of SPI FLash support the 1bit mode irrespective of whether they support 2 or 4 bit mode. If there ends up being a few SPI Flash chips that cannot be used, then it be so. Remember, we only have a few I2C eeprom chips supported on the P1.
The bot code on the SPI Flash can enable whatever mode you like. This should not be in ROM.
Gee Chip... That is one big can of worms at this late stage. But it still does not satisfy the SD boot problem where Flash is not required. Why require Flash if it is not required. Parallax best be able to answer this on a professional level on the P2 because it will definately be asked.
There is no SD card abyss - just a lot of negativity from those who don't care for it. But as you know, there are likely to be a lot of professional uses requiring SD cards. This can be seen everywhere now. Anyway, I wil post working P1 code tonight so you should have it in the morning tomorrow your time. Then you can see how simple it should be.
Thanks for thinking about this. I will look forward to your code.
Kye explained to me that SPI compatibility is an optional matter for SD card manufacturers and as things get much BIGGER it will become impractical because of its 25MHz limitation, so many manufacturers might drop it, as time moves forward. We'll investigate this all a little further, though.
I have to agree with Kye on the SPI Flash. Just use 1-bit mode. The vast majority of SPI FLash support the 1bit mode irrespective of whether they support 2 or 4 bit mode. If there ends up being a few SPI Flash chips that cannot be used, then it be so. Remember, we only have a few I2C eeprom chips supported on the P1.
The bot code on the SPI Flash can enable whatever mode you like. This should not be in ROM.
We need to be sure that we can reset it properly, so that we can be assured that it is in one-bit mode when we boot from it. We need to be sure that the ROM code can reset chips that are wired in all the useful ways. I don't know if this is trivial, or not, yet.
It's a really good thing that this matter was brought up.
Here is my EEPROM boot code for booting a file on the SD card. This is not how I propose, as it will be way simpler than this. But this does serve to show how simple this job is, so my proposed method is even simpler.
I have to agree with Kye on the SPI Flash. Just use 1-bit mode. The vast majority of SPI FLash support the 1bit mode irrespective of whether they support 2 or 4 bit mode.
The devil is in the details :
If you have a QuadSPI chip (and they WILL become ever-more standard) you need to reliably get it into 1 bit mode, after a watchdog or non-cycle reset.
There are plenty of real devices to verify this on, and it is really just simple house-keeping.
It is likely that the lowest initial boot read, would be in 1-bit mode, but you DO need to KNOW you are in 1-bit mode.
We can give, at the application level, some functionality that enables the Prop II to appear as a USB storage device to a host. This way, files can be dropped on it and read off it via host GUI's, giving it bigger-system interoperability, without needing to plunge into the SD card abyss.
I like that. USB is fast. I don't know how much space it would appear as, but it could be a tiny 32k of (?onboard) flash - whatever fits on the P2. You could drop a new file 'boot.txt' in to change the startup behaviour. I guess you need enough space to fit an SD reader. Or to talk to a flash chip. Or read from an I2C eeprom. But not necessarily all three at the same time - if the chip appears as a small USB drive you can always change the boot file as you need to.
I'm thinking about future proofing eg SD cards. But if you have enough space to put in a new boot program you can change that as things change. So in a way, no particular SD or flash or quad SPI protocol need be supported. All you have in that boot program is something that can be programmed to toggle the chips pins in certain ways. Some pasm code I suppose. So it is always software configurable to change to what you want it to be, just like the way cogs can be configured to be serial ports or display drivers. With all the issues I've seen with SD cards I'm not sure how you would hard code that into a chip.
I really like the idea of the P2 appearing as a USB drive. So easy to code an IDE to work with that.
Kye, are you talking strictly about SD card support in rom having support for fat or other type file systems?
What about supporting sd cards in a raw mode, it would not be hard to write a tool to "format" the sd card with proper data in the correct locations?
How much code is needed to get the prop pulling raw data off the card, ignoring any kind of file system or card size.
What about raw data pattern recognition methods for locating proper data on fat formated sd cards?
This might require a complete sd card spec and format/file windows manager tool for a "prop2" sd card partiton.
Couldn't a fat type structure exist wile still accessing raw data initially?
Files can be written to a specific spot on data medium, with proper tool.
And the prop could access raw data code from exact location on medium?
Throw all the file fat etc stuff out and just consider raw data interfacing sd cards in rom code?
Were talking exact data sructure to boot, no fancy file structure that the prop needs to "setup" to then find the proper file to boot.
Thanks for thinking about this. I will look forward to your code.
Kye explained to me that SPI compatibility is an optional matter for SD card manufacturers and as things get much BIGGER it will become impractical because of its 25MHz limitation, so many manufacturers might drop it, as time moves forward. We'll investigate this all a little further, though.
It was optional on the microSD (aka Transflash) cards. A couple of cards were initialy released without SPI mode, but from what I understand, they received so much flack that they abandonded their thinking and put it back in. The SD cards have always mandated the SPI mode.
The current boot process requires SPI mode to be present and then commands switch to nibble mode. Therefore, all devices currently on the market use SPI mode initially. I think this is why it will remain a requiredment on all devices. However, if I am wrong,and later SPI mode is abandoned, then we have not lost anything to what was proposed... the Flash would be required. But with all the cameras and phones it would be one foolish manufacturer who decided to abandon the SPI mode given the users with equipment that currently use this mode. And this mode no longer requires a licence AFAIK because it was cleanroom decoded by the *nix group. In fact I believe they have cleanroom decoded the nibble mode too.
SPI Flash: I will leave others to verify that the flash can be left in nibble mode and requires a specific reset to take it out. Just on my way out atm.
We need to be sure that we can reset it properly, so that we can be assured that it is in one-bit mode when we boot from it. We need to be sure that the ROM code can reset chips that are wired in all the useful ways.
I don't know if this is trivial, or not, yet.
It's a really good thing that this matter was brought up.
So far, it appears 0FFH clocked is a common reset.
Less clear, is how tolerant they are of various clock counts.
SST says this The Reset Quad I/O instruction, FFH, resets the device to 1-bit SPI protocol operation. To execute a Reset Quad I/O operation, the host drives CE# low, sends the Reset Quad I/O command cycle (FFH) then, drives CE# high. The device accepts either SPI (8 clocks) or SQI (2 clocks) command cycles.
Microchip says this: Exit SDI or SQI Mode
To exit from SDI mode, the RSTIO command must be issued. The command must be entered in the current device configuration, either SDI or SQI, see Figure 4-7 and Figure 4-8
A little more cryptic, but that sounds a little more constrained.
Winbond fig 7.2.20 suggests it needs Data HH and 8 clocks to exit Quad mode, and 16 clocks to exit Dual mode.
Universal might be : All Data pins HI then one of each of
a) CS=L, 2 Clks, CS=H == QuadRST
b) CS=L, 4 Clks, CS=H == DualRST
c) CS=L, 8 Clks, CS=H == SingleRST
d) CS=L, 16 Clks, CS=H == Winbond, Dual mode
- from here, single bit SPI mode should now work, on everyone, no matter what state it started in.
In most cases, the extra clocks will simply be redundant, but if frame counts matter, this covers those.
I don't understand the technical details about booting from SD cards or eeprom, but my limited experience supervising the SD card procurement/qualification in Parallax leads me to believe that SD is probably not the most important commercial solution for booting for a couple of reasons. First off, we've had tons of trouble locating SD cards on the Asian market that are of consistent design. And domestically-sourced cards are far too expensive for production. The data David Carrier has showed me about boot and access speeds varies greatly, even from the same shipped lot from the same source. Sometimes Kwabena's driver works, sometimes fsrw works. Some SD cards we've received have formatting challenges, too, but Daniel seems to have made a Linux tool that works on all cards. And if you want a name brand SD card, you'll never know that it's the real deal unless you buy it from Best Buy (I assume they carry the real brands, but not sure). SD cards are among the most frequently fake-labelled parts available from China. The Chinese markets are full of Kingston, SanDisk and other leading brands that are from "who knows where".
I'm not suggesting it's not commercially viable, but it certainly has some characteristics that are cause for concern. We should support it when it's sensible to do so, not right now.
It is true that Chip has six weeks while the synthesis team wraps it up, but that time is going to be better spent counseling our staff on the Propeller 2 design so we can prepare the data sheet, documentation and resolve our programming tool plan. Supporting the boot process off of an SD card wouldn't be a top priority right now if it can wait - our tools and documentation are far more important.
Nobody manages Chip (he does whatever he wants according to history) but I believe it's in everybody's interest to encourage him to get Propeller 2 OTFD and to effectively communicate the design to our staff so we can get it documented properly.
SD is probably not the most important commercial solution for booting for a couple of reasons.
So far what I have noticed, is people think that someone here is suggesting that flash eeprom booting should get REPLACED with sd card booting.
I don't think this is the case at all, i think people are only saying, they would like sd boot capability if possible after the normal eeprom, and other features are proper.
Sd boot?
Its more of a neat feature to be used by the "elite" prop2-ist who can find the miracle golden egg sd card that works with it.?
Is finding compatibility really that big of a golden egg? If so, im surprised sd cards made it so far.
I would like to formally withdraw my request to support booting with a QuadSPI (Winbond) or SQI (Microchip SST) device. I think there is too much risk. The most common denominator seems to be single bit SPI or other similar solutions for power on reset.
While it is possible to write code to reset these multi-bit devices to "single bit" SPI mode to ensure a proper read, the idea of it is not very pretty. The "reliable thing" to do from experience with flash in year's past would be to use the device ID available from the JEDEC command $9F to get the chip information and have the code initialize accordingly. JEDEC codes are supposed to be readable regardless of bit type settings.
While it is a fine idea to use a lookup in user code that is easy to change, requiring a data base of command sequences in a tiny mask ROM memory space to support N types of SPI flash just doesn't seem to make any sense.
Comments
While I agree that booting from an SD card is a good thing, I think there are too many things that can go wrong (and will). Without a way to "tell" the user (who may or may not be knowledgeable about the technical aspects of troubleshooting an SD boot) that there has been an error. I learned very quickly that file systems are fragile (I've trashed many a filesystem with glitchy code). I DOUBT there will be enough room in ROM to implement a robust boot from SD. And I would NOT be willing to lose ANY hub-ram. Also, imagine trying to get a 486 to boot from CD WITHOUT BIOS... I GUESS it could be done, but is it worth it? NO.
Kye made an excellent point about the complications with just getting an SD card working. I've been through FSRW and FAT a few times trying to get things to work... What a MESS. And I'm not saying that the code is bad, these are BRILLIANT implementations. I just think there are WAY more important things to spend time on. I think that ALL the mechanisms to this point have inherent weaknesses that limit the usefulness. Using the EEPROM to implement a BIOS is a WAY better idea, and the current Prop1 project does something to this effect. In-field upgrades ARE as simple as copying the new program to the card. The current "bios" is quite a bit more bloated than a simple 2nd stage boot-loader, but could be stripped down if desired. And there's plenty of functionality by this point, displaying an error message is trivial. The point is there are more important fish to fry.
That said, having an EEPROM with more robust code (as a default capability) for SD card is a minor additional cost for a hobbyist board and there are lots of pins anyway. I won't loose sleep if we still need to keep the EEPROM.
Now this is what I want to know. Who can think of stuff to fill that hole with? I wouldn't mind having a character map again. This has made debugging a SNAP because I have a character set from boot. I know there's WAY better uses for this "extra" ROM. Now what's Chip going to fill it with?
I TOTALLY agree with Phil.. But let me re-iterate,
I LOVE HAVING THE ROM FONT, PLEASE KEEP IT
Now, can anyone come up with requests for ROM code that will be useful? OTHER than sd boot?
(please Chip, save EVERYONE the headache)
I will write the code tonight for you. Unfortunately I am busy today (now ~13:00 here). I have virtually done this all before with the only difference being that I used the FAT to locate the file data rather than a pointer in the MBR. All my ZiCog SD file accesses are done using raw mode relative to this/these file base sectors (i.e. disregards the FAT system). So I do know what I am talking about.
Would this mean that we need to drive all 4 QuadSPI data pins high and give clock pulses? It looks like we might as well commit to QuadSPI and wire up all four bits, if so.
Exactly! Using the conventions that are already used, such as the MBR, make it easy to make it interoperable with PCs. Your suggestion outlined in your previous post is ideal, IMHO. It's simple, it inter operates with PCs, and allows for flexibility to operate without depending on a specific file system, like FAT.
Yes, I think that is the best solution, to give a known recovery from a non power cycle reset, for a wide range of devices.
If users want to 'borrow' the QSI pins later, they can.
I see the SST parts ( SST26VF016/032) also say this :
RSTQIO Reset Quad I/O FFH
Chip, while it's great that we can connect QuadSPI devices as Kye verified, the technology is only a year old. Please stick with SPI type devices for booting (SPI Flash, SD card, etc...). Can you support EEPROM? I've seen that mentioned several times here.
QuadSPI dates from way back in 2007, so it is hardly "only a year old".
The SPI parts are a subset of QuadSPI, but the issue here covers a user with QuadSPI, who does a fresh download, or a watchdog reset...(etc).
You DO want that to work, which means you need to exit Quad SPI mode, in case they are still in that mode.
So it is a just small preamble, it does not exclude Std SPI, but I would expect those subset parts to quietly phase out in all but the smallest sizes.
We can give, at the application level, some functionality that enables the Prop II to appear as a USB storage device to a host. This way, files can be dropped on it and read off it via host GUI's, giving it bigger-system interoperability, without needing to plunge into the SD card abyss.
I'm happy to see it work and would like things to be as general as possible, but the requirements list certainly seems to be growing. Best to not leave anything out I guess, but we've already seen SRAM start to shrink, and that is painful too.
That would be nice, but what about someone who has an isolated, or non-working system, or who couriers a new SD card ?
Layers that make usage easier are always nice, but the lowest level still has to work on a minimal system.
I can't help but feel this has less practical use than SD boot support. Think about it this way - if you choose, you can have a fully integrated system using SD and no SPI flash, but the same can't be said if you replace SD with USB.
Another thing is, the P2 will have a lot of multimedia capabilities, which is well suited to large capacity of SD. In these cases, it might be nice to not have put an SPI flash chip in the product.
Changing the status register to enable quadSPI operation does just that... it enables it. This means the quadSPI read instructions will work afterward. It does not mean that every instruction will suddenly work in quadSPI mode.
Because of this. The reset problem on quadSPI memory is not a problem because when the CS pin goes high during reset (assuming you pull it up - which you should), the chip will abandon the current instruction. After which the bootloader can issue the 0x03 "read-slow" instruction and work again in 1-bit mode.
The user's application can then make the SPI chip go to quadSPI mode.
---
Please do not compare the prop chip 150 long ROM space to other competitor solutions. Other chips have dedicated hardware to communicate to the SD card and are using paid for SD card spec material. If Parallax chooses to go this route then I agree for SD card support.
As I have been saying, committing to SD card support in ROM means that no functionality can be upgraded and bugs cannot be worked out. A lot of functionality has to be put into a small space for true SD card support.
A 30 cent flash chip is not much.
---
I agree with Phil on this conversation.
One way or another, I'll be more than happy to trade my hard-earned money for a nice new P2.
Please understand that SPI flash memory devices are not all compatible. Many of the instructions for SPI flash are different. I spent a great deal of time researching this and you will only be able to find compatibility across the 0x03 "read (slow) instruction".
The flash vendors are Atmel, Microchip (SST), Winbond, Micron, Macronix, and Spansion.
That is not what the Winbond, or Microchip, or SST data says.
These devices are designed for fast, execute in place, and having to re-assert QuadSPI every cycle, defeats that.
Winbond has a sticky opcode mode, and that can only ex exited via the reset opcode.
Microchip ( 23A1024/23LC1024 FIg 4-5) and SST (SST26VF016 / SST26VF032 Fig 11) show a nibble-mode opcode, straight after CS=\_ , so the opcode is NOT guaranteed to always be 1 bit/8 clocks.
That is why you need a deliberate exit-quad action, on QuadSPI parts, and that is more than CS=H.
Gee Chip... That is one big can of worms at this late stage. But it still does not satisfy the SD boot problem where Flash is not required. Why require Flash if it is not required. Parallax best be able to answer this on a professional level on the P2 because it will definately be asked.
There is no SD card abyss - just a lot of negativity from those who don't care for it. But as you know, there are likely to be a lot of professional uses requiring SD cards. This can be seen everywhere now. Anyway, I wil post working P1 code tonight so you should have it in the morning tomorrow your time. Then you can see how simple it should be.
The bot code on the SPI Flash can enable whatever mode you like. This should not be in ROM.
Thanks for thinking about this. I will look forward to your code.
Kye explained to me that SPI compatibility is an optional matter for SD card manufacturers and as things get much BIGGER it will become impractical because of its 25MHz limitation, so many manufacturers might drop it, as time moves forward. We'll investigate this all a little further, though.
We need to be sure that we can reset it properly, so that we can be assured that it is in one-bit mode when we boot from it. We need to be sure that the ROM code can reset chips that are wired in all the useful ways. I don't know if this is trivial, or not, yet.
It's a really good thing that this matter was brought up.
PropBootSD_V1_10_RB3 - Archive [Date 2012.01.20 Time 17.47].zip
The devil is in the details :
If you have a QuadSPI chip (and they WILL become ever-more standard) you need to reliably get it into 1 bit mode, after a watchdog or non-cycle reset.
There are plenty of real devices to verify this on, and it is really just simple house-keeping.
It is likely that the lowest initial boot read, would be in 1-bit mode, but you DO need to KNOW you are in 1-bit mode.
I like that. USB is fast. I don't know how much space it would appear as, but it could be a tiny 32k of (?onboard) flash - whatever fits on the P2. You could drop a new file 'boot.txt' in to change the startup behaviour. I guess you need enough space to fit an SD reader. Or to talk to a flash chip. Or read from an I2C eeprom. But not necessarily all three at the same time - if the chip appears as a small USB drive you can always change the boot file as you need to.
I'm thinking about future proofing eg SD cards. But if you have enough space to put in a new boot program you can change that as things change. So in a way, no particular SD or flash or quad SPI protocol need be supported. All you have in that boot program is something that can be programmed to toggle the chips pins in certain ways. Some pasm code I suppose. So it is always software configurable to change to what you want it to be, just like the way cogs can be configured to be serial ports or display drivers. With all the issues I've seen with SD cards I'm not sure how you would hard code that into a chip.
I really like the idea of the P2 appearing as a USB drive. So easy to code an IDE to work with that.
What about supporting sd cards in a raw mode, it would not be hard to write a tool to "format" the sd card with proper data in the correct locations?
How much code is needed to get the prop pulling raw data off the card, ignoring any kind of file system or card size.
What about raw data pattern recognition methods for locating proper data on fat formated sd cards?
This might require a complete sd card spec and format/file windows manager tool for a "prop2" sd card partiton.
Couldn't a fat type structure exist wile still accessing raw data initially?
Files can be written to a specific spot on data medium, with proper tool.
And the prop could access raw data code from exact location on medium?
Throw all the file fat etc stuff out and just consider raw data interfacing sd cards in rom code?
Were talking exact data sructure to boot, no fancy file structure that the prop needs to "setup" to then find the proper file to boot.
But a windows tool could be made to write data to that spot on the sd card and then make fat entry for that data?
I am not sure what all is required to accomplish raw sd card data access though.
http://www.sandisk.com/Assets/File/OEM/Manuals/SD_SDIO_specsv1.pdf
It was optional on the microSD (aka Transflash) cards. A couple of cards were initialy released without SPI mode, but from what I understand, they received so much flack that they abandonded their thinking and put it back in. The SD cards have always mandated the SPI mode.
The current boot process requires SPI mode to be present and then commands switch to nibble mode. Therefore, all devices currently on the market use SPI mode initially. I think this is why it will remain a requiredment on all devices. However, if I am wrong,and later SPI mode is abandoned, then we have not lost anything to what was proposed... the Flash would be required. But with all the cameras and phones it would be one foolish manufacturer who decided to abandon the SPI mode given the users with equipment that currently use this mode. And this mode no longer requires a licence AFAIK because it was cleanroom decoded by the *nix group. In fact I believe they have cleanroom decoded the nibble mode too.
SPI Flash: I will leave others to verify that the flash can be left in nibble mode and requires a specific reset to take it out. Just on my way out atm.
Correct.
So far, it appears 0FFH clocked is a common reset.
Less clear, is how tolerant they are of various clock counts.
SST says this
The Reset Quad I/O instruction, FFH, resets the device to 1-bit SPI protocol operation. To execute a Reset Quad I/O operation, the host drives CE# low, sends the Reset Quad I/O command cycle (FFH) then, drives CE# high. The device accepts either SPI (8 clocks) or SQI (2 clocks) command cycles.
Microchip says this:
Exit SDI or SQI Mode
To exit from SDI mode, the RSTIO command must be issued. The command must be entered in the current device configuration, either SDI or SQI, see Figure 4-7 and Figure 4-8
A little more cryptic, but that sounds a little more constrained.
Winbond fig 7.2.20 suggests it needs Data HH and 8 clocks to exit Quad mode, and 16 clocks to exit Dual mode.
Universal might be : All Data pins HI then one of each of
a) CS=L, 2 Clks, CS=H == QuadRST
b) CS=L, 4 Clks, CS=H == DualRST
c) CS=L, 8 Clks, CS=H == SingleRST
d) CS=L, 16 Clks, CS=H == Winbond, Dual mode
- from here, single bit SPI mode should now work, on everyone, no matter what state it started in.
In most cases, the extra clocks will simply be redundant, but if frame counts matter, this covers those.
But then what happens to all the Prop devices without a flash? They're no longer usable.
I'm not suggesting it's not commercially viable, but it certainly has some characteristics that are cause for concern. We should support it when it's sensible to do so, not right now.
It is true that Chip has six weeks while the synthesis team wraps it up, but that time is going to be better spent counseling our staff on the Propeller 2 design so we can prepare the data sheet, documentation and resolve our programming tool plan. Supporting the boot process off of an SD card wouldn't be a top priority right now if it can wait - our tools and documentation are far more important.
Nobody manages Chip (he does whatever he wants according to history) but I believe it's in everybody's interest to encourage him to get Propeller 2 OTFD and to effectively communicate the design to our staff so we can get it documented properly.
So far what I have noticed, is people think that someone here is suggesting that flash eeprom booting should get REPLACED with sd card booting.
I don't think this is the case at all, i think people are only saying, they would like sd boot capability if possible after the normal eeprom, and other features are proper.
Sd boot?
Its more of a neat feature to be used by the "elite" prop2-ist who can find the miracle golden egg sd card that works with it.?
Is finding compatibility really that big of a golden egg? If so, im surprised sd cards made it so far.
So far the suggestions for use are:
-sd card booting code
-debug code
-USB storage device (how much space? tho)
?
I would like to formally withdraw my request to support booting with a QuadSPI (Winbond) or SQI (Microchip SST) device. I think there is too much risk. The most common denominator seems to be single bit SPI or other similar solutions for power on reset.
While it is possible to write code to reset these multi-bit devices to "single bit" SPI mode to ensure a proper read, the idea of it is not very pretty. The "reliable thing" to do from experience with flash in year's past would be to use the device ID available from the JEDEC command $9F to get the chip information and have the code initialize accordingly. JEDEC codes are supposed to be readable regardless of bit type settings.
While it is a fine idea to use a lookup in user code that is easy to change, requiring a data base of command sequences in a tiny mask ROM memory space to support N types of SPI flash just doesn't seem to make any sense.
Thanks,
--Steve