[coreboot] BadRAM generic support in CoreBoot?

[Robert Millan]

On Sun, Sep 28, 2008 at 10:51:43PM +0000, Rick van Rein wrote:
> Hello,
> 
> Years ago, I developed a BadRAM patch that enabled Linux to run in spite
> of broken memory chips.  I am now contemplating making it go into coreboot.

Hi,

This is a very nice idea.  I hope the coreboot maintainers will find it
suitable too :-)

> After browsing through the coreboot code, it seems that the best approach
> to follow would be to call lb_remove_memory_range() on ranges that are
> faulty, after having included all the memory on each DIMM.  CoreBoot
> would then deliver a memory map with more regions than in a usual setup.
> For example, if one row is marked bad, and it consists of 4096 columns,
> there may be as many as 4096 ranges marked bad.  This would make the
> memory map expand -- but in a payload-compatible manner.

Note that there are two interfaces for exporting a memory map, one is the
native coreboot table interface (write_coreboot_table()) and the other is
Multiboot (write_multiboot_info).  Please make sure your code supports both.

(That's for v3.  In v2, Multiboot is not merged yet, but I expect it will
be soon)

> I am not sure how the memory map is used after booting...
> - does the memory map feed the e820 bios call (through openbios, say)?

Yes (with SeaBIOS or ADLO, that is, but openbios has an equivalent interface).
Though you don't have to worry about this;  all these stages get the info
from coreboot through the interfaces mentioned above.

> - would a memory map of, say, 4097 entries (so, 81 kB) ever be problematic?

I think it could, but if it is problems are likely to happen elsewhere, and
they're bugs that need to be fixed IMHO.

> I'd love to make the
> use of broken memory chips as commonplace as possible, so as to avoid
> the environmental damage caused by making (memory) chips.

A laudable goal.  My hat off to you.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."