[coreboot] [PATCH] consolidate K8M890 VGA code
libv at skynet.be
Thu Oct 29 14:16:56 CET 2009
On Thu, Oct 29, 2009 at 10:15:07AM +0100, r.marek at 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
> how it is supposed to be done. Third is I like to have a settable default in
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
> 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)
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
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
> it was not evil intention and I would
> 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.
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.
More information about the coreboot