Board.KolibriOS.org

Hello,
I got my 3350MX with the intention of using its PXE capabilities, unfortunately its PXE bios module is v2.0 and since long ago (1999) everything runs PXE v2.1

Opening a bios image with mmtool.exe I find
Module: 20
Vendor: 17F3
DeviceID: 6040
It's the AMI bios “PCI Option ROM” of the PXE v2.0 bios component of the “RDC R6040” vortex86 NIC.

Does anyone know if there’s available the same module but implementing PXE 2.1 in order to make a bios “really” able to do PXE on the 3350MX?

Thanks

Why do you think it will not work?
Whats the big difference between v2.0 and v2.1?

http://wiki.kolibrios.org/wiki/Boot_from_PXE

It works for me (on eBox)

Works for me as well, successfully booted WTWare via PXE boot.

I wasn't talking specifically about KolibryOS.
On that link you guys just chain to memdisk which by chance does not require 2.1,
my problem is chaning to other NBPs (i.e XP Startrom.n12 ) that systematically hang the eBox.

I've contacted DPM/ICOP about this but I wanted to know if you guys had some info on this; I've seen there are people with good BIOS background arround here.

thanks

I haven't tried XP, but I did try WTWare as I wrote above. It's based on Linux. I think that almost any Linux version will boot via PXE on eBox. You did not answer which function is required from PXE 2.1 that is missing in PXE 2.0. Are you sure that your setup (i.e. Serva that you mentioned on RoboSavvy forum) is not the problem? Note that eBox does not support i686 instructions and x64 at all. In order to support i586 instructions you need to turn MMX on in BIOS. If your installation environment tries to use i686 or x64 (or i586 with MMX disabled in eBox BIOS), it won't work.

Sorry when you posted your answer I was writing mine.
When you say booting Linux you really mean prxelinux.0, that’s right I’m able to load pxelinux.0 but when thisone wants to load Startrom.n12 the PXE stack shows on the screen it cannot perform the TFTP transfer, I understand the two versions (2.0/2.1) have non identical !PXE structures then when a chained NBP relies on the stack that got the previous NBP the thing gets broken…

No I meant I was able to load complete Linux, not just pxelinux.0
If you try to boot Windows XP via PXE without Serva, does it work?
Can you post screenshots of your errors?

When you run a typical Linux PXE install the only code that really requires PXE services is pxelinux.0; when the kernel gets loaded it does not rely on a previously loaded in memory PXE environment. Fortunately pxelinux.0 understands PXE v2.0 and v2.1.
PXE 2.0 API relies on the C structure PXENV+ while v2.1 makes the former structure obsolete and replaces it with the structure !PXE.

I’ve just performed more testing, when I try to PXE install XP the problem is not Serva. Pxelinux.0 loads ok but when it calls its own module “pxechain” (in order to load Startrom.n12) it gets as TFTP IP address 0.0.0.0 !!! of course pxechain relies on the previously loaded in memory pxelinux.0 PXE stack and getting a TFTP IP = 0.0.0.0 (when pxelinux.0, vesamenu.c32 and default, were transferred from the TFTP server w/o problem) smells to PXE API 2.0 vs 2.1 problem.

Putting all of this together makes me think that PXE v2.1 might be required… I also wonder how a company that sells cutting edge embedded designs and also advertise BIOS developments can rely on a BIOS module based on a standard that was replaced 13 years ago?

Anyway, coming back to my original question, does anyone know if the updated PXE BIOS module can be obtained “somewhere”??

patpat wrote: Anyway, coming back to my original question, does anyone know if the updated PXE BIOS module can be obtained “somewhere”??

If anybody has it, it's RDC. The bios module must be specific for the RDC6040.
Have you tried contacting them?

It's a bit tricky... Probably RDC only release the hardware info under some NDA and the one that codes the module is actually DMP or even AMI, I really do not know; I've contacted DMP/ICOP and I've been routed to some technical staff but no answer yet...

I've checked BIOS files of various eBox machines I own, and all ROM files I have got PXE 2.0 in their signature.
However I still don't think your install fails just because it's not version 2.1
Pity I don't have enough spare time to reproduce your scenario and find your problem.
Does your Serva have a server-side log of all what it's doing, that you can attach here?

Thanks for your effort, but forget about Serva. This is pxelinux.0 calling pxechain for calling Startrom.n12.
Why are you trying to blame Serva here?

pxelinux.0 loads and runs ok.
pxechain says TFTP IP=0.0.0.0 when it should've got the right TFTP server IP from the PXE stack; can't you see that?

btw Serva log shows the last file requested and TFTP transferred was pxechain.

The Serva menu entry looks like where the append command starting with "::" means the TFTP IP address should be taken from the PXE stack, but that PXE stack has TFTP IP=0.0.0.0 then of course it cannot continue...

I really wonder how w/o having more info than this you can say "I still don't think your install fails just because it's not version 2.1" ???

Anyway I think DPM/ICOP should replace the 13 years old PXE BIOS module with a current one and we all can save future guess work on these topics.

To be sure, try the same config on a PXE2.1 capable machine.
(You can even use VirtualBox or another virtual machine)

Also, you can use gPXE (Etherboot) to get PXE2.1 to the eBox.

Exactly the same set-up on a PXE 2.1 capable PC works perfectly.

I really think the best approach would be updating eBox firmware. I hope DPM/ICOP is listening.