I think this perceived requirement to have SD booting as a feature in order to be accepted by engineers is unfounded. I think a few of you are projecting your own desires out to everyone.
Chip, I urge you to drop SD card booting of any kind. If you don't, then it's going to be no end of problems...
I have now even tested FAT32 formated SD-4GB by that method I described before and it have 6000 free before first Partition.
And are safe from 1800 Hex to place BOOT.binary ( that even not disturb my CAMERA )
On FAT16 type form sector 2 to 49 safe
So only need is to place that file on SD and by Andy's Loader -- It will boot in no time.
If you buy the spec from the SD association then the boot loader cannot be open source. So, it needs to be implemented with what we already have.
If true, what that means is that you are either:
a) Using closed source code and tieing the Propeller to the SD association. An all together horrible situation.
b) Putting code into the Prop II ROM withouout any solid standard to work from. Also an all together horrible situation.
I know Cluso is doing is best to find out what SD cards do what, but this trial and error is not how engineering should proceed,
On top of that there are other issues:
a) I seriously do not believe that the lack of boot from SD will have any impact on Prop II market opportunities. It's a micro-controller for Gods sake. Booting from SD makes some kind of sense for an ARM system that will end up running Linux or other OS where you for sure will need a couple of gigs file system for your OS. For an MCU no.
b) Those few who want/need a huge file system on thier MCU can tolerate a few cents for an I2C/SPI boot ROM as normal.
c) If this boot from SD code takes even one byte away from the HUB RAM that is too much. RAM, even on the Prop II is a precious resource.
I completely agree on dropping SD card boot. Honestly, what chip that exists and will be competing with Prop II, supports SD boot? Heck: I used one ARM board once that needed a small NOR flash in order to boot off NAND flash; it had both.
I wonder, would it be possible to swap on the 6T-SRAM for 7T-SRAM with reset? Could "ROM" be done by having the reset mode of some cells be different than others, in order to make the ROM code? That way we wouldn't lose the RAM space for ROM, but would still be able to boot easily.
I think this perceived requirement to have SD booting as a feature in order to be accepted by engineers is unfounded. I think a few of you are projecting your own desires out to everyone.
Chip, I urge you to drop SD card booting of any kind. If you don't, then it's going to be no end of problems...
I couldn't agree more with Roy. Chip has told us he is sick and that he is tired. Ken Gracey has already told us "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!"."
I would strongly suggest people read between the lines. The Prop2 has been costing Parallax a fortune. They can't afford to spend more time on it. It's time to forget SD booting, get the Prop2 OTFD and move on.
Given that I never understood the draw of SD booting in the first place... I have already entered my negative vote. I figured a USB-HID loader might be handy, but I'm not sure the clock/PLL could be synchronized with only the USB enumeration as a timing source, even with Low Speed, so I'm not too stuck on that.
Really, name any other micro with mask ROM that works with SD or any type of mass storage. Even ARM7/Cortex-M devices don't boot off SD, and I'm not sure any Cortex-R devices do either. All the ARM9's that do are 400+MHz and have MMUs. It's just not that worth it, and not that much of a selling point, either.
It seems very safe to put a pointer in the MBR to indicate where start the contiguous read of firmware. With the second partition you guarantee that the firmware remains contiguous. The loaded firmware will provide support for FAT or any other FS desired by the developer. To here it seems all safe. Cluso and Ariba has shown that the code will fit in the 150 longs. So why not? Even if it boots only from a selected group of SDs is better than nothing. The ones wanting the SPI flash can have it, it's not precluded. The ones using the flash and SD can wire the SD on different pins, also this is not precluded. So why not?
I really wonder about that cost / market dynamic myself. Time to market costs are serious and have been growing for some time. There is a window of applicability, and a clear "prime" time for product introduction. Every month that time goes by without the product there in the market means very serious opportunity costs, in addition to the already significant development costs. Those opportunity costs compound too!
There are the sales that do not happen because the product isn't there. There is the potential for overall market share mixed in with that too. As people get established on products they've selected, they become reluctant to select different ones, raising the barrier to entry, which compounds the opportunity costs.
An opportunity cost is basically money left on the table, never to be earned.
Right now, this entire SD discussion is "chasing the window" in some attempt to engineer more quickly than the product viability window evolves. Sometimes this makes sense, but it's extremely expensive and risky to do. Chasing that window compounds the costs even further as raising expectations and adding features increases product cost, the window continues to move, and all the dollars required for that likely will dilute the dollars needed to properly promote the product, further compounding opportunity costs.
Folks, right now, today, there are millions of dollars that won't ever be earned at Parallax, despite a very significant and sustained investment. That impacts the future of the company and for the most part, those impacts are permanent. New products can meet future windows, but this product, and it's viability window are happening right now, and that window is prime right now, or close to prime. Frankly, I don't see it improving too much, and when it peaks, it's a slow downhill from there.
To do it right, the product needs to be there for early adopters and at the very least, the early majority. That revenue is the highest margin, with diminishing returns beyond the majority. I can link a ton of information about how the earning potential of a product is impacted by failing to reach the market during the early viability time. It's ugly. Really ugly. A product can easily be worth half, and the half can happen over a span of mere months for some products too.
It is true that Parallax will sell products for a long time, but what they get for doing that could be significantly different depending on when they get the product out there for sale, and this is the final compounding effect:
If they miss their prime window, they could get half of what the product was really worth. Half. What impact does that have?
Where do you think the capital required to build the next product and innovate comes from? Missing this could resign Parallax to a niche, unable to build to compete on the next level. That's the kind of stuff we are talking about here, and that's the "nontrivial" Ken is trying very nicely to articulate.
That's not a gloom and doom message, though I can't speak for Ken. I honestly don't think it's that. More like a potential wasted, opportunities gone message, and while not the same thing as doom, still very unpleasant, if the objective is to make it here in the USA, pay people well, capitalize against risk, fund development and do all the great things a company can do.
Want to see the great things? Then support Parallax in getting a great product out there now while there remains time to be great. The early adopters are buying now. Competitors are being established now. Trends, preferences, efforts, market shares, etc... are being decided now. Those things are all very big multiples, and they matter, and they matter now.
Wait another year or two? They won't matter as much, and neither will Parallax, and the great things we know they can do, and are eager to see them do, simply move off the table, gone, never to exist.
Sorting this out for companies is part of what I do for a living. I've seen companies spend insane amounts of money and devote huge labor resources to attacking this problem, and they do it because the returns are so large they can't afford not to. Fact.
To be perfectly frank, P1 suffered from this. An earlier release would have been much better aligned with the trends we enjoy currently. Several key players were established during that time, and had even one of them adopted the P1, the revenue story would be much different.
Now, consider that and the constraints on software development, research, testing, simulation, etc... in play right now, and the impact of that on when we get P2. Look at all the players starting to establish right now! Again, being a part of that or not will very significantly impact the revenue from this effort, and it compounds over and over....
To be perfectly frank again, P2 is currently suffering from this. Weeks matter. Even days do. However, given sufficient delay, neither will matter, and that's something for everybody to think about. Most importantly, is this viable being a small niche? Seriously? Bet you Ken is wondering that big right now. I am too.
I think trying to read the FAT table from the SD card every time you boot would take up too much ROM space and take too much time...
Raw block mode would be more reliable, simpler and faster...
Doh! Sigh. Read the whole topic. The only thing the ROM sees is a pointer to two raw blocks. The ROM knows nothing about any filesystem no matter what volume type is chosen. Any filesystem can exist on that partition/volume.
I think this perceived requirement to have SD booting as a feature in order to be accepted by engineers is unfounded. I think a few of you are projecting your own desires out to everyone.
Chip, I urge you to drop SD card booting of any kind. If you don't, then it's going to be no end of problems...
+1
A long way back in this thread, I asked if there were any P2 competitors that booted from SD, nobody really came up with anything.
People are throwing around that it's needed for marketability. Is that a real market demand or a perceived market demand or a wished for market demand?
The good points against supporting it are far outweighing the points for supporting it.
Get the product out the door on time. That should be the focus, not one more last minute feature. That has been the death of a lot more than one project.
To do it right, the product needs to be there for early adopters and at the very least, the early majority. That revenue is the highest margin, with diminishing returns beyond the majority. I can link a ton of information about how the earning potential of a product is impacted by failing to reach the market during the early viability time. It's ugly. Really ugly. A product can easily be worth half, and the half can happen over a span of mere months for some products too.
Doing it right also includes all the infrastructure (infrastructure is infrastructure, regardless of product) needed to launch and support the product for early adopters. If the support and documentation isn't there at launch, then people get turned off the product/company and find other alternatives. As Ken said earlier, Chip's time and efforts are better spent elsewhere at some point. This debate has reached that point.
Or, maybe that fuse bit that was discussed could be blown to allow SD boot, instead of prevent it...
That way, no SD would be the default...
This is called a CYA bit (also known as an ACB). It can be viewed in different ways depending on how things work out.
Another way that I've seen chip designers handle this is by calling a feature bit a "reserved bit". That is: "reserved and should always be in a certain state otherwise results may not be predictable." Once there is more solid information/evidence available, the feature can be fully documented.
Chip, I like that you have put the ROM boot stub in the lower section of memory because it is a *manageable* hole. I request however that you move the offset up to address $80 because we may want to have 32bit pointers and other values in the lower memory for *immediate* HUB access in PASM as is practiced by some today i.e., "rdlong value, #LOWADDR".
I'm sad to hear of the recent loss in your family Chip. God bless you, your wife, and beautiful children.
--Steve
While I'd like SD boot, I'd prefer the Prop2 sooner What I did not like was requiring the boot media to be FAT formatted.
I don't mind putting a <$0.40 flash chip on my boards, which could boot from SD if it detects an inserted card with the right "signature offset" in the MBR.
I am still not sure about removing direct addressing of the first 256 bytes in the hub; even though I like the larger index it makes possible.
I'm not really following this ? Do you know exactly how much RAM finally fits ? is it a clean 128k, or might 140k, or 156k fit ?
The amount of memory is set in silicon, at this point, and cannot be changed. The memory exists as four instances of an 8192 x 32 SRAM that we designed. Some of the SRAM bit cells are going to be replaced by ROM bits so that the chip has some initial functionality after reset, so that user code can be loaded into the SRAM (I know you know this part, jmg, I'm just spelling it out for everyone). So, we have byte addresses $00000..$1FFFF that wrap around, effectively giving us a 17-bit address bus. The only questions have been how much SRAM do we convert to ROM, where do we locate the ROM address space, and what does the ROM do. Right now, we are set up to have RAM from $00000..$0000F, then ROM from $00010..$00xxx, then SRAM from $00xxx+1..$1FFFF. It's looking like without SD boot, $00xxx will be equal to $007FF. With SD boot, it would get a little higher.
... With the second partition you guarantee that the firmware remains contiguous ...
All methods guarantee integrity, and all but one are contiguous. And that one is explicitly designed to not require it. Most importantly, none of them add any additional burden on the ROM code.
Off the top of my head for SD card booting there can be support for:
- Prebuilt image written to raw blocks. No partition, no volume. Everything contained in the image. This is a direct alternative to a SPI flash.
- Prebuilt image written to raw blocks within custom partition. Ditto for SPI flash.
- Bootloader written to raw blocks within custom partition. This contains filesystem handler code for booting main program from a second partition containing a filesystem.
- Bootloader written to raw blocks within reserved space of FAT volume. Ditto for filesystem handler code.
- Bootloader written to contiguous file within FAT volume. Ditto for filesystem handler code.
- Bootloader written to non-contiguous file within FAT volume. It has a split loader for handling the distribution of it's blocks or clusters. Ditto for filesystem handler code.
All of those are supportable with the tiny ROM code as planned - simply loading two blocks via a pointer.
What I did not like was requiring the boot media to be FAT formatted.
Certainly isn't being required.
No reason why most of those above FAT methods can't be applied to other filesystems also. After all, Grub does exactly this on a multitude of filesystems.
I think I have said this before but, oh man I love it when you talk MBA:)
Anyway I agree "ship the damn thing ASAP". We can buy it and have years of fun. Parallax gets money. Chip can take time out to enjoy his walnut farm and family. Then we can regroup for the Prop III debate:)
Circuitsoft is spot on. No other MCU boots off SD so why waste time on this feature and the SOC's that do have the feature like the one in the Raspberry are way out of the market segment that Parallax can compete in.
Just drop it. If the fanbois want it, left them roll their own FPGA.
Circuitsoft is spot on. No other MCU boots off SD so why waste time on this feature and the SOC's that do have the feature like the one in the Raspberry are way out of the market segment that Parallax can compete in.
Just drop it. If the fanbois want it, left them roll their own FPGA.
I wonder, would it be possible to swap on the 6T-SRAM for 7T-SRAM with reset? Could "ROM" be done by having the reset mode of some cells be different than others, in order to make the ROM code? That way we wouldn't lose the RAM space for ROM, but would still be able to boot easily.
If we had more area within the bit cell and more wiring space, we could do a 7T cell with initialization. Too late for that now, though. 6T or less is all that will fit in those bit cell spaces.
All methods guarantee integrity, and all but one are contiguous. And that one is explicitly designed to not require it. Most importantly, none of them add any additional burden on the ROM code.
Off the top of my head for SD card booting there can be support for:
- Prebuilt image written to raw blocks. No partition, no volume. Everything contained in the image. This is a direct alternative to a SPI flash.
- Prebuilt image written to raw blocks within custom partition. Ditto for SPI flash.
- Bootloader written to raw blocks within custom partition. This contains filesystem handler code for booting main program from a second partition containing a filesystem.
- Bootloader written to raw blocks within reserved space of FAT volume. Ditto for filesystem handler code.
- Bootloader written to contiguous file within FAT volume. Ditto for filesystem handler code.
- Bootloader written to non-contiguous file within FAT volume. It has a split loader for handling the distribution of it's blocks or clusters. Ditto for filesystem handler code.
All of those are supportable with the tiny ROM code as planned - simply loading two blocks via a pointer.
Sometimes it seems to me that I am not able to explain the things due to my poor english.
The second option is the best one because:
- it allows for entire prebuild image (I mean the whole hub memory) to be loaded
- it allows for only a bootloader (provided the image starts with length to load: if this the case also the previous solution wil have the lenght information stating 128K)
- it allocates the data in a defined space (the partition) rather than unallocated space preserving it from any other OS damage. If its type is 0x27 or 0x7F no one will touch it
- it not depends on any FS
- it allows for the shortest code to do the job (like the first choice but because without the partition container more dangerous in my opinion)
If things work with RAM topping of at $007FF, well that is a darned good thing, right? Let's finish the chip and worry about SD boot code coming from the SPI flash. (My concern is that a partially or conditionally working SD boot function will give the whole chip an unreliable reputation.)
I hate it when I have to, or feel compelled to talk MBA Heater. That is a significant part of why I enjoy this hobby on a lot of levels. Costs are no fun, however, everybody seems to enjoy returns. Truth is, dollars do impact a lot of things, and sometimes one just needs to think in dollars to get answers that can't be had any other way. This SD feature invokes dollars. Ugly, but true, so there you go.
This SD discussion is a great case in point. I frankly wish I could highlight it, generalize some bits "protect the innocent" style, and use it to illustrate real feature costs. Just deciding SD or not was fairly expensive. (and I'm just capping it for the purpose of my post, to make the point, not declaring some decision) If it were to be done, the code is one cost, SD tests and such more costs, and the real heavy hitter is of course delay costs and expectations! Consider the cost of just the discussion. Plug $100 / hour in there, or maybe $50 then add up the consideration. That's not a small number, and it's just the tip of the dynamics. Again, ugly, undesirable, not fun, etc... Somebody has to say it though.
Boot from SD sounds simple and awesome, and if it were simple and awesome, then it would likely make sense, but it's not simple and awesome. It's sort of simple, but for a lot of cases, meaning it looks awesome, but really isn't, and there are a bunch of cases, each will trigger a decision tree that can very easily dilute the overall value of the feature.
Some features end up a negative impact because of this, and it's strange to see, but I've seen it many times. Awesome product with this one feature that people just gravitate to over and over, and that one feature that's "shiny thing" attractive, is also the one feature that biases perception of the product in a negative way triggering more rejections on "gut" responses more than not. It goes like this, "If this is kind of hokey, and who are these guys anyway, maybe the rest of it is hokey, so we better do testing..." which costs, and some "known not hokey" thing gets picked, and there you go. Negative feature value, despite the best of intentions. Happens all the time, and this is part of why Jazzed mentioned the "reserved" device used to take something like that off the table. It's costly enough to warrant doing stuff like that.
I see the SD boot in this way for P2 honestly. Ditch it.
Besides, one design attribute of the P1 was that it "just works", and remember Chip's letter. This SD feature can't meet that standard. IMHO, that's pretty darn important.
Edit: Invent-o-doc nailed it. Seconded. (bonus for brevity too, which I regularly struggle with --sorry all, that's just how I roll)
Circuitsoft is spot on. No other MCU boots off SD so why waste time on this feature and the SOC's that do have the feature like the one in the Raspberry are way out of the market segment that Parallax can compete in.
Just drop it. If the fanbois want it, left them roll their own FPGA.
Maybe it's true, even if I wouldn't put my hand on fire. But most of them (just to not say all because of my hand) have programmable memory (flash and eeprom) on them and some of them also the usb and ethernet front end, you need only the usb connector and/or the rj jack with magnetics.
PEDIT: Whats wrong in being the firsts? Nowadays I can find The Flintstones only in the cartoons
Sometimes it seems to me that I am not able to explain the things due to my poor english.
The second option is the best one because:
- it allows for entire prebuild image (I mean the whole hub memory) to be loaded
- it allows for only a bootloader (provided the image starts with length to load: if this the case also the previous solution wil have the lenght information stating 128K)
- it allocates the data in a defined space (the partition) rather than unallocated space preserving it from any other OS damage. If its type is 0x27 or 0x7F no one will touch it
- it not depends on any FS
- it allows for the shortest code to do the job (like the first choice but because without the partition container more dangerous in my opinion)
I hate it when I have to, or feel compelled to talk MBA Heater. That is a significant part of why I enjoy this hobby on a lot of levels. Costs are no fun, however, everybody seems to enjoy returns. Truth is, dollars do impact a lot of things, and sometimes one just needs to think in dollars to get answers that can't be had any other way. This SD feature invokes dollars. Ugly, but true, so there you go.
This SD discussion is a great case in point. I frankly wish I could highlight it, generalize some bits "protect the innocent" style, and use it to illustrate real feature costs. Just deciding SD or not was fairly expensive. (and I'm just capping it for the purpose of my post, to make the point, not declaring some decision) If it were to be done, the code is one cost, SD tests and such more costs, and the real heavy hitter is of course delay costs and expectations! Consider the cost of just the discussion. Plug $100 / hour in there, or maybe $50 then add up the consideration. That's not a small number, and it's just the tip of the dynamics. Again, ugly, undesirable, not fun, etc... Somebody has to say it though.
Boot from SD sounds simple and awesome, and if it were simple and awesome, then it would likely make sense, but it's not simple and awesome. It's sort of simple, but for a lot of cases, meaning it looks awesome, but really isn't, and there are a bunch of cases, each will triggers a decision tree that can very easily dilute the overall value of the feature. Some features end up a negative impact because of this, and it's strange to see, but I've seen it many times. Awesome product with this one feature that people just gravitate to over and over, and that one feature that's "shiny thing" attractive, is also the one feature that biases perception of the product in a negative way triggering more rejections on "gut" responses more than not. It goes like this, "If this is kind of hokey, and who are these guys anyway, maybe the rest of it is hokey, so we better do testing..." which costs, and some "known not hokey" thing gets picked, and there you go. Negative feature value, despite the best of intentions. Happens all the time, and this is part of why Jazzed mentioned the "reserved" device used to take something like that off the table. It's costly enough to warrant doing stuff like that.
I see the SD boot in this way for P2 honestly. Ditch it.
Besides, one design attribute of the P1 was that it "just works", and remember Chip's letter. This SD feature can't meet that standard. IMHO, that's pretty darn important.
Edit: Invent-o-doc nailed it. Seconded. (bonus for brevity too, which I regularly struggle with --sorry all, that's just how I roll)
The code is the only cost since the feature don't involve hw changes. I am pretty sure that Kye will do an excellent job as usual. The feature can be released as reserved, officially undocumented, and after some month, also with the community feedback you will have a good report of which SD works and which ones eventually not.
Just to remain on storage matter which standard has M$ and other producers followed when they have made the recovery partition for the first time?
Comments
Or, maybe that fuse bit that was discussed could be blown to allow SD boot, instead of prevent it...
That way, no SD would be the default...
+1
I have now even tested FAT32 formated SD-4GB by that method I described before and it have 6000 free before first Partition.
And are safe from 1800 Hex to place BOOT.binary ( that even not disturb my CAMERA )
On FAT16 type form sector 2 to 49 safe
So only need is to place that file on SD and by Andy's Loader -- It will boot in no time.
The last straw is this statement by Kye,
If true, what that means is that you are either:
a) Using closed source code and tieing the Propeller to the SD association. An all together horrible situation.
b) Putting code into the Prop II ROM withouout any solid standard to work from. Also an all together horrible situation.
I know Cluso is doing is best to find out what SD cards do what, but this trial and error is not how engineering should proceed,
On top of that there are other issues:
a) I seriously do not believe that the lack of boot from SD will have any impact on Prop II market opportunities. It's a micro-controller for Gods sake. Booting from SD makes some kind of sense for an ARM system that will end up running Linux or other OS where you for sure will need a couple of gigs file system for your OS. For an MCU no.
b) Those few who want/need a huge file system on thier MCU can tolerate a few cents for an I2C/SPI boot ROM as normal.
c) If this boot from SD code takes even one byte away from the HUB RAM that is too much. RAM, even on the Prop II is a precious resource.
Just say no to SD boot.
I wonder, would it be possible to swap on the 6T-SRAM for 7T-SRAM with reset? Could "ROM" be done by having the reset mode of some cells be different than others, in order to make the ROM code? That way we wouldn't lose the RAM space for ROM, but would still be able to boot easily.
+1 here too.
I couldn't agree more with Roy. Chip has told us he is sick and that he is tired. Ken Gracey has already told us "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!"."
I would strongly suggest people read between the lines. The Prop2 has been costing Parallax a fortune. They can't afford to spend more time on it. It's time to forget SD booting, get the Prop2 OTFD and move on.
Really, name any other micro with mask ROM that works with SD or any type of mass storage. Even ARM7/Cortex-M devices don't boot off SD, and I'm not sure any Cortex-R devices do either. All the ARM9's that do are 400+MHz and have MMUs. It's just not that worth it, and not that much of a selling point, either.
It seems very safe to put a pointer in the MBR to indicate where start the contiguous read of firmware. With the second partition you guarantee that the firmware remains contiguous. The loaded firmware will provide support for FAT or any other FS desired by the developer. To here it seems all safe. Cluso and Ariba has shown that the code will fit in the 150 longs. So why not? Even if it boots only from a selected group of SDs is better than nothing. The ones wanting the SPI flash can have it, it's not precluded. The ones using the flash and SD can wire the SD on different pins, also this is not precluded. So why not?
I really wonder about that cost / market dynamic myself. Time to market costs are serious and have been growing for some time. There is a window of applicability, and a clear "prime" time for product introduction. Every month that time goes by without the product there in the market means very serious opportunity costs, in addition to the already significant development costs. Those opportunity costs compound too!
There are the sales that do not happen because the product isn't there. There is the potential for overall market share mixed in with that too. As people get established on products they've selected, they become reluctant to select different ones, raising the barrier to entry, which compounds the opportunity costs.
An opportunity cost is basically money left on the table, never to be earned.
Right now, this entire SD discussion is "chasing the window" in some attempt to engineer more quickly than the product viability window evolves. Sometimes this makes sense, but it's extremely expensive and risky to do. Chasing that window compounds the costs even further as raising expectations and adding features increases product cost, the window continues to move, and all the dollars required for that likely will dilute the dollars needed to properly promote the product, further compounding opportunity costs.
Folks, right now, today, there are millions of dollars that won't ever be earned at Parallax, despite a very significant and sustained investment. That impacts the future of the company and for the most part, those impacts are permanent. New products can meet future windows, but this product, and it's viability window are happening right now, and that window is prime right now, or close to prime. Frankly, I don't see it improving too much, and when it peaks, it's a slow downhill from there.
To do it right, the product needs to be there for early adopters and at the very least, the early majority. That revenue is the highest margin, with diminishing returns beyond the majority. I can link a ton of information about how the earning potential of a product is impacted by failing to reach the market during the early viability time. It's ugly. Really ugly. A product can easily be worth half, and the half can happen over a span of mere months for some products too.
It is true that Parallax will sell products for a long time, but what they get for doing that could be significantly different depending on when they get the product out there for sale, and this is the final compounding effect:
If they miss their prime window, they could get half of what the product was really worth. Half. What impact does that have?
Where do you think the capital required to build the next product and innovate comes from? Missing this could resign Parallax to a niche, unable to build to compete on the next level. That's the kind of stuff we are talking about here, and that's the "nontrivial" Ken is trying very nicely to articulate.
That's not a gloom and doom message, though I can't speak for Ken. I honestly don't think it's that. More like a potential wasted, opportunities gone message, and while not the same thing as doom, still very unpleasant, if the objective is to make it here in the USA, pay people well, capitalize against risk, fund development and do all the great things a company can do.
Want to see the great things? Then support Parallax in getting a great product out there now while there remains time to be great. The early adopters are buying now. Competitors are being established now. Trends, preferences, efforts, market shares, etc... are being decided now. Those things are all very big multiples, and they matter, and they matter now.
Wait another year or two? They won't matter as much, and neither will Parallax, and the great things we know they can do, and are eager to see them do, simply move off the table, gone, never to exist.
Sorting this out for companies is part of what I do for a living. I've seen companies spend insane amounts of money and devote huge labor resources to attacking this problem, and they do it because the returns are so large they can't afford not to. Fact.
http://info.arteris.com/blog/bid/64099/How-to-Calculate-Late-Time-to-Market-TTM-Revenue-Loss-Part-1 (there are much better, more lengthly links to the dynamics --that one is a chip company just highlighting how they see it)
To be perfectly frank, P1 suffered from this. An earlier release would have been much better aligned with the trends we enjoy currently. Several key players were established during that time, and had even one of them adopted the P1, the revenue story would be much different.
Now, consider that and the constraints on software development, research, testing, simulation, etc... in play right now, and the impact of that on when we get P2. Look at all the players starting to establish right now! Again, being a part of that or not will very significantly impact the revenue from this effort, and it compounds over and over....
To be perfectly frank again, P2 is currently suffering from this. Weeks matter. Even days do. However, given sufficient delay, neither will matter, and that's something for everybody to think about. Most importantly, is this viable being a small niche? Seriously? Bet you Ken is wondering that big right now. I am too.
Doh! Sigh. Read the whole topic. The only thing the ROM sees is a pointer to two raw blocks. The ROM knows nothing about any filesystem no matter what volume type is chosen. Any filesystem can exist on that partition/volume.
+1
A long way back in this thread, I asked if there were any P2 competitors that booted from SD, nobody really came up with anything.
People are throwing around that it's needed for marketability. Is that a real market demand or a perceived market demand or a wished for market demand?
The good points against supporting it are far outweighing the points for supporting it.
Doing it right also includes all the infrastructure (infrastructure is infrastructure, regardless of product) needed to launch and support the product for early adopters. If the support and documentation isn't there at launch, then people get turned off the product/company and find other alternatives. As Ken said earlier, Chip's time and efforts are better spent elsewhere at some point. This debate has reached that point.
Mitigating risk may be the best way out.
Another way that I've seen chip designers handle this is by calling a feature bit a "reserved bit". That is: "reserved and should always be in a certain state otherwise results may not be predictable." Once there is more solid information/evidence available, the feature can be fully documented.
Chip, I like that you have put the ROM boot stub in the lower section of memory because it is a *manageable* hole. I request however that you move the offset up to address $80 because we may want to have 32bit pointers and other values in the lower memory for *immediate* HUB access in PASM as is practiced by some today i.e., "rdlong value, #LOWADDR".
I'm sad to hear of the recent loss in your family Chip. God bless you, your wife, and beautiful children.
--Steve
I don't mind putting a <$0.40 flash chip on my boards, which could boot from SD if it detects an inserted card with the right "signature offset" in the MBR.
I am still not sure about removing direct addressing of the first 256 bytes in the hub; even though I like the larger index it makes possible.
The amount of memory is set in silicon, at this point, and cannot be changed. The memory exists as four instances of an 8192 x 32 SRAM that we designed. Some of the SRAM bit cells are going to be replaced by ROM bits so that the chip has some initial functionality after reset, so that user code can be loaded into the SRAM (I know you know this part, jmg, I'm just spelling it out for everyone). So, we have byte addresses $00000..$1FFFF that wrap around, effectively giving us a 17-bit address bus. The only questions have been how much SRAM do we convert to ROM, where do we locate the ROM address space, and what does the ROM do. Right now, we are set up to have RAM from $00000..$0000F, then ROM from $00010..$00xxx, then SRAM from $00xxx+1..$1FFFF. It's looking like without SD boot, $00xxx will be equal to $007FF. With SD boot, it would get a little higher.
All methods guarantee integrity, and all but one are contiguous. And that one is explicitly designed to not require it. Most importantly, none of them add any additional burden on the ROM code.
Off the top of my head for SD card booting there can be support for:
- Prebuilt image written to raw blocks. No partition, no volume. Everything contained in the image. This is a direct alternative to a SPI flash.
- Prebuilt image written to raw blocks within custom partition. Ditto for SPI flash.
- Bootloader written to raw blocks within custom partition. This contains filesystem handler code for booting main program from a second partition containing a filesystem.
- Bootloader written to raw blocks within reserved space of FAT volume. Ditto for filesystem handler code.
- Bootloader written to contiguous file within FAT volume. Ditto for filesystem handler code.
- Bootloader written to non-contiguous file within FAT volume. It has a split loader for handling the distribution of it's blocks or clusters. Ditto for filesystem handler code.
All of those are supportable with the tiny ROM code as planned - simply loading two blocks via a pointer.
Certainly isn't being required.
No reason why most of those above FAT methods can't be applied to other filesystems also. After all, Grub does exactly this on a multitude of filesystems.
"...opportunity costs...compound...viability window"
I think I have said this before but, oh man I love it when you talk MBA:)
Anyway I agree "ship the damn thing ASAP". We can buy it and have years of fun. Parallax gets money. Chip can take time out to enjoy his walnut farm and family. Then we can regroup for the Prop III debate:)
Just drop it. If the fanbois want it, left them roll their own FPGA.
It is exactly what I'm are doing now.
If we had more area within the bit cell and more wiring space, we could do a 7T cell with initialization. Too late for that now, though. 6T or less is all that will fit in those bit cell spaces.
Sometimes it seems to me that I am not able to explain the things due to my poor english.
The second option is the best one because:
- it allows for entire prebuild image (I mean the whole hub memory) to be loaded
- it allows for only a bootloader (provided the image starts with length to load: if this the case also the previous solution wil have the lenght information stating 128K)
- it allocates the data in a defined space (the partition) rather than unallocated space preserving it from any other OS damage. If its type is 0x27 or 0x7F no one will touch it
- it not depends on any FS
- it allows for the shortest code to do the job (like the first choice but because without the partition container more dangerous in my opinion)
They're all available as is. No choosing needed.
This SD discussion is a great case in point. I frankly wish I could highlight it, generalize some bits "protect the innocent" style, and use it to illustrate real feature costs. Just deciding SD or not was fairly expensive. (and I'm just capping it for the purpose of my post, to make the point, not declaring some decision) If it were to be done, the code is one cost, SD tests and such more costs, and the real heavy hitter is of course delay costs and expectations! Consider the cost of just the discussion. Plug $100 / hour in there, or maybe $50 then add up the consideration. That's not a small number, and it's just the tip of the dynamics. Again, ugly, undesirable, not fun, etc... Somebody has to say it though.
Boot from SD sounds simple and awesome, and if it were simple and awesome, then it would likely make sense, but it's not simple and awesome. It's sort of simple, but for a lot of cases, meaning it looks awesome, but really isn't, and there are a bunch of cases, each will trigger a decision tree that can very easily dilute the overall value of the feature.
Some features end up a negative impact because of this, and it's strange to see, but I've seen it many times. Awesome product with this one feature that people just gravitate to over and over, and that one feature that's "shiny thing" attractive, is also the one feature that biases perception of the product in a negative way triggering more rejections on "gut" responses more than not. It goes like this, "If this is kind of hokey, and who are these guys anyway, maybe the rest of it is hokey, so we better do testing..." which costs, and some "known not hokey" thing gets picked, and there you go. Negative feature value, despite the best of intentions. Happens all the time, and this is part of why Jazzed mentioned the "reserved" device used to take something like that off the table. It's costly enough to warrant doing stuff like that.
I see the SD boot in this way for P2 honestly. Ditch it.
Besides, one design attribute of the P1 was that it "just works", and remember Chip's letter. This SD feature can't meet that standard. IMHO, that's pretty darn important.
Edit: Invent-o-doc nailed it. Seconded. (bonus for brevity too, which I regularly struggle with --sorry all, that's just how I roll)
Maybe it's true, even if I wouldn't put my hand on fire. But most of them (just to not say all because of my hand) have programmable memory (flash and eeprom) on them and some of them also the usb and ethernet front end, you need only the usb connector and/or the rj jack with magnetics.
PEDIT: Whats wrong in being the firsts? Nowadays I can find The Flintstones only in the cartoons
On SDHC spare area from 1800 Hex have place for 384000 KBytes
On <2GB it have 3136 KBytes on that spare space starting from Sector 1 to end of 49
BUT to that it require SD Formater 3.1 program.
The code is the only cost since the feature don't involve hw changes. I am pretty sure that Kye will do an excellent job as usual. The feature can be released as reserved, officially undocumented, and after some month, also with the community feedback you will have a good report of which SD works and which ones eventually not.
Just to remain on storage matter which standard has M$ and other producers followed when they have made the recovery partition for the first time?