cannot run latest FreeBSD on a 15 year old PC

we probably need to pad the bootcode with a known pattern until its size is a multiple of 512b. if its size is already a multiple of 512 add a whole "patterned" sector
when pmbr code reads the data should stop if the sector it just read ends with the pattern.
this way it will be backwards compatible and will minimize the bios data overwrite risk
here is a shell script which will pad a file to sector multiple and terminates it with a specific pattern
Code: 
#!/bin/sh
[ -r "$1" ] || exit
s=$(stat -f  %z "$1")
r=$((($s / 512 + 1) * 512 - $s))
PAT="EOOBBOOE"
if [ $r -lt 8 ];then
    r=$(($r + 512 - 8))
else
     r=$(($r - 8))
fi
cat "$1" && head -c $r /dev/zero | tr '\0' . && echo -n $PAT
 
covacat said:
we probably need to pad the bootcode with a known pattern until its size is a multiple of 512b. if its size is already a multiple of 512 add a whole "patterned" sector
when pmbr code reads the data should stop if the sector it just read ends with the pattern.
this way it will be backwards compatible and will minimize the bios data overwrite risk
here is a shell script which will pad a file to sector multiple and terminates it with a specific pattern
Code: 
#!/bin/sh
[ -r "$1" ] || exit
s=$(stat -f  %z "$1")
r=$((($s / 512 + 1) * 512 - $s))
PAT="EOOBBOOE"
if [ $r -lt 8 ];then
    r=$(($r + 512 - 8))
else
     r=$(($r - 8))
fi
cat "$1" && head -c $r /dev/zero | tr '\0' . && echo -n $PAT
Click to expand...

It needs to modify pmbr and gpart bootcode -b (or the make of gptboot / gptzfsboot).
And even with that, one cannot be sure this pattern will be found in the freebsd-boot partition, so the 545k test shall remain. As the room for code is very limited, it will be difficult to impossible to have both tests.

pmbr has been modified since 14.1-RELEASE. It's supposed to stop loading at 545k and continue the booting. It just emits a warning message... Is it bugged? The Op said it was a new 15.1-RELEASE installation. I will test this case.
 
the code itself is not bugged, the 545k provision is rather large as the code now is < 200k. the risk to overwrite something important for the bios will be less if 545 was 400 or 300 or 200
 
Code: 
load_boot: push %si            # Save %si
        call read
        pop %si                # Restore
        movl PART_END_LBA(%di),%eax    # See if this was the last LBA
        cmpl (%si),%eax
        jnz next_boot
        movl PART_END_LBA+4(%di),%eax
        cmpl 4(%si),%eax
        jnz next_boot
        mov %bx,%es            # Reset %es to zero
        jmp LOAD            # Jump to boot code
next_boot: addl $1,(%si)            # Next LBA
        adcl $0,4(%si)
        mov %es,%ax            # Adjust segment for next
        addw $SECSIZE/16,%ax        #  sector
        cmp $0x9000,%ax            # Don't load past 0x90000,
        jb sz_ok            #  545k should be enough for
        call err_big            #  any boot code, but warn
        mov $0x9000-SECSIZE/16,%ax    #  and truncate
sz_ok:  mov %ax,%es
        jmp load_boot

Oh... Just to read the code is enough to see the bug. It lacks a "jmp LOAD" after "mov $0x9000-SECSIZE/16,%ax".
 
the non fitting sectors will load at the same 0x90000 - 0x200 address (which is kind of useless) but should still work if nothing is broken
 
You're right. I went too fast. I need to sink anew in this code and the AT&T mnemonics.
That said, I don't see another test to get out of the loop than the comparison to PART_END_LBA plus something.

A test with an oversized freebsd-boot partition will give us the answer.
 
You must log in or register to reply here.
Back
Top