On Fri, 12 Sep 2008 15:37:41 +0200, Stefan Reinauer stepan@coresystems.de wrote:
I think this might be even better...
writing to drives from firmware might be a bad idea,
Why? Even if it is simple text file?
though... can this be done with cmos bits?
Not sure....you would have basicly convert a kernel command line into hex and store it in cmos???
This is why I asked you if it was possible to have a small read/write area in flash possibly at the end of the payload.
An interesting thing would also be to parse syslinux config files and put them in the grub menu.. these are used on basically all linux install cds/dvds..
Yeh I like this idea for read only media. I hope you don't mind if I forward this to the list for more opinions.
On Fri, Sep 12, 2008 at 10:15 AM, Joseph Smith joe@settoplinux.org wrote:
On Fri, 12 Sep 2008 15:37:41 +0200, Stefan Reinauer stepan@coresystems.de wrote:
I think this might be even better...
writing to drives from firmware might be a bad idea,
Why? Even if it is simple text file?
yes. It's very worrisome to people. I did my little bios virus for DOE and people were somewhat unhappy to learn how easy it is :-) It's never possible to put the words simple and file and write in the same sentence :-)
thanks
ron
On Fri, 12 Sep 2008 11:40:09 -0700, "ron minnich" rminnich@gmail.com wrote:
On Fri, Sep 12, 2008 at 10:15 AM, Joseph Smith joe@settoplinux.org
wrote:
On Fri, 12 Sep 2008 15:37:41 +0200, Stefan Reinauer
wrote:
I think this might be even better...
writing to drives from firmware might be a bad idea,
Why? Even if it is simple text file?
yes. It's very worrisome to people. I did my little bios virus for DOE and people were somewhat unhappy to learn how easy it is :-) It's never possible to put the words simple and file and write in the same sentence :-)
Maybe so for a virus. But when it allows an end user to have a completely configurable boot loader... I wish I knew a way to allocate a small read/write space at the end of the payload space (flash) (10k would be plenty), it would make the process painless and seamless...
On Fri, Sep 12, 2008 at 12:45 PM, Joseph Smith joe@settoplinux.org wrote:
Maybe so for a virus. But when it allows an end user to have a completely configurable boot loader...
If people want it I guess. But we computer people need to be more careful about opening holes to provide features. Just look at the state of the internet for a reason why....
ron
On Fri, 12 Sep 2008 12:46:57 -0700, "ron minnich" rminnich@gmail.com wrote:
On Fri, Sep 12, 2008 at 12:45 PM, Joseph Smith joe@settoplinux.org
wrote:
Maybe so for a virus. But when it allows an end user to have a
completely
configurable boot loader...
If people want it I guess. But we computer people need to be more careful about opening holes to provide features. Just look at the state of the internet for a reason why....
true. Well, how about this then. Instead of FILO writing the file we could just provide a generic filo.conf. The first time the user boots up they will have to manually boot. Once they are in Linux they can just copy the filo.conf to their first drive, first partion, root directory. Ahh, but that will still defeat the purpose, because it will still not be configurable from FILO at bootup, just read only... huh, my brain is starting to hurt.
On 12/09/08 15:55 -0400, Joseph Smith wrote:
On Fri, 12 Sep 2008 12:46:57 -0700, "ron minnich" rminnich@gmail.com wrote:
On Fri, Sep 12, 2008 at 12:45 PM, Joseph Smith joe@settoplinux.org
wrote:
Maybe so for a virus. But when it allows an end user to have a
completely
configurable boot loader...
If people want it I guess. But we computer people need to be more careful about opening holes to provide features. Just look at the state of the internet for a reason why....
true. Well, how about this then. Instead of FILO writing the file we could just provide a generic filo.conf. The first time the user boots up they will have to manually boot. Once they are in Linux they can just copy the filo.conf to their first drive, first partion, root directory. Ahh, but that will still defeat the purpose, because it will still not be configurable from FILO at bootup, just read only... huh, my brain is starting to hurt.
What specific use case are you trying to solve here? Under what circumstances would you prefer to write your configuration file from within the ROM and not from within the kernel or through some installation process?
Jordan
On Fri, 12 Sep 2008 14:05:50 -0600, Jordan Crouse jordan.crouse@amd.com wrote:
On 12/09/08 15:55 -0400, Joseph Smith wrote:
On Fri, 12 Sep 2008 12:46:57 -0700, "ron minnich" rminnich@gmail.com wrote:
On Fri, Sep 12, 2008 at 12:45 PM, Joseph Smith joe@settoplinux.org
wrote:
Maybe so for a virus. But when it allows an end user to have a
completely
configurable boot loader...
If people want it I guess. But we computer people need to be more careful about opening holes to provide features. Just look at the state of the internet for a reason why....
true. Well, how about this then. Instead of FILO writing the file we could
just
provide a generic filo.conf. The first time the user boots up they will have to manually boot. Once they are in Linux they can just copy the filo.conf to their first drive, first partion, root directory. Ahh, but that will still defeat the purpose, because it will still not be configurable from FILO at bootup, just read only... huh, my brain is starting to hurt.
What specific use case are you trying to solve here? Under what circumstances would you prefer to write your configuration file from within the ROM and not from within the kernel or through some
installation
process?
I'm trying to figure out a way to have a end user configurable kernel command line (and possibly give the ability for the end user to change some FILO settings) and have the ability to save them.
On Fri, 12 Sep 2008 16:28:53 -0400, Joseph Smith joe@settoplinux.org wrote:
On Fri, 12 Sep 2008 14:05:50 -0600, Jordan Crouse jordan.crouse@amd.com wrote:
On 12/09/08 15:55 -0400, Joseph Smith wrote:
On Fri, 12 Sep 2008 12:46:57 -0700, "ron minnich" rminnich@gmail.com wrote:
On Fri, Sep 12, 2008 at 12:45 PM, Joseph Smith joe@settoplinux.org
wrote:
Maybe so for a virus. But when it allows an end user to have a
completely
configurable boot loader...
If people want it I guess. But we computer people need to be more careful about opening holes to provide features. Just look at the state of the internet for a reason why....
true. Well, how about this then. Instead of FILO writing the file we could
just
provide a generic filo.conf. The first time the user boots up they will have to manually boot. Once they are in Linux they can just copy the filo.conf to their first drive, first partion, root directory. Ahh, but that will still defeat the purpose, because it will still not be configurable from FILO at bootup, just read only... huh, my brain is starting to hurt.
What specific use case are you trying to solve here? Under what circumstances would you prefer to write your configuration file from within the ROM and not from within the kernel or through some
installation
process?
I'm trying to figure out a way to have a end user configurable kernel command line (and possibly give the ability for the end user to change some FILO settings) and have the ability to save them.
Is there any way to fit a tiny ASKII to hex converter into FILO? And setup a writeable table?
Hmm, maybe I stumbled onto something. But I need figure out how it works. Can someone explain to me how it works when you password protect a normal bios? Where and how does the ASCII text get saved. You guys may or may not know where I am going with this but I have an idea if I can figure this out. If a normal bios can save a password (ASCII text) than why couldn't FILO save a kernel command line (ASCII text)?
Joseph Smith schrieb:
Hmm, maybe I stumbled onto something. But I need figure out how it works. Can someone explain to me how it works when you password protect a normal bios? Where and how does the ASCII text get saved. You guys may or may not know where I am going with this but I have an idea if I can figure this out. If a normal bios can save a password (ASCII text) than why couldn't FILO save a kernel command line (ASCII text)?
I think, they store one or two bytes of hash value in CMOS
Regards, Patrick Georgi
Joseph Smith wrote:
Hmm, maybe I stumbled onto something. But I need figure out how it works. Can someone explain to me how it works when you password protect a normal bios? Where and how does the ASCII text get saved. You guys may or may not know where I am going with this but I have an idea if I can figure this out. If a normal bios can save a password (ASCII text) than why couldn't FILO save a kernel command line (ASCII text)?
The BIOS paasword is saved in CMOS/NVRAM. and yes, filo can. you have almost 256 bytes
On Sat, 13 Sep 2008 10:50:53 +0200, Stefan Reinauer stepan@coresystems.de wrote:
Joseph Smith wrote:
Hmm, maybe I stumbled onto something. But I need figure out how it
works.
Can someone explain to me how it works when you password protect a
normal
bios? Where and how does the ASCII text get saved. You guys may or may
not
know where I am going with this but I have an idea if I can figure this out. If a normal bios can save a password (ASCII text) than why couldn't FILO save a kernel command line (ASCII text)?
The BIOS paasword is saved in CMOS/NVRAM. and yes, filo can. you have almost 256 bytes
Ok, now were getting somewhere. This area is also used for the coreboot CMOS/NVRAM table correct? What is the maximum bytes the coreboot CMOS/NVRAM table uses? And how many bites could we allocate for FILO to use?
Joseph Smith wrote:
Ok, now were getting somewhere. This area is also used for the coreboot CMOS/NVRAM table correct? What is the maximum bytes the coreboot CMOS/NVRAM table uses? And how many bites could we allocate for FILO to use?
Some of the space is reserved for the coreboot normal/fallback mechanism and some for the real time clock.
See your mainboard's cmos.layout. Most of the stuff is copied from other boards and can be removed.
On Sat, 13 Sep 2008 14:20:22 +0200, Stefan Reinauer stepan@coresystems.de wrote:
Joseph Smith wrote:
Ok, now were getting somewhere. This area is also used for the coreboot CMOS/NVRAM table correct? What is the maximum bytes the coreboot
CMOS/NVRAM
table uses? And how many bites could we allocate for FILO to use?
Some of the space is reserved for the coreboot normal/fallback mechanism and some for the real time clock.
See your mainboard's cmos.layout. Most of the stuff is copied from other boards and can be removed.
Great so far the requirements I'm thinking include:
a byte for the boot method: 0 - firstboot or CMOS cleared(default) 1 - Manual Boot 2 - Command Line boot 3 - filo.conf boot
a byte for auto boot time out specified in seconds
and the rest for ASCII text which would include one of two things:
a kernel command line
or
a pointer to filo.conf on the hard drive
What do you think?
Here's another thought. Why not setup a small jffs2 filesystem in flash to host filo.conf?
Joseph Smith wrote:
a byte for the boot method: 0 - firstboot or CMOS cleared(default) 1 - Manual Boot 2 - Command Line boot 3 - filo.conf boot
a byte for auto boot time out specified in seconds
and the rest for ASCII text which would include one of two things:
a kernel command line
Discussion on IRC seems to suggest that there are a couple of problems with this approach: 1. Size of the commandline. Linux allows for an unlimited command-line length. 2. Sharing among payloads. If, say, 128 bytes were allocated for this for FILO, that's 128 bytes less available to other payloads. (Anyone else who was involved with the discussion, feel free to add some if I missed them)
This is not to say that I agree with the severity of the problems. For the first, I think it's fine if coreboot imposes its own limit on the length of the commandline. The second one, I can't really argue with though. (except to say that it doesn't affect me; it'd be fine with me if filo's kernel commandline were to be overwritten by the gPXE's configuration or something.)
a pointer to filo.conf on the hard drive
For this one, it would (IMO) be sufficient to hard-code the configuration file location minus the drive itself, and then use a byte of CMOS to store which drive it's on. We could use the following values: 0x80 = first drive, 0x81= second drive ... Just (semi-) kidding on the values. Perhaps 0x61 (ASCII 'a') = filo hda:, 0x62 = filo hdb:, etc. would be more palatable though...or just 0x1, 0x2, etc for simplicity.
That then takes us to the question of how to consistently number the drives, but I'll leave that one alone for now and just say that when the first drive on my system shows up as hde:, that's *not* expected. :-D
Stefan also made mention of the possibility of using flashrom and allocating a portion of the main flash for kernel command lines and filo.conf locations.
-Alex Mauer "hawke"
On 15.09.2008 20:42, Alex Mauer wrote:
Stefan also made mention of the possibility of using flashrom and allocating a portion of the main flash for kernel command lines and filo.conf locations.
Some legacy BIOSes seem to use that method. Stuffing a complete flashrom binary there would be overkill, though.
Regards, Carl-Daniel
Carl-Daniel Hailfinger wrote:
Some legacy BIOSes seem to use that method. Stuffing a complete flashrom binary there would be overkill, though.
He was talking about turning flashrom into a library. I guess you'd have to ask him about the details though.
-Alex Mauer "hawke"
-
Alex Mauer -
Carl-Daniel Hailfinger -
Jordan Crouse -
Joseph Smith -
Patrick Georgi -
ron minnich -
Stefan Reinauer