Meanwhile, Peter and my method will co-exist simply with ANY method you would like to use. How many times must we repeat this statement ???
Yours, Peter's AND MY methods are basically the same:
1. read an ID and a pointer located somewhere in the MBR
2. if ID matches start raw sequential block read from the pointed block/sector
What differs is the pointer and ID storage locations inside the MBR. You want to use part of the original bootcode area identified by addresses 1AE..1BD (430..445).
What I am trying to explain you is that your locations partially overlap with disk signature: precisely addresses 1B8..1BD (440.445). And there are systems/devices that automatically, without any notification, write to this area thus making your written data risky. And nearly all the modern systems register these values in their mounting tables thus identifying the storage media. It's not good to have the pointer here.
Moreover, in the case someone uses a dedicated partition, its starting point can be the fw pointer at the same time without requiring any pointer update. Otherwise you need to do the partition and then stil maintain a pointer somewhere else.
If you don't want a dedicated partition, you still need to use a pointer in the MBR. Why don't use the "unused" partition entry area?
How many times I must repeat this??? But I am sure this misunderstandings are due to my poor english, if not enough I will try to explain it in another way, don't worry!
David Betz,
Go back and reread what people have said. The suggestion was "copy the file normally to a valid partition" then run something to mod the MBR to point to that file. That is not standard in any way.
If the suggestion is the make a new partition type that is "P2 boot image" and it just contains the image, then that at least fits the MBR standards, but it still requires some special tool or code to create the partition and put the image in it. That's a PITA.
There is enough ROM space, just make it read FAT and be done with it. The code can read FAT16, FAT32, or exFAT (which is just FAT32 extended). That will cover the current and most recent SD standards.
The only limitation is trivial, don't use long file names, so there is no issues with the patents.
I understand that people have been talking about putting a pointer to a FAT file in the MBR. I disagree with that approach. My suggestion is til use a special partition type and write the boot code to a partition of that type using a standard partition table entry. I object to using the "boot code" area because, as some have pointed out, it is currently unused. That makes it very likely that some new MBR format will repurpose it for something else. We're better off using an area that is already defined and in the way it is supposed to be used.
Today, microcontrollers that require external Flash to boot are quite antiquated, and could be seen as yet another reason to skip the P2, and for that matter the P1.
This is due to the flash being external, not because it is flash. In this case, you could extend the same "antiquated" argument to just about any external media. Put another way, this is actually a non-argument for the current conversation. Unless Chip is secretly working on adding internal flash, external flash is going to be a regular occurrence in P2 designs. It's simple, small, and cheap. I doubt that the people who would dismiss the chip because of the external flash are likely to change their mind just because they can use an SD card instead. And I doubt that the lack of a single-stage SD boot will discourage anyone else from adding SD as a second-stage boot device.
In other words, single-stage SD boot is a "nice to have", not a "need to have." And it is very clear from the current discussion that there is no consensus on how SD boot should work. I say we leave SD boot out of the ROM and move on to other topics.
People will work from images too. I did. That was the super easy way to get running. Took 5 minutes.
I see two use cases:
1. Developer owns the SD card. No interoperability is planned, nor needed. Developer uses their own tools and manages the SD card. Card is not portable.
2. Interoperability is planned. Card is portable, could end up in other systems. Linux, macos, dos, windows, camera, etc...
Both use cases require a bit of code to prep the SD card. Tons of Pi users prep cards, and they don't care. After the first one, it's super easy. I do this all the time and don't even think about it. One product I support uses a Pi and the easiest thing is to have images. Insert card, write image, done.
People can opt to buy an SD with their product, and that SD can be prepped, or the product can include "use your formatted SD" as a boot method via flash. This is how the Pi world works. Those who want to roll their own SD, just do so. Those who want to just go, make sure an SD prepped for that purpose comes with the product.
There are two other branches in this tree:
1. Boot code in ROM, not something we want to update.
2. Boot code in flash, something we will want to update.
Why don't we just use a few longs and look for a pointer? and I suggest we use Peters pointer as he's got code, has a system, etc... he's got a valid, production use case.
If pointer not found, look for boot partition? We know how to do that one, and it's really simple and well defined. We aren't adding anything new.
If we include those two in the ROM, we can insure they work, are debugged, and basically any SD card ever made can function as a boot device.
All it takes is one of us to use whatever tools we want to make a reference image, say 2GB. With that, anyone can prep any SD card using any OS and either the OS tools, or the SD card association tools to get running quick.
And that's where the on chip support ends. It's enough.
More spiffy options can be delivered via flash, or bootstrapped via serial. Both of these use the system itself to prep any SD card, after which the boot happens from a prepped SD card.
Or, unprepped SD cards are directly supported via flash, can read filesystems, etc... and that's a choice left to those who design products and systems. Updates happen as needed.
We are targeting a 20 year life here. Stuff is gonna change. The higher level it is, the more it's likely to change. Target chip at the best practice, block level basics.
(and that's the two use cases above. Own the card, or plan for interoperability on the card.)
Advanced, current filesystem support is patent encumbered. Best leave that to the off chip use cases so it can be managed approprately.
BTW, I'm completely happy to ignore the SD card completely. Flash boot support for all this stuff is just fine.
Agreed. In fact, even if they put some kludgy FAT boot software in the ROM, I guess we can just ignore it if we use a SPI flash. I'm assuming the boot order will look for flash first.
That's my plan, just do it P1 style, given we don't end up with a best practice block level option. I've worked with tons of media, filesystems, etc... on everything from little tiny systems to big iron. Those basic definitions are the right way to go. Stuff will work, and it will work in scenarios we aren't even thinking about right now too. (that's why those basic, best practices are there)
Worse case, bootstrapping via serial is OK too. A while back, I did that on my old Apple //e. Got a machine, disk drive, no bootable media. Was kind of interesting. After some digging, I realized I could just type a DOS right in! But, the better path was to stream one in via serial, and that machine included just enough in the ROM to make that possible. (Woz had his head on straight for that one)
So, I watched a DOS get typed in. Formatted my first media, then the system runs from that.
I feel very strongly that the chip level stuff, baked in, needs to allow for enough options to make things possible. From there, bootstrapping is the bare minimum, and likely won't get used in the near term, though some brave soul many years from now may attempt it, just as I did, nearly 30 years after the hardware I wanted to use was produced! That's solid, and the way I would prefer we do this stuff. Mostly it will get ignored in the near term. But... our stuff will always be useful, if we think it through today.
Everything above that is a great case for second stage boot, or a native boot once the prep / bootstrapping work has been done.
Yeah, that's old school, but it's well proven, understandable, etc... We can count on it.
We have the serial baked in. So it's all possible now, just a matter of where we put the cutoff.
BTW, I'm completely happy to ignore the SD card completely. Flash boot support for all this stuff is just fine.
Agreed. In fact, even if they put some kludgy FAT boot software in the ROM, I guess we can just ignore it if we use a SPI flash. I'm assuming the boot order will look for flash first.
Sorry for commenting on my own message but it occurs to me that boot order may be an issue. I can see an argument for looking for SPI flash first in case someone is using an SD card in their system but doesn't want to boot from it. On the other hand, some might want SD to override flash sort of like you'd force booting from a CD on a desktop PC for loading a new OS. So it seems boot order should be configurable. Should that be done with fuses? Unfortunately, if you do it with fuses you won't ever be able to change it.
I think that the boot order might need to be SD first, so that any resident flash could be updated and no serial would ever be needed.
But that slows down the boot process even if you have a product that never boots off of SD if it has an SD card. Also, it could result in a product that doesn't work if someone inserts an SD card that looks like it has a boot image on it but it isn't a valid image. I really think this is a can of worms and it would probably be better to just boot from SPI flash and leave any of these complicated boot order issues to a second-stage loader.
But that slows down the boot process even if you have a product that never boots off of SD if it has an SD card. Also, it could result in a product that doesn't work if someone inserts an SD card that looks like it has a boot image on it but it isn't a valid image. I really think this is a can of worms and it would probably be better to just boot from SPI flash and leave any of these complicated boot order issues to a second-stage loader.
+1
Also, if SD boot is first, then it will be very difficult (if not impossible) for people implement an alternative SD boot.
I think that the boot order might need to be SD first, so that any resident flash could be updated and no serial would ever be needed.
But... why? Suppose you were to program the flash as a second-stage loader for your SD card. Why would you want to use the SD card to reprogram the flash, apart from installing an improved loader? And, in that case, it seems reasonable that you would still boot with the "current" loader, then just overwrite it once the second-stage SD has booted.
It wouldn't make sense to even have the flash installed if you were primarily running off the SD card. It seems to me that the only use case for booting SD first is to use SD only to update flash. Afterward, you would have to remove the SD card to actual boot from flash. I think this is the least likely way that multi-device booting would be used.
I think that the boot order might need to be SD first, so that any resident flash could be updated and no serial would ever be needed.
But that slows down the boot process even if you have a product that never boots off of SD if it has an SD card. Also, it could result in a product that doesn't work if someone inserts an SD card that looks like it has a boot image on it but it isn't a valid image. I really think this is a can of worms and it would probably be better to just boot from SPI flash and leave any of these complicated boot order issues to a second-stage loader.
The SD data would be validated by SHA-256/HMAC, so it wouldn't misfire. After SD, then SPI flash is checked.
Big question: How long does it take to read an SD card? Are there long timeouts? I know searching a FAT could take time, but probably not much, right?
With SHA-256/HMAC validation, boot order could be set by data contents. Whichever has a properly-signed loader gets used for booting, with SD having priority, so that it could either supply the whole application, or be used to update the SPI flash with a signed loader, so that on next boot, without the SD card plugged in, the SPI flash is used. This would allow easy field upgrades, where the SD card is only used to configure the system (by programming the SPI flash). SD would need boot priority. Just, how long would it take to read the SD card?
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.
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 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.
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).
The ROM should be as simple as possible. We know it has to have code to load sectors from SD, and do a basic sanity check before booting from it (maybe a simple checksum for validation, or maybe just a magic word check: either way something simple). That's all it should do. Put the policy on the SD card itself.
I think that the boot order might need to be SD first, so that any resident flash could be updated and no serial would ever be needed.
But that slows down the boot process even if you have a product that never boots off of SD if it has an SD card. Also, it could result in a product that doesn't work if someone inserts an SD card that looks like it has a boot image on it but it isn't a valid image. I really think this is a can of worms and it would probably be better to just boot from SPI flash and leave any of these complicated boot order issues to a second-stage loader.
The SD data would be validated by SHA-256/HMAC, so it wouldn't misfire. After SD, then SPI flash is checked.
Big question: How long does it take to read an SD card? Are there long timeouts? I know searching a FAT could take time, but probably not much, right?
How will the ROM determine that an SD card is present? Does that require a pin to be dedicated to that function even on a system that doesn't have an SD card? Maybe we could at least have a fuse that says to skip checking for an SD card?
I think that the boot order might need to be SD first, so that any resident flash could be updated and no serial would ever be needed.
But that slows down the boot process even if you have a product that never boots off of SD if it has an SD card. Also, it could result in a product that doesn't work if someone inserts an SD card that looks like it has a boot image on it but it isn't a valid image. I really think this is a can of worms and it would probably be better to just boot from SPI flash and leave any of these complicated boot order issues to a second-stage loader.
The SD data would be validated by SHA-256/HMAC, so it wouldn't misfire. After SD, then SPI flash is checked.
Big question: How long does it take to read an SD card? Are there long timeouts? I know searching a FAT could take time, but probably not much, right?
How will the ROM determine that an SD card is present? Does that require a pin to be dedicated to that function even on a system that doesn't have an SD card? Maybe we could at least have a fuse that says to skip checking for an SD card?
I figure we'd just toggle the pins, as needed, in case one is present. We could also use pull-up resistors on SD/SPI pins to determine behavior.
I think that the boot order might need to be SD first, so that any resident flash could be updated and no serial would ever be needed.
But that slows down the boot process even if you have a product that never boots off of SD if it has an SD card. Also, it could result in a product that doesn't work if someone inserts an SD card that looks like it has a boot image on it but it isn't a valid image. I really think this is a can of worms and it would probably be better to just boot from SPI flash and leave any of these complicated boot order issues to a second-stage loader.
The SD data would be validated by SHA-256/HMAC, so it wouldn't misfire. After SD, then SPI flash is checked.
Big question: How long does it take to read an SD card? Are there long timeouts? I know searching a FAT could take time, but probably not much, right?
How will the ROM determine that an SD card is present? Does that require a pin to be dedicated to that function even on a system that doesn't have an SD card? Maybe we could at least have a fuse that says to skip checking for an SD card?
I figure we'd just toggle the pins, as needed, in case one is present. We could also use pull-up resistors on SD/SPI pins to determine behavior.
So there will be a pin reserved for SD CS as well as flash CS even on systems with no SD card?
SD card boot should definitely not be first.
SPI flash for sure should be first.
If you want a system where you can update from SDcard without serial, then you can build it into your code in the SPI flash to update itself via SDcard (with all the proper validation and whatnot).
You don't want to fix in the SD -> SPI flash update process in the P2 ROM, that will be far to restrictive.
SD card boot should definitely not be first.
SPI flash for sure should be first.
If you want a system where you can update from SDcard without serial, then you can build it into your code in the SPI flash to update itself via SDcard (with all the proper validation and whatnot).
You don't want to fix in the SD -> SPI flash update process in the P2 ROM, that will be far to restrictive.
But if the SD card has no signed boot program, it doesn't boot. Whichever has the proper signature would be the one to boot. In the case where they BOTH have good signatures, one of them needs priority, and it seems the SD card should have it, so that it can possibly update the SPI flash.
SD card boot should definitely not be first.
SPI flash for sure should be first.
If you want a system where you can update from SDcard without serial, then you can build it into your code in the SPI flash to update itself via SDcard (with all the proper validation and whatnot).
You don't want to fix in the SD -> SPI flash update process in the P2 ROM, that will be far to restrictive.
But if the SD card has no signed boot program, it doesn't boot. Whichever has the proper signature would be the one to boot. In the case where they BOTH have good signatures, one of them needs priority, and it seems the SD card should have it, so that it can possibly update the SPI flash.
Is it possible that this is a security problem? What about a product that should boot exclusively from SPI flash but also has an SD card for data storage? If a user writes a bootable image on an SD card it will override the flash and that will allow unauthorized software to run on the device. It seems to me that the idea of first looking at the SD card is mostly useful if you want to use the P2 as a standalone system. Is this really likely to be the most common use?
Not laughing at anyone in particular. Just us. We care. What a saga!
Ersmith's contribution is worth thinking about IMHO. I'm in full support as that is compliant with other stuff out there, and that would get us interoperability with a lot of unforseen scenarios. To me, that's the biggest concern.
With his idea, we end up with an Apple 2 kind of scenario. The ROM is just enough to fetch that first "track", and in our case, block. From there, the card contains what it needs to do it's thing, which could be to just fetch a bunch more blocks, using the ROM routines as is, and go, or it could fetch a second stage, which contains filesystem support, etc... and then go from there.
I like this a lot. Count me as a fan. People do what makes sense for them, and we don't worry about any of it.
We just don't own the SD card, that's what this comes down to. We can take ownership of it, but at a cost of breaking general expectations about the media. This is the nature of portable media of all kinds.
We do own SPI flash, and we do what we want and what is simplest with no worries.
I'm still happy with no SD boot. It's fine. We just put all this into the flash, and we all do what we want.
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.
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 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.
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).
The ROM should be as simple as possible. We know it has to have code to load sectors from SD, and do a basic sanity check before booting from it (maybe a simple checksum for validation, or maybe just a magic word check: either way something simple). That's all it should do. Put the policy on the SD card itself.
Eric
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.
Comments
I expect there will be an open source FAT sometime in the future.
Meanwhile, Peter and my method will co-exist simply with ANY method you would like to use. How many times must we repeat this statement ???
Yours, Peter's AND MY methods are basically the same:
1. read an ID and a pointer located somewhere in the MBR
2. if ID matches start raw sequential block read from the pointed block/sector
What differs is the pointer and ID storage locations inside the MBR. You want to use part of the original bootcode area identified by addresses 1AE..1BD (430..445).
What I am trying to explain you is that your locations partially overlap with disk signature: precisely addresses 1B8..1BD (440.445). And there are systems/devices that automatically, without any notification, write to this area thus making your written data risky. And nearly all the modern systems register these values in their mounting tables thus identifying the storage media. It's not good to have the pointer here.
Moreover, in the case someone uses a dedicated partition, its starting point can be the fw pointer at the same time without requiring any pointer update. Otherwise you need to do the partition and then stil maintain a pointer somewhere else.
If you don't want a dedicated partition, you still need to use a pointer in the MBR. Why don't use the "unused" partition entry area?
How many times I must repeat this??? But I am sure this misunderstandings are due to my poor english, if not enough I will try to explain it in another way, don't worry!
This is due to the flash being external, not because it is flash. In this case, you could extend the same "antiquated" argument to just about any external media. Put another way, this is actually a non-argument for the current conversation. Unless Chip is secretly working on adding internal flash, external flash is going to be a regular occurrence in P2 designs. It's simple, small, and cheap. I doubt that the people who would dismiss the chip because of the external flash are likely to change their mind just because they can use an SD card instead. And I doubt that the lack of a single-stage SD boot will discourage anyone else from adding SD as a second-stage boot device.
In other words, single-stage SD boot is a "nice to have", not a "need to have." And it is very clear from the current discussion that there is no consensus on how SD boot should work. I say we leave SD boot out of the ROM and move on to other topics.
This gets done, it's not hard, etc...
People will work from images too. I did. That was the super easy way to get running. Took 5 minutes.
I see two use cases:
1. Developer owns the SD card. No interoperability is planned, nor needed. Developer uses their own tools and manages the SD card. Card is not portable.
2. Interoperability is planned. Card is portable, could end up in other systems. Linux, macos, dos, windows, camera, etc...
Both use cases require a bit of code to prep the SD card. Tons of Pi users prep cards, and they don't care. After the first one, it's super easy. I do this all the time and don't even think about it. One product I support uses a Pi and the easiest thing is to have images. Insert card, write image, done.
People can opt to buy an SD with their product, and that SD can be prepped, or the product can include "use your formatted SD" as a boot method via flash. This is how the Pi world works. Those who want to roll their own SD, just do so. Those who want to just go, make sure an SD prepped for that purpose comes with the product.
There are two other branches in this tree:
1. Boot code in ROM, not something we want to update.
2. Boot code in flash, something we will want to update.
Why don't we just use a few longs and look for a pointer? and I suggest we use Peters pointer as he's got code, has a system, etc... he's got a valid, production use case.
If pointer not found, look for boot partition? We know how to do that one, and it's really simple and well defined. We aren't adding anything new.
If we include those two in the ROM, we can insure they work, are debugged, and basically any SD card ever made can function as a boot device.
All it takes is one of us to use whatever tools we want to make a reference image, say 2GB. With that, anyone can prep any SD card using any OS and either the OS tools, or the SD card association tools to get running quick.
And that's where the on chip support ends. It's enough.
More spiffy options can be delivered via flash, or bootstrapped via serial. Both of these use the system itself to prep any SD card, after which the boot happens from a prepped SD card.
Or, unprepped SD cards are directly supported via flash, can read filesystems, etc... and that's a choice left to those who design products and systems. Updates happen as needed.
We are targeting a 20 year life here. Stuff is gonna change. The higher level it is, the more it's likely to change. Target chip at the best practice, block level basics.
(and that's the two use cases above. Own the card, or plan for interoperability on the card.)
Advanced, current filesystem support is patent encumbered. Best leave that to the off chip use cases so it can be managed approprately.
Worse case, bootstrapping via serial is OK too. A while back, I did that on my old Apple //e. Got a machine, disk drive, no bootable media. Was kind of interesting. After some digging, I realized I could just type a DOS right in! But, the better path was to stream one in via serial, and that machine included just enough in the ROM to make that possible. (Woz had his head on straight for that one)
So, I watched a DOS get typed in. Formatted my first media, then the system runs from that.
I feel very strongly that the chip level stuff, baked in, needs to allow for enough options to make things possible. From there, bootstrapping is the bare minimum, and likely won't get used in the near term, though some brave soul many years from now may attempt it, just as I did, nearly 30 years after the hardware I wanted to use was produced! That's solid, and the way I would prefer we do this stuff. Mostly it will get ignored in the near term. But... our stuff will always be useful, if we think it through today.
Everything above that is a great case for second stage boot, or a native boot once the prep / bootstrapping work has been done.
Yeah, that's old school, but it's well proven, understandable, etc... We can count on it.
We have the serial baked in. So it's all possible now, just a matter of where we put the cutoff.
Maybe we could have it on same pins as SPI flash. So, it'd be one or the other.
+1
Also, if SD boot is first, then it will be very difficult (if not impossible) for people implement an alternative SD boot.
But... why? Suppose you were to program the flash as a second-stage loader for your SD card. Why would you want to use the SD card to reprogram the flash, apart from installing an improved loader? And, in that case, it seems reasonable that you would still boot with the "current" loader, then just overwrite it once the second-stage SD has booted.
It wouldn't make sense to even have the flash installed if you were primarily running off the SD card. It seems to me that the only use case for booting SD first is to use SD only to update flash. Afterward, you would have to remove the SD card to actual boot from flash. I think this is the least likely way that multi-device booting would be used.
So, just leave SD boot out of the ROM.
The SD data would be validated by SHA-256/HMAC, so it wouldn't misfire. After SD, then SPI flash is checked.
Big question: How long does it take to read an SD card? Are there long timeouts? I know searching a FAT could take time, but probably not much, right?
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 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:
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.
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).
The ROM should be as simple as possible. We know it has to have code to load sectors from SD, and do a basic sanity check before booting from it (maybe a simple checksum for validation, or maybe just a magic word check: either way something simple). That's all it should do. Put the policy on the SD card itself.
Eric
But then, you can bump clock up to 20 MHz (if I recall correctly).
Then, its about as fast as SPI flash.
I figure we'd just toggle the pins, as needed, in case one is present. We could also use pull-up resistors on SD/SPI pins to determine behavior.
SPI flash for sure should be first.
If you want a system where you can update from SDcard without serial, then you can build it into your code in the SPI flash to update itself via SDcard (with all the proper validation and whatnot).
You don't want to fix in the SD -> SPI flash update process in the P2 ROM, that will be far to restrictive.
But if the SD card has no signed boot program, it doesn't boot. Whichever has the proper signature would be the one to boot. In the case where they BOTH have good signatures, one of them needs priority, and it seems the SD card should have it, so that it can possibly update the SPI flash.
*sigh*
Like seriously, less than 1% of P2s lifetime installed base for it's lifetime will even have an SD card let alone want to boot from it.
Not laughing at anyone in particular. Just us. We care.
Ersmith's contribution is worth thinking about IMHO. I'm in full support as that is compliant with other stuff out there, and that would get us interoperability with a lot of unforseen scenarios. To me, that's the biggest concern.
With his idea, we end up with an Apple 2 kind of scenario. The ROM is just enough to fetch that first "track", and in our case, block. From there, the card contains what it needs to do it's thing, which could be to just fetch a bunch more blocks, using the ROM routines as is, and go, or it could fetch a second stage, which contains filesystem support, etc... and then go from there.
I like this a lot. Count me as a fan. People do what makes sense for them, and we don't worry about any of it.
We just don't own the SD card, that's what this comes down to. We can take ownership of it, but at a cost of breaking general expectations about the media. This is the nature of portable media of all kinds.
We do own SPI flash, and we do what we want and what is simplest with no worries.
I'm still happy with no SD boot. It's fine. We just put all this into the flash, and we all do what we want.