sdTransferBlocks getting random data from SD card
melaquin opened this issue · comments
When the SD card is initializing and calls LoadDrivePartition, it seems to be getting completely random data from the SD card. Using a hex editor, I did find a portion of the data that was being written into the buffer in a part of the card that did not belong to any of the files on it, so I completely reformatted the card and put the firmware and kernel back on it. The buffer was still being filled with the exact same bytes as before, but this time the hex editor couldn't find those bytes on the card. The weird thing is that the last 2 bytes are still 55 aa, but the first 510 bytes are incorrect. I also tried reading sector 1, and that returns all 0's even though the card does have data in sector 1. The buffer is created on the stack and always has uninitialized memory (55 55 55 ..) before the transfer occurs.
Here's what the output looks like when reading sector 0:
And here's the actual contents of sector 0:
When reading sector 1:
actual sector 1:
(EDIT) Here's where I found the data being read into the buffer before formatting the card:
I also modified the print statement to print *(buffer - 512 + i) and *(buffer + 512 + i) to see if buffer was pointing somewhere else and not to where it was originally allocated, and the output didn't have the sector data I was looking for. I had the hex editor search all the files on the card and none of them contained those bytes, so I figured it was from a past OS and decided to completely format the drive and try again. Sector 399,032 is now all 0's. Also, how is it possible that the card read data that was not 512-byte aligned?
I didn't make any changes to SDCard.c bedsides the header inclusions and macros to make it call my kernel's functions, so I don't get why it's not working or where it's getting that data from. Do I need to do anything in particular to make it read correctly?
You formatted the disk with a DOS/WINDOWS boot sector ... Why????? :-)
You are on an ARM processor no way you can boot from Intel code.
So basically the code never allowed for a DOS/WINDOWS system MBR to be present. You either need to change the code (you can pick it from the first byte being FA) or reformat the disk normally without boot sector.
If you do want to add the functionality here is the C structs for reading it
https://github.com/jhermsmeier/node-mbr
It shows you the binary dump you should recognize it
000000 FA B8 00 10 8E D0 BC 00 B0 B8 00 00 8E D8 8E C0 ú¸...м.°¸...Ø.À
000010 FB BE 00 7C BF 00 06 B9 00 02 F3 A4 EA 21 06 00 û¾.|¿..¹..ó¤ê!..
000020 00 BE BE 07 38 04 75 0B 83 C6 10 81 FE FE 07 75 .¾¾.8.u..Æ..þþ.u
000030 F3 EB 16 B4 02 B0 01 BB 00 7C B2 80 8A 74 01 8B óë.´.°.».|²..t..
000040 4C 02 CD 13 EA 00 7C 00 00 EB FE 00 00 00 00 00 L.Í.ê.|..ëþ.....
000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
--
0001A0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0001B0 00 00 00 00 00 00 00 00 B9 77 74 8B 00 00 80 00 ........¹wt.....
0001C0 01 40 0C 03 60 7F 00 20 00 00 00 A0 00 00 00 00 .@..`.. ... ....
0001D0 41 80 83 03 E0 FF 00 C0 00 00 00 80 05 00 00 03 A...àÿ.À........
0001E0 E0 FF 83 03 E0 FF 00 40 06 00 00 80 05 00 00 03 àÿ..àÿ.@........
0001F0 E0 FF 0F 03 E0 FF 00 C0 0B 00 00 60 20 00 55 AA àÿ..àÿ.À...` .Uª
I flashed Raspbian onto the card with Etcher before I started writing an OS for it, so I thought that's what formatted the mbr like that. I reformatted it again with diskpart.exe using this website, but I chose to format it as FAT32 instead of NTFS. and now it started with this:
0x0000 33 c0 8e d0 bc 00 7c fb-50 07 50 1f fc be 1b 7c
0x0010 bf 1b 06 50 57 b9 e5 01-f3 a4 cb bd be 07 b1 04
0x0020 38 6e 00 7c 09 75 13 83-c5 10 e2 f4 cd 18 8b f5
0x0030 83 c6 10 49 74 19 38 2c-74 f6 a0 b5 07 b4 07 8b
Which looks like it's for windows 95 to windows vista. What format is your driver expecting to read? I can't figure out how to make the card start with the correct boot sector type, even after formatting it as FAT32.