[9fans] pxe - nvram
Steve Simon
when doing a PXE boot (other than on a floppy or disk).
This would mean PXE is only really useful for terminals
rather than booting a CPU server.
Is this correct?
On a related note, I thought there was support for USB
flash disks, but cannot find any documentation - am I
being blind?
-Steve
ge...@collyer.net
it could easily be on a CF-IDE disk.
Ronald G. Minnich
On Sun, 28 Nov 2004, Steve Simon wrote:
> I cannot see any way that nvram could be stored
> when doing a PXE boot (other than on a floppy or disk).
Not sure I get this. What if you really have real nvram and are using it
(FLASH or CMOS)?
ron
Steve Simon
not even an IDE flash card. I hoped there might be somwhere I could
put my auth ID and key so I could boot CPU servers the same way
but I cannot see how - I have to use a disk of some sort.
I was vaguely hoping somone might know a standardised free area
PXE flash on ether cards or maybe know how to hide 64 odd bytes
of data in the CMOS nvram on x86 PCs.
The only idea I came up with is a allowing secstore to serve
up files without a password for given MAC address and auth ID pairs,
but then again MACs are no longer fixed-in-the-die in modern cards
so I am suspectable to spoofing.
Anyway the general answer appears to be "no" for x86 PCs.
-Steve
Kenji Okamoto
> flash disks, but cannot find any documentation - am I
> being blind?
Well, Richard may be out of the world now.
After revision of usbd, it doesn't work anymore.
Additionally, I think it is a personal and experimental version of
USB storage for Plan 9 by Richard. It also has a problem of being
very slow to transfer data. Those are, probably, the reason why
Richard does not make it public yet (Just my guess).
Kenji
ge...@collyer.net
PC started out short of resources (e.g., 8 then 15 IRQs) and some of
those limitations are still with us. Apparently nobody in a position
to fix it (e.g., Microsoft and Intel) thinks that having a chunk of
unallocated NVRAM would be useful enough to make it standard.
Richard Miller
Not quite! Just very busy.
> After revision of usbd, it doesn't work anymore.
True. Usbd has stopped doing some of the initialisation that the
usb storage driver (and perhaps also usb printing?) depended on.
I need to do a bit more work to recover from this.
But you should still be able to use the previous usbd - you'll
probably find it in /bin/usb/_usbd, or you can fetch it from
/n/sourcesdump/1106/plan9/386/bin/usb/usbd.
> Additionally, I think it is a personal and experimental version of
> USB storage for Plan 9 by Richard. It also has a problem of being
> very slow to transfer data. Those are, probably, the reason why
> Richard does not make it public yet (Just my guess).
Not personal (I've sent copies to everyone who asks) but still
experimental. The slow transfers are because the usbuhci driver in
the kernel does only one read/write per polling cycle. It should
be able to chain blocks together, but I have not been able to get
this to work yet.
-- Richard
Ronald G. Minnich
"Wait a minnit" I thought. Then I realized -- I only used the NVRAM on
linuxbios machines. Never mind. I'm sure the PC bios uses it all ...
ron
Jason Gurtz
> I couldn't find any free NVRAM in a stock PC when I last looked.
Some motherboards, Intel desktop boards in particular, support a boot
splash screen. Perhaps you could use that area to store stuff (after
making sure the bios is set to NOT display the splash screen!)
Or, maybe it would be really neat to hide data stenographicaly in an
actual splash screen. Off the top of my head the images are 640x480 at
256 colors. Not sure if they're compresses, there's a special tool they
have to use a bmp and put it in nvram.
Of course all this isn't standardized :/
~Jason
--
Nigel Roles
>On 30-Nov-04 02:58, ge...@collyer.net wrote:
>
>
>>I couldn't find any free NVRAM in a stock PC when I last looked.
>>
>>
>
>Some motherboards, Intel desktop boards in particular, support a boot
>splash screen. Perhaps you could use that area to store stuff (after
>making sure the bios is set to NOT display the splash screen!)
>
>Or, maybe it would be really neat to hide data stenographicaly in an
>actual splash screen. Off the top of my head the images are 640x480 at
>256 colors. Not sure if they're compresses, there's a special tool they
>have to use a bmp and put it in nvram.
>
>Of course all this isn't standardized :/
>
>~Jason
>
>
>
It's not nvram, it's part of the BIOS flash. I don't think I'd like to
reprogram my BIOS every time....
Ronald G. Minnich
On Tue, 30 Nov 2004, Nigel Roles wrote:
> > Some motherboards, Intel desktop boards in particular, support a boot
> > splash screen. Perhaps you could use that area to store stuff (after
> > making sure the bios is set to NOT display the splash screen!)
that's in FLASH, which is another kettle of fish. NVRAM is a simple
inb/outb to program, but FLASH, well, it is harder. But it would be WAY
cooler to use it, so ...
> > actual splash screen. Off the top of my head the images are 640x480 at
> > 256 colors. Not sure if they're compresses, there's a special tool they
> > have to use a bmp and put it in nvram.
intersting idea ...
ron
Ronald G. Minnich
On Tue, 30 Nov 2004, Jack Johnson wrote:
> for the splash screen, maybe some nice moire pattern. It would be
> nearly indecipherable by mere mortals, and would be a lot of (geek)
> fun.
as long as it looked like glenda, let's see, 480x320 is about 128 Kbits if
you just put it in the low bit!
ron
r...@vitanuova.com
> > nearly indecipherable by mere mortals, and would be a lot of (geek)
> > fun.
>
> as long as it looked like glenda, let's see, 480x320 is about 128 Kbits if
erm as pointed out earlier, the splash screen's gotta be *off*
otherwise a screen grab could potentially figure out your nvram &
hence decipher your passwords...
Ronald G. Minnich
On Tue, 30 Nov 2004 r...@vitanuova.com wrote:
> erm as pointed out earlier, the splash screen's gotta be *off*
> otherwise a screen grab could potentially figure out your nvram &
> hence decipher your passwords...
shoot, I thought we were gonna steganographisize the splash, never mind.
ron
Ronald G. Minnich
On Wed, 1 Dec 2004, Sergey Reva wrote:
> Hello 9fans,
>
> I heard many ideas in this thread, but I don't hear comment for my offer:
> RS> How about external FlashROM (24c01 - 128 bytes, 24c02 - 256 bytes
> RS> and 24c04 - 512 bytes) on LPT (or COM) port through i2c bus. It's
> RS> more easy and most standardised.
> I2C very easy bus and can be attached to LPT, COM or anything else
> (i2c controller integrated in system board). In this way you need:
> 1. 24c01(02, 03) IC (manufacturer Atmel or other)
> 2. 4 wires (SDA, SCL, plus, minus)
> 3. LPT connector
> 4. maybe 2-3 diodes
> 5. Cold head, hot heart and direct hands :-)
you want to do that 60 or 100 times? I don't. sorry.
> Disk emulation (CF-IDE and other), usbflash it's very $$$ way!
usbflash. Good idea.
> New idea: create special nvram driver with parameter setted while
> compilation. This is bad idea, this my opinion, but costless.
not a bad idea for some applications.
ron
Ronald G. Minnich
On Wed, 1 Dec 2004, Sergey Reva wrote:
> You mean, put 60-100 USB Flash Drive's with 128 Mb and use only 512
> bytes. Maybe I not understand something? I think if we have fs we don't
> need disk on other machines. And how about prices, it terrible (and multiple
> it to 60-100)?
flash drives are free. Really. They hand them out instead of pens now.
ron