It doesn't have to be. Those SPI flash's have a non-volatile config bit which causes those /WE and /HOLD pins to be ignored. When programming the flash chip, the loader doing the programming would set this bit for you (while driving /WE and /HOLD high), along with loading the code into the device. It won't matter after that, as those /WE and /HOLD pins will be don't-care.
Requiring that sounds to me like a support nightmare... - and I cannot see that bit in a Microchip SPI SRAM
[ added : Nor in the Winbond data, the config bit they have, QE, flips pins to Quad usage.]
Some users may want to boot from that new SPI SRAM, or the battery backed one, with tamper switches...
A user who only ever has 1 bit SPI, can still use these Quad pins, they just have a briefly defined light-hi during boot.
Have you confirmed that in tests, as that is not what the data sheets I have here say ?
(Add: Also as #632 says, those pins are /WE /HOLD in 1 bit mode and are now connected to Prop Pins )
QuadSPI is designed for speed, so some modes are 'sticky'.
Yes, a cold reset is to 1 bit mode, but a user may be in a Quad mode when a reset arrives.....
Right now, the booter is delivering three sets of $FFFFFFFF commands to knock chips out of special modes. I could do it once, but Kye thought a few whacks would be good.
I think it was a Winbond data sheet where I saw the non-volatile 'ignore /WE and /HOLD' bit. It will have to be that in the user's top-level file, he specifies what kind of memory he's using. There's no one-size-fits-all left in this complex world.
One question: do we still need to use an FTDI chip or other USB-serial chip to program P2 ?
Yes, unfortunately. This could be gotten around with enough ROM code to speak USB, though. We'd need to get a vendor ID, or emulate what FTDI does, as well.
Hmm... I'd almost go with SPI only boot then and make it 2-step boot process where the second stage can do USB...
Maybe second stage could do full FAT SD boot or USB...
Maybe stuck with SPI chip, but I'd much rather have a SPI/SQI flash chip required than the little I2C EEPROM of Prop I...
It would have a lot of space left over and high-speed access...
Right now, the booter is delivering three sets of $FFFFFFFF commands to knock chips out of special modes. I could do it once, but Kye thought a few whacks would be good.
Multiple frames sounds good - do you vary the clock counts ?
I would do 4 frames of 2/4/8/16 clocks, as mentioned earlier, with D0 hi, and D1..D3 /WE /HOLD in light-pull-up mode, in order to cover all the documented bases I could find.
If SD boot support is not added, would it still be possible to load an encrypted binary from one using the P2's encryption system?
The short answer is yes.
The long answer is that the P2 authenticates the second stage boot loader and executes that. The second stage boot loader is responsible for decrypting the user code. You could have unencrypted user code or implement any encryption algorithm in the second stage boot loader.
The likely scenarios for a second stage boot loader that chain loads from SD would be:
* Load second stage boot loader from SPI flash
* Authenticate boot loader
* Execute boot loader
* Boot loader loads overlay code from SPI flash and Authenticates it
* Boot loader uses overlay code to chain load encrypted firmware from SD card
* Boot loader authenticates encrypted payload to ensure it's not corrupted
* Boot loader decrypts payload in place
* Boot loader executes user firmware and releases control of chip
Move SD boot after SPI flash boot. Understand that you cannot have two SPI devices share the SPI bus with one CS pin. The SD card can share the SPI flash bus for booting. If you choose to go with SD card boot then you forfeit SPI flash booting and vice versa.
Now, SD card boot must happen after the SPI flash boot. This is because the SD card will ignore bogus data. While the SPI flash chip may interpret SD card traffic as a command. The SD card will look for the command 0x40 0x00 0x00 0x00 0x00 0x95 to be sent or it will not startup. The SPI flash chip on the other hand may respond to an SD card command accidentally.
...
Chip's time would be better spent as Ken said, documenting this beast. I do not believe in putting this one feature in to save the cost of 30 cents and hardwire in an inflexibility. But, I will help Chip out on understanding what needs to be done to support an SD card. Chip can go from there on what he wants to do...
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.
Interesting. "One clock" meaning no stalling at all, right? Lining up hub accesses is desirable even with the Prop1.
Now the next question becomes: What's it take to make the "cache" buffers valid?
That's right, plus they cost a lot more for the amount of storage you get. Here are the cheapest two 128k x 8 parts from Digikey, of each type:
I2C (2 pins), 1MHz, "CAT24M01WI-GT3", $0.94/1k units
SPI, (4 pins), 104MHz, "MX25L1006EMI-10G", $0.37/1k units
24LC64 in SOT23-5 are 0.33/100 (digikey 24LC64T-I/OTCT-ND), 24lc32 are slightly cheaper. Both are enough for a boot but are I2C. Both have been verified with the Prop 1.
But I am not advocating them. From my searches, there is nothing smaller than an SOIC8 for Flash which is larger than the TSSOP we mostly use on the P1.
Right now, the booter is delivering three sets of $FFFFFFFF commands to knock chips out of special modes. I could do it once, but Kye thought a few whacks would be good.
I think it was a Winbond data sheet where I saw the non-volatile 'ignore /WE and /HOLD' bit. It will have to be that in the user's top-level file, he specifies what kind of memory he's using. There's no one-size-fits-all left in this complex world.
This is good. I think the same sequence was required (I did the patch) to get the SD to release the DO pin.
Move SD boot after SPI flash boot. Understand that you cannot have two SPI devices share the SPI bus with one CS pin. The SD card can share the SPI flash bus for booting. If you choose to go with SD card boot then you forfeit SPI flash booting and vice versa.
Now, SD card boot must happen after the SPI flash boot. This is because the SD card will ignore bogus data. While the SPI flash chip may interpret SD card traffic as a command. The SD card will look for the command 0x40 0x00 0x00 0x00 0x00 0x95 to be sent or it will not startup. The SPI flash chip on the other hand may respond to an SD card command accidentally.
Agreed.
If you have Flash, then where the SD is located and which pins are shared is irrelevant. My request is to simply avoid requiring the Flash chip to be present if SD is used. However, Flash can be present withSD.
pin 89 = SPI CS
pin 88 = SPI CLK
pin 87 = SPI DI
pin 86 = SPI DO
*** THAT'S IT ***
Boot sequence:
1) Serial
2) SPI SD
3) SPI Flash
...And maybe a fuse bit could optionally reorder #2 and #3.
This way, booter pin use is tightly limited and if you wanted BOTH flash and SD, you could relocate the non-booting one's CS to another pin.
How would this be?
Chip: Would it not be better to
ROM BOOT------------------------------------------ RUN QUAD SPI
first second third third
SERIAL FLASH SD or SD
pin 91 = Serial RX
pin 90 = Serial TX
pin 89 = SPI CS SD CS SD CS SPI CS
pin 88 = SPI CLK SD CLK SD CLK SPI CLK
pin 87 = SD DO SPI IO3
pin 86 = SD DI SPI IO2
pin 85 = SPI DO(IO1) SD DO SPI IO1
pin 84 = SPI DI(IO0) SD DI SPI IO0
pin 83 = SPI IO3 *optional
pin 82 = SPI IO2 * dual
pin 81 = SPI IO1 * 4bit
pin 80 = SPI IO0 * spi
While I realise this leaves a 2 pin hole during boot, I think this is far better than requiring the use of a REV instruction to get the bits in the correct order, or munging a mix on the SPI to get it correct.
Remember we have nearly 3x the pins on P1, and even allowing for SDRAM we have more. Add to that from what you have said, we will only require 3 pins for VGA (not 8), etc.
There is another way rather than fuses to determine the boot order. You may recall that I discussed using a different value pullup resistor on 1 pin to determine a number of options using the onboard ADC. Perhaps using the SPI CLK pin with 100K/68K/27K to specify boot only from of: FLASH, SD, SERIAL (27K=SERIAL so that in an emergency, you can place a resistor in parallel with the 100K or 68K to make 27K to override the pcb board, so that serial booting is possible.
However, I am quite happy to boot SERIAL --> FLASH --> SD. If the flash gets corrupted, then serial is available.
The long answer is that the P2 authenticates the second stage boot loader and executes that. The second stage boot loader is responsible for decrypting the user code. You could have unencrypted user code or implement any encryption algorithm in the second stage boot loader.
The likely scenarios for a second stage boot loader that chain loads from SD would be:
* Load second stage boot loader from SPI flash
* Authenticate boot loader
* Execute boot loader
* Boot loader loads overlay code from SPI flash and Authenticates it
* Boot loader uses overlay code to chain load encrypted firmware from SD card
* Boot loader authenticates encrypted payload to ensure it's not corrupted
* Boot loader decrypts payload in place
* Boot loader executes user firmware and releases control of chip
Thanks for the answer, pedward. Is it safe to assume that the same utility that generates the encrypted code stored in SPI flash could also be used to generate the encrypted program stored in SD, given that the second stage boot loader uses the same algorithm as the first stage boot loader?
Thanks for the answer, pedward. Is it safe to assume that the same utility that generates the encrypted code stored in SPI flash could also be used to generate the encrypted program stored in SD, given that the second stage boot loader uses the same algorithm as the first stage boot loader?
Yes, the Crypto Wizard will need to be able to sign downloads and files. Hopefully we can agree on an encapsulated format that can be used in FLASH and on filesystem.
Something like HASH+IV+DATA would work.
HASH = SHA-256 HMAC of DATA
IV = AES-128 Initialization Vector
DATA = AES-128+CBC encrypted data
If you do a cached read (RDxxxxC) and the cache is not valid and in range (cache miss) the instruction's timing becomes exactly like a normal RDxxxx instruction. When a RDxxxxC is a cache-miss, it loads 4 longs (16 bytes) from the address range %x_xxxxxxxx_xxxx0000..%x_xxxxxxxx_xxxx1111. Thereafter, RDxxxxC instructions which access a location in that range take just one clock. If you do RDBYTEC instructions on a long stretch of hub memory, every 16th instruction will time like a RDBYTE, while every one in-between will take just one clock.
Sorry - should have qualified that with "except for QFN style chips". I am still a little hesitant abour using these even professionally where an external assembly plant is used. Just me I guess.
Sorry - should have qualified that with "except for QFN style chips". I am still a little hesitant abour using these even professionally where an external assembly plant is used. Just me I guess.
We have had a lot of trouble at Parallax with soldering leadless IC's, too. They are a pain. I totally blame the lousy solder chemistry that has been forced on us. Eutectic tin/lead always worked perfectly. Now, we have poor wetting and a long plastic state during cooling.
I had a 3-hour conversation with Kye tonight and he took me through the details of mounting and reading an SD card. It's not trivial like SPI flash is. I think SD booting could be done, but it would take some time to ensure that it gets done correctly. I'm going to read some more about this and study the code that Cluso posted and Kye gave me. Thanks for all your input, everybody! Please feel free to keep making suggestions.
Hmm... I'd almost go with SPI only boot then and make it 2-step boot process where the second stage can do USB...
Maybe second stage could do full FAT SD boot or USB...
Maybe stuck with SPI chip, but I'd much rather have a SPI/SQI flash chip required than the little I2C EEPROM of Prop I...
It would have a lot of space left over and high-speed access...
Rayman, I think this is the way complex things like USB and SD cards may have to work, until we prove the software and make a much bigger ROM to put them in. Serial and SPI flash are simple and known, whereas the others are maybe too big of bites to take, at first.
Then back to my original MONITOR ... simple cmd-orientated serial HUB-monitor... You could also jump there if nothing found to boot or on unhandled aborts. At least you can look at the hub-ram and find out why....
I had a 3-hour conversation with Kye tonight and he took me through the details of mounting and reading an SD card. It's not trivial like SPI flash is. I think SD booting could be done, but it would take some time to ensure that it gets done correctly. I'm going to read some more about this and study the code that Cluso posted and Kye gave me. Thanks for all your input, everybody! Please feel free to keep making suggestions.
While I agree it is not as trivial as Flash, it is relatively simple to read the SD card in raw mode - which is what we are doing. There is no FAT which is where a lot of the inconsistencies come from. We only want/require the basics. This removes much of the problems of the files system from the equation. The secondary boot process is what will take the time, and that is soft so we have time to experiment, and also if required support newer file formats if we wish.
Chip, I am sorry. Did not get a chance today to remove some more of the FAT (mount) code from my code postings. I don't expect time tomorrow either as I have to drive to Brisbane again (its ~10 hours). Rest assured, I will continue this. We can do it safely provided we make it the 3rd boot. If there are unintended restrictions on the cards or formats, so be it - it will be much better than none at all. FYI currently we are sitting at ~4.5KB. Removing the eeprom code will reduce by about 2KB, and the SD SPI code will be smaller using the new instruction set. Hopefully we can use some of the routines from the Flash as well. I fully realise that we have to replace the spin code (which will be larger) but there is not a great deal going on once I remove the code not required. My guess is that it will be << 1KB extra space.
While I agree it is not as trivial as Flash, it is relatively simple to read the SD card in raw mode - which is what we are doing. There is no FAT which is where a lot of the inconsistencies come from. We only want/require the basics. This removes much of the problems of the files system from the equation. The secondary boot process is what will take the time, and that is soft so we have time to experiment, and also if required support newer file formats if we wish.
Chip, I am sorry. Did not get a chance today to remove some more of the FAT (mount) code from my code postings. I don't expect time tomorrow either as I have to drive to Brisbane again (its ~10 hours). Rest assured, I will continue this. We can do it safely provided we make it the 3rd boot. If there are unintended restrictions on the cards or formats, so be it - it will be much better than none at all. FYI currently we are sitting at ~4.5KB. Removing the eeprom code will reduce by about 2KB, and the SD SPI code will be smaller using the new instruction set. Hopefully we can use some of the routines from the Flash as well. I fully realise that we have to replace the spin code (which will be larger) but there is not a great deal going on once I remove the code not required. My guess is that it will be << 1KB extra space.
Cluso,
No worries. I am still open to doing this if we can do it simply and certainly. We've got 660 bytes of ROM left. That's it. I can wait a few days and work on other stuff while you come up with a plan.
In talking to Kye, I realized that it might be good practice to use a CTR to generate the SPI_CLK signal, so that it is continuous. These SD cards have complex state machines in them that might run better if allowed to keep clocking while you wait on them, etc. He was telling me about many corner cases where you need to provide several extra clocks after or before commands, in order for things to work right. Might be easier to give it a continuous clock and just mesh CS/DI/DO activity into it.
Then back to my original MONITOR ... simple cmd-orientated serial HUB-monitor... You could also jump there if nothing found to boot or on unhandled aborts. At least you can look at the hub-ram and find out why....
Enjoy!
Mike
A command-based monitor is cool because it doesn't need any other COG to feed its data structures or interact with it - commands come from a serial host and results go back to the host. It only needs to be started.
Wait! this could only be automatically launched on boot-fail if all the security fuse bits were 0's (not set, so no key was in use). Otherwise, this would be a huge back door past security. You know, it could even serve, incidentally, as a text-based loading mechanism that would be trivial to operate.
I have don't reflected first time I read it ---- BUT it need be that to function correctly
To this Swap fuse and NO more is needed to be possible to reuse it in SYSTEM after boot --->
Serial always first --- Only if You add fuse to disable it that NOT serial boot -- But that You decide
Default boot --> Flash only
Alternate
> SD then Flash
HOW ABOUT THIS?
pin 91 = Serial RX
pin 90 = Serial TX
I have don't reflected first time I read it ---- BUT it need be that to function correctly
To this Swap fuse and NO more is needed to be possible to reuse it in SYSTEM after boot --->
Serial always first --- Only if You add fuse to disable it that NOT serial boot -- But that You decide
Default boot --> Flash only
Alternate
> SD then Flash
HOW ABOUT THIS?
pin 91 = Serial RX
pin 90 = Serial TX
I considered that pin mapping, too, but because pins 87..80 are Byte3 of PortC, they need to be used for potentially-multiple data bits, as this allows efficient MOVF instructions to grab 4 or 8 bits at a time and pack them into a variable quickly. If they were shifted down by one, you couldn't read or write them very efficiently.
Maybe we should formulate the goals to archive and then decide what to do:
#1 Cluso wants to have the ability to build a board without flash IF he needs sd anyway. Else boot from flash ok.
#2 Me and others where speaking about Firmware-updates in the field where flashing/serial with a pc is not available.
Are there Flash in sockets? this would eliminate #2
I still think #1 is valuable.
having Flash and sd on the same pins is not sensible - see c3. If you have flash sd can be anywhere if needed with full fat-support.
but booting from removabe media is way cool. since we can create any bootable sd on a prop or make it bootable there. what about those unused sectors after the mbr? we need 8 sectors for a cog. Just read sector 3 to 11. start what is there to do more.
or - forget about it and put my MONITOR in.
@chip why backdoor? If it fails to load the program in the first place there is nothing to protect ?
If it does this because of an abort? hm. a fuse to disable onboard monitor?
having the ability to write to the hub via serial-debug and start a cog with some adress? THAT would be cool.
and having some standard adress to jump to for starting a MONITOR without wasting precious program-code is very tempting.
Comments
Requiring that sounds to me like a support nightmare...
[ added : Nor in the Winbond data, the config bit they have, QE, flips pins to Quad usage.]
Some users may want to boot from that new SPI SRAM, or the battery backed one, with tamper switches...
A user who only ever has 1 bit SPI, can still use these Quad pins, they just have a briefly defined light-hi during boot.
I will add pull-ups on my board anyway and use a DIP8 socket just in case for a while at least
Right now, the booter is delivering three sets of $FFFFFFFF commands to knock chips out of special modes. I could do it once, but Kye thought a few whacks would be good.
I think it was a Winbond data sheet where I saw the non-volatile 'ignore /WE and /HOLD' bit. It will have to be that in the user's top-level file, he specifies what kind of memory he's using. There's no one-size-fits-all left in this complex world.
Yes, unfortunately. This could be gotten around with enough ROM code to speak USB, though. We'd need to get a vendor ID, or emulate what FTDI does, as well.
Maybe second stage could do full FAT SD boot or USB...
Maybe stuck with SPI chip, but I'd much rather have a SPI/SQI flash chip required than the little I2C EEPROM of Prop I...
It would have a lot of space left over and high-speed access...
If SD boot support is not added, would it still be possible to load an encrypted binary from one using the P2's encryption system?
Multiple frames sounds good - do you vary the clock counts ?
I would do 4 frames of 2/4/8/16 clocks, as mentioned earlier, with D0 hi, and D1..D3 /WE /HOLD in light-pull-up mode, in order to cover all the documented bases I could find.
- but you cannot rely on such a bit even existing, so you need to also do the light pullup on likely-connected pins, in the ROM loader.
The short answer is yes.
The long answer is that the P2 authenticates the second stage boot loader and executes that. The second stage boot loader is responsible for decrypting the user code. You could have unencrypted user code or implement any encryption algorithm in the second stage boot loader.
The likely scenarios for a second stage boot loader that chain loads from SD would be:
* Load second stage boot loader from SPI flash
* Authenticate boot loader
* Execute boot loader
* Boot loader loads overlay code from SPI flash and Authenticates it
* Boot loader uses overlay code to chain load encrypted firmware from SD card
* Boot loader authenticates encrypted payload to ensure it's not corrupted
* Boot loader decrypts payload in place
* Boot loader executes user firmware and releases control of chip
Now, SD card boot must happen after the SPI flash boot. This is because the SD card will ignore bogus data. While the SPI flash chip may interpret SD card traffic as a command. The SD card will look for the command 0x40 0x00 0x00 0x00 0x00 0x95 to be sent or it will not startup. The SPI flash chip on the other hand may respond to an SD card command accidentally.
...
Chip's time would be better spent as Ken said, documenting this beast. I do not believe in putting this one feature in to save the cost of 30 cents and hardwire in an inflexibility. But, I will help Chip out on understanding what needs to be done to support an SD card. Chip can go from there on what he wants to do...
Thanks,
Interesting. "One clock" meaning no stalling at all, right? Lining up hub accesses is desirable even with the Prop1.
Now the next question becomes: What's it take to make the "cache" buffers valid?
24LC64 in SOT23-5 are 0.33/100 (digikey 24LC64T-I/OTCT-ND), 24lc32 are slightly cheaper. Both are enough for a boot but are I2C. Both have been verified with the Prop 1.
But I am not advocating them. From my searches, there is nothing smaller than an SOIC8 for Flash which is larger than the TSSOP we mostly use on the P1.
If you have Flash, then where the SD is located and which pins are shared is irrelevant. My request is to simply avoid requiring the Flash chip to be present if SD is used. However, Flash can be present withSD.
This is very important.
As I understand it, if you miss the window it's similar to the current Propeller except that you get more instructions between HUB cycles.
Chip: Would it not be better to
ROM BOOT------------------------------------------ RUN QUAD SPI first second third third SERIAL FLASH SD or SD pin 91 = Serial RX pin 90 = Serial TX pin 89 = SPI CS SD CS SD CS SPI CS pin 88 = SPI CLK SD CLK SD CLK SPI CLK pin 87 = SD DO SPI IO3 pin 86 = SD DI SPI IO2 pin 85 = SPI DO(IO1) SD DO SPI IO1 pin 84 = SPI DI(IO0) SD DI SPI IO0 pin 83 = SPI IO3 *optional pin 82 = SPI IO2 * dual pin 81 = SPI IO1 * 4bit pin 80 = SPI IO0 * spiWhile I realise this leaves a 2 pin hole during boot, I think this is far better than requiring the use of a REV instruction to get the bits in the correct order, or munging a mix on the SPI to get it correct.
Remember we have nearly 3x the pins on P1, and even allowing for SDRAM we have more. Add to that from what you have said, we will only require 3 pins for VGA (not 8), etc.
There is another way rather than fuses to determine the boot order. You may recall that I discussed using a different value pullup resistor on 1 pin to determine a number of options using the onboard ADC. Perhaps using the SPI CLK pin with 100K/68K/27K to specify boot only from of: FLASH, SD, SERIAL (27K=SERIAL so that in an emergency, you can place a resistor in parallel with the 100K or 68K to make 27K to override the pcb board, so that serial booting is possible.
However, I am quite happy to boot SERIAL --> FLASH --> SD. If the flash gets corrupted, then serial is available.
Thanks for the answer, pedward. Is it safe to assume that the same utility that generates the encrypted code stored in SPI flash could also be used to generate the encrypted program stored in SD, given that the second stage boot loader uses the same algorithm as the first stage boot loader?
Yes, the Crypto Wizard will need to be able to sign downloads and files. Hopefully we can agree on an encapsulated format that can be used in FLASH and on filesystem.
Something like HASH+IV+DATA would work.
HASH = SHA-256 HMAC of DATA
IV = AES-128 Initialization Vector
DATA = AES-128+CBC encrypted data
If you do a cached read (RDxxxxC) and the cache is not valid and in range (cache miss) the instruction's timing becomes exactly like a normal RDxxxx instruction. When a RDxxxxC is a cache-miss, it loads 4 longs (16 bytes) from the address range %x_xxxxxxxx_xxxx0000..%x_xxxxxxxx_xxxx1111. Thereafter, RDxxxxC instructions which access a location in that range take just one clock. If you do RDBYTEC instructions on a long stretch of hub memory, every 16th instruction will time like a RDBYTE, while every one in-between will take just one clock.
We have had a lot of trouble at Parallax with soldering leadless IC's, too. They are a pain. I totally blame the lousy solder chemistry that has been forced on us. Eutectic tin/lead always worked perfectly. Now, we have poor wetting and a long plastic state during cooling.
Rayman, I think this is the way complex things like USB and SD cards may have to work, until we prove the software and make a much bigger ROM to put them in. Serial and SPI flash are simple and known, whereas the others are maybe too big of bites to take, at first.
so the rom space is back in the race!
Then back to my original MONITOR ... simple cmd-orientated serial HUB-monitor... You could also jump there if nothing found to boot or on unhandled aborts. At least you can look at the hub-ram and find out why....
Enjoy!
Mike
While I agree it is not as trivial as Flash, it is relatively simple to read the SD card in raw mode - which is what we are doing. There is no FAT which is where a lot of the inconsistencies come from. We only want/require the basics. This removes much of the problems of the files system from the equation. The secondary boot process is what will take the time, and that is soft so we have time to experiment, and also if required support newer file formats if we wish.
Chip, I am sorry. Did not get a chance today to remove some more of the FAT (mount) code from my code postings. I don't expect time tomorrow either as I have to drive to Brisbane again (its ~10 hours). Rest assured, I will continue this. We can do it safely provided we make it the 3rd boot. If there are unintended restrictions on the cards or formats, so be it - it will be much better than none at all. FYI currently we are sitting at ~4.5KB. Removing the eeprom code will reduce by about 2KB, and the SD SPI code will be smaller using the new instruction set. Hopefully we can use some of the routines from the Flash as well. I fully realise that we have to replace the spin code (which will be larger) but there is not a great deal going on once I remove the code not required. My guess is that it will be << 1KB extra space.
Cluso,
No worries. I am still open to doing this if we can do it simply and certainly. We've got 660 bytes of ROM left. That's it. I can wait a few days and work on other stuff while you come up with a plan.
In talking to Kye, I realized that it might be good practice to use a CTR to generate the SPI_CLK signal, so that it is continuous. These SD cards have complex state machines in them that might run better if allowed to keep clocking while you wait on them, etc. He was telling me about many corner cases where you need to provide several extra clocks after or before commands, in order for things to work right. Might be easier to give it a continuous clock and just mesh CS/DI/DO activity into it.
A command-based monitor is cool because it doesn't need any other COG to feed its data structures or interact with it - commands come from a serial host and results go back to the host. It only needs to be started.
Wait! this could only be automatically launched on boot-fail if all the security fuse bits were 0's (not set, so no key was in use). Otherwise, this would be a huge back door past security. You know, it could even serve, incidentally, as a text-based loading mechanism that would be trivial to operate.
I have don't reflected first time I read it ---- BUT it need be that to function correctly
To this Swap fuse and NO more is needed to be possible to reuse it in SYSTEM after boot --->
Serial always first --- Only if You add fuse to disable it that NOT serial boot -- But that You decide
Default boot --> Flash only
Alternate
> SD then Flash
HOW ABOUT THIS?
pin 91 = Serial RX
pin 90 = Serial TX
pin 89 = SPI CSF
> Flash
pin 88 = SPI CSD
> SD
pin 87 = SPI CLK
pin 86 = SPI DI
pin 85 = SPI DO
*** THAT'S IT ***
I considered that pin mapping, too, but because pins 87..80 are Byte3 of PortC, they need to be used for potentially-multiple data bits, as this allows efficient MOVF instructions to grab 4 or 8 bits at a time and pack them into a variable quickly. If they were shifted down by one, you couldn't read or write them very efficiently.
#1 Cluso wants to have the ability to build a board without flash IF he needs sd anyway. Else boot from flash ok.
#2 Me and others where speaking about Firmware-updates in the field where flashing/serial with a pc is not available.
Are there Flash in sockets? this would eliminate #2
I still think #1 is valuable.
having Flash and sd on the same pins is not sensible - see c3. If you have flash sd can be anywhere if needed with full fat-support.
but booting from removabe media is way cool. since we can create any bootable sd on a prop or make it bootable there. what about those unused sectors after the mbr? we need 8 sectors for a cog. Just read sector 3 to 11. start what is there to do more.
or - forget about it and put my MONITOR in.
@chip why backdoor? If it fails to load the program in the first place there is nothing to protect ?
If it does this because of an abort? hm. a fuse to disable onboard monitor?
having the ability to write to the hub via serial-debug and start a cog with some adress? THAT would be cool.
and having some standard adress to jump to for starting a MONITOR without wasting precious program-code is very tempting.
Enjoy!
Mike