On 12/26/05, J.C. Roberts <[hidden email]> wrote:
> >01F0 - no drive found !
> >My /tftpboot/bsd should be ok as the same kernel file boot ok from a
> >CompactFlash card.
> Should we assume you have removed the CompactFlash device?
Yes, the CF card is removed, as someone trying PXE on Soekris
experienced problems when there was a such drive. But, although the
"01F0 - no drive found !" error disappears after inserting a bootable
CF card, the pxeboot process still freezes.
> Have you tried bsd.rd ?
No, not yet. Will try that now, even though I expect that it might not
work as it was probably built for GENERIC machine and not for a WRAP
that uses an National SC1100 'Geode' ?
>>> Rolf Sommerhalder 26-Dec-05 09:13 >>>
> pxeboot from OpenBSD3.8 (but also from 3.5, 3.6. and 3.7) fails to PXE
> boot WRAP appliances with BIOS 1.08 which supports PXE using etherboot
> (see www.pcengines.ch):
> Probing pci nic...
> natsemi_probe: MAC addr 00:0D:B9:01:A0:A4 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 half-duplex based on negotiated link capability.
> Searching for server (DHCP)...
> Me: 10.0.0.20, Server: 10.0.0.3, Gateway 10.0.0.1
> Loading 10.0.0.3:pxeboot (PXE)done
> probing: pc0 com0 pci pxe![2.1] <--- the cursor stays here
> Searching the Web also for Soekris (which is similar to WRAP) hints
> that the "A20 gate hack" may be the culprit for this halt.
This is very unlikely to have anything to do with it, as I used the
Soekris while implementing pxeboot on OpenBSD (based on the NetBSD code).
> Still, the boot process halts in the 'probing' line, right after 'pxe![2.1]'
The most likely reason is that pxeboot's calls into the PXE stack on
the WRAP are failing (to return).
> Do you have any suggestion how I could debug or prevent this freeze,
> for example by using debug compile flags in the Makefile, etc.?
Get me a WRAP board, babysit the kids for a few evenings, and wait
If you want to look at it yourself, make sure you understand i386
assembler, the PXE specification, and protected-to-real-and-back mode
You could find out if pxe_call works at all on the WRAP in its current
implementation by putting a printf() after it, and seeing if there'
any output. Look in pxe.c:pxe_init().
> single-stepping back into pxeboot. Five instructions later, I hit the
> lockup point at 4012:403c. The instruction causing the problem is:
> addrsize opsize lgdt [ds:0x45e80]
> which is the line marked "Load the GDT" in the following code from
> pxe_call.S in the OpenBSD source:
> * real_to_prot()
> * Switch the processor back into protected mode.
> .globl real_to_prot
> xorw %ax, %ax
> movw %ax, %ds /* Load %ds so we can get at Gdtr */
> data32 addr32 lgdt Gdtr /* Load the GDT */
> Note the address [ds:0x45e80] that this resolves to in the pxeboot binary.
> In particular, note that the offset contains five hexadecimal digits.
> We're allegedly in real-mode at this point. We can't access more than 64k
> in each segment, yet this instruction is trying to access data at an
> offset of approximately 279k. The CPU doesn't like this.
Not sure whether this issue was fixed in OpenBSD yet. That code in OpenBSD3.8 is
* Switch the processor back into protected mode.
> You could find out if pxe_call works at all on the WRAP in its current
> implementation by putting a printf() after it, and seeing if there'
> any output. Look in pxe.c:pxe_init().
Thanks, did that and definitely pxe_call() never returns. And it is
not specific to pxe_call(PXENV_GET_CACHED_INFO), because I also called
pxeinfo() which does a pxe_call(PXENV_UNDI_GET_NIC_TYPE) which never
As you say, it looks like I might have to refresh rusty gdb skills
now, and figure out what 'boch' does (as I am totally inexperienced
with baby sitting ;-)
On return from real mode, reload the GDT using a 16-bit pointer
rather than a 32-bit value. Found by Tim Fletcher <tim (at)
parrswood (dot) manchester (dot) sch (dot) uk> using Etherboot;
thanks to Tim and the Etherboot developers who narrowed this down.
Another OpenBSD on WRAP user wrote to me saying that pxeboot works.
Also, I found http://www.ultradesic.com/?section=43 which descripbes
PXE booting OpenBSD for the Soekris plattform which is very similar to
Both encouraged me to dig deeper:
a) pxeboot finds both labels '!PXE' and 'PXENV' in the BIOS code;
b) the checksums of both those BIOS section are OK, e.g. PXE code in
the BIOS appears to be intact;
c) forcing pxeboot to use the legacy PXENV (instead of the !PXE v2.1)
API results in pxe_call() to return OK. (forced by commenting out the
line " bang = 1; " in /sys/arch/i386/stand/libsa/pxe.c)
However, it appears that result fields of those calls are filled with
zero. Because calls of pxeinfo() returns with IP addresses and netmask
as 0.0.0.0, instead of DHCP client & server addresses.
d) Upgrading WRAP's BIOS from 1.08 to 1.10 did not make any difference.
Notably finding c) encouraged me to also question my DHCP server
configuration, which currently is:
Just to crosscheck the PXE capability of WRAP's BIOS, I also tried to
load pxegrub from GRUB as 2nd stage boot loader, instead of pxeboot
from OpenBSD. So far, pxegrub gets loaded, but I do not get any GRUB
prompt yet (something with serial console port parameters might still
be wron in my GRUB configure).