> The 'storage in the NIC where the PXE code resides, is, in fact an > EEPROM, which is similar to 'FLASH'. Really, it is an EPROM, that can > be written to without removing it from the board....whether it is > socketed, soldered on, or internal to the NIC controller is almost > irrelevant. A socketed one can be re-porgrammed in a PROM programmer > without UV, as it is 'Electrically Erasable'. Some uC programmers use > them to test a program, as they can download each version of their > program without removing, erasing programming, and replugging. On > slower systems, they use a ROM emulator, but on faster systems, the > cable length introduces its own problems..
>From a software person's POV, flash can be updated by software and even treated like a sort of disk drive via an MTD driver. The rest can't. > Having said all that, once the initial pxe load (eb-......lzpxe) has > completed, can the client then do a 'normal' dhcp boot ?, or are there > several stages to the process before the linux kernal can be loaded ?. Once PXE has chained Etherboot, it's Etherboot and should behave just as if you loaded Etherboot from ROM. Early on there were side effects of using PXE on some systems, but no-one has complained recently. Etherboot's PXE "support" does NOT use UNDI (the PXE nic independent driver) or PXE DHCP and TFTP. Currently Etherboot unloads PXE, then proceeds as normal: load nic driver, DHCP request, pull NBI... If anyone feels motivated, adding PXE UNDI suport to Etherboot should be quite straightforward, and this might be useful for sites which have multiple nic types and a "PXE only" policy. ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Caffeinated soap. No kidding. http://thinkgeek.com/sf _____________________________________________________________________ Ltsp-discuss mailing list. To un-subscribe, or change prefs, goto: https://lists.sourceforge.net/lists/listinfo/ltsp-discuss For additional LTSP help, try #ltsp channel on irc.openprojects.net
