I'd rather not rely on weak resistive- or current-drive pin modes for boot up, because we can't emulate those well on the FPGA. Detecting external pull-up or pull-down resistors digitally is easy, though.
As long as we're pretty sure that the start of the MBR will continue to be reserved for bootstrap code, I think this is a good solution. Is there anything that needs to be done to make sure that another system won't try to boot our code? What if I plug the card into a PC and then power on the PC? Will it attempt to boot since there is code in those first bytes of the MBR? I guess I'm asking how a system knows if the code found there is intended for it.
0x55, 0xAA. With this two bytes (called Boot Signature) at offsets 0x1FE, and 0x1FF the PC BIOS knows that the first sector has a valid Master BOOT Record and will load that sector into 0x7c00 and execute the code.
It sounds like we're trying to re-invent a solution to an already solved problem. The MBR *is* actually still used to boot -- see the documentation for grub, or syslinux, or any other x86 boot loader. It's gradually being superseded by GUID Partition Tables, but that's not going to appear on SD cards for a very long time, and even now GPT systems usually have a dummy MBR for backwards compatibility.
True
Traditionally the bootstrap code goes in offsets $0 to $1BE of the MBR. These days that area is broken up with $DA-$E0 being used as a disk identifier.
The disk identifier is between $1B8 and $1BE.
The PC BIOS loads that code to a predefined area and jumps to it.
We could do exactly the same thing. The ROM boot code could load sector 0, verify a signature (say, require the first 4 bytes of the MBR have a particular magic number for booting on P2) and then jump to offset 4. I think we should use hubexec for simplicity, since that allows the code to be re-used for loading multiple sectors.
There's not a lot of room in the MBR, particularly for P2 code -- but on the other hand, if the ROM provides services to us at known fixed locations, the MBR code can be pretty simple. The ROM already has sector reading code, so all the MBR has to do is something like:
mov PARAM1, ##firstsector '' PARAM1 is a defined location in COG memory; maybe $1C0
mov PARAM2, ##numsectors '' PARAM2 is at $1C4 (for example)
jmp ##ROM_load_and_boot '' load PARAM2 sectors at $800 and jump to it in hubexec mode
Those who want to boot from a partition can modify the above code a bit to set up PARAM1 and PARAM2 from the partition table; I think there's room to do that. Those wishing to have a general FAT file system code can either force a contiguous file, or else use a second stage boot loader. That's the way it's done on PCs.
This seems interesting, but at this point you do not need to store instructions in the MBR, you can simply store the parameters in a known structure. And if the first 2 bytes of the MBR gives you the offset where this structure is in the MBR then it becomes relocatable in the whole MBR space. And if the structure matches the one of the partition entry than this can be one of the entries of the partition table or a copy anywhere in the MBR.
Having infact the instructions in the MBR will not make the booter more dynamic since the rest of the code is still in ROM and thus the exchangeable parameters are still fixed by the later.
The main reason not to force the use of a boot partition is that many users will prefer to store their boot code as a FAT32 file, and having a partition that points into another partition is probably dangerous (and won't work if the file isn't contiguous).
Having the LBA parameter of one partition pointing into another isn't dangerous as long as the corresponding partition type and status are set correctly. But yes it will require a contiguous file and this is the reason I am for a dedicated boot partition both, because of the not needed filesystem awareness and because I fill the firmware more safe there, away from the FAT partition used for data exchange with other systems.
But unless you employ a FAT aware boot-loader the firmware copied into the FAT32 partition must be contiguous anyway, regardless of how and from where you point to it.
As long as we're pretty sure that the start of the MBR will continue to be reserved for bootstrap code, I think this is a good solution. Is there anything that needs to be done to make sure that another system won't try to boot our code? What if I plug the card into a PC and then power on the PC? Will it attempt to boot since there is code in those first bytes of the MBR? I guess I'm asking how a system knows if the code found there is intended for it.
I'm pretty sure it will always continue to be bootstrap code, and if it doesn't then other things will break. You do have a point that we should probably leave space for a simple x86 "boot" routine that prints "This disk is not bootable." (a lot of floppies and such already have this).
I think you can't be sure. The MBR structure has evolved during time. Also various 3rd-party boot managers that allows you multi OS boots use this areas in their way (even if this is not usually the case for removable media).
I think that the only areas you can put your hand on fire that will never change (in the 512 bytes space) are the first two bytes, the last two bytes, and the original partition table ($1BE..$1FD).
OTOH I missed the requirement that the boot code be signed, which adds some complexity (we now need room for the signature as well). I like the simplicity and flexibility of re-using the traditional PC booting path, but we almost certainly will need more space than the MBR provides. So other options are:
(1) Require that there be some unused, unallocated sectors between the MBR and the first partition. A lot of PC disks are already formatted this way, and it's a traditional spot to stick second stage bootloaders in. We could just always boot from, say, sectors 2-32 or something like that.
This is because on some media SSD, SD, ... the partitions are generally aligned due to performance reasons. But also here it depends on the tool that prepared the media, some have alignment as an option, others do it automatically and may have options to prevent it. It is not a warranty.
(2) Use a reserved boot partition, as you had suggested earlier. I didn't like that because I wanted to be able to put the boot code on a FAT file system, but I've since realized that the reserved partition could itself contain the FAT reading code and could load and verify an arbitrary FAT file, so it works either way.
Yes, this is a stage more in the boot process: load the FAT framework/drivers and then search for the file following its fragmentation.
One potential issue with all of these schemes is that we might want there to be *two* authorized keys to verify boot signatures: a standard Parallax one (for the basic, first stage boot code) and the user's own key (for the application specific code that's finally booted). This would make formatting the disks a lot easier -- the P2 disk formatter could write a generic first stage boot code that would read from FAT or whatever, and that would in turn verify the final boot code with the user's key. It's not a big deal -- obviously the user could sign their own first stage boot code, and users that want signed boot probably are sophisticated enough to handle the extra complication.
Can't the user key be part of the fw image, a header, containing also its size and execution mode/address
Overriding SPI boot feature needs to be there, a button/jumper that pulls one of the SPI pins low (and wait until you release)
As a way of bootstrap-loading new firmware that writes itself to SPI flash,
in case the previous firmware no longer function, as normally it would look for a newer reversion on SD to update itself, but it's corrupt or you need downgrading.
Right.
Turn off system. Plug in SD card. Turn it back on. SD card updates SPI flash. Turn off system. Remove SD card. Turn system back on. Now running updated code in SPI flash. Simple field upgrade.
An SD card without a signed booter would never cause an SD boot.
If we speak of field upgrades there will be two kind of systems:
1) offline systems, where most probably the upgrade will require physical access to the device.
2) connected systems, where the upgrade can be done remotely.
Now this systems can have:
a) a flash
b) an SD
c) both.
In case of flash presence I am with all the ones thinking that boot priority should be on flash. Moreover if there is a flash the SD should not boot in any way. In this case is the flash loader/part of firmware that will handle the upgrade or the further boot/load from SD, up to developer needs, eventually by detecting a pullup/switch on a pin. Most probably here the fw will reside all in flash or at least the FAT awareness and SD will be only used for user data exchange.
But Chip, if you are seriously considering field upgrades (specially if done remotely to connected systems) you must foresee the issue that an power outage can happen during the flash(a)/SD(b) write phase. I think the boot process, regarding of the media, should have the opportunity to have two images, one active and one inactive. During the upgrade the inactive image will be rewritten and at the end of the process the selector changed so the next boot the later will became active. The selector change can be done quickly and the power required can be easily sourced from the onboard (PS) capacitors.
Would it be a bad thing if there was no boot ROM support for SD?
I know SD is doable, but it takes more time and energy to get working.
I do have the ROM done now, so that we have SPI and serial support. We could just call it done and move onto all the software that needs attention, with a stable platform.
Could you please each rate your interest in this SD matter with a 1..5 rating, where 1 is "I don't want it", 3 is "I don't care" and 5 is "I really want it"?
Well, I don't want an implementation that I don't like, so I'll vote 1.
A more complex scheme that would be better is to get a VID/PID and a driver that lets you program prop over USB as a device. But, I'm sure that would take a lot of development.
I vote 1 if it's any of the special case hacks that involve poking the MBR with special values.
I vote 3 if it's something using the proper FAT mechanism to find the image and load it. So, I would use this if it was there, but won't miss it if it's not.
However, I'm a very low volume user, and having a flash chip required to then boot from the SD is not a problem for me at all, in fact I kind of prefer to have both.
I don't mind having a boot rom without SD stuff just for testing on FPGA but that's just so we can play with the latest version and come back to you with a nice simple version to include in silicon. So I have to vote +5 because I know how I intend to use this for a volume project and I can't understand the negative vote* as I was sure you were asking about "need" vs "happy". I am voting for need because I need it to be fast.
* reminds me of the two women and the baby judgment before Joseph Solomon (how'd I get that wrong?) in the bible.
We got a lot of great features into this design. Not sure SD will even move the needle.
We appear unable to arrive at a baseline consensus too. That isn't a negative statement about us or anyone, more confirmation this feature has more considerations than we can afford right now.
I'm with Roy. May use it, if it's there, don't care if it's not.
And I voted two because this should either be great, or something we don't do, and that trumps wanting it or not.
I do feel it's mostly a loss, in that anything short of great is more likely to leave a negative impression, which speaks to that 2 vote again.
Prefer both, low volume, but maybe production user. Depends on what pans out for me next year.
I vote 4. I see SD as useful in a couple of cases...
1) lowest BOM cost - no flash required
2) if you need to build a P2 based product that can potentially recover from field upgrade flash corruption problem by the end user and not be bricked if they corrupt the usual boot flash. Ok bricked may be too strong given there is a still a serial port pathway to recover, but from an end-user only perspective if they just can put a special SD card image (assuming there is already SD on the board) and be able recover their device in case of upgrade failure this is nice.
There are other ways to solve the recovery problem though such as multiple devices/protected boot blocks etc, and arbitrary SD code boot is potentially a security hole too in a shipped product. Maybe fuses could enable/disable SD boot if required.
I vote 3. I really want to see silicon soon, and my understanding is that this will add a significant amount of testing time. That said, if it were available, I would definitely use SD only boot in my projects.
I'd be happy with any flavor of SD boot being in ROM (no matter how bare-bones and/or non-standard and/or non-portable and/or not-universal-to-all-cards-ever-made).
I look forward to seeing what Cluso and Peter come up with. I'm sure I'd be happy with it.
Would it be a bad thing if there was no boot ROM support for SD?
I know SD is doable, but it takes more time and energy to get working.
I do have the ROM done now, so that we have SPI and serial support. We could just call it done and move onto all the software that needs attention, with a stable platform.
Could you please each rate your interest in this SD matter with a 1..5 rating, where 1 is "I don't want it", 3 is "I don't care" and 5 is "I really want it"?
SPI Flash parts are well under 20c, so the incremental cost in $ of bumping SD support into Flash is small.
There is some feature cost, which is why I suggest the below...
I would suggest release of a ROM image, minus SD, so testing can proceed.
If you can also outline the spare ROM space, and how the code is loaded/run, and allocate spare Pin-Overrule mappings, that would allow others to craft SD candidates that can be tested in parallel with other work.
ie a SD pin-overrule mapping would be tested for, but simply return from an empty SD call.
[quote="cgracey;1387084"
I know SD is doable, but it takes more time and energy to get working.
[/quote]
The important thing is to avoid consuming your time and energy, but to release something asap that can allow rigorous test of test Flash-boot, and allow others to craft a SD candidate...
I vote 5
And support Peter in having the solution he wants, because even if not standard it's certainly excellent. So bring out the next version FPGA and you will gain support from the forth front!
Would it be a bad thing if there was no boot ROM support for SD?
I know SD is doable, but it takes more time and energy to get working.
I do have the ROM done now, so that we have SPI and serial support. We could just call it done and move onto all the software that needs attention, with a stable platform.
Could you please each rate your interest in this SD matter with a 1..5 rating, where 1 is "I don't want it", 3 is "I don't care" and 5 is "I really want it"?
Since I changed the company embedded MCU/FW development is no longer part of the primary job. Now, except for a industrial vacuumeter that uses edwards and laybold measuring gauges the rest is done at the hobby /second job) level in the fields of home-automation (also off-grid vacation houses with their own drinking water cistern), boat & caravan/autocaravan automation/accessories.
The volumes are low and, to certain level, the BOM cost is irrelevant, because of the niche product, while the space (component count, pcb complexity) is many times an issue because being this mostly hand production I am unable to use all the miniaturized packages and multi-layer pcbs also increases costs. For example my 4 channel configurable dimmer/switch (8 wide voltage IN, 4POUT with independent current measurement, bus operated) is using this box.
That said, regarding the SD, I will use it if available, certainly. But I will use it only if I will have the possibility to have the firmware away from the main file system. By improperly dealing with the SD you can corrupt it, it's enough you corrupt a small part (eg the fat table, a thing that is updated on nearly every file write access), to make it unusable. This must not corrupt your firmware that can then detect it and handle the error properly.
I will never use both, the flash and SD, if not forced or if the former will not be internal. But the choosing factors will not be of course only the SD boot but also the other features of the smart pins that can help me reach the goal. In the case of PIC16F1779/16F1789 the hall effect current sensor that provides isolation between high and lo voltage is directly connected to the MCU. With its comparator and dac I set the max current that in hw switch-off immediately the pwm thus avoiding mosfet damages and with the adc at the same time I read the current for process needs: stats and adjustments. So the hw peripherals, once setup, offloads the cpu from safety checks (which thus react quicker and require smaller inductors, if any at all) and most of the timing controls/calculations and let it simply manage the process helping me not becoming crazy with interrupts.These are the models upon which I asked (in the other thread) how are comparators/opamps with DAC references with external and internal inputs/outputs supported on P2.
P2, if will have the features I've understood, will be a great advance because of its huge ram: my projects usually do not need big code memory, but I need a lot of ram and storage because most of the time the applications logs many parameters continuously. On the other side I am not building health-care or HA equipment thus a few ms more of booting time are acceptable for me, but I understand the ones that require instantly on MCU's.
So I think my rate can be around 3 to 4. It must be simple and reliable, future proof and easy for you to implement, but done properly. It not have to be easy to understand, easy for students, occasional users since all this can be automated and handled with sw tools, if needed (eg to prepare the MBR), and thus be transparent to the end user.
And once again, even for flash, please consider a double image for the ones that want it. IMHO an MBR can be also in the flash (but it can be deadly simple as reading an offset in the first location). This doesn't means that flash will have any file system, just a small area where the image to be booted can be chosen. In the past I've used Lantronix modules for connectivity. Now I am using Tibbo's for many years. With tibbo I am able to program PICs directly through ICSP and P1 by writing to the I2C fram (I use FM31L278 usually) or the serial port. With these MCU the firmware is small and in case of remote (internet mostly 3g/4g) upgrades I buffer the FW image in the tibbo prior to rewrite the MCU. But with the P2 the hub is much greater (and will probably be bigger in P3). This allows for bigger firmware that can't be buffered. A direct remote update can be dangerous eg in case of power outage or data corruption during the reflash process. On the other side you can reflash the unused image and once finished and verified it change the boot selector to it. For the latter (the selector change) power supply capacitors can easily protect (backup) from power outages during the rewrite.
And once again, even for flash, please consider a double image for the ones that want it.
Yes, I think a double image for flash is a good idea. SPI flash chips all have a lot more than 512K so it should easily be possible to have two copies of the boot image. In fact, maybe this could be a solution to recovering a trashed flash without requiring boot support for an SD card in ROM. There could be a "emergency recovery" image in the flash that is locked and has the code needed to load a new image from an SD card. In addition, there could be two partitions for normal firmware. This gives two levels of safety without requiring any code in ROM to handle the SD card.
And once again, even for flash, please consider a double image for the ones that want it.
Yes, I think a double image for flash is a good idea.
I agree a dual-image support is a very good idea, and wireless updates are certainly going to become more common, and one area that P2 Boot should be tested carefully with.
Perhaps an image-choice-force could even be usefully added to the Pin-Overrule map, as the needed QuadSPI pin define, gives many choices.
SPI flash chips all have a lot more than 512K so it should easily be possible to have two copies of the boot image.
Err, not quite.
The cheapest SPI Flash is showing at 4Mb, which is exactly 512kB
16Mb (& above) are available, but for now still a higher price than 4Mb.
Of course, Fast-SPI boot should always remain a cornerstone of P2.
And once again, even for flash, please consider a double image for the ones that want it.
Yes, I think a double image for flash is a good idea.
I agree a dual-image support is a very good idea, and wireless updates are certainly going to become more common, and one area that P2 Boot should be tested carefully with.
Perhaps an image-choice-force could even be usefully added to the Pin-Overrule map, as the needed QuadSPI pin define, gives many choices.
SPI flash chips all have a lot more than 512K so it should easily be possible to have two copies of the boot image.
Err, not quite.
The cheapest SPI Flash is showing at 4Mb, which is exactly 512kB
16Mb (& above) are available, but for now still a higher price than 4Mb.
Of course, Fast-SPI boot should always remain a cornerstone of P2.
Hmmm... Well, I guess it should be possible to have only a single firmware partition as well. In fact, the ESP8266 has exactly this. You can have two firmware images or only a single image and both are supported by the ROM. In fact, the ESP8266 is fairly similar to the P2 in that it doesn't contain any onboard flash and keeps firmware images in an external SPI or QSPI flash.
I think all we really need from the ROM boot is the ability to read in the "second stage boot" image from a secondary location if the primary location's image fails validity checks. This can be done by having the first few bytes of the SPI flash contain the pointers to the two images for it to try loading.
Everything else can be handled by the second stage boot that is your own code and you can do whatever you want.
Hmmm... Well, I guess it should be possible to have only a single firmware partition as well. In fact, the ESP8266 has exactly this. You can have two firmware images or only a single image and both are supported by the ROM. In fact, the ESP8266 is fairly similar to the P2 in that it doesn't contain any onboard flash and keeps firmware images in an external SPI or QSPI flash.
The new ESP32 I think is also the same Flash->RAM as P2, but I notice their DOCs are deliberately vague around what is on-chip, and what is on-module, and a line of 16 MByte flash does not mean that is on the die.
I think all we really need from the ROM boot is the ability to read in the "second stage boot" image from a secondary location if the primary location's image fails validity checks. This can be done by having the first few bytes of the SPI flash contain the pointers to the two images for it to try loading.
Everything else can be handled by the second stage boot that is your own code and you can do whatever you want.
That is probably okay but I still think it would be best if there was a "disaster recovery image" that was in protected flash that is separate from the ping-pong image partitions used during normal updates. Since those ping-pong partitions are writable, there is a chance both could get corrupted. A protected disaster recovery partition would provide a guaranteed way of booting even in the case that all writeable flash was trashed.
Edit: Well, I suppose only a single protected flash image would be okay. It could then boot a second-stage loader from one of two ping-pong partitions. Maybe this is what you were suggesting. Sorry for being dense!
Comments
Fair enough.
Look forward to the new image
0x55, 0xAA. With this two bytes (called Boot Signature) at offsets 0x1FE, and 0x1FF the PC BIOS knows that the first sector has a valid Master BOOT Record and will load that sector into 0x7c00 and execute the code.
https://en.wikipedia.org/wiki/Booting
http://wiki.osdev.org/System_Initialization_(x86)
https://support.microsoft.com/en-us/kb/149877 (Boot Record Signature AA55 Not Found)
So without those two bytes, problem solved.
You can define your own signature for P2. How about 0x50, 0x32?
MBR ... since 1983. I still remember the good old msdos debug.com:
- L 100 2 0 1 (http://thestarman.pcministry.com/asm/debug/debug2.htm)
This seems interesting, but at this point you do not need to store instructions in the MBR, you can simply store the parameters in a known structure. And if the first 2 bytes of the MBR gives you the offset where this structure is in the MBR then it becomes relocatable in the whole MBR space. And if the structure matches the one of the partition entry than this can be one of the entries of the partition table or a copy anywhere in the MBR.
Having infact the instructions in the MBR will not make the booter more dynamic since the rest of the code is still in ROM and thus the exchangeable parameters are still fixed by the later.
Having the LBA parameter of one partition pointing into another isn't dangerous as long as the corresponding partition type and status are set correctly. But yes it will require a contiguous file and this is the reason I am for a dedicated boot partition both, because of the not needed filesystem awareness and because I fill the firmware more safe there, away from the FAT partition used for data exchange with other systems.
But unless you employ a FAT aware boot-loader the firmware copied into the FAT32 partition must be contiguous anyway, regardless of how and from where you point to it.
I think you can't be sure. The MBR structure has evolved during time. Also various 3rd-party boot managers that allows you multi OS boots use this areas in their way (even if this is not usually the case for removable media).
I think that the only areas you can put your hand on fire that will never change (in the 512 bytes space) are the first two bytes, the last two bytes, and the original partition table ($1BE..$1FD).
This is because on some media SSD, SD, ... the partitions are generally aligned due to performance reasons. But also here it depends on the tool that prepared the media, some have alignment as an option, others do it automatically and may have options to prevent it. It is not a warranty.
Yes, this is a stage more in the boot process: load the FAT framework/drivers and then search for the file following its fragmentation.
Can't the user key be part of the fw image, a header, containing also its size and execution mode/address
If we speak of field upgrades there will be two kind of systems:
1) offline systems, where most probably the upgrade will require physical access to the device.
2) connected systems, where the upgrade can be done remotely.
Now this systems can have:
a) a flash
b) an SD
c) both.
In case of flash presence I am with all the ones thinking that boot priority should be on flash. Moreover if there is a flash the SD should not boot in any way. In this case is the flash loader/part of firmware that will handle the upgrade or the further boot/load from SD, up to developer needs, eventually by detecting a pullup/switch on a pin. Most probably here the fw will reside all in flash or at least the FAT awareness and SD will be only used for user data exchange.
But Chip, if you are seriously considering field upgrades (specially if done remotely to connected systems) you must foresee the issue that an power outage can happen during the flash(a)/SD(b) write phase. I think the boot process, regarding of the media, should have the opportunity to have two images, one active and one inactive. During the upgrade the inactive image will be rewritten and at the end of the process the selector changed so the next boot the later will became active. The selector change can be done quickly and the power required can be easily sourced from the onboard (PS) capacitors.
My P123 board has a Program/Run jumper so maybe it's not so uncommon...
Hmm. But then, I guess you'd have to detect the user putting jumper back if your goal was to reprogram SPI flash...
Sounds like we're going to have to dedicate 4 pins to SPI flash update via SD...
Yes, any SD options certainly need to be added to the present smaller Pin-Overrule table.
Yes, some decisions will be needed around pin mapping.
Some could in theory be shared, but would you want Flash-pins exposed to ESD events via SD sockets ?
(or attacks / vandalism via SD sockets.?)
Some designs may choose to include series R and ESD clamps and current limiters on any exposed SD sockets, just like is common now for USB connects.
I know SD is doable, but it takes more time and energy to get working.
I do have the ROM done now, so that we have SPI and serial support. We could just call it done and move onto all the software that needs attention, with a stable platform.
Could you please each rate your interest in this SD matter with a 1..5 rating, where 1 is "I don't want it", 3 is "I don't care" and 5 is "I really want it"?
A more complex scheme that would be better is to get a VID/PID and a driver that lets you program prop over USB as a device. But, I'm sure that would take a lot of development.
So, I'll vote for keeping it simple and fast...
I vote 3 if it's something using the proper FAT mechanism to find the image and load it. So, I would use this if it was there, but won't miss it if it's not.
However, I'm a very low volume user, and having a flash chip required to then boot from the SD is not a problem for me at all, in fact I kind of prefer to have both.
* reminds me of the two women and the baby judgment before Joseph Solomon (how'd I get that wrong?) in the bible.
We got a lot of great features into this design. Not sure SD will even move the needle.
We appear unable to arrive at a baseline consensus too. That isn't a negative statement about us or anyone, more confirmation this feature has more considerations than we can afford right now.
I'm with Roy. May use it, if it's there, don't care if it's not.
And I voted two because this should either be great, or something we don't do, and that trumps wanting it or not.
I do feel it's mostly a loss, in that anything short of great is more likely to leave a negative impression, which speaks to that 2 vote again.
Prefer both, low volume, but maybe production user. Depends on what pans out for me next year.
I don't want FLASH on my boards. It is an overhead not required these days unless it is inside the chip.
However, please just get us a ROM so Peter and I can get it working - we will give you the code to check it out Chip.
Ok. I've almost got the new release ready. Just one more compile for the BeMicro A2 board. I've got to comb through all the files, also.
I'd be happy to run with V11 with SPI boot support for now.
1) lowest BOM cost - no flash required
2) if you need to build a P2 based product that can potentially recover from field upgrade flash corruption problem by the end user and not be bricked if they corrupt the usual boot flash. Ok bricked may be too strong given there is a still a serial port pathway to recover, but from an end-user only perspective if they just can put a special SD card image (assuming there is already SD on the board) and be able recover their device in case of upgrade failure this is nice.
There are other ways to solve the recovery problem though such as multiple devices/protected boot blocks etc, and arbitrary SD code boot is potentially a security hole too in a shipped product. Maybe fuses could enable/disable SD boot if required.
I'd be happy with any flavor of SD boot being in ROM (no matter how bare-bones and/or non-standard and/or non-portable and/or not-universal-to-all-cards-ever-made).
I look forward to seeing what Cluso and Peter come up with. I'm sure I'd be happy with it.
There is some feature cost, which is why I suggest the below...
I would suggest release of a ROM image, minus SD, so testing can proceed.
If you can also outline the spare ROM space, and how the code is loaded/run, and allocate spare Pin-Overrule mappings, that would allow others to craft SD candidates that can be tested in parallel with other work.
ie a SD pin-overrule mapping would be tested for, but simply return from an empty SD call.
[quote="cgracey;1387084"
I know SD is doable, but it takes more time and energy to get working.
[/quote]
The important thing is to avoid consuming your time and energy, but to release something asap that can allow rigorous test of test Flash-boot, and allow others to craft a SD candidate...
And support Peter in having the solution he wants, because even if not standard it's certainly excellent. So bring out the next version FPGA and you will gain support from the forth front!
The volumes are low and, to certain level, the BOM cost is irrelevant, because of the niche product, while the space (component count, pcb complexity) is many times an issue because being this mostly hand production I am unable to use all the miniaturized packages and multi-layer pcbs also increases costs. For example my 4 channel configurable dimmer/switch (8 wide voltage IN, 4POUT with independent current measurement, bus operated) is using this box.
That said, regarding the SD, I will use it if available, certainly. But I will use it only if I will have the possibility to have the firmware away from the main file system. By improperly dealing with the SD you can corrupt it, it's enough you corrupt a small part (eg the fat table, a thing that is updated on nearly every file write access), to make it unusable. This must not corrupt your firmware that can then detect it and handle the error properly.
I will never use both, the flash and SD, if not forced or if the former will not be internal. But the choosing factors will not be of course only the SD boot but also the other features of the smart pins that can help me reach the goal. In the case of PIC16F1779/16F1789 the hall effect current sensor that provides isolation between high and lo voltage is directly connected to the MCU. With its comparator and dac I set the max current that in hw switch-off immediately the pwm thus avoiding mosfet damages and with the adc at the same time I read the current for process needs: stats and adjustments. So the hw peripherals, once setup, offloads the cpu from safety checks (which thus react quicker and require smaller inductors, if any at all) and most of the timing controls/calculations and let it simply manage the process helping me not becoming crazy with interrupts.These are the models upon which I asked (in the other thread) how are comparators/opamps with DAC references with external and internal inputs/outputs supported on P2.
P2, if will have the features I've understood, will be a great advance because of its huge ram: my projects usually do not need big code memory, but I need a lot of ram and storage because most of the time the applications logs many parameters continuously. On the other side I am not building health-care or HA equipment thus a few ms more of booting time are acceptable for me, but I understand the ones that require instantly on MCU's.
So I think my rate can be around 3 to 4. It must be simple and reliable, future proof and easy for you to implement, but done properly. It not have to be easy to understand, easy for students, occasional users since all this can be automated and handled with sw tools, if needed (eg to prepare the MBR), and thus be transparent to the end user.
And once again, even for flash, please consider a double image for the ones that want it. IMHO an MBR can be also in the flash (but it can be deadly simple as reading an offset in the first location). This doesn't means that flash will have any file system, just a small area where the image to be booted can be chosen. In the past I've used Lantronix modules for connectivity. Now I am using Tibbo's for many years. With tibbo I am able to program PICs directly through ICSP and P1 by writing to the I2C fram (I use FM31L278 usually) or the serial port. With these MCU the firmware is small and in case of remote (internet mostly 3g/4g) upgrades I buffer the FW image in the tibbo prior to rewrite the MCU. But with the P2 the hub is much greater (and will probably be bigger in P3). This allows for bigger firmware that can't be buffered. A direct remote update can be dangerous eg in case of power outage or data corruption during the reflash process. On the other side you can reflash the unused image and once finished and verified it change the boot selector to it. For the latter (the selector change) power supply capacitors can easily protect (backup) from power outages during the rewrite.
Perhaps an image-choice-force could even be usefully added to the Pin-Overrule map, as the needed QuadSPI pin define, gives many choices.
Err, not quite.
The cheapest SPI Flash is showing at 4Mb, which is exactly 512kB
16Mb (& above) are available, but for now still a higher price than 4Mb.
Of course, Fast-SPI boot should always remain a cornerstone of P2.
Everything else can be handled by the second stage boot that is your own code and you can do whatever you want.
Edit: Well, I suppose only a single protected flash image would be okay. It could then boot a second-stage loader from one of two ping-pong partitions. Maybe this is what you were suggesting. Sorry for being dense!