[coreboot] [PATCH] Support for the ASI MB-5BLGP (Neoware Eon 4000s)

[Juergen Beisert]

Hi Carl-Daniel,

On Montag, 14. Juli 2008, Carl-Daniel Hailfinger wrote:
> thanks a lot for the code.
>
> On 13.07.2008 22:50, Juergen Beisert wrote:
> > On Sonntag, 13. Juli 2008, Carl-Daniel Hailfinger wrote:
> >> On 13.07.2008 21:37, Juergen Beisert wrote:
> >>> On Sonntag, 13. Juli 2008, Uwe Hermann wrote:
> >>>> On Fri, Jul 11, 2008 at 11:17:53PM +0200, Carl-Daniel Hailfinger wrote:
> >>>>> Does CAR work for the GX1?
> >>>>
> >>>> Not yet, but it's possible to do. I think Juergen Beisert (CC'd) wrote
> >>>> something for GX1 in v3 a while ago (?) Juergen, do you still have
> >>>> that code and will it work for v3 (and even better, also for v2)? If
> >>>> so, please post it with a Signed-off-by so we can get it into svn.
> >>>
> >>> The code still exists. But I have no idea how I should add it to v2. I
> >>> do not know how CAR in v2 works.
> >>
> >> Can you just post the code to the list? Then we can review it and
> >> commit.
> >
> > Its not adapted to v2 nor v3. Its only an example, how to do it for CPUs
> > with these special cache test registers (like older i486 and the Geode
> > GX1).
>
> You say "older i486". Does that mean newer i486 have different registers?

No, that's not what I mean. All i486 are "old", aren't they? ;-) My amd486 
datasheet tells me, this CPU has such registers. I believe the old Intel 
i486s also have such registers (but I'm not sure).

> > After running this program, you have (a very fast) RAM at physical
> > address __car_data_dst up to (__car_data_dst + __car_size). These two
> > symbols are generated by my linker script. I'm using this code in my
> > current u-boot-v2 development for ia32.
> >
> > Note: This code must run with *disabled* cache and this piece of RAM only
> > exists and is useable, _until_you_enable_the_cache_!
> > Note also: You should locate this CAR area in the regular SDRAM area,
> > because when you enable the cache (after SDRAM controller
> > initialisation), the cache unit will flush its content to the SDRAM. It
> > will fail badly if at the same physical address is no real memory to
> > write/flush to.
>
> Hm. I thought a self-copy followed by a WBINVD was required to transfer
> the cache contents to the SDRAM.

But also the WBINVD will fail, if at the physical mapping address is no valid 
device (like SDRAM or PCI...). In this case you must use the INVD instruction 
instead. But I believe you know what you are doing ;-)

Juergen