On Prop II thread I write to someone THAT them that advocate FAT support in PROP II boot initialization code --- DON't know what them talk on.
On pictures attached You can see all types of formats used by SD and all others storage media.
And on image in this post
---- http://forums.parallax.com/showthread.php?141952-SD-Card-Test-(Please-test-may-be-used-for-boot-code-for-the-Prop2)&p=1120744&viewfull=1#post1120744
---- You can see that ---- If Chip made code that simple read MBR sector and give it possibility to START code stored from "0 to 1AF" in MBR
--- we can made any type of BOOTING of SD on Propeller II.
AND still that SD will be Writable / Readable by any system. BUT not Boot-able on them.
On this pictures You can even see that only FAT32 can have more that ONE partition on SD without special formating program.
SO this test was just to see if most sd cards COULD read their MBRS? AND to see if any of the regular formatted sd cards had anything in the mbr?
It looks like everyones sd cards read fine with the test program, and most mbr's are empty. I like not relying on a specific format or file system to boot the p2. This will allow any p2 developer to even develop their OWN operating system and file system if they choose. And this also allows other file systems like linux ext3 to be utilized if the user so chooses, because the p2 is only looking for mbr data in specific location for boot code. What the developer does from that point on is wide open. Just the way everyone here likes it. FREEDOM!
I think that the only reason any one would suggest it be tied to a specific file system format, is because they don't understand the nature of the mbr and how it dosen't care what file system you use, the mbr chugs along oblivious to any file system format, making it perfectly suited for modification with pointer code. (exactly how computers work today)
The p2 is pretty much a computer in a single chip, so it makes sense to adopt mbr booting.
Perhaps I missing some gotchas? Consider how long computers have been utilizing mbr to boot a plethora of OS's, even today with our modern 64-bit cpus, OS's and super immersive gaming, but yet it all starts with a simple MBR method that was invented decades ago, and hasn't changed at all since, even with our 4ghz, 16gig ram, solid state hard drives, 64-bit cpus, etc... all the wonderful advanced hardware and software, but yet we still rely on the good ol' simple MBR to get it all going.
This method has worked so well for so long, I am kinda surprised to see opposition to it, and even more surprised to see people saying that the p2 ROM should contain FAT support!!!!!! HELL NO. o.O
A few of my sd cards had info in the mbr, but thats because i had used those sd cards for bootable utilities, firmware updaters, and mini-linux, and I had to use a special tool to format and write data to those cards.
It looks like, ALL sd cards so far can read the mbr just fine, and like you said, they all have no data in the mbr. (with original sd format)
The idea to use the sd mbr as pointer to locate boot code for p2, looks like it will work great! Now let hope it gets implemented.
(its pretty easy to plop a binary file onto the sd card, and then use a tool to find its start address, then inject that start address into the mbr at pre-defined location.)
Is this something a new user to the p2 will be able to easily do? No, not at first.
But then after the guru's here hack on it, they will develop a tool that allows one to automate most of the process, by just supplying the drive letter of the sd card, and the prop2 program to be booted.
A tool could be developed for different sd formats also.
Code is saved to SD card like any other file, don't have to be continuous.
A util will read sectors used for this file and store pointers in the 440bytes reserved as bootcode in MBR.
If using 16bit for pointers, should be able to point to 220 sectors so no problem booting large code.
This is not a hack, bootcode is whaterever you want it to be, x86 code or bytecode and that would be pointers in our case.
PropTool will save boot-code AND do the rewrites of MBR in one step
I wrote to my sd cards MBR using winimage.
I did this by saving the mbr in winimage as mbr.bin file, I then opened it up in NOTEPAD and started typing, I then saved it as is. I then imported it into winimage, writing to the mbr of the sd card.
Heres the result with the fixed spin program.
Clusos program as it is now in the first post (he hasn't fixed it yet) will not even push this information to the terminal, it will just throw out garbage due to the pasm stomping.
It seems that due to variations in the sd card logic speeds, some see the problem, and others do not.
But rest assured, the sd PASM, and the fullduplexserial PASM are stomping on eachother in the original program.
Sorry, apart from making the buffer a lot bigger in the first post, I have not had time to fix.
sorry my previous post has the code produced. my xoom is almost impossible to use to quote or edit - seems to be a real problem with android, not xoom. i am on ics.
SD Booting...
i didnt want to use the partition table as that may interfere with something. i now think the 16 bytes immediately before the partition table is fair game. anyone wanting to use a partition for the boot can do this by placing the pointer where i am asking it to be.
i have already posted a p1 program that will write the mbr pointer. it is such a simple program.
seems we have validated the pasm init cod to read from the sd cards. but as yet i havent seen an sdx card. anyone have one they can test please?
I have no idea why, but I removed all the code from the SD card test that didn't have to do with the accessing and reading of the MBR, then I compilied it and saved the binary. I then injected it into my sd card's MBR.
It truncated some of the binary code because the binary file was >600 bytes, the MBR only holds 446 bytes, after the first 446bytes, it reserves the rest of the space for other data. (partition, etc)
It could probably fit, if buffers were able to be reduced, and PASM shortcuts were able to be utilized(if any)
The MBR can be a pretty useful data space for custom prop2 jobs that boot from the sd card.
It wouldn't be too hard to put some pretty powerful binary code directly into the MBR, to allow many different scenarios of prop2 booting, putting some simple pointer code into the MBR is trivial, compared to what I just did here.
I see a bright future with this, if it is implemented.
This dump is either a bad card, or using cluso's old code (note the "testing" message at the top) my code removed the "testing" message.
The dump has the signature missing from the end of the mbr.
Re-run this test on your card, using the program I attached here: http://forums.parallax.com/attachment.php?attachmentid=95080&d=1345664945
Just posted a code update to the first post.
Anyone who was getting a corrupted display on PST should re-run this code. Is anyone experiencing a lockup? i.e. no display after the "testing..." message. This would indicate the SD initialisation may not be working and this is my real interest - to ensure the pasm section is working correctly!
ClockLoop: You dump from 2 posts ago is most likely that the card has no formatting. Therefore the MBR has not been initialised, hence the missing $55AA at the end. Therefore there is no partition data. IIRC it is referred to as a VBR instead. It is still perfectly valid for us to use this card.
ClockLoop: You dump from 2 posts ago is most likely that the card has no formatting. Therefore the MBR has not been initialised, hence the missing $55AA at the end. Therefore there is no partition data. IIRC it is referred to as a VBR instead. It is still perfectly valid for us to use this card.
Someone made the comment that those results are likely due to the card not being readable.
ClockLoop: You dump from 2 posts ago is most likely that the card has no formatting. Therefore the MBR has not been initialised, hence the missing $55AA at the end. Therefore there is no partition data. IIRC it is referred to as a VBR instead. It is still perfectly valid for us to use this card.
Oh, it wasn't my dump, it was donnpangy's. So it really might be a correct dump?
So, actually, If I were to write all 0's to my sd card from beginning to end, it would look like his?
Hmm, I suppose I could do this with winhex...then? (if i had a registered version, damn shareware, time to search alternatives for poor bastards like me)
This also means that, technically, one could use all 512 bytes of MBR space, if you don't care about any formatting.
(say in the case of using the sd card for prop1/2 ONLY)
Oh, it wasn't my dump, it was donnpangy's. So it really might be a correct dump?
So, actually, If I were to write all 0's to my sd card from beginning to end, it would look like his?
Hmm, I suppose I could do this with winhex...then?
This also means that, technically, one could use all 512 bytes of MBR space, if you don't care about any formatting.
(say in the case of using the sd card for prop1/2 ONLY)
What I am really interessted in is how many SD cards do you find which will not initialize correct. Cluso modification do not test the timeout abort, so you see this only in that you get a MBR with all zeroes.
It was not me that have write this table --- It is copy of one official document I have on that ----
So don't teach me --- Teach them that have write IT.
It seems the only way to tell if a card fails is it it freezes at the "testing" stage and has no further output, OR if you look at the parameters section, and its almost all 0's? (see second card dump below)
Oh, it wasn't my dump, it was donnpangy's. So it really might be a correct dump?
So, actually, If I were to write all 0's to my sd card from beginning to end, it would look like his?
Hmm, I suppose I could do this with winhex...then? (if i had a registered version, damn shareware, time to search alternatives for poor bastards like me)
This also means that, technically, one could use all 512 bytes of MBR space, if you don't care about any formatting.
(say in the case of using the sd card for prop1/2 ONLY)
Why not just use the prop? Just change the code I used to write the MBR pointer initially.
I would need to recheck, but IIRC my code will hang if the card is not initialised correctly. So you will not get a display. BTW it was Andy's code that I modified.
It seems the only way to tell if a card fails is it it freezes at the "testing" stage and has no further output, OR if you look at the parameters section, and its almost all 0's? (see second card dump below)
After looking at the mounting code from FSRW, Kye and PropGCC, I have rewritten the whole boot code. Now it is much more readable, uses the same formating and register names as Chips current Prop2 boot code I also added a lot of comments.
But the best is that it works with all of my SD and SDHC cards and it needs only 127 longs!
The attached ZIP contains a Spin tool, which lets you:
- write a boot file
- set and remove the shortcut to it in sector 0
- print the allocated sectors of the bootfile, to see if they are contiguous
- simulate booting of the file
It gives you a lot of error codes and texts.
The shortcut in sector 0 has now 3 longs: Signature, Startsector, NumberOfSectors to boot.
The last parameter lets you define how many contiguous sectors the code will use after the startsector. So if there is really a problem with non contiguous sectors we can also boot only a 4 kB file which fits in one cluster, without changing the ROM boot code. But I was not able to write small files (<= 128kB) from Windows XP to the SD card which had not contiguous sectors. To try this just make a text file on your PC up to 128 kB and give it the name: BOOT.TXT then copy it to the SD card. You also can see that if you use the same filename, the file lands always at the same sectors, so it is no problem to overwrite the bootfile with new code.
The main problem I see with this solution, is that it needs a tool to write the shortcut.
In Spin this is very easy to do, but I don't know how you can access such low level functions in Windows, Linux, MacOS. One solution is to provide a Disk Image, with a bootfile, which provides the tool functions.
Please try it out and report if it works for you. All you have to do is to load the sd_boot_test_P2.spin file into the IDE and edit the SD pins and clockfreq. Then start it and then start PST and press a key. As long as you not choose one of the write functions from the menu, nothing is written to your card. The main test is to press "5" which tries to boot. As long as you don't get error -9 or -13, the card should work with the booter code (just write the boot file and set the shortcut for that).
Thats a good description Sapieha, thanks.
There is a lot of confusion about MBR vs VBR. And they get mixed in some docs.
I am really referring to sector 0 which may contain either a VBR or MBR (seems they can be interchanged sometimes). Anyway, provided I use the available boot area common to both (which is what I am proposing) there is no downside.
Because of the use of an optional disk signature contained on the MBR, I propose to use the 16 bytes from $1A0 so that this is not interferred with. I will use only a 4 byte identifier followed by a 4 byte sector pointer where the prop bootloader will begin. From what Chip has said, the Flash uses a 4KB (IIRC) initial boot with security embedded, so I propose to do the same. If a seperate partition is used, as some have proposed, then the pointer will just point to the start sector of the partition. If we use a file, then it will point to the start of the file. If we just use a raw mode then it will point to whereever the data is.
Do you agree that $1A0 would be a better place to reserve 16 bytes? (rather than $190 = 400)
Any reason for that?
We can have 3 different Sector 0 layouts for a FAT formated SD card. In the following picture the red areas are reserved for parameters, the green area has only x86 boot code which we can overwrite. The blue line is where we place the shortcut.
So I don't see why a bit higher or lower does matter. If we really need to store a table of sectors then we should go lower, so that we have place for about 33 longs (signature + 32 sector numbers , 1 per 4kB cluster). But I think we need only 3 longs anyway. Windows uses already 2 longs under the MBR table to store a disk ID, so I think we should left some space between the shortcut and the begin of the MBR table.
But the exact loaction is not so important for me at the moment, important is:
1) does it work
2) will it even be implemented in the ROM
3) should it be a file + shortcut, or a separate partition
A partition will have the shortcut already in the MBR table, so you don't need to write it, but formating an SD card with partitions and store a file into a FATless partition is complicated. And this must be done everytime you change the bootcode.
A bootfile in the root directory and a shortcut in sector 0 is simpler for the user. If the shortcut is once there you just can replace the bootfile with new code. But you should not delete the bootfile without removing te shortcut, for example.
We can have 3 different Sector 0 layouts for a FAT formated SD card. In the following picture the red areas are reserved for parameters, the green area has only x86 boot code which we can overwrite. The blue line is where we place the shortcut.
So I don't see why a bit higher or lower does matter. If we really need to store a table of sectors then we should go lower, so that we have place for about 33 longs (signature + 32 sector numbers , 1 per 4kB cluster). But I think we need only 3 longs anyway. Windows uses already 2 longs under the MBR table to store a disk ID, so I think we should left some space between the shortcut and the begin of the MBR table.
But the exact loaction is not so important for me at the moment, important is:
1) does it work
2) will it even be implemented in the ROM 3) should it be a file + shortcut, or a separate partition
A partition will have the shortcut already in the MBR table, so you don't need to write it, but formating an SD card with partitions and store a file into a FATless partition is complicated. And this must be done everytime you change the bootcode.
A bootfile in the root directory and a shortcut in sector 0 is simpler for the user. If the shortcut is once there you just can replace the bootfile with new code. But you should not delete the bootfile without removing te shortcut, for example.
Comments
On Prop II thread I write to someone THAT them that advocate FAT support in PROP II boot initialization code --- DON't know what them talk on.
On pictures attached You can see all types of formats used by SD and all others storage media.
And on image in this post
---- http://forums.parallax.com/showthread.php?141952-SD-Card-Test-(Please-test-may-be-used-for-boot-code-for-the-Prop2)&p=1120744&viewfull=1#post1120744
---- You can see that ---- If Chip made code that simple read MBR sector and give it possibility to START code stored from "0 to 1AF" in MBR
--- we can made any type of BOOTING of SD on Propeller II.
AND still that SD will be Writable / Readable by any system. BUT not Boot-able on them.
On this pictures You can even see that only FAT32 can have more that ONE partition on SD without special formating program.
A util will read sectors used for this file and store pointers in the 440bytes reserved as bootcode in MBR.
If using 16bit for pointers, should be able to point to 220 sectors so no problem booting large code.
This is not a hack, bootcode is whaterever you want it to be, x86 code or bytecode and that would be pointers in our case.
PropTool will save boot-code AND do the rewrites of MBR in one step
testing...
Parameters used...
00 00 00 FF 00 00 00 FF 00 00 00 FF 00 00 00 FF
00 00 00 FF 00 00 00 FF 00 00 00 FF 00 00 00 FF
00 00 00 FF 08 AA 00 FF 37 AA 00 FF 29 AA 00 FF
11 00 00 FF 00 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 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 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 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
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 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 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 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 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 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 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
MBR sector 0...
49 20 6F 70 65 6E 65 64 20 75 70 20 61 20 74 65 I opened up a te
78 74 20 66 69 6C 65 20 69 6E 20 6E 6F 74 65 70 xt file in notep
61 64 20 61 6E 64 20 73 74 61 72 74 65 64 20 74 ad and started t
79 70 69 6E 67 20 74 65 78 74 2C 20 61 6E 64 20 yping text, and
74 68 65 6E 20 73 61 76 65 64 20 69 74 20 61 73 then saved it as
20 61 20 6D 62 72 2E 62 69 6E 20 66 69 6C 65 20 a mbr.bin file
61 6E 64 20 74 68 65 6E 20 69 6D 70 6F 72 74 65 and then importe
64 20 69 74 20 69 6E 74 6F 20 74 68 65 20 6D 61 d it into the ma
73 74 65 72 20 62 6F 6F 74 20 72 65 63 6F 72 64 ster boot record
20 63 6F 64 65 20 70 72 6F 70 65 72 74 69 65 73 code properties
20 77 69 6E 64 6F 77 20 69 6E 20 77 69 6E 69 6D window in winim
61 67 65 2E 20 20 49 20 72 65 61 6C 6C 79 20 68 age. I really h
6F 70 65 20 77 65 20 63 61 6E 20 75 73 65 20 73 ope we can use s
64 20 63 61 72 64 73 20 74 6F 20 62 6F 6F 74 20 d cards to boot
74 68 65 20 70 72 6F 70 2E 20 20 20 20 20 20 20 the prop.
20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
20 20 20 20 20 20 20 20 00 00 00 00 00 00 80 03 ......€.
3D 00 06 1F FF D7 F9 00 00 00 07 44 1E 00 00 00 =..ÿ×ù....D....
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 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 ............ÿ
[/code][/quote]
SD Booting...
i didnt want to use the partition table as that may interfere with something. i now think the 16 bytes immediately before the partition table is fair game. anyone wanting to use a partition for the boot can do this by placing the pointer where i am asking it to be.
i have already posted a p1 program that will write the mbr pointer. it is such a simple program.
seems we have validated the pasm init cod to read from the sd cards. but as yet i havent seen an sdx card. anyone have one they can test please?
Being smart about the use of the mbr is a great idea. Why stomp if you don't have to. (and even prevent stomps) I LIKE YOU THINKING.
It truncated some of the binary code because the binary file was >600 bytes, the MBR only holds 446 bytes, after the first 446bytes, it reserves the rest of the space for other data. (partition, etc)
It could probably fit, if buffers were able to be reduced, and PASM shortcuts were able to be utilized(if any)
The MBR can be a pretty useful data space for custom prop2 jobs that boot from the sd card.
It wouldn't be too hard to put some pretty powerful binary code directly into the MBR, to allow many different scenarios of prop2 booting, putting some simple pointer code into the MBR is trivial, compared to what I just did here.
I see a bright future with this, if it is implemented.
This dump is either a bad card, or using cluso's old code (note the "testing" message at the top) my code removed the "testing" message.
The dump has the signature missing from the end of the mbr.
Re-run this test on your card, using the program I attached here:
http://forums.parallax.com/attachment.php?attachmentid=95080&d=1345664945
Anyone who was getting a corrupted display on PST should re-run this code.
Is anyone experiencing a lockup? i.e. no display after the "testing..." message. This would indicate the SD initialisation may not be working and this is my real interest - to ensure the pasm section is working correctly!
ClockLoop: You dump from 2 posts ago is most likely that the card has no formatting. Therefore the MBR has not been initialised, hence the missing $55AA at the end. Therefore there is no partition data. IIRC it is referred to as a VBR instead. It is still perfectly valid for us to use this card.
If You write any Driver for SD ..
Look that it are compatible with this document.
Someone made the comment that those results are likely due to the card not being readable.
Oh, it wasn't my dump, it was donnpangy's. So it really might be a correct dump?
So, actually, If I were to write all 0's to my sd card from beginning to end, it would look like his?
Hmm, I suppose I could do this with winhex...then? (if i had a registered version, damn shareware, time to search alternatives for poor bastards like me)
This also means that, technically, one could use all 512 bytes of MBR space, if you don't care about any formatting.
(say in the case of using the sd card for prop1/2 ONLY)
YES.
But if You have Partition table in correct place and end signature in it --- It will be readable by any system.
Only BOOT from it reserved to Propeller II.
Pic show FAT16 MBR specification.
First 3 bytes are JUMP instruction of Intel type CPU --- Can be extended to 4 bytes for Propeller --- As name field are only optional.
As You can see in picture You have 448 bytes for BOOT strap code on FAT 16.
EDIT: Or is that out of date now?
If you keep teaching me, I might "HACK THE PLANET"
I found a freeware hex editor similar to hexedit. I used it to write all zero's to my MBR.
http://mh-nexus.de/en/hxd/
I then ran the sd card with the sd card test program.
Like cluso said, its empty now.
The FAT boot code and FAT parameters go in the VBR, not the MBR. The 448 spare bytes are in the MBR. Two different things.
We have long since moved past this issue, it was covered about a week ago. Cluso proposed the pointers as a tidy solution.
It was not me that have write this table --- It is copy of one official document I have on that ----
So don't teach me --- Teach them that have write IT.
It seems the only way to tell if a card fails is it it freezes at the "testing" stage and has no further output, OR if you look at the parameters section, and its almost all 0's? (see second card dump below)
Heres a working card with a zeroed MBR.
And this is what happens when you run the program with no sd card connected at all. (resistors left in circuit)
The table is fine. I was just explaining it's meaning and how the Prop would handle it.
Why not just use the prop? Just change the code I used to write the MBR pointer initially.
I would need to recheck, but IIRC my code will hang if the card is not initialised correctly. So you will not get a display. BTW it was Andy's code that I modified.
That is a slightly different problem because I am detecting the error of no reply at all.
Not only for BOOT system.
http://www.techsec.com/pdf/Monday/ICFP%20FAT%20Prep.pdf
But the best is that it works with all of my SD and SDHC cards and it needs only 127 longs!
The attached ZIP contains a Spin tool, which lets you:
- write a boot file
- set and remove the shortcut to it in sector 0
- print the allocated sectors of the bootfile, to see if they are contiguous
- simulate booting of the file
It gives you a lot of error codes and texts.
The shortcut in sector 0 has now 3 longs: Signature, Startsector, NumberOfSectors to boot.
The last parameter lets you define how many contiguous sectors the code will use after the startsector. So if there is really a problem with non contiguous sectors we can also boot only a 4 kB file which fits in one cluster, without changing the ROM boot code. But I was not able to write small files (<= 128kB) from Windows XP to the SD card which had not contiguous sectors. To try this just make a text file on your PC up to 128 kB and give it the name: BOOT.TXT then copy it to the SD card. You also can see that if you use the same filename, the file lands always at the same sectors, so it is no problem to overwrite the bootfile with new code.
The main problem I see with this solution, is that it needs a tool to write the shortcut.
In Spin this is very easy to do, but I don't know how you can access such low level functions in Windows, Linux, MacOS. One solution is to provide a Disk Image, with a bootfile, which provides the tool functions.
Please try it out and report if it works for you. All you have to do is to load the sd_boot_test_P2.spin file into the IDE and edit the SD pins and clockfreq. Then start it and then start PST and press a key. As long as you not choose one of the write functions from the menu, nothing is written to your card. The main test is to press "5" which tries to boot. As long as you don't get error -9 or -13, the card should work with the booter code (just write the boot file and set the shortcut for that).
Andy
There is a lot of confusion about MBR vs VBR. And they get mixed in some docs.
I am really referring to sector 0 which may contain either a VBR or MBR (seems they can be interchanged sometimes). Anyway, provided I use the available boot area common to both (which is what I am proposing) there is no downside.
Because of the use of an optional disk signature contained on the MBR, I propose to use the 16 bytes from $1A0 so that this is not interferred with. I will use only a 4 byte identifier followed by a 4 byte sector pointer where the prop bootloader will begin. From what Chip has said, the Flash uses a 4KB (IIRC) initial boot with security embedded, so I propose to do the same. If a seperate partition is used, as some have proposed, then the pointer will just point to the start sector of the partition. If we use a file, then it will point to the start of the file. If we just use a raw mode then it will point to whereever the data is.
Do you agree that $1A0 would be a better place to reserve 16 bytes? (rather than $190 = 400)
Any reason for that?
We can have 3 different Sector 0 layouts for a FAT formated SD card. In the following picture the red areas are reserved for parameters, the green area has only x86 boot code which we can overwrite. The blue line is where we place the shortcut.
So I don't see why a bit higher or lower does matter. If we really need to store a table of sectors then we should go lower, so that we have place for about 33 longs (signature + 32 sector numbers , 1 per 4kB cluster). But I think we need only 3 longs anyway. Windows uses already 2 longs under the MBR table to store a disk ID, so I think we should left some space between the shortcut and the begin of the MBR table.
But the exact loaction is not so important for me at the moment, important is:
1) does it work
2) will it even be implemented in the ROM
3) should it be a file + shortcut, or a separate partition
A partition will have the shortcut already in the MBR table, so you don't need to write it, but formating an SD card with partitions and store a file into a FATless partition is complicated. And this must be done everytime you change the bootcode.
A bootfile in the root directory and a shortcut in sector 0 is simpler for the user. If the shortcut is once there you just can replace the bootfile with new code. But you should not delete the bootfile without removing te shortcut, for example.
Andy
Forget separate Partition !!!. ---> Some of systems Can't partition SD cards smaller that 2GB (FAT 12 and FAT 16).