-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi all,
Is there someone who is actively using most of the CMOS options? For example I just know that Luc is using at least the VRAM size. I think he mentioned that on M2V-MX SE memory init options are too dangerous and board won't boot anymore if set wrong - maybe even after cmos clear?
I noticed that century byte is happily ignored - need to check if it really collides.
Question is what to do with that. Maybe it would be useful if someone could do some payload aka "setup" screen to change those options. Maybe it would make sense to get rid of most and have there only which are really used.
What do you think?
Rudolf
Am 08.12.2009 23:01, schrieb Rudolf Marek:
Is there someone who is actively using most of the CMOS options? For example I just know that Luc is using at least the VRAM size. I think he mentioned that on M2V-MX SE memory init options are too dangerous and board won't boot anymore if set wrong - maybe even after cmos clear?
What we definitely need is a recovery procedure.
Right now, on many boards coreboot looks if CMOS is valid (by using the checksum), and jumps to normal which uses CMOS or stays in fallback which uses hardcoded values. That fails if the validation routine fails (happened for me a couple of times), and isn't too nice to handle - basically two copies of the entire code just to switch between two sets of values (CMOS or hardcode).
It might be sufficient to keep a static array around with a valid preset of CMOS values (the cmos.layout format would have to be extended to store defaults for that), and just overwrite CMOS if it's found to be invalid - it's a bit harsh, but well, it's something that works (all PCBIOSes do it like that), and it works better than what we have, in my opinion.
If we figure out a better way to handle it later (indirect access to CMOS via accessors that can be retargeted to accessing said static array or whatever), all the better. The hard part in this idea is that these accessor functions would need to be global variables of some sort.
Question is what to do with that. Maybe it would be useful if someone could do some payload aka "setup" screen to change those options. Maybe it would make sense to get rid of most and have there only which are really used.
Basically, an nvramtool with frontend and as payload. Sounds good :-)
While we're talking about CMOS options, there was some talk about adding some include statement to cmos.layout, so components could add their flags and config variables. I don't think that there was some good proposal about how to do it. The issue is that variables should stay in their place, even if some component gains or loses some flags.
Patrick
Patrick Georgi wrote:
It might be sufficient to keep a static array around with a valid preset of CMOS values (the cmos.layout format would have to be extended to store defaults for that), and just overwrite CMOS if it's found to be invalid
I think this is too violent as a general solution.
When first testing coreboot on a board, it will trample all over the existing bytes in NVRAM. A more gentle approach there is definately on my wishlist.
However, when evaluation has finished and the board will be running coreboot exclusively - never the factory BIOS again - I agree that it is a good thing for coreboot to be a bit agressive with NVRAM contents, since it helps reliability.
I don't think a single solution works for both evaluation and production behaviors. Since the latter will be destructive I think it should be explicitly chosen by user. Kconfig seems like the place.
coreboot-eval basically should not rely on NVRAM at all. That means sane values for all settings must be stored somewhere else, and be accessible. It also means slightly less functionality, but I think that is quite acceptable as long as it does not alter the board.
- it's a bit harsh, but well, it's something that works (all
PCBIOSes do it like that), and it works better than what we have, in my opinion.
I don't know if I've seen a BIOS which will overwrite NVRAM without user confirmation. I think it's a problem that coreboot always does this.
If we figure out a better way to handle it later (indirect access to CMOS via accessors that can be retargeted to accessing said static array or whatever), all the better. The hard part in this idea is that these accessor functions would need to be global variables of some sort.
Hm, the option name->number translation is done at build time now, right?
Maybe it would be useful if someone could do some payload aka "setup" screen to change those options. Maybe it would make sense to get rid of most and have there only which are really used.
Basically, an nvramtool with frontend and as payload. Sounds good :-)
Yes, I like both ideas.
While we're talking about CMOS options, there was some talk about adding some include statement to cmos.layout, so components could add their flags and config variables. I don't think that there was some good proposal about how to do it. The issue is that variables should stay in their place, even if some component gains or loses some flags.
Maybe a preprocessing stage (cat?) with a bit of validation.
Rather than trying to go from completely static to completely generic at once I think it might be better to split NVRAM into one part with options that are common for all boards and defined in one single place, and another part with board-local options defined per board.
That will still require careful selection of where to put an option, but I think it would be very helpful to have such a divide since the point is that in the minimal case a new board port does not need any explicit options at all. (This is the big point.)
The few number of bytes make it annoying to create a generic solution without sacrificing too much space, some kind of compromise will be much easier to implement yet still bring most if not all of the benefit.
//Peter
Peter Stuge wrote:
Patrick Georgi wrote:
It might be sufficient to keep a static array around with a valid preset of CMOS values (the cmos.layout format would have to be extended to store defaults for that), and just overwrite CMOS if it's found to be invalid
I think this is too violent as a general solution.
As a general solution it is exactly what you want.
When first testing coreboot on a board, it will trample all over the existing bytes in NVRAM. A more gentle approach there is definately on my wishlist.
In this specific case I can see a more gentle approach may be slightly more desirable. Using an emulated CMOS device rather than the real hardware could be an option if there is sufficient isolation in the interface. But on the whole I don't see a problem with overwriting CMOS.
- it's a bit harsh, but well, it's something that works (all
PCBIOSes do it like that), and it works better than what we have, in my opinion.
I don't know if I've seen a BIOS which will overwrite NVRAM without user confirmation. I think it's a problem that coreboot always does this.
AFAIK all BIOSes will load defaults on detection of invalid checksums with no user confirmation. On Phoenix a CMOS checksum error is only a warning, you may not even notice it had happened. By the time you see a prompt about entering Setup or continue, defaults were loaded long ago. The BIOS owns the machine, it has no interest in preserving corrupt CMOS contents.
Andrew
Rudolf Marek wrote:
Hi all,
Is there someone who is actively using most of the CMOS options? For example I just know that Luc is using at least the VRAM size. I think he mentioned that on M2V-MX SE memory init options are too dangerous and board won't boot anymore if set wrong - maybe even after cmos clear?
I am using all CMOS options on Kontron 986LCD-M. Actually, if options are not supposed to be used, they should be dropped. Many boards have options that make no sense because people love copy and paste for that stuff. The only time CMOS options cause an error is when you use an option in auto.c phase and it's not in cmos.layout. No error in stage 2 and no error when you leave unused options in.
CMOS clear does not happen at all, or correctly. It should write CMOS to a defined state of default values. right now we don't even define default values in the CMOS table but only in the code where the values are actually used. This can lead to troublesome situations.
I noticed that century byte is happily ignored - need to check if it really collides.
Is that good for anything? Does the BIOS need to care? I thought hwclock --sys-to-hc does that ;-)
Question is what to do with that. Maybe it would be useful if someone could do some payload aka "setup" screen to change those options.
Have a look at the nvramtool in util/ ... it provides a setup screen with ssh and support and you can even choose to have X11 running with animations next to it.
Maybe it would make sense to get rid of most and have there only which are really used.
Yes. We should eliminate dead code.
Stefan
Stefan Reinauer wrote:
Many boards have options that make no sense because people love copy and paste for that stuff.
No, but because people do not understand how it works and what is required to get a board running.
//Peter
On 12/9/09 8:34 AM, Peter Stuge wrote:
Stefan Reinauer wrote:
Many boards have options that make no sense because people love copy and paste for that stuff.
No, but because people do not understand how it works and what is required to get a board running.
What makes you think so? Where do you see the parts that are hard to understand?
Stefan
Stefan Reinauer wrote:
Many boards have options that make no sense because people love copy and paste for that stuff.
No, but because people do not understand how it works and what is required to get a board running.
What makes you think so?
It's how I see the options. :) If I would be making a new port now I would not immediately care about the options, and possibly would never get around to it.
But if I start working with an existing board then the options will be there, and I would have to actually learn how to get rid of them. I would have other things to do.
Where do you see the parts that are hard to understand?
The old build system in general is really difficult to penetrate. I'm very glad that we're getting Kconfig going! It's just not worth the effort to learn how to clean out surplus options from a new board, Kconfig reduces the effort a bit, and I think it helps even more to make the options space becomes a little more structured than just all or nothing.
//Peter
Stefan Reinauer wrote:
I noticed that century byte is happily ignored - need to check if it really collides.
Is that good for anything? Does the BIOS need to care? I thought hwclock --sys-to-hc does that ;-)
Some implementations of the RTC will auto increment the century byte on a century roll over. I know we are past Y2K so this is unlikely to produce a bug in practice but there is the possibility for an unexpected change in the contents if that position is used for any other purpose. It is a 'well known' position and can be read/written by an OS.
Andrew
On Tue, Dec 08, 2009 at 11:01:43PM +0100, Rudolf Marek wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi all,
Is there someone who is actively using most of the CMOS options? For example I just know that Luc is using at least the VRAM size. I think he mentioned that on M2V-MX SE memory init options are too dangerous and board won't boot anymore if set wrong - maybe even after cmos clear?
I noticed that century byte is happily ignored - need to check if it really collides.
Question is what to do with that. Maybe it would be useful if someone could do some payload aka "setup" screen to change those options. Maybe it would make sense to get rid of most and have there only which are really used.
What do you think?
Rudolf
On m2v mx se, if you set Videoram, then the cmos checksum becomes valid, no matter what bullshit is in the rest of cmos. Then amd k8 init fails, because some of the options on the m2v mx se influence the k8 lethally..
Options which are there for development purposes are ok, but for a board as well implemented as the m2v-mx they should no longer be necessary. As stepan said: people copy paste cluelessly.
Last time i posted a patch, and then only after it was commited did it became clear that a "string" is reserved for the seabios/filo at least on the kontron board, making the patch invalid.
People spent time discussing a fantastic great future far far away, requiring a copy of flashrom to be available and everything, but no-one involved in that discussion bothered to review the patch properly, and the only Acker did so from the best of his knowledge (and the patch really was sane, just the requirements were wrong).
This bootloader option stuff needs to be done differently. Why not just reserve the top 64bytes or so for the bootloader?
Then, coreboot board info should be stored in a few bytes too, together with a version number carried in the cmos.options file, bumped as it changes. Option retrieval should check * checksum valid. * board valid. * version valid before it accepts any cmos options.
On top of that, cmos.options needs to have a way to specify defaults. We need defaults. If any of the above checks fail when running nvramtool, the tool should ask whether the defaults should be written in, if not, the checksum should not be validated (which should be able to be forcibly overwritten).
And nvram tool also needs to be able to work with the space reserved for the bootloader, so the common bootloaders better get reserved space structured too.
All of this is a lot of work, but all a lot more useful than doing even more work on a pipedream.
We have 892 bytes to our disposal in cmos. We can reserve 128 for board/cmos versioning, and reserve even 256 for the bootloader, and still have 512bytes left for coreboot options, which is tons when bits are used properly and when strings are not used.
CMOS is there, and it is easy to access and alter, all it needs is structure and properly implemented infrastructure.
Luc Verhaegen.
Luc Verhaegen wrote:
We have 892 bytes to our disposal in cmos. We can reserve 128 for board/cmos versioning, and reserve even 256 for the bootloader, and still have 512bytes left for coreboot options, which is tons when bits are used properly and when strings are not used.
Most boards I have used have a maximum space of 256 bytes that includes the RTC. Where does the extra come from?
Andrew
On Wed, Dec 9, 2009 at 2:57 AM, Andrew Goodbody andrew.goodbody@tadpole.com wrote:
Luc Verhaegen wrote:
We have 892 bytes to our disposal in cmos. We can reserve 128 for board/cmos versioning, and reserve even 256 for the bootloader, and still have 512bytes left for coreboot options, which is tons when bits are used properly and when strings are not used.
Most boards I have used have a maximum space of 256 bytes that includes the RTC. Where does the extra come from?
On much of my hardware, the most I can assume is 128 bytes - subtracting many bytes that are weirdly hardware controlled (such as date).
Some of our hardware has 256 bytes.
The io ports only support an 8-bit address I thought?
That said, if newer parts really do have so much data, that is great news.
ron
On 12/11/09 8:39 PM, ron minnich wrote:
On Wed, Dec 9, 2009 at 2:57 AM, Andrew Goodbody andrew.goodbody@tadpole.com wrote:
Luc Verhaegen wrote:
We have 892 bytes to our disposal in cmos. We can reserve 128 for board/cmos versioning, and reserve even 256 for the bootloader, and still have 512bytes left for coreboot options, which is tons when bits are used properly and when strings are not used.
Most boards I have used have a maximum space of 256 bytes that includes the RTC. Where does the extra come from?
On much of my hardware, the most I can assume is 128 bytes - subtracting many bytes that are weirdly hardware controlled (such as date).
Some of our hardware has 256 bytes.
The io ports only support an 8-bit address I thought?
The ports 0x70/0x71 even only support 7 bits... The 8th bit is used for NMI control.
Higher CMOS bytes can be accessed by 0x72/0x73, 0x74/0x75....
However, if you try to access the upper 128 bytes by setting the topmost bit in 0x70 it will just look like the upper 128 byte are a mirror of the lower 128 bytes.
Stefan
On Sat, Dec 12, 2009 at 02:30:01PM +0100, Stefan Reinauer wrote:
On 12/11/09 8:39 PM, ron minnich wrote:
On Wed, Dec 9, 2009 at 2:57 AM, Andrew Goodbody andrew.goodbody@tadpole.com wrote:
Luc Verhaegen wrote:
We have 892 bytes to our disposal in cmos. We can reserve 128 for board/cmos versioning, and reserve even 256 for the bootloader, and still have 512bytes left for coreboot options, which is tons when bits are used properly and when strings are not used.
Most boards I have used have a maximum space of 256 bytes that includes the RTC. Where does the extra come from?
On much of my hardware, the most I can assume is 128 bytes - subtracting many bytes that are weirdly hardware controlled (such as date).
Some of our hardware has 256 bytes.
The io ports only support an 8-bit address I thought?
The ports 0x70/0x71 even only support 7 bits... The 8th bit is used for NMI control.
Higher CMOS bytes can be accessed by 0x72/0x73, 0x74/0x75....
However, if you try to access the upper 128 bytes by setting the topmost bit in 0x70 it will just look like the upper 128 byte are a mirror of the lower 128 bytes.
Stefan
Ah, my bad, i guess 1024 bits is why my synapses brought up that figure.
Still, it should still be possible to segment this up nicely, and then we suddenly do have a lot of space for bools, sets and integers. And maybe a string or two to denote the board.
Luc Verhaegen
-
Andrew Goodbody -
Luc Verhaegen -
Patrick Georgi -
Peter Stuge -
ron minnich -
Rudolf Marek -
Stefan Reinauer