[BULK] RFC: Generic shadow mechanism useable from a payload

Eric W. Biederman ebiederman at lnxi.com
Wed Jan 26 08:19:00 CET 2005


Richard Smith <smithbone at gmail.com> writes:

> Thinking about ADLO and the shadow enable/disable got some wheels turning.
> 
> I've been spending lots of time in V2 and I was wondering if the same
> type of methodology can't work for ADLO.
> 
> In V2 there are specifc .c files that do thing in a chipset specific
> way and the auto.c includes them as necesary.  Those get compiled and
> then stuck in the startup assembly.
> 
> What if we created a shadow.c file that was in the northbridge
> directory with a simple API type setup that enabled and disabled the
> various shadow ranges.

That is a fairly sane way to get code sharing, if we need it.  The code
is small enough and simple enough cut-and-paste code sharing is probably
just as good.  All you need to do is look at which chipset you are running
on.  We only need to drop out support if it becomes too much code having
support for all of the chipsets and cpus.

But I actually think that is overkill. v2 by default and design
enables all of the shadow ranges as memory.  So we just need to
use those ranges.  That should be much easier having to patch
ADLO each time.  It is fairly unlikely a writable ROM segment is
going to break anything. 

Once we find the application a writable rom segment breaks I will
be happy to reconsider, solutions.

> I suppose that that FILO and the emulator render most of ADLO
> un-needed but if you are going to try and use FreeDOS or Windoze as an
> OS then you will need ADLO.

ADLO has a use case and for those 


Eric



More information about the coreboot mailing list