I've just tried running lxbios on a gigabyte m57sli-s4 board that's running LinuxBIOS. This was the output:
# ./lxbios -y ../LinuxBIOSv2/src/mainboard/gigabyte/m57sli/cmos.layout -a boot_option = Fallback last_boot = Fallback ECC_memory = Disable baud_rate = 1200 hw_scrubber = Enable interleave_chip_selects = Enable max_mem_clock = 100Mhz dual_core = Disable power_on_after_fail = Disable # Bad value -> debug_level = 0xf # Bad value -> boot_first = 0x7 boot_second = Network # Bad value -> boot_third = 0x4 boot_index = 0xe boot_countdown = 0xfa # Bad value -> slow_cpu = 0xd nmi = Enable iommu = Enable lxbios: Can not read LinuxBIOS parameter user_data because layout info specifies CMOS area that is too wide. lxbios: Warning: LinuxBIOS CMOS checksum is bad.
As you can see there's an error at the bottom, and a bunch of 'bad value' warnings. I first tried without passing it the cmos layout file, and got the same result as above.
What am I doing wrong? This is lxbios 2.0.1.
Thanks, Ward.
* Ward Vandewege ward@gnu.org [070423 20:49]:
I've just tried running lxbios on a gigabyte m57sli-s4 board that's running LinuxBIOS. This was the output:
# ./lxbios -y ../LinuxBIOSv2/src/mainboard/gigabyte/m57sli/cmos.layout -a
You should not need to use -y here when running under linuxbios. it should read the cmos options from the lb table.
boot_option = Fallback last_boot = Fallback ECC_memory = Disable baud_rate = 1200
^^^^^^^^^^^^^^^^ ?
hw_scrubber = Enable interleave_chip_selects = Enable max_mem_clock = 100Mhz dual_core = Disable power_on_after_fail = Disable # Bad value -> debug_level = 0xf # Bad value -> boot_first = 0x7 boot_second = Network # Bad value -> boot_third = 0x4 boot_index = 0xe boot_countdown = 0xfa # Bad value -> slow_cpu = 0xd nmi = Enable iommu = Enable lxbios: Can not read LinuxBIOS parameter user_data because layout info specifies CMOS area that is too wide. lxbios: Warning: LinuxBIOS CMOS checksum is bad.
As you can see there's an error at the bottom, and a bunch of 'bad value' warnings. I first tried without passing it the cmos layout file, and got the same result as above.
Did you ever set the options to reasonable values? linuxbios does not to this by itself. 8)
What am I doing wrong? This is lxbios 2.0.1.
Stefan
On Mon, Apr 23, 2007 at 09:11:40PM +0200, Stefan Reinauer wrote:
Did you ever set the options to reasonable values? linuxbios does not to this by itself. 8)
I see :) So that's what I did wrong. How many of these values are actually used by linuxbios? For instance, I had baud_rate set to 1200 and dual_core was off; yet the system booted just fine with 115200 baud on serial, and I could see both cores on this dual-core cpu board.
I can't really seem to find any documentation about all the settings that are possible with lxbios; most seem straightforward enough, but is there something out there that describes each field?
Thanks, Ward.
boot_option = Fallback last_boot = Fallback ECC_memory = Disable baud_rate = 115200 hw_scrubber = Enable interleave_chip_selects = Enable max_mem_clock = 100Mhz dual_core = Enable power_on_after_fail = Enable debug_level = Spew boot_first = HDD boot_second = Network boot_third = Floppy boot_index = 0xe boot_countdown = 0xfa slow_cpu = off nmi = Enable iommu = Enable
* Ward Vandewege ward@gnu.org [070423 22:33]:
On Mon, Apr 23, 2007 at 09:11:40PM +0200, Stefan Reinauer wrote:
Did you ever set the options to reasonable values? linuxbios does not to this by itself. 8)
I see :) So that's what I did wrong. How many of these values are actually used by linuxbios? For instance, I had baud_rate set to 1200 and dual_core was off; yet the system booted just fine with 115200 baud on serial, and I could see both cores on this dual-core cpu board.
The checksum was wrong, so none of the values were used.
It's not you doing this wrong. I think linuxbios should in fact reset the extended linuxbios range in cmos to the values it has hardcoded as defaults from the cmos options file.
I can't really seem to find any documentation about all the settings that are possible with lxbios; most seem straightforward enough, but is there something out there that describes each field?
No. The wild thing is these settings may be different in each mainboard and many of them are there because of copy & paste.
boot_first = HDD boot_second = Network boot_third = Floppy boot_index = 0xe boot_countdown = 0xfa
I think these are used by some payload. Baremetal toolkit? Etherboot?
Stefan
On Mon, Apr 23, 2007 at 10:38:18PM +0200, Stefan Reinauer wrote:
The checksum was wrong, so none of the values were used.
Ah, that makes sense.
It's not you doing this wrong. I think linuxbios should in fact reset the extended linuxbios range in cmos to the values it has hardcoded as defaults from the cmos options file.
Right. That would be cool.
I can't really seem to find any documentation about all the settings that are possible with lxbios; most seem straightforward enough, but is there something out there that describes each field?
No. The wild thing is these settings may be different in each mainboard and many of them are there because of copy & paste.
I see! Hmmm, it would be a nice project to do some code analysis to find out which port uses which settings, and document that.
boot_first = HDD boot_second = Network boot_third = Floppy boot_index = 0xe boot_countdown = 0xfa
I think these are used by some payload. Baremetal toolkit? Etherboot?
But not FILO, I take it?
I've started a page on lxbios on the LB wiki to document this:
Thanks, Ward.
On 4/23/07, Ward Vandewege ward@gnu.org wrote:
boot_first = HDD boot_second = Network boot_third = Floppy boot_index = 0xe boot_countdown = 0xfa
believe it or not ... these values may well date back to the first linuxbios cluster lnxi delivered, Pink, ... I think I recognize them as settings for Etherboot!
thanks
ron
* Ward Vandewege ward@gnu.org [070423 22:53]:
No. The wild thing is these settings may be different in each mainboard and many of them are there because of copy & paste.
I see! Hmmm, it would be a nice project to do some code analysis to find out which port uses which settings, and document that.
Indeed!
boot_first = HDD boot_second = Network boot_third = Floppy boot_index = 0xe boot_countdown = 0xfa
I think these are used by some payload. Baremetal toolkit? Etherboot?
But not FILO, I take it?
No. I started a patch a while ago, but I never finished it.
I've started a page on lxbios on the LB wiki to document this:
Thank you very much!
On Mon, Apr 23, 2007 at 10:38:18PM +0200, Stefan Reinauer wrote:
No. The wild thing is these settings may be different in each mainboard and many of them are there because of copy & paste.
This is something we should handle centrally in v3 then.
//Peter
On 4/23/07, Peter Stuge stuge-linuxbios@cdy.org wrote:
On Mon, Apr 23, 2007 at 10:38:18PM +0200, Stefan Reinauer wrote:
No. The wild thing is these settings may be different in each mainboard and many of them are there because of copy & paste.
This is something we should handle centrally in v3 then.
in Kconfig, right? tha'ts what people would want to see, I think.
Optimally, in Kconfig, there is a "CMOS options settings" entry, then, for each setting, you see the name, the possible values, and the default values.
thanks
ron
On Mon, Apr 23, 2007 at 02:35:50PM -0700, ron minnich wrote:
On 4/23/07, Peter Stuge stuge-linuxbios@cdy.org wrote:
On Mon, Apr 23, 2007 at 10:38:18PM +0200, Stefan Reinauer wrote:
No. The wild thing is these settings may be different in each mainboard and many of them are there because of copy & paste.
This is something we should handle centrally in v3 then.
in Kconfig, right? tha'ts what people would want to see, I think.
Optimally, in Kconfig, there is a "CMOS options settings" entry, then, for each setting, you see the name, the possible values, and the default values.
That would be *awesome*.
Thanks, Ward.
OK, so: 1. cmos options should be defined in the DTS. I see a node with the name boot parameters or some such, and then in the node, there are nodes and properties, e..g
boot-parameters { console-baud { default=115200, choices={9600, 19200, etc.}} something=true (use of true or false defines this as a 1/0 choice) }
and so on, is this reasonable?
But we will need to have dts tree parsing happening as part of make config; is this ok too?
ron
On Mon, Apr 23, 2007 at 02:42:40PM -0700, ron minnich wrote:
OK, so:
- cmos options should be defined in the DTS. I see a node with the
name boot parameters or some such, and then in the node, there are nodes and properties, e..g
boot-parameters { console-baud { default=115200, choices={9600, 19200, etc.}} something=true (use of true or false defines this as a 1/0 choice) }
and so on, is this reasonable?
Yes!
But we will need to have dts tree parsing happening as part of make config; is this ok too?
I think so, it makes the obj-files-from-dts problem a lot simpler as well.
I don't know what would be most practical however;
* Generate Kconfig.dts * Teach Kconfig dts or dtb with hooks for select:ing based on dt[bs]
Perhaps start with generating includes..
//Peter
On Mon, Apr 23, 2007 at 11:49:00PM +0200, Peter Stuge wrote:
boot-parameters { console-baud { default=115200, choices={9600, 19200, etc.}} something=true (use of true or false defines this as a 1/0 choice) }
and so on, is this reasonable?
Yes!
But we will need to have dts tree parsing happening as part of make config; is this ok too?
I think so, it makes the obj-files-from-dts problem a lot simpler as well.
I don't know what would be most practical however;
- Generate Kconfig.dts
- Teach Kconfig dts or dtb with hooks for select:ing based on dt[bs]
Perhaps start with generating includes..
Yes, Kconfig.dts sounds like the better solution, IMHO.
But maybe we can even use Kconfig only for this? Do we need/want to stick that information in the dts? Why not put it into Kconfig files directly?
Uwe.
* Uwe Hermann uwe@hermann-uwe.de [070424 00:34]:
Yes, Kconfig.dts sounds like the better solution, IMHO.
But maybe we can even use Kconfig only for this? Do we need/want to stick that information in the dts? Why not put it into Kconfig files directly?
Ok, another alternative indeed.
Before we should decide the technical implementation, what do we want to achieve, what are our requirements to the system?
* configure cmos options defaults with make menuconfig
* have one single prominent place (per mainboard?) for those options?
* inherit options? Options per component? Like superio serial 0/1 on/off should be set in cmos instead of dts or compile time?
* simple format for describing the options
* have a tool that creates an "option_table" format file as we have it now, so we can easily use all the existing code for now (get_option(...), linuxbios table, lxbios utility....)
* what else...?
Stefan
Hi, I've thought hard about the "one single place" for V3 config, and I am thinking we will always have 2 files that define configuration, like it or not. There will always be some things in Kconfig, and some things in DTS. DTS describes, for the most part, data structures used at runtime. Kconfig, for the most part, defines how to build linuxbios. But in Kconfig there are a very small number of things related to runtime -- CMOS options being one of them, we hope, And in DTS there may be things related to how to build linuxbios (Although I can't think of one at present).
There is some small overlap. I think there always may be. We should work to minimize the overlap, but not go too crazy if we can't remove it all.
Just a meta-thought on the Kconfig vs. DTS discussion.
thanks
ron
* ron minnich rminnich@gmail.com [070424 00:50]:
Hi, I've thought hard about the "one single place" for V3 config, and I am thinking we will always have 2 files that define configuration, like it or not. There will always be some things in Kconfig, and some things in DTS. DTS describes, for the most part, data structures used at runtime.
... how does the machine look
Kconfig, for the most part, defines how to build linuxbios. But in Kconfig there are a very small number of things related to runtime
... configuration stuff. serial console? usb console? ... compile time options for those.
-- CMOS options being one of them, we hope, And in DTS there may be things related to how to build linuxbios (Although I can't think of one at present).
runtime configuration.
We basically have three now. We might marry options with options. But we should not try to marry hardware description and options. Even though we called it config in v2, it really is more than that.
There is some small overlap. I think there always may be. We should work to minimize the overlap, but not go too crazy if we can't remove it all.
In a perfect world, we would only have runtime configurable options
- because flashes would be big enough to hold all compile time options - because we could autodetect everything.
Just a meta-thought on the Kconfig vs. DTS discussion.
I completely agree. Overlap is less ugly when the concept is nice, and when we don't spaghetti it up to a max.
Those things are different information entities: 1) hw description 2) compile time config (image description) 3) run time settings (user environment "description")
We can mix those at will by making them a single file, or we can make three files, or two out of it. If we can unite any and things will become easier without dropping flexibility, that's great. But we need to be careful and choose the tools after we found a suitable set of requirements/features of why we are doing it. (Like, if we are never ever going to disable IOMMU, why add an option to do so, bad example[tm])
Stefan
On Tue, Apr 24, 2007 at 12:43:02AM +0200, Stefan Reinauer wrote:
- Uwe Hermann uwe@hermann-uwe.de [070424 00:34]:
Yes, Kconfig.dts sounds like the better solution, IMHO.
But maybe we can even use Kconfig only for this? Do we need/want to stick that information in the dts? Why not put it into Kconfig files directly?
Ok, another alternative indeed.
Before we should decide the technical implementation, what do we want to achieve, what are our requirements to the system?
- configure cmos options defaults with make menuconfig
Yes.
- have one single prominent place (per mainboard?) for those options?
One place: yes (Kconfig files, for example).
Parts of the settings will be generic, others may be mainboard-specific. But we can still make Kconfig stick them all in the same menu (from a user-perspective) is we want, so that's not a problem.
- inherit options? Options per component? Like superio serial 0/1 on/off should be set in cmos instead of dts or compile time?
Set a default at compile time, but allow overriding via CMOS settings.
Not sure what exactly inheriting and per-component options mean here.
- simple format for describing the options
Yes. AFAICS Kconfig can handle everything we have in cmos.layout files now: numbers, strings, multiple-selects (with a default value), etc. etc.
- have a tool that creates an "option_table" format file as we have it now, so we can easily use all the existing code for now (get_option(...), linuxbios table, lxbios utility....)
Hm, yes, probably. Needs some more investigations, maybe.
Uwe.
* Uwe Hermann uwe@hermann-uwe.de [070424 21:46]:
- have one single prominent place (per mainboard?) for those options?
One place: yes (Kconfig files, for example).
Parts of the settings will be generic, others may be mainboard-specific. But we can still make Kconfig stick them all in the same menu (from a user-perspective) is we want, so that's not a problem.
"One place" is ambiguous. We might prefer all options for a board in one single file, instead of spreading it between lots of Kconfig files.
One method, for sure. But that's what we have already
- inherit options? Options per component? Like superio serial 0/1 on/off should be set in cmos instead of dts or compile time?
Set a default at compile time, but allow overriding via CMOS settings.
Ok, say we add this stuff to Kconfig. How do we get it out of kconfig again, ie. how do we know which Kconfig options are runtime changeable (I hate the word CMOS) options
Not sure what exactly inheriting and per-component options mean here.
per component means: you use a FooBar superio. This allows you to enable/disable serial port 2 at runtime, and at compile time.
inheriting means: where do we get the initial defaults from? If we have per-component settings, the dts is the wrong place for defaults.
- simple format for describing the options
Yes. AFAICS Kconfig can handle everything we have in cmos.layout files now: numbers, strings, multiple-selects (with a default value), etc. etc.
Ok. So each mainboard gets a file Kconfig.options ?
Or will we rather start putting that to northbridge/, southbridge/ and superio/ and try to keep the mainboard/ directory clean per default?
How do you plan to generate a "map" from a Kconfig file, so LinuxBIOS will know where each option sits in the nvram?
- have a tool that creates an "option_table" format file as we have it now, so we can easily use all the existing code for now (get_option(...), linuxbios table, lxbios utility....)
Hm, yes, probably. Needs some more investigations, maybe.
For instance?
* ron minnich rminnich@gmail.com [070423 23:42]:
- cmos options should be defined in the DTS. I see a node with the
name boot parameters or some such, and then in the node, there are nodes and properties, e..g
boot-parameters { console-baud { default=115200, choices={9600, 19200, etc.}} something=true (use of true or false defines this as a 1/0 choice) }
How is this an improvement over the cmos config files we have now? (I do like the file format better, but thats not an issue of putting it into the dts.)
But we will need to have dts tree parsing happening as part of make config; is this ok too?
Dont we have this already?
On 4/23/07, Stefan Reinauer stepan@coresystems.de wrote:
- ron minnich rminnich@gmail.com [070423 23:42]:
- cmos options should be defined in the DTS. I see a node with the
name boot parameters or some such, and then in the node, there are nodes and properties, e..g
boot-parameters { console-baud { default=115200, choices={9600, 19200, etc.}} something=true (use of true or false defines this as a 1/0 choice) }
How is this an improvement over the cmos config files we have now? (I do like the file format better, but thats not an issue of putting it into the dts.)
I have always, personally, had trouble reading those files. I just don't find them to be easily comprehended. I think this new format is more readable. That said, there's no reason, as a first step, not to put the current format into dts ...
But we will need to have dts tree parsing happening as part of make config; is this ok too?
Dont we have this already?
oh, maybe we do; we run dtc when we do make config?
thanks ron
* ron minnich rminnich@gmail.com [070424 00:15]:
boot-parameters { console-baud { default=115200, choices={9600, 19200, etc.}} something=true (use of true or false defines this as a 1/0 choice) }
I do like this format!
I have always, personally, had trouble reading those files. I just don't find them to be easily comprehended. I think this new format is more readable.
fully agreed.
That said, there's no reason, as a first step, not to put the current format into dts ...
As a first step? Does it logically belong into the dts?
Is so, lets put it there. If not, it is easy to change the current option utility to read the new format instead.
But we will need to have dts tree parsing happening as part of make config; is this ok too?
Dont we have this already?
oh, maybe we do; we run dtc when we do make config?
ah d'uh. no. We run it during make. hitch in my head :)
On Mon, Apr 23, 2007 at 02:35:50PM -0700, ron minnich wrote:
On 4/23/07, Peter Stuge stuge-linuxbios@cdy.org wrote:
On Mon, Apr 23, 2007 at 10:38:18PM +0200, Stefan Reinauer wrote:
No. The wild thing is these settings may be different in each mainboard and many of them are there because of copy & paste.
This is something we should handle centrally in v3 then.
in Kconfig, right? tha'ts what people would want to see, I think.
Cool! Yes, setting the defaults that are stored in flash in Kconfig would be very nice.
I was thinking more about code reuse though, and that we want to have the code for any one procedure only in one place. (Better abstraction I guess.)
Optimally, in Kconfig, there is a "CMOS options settings" entry, then, for each setting, you see the name, the possible values, and the default values.
Yes, awesome!
//Peter
* Peter Stuge stuge-linuxbios@cdy.org [070423 23:44]:
This is something we should handle centrally in v3 then.
in Kconfig, right? tha'ts what people would want to see, I think.
Cool! Yes, setting the defaults that are stored in flash in Kconfig would be very nice.
I was thinking more about code reuse though, and that we want to have the code for any one procedure only in one place. (Better abstraction I guess.)
I like this approach! How/Where?
-
Peter Stuge -
ron minnich -
Stefan Reinauer -
Uwe Hermann -
Ward Vandewege