Page 1 of 1

Reading ATA status port always gives 0xFF (IDENTIFY command)

Posted: Sun Nov 20, 2022 2:19 am
by Cyao
Hello,

Im tring to read from my boot cdrom, but its always responding 0xFF :( , and I've checked and i think that all the logic is right, can anyone help me have a look? thanks!

https://github.com/cheyao/AchiveOS/blob ... b/cd.c#L33

Re: Reading ATA status port always gives 0xFF (IDENTIFY comm

Posted: Sun Nov 20, 2022 3:03 am
by Octocontrabass
Does your virtual machine's debug log show that you're accessing the hardware? Bochs is very talkative if you enable debug messages.

Re: Reading ATA status port always gives 0xFF (IDENTIFY comm

Posted: Sun Nov 20, 2022 3:07 am
by Cyao
Octocontrabass wrote:Does your virtual machine's debug log show that you're accessing the hardware? Bochs is very talkative if you enable debug messages.
Nope, no messages after the 00035981151i[BIOS ] Booting from 07c0:0000 message

Re: Reading ATA status port always gives 0xFF (IDENTIFY comm

Posted: Sun Nov 20, 2022 4:24 am
by nullplan
0xFF is the open bus value. You seem to think it was 0, but no, if no hardware is there, you get all 1-bits. Unfortunately, for some hardware ports, 0xFF is also a valid register value. Anyway, you do not seem to be detecting ATA, but are just assuming an ATA controller to be at a predetermined address.

0xFF being the open-bus value is also why most A20 enabling code using the keyboard controller is wrong on systems that don't have a keyboard controller. But that is a question for another time.

Re: Reading ATA status port always gives 0xFF (IDENTIFY comm

Posted: Sun Nov 20, 2022 4:59 am
by Cyao
nullplan wrote:0xFF is the open bus value. You seem to think it was 0, but no, if no hardware is there, you get all 1-bits. Unfortunately, for some hardware ports, 0xFF is also a valid register value. Anyway, you do not seem to be detecting ATA, but are just assuming an ATA controller to be at a predetermined address.

0xFF being the open-bus value is also why most A20 enabling code using the keyboard controller is wrong on systems that don't have a keyboard controller. But that is a question for another time.
I think that shouldn't be the case, it reports 0xff for all 4 ports, but atleast one should have something since i've got a cdrom connected

Re: Reading ATA status port always gives 0xFF (IDENTIFY comm

Posted: Sun Nov 20, 2022 8:37 am
by Cyao
And now I just used changed it to use a pointer, but now it gets 0 out of the pointer when using -O2, but -O1 and -O0 works. Is there some kind of UB that im overlooking?

Re: Reading ATA status port always gives 0xFF (IDENTIFY comm

Posted: Sun Nov 20, 2022 3:00 pm
by Octocontrabass

Re: Reading ATA status port always gives 0xFF (IDENTIFY comm

Posted: Mon Nov 21, 2022 11:11 am
by Cyao
Octocontrabass wrote:How big is your kernel binary?
Its only 19 sectors, enough for now.

And I found the problem, some how i needed a delay after the inb, dunno why, but its fixed :D

but thanks for the help!

Re: Reading ATA status port always gives 0xFF (IDENTIFY comm

Posted: Mon Nov 21, 2022 11:59 am
by Octocontrabass
cyao1234 wrote:Its only 19 sectors, enough for now.
Are you sure? I checked a recently-generated disk image and the kernel binary in that one is at least 30 sectors...

Re: Reading ATA status port always gives 0xFF (IDENTIFY comm

Posted: Mon Nov 21, 2022 1:01 pm
by Cyao
Octocontrabass wrote:
cyao1234 wrote:Its only 19 sectors, enough for now.
Are you sure? I checked a recently-generated disk image and the kernel binary in that one is at least 30 sectors...
That's weird, on my pc it's only 19 sectors, anywas im going to increase it a little bit

Re: Reading ATA status port always gives 0xFF (IDENTIFY comm

Posted: Mon Nov 21, 2022 1:32 pm
by Octocontrabass
You should figure out a way to automatically load the correct number of sectors. Otherwise, you'll keep running into problems whenever your kernel outgrows your bootloader.