The pfSense Store

Author Topic: NFS root WRAP  (Read 10352 times)

0 Members and 1 Guest are viewing this topic.

Offline MrMoo

  • Jr. Member
  • **
  • Posts: 86
    • View Profile
    • じゅんこ
NFS root WRAP
« on: July 27, 2006, 04:54:51 am »
I'm going around in circles and not sure if anyone has actually got this to work with FreeBSD.  Basically the PC Engines WRAP hardware has optional etherboot support, precisely its v5.4.1 from http://etherboot.org  From this you can either boot the kernel or the pxeboot loader.  Some sites say the kernel needs to be uncompresed for etherboot, however whichever method fails.

For kernel loading directly:

Code: [Select]
ROM segment 0xe000 length 0x8000 reloc 0x00000000
Etherboot 5.4.1 (GPL) http://etherboot.org
Drivers: NATSEMI   Images: NBI ELF PXE   Exports: PXE
Protocols: DHCP TFTP NFS TFTM HTTP DNS
Relocating _text from: [00088f80,0009fe20) to [07ee9160,07f00000)
Boot from (N)etwork (D)isk or (Q)uit? N

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 nfs://10.0.0.183:/usr/local/ocean/pxe-clone/boot/kernel/kernel.gz XXXX(0608|
segment [000A0000,000A0400) does not fit in any memory region
<abort>

For loading pxeboot:

Code: [Select]
ROM segment 0xe000 length 0x8000 reloc 0x00000000
Etherboot 5.4.1 (GPL) http://etherboot.org
Drivers: NATSEMI   Images: NBI ELF PXE   Exports: PXE
Protocols: DHCP TFTP NFS TFTM HTTP DNS
Relocating _text from: [00088f80,0009fe20) to [07ee9160,07f00000)
Boot from (N)etwork (D)isk or (Q)uit? N

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 tftp://10.0.0.183:/pxeboot XXXX(0214K done
PXE Loader 1.00

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


Amusingly you can load a different etherboot image from etherboot itself, but that didn't help either.

Code: [Select]
ROM segment 0xe000 length 0x8000 reloc 0x00000000
Etherboot 5.4.1 (GPL) http://etherboot.org
Drivers: NATSEMI   Images: NBI ELF PXE   Exports: PXE
Protocols: DHCP TFTP NFS TFTM HTTP DNS
Relocating _text from: [00088f80,0009fe20) to [07ee9160,07f00000)
Boot from (N)etwork (D)isk or (Q)uit? N

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:eb-5.4.2-natsemi.zpxe XXXX(0026K done
PXE->EB !PXE 9F40:0000 9F40:0680 9F40:0AB0 9E40:1000 dp83815: Setting full-duplex based on negotiated link capability.
0000 0000 0000 0280 ok
Etherboot 5.4.2 (GPL) http://etherboot.org
Drivers: NATSEMI   Images: NBI ELF FreeBSD PXE   Exports: PXE
Protocols: DHCP TFTP NFS
Relocating _text from: [0008ac10,0009fe00) to [07eeae10,07f00000)
Boot from (N)etwork or (Q)uit?

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 786D 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
Loading tftp://10.0.0.183:/pxeboot XXXX(0214K done
PXE Loader 1.00

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

The DHCP/TFTP/NFS server works fine serving a VMware machine.

 :'(

Links:

Boink in the m0n0 wiki didn't get much further.
A big thread on OpenBSD and WRAP/PXE had no real details.
There appears an implication from the LEAF project with Linux and PXE WRAP, at least in the tarball.
Using pxelinux and etherboot for another multistage boot process.
« Last Edit: July 27, 2006, 09:21:06 am by MrMoo »

Offline MrMoo

  • Jr. Member
  • **
  • Posts: 86
    • View Profile
    • じゅんこ
Re: NFS root WRAP
« Reply #1 on: July 27, 2006, 05:44:50 am »
I'm using the following etherboot parameters:

Code: [Select]
natsemi:dp83815 -- [0x100b,0x0020]

PXE bootstrap loader format ROM Image (.zpxe)

ASK_BOOT: -1
BOOT_FIRST: BOOT_NIC
BOOT_SECOND: BOOT_NOTHING
BOOT_THIRD: BOOT_NOTHING
BOOT_INDEX: 0
ELF_IMAGE
PXE_IMAGE
IMAGE_FREEBSD
FREEBSD_KERNEL_ENV
DOWNLOAD_PROTO_TFTP
PXE_EXPORT
CONFIG_PCI
PCBIOS

With etherboot etherbooting the kernel loads but nothing more happens:

Code: [Select]
[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 786D 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
Loading tftp://10.0.0.183:/kernel ...(ELF/FreeBSD)... .........................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................done

Trying the FLATTEN_REAL_MODE for OpenBSD doesn't seem to affect FreeBSD.

Code: [Select]
[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 786D 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
Loading 10.0.0.183:pxeboot ...(PXE).........................................................................................................................................................done
PXE Loader 1.00

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

Offline MrMoo

  • Jr. Member
  • **
  • Posts: 86
    • View Profile
    • じゅんこ
Re: NFS root WRAP
« Reply #2 on: July 27, 2006, 11:07:12 pm »
Maybe it is just a messed up serial console, its acting very strange.  Connecting via teraterm gives me the BIOS boot but nothing more:

Code: [Select]
WRAP.1 v1.11

Wisp-Router.com
Your Full Time Professionals

640 KB Base Memory
130048 KB Extended Memory

01F0 - no drive found !

Connecting via kermit gives me only the Etherboot ROM:

Code: [Select]
ROM segment 0xe000 length 0x8000 reloc 0x00000000
Etherboot 5.4.1 (GPL) http://etherboot.org
Drivers: NATSEMI   Images: NBI ELF PXE   Exports: PXE
Protocols: DHCP TFTP NFS TFTM HTTP DNS
Relocating _text from: [00088f80,0009fe20) to [07ee9160,07f00000)
Boot from (N)etwork (D)isk or (Q)uit?

 ???

Offline MrMoo

  • Jr. Member
  • **
  • Posts: 86
    • View Profile
    • じゅんこ
Re: NFS root WRAP
« Reply #3 on: July 27, 2006, 11:25:27 pm »
PXELINUX just stops before loading a Linux Kernel, this is from the LEAF project that is supposed to be WRAP friendly.  I guess I need to try Voyage too.

Code: [Select]
ROM segment 0xe000 length 0x8000 reloc 0x00000000
Etherboot 5.4.1 (GPL) http://etherboot.org
Drivers: NATSEMI   Images: NBI ELF PXE   Exports: PXE
Protocols: DHCP TFTP NFS TFTM HTTP DNS
Relocating _text from: [00088f80,0009fe20) to [07ee9160,07f00000)
Boot from (N)etwork (D)isk or (Q)uit?

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
Loading pxe/linux...............
Loading pxe/initrd.lrp........
Ready.
dp83815: Setting full-duplex based on negotiated link capability.

Offline MrMoo

  • Jr. Member
  • **
  • Posts: 86
    • View Profile
    • じゅんこ
Re: NFS root WRAP
« Reply #4 on: July 27, 2006, 11:32:49 pm »
Great, the Voyage Linux kernel works, so I wonder whats up with the FreeBSD kernels I am using :(

Code: [Select]
PXELINUX 3.11 2005-09-02  Copyright (C) 1994-2005 H. Peter Anvin
Loading pxe/linux......................
Loading pxe/initrd.lrp........
Ready.
dp83815: Setting full-duplex based on negotiated link capability.
Linux version 2.6.15-486-voyage (2.0-10) (root@punknix-uml) (gcc version 3.3.5 (Debian 1:3.3.5-13)) #1 PREEMPT Mon Mar 27 07:45:05 GMT 2006
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 00000000000a0000 (usable)
 BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 0000000008000000 (usable)
 BIOS-e820: 00000000fff00000 - 0000000100000000 (reserved)
128MB LOWMEM available.
DMI not present.
Allocating PCI resources starting at 10000000 (gap: 08000000:f7f00000)
Built 1 zonelists
Kernel command line: ro root=/dev/ram0 ip=dhcp initrd=pxe/initrd.lrp console=ttyS0,9600 BOOT_IMAGE=pxe/linux
No local APIC present or hardware disabled
Initializing CPU#0
PID hash table entries: 1024 (order: 10, 16384 bytes)
Detected 266.667 MHz processor.
Using tsc for high-res timesource
Console: colour dummy device 80x25
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
Memory: 126216k/131072k available (1606k kernel code, 4316k reserved, 598k data, 140k init, 0k highmem)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Calibrating delay using timer specific routine.. 534.42 BogoMIPS (lpj=1068850)
Mount-cache hash table entries: 512
CPU: NSC Unknown stepping 01
Checking 'hlt' instruction... OK.
checking if image is initramfs...it isn't (no cpio magic); looks like an initrd
Freeing initrd memory: 359k freed
NET: Registered protocol family 16
PCI: PCI BIOS revision 2.10 entry at 0xfc47b, last bus=0
PCI: Using configuration type 1
PCI: Probing PCI hardware
PCI: Device 0000:00:12.5 not found by BIOS
Initializing Cryptographic API
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered
i8042.c: No controller found.
Serial: 8250/16550 driver $Revision: 1.90 $ 2 ports, IRQ sharing enabled
�serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a NS16550A
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
mice: PS/2 mouse device common for all mice
padlock: VIA PadLock not detected.
NET: Registered protocol family 2
IP route cache hash table entries: 2048 (order: 1, 8192 bytes)
TCP established hash table entries: 8192 (order: 3, 32768 bytes)
TCP bind hash table entries: 8192 (order: 3, 32768 bytes)
TCP: Hash tables configured (established 8192 bind 8192)
TCP reno registered
TCP bic registered
NET: Registered protocol family 1
NET: Registered protocol family 10
lo: Disabled Privacy Extensions
IPv6 over IPv4 tunneling driver
NET: Registered protocol family 17
NET: Registered protocol family 15
Using IPI Shortcut mode
IP-Config: No network devices available.
RAMDISK: Compressed image found at block 0
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(1,0)

Offline MrMoo

  • Jr. Member
  • **
  • Posts: 86
    • View Profile
    • じゅんこ
Re: NFS root WRAP
« Reply #5 on: July 28, 2006, 02:38:08 am »
I'm hoping its simply its a serial console issue.  m0n0wall uses FreeBSD 4.11 which supports inline configuration parameters in the kernel, e.g.

Code: [Select]
# Serial (COM) ports
device sio0 at isa? port IO_COM1 flags 0x30 irq 4
device sio1 at isa? disable port IO_COM2 irq 3
device sio2 at isa? disable port IO_COM3 irq 5
device sio3 at isa? disable port IO_COM4 irq 9

FreeBSD 5 and above use /boot/device.hints file or an include file with the "hints" parameter, this is not included in the pfSense embedded kernel.  Which means that loading the kernel directly from etherboot will fail because if cannot load the hints file.   :-\

Offline MrMoo

  • Jr. Member
  • **
  • Posts: 86
    • View Profile
    • じゅんこ
Re: NFS root WRAP
« Reply #6 on: July 28, 2006, 03:46:39 am »
Another comedy multi-stage sequence, etherboot -> pxelinux -> pxeboot -> failure.

Code: [Select]
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?

Offline MrMoo

  • Jr. Member
  • **
  • Posts: 86
    • View Profile
    • じゅんこ
Re: NFS root WRAP
« Reply #7 on: July 28, 2006, 04:35:49 am »
Not surprisingly these options didn't do much in /etc/make.conf for rebuilding pxeboot.0

Code: [Select]
LOADER_TFTP_SUPPORT=YES
BTX_SERIAL=YES
BOOT_PXELDR_ALWAYS_SERIAL=YES

Offline billm

  • Administrator
  • Hero Member
  • *****
  • Posts: 731
    • View Profile
    • UCSecurity - Technology discovery and ramblings
Re: NFS root WRAP
« Reply #8 on: July 28, 2006, 05:14:51 pm »
Any chance you didn't disable VGA in the kernel?

--Bill
pfSense core developer
blog - http://www.ucsecurity.com/
twitter - billmarquette

Offline MrMoo

  • Jr. Member
  • **
  • Posts: 86
    • View Profile
    • じゅんこ
Re: NFS root WRAP
« Reply #9 on: July 28, 2006, 10:19:27 pm »
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.

Offline MrMoo

  • Jr. Member
  • **
  • Posts: 86
    • View Profile
    • じゅんこ
Re: NFS root WRAP
« Reply #10 on: July 29, 2006, 07:39:09 am »
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.

Offline hoba

  • Administrator
  • Hero Member
  • *****
  • Posts: 5837
  • What was the problem to this solution again?
    • View Profile
    • pfSense
Re: NFS root WRAP
« Reply #11 on: July 29, 2006, 12:53:35 pm »
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).

Offline hoba

  • Administrator
  • Hero Member
  • *****
  • Posts: 5837
  • What was the problem to this solution again?
    • View Profile
    • pfSense
Re: NFS root WRAP
« Reply #12 on: July 29, 2006, 02:28:05 pm »
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.

Offline MrMoo

  • Jr. Member
  • **
  • Posts: 86
    • View Profile
    • じゅんこ
Re: NFS root WRAP
« Reply #13 on: July 29, 2006, 09:33:52 pm »
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:

Quote
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

Offline MrMoo

  • Jr. Member
  • **
  • Posts: 86
    • View Profile
    • じゅんこ
Re: NFS root WRAP
« Reply #14 on: August 24, 2006, 10:57:40 pm »
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 :(