[coreboot] [PATCH] Make RAM check configurable via Kconfig

Corey Osgood corey.osgood at gmail.com
Mon Mar 17 08:09:19 CET 2008


On Mon, Mar 17, 2008 at 12:43 AM, ron minnich <rminnich at gmail.com> wrote:

> On Sun, Mar 16, 2008 at 6:44 PM, Carl-Daniel Hailfinger
> <c-d.hailfinger.devel.2006 at gmx.net> wrote:
>
> >  Agreed, but at the same time, I'd like to keep this in the code as
> >  reference for future porters. Maybe have it depend on
> >  CONFIG_PARANOID_CHECKING or something like that?
> >  Or we simply comment it out once the board is running perfectly.
>
> We're spending a lot of time on this one :-)
>
> i can't debug without the memtest, but it is true that we don't need
> it once a board works.
>
> One conclusion I come away with, which you may all disagree with.
>
> #ifdef option is the wrong way to go. Options should always have a
> defined value. Why? So we can let C do its job, e.g.:
> if (CONFIG_THIS_THAT == 'y') {
>  whatever();
> }
>
> This code will be enabled or completely optimized out, and it's pretty
> clear what's up. And it looks more like C than:
> #ifdef CONFIG_THIS_THAT
>  whatever();
> #endif
>
> That's my main conclusion from this thread, but I'm not worried enough
> about it either way to argue the point too much.
>
> thanks
>
> ron


IMO, ram_check should be a lot more advanced and configurable then it
already is. I'd like to see it work something like this:

* configured via Kconfig. Builder has the option of running it all the time,
only if coreboot enters fallback, or if the memory size changes
* size of the ram is stored in cmos, for above. obviously there would need
to be some northbridge-specific function created to return the size of the
ram
* ram_check has two options, basic or advanced. basic would be the current
code, advanced would incorporate more tests, similar to memtest86's tests.
user gets the option of which test is run. possibly basic runs when the
memory size changes, advanced only runs in fallback.

The reasoning is that many problems, both with coreboot/BIOS and OS, can be
attributed to the memory. If we have a system for diagnosing memory errors
from coreboot, before we even attempt to use the potentially bad ram, we
have that small advantage over the factory BIOS. On embedded, this seems
like less of a concern, since the memory is usually soldered on and the user
never touches it, but on K8 desktop boards, combined with users ignorant to
ESD damage, this seems like it could be useful. If others want to see this,
I'll try to make it happen.

-Corey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080317/18f9069b/attachment.html>


More information about the coreboot mailing list