NetBSD Problem Report #32958
From www@netbsd.org Wed Mar 1 04:24:22 2006
Return-Path: <www@netbsd.org>
Received: by narn.netbsd.org (Postfix, from userid 31301)
id A180263B877; Wed, 1 Mar 2006 04:24:22 +0000 (UTC)
Message-Id: <20060301042422.A180263B877@narn.netbsd.org>
Date: Wed, 1 Mar 2006 04:24:22 +0000 (UTC)
From: sinda@users.sf.net
Reply-To: sinda@users.sf.net
To: gnats-bugs@netbsd.org
Subject: pxeboot on WRAP
X-Send-Pr-Version: www-1.0
>Number: 32958
>Category: port-i386
>Synopsis: pxeboot on WRAP
>Confidential: no
>Severity: serious
>Priority: high
>Responsible: port-i386-maintainer
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Wed Mar 01 04:25:00 +0000 2006
>Last-Modified: Sun Oct 15 17:30:01 +0000 2006
>Originator: Petr Sindylek
>Release: NetBSD 3.0
>Organization:
AlphaSys, s.r.o.
>Environment:
>Description:
I'm not able to PXE boot WRAP 1E [1] system board using NetBSD's pxeboot. It looks like this:
PC Engines WRAP.1C/1D/1E v1.08
640 KB Base Memory
130048 KB Extended Memory
01F0 Master 848A Hitachi XX.V.3.4.0.0
Phys C/H/S 695/15/48 Log C/H/S 695/15/48
ROM segment 0xe000 length 0x8000 reloc 0x00020000
Etherboot 5.3.12 (GPL) http://etherboot.org
Drivers: NATSEMI Images: NBI PXE Exports: PXE
Relocating _text from: [00089370,0009b230) to [07eee140,07f00000)
Boot from (N)etwork (D)isk or (Q)uit? N
Probing pci nic...
[dp83815]
natsemi_probe: MAC addr 00:0D:B9:03:5C:BC 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: 192.168.127.19, Server: 192.168.127.254, Gateway 192.168.127.254
Loading 192.168.127.254:pxeboot_ia32.bin (PXE)done
>> NetBSD/i386 PXE Boot, Revision 1.1
>> (root@, Wed Mar 1 03:39:25 CET 2006)
>> Memory: 614/128824 k
Press return to boot now, any other key for boot menu
Starting in 0
exec: file=netbsd loadaddr=0x0
PXE BIOS Version 2.1
and it locks now. pxeboot enters pxe_call(PXENV_GET_CACHED_INFO) on line 389 of pxe.c ver. 1.6 and never return.
It seems similar to problem solved in this posting
http://www.monkey.org/openbsd/archive2/bugs/200503/msg00001.html
[1] http://www.pcengines.ch/wrap.htm
>How-To-Repeat:
>Fix:
>Audit-Trail:
From: Nino Dehne <ndehne@gmail.com>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: port-i386/32958
Date: Tue, 11 Apr 2006 19:13:18 +0200
Hi,
a recent Etherboot contains the option FLATTEN_REAL_MODE which carries a
description:
"Use 4GB segment limits when calling out to or returning to real-mode code.
This is necessary to work around some buggy code (e.g. OpenBSD's pxeboot)
that uses flat real-mode without being sufficiently paranoid about the
volatility of its segment limits."
which is exactly the fix described in the thread listed above.
Since my WRAP somehow doesn't jump into Etherboot when I flash it with a
recent 5.4.1 instead of the ancient 5.3.12, I wanted to revive this PR.
(Alternatively, if someone managed to get a 5.4.1 Etherboot into the WRAP
BIOS and make it boot, I'd be interested in hearing about it.)
From the description, it rather looks like a bug in pxeboot which Etherboot
merely works around.
If someone could please look into this, I'd be very grateful. This way, I
wouldn't have to fiddle with the WRAP and potentially wreck it.
Thanks
Best regards
ND
From: Nino Dehne <ndehne@gmail.com>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: port-i386/32958
Date: Sun, 1 Oct 2006 07:02:30 +0200
As it turned out, there was one Etherboot option that was in the readme to
WRAP's BIOS update which prevented Etherboot from getting jumped to, unless
you pressed N during the memory test. That really sucked because the list
of options made it sound like they were used to build the old Etherboot
already in the BIOS.
Anyway, a current Etherboot works now, although there is still trouble:
---- snip ----
PC Engines WRAP.1C/1D/1E v1.11
640 KB Base Memory
130048 KB Extended Memory
01F0 Master 848A Hitachi XXM2.3.0
Phys C/H/S 978/8/32 Log C/H/S 978/8/32
ROM segment 0xe000 length 0x8000 reloc 0x00000000
Etherboot 5.4.2 (GPL) http://etherboot.org
Drivers: NATSEMI Images: NBI ELF Multiboot PXE Exports: PXE
Protocols: DHCP TFTP
Relocating _text from: [0008bb80,0009fdc0) to [07eebdc0,07f00000)
Boot from (N)etwork or (Q)uit?
Probing pci nic...
[dp83815]
natsemi_probe: MAC addr 00:0D:B9:[...] 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: 192.168.1.99, DHCP: 192.168.1.1, TFTP: 192.168.1.1, Gateway 192.168.1.254
Loading 192.168.1.1:i386/n/pxeboot.bin ...(PXE)............................done
>> NetBSD/i386 PXE Boot, Revision 1.1
>> (build@[...], Fri Sep 22 03:59:22 CEST 2006)
>> Memory: 633/128943 k
Press return to boot now, any other key for boot menu
Starting in 0
type "?" or "help" for help.
>
>
>
> boot netbsd.gz
PXE BIOS Version 2.1
Using PCI device at bus 0 device 14 function 0
Ethernet address 00:0d:b9:[...]
net_open: client addr: 192.168.1.99
net_open: subnet mask: 255.255.255.0
net_open: net gateway: 192.168.1.254
net_open: server addr: 192.168.1.1
net_open: server path: /x/b/i386/n/any/ext-gw/
1914740+67142336+149048 [130592+123598]=0x423f4bc
dp83815: Setting full-duplex based on negotiated link capability.
---- snip ----
And that's it. pxeboot doesn't hang anymore. Instead, the kernel doesn't boot.
Is it perhaps still pxeboot related? How can I debug?
Best regards,
ND
From: Adrian Portelli <adrianp@stindustries.net>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Subject: Re: port-i386/32958
Date: Sun, 15 Oct 2006 18:27:30 +0100
Just as a data point I have a WRAP.1E-2 running BIOS v1.11 and the
pxeboot functionality has the same problem as documented earlier in this
ticket.
However, using a kernel built from the netbsd-3 branch I was able to
successfully boot a GENERIC kernel off a CF card on the WRAP.1E-2. So
you might want to try booting a kernel directly from a CF card and see
how far it gets you.
adrian.
(Contact us)
$NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2007
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.