CDROM Problems

[gudenau]

I am attempting to read a sector from a CDROM image in bochs, but I am getting "ata0-0: read sectors issued to non-disk" but bochs is configured to have a CDROM at 0-0. It boots fine from the disk.

Read sector code:

Code: Select all

[bits 32]
readSector:
	mov dx, 0x01F6
	mov al, 0xE0
	out dx, al
	
	mov dx, 0x01F1
	mov al, 0x00
	out dx, al
	
	mov dx, 0x01F2
	mov al, 0x01
	out dx, al
	
	mov dx, 0x01F3
	mov al, 0x01
	out dx, al
	
	mov dx, 0x01F4
	mov al, 0x00
	out dx, al

	mov dx, 0x01F5
	mov al, 0x00
	out dx, al
	
	mov dx, 0x01F7
	mov al, 0x20
	out dx, al
	
	jmp $

bochs.cfg:

Code: Select all

# configuration file generated by Bochs
plugin_ctrl: unmapped=1, biosdev=1, speaker=1, extfpuirq=1, parallel=1, serial=1, gameport=1, iodebug=1
config_interface: textconfig
display_library: x
memory: host=1024, guest=1024
romimage: file="/usr/local/share/bochs/BIOS-bochs-latest"
vgaromimage: file="/usr/local/share/bochs/VGABIOS-lgpl-latest"
boot: cdrom
floppy_bootsig_check: disabled=0
# no floppya
# no floppyb
ata0: enabled=1, ioaddr1=0x1f0, ioaddr2=0x3f0, irq=14
ata0-master: type=cdrom, path="bootable.iso", status=inserted, model="Generic 1234", biosdetect=auto
ata0-slave: type=disk, path="disk.img", mode=flat, cylinders=20805, heads=16, spt=63, model="Generic 1234", biosdetect=auto, translation=auto
ata1: enabled=1, ioaddr1=0x170, ioaddr2=0x370, irq=15
ata1-master: type=none
ata1-slave: type=none
ata2: enabled=0
ata3: enabled=0
pci: enabled=1, chipset=i440fx
vga: extension=vbe, update_freq=5, realtime=1
cpu: count=1:1:1, ips=4000000, quantum=16, model=bx_generic, reset_on_triple_fault=0, cpuid_limit_winnt=0, ignore_bad_msrs=1, mwait_is_nop=0
cpuid: level=6, stepping=3, model=3, family=6, vendor_string="AuthenticAMD", brand_string="AMD Athlon(tm) processor"
cpuid: mmx=1, apic=xapic, simd=sse2, sse4a=0, misaligned_sse=0, sep=1, movbe=0, adx=0
cpuid: aes=0, sha=0, xsave=0, xsaveopt=0, x86_64=1, 1g_pages=0, pcid=0, fsgsbase=0
cpuid: smep=0, smap=0, mwait=1, vmx=1
print_timestamps: enabled=0
debugger_log: -
magic_break: enabled=1
port_e9_hack: enabled=0
private_colormap: enabled=0
clock: sync=none, time0=local, rtc_sync=0
# no cmosimage
# no loader
log: -
logprefix: %t%e%d
debug: action=ignore
info: action=report
error: action=report
panic: action=ask
keyboard: type=mf, serial_delay=250, paste_delay=100000, user_shortcut=none
mouse: type=ps2, enabled=0, toggle=ctrl+mbutton
sound: waveoutdrv=dummy, waveout=none, waveindrv=dummy, wavein=none, midioutdrv=dummy, midiout=none
speaker: enabled=1, mode=sound
parport1: enabled=1, file=none
parport2: enabled=0
com1: enabled=1, mode=null
com2: enabled=0
com3: enabled=0
com4: enabled=0

Any help is appreciated!

[Nable]

It looks like you're trying to read CD with ATA commands. It won't work, sorry. You should read about ATAPI instead: http://wiki.osdev.org/ATAPI

If you need more specific answer, I'll try to say more. Briefly speaking, IDE is a physical interface and devices can communicate over it using different sets of commands (different protocols). The most common command sets are ATA (mostly for HDDs) and ATAPI (mostly for CD drives).

[gudenau]

It looks like you're trying to read CD with ATA commands. It won't work, sorry. You should read about ATAPI instead: http://wiki.osdev.org/ATAPI

Hrm, I figured it would be the same because they are on the same bus. I will look into that.

Edit:
So, I make a buffer with my command then send it out of the relevant ATA ports? Could I poll instead of using interrupts?

Edit 2:
Something like this?

Code: Select all

out 0x01F6, 0x00
out 0x01F1, 0x00
out 0x01F4, 0x0C
out 0x01F5, 0x00
out 0x01F7, 0xA0
call wait
out 0x01F0, com1
out 0x01F0, com2
out 0x01F0, com3
out 0x01F0, com4
out 0x01F0, com5
out 0x01F0, com6
call wait
in 0x01F5, ah
in 0x01F4, al
shr ax, 1
loop:
cmp ax, 0
je done
in 0x01F0, bx
[store in buffer]
dec ax
jmp loop
done:
ret

[Nable]

Hrm, I figured it would be the same because they are on the same bus. I will look into that.

Same physical bus doesn't mean same protocol, while waiting for your answer I've edited my message to add a notice about it.

About polling: it's a bad idea and in fact you cannot disable IRQ generation for this kind of devices.

http://wiki.osdev.org/ATAPI#x86_Directions
Then wait for another IRQ. You cannot poll.

[gudenau]

Hrm, I figured it would be the same because they are on the same bus. I will look into that.

Same physical bus doesn't mean same protocol, while waiting for your answer I've edited my message to add a notice about it.

About polling: it's a bad idea and in fact you cannot disable IRQ generation for this kind of devices.

http://wiki.osdev.org/ATAPI#x86_Directions
Then wait for another IRQ. You cannot poll.

See my last post, edited while you replied. :-D

[Nable]

AFAIR, it won't compile. But you're taking right direction and I think that you're able to fix it when you'll try implementing all this stuff. Just try it.

[gudenau]

AFAIR, it won't compile. But you're taking right direction and I think that you're able to fix it when you'll try implementing all this stuff. Just try it.

Thanks, that will probably take a while, I was attempting to wait to do my IDT.

[SpyderTL]

I'm currently fighting with the ATA/ATAPI commands on the IDE controller, trying to read audio data, and I think a lot of the problems that I'm running into are rooted in the fact that I'm ignoring the interrupt and polling instead. For reading a single block from the CD-ROM, it seems to work fine, but that may be because I've been running primarily on virtual machines (VirtualBox, VMware, Bochs, SimNow, M.E.S.S, Tornado64, etc.)

But for reading audio data, the CD-ROM can't be virtualized, so the drive must be configured for direct access. ("Passthrough" in VirtualBox, non-"Legacy" mode in VMware, etc.)

But this brings up an interesting point. If you "can't use polling" for reading from CD-ROM, and "must wait for an interrupt", like the Wiki says... what happens if a different device causes an interrupt on IRQ 14/15? (The wiki isn't clear which IRQ is fired in which scenario, either.)

Is it guaranteed that you'll never get an IRQ 14/15 unless the IDE controller sent it?

Is IRQ 14 for the primary device and IRQ 15 for the slave device (or vice versa)?

EDIT: Just FYI, all of my interrupt handlers currently increment one of 255 counters, and then return. This works well for single-threaded applications, which is all I care about at the moment. So, for me, instead of polling the controller itself, I can simply "poll" the correct counter and wait for it to change. Quick and dirty...

EDIT2: It looks like IDE Controller 1 uses IRQ 14 for both master and slave device, and IDE Controller 2 uses IRQ 15. So this highlights the question, what if the IDE 1 master and slave device both finish a read operation, and fire an IRQ 14? Is there any way to know which IRQ goes to which device? Or must the OS guarantee that only one device is active at a time?