Yeah, write a bootloader that loads from SPI flash that will read and update firmware from SD card...
But Rayman's point was that some crude SD boot loader would allow a messed up SPI flash chip to be reprogrammed without needing a PC. He referred to the SPI flash as firmware, the way I read his post.
Critical path for this project is to finish the ROM code for the bootloader so we have the ability to talk to external memory, without SD if it is responsible for even a very minor delay. Any further changes require design time from Chip, layout from Beau and subsequent re-synthesis at a rate you may not imagine. There's more at stake here than everybody knows - and if you knew the whole story you might say "jettison the SD booting stuff, let's get it done!". We're losing traction all around this topic in my view: the synthesis company shifts energy elsewhere when we introduce delays, Chip is working non-stop around the clock (I don't know how much of that effort relates to booting from SD) and is very tired yet still enthusiastic, and the financial returns from a protracted design have diminishing returns.
Let's give Chip a break he doesn't know he needs and let him finish the project.
I agree with Phil and Ken.
As far as firmware is concerned... have an application specific SD loader in the EEPROM and the program on an SD card... really simple, works every time.
Want to update?... slip in a new SD card.
... I've relocated it to the bottom of memory, though the first 16 byte locations ($00000..$0000F) are going to be SRAM. I think they are useful for storing some system-wide status data, like freq, clkmode, etc. ROM will start at $00010 and cog0 will boot from there on power-up. ...
I'll highlight this one. There was a few people that weren't too keen on losing any of zero page.
This has been mentioned, but not discussed much ... We're not talking about an SD card that's bootable on both a PC and a P2. We're talking about an SD card that boots a P2 and is readable / writable using a standard PC OS, whether Windows, Linux, or the MacOS. As such, it needs a standard FAT16 or FAT32 partition plus another partition for P2 bootstrap use. This 2nd partition can have any format needed for P2 boot use. We would need a utility program to either initialize an SD card with such a partition or add such a partition to an existing card, possibly by shrinking an existing partition like many such utilities on the market today. We should have a version of this program for the P1 and P2 as well as cross platform (Windows, Linux, MacOS). If necessary for booting, we could insist that the boot partition be the first on the volume or insist that the partition be close to the beginning of the volume as was necessary for some old BIOSes or insist that a boot partition not be an "extended partition".
These 10 pages of posts are taking me a long time to plow through. Would it be okay if I just asked, at this point, whether a consensus has been reached on the best approach for SD boot?
Cluso has started another thread for testing SD card responses to the current init code.
The ROM's boot sequence after SD init is very simple: ID the MBR, grab the attached pointer to two consecutive raw blocks, load the 1kB of data there, authenticate, run.
This has been mentioned, but not discussed much ... We're not talking about an SD card that's bootable on both a PC and a P2. We're talking about an SD card that boots a P2 and is readable / writable using a standard PC OS, whether Windows, Linux, or the MacOS.
Yep, spot on.
As such, it needs a standard FAT16 or FAT32 partition plus another partition for P2 bootstrap use.
Repartitioning is completely optional. The ROM doesn't need to know. There is many ways with few limits. Including booting from a singular ext2/3/4 partition for example.
Since anything less than a fully FAT-aware system is going to cut some corners, is there a totally crude approach we could take that WOULD involve specially prepping an SD card, but would get us around needing a PC for reprogramming the SPI flash?
A special prep is fine, especially as it can slash ROM size, which is VERY important.
It does not exclude a Fully FAT aware solution using Flash, and I'd even document it so users do not expect the ROM to be 'all features'.
Do we have a final size for the prep'd ROM reader ?
.. I've relocated it to the bottom of memory, though the first 16 byte locations ($00000..$0000F) are going to be SRAM. I think they are useful for storing some system-wide status data, like freq, clkmode, etc. ROM will start at $00010 and cog0 will boot from there on power-up....
What does this gain, over Top placed ROM ? I'm sure this Some-RAM-Some-Rom-Some-Ram will bite users...
Can the very top ($FFFFFFFF) read from ROM ? (due to wrapping ?)
Any external memory cannot seamlessly patch above chip SRAM, as it has physically different access ?
Critical path for this project is to finish the ROM code for the bootloader so we have the ability to talk to external memory, without SD if it is responsible for even a very minor delay. Any further changes require design time from Chip, layout from Beau and subsequent re-synthesis at a rate you may not imagine. There's more at stake here than everybody knows - and if you knew the whole story you might say "jettison the SD booting stuff, let's get it done!". We're losing traction all around this topic in my view: the synthesis company shifts energy elsewhere when we introduce delays, Chip is working non-stop around the clock (I don't know how much of that effort relates to booting from SD) and is very tired yet still enthusiastic, and the financial returns from a protracted design have diminishing returns.
Let's give Chip a break he doesn't know he needs and let him finish the project.
ROM -- as much as needed for good function That are switched ACTIVE only in boot mode and load needed COG's. That give optimal use of RAM and as much space as needs to boot.
To that needs much extra work in Verilog code.
What does this gain, over Top placed ROM ? I'm sure this Some-RAM-Some-Rom-Some-Ram will bite users...
Can the very top ($FFFFFFFF) read from ROM ? (due to wrapping ?)
Any external memory cannot seamlessly patch above chip SRAM, as it has physically different access ?
Will You have HALF product on market as fast as possible.
Even if it ended yesterday, I would hardly call the Prop II's gestation period "as fast as possible." At some point you have to declare development finished, and save further research for the Next Great Thing. Don't forget: Parallax has to make a profit to sustain future projects. A company can easily go broke fussing, fiddling, and perfecting -- all at the expense of selling.
Great companies are inspired by their best engineers, but not run by them. There's a reason for that.
Critical path for this project is to finish the ROM code for the bootloader so we have the ability to talk to external memory, without SD if it is responsible for even a very minor delay. Any further changes require design time from Chip, layout from Beau and subsequent re-synthesis at a rate you may not imagine. There's more at stake here than everybody knows - and if you knew the whole story you might say "jettison the SD booting stuff, let's get it done!". We're losing traction all around this topic in my view: the synthesis company shifts energy elsewhere when we introduce delays, Chip is working non-stop around the clock (I don't know how much of that effort relates to booting from SD) and is very tired yet still enthusiastic, and the financial returns from a protracted design have diminishing returns.
Let's give Chip a break he doesn't know he needs and let him finish the project.
Personally I say scrap the SD boot and stick with I2C/SPI and serial load. If SD boot is desired it can be done via a routine via spi flash!
ROM -- as much as needed for good function That are switched ACTIVE only in boot mode and load needed COG's. That give optimal use of RAM and as much space as needs to boot.
To that needs much extra work in Verilog code.
That is a large change, and thus outside the scope.
Separate ROM has a small but definite speed cost, over RAM-as-ROM.
RAM-as-ROM is a good choice for small ROMs.
Chip: My condolences. ANd do take care with your health!
Commercial reality is that the 50c (plus inventory etc) may just be the difference between a desing win or not. Yes, it often does come down to that.
Requiring a PropPlug (even a cheap version) does cost money. Just because you have a connector doesn't mean users will not have to buy a PropPlug.
My method of placing a pointer on the MBR to 1 or 2 sectors where the boot cod is stored is the simplest and least likely to fail and yet does not demand any specific format or lcation on the card, other than using part of the MBR (or VBR) using precisely the area defined for the boot code to begin. Only a simple program to run on the P1 (already done and working - see my previously posted code), the P2 (mod the previous code), or write a new simple program for DOS, Windows, *nix, Mac, Android, etc that just finds the boot code (2 sectors) and writes a pointer to the MBR.
Simple, easy. If you want it to be in a partition you can have it, if you want it to be a file you can have it, if you want it to be a raw card you can have it - what's to lose? And it is fitting in around 150 longs but with P2 is likely to be smaller. There is no OS FATxx risk whatsoever.
Great companies are inspired by their best engineers, but not run by them. There's a reason for that.
Sheesh! Am I really quoting myself here? Well, anyway, as a one-man company, it's amazing I don't have a split personality. But just one word as an example: PropCam. (If anyone else dares utter that word in this context, I will hunt you down!)
What You need that speed to in ROM ---> if it has one shoot USAGE --- Only in boot sequence --- Some uSec then in my solution switched OF and only entire RAM addressing space used !!!
That is a large change, and thus outside the scope. Separate ROM has a small but definite speed cost, over RAM-as-ROM.
RAM-as-ROM is a good choice for small ROMs.
Before the ROM code gets finalized, I want to ask what others think about the following little change in the code:
It would be nice if we can load a binary also over a wireless serial connection. Cheap bluetooth or WiFi modules have
normally no DTR or RTS output to generate a Reset. But it will be possible to press the Reset button on the board and then start the download in the IDE, if the code waits long enough for serial data, before it boots from Flash.
I had a closer look at the current boot code that Chip has posted in this thread. The timeout is set now to 150ms. This is too short for manual reset with download. So I think it would make sense to check a pin and then set the timout longer according the state of this pin. (The RX pin is already checked to bypass the serial loader completly if set to Low).
This would add only 2 instructions, and spares the FTDI chip if you have anyway a wireless module connected.
What You need that speed to in ROM ---> if it has one shoot USAGE --- Only in boot sequence --- Some uSec then in my solution switched OF and only entire RAM addressing space used !!!
You are partly right here, given how ROM is actually used in a Prop, it could side-step the RAM Memory fetch entirely, and so avoid that speed cost, (in address decode), and instead patch directly into a COG somehow and load even from Serial ROM.
However, doing that is an even larger jump in scope. I have also seen serial memories that simply start reading on Clock, so do not have to have a Write-address first.
I had a closer look at the current boot code that Chip has posted in this thread. The timeout is set now to 150ms. This is too short for manual reset with download. So I think it would make sense to check a pin and then set the timout longer according the state of this pin. (The RX pin is already checked to bypass the serial loader completly if set to Low).
This would add only 2 instructions, and spares the FTDI chip if you have anyway a wireless module connected.
I agree (all the way back in #625, too!). I think the ability to use a wireless download is one of the most common "nice to have" features.
Note that to do so would require some sort of checking for download success. The wireless devices will drop packets, and it wouldn't do to run code that is incomplete.
. So I think it would make sense to check a pin and then set the timout longer according the state of this pin. (The RX pin is already checked to bypass the serial loader completly if set to Low).
This would add only 2 instructions, and spares the FTDI chip if you have anyway a wireless module connected.
Rather than a time-switch, why not a wait-until-hi - that allows more flexible handshake ? A FF triggered on serial data would allow system-flexible waits. I think the SPI pins have light pullups during boot ?
And could we add the ability to boot from a bar-code reader so I can scan my programs into the P2? Seriously guys, wouldn't you rather have the P2 sooner rather than wait for every suggestion to be incorporated into the chip?
I work every day in VHDL code. And know that that solution add only small amount of transistors to silicon.
BUT give as much address space as needed to have more powerful BOOT system.
As You can LOAD as many COG's You need for it before You change addressing from ROM to RAM.
If You look on picture -- It say all You need know on my solution.
You are partly right here, given how ROM is actually used in a Prop, it could side-step the RAM Memory fetch entirely, and so avoid that speed cost, (in address decode), and instead patch directly into a COG somehow and load even from Serial ROM.
However, doing that is an even larger jump in scope. I have also seen serial memories that simply start reading on Clock, so do not have to have a Write-address first.
I work every day in VHDL code. And know that that solution add only small amount of transistors to silicon.
BUT give as much address space as needed to have more powerful BOOT system.
ROMs are not usually coded in VHDL, usually they are foundary macros, with a regular pattern, and designed to allow 1 layer updates.
What you describe is a more classic ROM+RAM design, and certainly above a given size, that needs less silicon.
Another modern variant, is a dual-die scheme, and the Prop can work comfortably with Serial ROM
My personal preference is more ROM, and I see vendors like NXP now offering ROM usb loaders, and ROM CAN-Open libraries etc.
Not correctly classic as in classic -- You switch OF only some part of RAM.
This I describe switch entire RAM area OF -- as it don't needs in time of loading COG's -- And switch RAM ON -- after COG's loaded as in this time ROM are no longer needed.
But I agree with You on Dual die -- As that give re-programmability to Propeller core --- BUT still need some type of loader on Propeller die to function -- Still need that ROM area as it is NOW else again TRANSPARENT ROM that I describe to LOAD real LOADER code from it.
ROMs are not usually coded in VHDL, usually they are foundary macros, with a regular pattern, and designed to allow 1 layer updates.
What you describe is a more classic ROM+RAM design, and certainly above a given size, that needs less silicon.
Another modern variant, is a dual-die scheme, and the Prop can work comfortably with Serial ROM
My personal preference is more ROM, and I see vendors like NXP now offering ROM usb loaders, and ROM CAN-Open libraries etc.
Comments
Let's give Chip a break he doesn't know he needs and let him finish the project.
As far as firmware is concerned... have an application specific SD loader in the EEPROM and the program on an SD card... really simple, works every time.
Want to update?... slip in a new SD card.
Rich
I'll highlight this one. There was a few people that weren't too keen on losing any of zero page.
Cluso has started another thread for testing SD card responses to the current init code.
The ROM's boot sequence after SD init is very simple: ID the MBR, grab the attached pointer to two consecutive raw blocks, load the 1kB of data there, authenticate, run.
Yep, spot on.
Repartitioning is completely optional. The ROM doesn't need to know. There is many ways with few limits. Including booting from a singular ext2/3/4 partition for example.
A special prep is fine, especially as it can slash ROM size, which is VERY important.
It does not exclude a Fully FAT aware solution using Flash, and I'd even document it so users do not expect the ROM to be 'all features'.
Do we have a final size for the prep'd ROM reader ?
-Phil
What does this gain, over Top placed ROM ? I'm sure this Some-RAM-Some-Rom-Some-Ram will bite users...
Can the very top ($FFFFFFFF) read from ROM ? (due to wrapping ?)
Any external memory cannot seamlessly patch above chip SRAM, as it has physically different access ?
My only question to You are.
Will You have HALF product on market as fast as possible.
Else good product accepted by Designers that are on market.
I still advocate to separate parts --->
RAM --- Entire address space.
ROM -- as much as needed for good function That are switched ACTIVE only in boot mode and load needed COG's. That give optimal use of RAM and as much space as needs to boot.
To that needs much extra work in Verilog code.
Great companies are inspired by their best engineers, but not run by them. There's a reason for that.
-Phil
Personally I say scrap the SD boot and stick with I2C/SPI and serial load. If SD boot is desired it can be done via a routine via spi flash!
That is a large change, and thus outside the scope.
Separate ROM has a small but definite speed cost, over RAM-as-ROM.
RAM-as-ROM is a good choice for small ROMs.
Commercial reality is that the 50c (plus inventory etc) may just be the difference between a desing win or not. Yes, it often does come down to that.
Requiring a PropPlug (even a cheap version) does cost money. Just because you have a connector doesn't mean users will not have to buy a PropPlug.
My method of placing a pointer on the MBR to 1 or 2 sectors where the boot cod is stored is the simplest and least likely to fail and yet does not demand any specific format or lcation on the card, other than using part of the MBR (or VBR) using precisely the area defined for the boot code to begin. Only a simple program to run on the P1 (already done and working - see my previously posted code), the P2 (mod the previous code), or write a new simple program for DOS, Windows, *nix, Mac, Android, etc that just finds the boot code (2 sectors) and writes a pointer to the MBR.
Simple, easy. If you want it to be in a partition you can have it, if you want it to be a file you can have it, if you want it to be a raw card you can have it - what's to lose? And it is fitting in around 150 longs but with P2 is likely to be smaller. There is no OS FATxx risk whatsoever.
Sheesh! Am I really quoting myself here? Well, anyway, as a one-man company, it's amazing I don't have a split personality. But just one word as an example: PropCam.
-Phil
What You need that speed to in ROM ---> if it has one shoot USAGE --- Only in boot sequence --- Some uSec then in my solution switched OF and only entire RAM addressing space used !!!
It would be nice if we can load a binary also over a wireless serial connection. Cheap bluetooth or WiFi modules have
normally no DTR or RTS output to generate a Reset. But it will be possible to press the Reset button on the board and then start the download in the IDE, if the code waits long enough for serial data, before it boots from Flash.
I had a closer look at the current boot code that Chip has posted in this thread. The timeout is set now to 150ms. This is too short for manual reset with download. So I think it would make sense to check a pin and then set the timout longer according the state of this pin. (The RX pin is already checked to bypass the serial loader completly if set to Low).
This would add only 2 instructions, and spares the FTDI chip if you have anyway a wireless module connected.
Andy
You are partly right here, given how ROM is actually used in a Prop, it could side-step the RAM Memory fetch entirely, and so avoid that speed cost, (in address decode), and instead patch directly into a COG somehow and load even from Serial ROM.
However, doing that is an even larger jump in scope. I have also seen serial memories that simply start reading on Clock, so do not have to have a Write-address first.
I agree (all the way back in #625, too!). I think the ability to use a wireless download is one of the most common "nice to have" features.
Note that to do so would require some sort of checking for download success. The wireless devices will drop packets, and it wouldn't do to run code that is incomplete.
Rather than a time-switch, why not a wait-until-hi - that allows more flexible handshake ? A FF triggered on serial data would allow system-flexible waits. I think the SPI pins have light pullups during boot ?
I work every day in VHDL code. And know that that solution add only small amount of transistors to silicon.
BUT give as much address space as needed to have more powerful BOOT system.
As You can LOAD as many COG's You need for it before You change addressing from ROM to RAM.
If You look on picture -- It say all You need know on my solution.
transparent
It think is possible to write code for COG that can act as JTAG Serial mode loader without having extra hardware for it.
ROMs are not usually coded in VHDL, usually they are foundary macros, with a regular pattern, and designed to allow 1 layer updates.
What you describe is a more classic ROM+RAM design, and certainly above a given size, that needs less silicon.
Another modern variant, is a dual-die scheme, and the Prop can work comfortably with Serial ROM
My personal preference is more ROM, and I see vendors like NXP now offering ROM usb loaders, and ROM CAN-Open libraries etc.
Could code to allow loading the PII via JTAG fit in the extra ROM space?
Not correctly classic as in classic -- You switch OF only some part of RAM.
This I describe switch entire RAM area OF -- as it don't needs in time of loading COG's -- And switch RAM ON -- after COG's loaded as in this time ROM are no longer needed.
But I agree with You on Dual die -- As that give re-programmability to Propeller core --- BUT still need some type of loader on Propeller die to function -- Still need that ROM area as it is NOW else again TRANSPARENT ROM that I describe to LOAD real LOADER code from it.
If you mean proper JTAG, with BYPASS ability etc, then no, that would need specific hardware added.