[LinuxBIOS] How to separate CS5536 and CPU?

[Indrek Kruusa]

Hi!

Currently I need to change cs5536 code (below) to make Geode LX target 
build.

To conclude the situation:
- different CPU-s with integrated northbridge using the same southbridge
- southbridge needs to know about CPU

Which should be the preferred way to fix it?

thanks,
Indrek

/*****************/

diff -u -r -b -B LinuxBIOSv2/src/southbridge/amd/cs5536/cs5536.c 
LinuxBIOSv2_cp1/src/southbridge/amd/cs5536/cs5536.c
--- LinuxBIOSv2/src/southbridge/amd/cs5536/cs5536.c     2006-07-22 
02:21:01.000000000 +0300
+++ LinuxBIOSv2_cp1/src/southbridge/amd/cs5536/cs5536.c 2006-07-31 
17:53:04.000000000 +0300
@@ -5,7 +5,7 @@
 #include <device/pci_ops.h>
 #include <device/pci_ids.h>
 #include <console/console.h>
-#include <cpu/amd/gx2def.h>
+#include <cpu/amd/lxdef.h>
 #include <cpu/x86/msr.h>
 #include "chip.h"

diff -u -r -b -B 
LinuxBIOSv2/src/southbridge/amd/cs5536/cs5536_early_setup.c 
LinuxBIOSv2_cp1/src/southbridge/amd/cs5536/cs5536_early_setup.c
--- LinuxBIOSv2/src/southbridge/amd/cs5536/cs5536_early_setup.c 
2006-07-27 07:05:43.000000000 +0300
+++ LinuxBIOSv2_cp1/src/southbridge/amd/cs5536/cs5536_early_setup.c     
2006-07-31 17:52:52.000000000 +0300
@@ -1,4 +1,4 @@
-#include <cpu/amd/gx2def.h>
+#include <cpu/amd/lxdef.h>

/*
  *

[ron minnich]

I'm on vacation, but have a plan for this, can we wait one week?

thanks

ron

[Indrek Kruusa]

ron minnich wrote:
> I'm on vacation, but have a plan for this, can we wait one week?

yes we can.

thanks,
Indrek

[Stefan Reinauer]

Why is this one needed? Which of the defines actually break the tree?
Can't you #define GX2_FOO and LX_FOO instead of FOO and use it based on
some compile time or runtime test?
> diff -u -r -b -B LinuxBIOSv2/src/southbridge/amd/cs5536/cs5536.c 
> LinuxBIOSv2_cp1/src/southbridge/amd/cs5536/cs5536.c
> --- LinuxBIOSv2/src/southbridge/amd/cs5536/cs5536.c     2006-07-22 
> 02:21:01.000000000 +0300
> +++ LinuxBIOSv2_cp1/src/southbridge/amd/cs5536/cs5536.c 2006-07-31 
> 17:53:04.000000000 +0300
> @@ -5,7 +5,7 @@
>  #include <device/pci_ops.h>
>  #include <device/pci_ids.h>
>  #include <console/console.h>
> -#include <cpu/amd/gx2def.h>
> +#include <cpu/amd/lxdef.h>
>  #include <cpu/x86/msr.h>
>  #include "chip.h"

the next one is simple. it is included from here:
 src/mainboard/amd/rumba/auto.c
 src/mainboard/olpc/rev_a/auto.c
 src/mainboard/artecgroup/dbe61/auto.c

so these 3 should be patched to include gx2def.h or lxdef.h accordingly
before including cs5536_early_setup.c
> LinuxBIOSv2/src/southbridge/amd/cs5536/cs5536_early_setup.c 
> LinuxBIOSv2_cp1/src/southbridge/amd/cs5536/cs5536_early_setup.c
> --- LinuxBIOSv2/src/southbridge/amd/cs5536/cs5536_early_setup.c 
> 2006-07-27 07:05:43.000000000 +0300
> +++ LinuxBIOSv2_cp1/src/southbridge/amd/cs5536/cs5536_early_setup.c     
> 2006-07-31 17:52:52.000000000 +0300
> @@ -1,4 +1,4 @@
> -#include <cpu/amd/gx2def.h>
> +#include <cpu/amd/lxdef.h>

[Indrek Kruusa]

Stefan Reinauer wrote:
> Why is this one needed? Which of the defines actually break the tree?
> Can't you #define GX2_FOO and LX_FOO instead of FOO and use it based on
> some compile time or runtime test?
> > diff -u -r -b -B LinuxBIOSv2/src/southbridge/amd/cs5536/cs5536.c 
> > LinuxBIOSv2_cp1/src/southbridge/amd/cs5536/cs5536.c
> > --- LinuxBIOSv2/src/southbridge/amd/cs5536/cs5536.c     2006-07-22 
> > 02:21:01.000000000 +0300
> > +++ LinuxBIOSv2_cp1/src/southbridge/amd/cs5536/cs5536.c 2006-07-31 
> > 17:53:04.000000000 +0300
> > @@ -5,7 +5,7 @@
> >  #include <device/pci_ops.h>
> >  #include <device/pci_ids.h>
> >  #include <console/console.h>
> > -#include <cpu/amd/gx2def.h>
> > +#include <cpu/amd/lxdef.h>
> >  #include <cpu/x86/msr.h>
> >  #include "chip.h"

Yes - and the question was what should be that compile time test.
> the next one is simple. it is included from here:
>  src/mainboard/amd/rumba/auto.c
>  src/mainboard/olpc/rev_a/auto.c
>  src/mainboard/artecgroup/dbe61/auto.c
>
> so these 3 should be patched to include gx2def.h or lxdef.h accordingly
> before including cs5536_early_setup.c

This is OK for me.

Question about OLPC: if memtest is set as payload then is it works? We 
have got dbe61 up and running after some ram_resource() hacking. With 
ehterbooted Linux the thing is still totally quiet.

thanks,
Indrek

[Richard Smith]

> Question about OLPC: if memtest is set as payload then is it works? We
> have got dbe61 up and running after some ram_resource() hacking. With
> ehterbooted Linux the thing is still totally quiet.

I've not tried memtest on OLPC.  Ron may have.  I can test later on
tonight if you wish. I'm CDT. So it will be in 6 or so hours.

[Indrek Kruusa]

Richard Smith wrote:
> > Question about OLPC: if memtest is set as payload then is it works? We
> > have got dbe61 up and running after some ram_resource() hacking. With
> > ehterbooted Linux the thing is still totally quiet.
>
> I've not tried memtest on OLPC.  Ron may have.  I can test later on
> tonight if you wish. I'm CDT. So it will be in 6 or so hours.

Yes, I am very interested in your results. If you still have the 
possbility to test of course.

thanks,
Indrek

[Ronald G Minnich]

Richard Smith wrote:
> > Question about OLPC: if memtest is set as payload then is it works? We
> > have got dbe61 up and running after some ram_resource() hacking. With
> > ehterbooted Linux the thing is still totally quiet.
>
> I've not tried memtest on OLPC.  Ron may have.  I can test later on
> tonight if you wish. I'm CDT. So it will be in 6 or so hours.

we have used memtest as a payload. It works fine.

ron

[Richard Smith]

> > I've not tried memtest on OLPC.  Ron may have.  I can test later on
> > tonight if you wish. I'm CDT. So it will be in 6 or so hours.

Oops.  Sorry.  I forgot i was going to try this for you.