cannot run latest FreeBSD on a 15 year old PC

[covacat]

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

#!/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

 

[Emrion]

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

#!/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

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.

 

[covacat]

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

 

[Emrion]

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".

 

[covacat]

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

 

[Emrion]

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.

 

[T-Aoki]

Maybe the size was chosen from the gap between last address MBR is read into by legacy BIOS and 640KiB limit, minus 64KiB single real mode segment for buffering disk reads by BIOS to copy (move) to HMA, according to this.

 

[Emrion]

It was pretty simple. I have a VM with 14.4-RELEASE. I first checked it boots well with BIOS (it was starting with EFI). Then, I resized the freebsd-boot partition to 1004 KB (that was the space available).

On reboot, I got "Loaded only 545k" in an infinite loop. So, the patch just doesn't work. It's amazing that no one tested the only purpose of this patch before. I mean, you change something to get a given result, you test at least what it's supposed to bring.

If I have time, I will see what I can do.

 

[covacat]

looks like putstr from call err_big fux and resets the SI reg which holds the address current sector read and will never reach the last lba of the partition