Octocontrabass wrote:
The BIOS EDD specification says it's a 4-byte dword, but also says that the dword contains a 16-bit far pointer instead of a 32-bit linear pointer. Whoever wrote that part of RBIL only copied the size of the data and not its type.
so 16 out of the 32 bits of this field are for the far pointer; what are the other 16 bits used for? maybe a dumb question but it's been a while since I did anything that's not in 64 bits land.
This is the
formula I used for 32-bit far pointers
Code:
LIN_TO_FAR_ADDR(linaddr) (((linaddr >> 4) << 16) | (linaddr & 0xf))
I guess I can easily convert it to get a 16-bit far pointer as so(?):
Code:
LIN_TO_FAR_ADDR(linaddr) (((linaddr >> 2) << 8) | (linaddr & 0xf))
Octocontrabass wrote:
I would guess it doesn't work in either case. What data do you see in memory in the "working" version? Does that data actually match the contents of your disk?
well yes my entire kernel is loaded by this function so unless both QEMU, VMWare, VBox, and the motherboard I use for testing are doing some crazy stuff with the image generated by Debian (and not with the Arch one), it does work
Octocontrabass wrote:
The read is successful, but the data ends up in the wrong location in memory.
yea it makes total sense