Sorry, Michael. I meant that I made a patch for gPXE to accept the
mal-formed OACK. I _wish_ I had access to TPMfOSd source code. Or
maybe you knew that I was talking about a gPXE patch, and were simply
asking out loud in case anyone else could offer some options.
The best I could dig up was some source code for something called the
Rembo Wizard Toolkit, which might be a project based on the Rembo code
(when/if it was open source code at one point) and containing some Rembo
code. Of course, it would likely be fairly dated, now. I downloaded
it, but didn't save the link.
It might be possible to debug in QEmu. It might be possible to
recompile gPXEs as-needed to work with the Rembo-ia32 loader. For
example, a SYSLINUX floppy image with a cmdline+initrd-patched gPXE, and
an embedded script FOO could do the trick. One needs FOO because we
need to manually set some client-specific DHCP options which the NBP is
expecting.
It would be nice to hear from these developers; I would have thought
that advertising the ability to deploy to any computer capable of
booting gPXE would have been a boon, but I understand that it might not
necessarily be a business priority.
Down below, I've included parts of my original e-mail.
--- --- --- E-MAIL START --- --- ---
_____________________________________________
From: Miller, Shao
Sent: Wednesday, November 12, 2008 19:05
To: BLANKITYBLANKBLANK
Subject: RE: PXE Support
... ... ...
Screenshot of the Rembo service TFTP OACK problem:
<ATTACHED_AS_REMBO1.JPG>
Screenshot of gPXE work-around ignoring the OACK and booting Rembo-ia32:
<ATTACHED_AS_REMBO2.JPG>
You can see that we get as far as Rembo - !PXE v2.1 API detected. All
of that other stuff inside the word "detected" is gPXE debugging
verbosity, showing what Rembo-ia32 is doing with the UNDI:
Rembo - !PXE v2.1 API PXENV_GET_CACHED_INFO 3 to 0000:0000+0 returning
9c8f:1418+04ec['0']PXENV_GET_CACHED_INFO 2 to 0000:0000+0 returning
9c8f:0f2c+04ec['0']detPXENV_UNDI_CLOSEePXENV_UNDI_SHUTDOWNcPXENV_UNLOAD_
STACKtPXENV_UNDI_INITIALIZEed
I hope this helps them, if they are interested in supporting all of
those models via gPXE.
- Shao Miller
--- --- --- E-MAIL END --- --- ---
Since then, a newer version of TPMfOSd along with the unfortunate TFTP
OACK gPXE patch applied to a newer gPXE version will allow for a
different error message. Something about "Too many GDT entries."
The unfortunate patch to gPXE involves putting
goto done;
at the beginning of tftp_rx_oack() in gpxe/src/net/udp/tftp.c.
Huh. It looks like I also patched pxenv_undi_shutdown() and
pxenv_undi_close() to remove the pxe_netdev_close() call inside of
gpxe/src/interface/pxe/pxe_undi.c while I was debugging. That's not for
the TFTP OACK problem, though. It was probably something else while
debugging.
- Shao Miller
-----Original Message-----
From: Michael Brown [mailto:mbrown@...]
Sent: Friday, March 27, 2009 02:17
To: Miller, Shao
Cc: etherboot-discuss@...
Subject: Re: [Etherboot-discuss] Sends filename als Rembo-ia32\000
On Thursday 26 March 2009 16:13:16 Miller, Shao wrote:
> This is exactly true. I made a patch some time ago to do exactly
this.
> It's a mal-formed OACK. I've brought this up to the TPMfOSd
developers
> a long time ago; perhaps they haven't fixed their TFTP service
> implementation yet.
>
> Even if they do, the product is still incompatible past this point.
> "Too many GDT entries." Debugging is possible, but I sort of suspect
> that any patching needs to happen away from gPXE.
This might be optimistic, but is source available (even if not under a
licence
that allows redistribution) for the IBM product?
Michael
|