FDISK? LOL!! (actually need it, or gpartd, or something like that too, I've just been lazy in my commentary)
The thing is, a small program could be made, and should be made for "those windows users", and frankly a whole lot of UNIX ones that don't really know what disks, partitions, filesystems and such are, and I don't get that at all.
No matter what, a nice little program is good for the "non-pro", but that shouldn't drive the spec for those that don't need a little program.
I find it hilarious! So, we are out to make a pro device with pro tools, and that's gcc and friends. Great!! I'm all over that, because using those tools is a great practice, empowering, cross platform, free, etc...
Then we break down on a couple of basic things like mkfs & dd? Who are we really building for?
Joe blow hobby guy, or that "professional?" The Pro guy, setup on Linux will know all about that and can execute it cold, and it's resonant with all they know. The hobby guy who wants to just click stuff? Seriously? We are thinking about THAT?
Frankly, my advocacy for a compliant boot capability is all about the "pro", in that anyone who knows their stuff about booting, filesystems, disks, etc... would have zero trouble with a compliant boot process. Easy stuff, the docs could be a mere script and a coupla paragraphs, with the rest being understood.
If we aren't doing that, then who really cares? Just do something on the SD card, document it, and leave the folks who know better asking, "WTF?" scratching their heads and likely bitching about having to use the tool, instead of their open, standard workflow. Isn't that funny? (no, but laugh, because I am)
And the bizarre thing is chasing this "windows user" who apparently is so clueless they can't do anything other than copy a file and insert a card? LOL!! (have to laugh, because it gets rather painful, if I don't.)
Edit:
My point here being that Parallax went to considerable effort to build out a nice, standard, pro grade, open tool chain. Good on 'em for that. Tons of people here said that was absolutely necessary to capture the "pro" market, whatever that really is. Let's say it's there, and that the gcc efforts, right along with the more serious branding, etc... all make great sense.
If it makes sense, then why break from that on this feature? There are well established, time tested, widely accepted, robust, free, ways to deal with media, partitions and filesystems, and not only is it being discussed not to use them in favor of "this tool", but some are actually advocating ways of doing things that makes sure nobody CAN use them! Nuts!
The right way to do this is precisely what is being done with the gcc tools too. If somebody knows their stuff, the gcc package is right there, as complex and flexible powerful as needed. Command line the whole thing, if you want to. That's pro stuff, right? No getting in the way of people who know what they are really doing, right?
What did we do for the hobby person? SimpleIDE, which runs on top of "the right way" hiding all that real stuff so that people have a good shot at getting their stuff done and learning more about it on the way. Fantastic!
Same should apply here. Get the boot compliant, robust, effective. Then build the tool on top of that. The folks that know their stuff will appreciate a device that can boot in a standard way, those that don't can use the tool, and those that want to hack out their own path (which is a perfectly fine thing to do, mind you) can do their thing, authoring their own tools.
Rant mode = 0 (I did say I would bow out, and I think I shall. RAM is worth more than a broken SD feature, IMHO)
The PropII should not have the search feature then, unless it looks at FAT tables.
As we don't want the PropII to find old "deleted" code.
A PC util or PropTool will have no problem reading fat32 to find the lastest location of the file.
So there will be no simple drag and drop, but always saved/re-scanned with a util or Prop-Tool.
And I think we should use all the 440bytes in MBR reserved for code/pointers to point to 128kb worth of sectors for a quick boot of a full program.
No utility is required if one of the pointer options is to look at a partition table entry. UNIX / Linux / MAC OS are set and have the required tools.
This COULD work, but you would need to have the initial pointer in MBR point to another location in MBR, which had a small program inserted into the 446 bytes available in mbr.
You would have to write a really small program that tells the prop2 how to: do proper sd card i/o, read the partition table, read the file table, find the proper file, and load it.
Can it all fit inside the (safe areas) of the mbr is the question?
If the prop just did a search for ID, no program would be needed to fit into the MBR.
If the prop knew to search for ID as last effort, With a tool (or another prop running a program), one could write a file with the proper id and pointer calulated, and all other ids removed on the sd card.
Heck, someone could even write a prop program that scanned the sd card for ID, and removed any. And then scanned card for proper program signature, once found, the mbr would be updated with ID and pointer.
Really theres many ways to accomplish this with the prop2, if it does a ID/pointer sd card support.
The 8086 processor does exactly this. The cpu inside your pc, right now, has no clue WTF a FAT/NTFS etc is. Your computers mbr has a program that runs on the cpu, which has pointer to bigger boot program.
The cpu DOES NOT look for a specific partiton. It first runs a program inside the mbr.
We installed this pointer and bigger boot program, using previous versions of the 8086 to create the framework, (cdrom) to install the proper program onto the mbr, which in turn has a program and pointer to recognise the file system format and then runs the desired file. a.k.a Windows 7.
Having the prop look in the FAT tables when it searches is incompatible with other sd card formats.
No framework could be relied upon in the ROM.
Strictly from a P2 chip point of view, the only thing that the chip should know is:
How to access the sd card to look for specific bytes (ID and pointer) and if not found, do linear search.
No table, no partition, nothing, just data. This means less possibilities for bugs.
The ROM program would also need to deal with the possibility that the sd card might already be in high speed mode.
Bootstrapping can also refer to the development of successively more complex, faster programming environments. The simplest environment will be, perhaps, a very basic text editor (e.g., ed) and an assembler program. Using these tools, one can write a more complex text editor, and a simple compiler for a higher-level language and so on, until one can have a graphicalIDE and an extremely high-level programming language.
Historically, bootstrapping also refers to an early technique for computer program development on new hardware. The technique described in this paragraph has been replaced by the use of a cross compiler executed by a pre-existing computer. Bootstrapping in program development began during the 1950s when each program was constructed on paper in decimal code or in binary code, bit by bit (1s and 0s), because there was no high-level computer language, no compiler, no assembler, and no linker. A tiny assembler program was hand-coded for a new computer (for example the IBM 650) which converted a few instructions into binary or decimal code: A1. This simple assembler program was then rewritten in its just-defined assembly language but with extensions that would enable the use of some additional mnemonics for more complex operation codes. The enhanced assembler's source program was then assembled by its predecessor's executable (A1) into binary or decimal code to give A2, and the cycle repeated (now with those enhancements available), until the entire instruction set was coded, branch addresses were automatically calculated, and other conveniences (such as conditional assembly, macros, optimisations, etc.) established. This was how the early assembly program SOAP (Symbolic Optimal Assembly Program) was developed. Compilers, linkers, loaders, and utilities were then coded in assembly language, further continuing the bootstrapping process of developing complex software systems by using simpler software.
The term was also championed by Doug Engelbart to refer to his belief that organizations could better evolve by improving the process they use for improvement (thus obtaining a compounding effect over time). His SRI team that developed the NLS hypertext system applied this strategy by using the tool they had developed to improve the tool.
You wanna know how fast you can turn your current PC into a chip with a broken sata(pata) feature?
Now write a program, that will tell it how to do what it did before your girlfriend wrote her letter.
It seems hard, but it can be done, many ways, too.
Just because a chip doesn't know how to recognize volume formats, doesn't mean its useless.
Clock loop,
Your exponentialy more mucky bootstrapping with editors compilers and such is a totally different thing compared to a computer booting itself up.
Here is new testcode.
The ZIP includes the possible ROM boot code, and a tool to try it out.
The tool lets you write a bootfile, write and remove the pointer, look if the bootfile is contiguous and so on. When you finally choose "Try to boot" from the menu, then the utility stops FSRW and starts the cog with the ROM boot code.
The code expects the pointer now in the MBR table at partition 2. On an SD card with MBR there is
normally a partition 1 with a FAT file system. So if we use partition 2 for boot, we don't need to
change anything than the pointer and type for partition 2. This can be done by a little utility, like
in this testcode, or by a standard partition tools on Linux/MAC/Windows.
According my tests the new pointer in the partition table does not confuse Windows, also if the pointer points
only to a file and not a real partition (it's anyway a hidden partition with type $27).
So we have now 3 options to setup a bootable SD card:
1) Copy a bootfile with a signature to an empty SD card
2) Copy a bootfile to an SD card (empty or not) and use a tool to set the pointer to it
3) Use a partition tool to make a second partition with the raw bootfile.
In case of 1) the rom_boot_code searches trough the sectors until it finds the signature at begin of the file (or datablock).
In case 2) and 3) the rom_boot_code uses the pointer in the MBR to find the file, both options are the same for the boot code, the difference is only how the user sets up the SD card. Option 2 works also if the SD card has only a VBR in sector 0 and no MBR.
Perhaps we can use a fuse to disable the search methode in case it is not desired by the user. The purpose of the search is to give a way to setup a Prop 2 system without the use of an IDE, a FTDI chip, or a PropPlug. Just copy the bootfile to an SD card and let the Prop search it. The search is anyway not executed if the rom code finds a pointer in sector 0.
I must say that I have not tested option 3) so far. I find it too complicated to use a partition tool just to write a bootfile to an SD card. Perhaps someone that find this easy and the best way, can try if the rom boot code works with such a setup (make a partition type $27, and copy a textfile as the bootfile into the partition). You should then use only menu items 5 and 6 of the utility, all others will not work.
The first test with the utility should be to write the bootfile with "1", then press 5" to find the file.
After reloading the code, next step will be to write the pointer with "3" and see if the file is found now much faster.
I thought if you overwrote a file it used same dataspace? When you overwrite the file the data are first written to the disk where is free space and then the FAT entry is updated to point to the new file, making the old file new free space
Even so, any style we use to boot the prop and do it from inside the structure, in a file, the prop still needs to know where that file is to jump to, from the pointer, where ever it is. The pointer still somehow needs to get there. So any way you look at it, the prop2 will need a utility to boot from sd, to put the proper data in the proper location.
If duplicate deleted (but not) data on SD is a problem.....well
Any way its done, a special program will be needed to put special data on the sd card with special calculated pointers to the full sd file.
Last i checked, its not hard to make a utility to scan the SD card for any old ID/POINTERS, and wipe them out.
I have used those undelete utilities and some of them had a way to permanently erase the deleted "undeleted" data. It is called "wipe" and these utilities follows the file in the system writing over each byte a sequence of 00h,FFh,00h (in many of them you can set how many times to overwrite each byte in order to clear also the magnetic persistance from the hdd surface)
Then a simple tool that scans for old ID/pointer is all that one would need.
Even if you just drop the binary file onto a fat formatted small partition at the beginning of the sd card, the binary file still needs its ID inserted and pointer calculated, this would require a utility.
If it was to be all done from windows.
Those things can be done with the P2, after someone gets a framework programmed and going for that purpose.
Any frame work chosen will probably work, so long as no other ID's were still on the dataspace, if near the beginning of the sd card, the file would be found, the P2 could insert its ID/and jump into MBR.
If that sd card then gets used in a pc to update its binary file, it will need a SD utility that does id scan and removal, before the new file gets put onto the card.
And also, somehow that file needs an ID and pointer to itself, which isn't that hard to do, but again a special utility would need to be made.
Or the P2 would need to have flags that it would know to use the dataspace directly proceeding the ID/pointer. I don't see how that could be done, but if we could tell the prop to use the dataspace directly after the ID/pointer, then we wouldn't need to calculate and insert the pointer.
I don't mind if the prop looks for this in specific locations, and THEN does a linear search from MBR/VBR byte 0 for id/pointer.
This would allow a specific land, or allow someone to use the sd card as they wanted, so long as they insert a id/pointer near the beginning of the sd card.
If you have to use a PC special utility to write the pointer (or a special spin program in P1 or P2) then is the same if this utility beside writing the pointer writes also the whole binary to the SD. In this way the written binary can be the bootloader (the one that the ROM reads to boot further) or the whole 128K hub image. To require only one pointer in a well known offset of the MBR you must be able to write 128K of contiguous data. There is no file system that will guaranty this on a used media and to me is not aceptable to format the SD each time. I WANT a solution that allows for dedicated unformatted partition where the raw bootloader (or the whole hub image) can be stored away from the second partition (FAT formatted) that will be used as a data storage.
PS: I am not saying that this shold be the solution, but if the pointer allows to point to a file in the file system it must in the same way work also if pointed to a reserved partition. Of course the ROM code and the bootloader must not know nothing about any file system but must comply with the MBR specifications.
Here is new testcode.
The ZIP includes the possible ROM boot code, and a tool to try it out.
The tool lets you write a bootfile, write and remove the pointer, look if the bootfile is contiguous and so on. When you finally choose "Try to boot" from the menu, then the utility stops FSRW and starts the cog with the ROM boot code.
Woohoo.. more stuff to play with. being unemployed kinda sucks.. (well the not having money part) at least I have time to dig into all this mbr/sd/booting....
by the time I learn it all, the prop2 will be out....
hopefully i can find work by then, and make some money so i can finish: A.C.S.E.R. http://forums.parallax.com/entry.php?871-A.c.s.e.r.
Perhaps we can use a fuse to disable the search methode in case it is not desired by the user. The purpose of the search is to give a way to setup a Prop 2 system without the use of an IDE, a FTDI chip, or a PropPlug. Just copy the bootfile to an SD card and let the Prop search it. The search is anyway not executed if the rom code finds a pointer in sector 0.
I only want the 'search' in case a situation arises that requires the pointer location to be changed.
I always thought the prop1 could load its own binary and re-program its self, then restart with new program. Is this not the case?
I tried the sd card booter program and noticed it says load the program using the ide. Either its a bit complicated to self-load a program and boot it, or... it just wasn't implemented here.
I made a binary, renamed it BOOT.TXT, and put it on the sd card.
Just spent some quality time with a Live Ubuntu 10, I think. It's the one I had handy. And just created two partitions, both fairly small, first is FAT formatted, second raw.
BTW: Type 27 shows up as "diag" to some programs... Windows completely ignores it though.
Win32 Disk Imager isn't fast, but it can archive an SD card for multiple tries at this stuff.
Ok, got success on two methods: (well maybe, see below)
Method 1. Let the program write it's partition #2 info. It saw the one I did, and asked to overwrite. Here's the terminal chatter:
SD Test on Dracblade V5 via Serial
press a key
SD mounted!
First File:
FILE_OUT.ZIP at sector: 2668 size: 31232
Boot Test Menu:
(1) Write a boot file to SD card
(2) show used sectors of file
(3) Write the pointer in Sector 0
(4) Remove the pointer in Sector 0
(5) Try to boot
(6) show pointer data in Sector 0
(7) Remove all boot data
file written!
Boot Test Menu:
(1) Write a boot file to SD card
(2) show used sectors of file
(3) Write the pointer in Sector 0
(4) Remove the pointer in Sector 0
(5) Try to boot
(6) show pointer data in Sector 0
(7) Remove all boot data
boot file sectors:
- 2640 2641 2642 2643 - 2640 - 2645 2646 2647
- 2644 - 2649 2650 2651 - 2648 - 2653 2654 2655
- 2652 - 2657 2658 2659 - 2656 - 2661 2662 2663
- 2660 - 2665 2666 2667 - 2664 - 2749 2750 2751
sectors are not contiguous
Boot Test Menu:
(1) Write a boot file to SD card
(2) show used sectors of file
(3) Write the pointer in Sector 0
(4) Remove the pointer in Sector 0
(5) Try to boot
(6) show pointer data in Sector 0
(7) Remove all boot data
boot file at sector: 2640
There is already a partition 2! overwrite it?(y/n?
Type: $27
boot start sector: 100001
number of sectors: 900
Boot Test Menu:
(1) Write a boot file to SD card
(2) show used sectors of file
(3) Write the pointer in Sector 0
(4) Remove the pointer in Sector 0
(5) Try to boot
(6) show pointer data in Sector 0
(7) Remove all boot data
boot file at sector: 2640
There is already a partition 2! overwrite it?(y/n?
boot signature written!
Type: $27
boot start sector: 2640
number of sectors: 8
Boot Test Menu:
(1) Write a boot file to SD card
(2) show used sectors of file
(3) Write the pointer in Sector 0
(4) Remove the pointer in Sector 0
(5) Try to boot
(6) show pointer data in Sector 0
(7) Remove all boot data
boot file at sector: 2640
There is already a partition 2! overwrite it?(y/n?
Type: $27
boot start sector: 2640
number of sectors: 8
Boot Test Menu:
(1) Write a boot file to SD card
(2) show used sectors of file
(3) Write the pointer in Sector 0
(4) Remove the pointer in Sector 0
(5) Try to boot
(6) show pointer data in Sector 0
(7) Remove all boot data
Type: $27
boot start sector: 2640
number of sectors: 8
Boot Test Menu:
(1) Write a boot file to SD card
(2) show used sectors of file
(3) Write the pointer in Sector 0
(4) Remove the pointer in Sector 0
(5) Try to boot
(6) show pointer data in Sector 0
(7) Remove all boot data
search....0 seconds
bootfile at sector: 2640
[P2BOOT]
Propeller 2 would load this file from SD-
card. If you see this text the boot file
was found and loaded.
done (please reload code from IDE)
That's using the write the file and point the partition to it method.
You can see that larger partition data in there perfectly.
Now the "use standard tools method", which is to use fdisk, mkfs.msdos, and dd to build the partition and write the boot file. With a little different set of commands, this can be scripted. (Example link in process.txt attached)
press a key
SD mounted!
First File:
FILE_OUT.ZIP at sector: 2668 size: 31232
Boot Test Menu:
(1) Write a boot file to SD card
(2) show used sectors of file
(3) Write the pointer in Sector 0
(4) Remove the pointer in Sector 0
(5) Try to boot
(6) show pointer data in Sector 0
(7) Remove all boot data
Type: $83
boot start sector: 100001
number of sectors: 33
Boot Test Menu:
(1) Write a boot file to SD card
(2) show used sectors of file
(3) Write the pointer in Sector 0
(4) Remove the pointer in Sector 0
(5) Try to boot
(6) show pointer data in Sector 0
(7) Remove all boot data
search....1 seconds
bootfile at sector: 2632
[P2BOOT]
Propeller 2 would load this file from SD-
card. If you see this text the boot file
was found and loaded.
done (please reload code from IDE)
I forgot to set the hidden "diag" partition type on the second pass. So it was done with type "linux"... It worked, but doing search.
Is the "search..." triggered by the wrong partition type? If so, then I believe the code will work fine as my earlier pass fetched data from the boot partition created with the right type, it was just wayyy too big. And it did so without searching.
That really should be accounted for. No matter the partition size, only some blocks need to be loaded, IMHO. Somebody making that mistake could be ugly.
I can run another test later next week.
Here is a much better partition table entry. It's the right size, but wrong type. Ran outta time, but given the larger partition loaded, I take this as a "pass" because the test code would have done the right thing with the right partition type.
Disk /dev/sdc: 2045 MB, 2045247488 bytes
63 heads, 62 sectors/track, 1022 cylinders, total 3994624 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x0002a6f1
Device Boot Start End Blocks Id System
/dev/sdc1 2048 100000 48976+ 6 FAT16
/dev/sdc2 100001 100033 16+ 83 Linux
Command (m for help):
root@ubuntu:/media/4FC5-DDCB# dd if=BOOT.TXT of=/dev/sdc2 bs=512 count=34
31+1 records in
31+1 records out
15987 bytes (16 kB) copied, 0.0143387 s, 1.1 MB/s
root@ubuntu:/media/4FC5-DDCB#
I like to use gpartd to view devices, mount, umount...
sfdisk is a scriptable thing. I didn't use it, running interactive Fdisk instead.
An example:
http://www.thelinuxdaily.com/2010/05/sfdisk-the-scriptable-fdisk/
Went ahead and made two small partitions, one FAT, one for P2 boot:
run fdisk to remove existing partition
run sfdisk -R to get a partition table reread
run fdisk to create two new partitions
run sfdisk -R to reread
run mkfs.msdos /dev/sdc1 to format first partition FAT 16 (this can be anything)
COMMANDS
sfdisk -R /dev/sdc
fdisk /dev/sdc
mkfs.msdos /dev/sdc1
Depending on your Linux, you might not even need the sfdisk command. I didn't on one boot, did on another.
Here is a sample session, but with too big of a partition. I wanted to vet the DD command and the partition.
root@ubuntu:~# fdisk /dev/sdc
WARNING: DOS-compatible mode is deprecated. It's strongly recommended to
switch off the mode (command 'c') and change display units to
sectors (command 'u').
Command (m for help): c
DOS Compatibility flag is not set
Command (m for help): u
Changing display/entry units to sectors
Command (m for help): m
Command action
a toggle a bootable flag
b edit bsd disklabel
c toggle the dos compatibility flag
d delete a partition
l list known partition types
m print this menu
n add a new partition
o create a new empty DOS partition table
p print the partition table
q quit without saving changes
s create a new empty Sun disklabel
t change a partition's system id
u change display/entry units
v verify the partition table
w write table to disk and exit
x extra functionality (experts only)
Command (m for help): p
Disk /dev/sdc: 2045 MB, 2045247488 bytes
63 heads, 62 sectors/track, 1022 cylinders, total 3994624 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x0002a6f1
Device Boot Start End Blocks Id System
/dev/sdc1 2048 100000 48976+ 6 FAT16
/dev/sdc2 100001 100900 450 27 Unknown
Command (m for help): x
Expert command (m for help): p
Disk /dev/sdc: 63 heads, 62 sectors, 1022 cylinders
Nr AF Hd Sec Cyl Hd Sec Cyl Start Size ID
1 00 33 3 0 37 57 25 2048 97953 06
2 00 37 58 25 52 27 25 100001 900 27
3 00 0 0 0 0 0 0 0 0 00
4 00 0 0 0 0 0 0 0 0 00
Expert command (m for help): q
root@ubuntu:~#
WARNING: DOS-compatible mode is deprecated. It's strongly recommended to
switch off the mode (command 'c') and change display units to
sectors (command 'u').
Command (m for help): c
DOS Compatibility flag is not set
Command (m for help): u
Changing display/entry units to sectors
Command (m for help): m
Command action
a toggle a bootable flag
b edit bsd disklabel
c toggle the dos compatibility flag
d delete a partition
l list known partition types
m print this menu
n add a new partition
o create a new empty DOS partition table
p print the partition table
q quit without saving changes
s create a new empty Sun disklabel
t change a partition's system id
u change display/entry units
v verify the partition table
w write table to disk and exit
x extra functionality (experts only)
Command (m for help): p
Disk /dev/sdc: 2045 MB, 2045247488 bytes
63 heads, 62 sectors/track, 1022 cylinders, total 3994624 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x0002a6f1
Device Boot Start End Blocks Id System
/dev/sdc1 2048 100000 48976+ 6 FAT16
/dev/sdc2 100001 100900 450 27 Unknown
Command (m for help): x
Expert command (m for help): p
Disk /dev/sdc: 63 heads, 62 sectors, 1022 cylinders
Nr AF Hd Sec Cyl Hd Sec Cyl Start Size ID
1 00 33 3 0 37 57 25 2048 97953 06
2 00 37 58 25 52 27 25 100001 900 27
3 00 0 0 0 0 0 0 0 0 00
4 00 0 0 0 0 0 0 0 0 00
Expert command (m for help): q
root@ubuntu:~#
WARNING: DOS-compatible mode is deprecated. It's strongly recommended to
switch off the mode (command 'c') and change display units to
sectors (command 'u').
Command (m for help): c
DOS Compatibility flag is not set
Command (m for help): u
Changing display/entry units to sectors
Command (m for help): m
Command action
a toggle a bootable flag
b edit bsd disklabel
c toggle the dos compatibility flag
d delete a partition
l list known partition types
m print this menu
n add a new partition
o create a new empty DOS partition table
p print the partition table
q quit without saving changes
s create a new empty Sun disklabel
t change a partition's system id
u change display/entry units
v verify the partition table
w write table to disk and exit
x extra functionality (experts only)
Command (m for help): p
Disk /dev/sdc: 2045 MB, 2045247488 bytes
63 heads, 62 sectors/track, 1022 cylinders, total 3994624 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x0002a6f1
Device Boot Start End Blocks Id System
/dev/sdc1 2048 100000 48976+ 6 FAT16
/dev/sdc2 100001 100900 450 27 Unknown
Command (m for help): x
Expert command (m for help): p
Disk /dev/sdc: 63 heads, 62 sectors, 1022 cylinders
Nr AF Hd Sec Cyl Hd Sec Cyl Start Size ID
1 00 33 3 0 37 57 25 2048 97953 06
2 00 37 58 25 52 27 25 100001 900 27
3 00 0 0 0 0 0 0 0 0 00
4 00 0 0 0 0 0 0 0 0 00
Expert command (m for help): q
root@ubuntu:~#
Now use DD to put the boot.zip into the second partition!
root@ubuntu:/media/4FC5-DDCB# dd if=/media/4FC5-DDCB/boot.zip of=/dev/sdc2 bs=512 count=61
60+1 records in
60+1 records out
30815 bytes (31 kB) copied, 0.208489 s, 148 kB/s
root@ubuntu:/media/4FC5-DDCB#
Let's get the file back out, just for kicks
ubuntu@ubuntu:~$ sudo su -
root@ubuntu:~# dd if=/dev/sdc2 of=/media/4FC5-DDCB/file_out.zip bs=512 count=61
61+0 records in
61+0 records out
31232 bytes (31 kB) copied, 0.0220688 s, 1.4 MB/s
root@ubuntu:~#
[ and it unzipped just fine ]
Only real requirement here is to just make the P2 boot sector the size of the boot file, or a lot of blocks will be loaded by
the test code. Maybe this can be dealt with?
That leaves the "just look for it" method. I didn't try that one. I'm off and into the woods for a few days after tomorrow. Won't be back for a bit. Wanted to do the test now, rather than wait. Sorry for the messy posts. Messy info is better than no info, right?
I used a live Ubuntu boot on my Propeller development laptop. IMHO, any recent version of this would do just fine.
The long process shows the detail. Truth is, a simple script can automate all of that stuff, leaving somebody with:
Insert SD card
Run script:
propboot [sd card device] [boot file]
eg: propboot /dev/sdc bootcode.cog
The sample link shows such a script using the scriptable fdisk. The wiki on it demonstrates stepping through a partition create, for reference.
IMHO, this works for me. Thanks. If we get SD, it's nice to know standard tools can be used to boot a P2!
(hope the mode issue gets sorted)
Oh, here's a screenie of the SD card in gpartd at one point in the process:
I made really small partitions, just checking things out. Much larger ones could be used. Windows was quite happy with any and all variations I tried in fdisk.
... Is the "search..." triggered by the wrong partition type? If so, then I believe the code will work fine as my earlier pass fetched data from the boot partition created with the right type, it was just wayyy too big. And it did so without searching.
That really should be accounted for. No matter the partition size, only some blocks need to be loaded, IMHO. Somebody making that mistake could be ugly.
I can run another test later next week.
It takes only one instruction more to limit the number of the loaded sectors to 254 (=126kByte). This is a good idea.
Yes, a wrong partition type means "no pointer there" for the code, so it begins a search for a file with the signature.
You can use menu item 3 in the Spin tool to change the partition type: Just comment out al the word[@sectbuf+$xxx] := yy lines in the Spin code at case "3", then only the partition type gets overwritten.
This search finds then the previously written file on the SD card, also if it is deleted. That's one of the problematic things whith the search methode. But you can use menu point "7" to delete all these remaining signatures in the first 20000 sectors. Caution: menu "7" deletes also the partition 2 pointer and type as lon as you not comment out all between 'Read sector 0' and 'Write sector 0' in the case "7" part of the code.
I wonder a bit about the sector list in the first terminal output. All sectors are there but not in the right order - maybe my algorithm to show the sectors is not working correct here.
Yeah, I wondered about that too. My SD image is huge!! Should have zeroed the card before creating everything. It would have compressed nicely. Oh well. I thought about dropping it somewhere to download, but that plan went bad.
You can get the same result by copying the zip to the SD, unzip it, rename a few things, add a file, take one away, etc... Mix it up a little, and it won't take much to get the sectors showing like that. I was hopping between a few machines, actually storing the results on the SD for storage on the net connected computer, in-between format attempts.
You are welcome. Appreciate you thinking SD through. If it happens, it should be good.
I like filesystem stuff. Learned some things about SD cards. Really wanted to try a coupla Linuxes. Just for fun I did put an IRIX boot record on my SD. LOL!! Should have grabbed a hex dump of that. The biggest issue I see is it appears some kernels will need a kick in the pants to see a new partition record. My results were inconsistent. It probably had something to do with what was running or not. This can be checked out much later though, during script testing.
I was successful resizing a FAT partition in various ways too. IMHO, that's just a user choice at this point.
One thing to consider though. If we do use partition two, then the prop boot is going to be wayyy up there on the SD card, unless somebody wants to resize their FAT to be small, and either make three partitions to add an additional FAT, or RAW space, or just not use very much of the SD.
Otherwise, partition 1 will be unallocated, and the FAT partition will live in slot two or three, depending on what people do. It's possible to just manually deal with the partitions to work around that. Didn't check that use case, but I suspect it would be fine, just odd.
If the high block addresses aren't a problem, then this is all pretty sweet. A short script will just add partition 2 in the standard way, placing BOOT.BIN somewhere high, or people can write their own utility and just poke it in the card somewhere too. Windows didn't seem to care what was done with the "diag" type.
Next week, I'll do a complete, correct run as I've identifed all the little hassles now.
Comments
The thing is, a small program could be made, and should be made for "those windows users", and frankly a whole lot of UNIX ones that don't really know what disks, partitions, filesystems and such are, and I don't get that at all.
No matter what, a nice little program is good for the "non-pro", but that shouldn't drive the spec for those that don't need a little program.
I find it hilarious! So, we are out to make a pro device with pro tools, and that's gcc and friends. Great!! I'm all over that, because using those tools is a great practice, empowering, cross platform, free, etc...
Then we break down on a couple of basic things like mkfs & dd? Who are we really building for?
Joe blow hobby guy, or that "professional?" The Pro guy, setup on Linux will know all about that and can execute it cold, and it's resonant with all they know. The hobby guy who wants to just click stuff? Seriously? We are thinking about THAT?
Frankly, my advocacy for a compliant boot capability is all about the "pro", in that anyone who knows their stuff about booting, filesystems, disks, etc... would have zero trouble with a compliant boot process. Easy stuff, the docs could be a mere script and a coupla paragraphs, with the rest being understood.
If we aren't doing that, then who really cares? Just do something on the SD card, document it, and leave the folks who know better asking, "WTF?" scratching their heads and likely bitching about having to use the tool, instead of their open, standard workflow. Isn't that funny? (no, but laugh, because I am)
And the bizarre thing is chasing this "windows user" who apparently is so clueless they can't do anything other than copy a file and insert a card? LOL!! (have to laugh, because it gets rather painful, if I don't.)
Edit:
My point here being that Parallax went to considerable effort to build out a nice, standard, pro grade, open tool chain. Good on 'em for that. Tons of people here said that was absolutely necessary to capture the "pro" market, whatever that really is. Let's say it's there, and that the gcc efforts, right along with the more serious branding, etc... all make great sense.
If it makes sense, then why break from that on this feature? There are well established, time tested, widely accepted, robust, free, ways to deal with media, partitions and filesystems, and not only is it being discussed not to use them in favor of "this tool", but some are actually advocating ways of doing things that makes sure nobody CAN use them! Nuts!
The right way to do this is precisely what is being done with the gcc tools too. If somebody knows their stuff, the gcc package is right there, as complex and flexible powerful as needed. Command line the whole thing, if you want to. That's pro stuff, right? No getting in the way of people who know what they are really doing, right?
What did we do for the hobby person? SimpleIDE, which runs on top of "the right way" hiding all that real stuff so that people have a good shot at getting their stuff done and learning more about it on the way. Fantastic!
Same should apply here. Get the boot compliant, robust, effective. Then build the tool on top of that. The folks that know their stuff will appreciate a device that can boot in a standard way, those that don't can use the tool, and those that want to hack out their own path (which is a perfectly fine thing to do, mind you) can do their thing, authoring their own tools.
Rant mode = 0 (I did say I would bow out, and I think I shall. RAM is worth more than a broken SD feature, IMHO)
As we don't want the PropII to find old "deleted" code.
A PC util or PropTool will have no problem reading fat32 to find the lastest location of the file.
So there will be no simple drag and drop, but always saved/re-scanned with a util or Prop-Tool.
And I think we should use all the 440bytes in MBR reserved for code/pointers to point to 128kb worth of sectors for a quick boot of a full program.
This COULD work, but you would need to have the initial pointer in MBR point to another location in MBR, which had a small program inserted into the 446 bytes available in mbr.
You would have to write a really small program that tells the prop2 how to: do proper sd card i/o, read the partition table, read the file table, find the proper file, and load it.
Can it all fit inside the (safe areas) of the mbr is the question?
If the prop just did a search for ID, no program would be needed to fit into the MBR.
If the prop knew to search for ID as last effort, With a tool (or another prop running a program), one could write a file with the proper id and pointer calulated, and all other ids removed on the sd card.
Heck, someone could even write a prop program that scanned the sd card for ID, and removed any. And then scanned card for proper program signature, once found, the mbr would be updated with ID and pointer.
Really theres many ways to accomplish this with the prop2, if it does a ID/pointer sd card support.
The 8086 processor does exactly this. The cpu inside your pc, right now, has no clue WTF a FAT/NTFS etc is. Your computers mbr has a program that runs on the cpu, which has pointer to bigger boot program.
The cpu DOES NOT look for a specific partiton. It first runs a program inside the mbr.
We installed this pointer and bigger boot program, using previous versions of the 8086 to create the framework, (cdrom) to install the proper program onto the mbr, which in turn has a program and pointer to recognise the file system format and then runs the desired file. a.k.a Windows 7.
Having the prop look in the FAT tables when it searches is incompatible with other sd card formats.
No framework could be relied upon in the ROM.
Strictly from a P2 chip point of view, the only thing that the chip should know is:
How to access the sd card to look for specific bytes (ID and pointer) and if not found, do linear search.
No table, no partition, nothing, just data. This means less possibilities for bugs.
The ROM program would also need to deal with the possibility that the sd card might already be in high speed mode.
https://en.wikipedia.org/wiki/Bootstrapping_(computing)#Software_bootstrapping
So you are going to have an opinion of this before you even have the chip in hand?
This thread IS indeed getting exponentially mucky.
Now write a program, that will tell it how to do what it did before your girlfriend wrote her letter.
It seems hard, but it can be done, many ways, too.
Just because a chip doesn't know how to recognize volume formats, doesn't mean its useless.
http://www.virtualroadside.com/blog/index.php/2007/11/11/inspired-by-xkcd-mbr-love-note/
Your exponentialy more mucky bootstrapping with editors compilers and such is a totally different thing compared to a computer booting itself up.
The ZIP includes the possible ROM boot code, and a tool to try it out.
The tool lets you write a bootfile, write and remove the pointer, look if the bootfile is contiguous and so on. When you finally choose "Try to boot" from the menu, then the utility stops FSRW and starts the cog with the ROM boot code.
The code expects the pointer now in the MBR table at partition 2. On an SD card with MBR there is
normally a partition 1 with a FAT file system. So if we use partition 2 for boot, we don't need to
change anything than the pointer and type for partition 2. This can be done by a little utility, like
in this testcode, or by a standard partition tools on Linux/MAC/Windows.
According my tests the new pointer in the partition table does not confuse Windows, also if the pointer points
only to a file and not a real partition (it's anyway a hidden partition with type $27).
So we have now 3 options to setup a bootable SD card:
1) Copy a bootfile with a signature to an empty SD card
2) Copy a bootfile to an SD card (empty or not) and use a tool to set the pointer to it
3) Use a partition tool to make a second partition with the raw bootfile.
In case of 1) the rom_boot_code searches trough the sectors until it finds the signature at begin of the file (or datablock).
In case 2) and 3) the rom_boot_code uses the pointer in the MBR to find the file, both options are the same for the boot code, the difference is only how the user sets up the SD card. Option 2 works also if the SD card has only a VBR in sector 0 and no MBR.
Perhaps we can use a fuse to disable the search methode in case it is not desired by the user. The purpose of the search is to give a way to setup a Prop 2 system without the use of an IDE, a FTDI chip, or a PropPlug. Just copy the bootfile to an SD card and let the Prop search it. The search is anyway not executed if the rom code finds a pointer in sector 0.
I must say that I have not tested option 3) so far. I find it too complicated to use a partition tool just to write a bootfile to an SD card. Perhaps someone that find this easy and the best way, can try if the rom boot code works with such a setup (make a partition type $27, and copy a textfile as the bootfile into the partition). You should then use only menu items 5 and 6 of the utility, all others will not work.
The first test with the utility should be to write the bootfile with "1", then press 5" to find the file.
After reloading the code, next step will be to write the pointer with "3" and see if the file is found now much faster.
Andy
If you have to use a PC special utility to write the pointer (or a special spin program in P1 or P2) then is the same if this utility beside writing the pointer writes also the whole binary to the SD. In this way the written binary can be the bootloader (the one that the ROM reads to boot further) or the whole 128K hub image. To require only one pointer in a well known offset of the MBR you must be able to write 128K of contiguous data. There is no file system that will guaranty this on a used media and to me is not aceptable to format the SD each time. I WANT a solution that allows for dedicated unformatted partition where the raw bootloader (or the whole hub image) can be stored away from the second partition (FAT formatted) that will be used as a data storage.
PS: I am not saying that this shold be the solution, but if the pointer allows to point to a file in the file system it must in the same way work also if pointed to a reserved partition. Of course the ROM code and the bootloader must not know nothing about any file system but must comply with the MBR specifications.
Woohoo.. more stuff to play with. being unemployed kinda sucks.. (well the not having money part) at least I have time to dig into all this mbr/sd/booting....
by the time I learn it all, the prop2 will be out....
hopefully i can find work by then, and make some money so i can finish: A.C.S.E.R. http://forums.parallax.com/entry.php?871-A.c.s.e.r.
I only want the 'search' in case a situation arises that requires the pointer location to be changed.
Plan for the worst, hope for the best.
Thanks for all your hard work on this code, BTW.
I tried the sd card booter program and noticed it says load the program using the ide. Either its a bit complicated to self-load a program and boot it, or... it just wasn't implemented here.
I made a binary, renamed it BOOT.TXT, and put it on the sd card.
http://uanr.com/sdfloppy/
OR
http://hackaday.com/2009/08/18/cheap-sd-card-cradle/
Just spent some quality time with a Live Ubuntu 10, I think. It's the one I had handy. And just created two partitions, both fairly small, first is FAT formatted, second raw.
BTW: Type 27 shows up as "diag" to some programs... Windows completely ignores it though.
Win32 Disk Imager isn't fast, but it can archive an SD card for multiple tries at this stuff.
Method 1. Let the program write it's partition #2 info. It saw the one I did, and asked to overwrite. Here's the terminal chatter:
You can see that larger partition data in there perfectly.
Now the "use standard tools method", which is to use fdisk, mkfs.msdos, and dd to build the partition and write the boot file. With a little different set of commands, this can be scripted. (Example link in process.txt attached)
I forgot to set the hidden "diag" partition type on the second pass. So it was done with type "linux"... It worked, but doing search.
Is the "search..." triggered by the wrong partition type? If so, then I believe the code will work fine as my earlier pass fetched data from the boot partition created with the right type, it was just wayyy too big. And it did so without searching.
That really should be accounted for. No matter the partition size, only some blocks need to be loaded, IMHO. Somebody making that mistake could be ugly.
I can run another test later next week.
Here is a much better partition table entry. It's the right size, but wrong type. Ran outta time, but given the larger partition loaded, I take this as a "pass" because the test code would have done the right thing with the right partition type.
Weird. I can't just attach text. Next post...
I like to use gpartd to view devices, mount, umount... sfdisk is a scriptable thing. I didn't use it, running interactive Fdisk instead. An example: http://www.thelinuxdaily.com/2010/05/sfdisk-the-scriptable-fdisk/ Went ahead and made two small partitions, one FAT, one for P2 boot: run fdisk to remove existing partition run sfdisk -R to get a partition table reread run fdisk to create two new partitions run sfdisk -R to reread run mkfs.msdos /dev/sdc1 to format first partition FAT 16 (this can be anything) COMMANDS sfdisk -R /dev/sdc fdisk /dev/sdc mkfs.msdos /dev/sdc1 Depending on your Linux, you might not even need the sfdisk command. I didn't on one boot, did on another. Here is a sample session, but with too big of a partition. I wanted to vet the DD command and the partition. root@ubuntu:~# fdisk /dev/sdc WARNING: DOS-compatible mode is deprecated. It's strongly recommended to switch off the mode (command 'c') and change display units to sectors (command 'u'). Command (m for help): c DOS Compatibility flag is not set Command (m for help): u Changing display/entry units to sectors Command (m for help): m Command action a toggle a bootable flag b edit bsd disklabel c toggle the dos compatibility flag d delete a partition l list known partition types m print this menu n add a new partition o create a new empty DOS partition table p print the partition table q quit without saving changes s create a new empty Sun disklabel t change a partition's system id u change display/entry units v verify the partition table w write table to disk and exit x extra functionality (experts only) Command (m for help): p Disk /dev/sdc: 2045 MB, 2045247488 bytes 63 heads, 62 sectors/track, 1022 cylinders, total 3994624 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x0002a6f1 Device Boot Start End Blocks Id System /dev/sdc1 2048 100000 48976+ 6 FAT16 /dev/sdc2 100001 100900 450 27 Unknown Command (m for help): x Expert command (m for help): p Disk /dev/sdc: 63 heads, 62 sectors, 1022 cylinders Nr AF Hd Sec Cyl Hd Sec Cyl Start Size ID 1 00 33 3 0 37 57 25 2048 97953 06 2 00 37 58 25 52 27 25 100001 900 27 3 00 0 0 0 0 0 0 0 0 00 4 00 0 0 0 0 0 0 0 0 00 Expert command (m for help): q root@ubuntu:~# WARNING: DOS-compatible mode is deprecated. It's strongly recommended to switch off the mode (command 'c') and change display units to sectors (command 'u'). Command (m for help): c DOS Compatibility flag is not set Command (m for help): u Changing display/entry units to sectors Command (m for help): m Command action a toggle a bootable flag b edit bsd disklabel c toggle the dos compatibility flag d delete a partition l list known partition types m print this menu n add a new partition o create a new empty DOS partition table p print the partition table q quit without saving changes s create a new empty Sun disklabel t change a partition's system id u change display/entry units v verify the partition table w write table to disk and exit x extra functionality (experts only) Command (m for help): p Disk /dev/sdc: 2045 MB, 2045247488 bytes 63 heads, 62 sectors/track, 1022 cylinders, total 3994624 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x0002a6f1 Device Boot Start End Blocks Id System /dev/sdc1 2048 100000 48976+ 6 FAT16 /dev/sdc2 100001 100900 450 27 Unknown Command (m for help): x Expert command (m for help): p Disk /dev/sdc: 63 heads, 62 sectors, 1022 cylinders Nr AF Hd Sec Cyl Hd Sec Cyl Start Size ID 1 00 33 3 0 37 57 25 2048 97953 06 2 00 37 58 25 52 27 25 100001 900 27 3 00 0 0 0 0 0 0 0 0 00 4 00 0 0 0 0 0 0 0 0 00 Expert command (m for help): q root@ubuntu:~# WARNING: DOS-compatible mode is deprecated. It's strongly recommended to switch off the mode (command 'c') and change display units to sectors (command 'u'). Command (m for help): c DOS Compatibility flag is not set Command (m for help): u Changing display/entry units to sectors Command (m for help): m Command action a toggle a bootable flag b edit bsd disklabel c toggle the dos compatibility flag d delete a partition l list known partition types m print this menu n add a new partition o create a new empty DOS partition table p print the partition table q quit without saving changes s create a new empty Sun disklabel t change a partition's system id u change display/entry units v verify the partition table w write table to disk and exit x extra functionality (experts only) Command (m for help): p Disk /dev/sdc: 2045 MB, 2045247488 bytes 63 heads, 62 sectors/track, 1022 cylinders, total 3994624 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x0002a6f1 Device Boot Start End Blocks Id System /dev/sdc1 2048 100000 48976+ 6 FAT16 /dev/sdc2 100001 100900 450 27 Unknown Command (m for help): x Expert command (m for help): p Disk /dev/sdc: 63 heads, 62 sectors, 1022 cylinders Nr AF Hd Sec Cyl Hd Sec Cyl Start Size ID 1 00 33 3 0 37 57 25 2048 97953 06 2 00 37 58 25 52 27 25 100001 900 27 3 00 0 0 0 0 0 0 0 0 00 4 00 0 0 0 0 0 0 0 0 00 Expert command (m for help): q root@ubuntu:~# Now use DD to put the boot.zip into the second partition! root@ubuntu:/media/4FC5-DDCB# dd if=/media/4FC5-DDCB/boot.zip of=/dev/sdc2 bs=512 count=61 60+1 records in 60+1 records out 30815 bytes (31 kB) copied, 0.208489 s, 148 kB/s root@ubuntu:/media/4FC5-DDCB# Let's get the file back out, just for kicks ubuntu@ubuntu:~$ sudo su - root@ubuntu:~# dd if=/dev/sdc2 of=/media/4FC5-DDCB/file_out.zip bs=512 count=61 61+0 records in 61+0 records out 31232 bytes (31 kB) copied, 0.0220688 s, 1.4 MB/s root@ubuntu:~# [ and it unzipped just fine ] Only real requirement here is to just make the P2 boot sector the size of the boot file, or a lot of blocks will be loaded by the test code. Maybe this can be dealt with?I used a live Ubuntu boot on my Propeller development laptop. IMHO, any recent version of this would do just fine.
The long process shows the detail. Truth is, a simple script can automate all of that stuff, leaving somebody with:
Insert SD card
Run script:
propboot [sd card device] [boot file]
eg: propboot /dev/sdc bootcode.cog
The sample link shows such a script using the scriptable fdisk. The wiki on it demonstrates stepping through a partition create, for reference.
IMHO, this works for me. Thanks. If we get SD, it's nice to know standard tools can be used to boot a P2!
(hope the mode issue gets sorted)
Oh, here's a screenie of the SD card in gpartd at one point in the process:
I made really small partitions, just checking things out. Much larger ones could be used. Windows was quite happy with any and all variations I tried in fdisk.
Thank you very much for these tests.
It takes only one instruction more to limit the number of the loaded sectors to 254 (=126kByte). This is a good idea.
Yes, a wrong partition type means "no pointer there" for the code, so it begins a search for a file with the signature.
You can use menu item 3 in the Spin tool to change the partition type: Just comment out al the word[@sectbuf+$xxx] := yy lines in the Spin code at case "3", then only the partition type gets overwritten.
This search finds then the previously written file on the SD card, also if it is deleted. That's one of the problematic things whith the search methode. But you can use menu point "7" to delete all these remaining signatures in the first 20000 sectors. Caution: menu "7" deletes also the partition 2 pointer and type as lon as you not comment out all between 'Read sector 0' and 'Write sector 0' in the case "7" part of the code.
I wonder a bit about the sector list in the first terminal output. All sectors are there but not in the right order - maybe my algorithm to show the sectors is not working correct here.
Andy
You can get the same result by copying the zip to the SD, unzip it, rename a few things, add a file, take one away, etc... Mix it up a little, and it won't take much to get the sectors showing like that. I was hopping between a few machines, actually storing the results on the SD for storage on the net connected computer, in-between format attempts.
You are welcome. Appreciate you thinking SD through. If it happens, it should be good.
I like filesystem stuff. Learned some things about SD cards. Really wanted to try a coupla Linuxes. Just for fun I did put an IRIX boot record on my SD. LOL!! Should have grabbed a hex dump of that. The biggest issue I see is it appears some kernels will need a kick in the pants to see a new partition record. My results were inconsistent. It probably had something to do with what was running or not. This can be checked out much later though, during script testing.
I was successful resizing a FAT partition in various ways too. IMHO, that's just a user choice at this point.
One thing to consider though. If we do use partition two, then the prop boot is going to be wayyy up there on the SD card, unless somebody wants to resize their FAT to be small, and either make three partitions to add an additional FAT, or RAW space, or just not use very much of the SD.
Otherwise, partition 1 will be unallocated, and the FAT partition will live in slot two or three, depending on what people do. It's possible to just manually deal with the partitions to work around that. Didn't check that use case, but I suspect it would be fine, just odd.
If the high block addresses aren't a problem, then this is all pretty sweet. A short script will just add partition 2 in the standard way, placing BOOT.BIN somewhere high, or people can write their own utility and just poke it in the card somewhere too. Windows didn't seem to care what was done with the "diag" type.
Next week, I'll do a complete, correct run as I've identifed all the little hassles now.
Anyone want to summarise where they believe we are up to and what has been agreed?
testing...
Parameters used...
00 00 01 FF 08 AA 01 FF 37 00 01 FF 29 00 01 FF
37 00 01 FF 29 00 01 FF 37 00 01 FF 29 00 01 FF
37 00 01 FF 29 00 01 FF 37 00 01 FF 29 00 01 FF
37 00 01 FF 29 00 01 FF 37 00 01 FF 29 00 01 FF
37 00 01 FF 29 00 01 FF 37 00 01 FF 29 00 01 FF
37 00 01 FF 29 00 00 FF 3A 00 00 FF 11 00 00 FF
FE FF 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
MBR sector 0...
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 ................
0A 00 06 3B FB BB 87 00 00 00 79 CF 3A 00 00 00 ...;......y.:...
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 AA ..............U.
$1AE(16): 00000000000000000000000000000000
Valid MBR
PTN 0: Typ=$06
PTN 1: Typ=$00
PTN 2: Typ=$00
PTN 3: Typ=$00
testing...
Parameters used...
00 00 01 FF 08 AA 01 FF 37 00 01 FF 29 00 01 FF
37 00 01 FF 29 00 01 FF 37 00 01 FF 29 00 01 FF
37 00 01 FF 29 00 01 FF 37 00 01 FF 29 00 01 FF
37 00 01 FF 29 00 01 FF 37 00 01 FF 29 00 01 FF
37 00 01 FF 29 00 01 FF 37 00 01 FF 29 00 01 FF
37 00 01 FF 29 00 00 FF 3A 00 00 FF 11 00 00 FF
FE FF 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
MBR sector 0...
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 ................
0A 00 06 3B FB BB 87 00 00 00 79 CF 3A 00 00 00 ...;......y.:...
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 AA ..............U.
$1AE(16): 00000000000000000000000000000000
Valid MBR
PTN 0: Typ=$06
PTN 1: Typ=$00
PTN 2: Typ=$00
PTN 3: Typ=$00