ebox 3300/3350MX PXE capabilities

Using Kolibri in embedded systems
  • 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)
    "Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction." Albert Einstein
  • 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”??
    Attachments
    IMAG0513.jpg
    IMAG0513.jpg (127.35 KiB)
    Viewed 11289 times
  • 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?
    "Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction." Albert Einstein
  • 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

    Code: Select all

    LABEL 4
       menu label 	^4) Windows XP Home Edition, NTx86
       kernel		pxechain.cbt
       append		::WIA_RIS\XP_32\_SERVA_\startrom.n12
    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.
    "Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction." Albert Einstein
  • 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.
  • Who is online

    Users browsing this forum: No registered users and 7 guests