On Tue, 27 Dec 2005 13:29:17 +0100, Rolf Sommerhalder
<[EMAIL PROTECTED]> wrote:
>Good news - my WRAPs now pxeboot OpenBSD as expected! The culprit was
>not pxeboot, but the etherboot PXE code 5.3.12 in BIOS 1.08 and 1.10,
>as supplied by PCengines.
>
Seems you were lucky but if you had to dig i
Good news - my WRAPs now pxeboot OpenBSD as expected! The culprit was
not pxeboot, but the etherboot PXE code 5.3.12 in BIOS 1.08 and 1.10,
as supplied by PCengines.
After building an etherboot 5.4.1 binary on rom-o-matic.org, merging
it into the BIOS and flashing the WRAPs, network boot of OpenB
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
WRAP.
Both encouraged me to dig deeper:
a) pxeboot finds both labels '!PXE' and 'PXENV' in
>>> Rolf Sommerhalder 26-Dec-05 11:45 >>>
>
> The posting
> http://www.monkey.org/openbsd/archive2/bugs/200503/msg1.html
> is interesting, as it points out that there has already been a problem
> with pxe_call.
Why is that posting interesting? That bug was fixed. I said that the
problem wou
On 12/26/05, Tom Cosgrove <[EMAIL PROTECTED]> wrote:
> 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. An
> Ah yes, according to CVS log
>
> http://www.openbsd.org/cgi-bin/cvsweb/src/sys/arch/i386/stand/libsa/pxe_call.S
> that real/protected mode problem should be patched since v1.2.
>
> But did current v1.3 eventually break it again?
Replacing pxe_call.S v1.3 by v1.2 does unfortunately not solve th
>>> 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 i
> 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' ?
Doesn't really help you, but GENERIC runs just fine on Geode machines...
The posting
http://www.monkey.org/openbsd/archive2/bugs/200503/msg1.html
is interesting, as it points out that there has already been a problem
with pxe_call.
> single-stepping back into pxeboot. Five instructions later, I hit the
> lockup point at 4012:403c. The instruction causing the pro
After inserting some printf() debug statements into
/sys/arch/i386/stand/libsa/pxe.c
I found that the call to the assembler subroutine
pxe_call(PXENV_GET_CACHED_INFO);
never returns.
It looks like either there is something wrong with that call, or with
the PXE code from Etherboot.
Rolf
On 12/26/05, J.C. Roberts <[EMAIL PROTECTED]> wrote:
> Have you tried bsd.rd ?
Just tried it, but pxeboot does not continue to boot either.
tcpdump on the TFTP server reveals that the WRAP's PXE client actually
requests and loads the pxeboot file, but does not get that far where
it would request
On 12/26/05, J.C. Roberts <[EMAIL PROTECTED]> 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
On Mon, 26 Dec 2005 10:13:50 +0100, Rolf Sommerhalder
<[EMAIL PROTECTED]> 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?
Have you tried bsd.rd ?
jcr
13 matches
Mail list logo
