> 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.