ATA Problems: works in VBox, not in QEMU or Bochs.
Posted: Fri Jul 19, 2013 3:00 am
I realise there's another recent thread dealing with... what *appears* to be a similar issue, but here I am, threadjacking isn't legit.
I'm having an issue reading sectors from an ATA drive. I currently have 2 drives connected: one is an MBR drive, the other a GPT drive.
I believe with reasonable confidence that both the MBR and GPT partition reading code works correctly... However, initialising a partition (specifically, reading anything above LBA2 on the second, GPT drive) results in... some weird ****.
Here is the relevant code, before I proceed:
PIO.cpp: http://pastebin.com/ppPYQ8bd
GPT.cpp: http://pastebin.com/2R5qNXxT
MBR.cpp: http://pastebin.com/mK1f8tSj
Partition.cpp: http://pastebin.com/XbALj2xQ
ATA.cpp: http://pastebin.com/6GFZ2Que
What happens is this:
1. MBR code detects partitions on both ATA devices. The first device is simply a single-partition boot drive with FAT32. The secondary drive (bus0, drive 1) is a GPT drive with 4 HFS+ partitions.
2. MBR code detects the 0xEE partition on the second drive and calls ReadPartitions() in GPT.cpp.
3. GPT code detects the partitions.
There's a secondary problem here: Reading the partitions... doesn't guarantee a GUID of 0x00.... which is most likely a problem on my end, but...
4. GPT code therefore only detects 4 partitions. It loops through (as shown) and detects the first HFS+ partition, and calls (new Partition()) with the relevant information.
5. Partition() detects the GUID of a HFS+ partition and calls new HFSPlus().
6. In HFSPlus(), I attempt to read a couple of sectors from the second drive. That, fails -- I get 0x00 on all reads.
7. This is the worst part: after all that, it returns back to the GPT code.
8. In the next loop, somehow *everything* gets trashed and becomes 0x00: no other partitions are initialised.
9. Reading from the first drive, however, works 100%...
The best part? As seen from the title, the bugs at steps 7 and 8... simply don't exist in VBox.
If there's any other code that might be needed, find the repo at https://bitbucket.org/requimrar/orion-x3.
This probably seems like another 'solve-my-problem-for-me-plus-code-dump' kind of post... but I've been trashing my brains about this and I cannot see the problem. It's probably something ridiculously stupid...
Thanks!
I'm having an issue reading sectors from an ATA drive. I currently have 2 drives connected: one is an MBR drive, the other a GPT drive.
I believe with reasonable confidence that both the MBR and GPT partition reading code works correctly... However, initialising a partition (specifically, reading anything above LBA2 on the second, GPT drive) results in... some weird ****.
Here is the relevant code, before I proceed:
PIO.cpp: http://pastebin.com/ppPYQ8bd
GPT.cpp: http://pastebin.com/2R5qNXxT
MBR.cpp: http://pastebin.com/mK1f8tSj
Partition.cpp: http://pastebin.com/XbALj2xQ
ATA.cpp: http://pastebin.com/6GFZ2Que
What happens is this:
1. MBR code detects partitions on both ATA devices. The first device is simply a single-partition boot drive with FAT32. The secondary drive (bus0, drive 1) is a GPT drive with 4 HFS+ partitions.
2. MBR code detects the 0xEE partition on the second drive and calls ReadPartitions() in GPT.cpp.
3. GPT code detects the partitions.
There's a secondary problem here: Reading the partitions... doesn't guarantee a GUID of 0x00.... which is most likely a problem on my end, but...
4. GPT code therefore only detects 4 partitions. It loops through (as shown) and detects the first HFS+ partition, and calls (new Partition()) with the relevant information.
5. Partition() detects the GUID of a HFS+ partition and calls new HFSPlus().
6. In HFSPlus(), I attempt to read a couple of sectors from the second drive. That, fails -- I get 0x00 on all reads.
7. This is the worst part: after all that, it returns back to the GPT code.
8. In the next loop, somehow *everything* gets trashed and becomes 0x00: no other partitions are initialised.
9. Reading from the first drive, however, works 100%...
The best part? As seen from the title, the bugs at steps 7 and 8... simply don't exist in VBox.
If there's any other code that might be needed, find the repo at https://bitbucket.org/requimrar/orion-x3.
This probably seems like another 'solve-my-problem-for-me-plus-code-dump' kind of post... but I've been trashing my brains about this and I cannot see the problem. It's probably something ridiculously stupid...
Thanks!