Do you really want to get rid of dynamically being able to set the FB size?
Well as we agreed? on IRC, I would like to have Kconfig settable default and the CMOS option as the most preferred state. Second reason is because as you pointed out the CMOS option does not work for M2V SE. Reason was that I never understood how it is supposed to be done. Third is I like to have a settable default in Kconfig.
Don't you think that this is a feature that regular users of probably the only fully implemented coreboot motherboards might actually want to touch?
Please don't take it as offense. I like the CMOS options but other stuff must be fixed here to make CMOS usable for M2V-MX.
Why is no time being spent on removing the other options that actually harm booting this device? Why does this feel like more pointless pedanticity?
It sounds you are really pissed off - please try no to look like exploded supernova ;) I completely agree with you that CMOS is right way. But it never worked here, so I changed it back - it was not evil intention and I would love to see the solution I written above. To have a Kconfig settable default and CMOS option which will be used if CMOS is valid. I think the code I wrote can be used for the CMOS option too, just simple change is needed.
Rudolf
---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
On Thu, Oct 29, 2009 at 10:15:07AM +0100, r.marek@assembler.cz wrote:
Do you really want to get rid of dynamically being able to set the FB size?
Well as we agreed? on IRC, I would like to have Kconfig settable default and the CMOS option as the most preferred state. Second reason is because as you pointed out the CMOS option does not work for M2V SE. Reason was that I never understood how it is supposed to be done. Third is I like to have a settable default in Kconfig.
I do not agree that kconfig is the way to go. Human nature will then make sure that cmos is treated further stepmotherly.
Don't you think that this is a feature that regular users of probably the only fully implemented coreboot motherboards might actually want to touch?
Please don't take it as offense. I like the CMOS options but other stuff must be fixed here to make CMOS usable for M2V-MX.
The cmos options work, but you need to clear the RTC before it can work properly on this board. There are some k8 options in there which should never become valid as they will stop the system from booting.
This is what needs to be fixed. Removing the need to touch cmos is not fixing things, it's avoiding things.
Why is no time being spent on removing the other options that actually harm booting this device? Why does this feel like more pointless pedanticity?
It sounds you are really pissed off - please try no to look like exploded supernova ;)
The reason is that i just got pestered with some hyperpedandicity on a whole wad of flashrom code, all because 1 tiny board enable was not deeemed acceptable straight away (and the user acked the original code, but now wandered on). Now i am quite sensitive.
Such hyperpedandicity stems progress as it: * tackles no real issues, even though plenty are around. * reduces the ability to get real issues tackled. Because patches do not get accepted, the real code in the patches gets ignored and issues with that code will eventually make it anyway, and those willing to do real work are not exactly encouraged.
I completely agree with you that CMOS is right way. But it never worked here, so I changed it back -
Why did cmos never work for you?
The videoram option for this board is absolutely golden. I have spent quite some time on verifying that.
I also had an issue with other hardware of the same family (CLE266) where i could only use the default value. Change the option and the thing would hang when sending some IDE stuff over the bus.
What i wanted then was the ability to be able to toggle the videoram_size option from the driver like such (quick pseudocode):
videoram_size = get_option("videoram_size") if (videoram_size != default) set_option("videoram_size", default);
This way, when i change the default in cmos, and the boot fails, it has changed the option in cmos already (or rather, invalidated cmos), so i am just a reset button away from it booting up normally.
Not useful for average joe user, but great for debugging.
I wasted quite a lot of time on being able to change videoram_size, and it is what holds back my sending in of native vga support on the epia-m.
I ended up moving to the Asus, as it was a very complete and very wellbehaved board, and i added the last big gap in this boards support with the native VGA code, complete with stable and acceptable videoram_size option.
This code works just fine, or you wouldn't even dream of setting up a kconfig option. Because the truth is, if you are able to set this through kconfig, then you're just as easily able to set this through cmos. But one means providing wanted functionality and means tackling real code, the other removes wanted functionality and means avoiding real code.
it was not evil intention and I would love to see the solution I written above.
I know that this is not evil intention, you were just following Uwes changes to other boards. And i know that uwe is not doing this with evil intent either, but that does not make the result less detrimental.
I really still have no idea as to why this is needed.
It seems like laziness in unifying cmos usage across more boards, and laziness in respect to fixing up existing cmos handling code. Compared to that, a KConfig option really is the easy way out.
To have a Kconfig settable default and CMOS option which will be used if CMOS is valid. I think the code I wrote can be used for the CMOS option too, just simple change is needed.
Rudolf
If there is one thing that users definitely want to be able to set as an option, then it is the amount of video ram that is being eaten by their IGP. Removing this ability is a no-go.
A KConfig option might seem nice, but it is is totally unnecessary. A sane default value _and_ a CMOS option is what is needed.
What will a KConfig option lead to: * developers will bother even less with cmos in future, leaving the crap that is in there for everyone to run into. * uwe then does not have to do the mental work to restore the cmos options for the other graphics chips. * users will think we're complete idiots, but we will never be told anyway, as it will be even more obvious that we are living in a world of our own.
Luc Verhaegen.
On 29.10.2009 14:16, Luc Verhaegen wrote:
On Thu, Oct 29, 2009 at 10:15:07AM +0100, r.marek@assembler.cz wrote:
Why is no time being spent on removing the other options that actually harm booting this device? Why does this feel like more pointless pedanticity?
It sounds you are really pissed off - please try no to look like exploded supernova ;)
The reason is that i just got pestered with some hyperpedandicity on a whole wad of flashrom code, all because 1 tiny board enable was not deeemed acceptable straight away (and the user acked the original code, but now wandered on). Now i am quite sensitive.
I wrote "I'd prefer a conversion to ich_gpio_raise instead.". This was not intended as NACK, but rather a nudge to reuse existing generic code. I'm very sorry if you felt offended.
I created a cake for you as an apology: http://imagebin.org/69634
Such hyperpedandicity stems progress as it:
- tackles no real issues, even though plenty are around.
- reduces the ability to get real issues tackled. Because patches do not get accepted, the real code in the patches gets ignored and issues with that code will eventually make it anyway, and those willing to do real work are not exactly encouraged.
Your last patch is a really great improvement over the old code in the tree. We now have real single-line board enables on ICH. Thanks a lot!
Regards, Carl-Daniel
-
Carl-Daniel Hailfinger -
Luc Verhaegen -
r.marek＠assembler.cz