I think worrying about having the first stage booter able to boot from SD card is silly. It just doesn't matter. Second stage is a fine place for worrying about SD and all it's details.
The only real upgrade to booting that could happen that would be significant is if they could get flash on die and not need an external flash chip, and that is unlikely to happen any time soon if at all.
If you can't just copy a file to the SD card using stock OS stuff, and then boot from that on the P2, then it's not good enough, and most people won't use the feature.
I really don't know what all the fuss is about !!!
Having a pointer in the MBR solves everything...
No need for any old/current/new partition layout. Just works where ever you place your code sectors
- just write that location to the MBR with whatever tool you wish to use, including a Prop program.
If you want a separate Partition. No worries - you can do that too
- just write that location to the MBR with whatever tool you wish to use, including a Prop program.
If you want FAT16/FAT32 or any other XFS or whatever. No worries either - you can do that too
- just write that location to the MBR with whatever tool you wish to use, including a Prop program.
For me, I already use FAT32 for my PropOS and also ZiCog (Z80 & CPM2.2 emulation). I just copy the file(s) across to the FAT32 file system on my PC using either a USB SD Card Reader, a USB to microSD adapter, or an SD to microSD adapter - all exist and just work on my current W10 laptop, but they also work on my older XP, Vista, and W7 laptops (9 & 10 years old).
I never change my boot code as it reads both FAT16 & FAT32 file systems and also CPM File Systems.
All I need to support the new method is write the "pointers" to the MBR (using the Prop) and I can siplify my boot EEPROM Boot Program and it will work for now and in the future with whatever FATxx replaces FAT32.
Everyone's method is covered by this simplification, so please, what is all the fuss about ???
I think worrying about having the first stage booter able to boot from SD card is silly. It just doesn't matter. Second stage is a fine place for worrying about SD and all it's details.
The only real upgrade to booting that could happen that would be significant is if they could get flash on die and not need an external flash chip, and that is unlikely to happen any time soon if at all.
If you can't just copy a file to the SD card using stock OS stuff, and then boot from that on the P2, then it's not good enough, and most people won't use the feature.
I don't see why that should put people off. They already use a custom tool for loading programs over a serial connection. Why not use a custom tool to create bootable SD cards?
Roy,
Why require a FLASH chip just to boot from an SD Card ?
If an SD Card is present then the FLASH pins can be used.
All my current P1 boards require an EEPROM just to boot from an SD Card. I pre-program the EEPROM and disable writing to it. It's a waste of space and parts and for those who don't understand production, the cost of placing these components is far greater than the parts cost!!!
Sometimes I have to wonder whether you guys that are commenting have ever manufactured products in volume and/or needed to be price competitive ???
I have designed and manufactured price competitive products in the 100,000's per annum (including for Apple USA). I have also co-owned and run a contract assembly house.
If you load your firmware onto an SD card and insert it into a P2 system you could then download a binary serially into RAM for setting up the MBR automatically. A single one step process, no PC code involved. On the next reset it will boot your file nicely from the microSD. No Flash chip required!
I wonder how many commercial or high volume projects using a Prop also have and SD card at all let alone one for booting from?
Probably the same is true for most MCUs.
I was a bit harsh saying it was silly, but I don't think it's going to really impact things much if P2 can't 1st stage boot from SD. Yes I am aware of the extra costs involved, but that's only for people that want the SD boot option without having a flash chip, and like I said before, it's probably not much of the lifetime volume of P2s.
I also think you are overstating the "simplicity" of making some ROM code that will reliably read and boot from any SD cards past, present, and future.
Well, it seems there are a lot of different opinions about how to handle SD boot.
Maybe that's another reason to leave that to a second stage booter...
I think worrying about having the first stage booter able to boot from SD card is silly. It just doesn't matter. Second stage is a fine place for worrying about SD and all it's details.
The only real upgrade to booting that could happen that would be significant is if they could get flash on die and not need an external flash chip, and that is unlikely to happen any time soon if at all.
This means that SD users will always have to use also a flash chip.
If you can't just copy a file to the SD card using stock OS stuff, and then boot from that on the P2, then it's not good enough, and most people won't use the feature.
Anyone who deal/program any mcu is using a sort of non OS stock utility/environment/IDE. Any non OS stock utility that allows you to transfer the firmware on the SD will be used by these users with no pain. Eventually it can be called from the IDE itself and thus become transparent to the developer.
I really don't know what all the fuss is about !!!
Having a pointer in the MBR solves everything...
...
Agreed.
Could we define the pointer location being a little-endian long (4 bytes) at absolute address 1F6h (502 dec) of SD's block 0.
Could we define an ID byte being at abbsolute address 1F2h (498 dec) with a defined value from one of this: B0h, A2h, 12h, 27h
** Could we optionally define absolute address 1EEh (494dec) as fw image pointer (for multi image cases, safe filed fw upgrades).
Could we define the following SD boot process:
1) read block 0 form SD
2) evaluate if its 1F2h address contains B0h value
3) start sequentially reading reading blocks from the one pointed by address 1F6h
3**) with image pointer: start sequentially reading blocks from the one pointed by: value(1F6h)+(value(1EEh)*4096)
4) first fw image data will contain the size to read.
And in all this I purposely never used any definition like MBR, partition, file, file-system, ...
Anyone is free tho call the above locations/process however he wants.
...Everyone's method is covered by this (the above) simplification ...
And with optional image pointer you can also safely field upgrade the firmware (one image) and at the end change the image pointer to it.
As I said before there will be some users that will use an SD in place of the flash chip even without any filesystem and never remove it from the board.
Peter seems to be one of them
...
I envisage using microSD cards simply as local storage with its own secure and Flash friendly file system without ever being removed or placed into a PC. The initial boot image burner and image would be loaded via serial.
...
Edit:
PS: I know that multiimage boots can be handled from the second stage loader but, if the fw image at the beginning contains its size and execution address and mode(hub/cog exec), also the first stage can load all the hub ram using both flash or SD. Why bother with multistage loaders when not required.
This tutorial says that you need a SD-USB adapter. But actually there is no need for such adapter. Every laptop with integrated SD reader can recognize the disk. But the tutorial is still useful.
I wonder how many commercial or high volume projects using a Prop also have and SD card at all let alone one for booting from?
Probably the same is true for most MCUs.
...
I have commercial P1 products that only contain a simple boot code to boot from the SD card. The EEPROM has write protect enabled.
I also have hobbyist P1 boards that also only use the EEPROM to boot from SD card. Again the EEPROM is write protected by default.
Another point here is that these cards DO NOT REQUIRE AN EXPENSIVE PROPPLUG TO WORK. Not even a cheap ($1.50) USB-Serial board is required to change the code on the SD card.
...
I also think you are overstating the "simplicity" of making some ROM code that will reliably read and boot from any SD cards past, present, and future.
IMHO I have proven it works since my boot code has worked for about 7 years so far and I haven't used the simpler method which removes the FAT16/32 requirement, which BTW I suggested many years ago for the P2.
Seems we've had this sd boot debate several times in the past...
I'm still with Roy, that a normally formatted SD card with a specific filename to boot from is the simplest approach. That's what the code I posted does.
This is also how most other devices with SD storage, work. Just with files, not MBR or partition tricks...
I also expect there to be other resources on the SD card besides just the boot code, BTW.
Being able to program the P2 without a PropPlug does sound good.
Maybe that's the only reason to think about having SD read in ROM.
On the other hand, P2 can be USB device or host, allowing one to program directly that way...
Seems we've had this sd boot debate several times in the past...
I'm still with Roy, that a normally formatted SD card with a specific filename to boot from is the simplest approach. That's what the code I posted does.
This is also how most other devices with SD storage, work. Just with files, not MBR or partition tricks...
I also expect there to be other resources on the SD card besides just the boot code, BTW.
Being able to program the P2 without a PropPlug does sound good.
Maybe that's the only reason to think about having SD read in ROM.
On the other hand, P2 can be USB device or host, allowing one to program directly that way...
Doesn't that mean the ROM needs to understand the filesystem format? I really don't like the "search for a magic string" approach and the requirement that the file be contiguous.
The FAT filesystem format is quite simple actually... The code I posted uses the FAT, so the file doesn't have to be contiguous.
I would prefer that the ROM not know anything about FAT.
+1
I think "Net" booting is very important, but I have no idea about the timing constraints. Somewhere in there we might need a bit that says the boot code is coming from a wireless serial connection... wait a little longer than normal. It could be a switch... we certainly have enough pins:)
I've been busy getting PNut.exe adapted to the new serial text loading scheme.
I haven't taken any time yet to read how SD works, so I don't have my own opinion of what should be done. If I had a flow chart or pseudo code to go from, I could write the code. I agree there's no room for FAT. We need a simple approach without many layers of decisions. I wish you guys could come to some agreement, given my own current lack of understanding.
How about this: What can be achieved in 64 instructions? In 128? In 256?
Won't the plain text serial option cover that case?
I really don't know, but then again it is not exactly a critical point either:)
My question about hub ram is germane to the issue of speed. If hub ram is conserved while power is on, then if someone wants the fastest possible reboot... It seems to me that RAM would be the place for emergency code, not pushing speed in the ROM process.
...And, I'm really glad you guys are concerned about this. Being able to boot from an SD card would be really clean. Hello, stand-alone bench computer!
Comments
The only real upgrade to booting that could happen that would be significant is if they could get flash on die and not need an external flash chip, and that is unlikely to happen any time soon if at all.
If you can't just copy a file to the SD card using stock OS stuff, and then boot from that on the P2, then it's not good enough, and most people won't use the feature.
Having a pointer in the MBR solves everything...
No need for any old/current/new partition layout. Just works where ever you place your code sectors
- just write that location to the MBR with whatever tool you wish to use, including a Prop program.
If you want a separate Partition. No worries - you can do that too
- just write that location to the MBR with whatever tool you wish to use, including a Prop program.
If you want FAT16/FAT32 or any other XFS or whatever. No worries either - you can do that too
- just write that location to the MBR with whatever tool you wish to use, including a Prop program.
For me, I already use FAT32 for my PropOS and also ZiCog (Z80 & CPM2.2 emulation). I just copy the file(s) across to the FAT32 file system on my PC using either a USB SD Card Reader, a USB to microSD adapter, or an SD to microSD adapter - all exist and just work on my current W10 laptop, but they also work on my older XP, Vista, and W7 laptops (9 & 10 years old).
I never change my boot code as it reads both FAT16 & FAT32 file systems and also CPM File Systems.
All I need to support the new method is write the "pointers" to the MBR (using the Prop) and I can siplify my boot EEPROM Boot Program and it will work for now and in the future with whatever FATxx replaces FAT32.
Everyone's method is covered by this simplification, so please, what is all the fuss about ???
Why require a FLASH chip just to boot from an SD Card ?
If an SD Card is present then the FLASH pins can be used.
All my current P1 boards require an EEPROM just to boot from an SD Card. I pre-program the EEPROM and disable writing to it. It's a waste of space and parts and for those who don't understand production, the cost of placing these components is far greater than the parts cost!!!
I have designed and manufactured price competitive products in the 100,000's per annum (including for Apple USA). I have also co-owned and run a contract assembly house.
Probably the same is true for most MCUs.
I was a bit harsh saying it was silly, but I don't think it's going to really impact things much if P2 can't 1st stage boot from SD. Yes I am aware of the extra costs involved, but that's only for people that want the SD boot option without having a flash chip, and like I said before, it's probably not much of the lifetime volume of P2s.
I also think you are overstating the "simplicity" of making some ROM code that will reliably read and boot from any SD cards past, present, and future.
Anyone who deal/program any mcu is using a sort of non OS stock utility/environment/IDE. Any non OS stock utility that allows you to transfer the firmware on the SD will be used by these users with no pain. Eventually it can be called from the IDE itself and thus become transparent to the developer.
Could we define the pointer location being a little-endian long (4 bytes) at absolute address 1F6h (502 dec) of SD's block 0.
Could we define an ID byte being at abbsolute address 1F2h (498 dec) with a defined value from one of this: B0h, A2h, 12h, 27h
** Could we optionally define absolute address 1EEh (494dec) as fw image pointer (for multi image cases, safe filed fw upgrades).
Could we define the following SD boot process:
1) read block 0 form SD
2) evaluate if its 1F2h address contains B0h value
3) start sequentially reading reading blocks from the one pointed by address 1F6h
3**) with image pointer: start sequentially reading blocks from the one pointed by: value(1F6h)+(value(1EEh)*4096)
4) first fw image data will contain the size to read.
And in all this I purposely never used any definition like MBR, partition, file, file-system, ...
Anyone is free tho call the above locations/process however he wants.
And with optional image pointer you can also safely field upgrade the firmware (one image) and at the end change the image pointer to it.
As I said before there will be some users that will use an SD in place of the flash chip even without any filesystem and never remove it from the board.
Peter seems to be one of them
Edit:
PS: I know that multiimage boots can be handled from the second stage loader but, if the fw image at the beginning contains its size and execution address and mode(hub/cog exec), also the first stage can load all the hub ram using both flash or SD. Why bother with multistage loaders when not required.
dd for windows: http://www.chrysocome.net/dd
Tutorial : http://www.86duino.com/?p=11264
This tutorial says that you need a SD-USB adapter. But actually there is no need for such adapter. Every laptop with integrated SD reader can recognize the disk. But the tutorial is still useful.
I also have hobbyist P1 boards that also only use the EEPROM to boot from SD card. Again the EEPROM is write protected by default.
Another point here is that these cards DO NOT REQUIRE AN EXPENSIVE PROPPLUG TO WORK. Not even a cheap ($1.50) USB-Serial board is required to change the code on the SD card. IMHO I have proven it works since my boot code has worked for about 7 years so far and I haven't used the simpler method which removes the FAT16/32 requirement, which BTW I suggested many years ago for the P2.
https://en.wikipedia.org/wiki/Master_boot_record
The image sector pointer is at offset $20:
I'm still with Roy, that a normally formatted SD card with a specific filename to boot from is the simplest approach. That's what the code I posted does.
This is also how most other devices with SD storage, work. Just with files, not MBR or partition tricks...
I also expect there to be other resources on the SD card besides just the boot code, BTW.
Being able to program the P2 without a PropPlug does sound good.
Maybe that's the only reason to think about having SD read in ROM.
On the other hand, P2 can be USB device or host, allowing one to program directly that way...
Is this going to be true for the P2 chip?
+1
I think "Net" booting is very important, but I have no idea about the timing constraints. Somewhere in there we might need a bit that says the boot code is coming from a wireless serial connection... wait a little longer than normal. It could be a switch... we certainly have enough pins:)
After WinXP the disk has to be locked or un-mounted to do so.
You can then use the standard file operations on the RAW disk using a name like "\\.\PhysicalDrive2" or even "\\.\H:" for a volume on a partition.
#include <io.h> #include <stdio.h> #include <stdlib.h> int main() { int fd; int result; unsigned char buf[512]; fd = open("\\\\.\\PhysicalDrive1",0); if (fd == -1) { printf("%d Open \n", fd); return -2; } result = read(fd, buf, 512); printf ("%d Read \n", buf[511]); return buf[511]; }read access usually does not need un-mounting and mounting (or locking/unlocking), but write access does.
But I still think the most easy way would be a program to load into RAM of the chip to do the writing.
Enjoy!
Mike
I haven't taken any time yet to read how SD works, so I don't have my own opinion of what should be done. If I had a flow chart or pseudo code to go from, I could write the code. I agree there's no room for FAT. We need a simple approach without many layers of decisions. I wish you guys could come to some agreement, given my own current lack of understanding.
How about this: What can be achieved in 64 instructions? In 128? In 256?
I really don't know, but then again it is not exactly a critical point either:)
My question about hub ram is germane to the issue of speed. If hub ram is conserved while power is on, then if someone wants the fastest possible reboot... It seems to me that RAM would be the place for emergency code, not pushing speed in the ROM process.