Author Topic: SOLVED boot1: error for many BIOSes (Dell XPS 410/Dimension 9200 in particular)  (Read 12177 times)

0 Members and 1 Guest are viewing this topic.

rivig

  • Entrant
  • Posts: 4
There are many people here complaining about Chameleon working fine from USB drive, but giving them infamous "boot1: error" when trying to install it to hard drive. This error (in my case at least) is caused by improper handling of some BIOSes of segment:offset passed to them by boot1h.

First, kudos to Zef, who managed to squeeze full HFS+ read-only driver into 512 bytes (or so - second part of boot1h). It is amazing achievement - it parses all variants of file location, and judging by the code should even work in highly fragmented cases, when overflow extents are necessary, but it complicated my debugging immensely. There is simply almost no place, you should move code around to be able to squeeze some debug output.

Finally, I found that some BIOSes does not like when offset passed is negative, that is have highest bit set. This is incorrect, because address is formed by interpreting offset as unsigned integer, but so it was programmed by people who can not read well. The consequences are that such BIOS does not allow to load second stage boot loader (containing EFI emulation) if it's larger than 32K.

The phenomenon of successful booting from USB can be explained as well: this part of BIOS is written much later, by other people, who interpreted the architecture by the book, not by heart ;-)

Anyway, the recipe is simple - instead of splitting linear address by 16:16 bits, split it 20:12, because higher 12 bits of linear space are unnecessary anyway it does not affect actual result.

For you it boils down to small editing of boot1.s of Chameleon 2.0 RC3 - replacing lines 564-8:

    push    dx
    xor     dx, dx
    shr     edx, 4
    mov     es, dx
    pop     bx

with the code (please, retain the comment and the original code, just comment it out):

    ; Some BIOSes do not like offset to be negative while reading
    ; from hard drives. This usually leads to "boot1: error" when trying
    ; to boot from hard drive, while booting normally from USB flash.
    ; The routines, responsible for this are apparently different.
    ; Thus we split linear address slightly differently for these
    ; capricious BIOSes to make sure offset is always positive.

    mov bx, dx
    and bx, 0x0fff                             
    shr edx, 4                                                         
    xor dl, dl
    mov es, dx


Then recompile it:

nasm boot1.s -o boot1h

and place it into its usual first 2 sectors of your HFS+ boot partition (as described in Chameleon's README).

That's it. Happy booting!

rals2007

  • Observer
  • Posts: 10
Can this also be done in cdboot.s ? Looking at the source, it has also the same string that you were referring to.

rivig

  • Entrant
  • Posts: 4
I think so. And cdboothdd.s, whatever the difference between it and cdboot.s. Fortunately in boot0.s and chain0.s the offset is set explicitly to 0x1000, so this is not a problem there. And I still don't know why boot2 works! It uses OFFSET macro inside, which is
Code: [Select]
#define OFFSET(addr)      ((addr) & 0xFFFF)and so should not work if you step long enough reading your file. The only reason I can imagine, is that they read into intermediate buffer, which is in fortunate place, then copy over to the final place. Needs investigation yet.

I've sent the patched file to Zef, and hope it will appear in the next release of Chameleon.

zef

  • Administrator
  • Posts: 265
Thx rivig for the patch! :)

Will be applied to boot1.s, boot1f32.s and cdboot.s. They're using the very same code regarding how linear address are mapped to segment:offset pairs.


ASUS P8Z68-V PRO/GEN3 | i5-2500k | 16GB RAM | GTX560 | Keyboard | Mouse | Devilsound DAC

rals2007

  • Observer
  • Posts: 10
rivig

Patched file is also the same on post#1 ?

rivig

  • Entrant
  • Posts: 4
@rals2007 - sure, you just replace this calculation of segment:offset with a new one and you're good to go. That, by the way can explain why for me not a signle CD-boot method worked, and I tried many.

@zef - you're welcome, I'm only glad to be of little use after your enormous work.

rals2007

  • Observer
  • Posts: 10
Thank You for the wonderful fix. Also worked on my old Asus Laptop.

Just to make sure...

is it,

mov bx, dx
and bx, 0x0fff                             
shr edx, 4                                                         
xor dl, dl
mov es, dx


or,

mov       bx, dx
and        bx, 0x0fff                             
shr        edx, 4                                                         
xor        dl, dl
mov       es, dx


zef

  • Administrator
  • Posts: 265
Since we don't touch BL register, we can even spare 1 extra byte by replacing:

Code: [Select]
and     bx, 0x0fff

with:

Code: [Select]
and     bh, 0x0f

ASUS P8Z68-V PRO/GEN3 | i5-2500k | 16GB RAM | GTX560 | Keyboard | Mouse | Devilsound DAC

rivig

  • Entrant
  • Posts: 4
Yea, and this saved byte can be useful, I felt it ;-)

zef

  • Administrator
  • Posts: 265
Thanks again rivig!

Your fix will be available in the next release - the changes are committed to our repo - including boot1h (+debug versions), boot1f32, cdboot, cdboothdd.
ASUS P8Z68-V PRO/GEN3 | i5-2500k | 16GB RAM | GTX560 | Keyboard | Mouse | Devilsound DAC

abend

  • Entrant
  • Posts: 7
Thank you, Thank you, Thank you, Rivig. My HP dc7800 has been stuck at 1.0.11 due to this bug. Now I can move forward. BTW, the '1 byte smaller' version of your patch works fine as well.

abend