NFS root WRAP

MrMoo

Another comedy multi-stage sequence, etherboot -> pxelinux -> pxeboot -> failure.


Probing pci nic...
[dp83815]
natsemi_probe: MAC addr 00:0D:B9:04:9A:3C at ioaddr 0X1000
natsemi_probe: Vendor:0X100B Device:0X0020
dp83815: Transceiver default autoneg. enabled, advertise 100 full duplex.
dp83815: Transceiver status 7869 advertising 05E1
dp83815: Setting full-duplex based on negotiated link capability.
Searching for server (DHCP)...\
Me: 10.0.0.160, DHCP: 10.0.0.183, TFTP: 10.0.0.183, Nameserver 10.0.0.1
Loading 10.0.0.183:pxelinux.0 XXXX(0012K done

PXELINUX 3.11 2005-09-02  Copyright (C) 1994-2005 H. Peter Anvin
....
PXE Loader 1.00

Building the boot loader arguments
Relocating the loader and the BTX
Starting the BTX loader

The loader doesn't attempt to load anything else, maybe there is a way of forcing it to use the serial console?

MrMoo

Not surprisingly these options didn't do much in /etc/make.conf for rebuilding pxeboot.0


LOADER_TFTP_SUPPORT=YES
BTX_SERIAL=YES
BOOT_PXELDR_ALWAYS_SERIAL=YES

billm

Any chance you didn't disable VGA in the kernel?

–Bill

MrMoo

@billm:

Any chance you didn't disable VGA in the kernel?

There's an update on the freebsd-embedded mailing list. It appears because FreeBSD uses VM86 mode and the BIOS wants real mode, its currently not possible to get working without re-writing the BTX loader.

I'm not sure why loading the kernel direct has the same problem though.

MrMoo

Actually as the subject implies the work around for not being able to PXE boot the kernel is to have the kernel on compact flash and have that NFS root mount its filing system.

hoba

I sent a mail to Pascal Dornier (creator of the tiny bios and designer of the wrap boards) to ask for a solution. I'll translate the technical aspects of his answer:

I asked him to make the netboot default bootmethod for wraps:
You can compile a new bios with the latest etherboot.org netboot module. It will offer the setting to make the netboot the default bootmethod.

How can FreeBSD successfully boot vie Netboot:
tinybios goes to "unreal mode" if it accesses ram>1 MB. This happens after memorytest + PCI PNP only if something calls Int15 function 87 (block move), which can be controlled. If this is used I would suggest that the VM handles that or the VM uses block move functions.

He provided me a biossource as attachment. If you are interested to have a look I can forward it to you. I also asked him if there is the possibility to somehow roll out a new biosversion with these 2 things fixed. I'm waiting for his answer (mail sent minutes ago).

hoba

Got an answer. In case it's the netboot module calling the function that breaks the bootup it might be fixed with the latest version from eherboot.org. Just download the bios from pcengines, then download from etherboot.org the latest version and replace eboot.bin with the new version. Then run make.bat. I don't have the possibility to try that as I'm not home. Maybe someone can try that and report back.

MrMoo

@hoba:

Got an answer. In case it's the netboot module calling the function that breaks the bootup it might be fixed with the latest version from eherboot.org. Just download the bios from pcengines, then download from etherboot.org the latest version and replace eboot.bin with the new version. Then run make.bat. I don't have the possibility to try that as I'm not home. Maybe someone can try that and report back.

Isn't the same effect achieved with the chain loading sequence? i.e. loading 5.4.2 from the current version in the ROM, which is what I am doing above as the BIOS complains about memory otherwise.

The freebsd-embedded team got to a similar point:

On Fri, Jul 28, 2006 at 12:36:54PM -0400, John Baldwin wrote:

This is because the BIOS you are talking to here is trying to enter
protected mode on its own, which simply does not play well with VM86 at all.
It's not something you are going to "fix" in VM86 unless you change BTX
drastically to pop back into real mode to call the BIOS and handle IRQs
rather than using vm86 mode.

PC-Engines says that only the int 15, function 87 goes back into
protected mode, and that seems to be trapped in boot/i386/btx/btx/btx.S
line 609 so the FreeBSD BTX should cover that case. Or am I
misunderstanding something here?

The disassembled code you mention:

00000000 660F01975200 o32 lgdt [bx+0x52]
00000006 0F20C0 mov eax,cr0
00000009 0C01 or al,0x1
0000000B 0F22C0 mov cr0,eax
0000000E 66FFAF6A00 jmp dword far [bx+0x6a]
00000013 66B810008ED0 mov eax,0xd08e0010
00000019 89EC mov sp,bp
0000001B 8ED8 mov ds,ax
0000001D 8EC0 mov es,ax
0000001F 8E db 0x8E
seems to indeed stem from http://www.pcengines.ch/tb13.zip INT1X.8
where the "Int 15, AH=87: block move" is handled in "unreal mode", as
described in http://www.pcengines.ch/tb13.pdf. So would that mean that
BTX didn't trap that or something else was amiss before?

Adrian

MrMoo

I was hoping the PC Engines guy would work it out and release a new BIOS, a couple of the developers were getting quite exicted. Looks like they gave up :(

Numbski

This is going to qualify as a DDH (damn dirty hack), but what else am I good at? ;)

If you guys are at all familiar with the Tivo, they don't make the unit hackable on purpose. In fact, you have to go to an awful lot of trouble in order to be able to play with the thing at all! You have to kill the initrd process at boot time, and have to load a kernel other than theirs….however the unit will ONLY boot theirs.

The solution to this is something called monte. monte allows you to switch kernels entirely after the boot process has loaded the kernel initially.

You could in theory compile monte to execute on the linux you got to load, and then monte to your pfSense kernel, could you not? Assembler isn't my strong point here, so feel free to jump in and stomp on me if I've entirely missed the problem.

Here's the sourceforge link:

http://sourceforge.net/projects/monte/