Page 1 of 1

LBA load with Int 13h extensions

Posted: Thu Apr 02, 2009 8:32 am
by johnsa
So I'm having a weird problem.. the code works under all the emulators and on 2 real machines with int 13h ext. support... but one one DELL Optiplex G630 it reports EDD2.1 / int 13h extension support but just hangs
on the int call... here is the code.. anyone see anything funny ?

Code: Select all


; Here is the disk_packet struct...
align 4
	disk_packet    db 10h									; 10h or 18h Disk Packet Structure for Extended int 13h loads(size).
			       db 0										; reserved.
			       db 32									; block count to transfer (max 07fh for phoenix edd).
			       db 0										; reserved
			       dw 0,0									; ofs:seg for read/write buffer (if ffffh:ffffh use last qword and 18h).
			       dq 1										; qword block start (2nd sector).
			       dq 0										; Float 64bit address of transfer buffer if dword at 4 is ffff:ffff (EDD3). (not used).

; here is the code snippet.. load... the val in EAX and CL and ES:BX I've checked and they're correct.. 
; ONE thing i did notice in the spec doc there is 1 byte for the sector count and a reserved byte, in RB's int list there is a a full DW (word)?!?

	mov esi,offset disk_packet
	mov dword ptr ds:[esi+12],0
	mov dword ptr ds:[esi+8],eax	; Store Starting Sector.
	mov byte ptr ds:[esi+2],cl		; Store Sector Count to disk_packet.
	mov ax,es
    mov word ptr ds:[esi+6],ax		; Store Segment to Load To.
    mov eax,ebx
    mov word ptr ds:[esi+4],ax		; Store Offset to Load To.
    mov dl,fs:[BOOT_DRIVE_ID]
	mov ax,4200h
	int 13h

Re: LBA load with Int 13h extensions

Posted: Thu Apr 02, 2009 10:16 am
by quok
Are you running this code from an El-Torito bootable CD by chance? Some research I've done in the past revealed broken/dodgy BIOSes that don't return good information for the INT13h Extensions Check when booting from a no-emulation EL-Torito image as well as on hard disk emulations. Others don't return proper information for the geometry checks on El-Torito images, but I don't remember if that's under no-emulation or hard disk emulation or what.

I haven't actually looked at your code, just had a few thoughts to share about my research with El-Torito images as you'll see a lot of this type of stuff there. (That is, working on some machines, and not others.)

Re: LBA load with Int 13h extensions

Posted: Thu Apr 02, 2009 11:29 am
by johnsa
Nope, it's booting from USB HDD emulated.. whats odd as well.. is that that piece of code i posted, where the issue is.... is in the 2nd stage boot loader. The first stage loader uses the same sort of code and it seems to work on all machines.. it checks for extensions, if found, tries to get the drive info from the ext. functions else reverts to 08h and CHS reads.. it finds the same ext info and loads the stage 2 loader with it... the only difference i can see is
the starting sector, sector count and load address

in stage1 the vals are:
start: 1
count: 32 (16kb stage2)
load: 07c0:0000

in stage 2:
start 33
count: 64
load: ffff:00016

and yes a20 is enabled and unreal mode too.. so i load 32kb high, then move it out somewhere else...(for kernel load and bkg image load etc).

This all works everywhere except on this one dumb dell optiplex machine.. and that annoys me :)

Re: LBA load with Int 13h extensions

Posted: Fri Apr 03, 2009 5:13 am
by johnsa
Ok... things eventually got worse.. then there was much testing and investigation and fiddling... and now it's solved..

Here is what happened:

The Dell Optiplex GX620 when booting from USB would emulate a HDD.. reported info was drive: 80h, 13h extensions supported, Version 2.1
Crash when trying to call int 13h extended read, machine reboot.

So i tried it on my other machine, a Dell Latitude D830, which reports all the same info, emulated USB-HDD boot but it would work using extended int 13h read.

So to test, I tried FORCING the legacy 08h CHS read mode.. and then BOTH machines crashed.

Eventually it turned out that it was the load address ES:BX being = 0ffff:0010 ....
It works with 13h-extended read on the latitude but not the optiplex and didn't work for EITHER using legacy CHS functions, but it DID work when reading from a CD-ROM under FDD emulated boot.
Moral of the story... DONT load to that address and you'll be happy :)

Cheers

Re: LBA load with Int 13h extensions

Posted: Fri Apr 03, 2009 10:24 am
by ru2aqare
johnsa wrote: Eventually it turned out that it was the load address ES:BX being = 0ffff:0010 ....
...
Moral of the story... DONT load to that address and you'll be happy :)
You realize that FFFF:0010 is exactly the one megabyte mark, and if the A20 address line is not enabled, this becomes the zero megabyte mark...? Where the real-mode IVT is located. So the IVT could have been overwritten, which would easily explain why the machines crashed.

If you did that intentionally while the A20 address line was enabled, then just ignore this post.

Re: LBA load with Int 13h extensions

Posted: Sat Apr 04, 2009 4:07 pm
by Combuster
Even then, the BIOS might decide to do its own address translation and load to 0x0 anyway, A20 or not.

Re: LBA load with Int 13h extensions

Posted: Sat Apr 04, 2009 7:09 pm
by bewing
Yes -- trying to use any bios INT call on memory that is > 640K is just asking for a system crash. It may work on some systems, but boot code is supposed to be portable, and non-buggy bios support of "upper memory" is highly bios-specific. (ie. not portable at all)

Re: LBA load with Int 13h extensions

Posted: Sun Apr 05, 2009 4:47 am
by johnsa
a20 was enabled, i guess it is just a case of the bios doing its own translation and doing something funny with the address... IE making it 0, or checking for >640kb. In any event it's a fairly obvious thing.. just make sure you never try and load data from bios anywhere over it and it works everywhere as opposed to intermittently. Its a pity bochs and qemu are so forgiving all the time.. many times ive had issues like this.. or at least the emulators should have 2 modes.. maximum tolerance ( to allow as much as possible to work ) and a dev mode that is more strict and emulates these sort of nuances of the more unforgiving bioses/systems etc.. IE qemu doesn't seem to check that PDE entries are 2Mb aligned either.. my paging cod worked perfectly in it but obviously not on real h/w or in bochs.. once again a silly little mistake that was easily fixed, but that fact it worked in qemu made me look in the wrong place and thing it might be something less trivial.

Re: LBA load with Int 13h extensions

Posted: Sun Apr 05, 2009 11:22 am
by bewing
Yes, I am trying to code some of these error tests as "user options" into my new version of bochs. In this particular case, however, the bochs "bios" is a completely separate program from bochs itself, and it is difficult to make it "customizable". Bochs simply assumes that the emulated bios is written properly, and is not buggy. Unfortunately, it seems to be true that most real bioses ARE buggy in some way.