>>> 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... > [dp83815] > 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 patiently :) If you want to look at it yourself, make sure you understand i386 assembler, the PXE specification, and protected-to-real-and-back mode switching. 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(). Tom
