memory epia-m 127M != 512M

[Niki Waibel]

i use a 512MByte mem module in the epia-m 600mhz and linuxbios sayes:
===
totalram: 127M
===

i modified src/northbridge/via/vt8623/northbridge.c
===
diff -u -N -r freebios-20030924.old/src/northbridge/via/vt8623/northbridge.c freebios-20030924/src/northbridge/via/vt8623/north
bridg
e.c
--- freebios-20030924.old/src/northbridge/via/vt8623/northbridge.c      2003-06-29 18:23:58.000000000 +0200
+++ freebios-20030924/src/northbridge/via/vt8623/northbridge.c  2003-09-24 14:10:22.025680920 +0200
@@ -9,10 +9,14 @@
 {
        unsigned long totalmem;
        unsigned char bank, mem, prevmem;
+#if 0
        // fix me later -- there are two more banks at 0x56 and 0x57
        unsigned long firstbank = 0x5a, lastbank = 0x5d;
+#endif
+       unsigned long banks[] = { 0x56, 0x57, 0x5a, 0x5b, 0x5c, 0x5d };
+       const unsigned long nbanks = 6;
+       unsigned long i;
        u8 sma_status, sma_size, sma_size_bits;
-       u8 val;

struct pci_dev *pcidev;

@@ -28,8 +32,9 @@
        else
                sma_size = 0x01 << sma_size_bits;

-       for(totalmem = mem = prevmem = 0, bank = firstbank; 
-           bank <= lastbank; bank++) {
+       totalmem = mem = prevmem = 0;
+       for(i=0; i<nbanks; i++) {
+               bank = banks[i];
                pci_read_config_byte(pcidev, bank, &mem);
                // sanity check. If the mem value is < prevmem, 
                // that is an error, so skip this step. 
@@ -41,7 +46,7 @@
                        totalmem += (mem - prevmem) * 16;
                prevmem = mem;
        }
-
+
        totalmem -= sma_size;
        totalmem *= 1024;
 #if 0
===

but that did not help.

this is no urgent problem, because 128M is enough for the system i want
to build. but it could be a problem for other people.

niki

[Ian Smith]

Hi Niki,

I was looking at this as well and I think there may be a couple of problems 
here.

The first is that I think the comments in the code may be a bit misleading 
(apologies to the original author!)

AIUI the registers at 0x56 and 0x57 (and 0x5E and 0x5F as well) should be 
set to the same value as 0x5D i.e. the DRAM ending address for your highest 
populated bank of memory.

Looking through northbridge/via/vt8623/raminit.inc it looks like 0x56 and 
0x56 are set to 0x10, which I think would equate to 128MB as you are seeing.

I think if you possibly remove the references to 0x56 and 0x57 in 
northbridge.c (and set the number of banks to 4), then set the values in 
raminit.inc to what you want i.e.

0x5A = 0x20
0x5B = 0x40
0x5C = 0x40
0x5D = 0x40
0x56 = 0x40
0x57 = 0x40

then the size detect code might just work.

Of course if your 512MB module actually has two banks of memory then you 
might need to add some extra code to initialise the second bank (not sure 
about this though.

I need to get this working for the project I'm working on (as well as 
getting banks 2 and 3 going too), but at the moment I'm trying to get the 
VGA working so it might be a few days before I will the time to do some 
proper investigation.

Hope this helps anyway

Cheers

Ian

At 13:14 24/09/2003, Niki Waibel wrote:
> i use a 512MByte mem module in the epia-m 600mhz and linuxbios sayes:
> totalram: 127M
> i modified src/northbridge/via/vt8623/northbridge.c
>
> diff -u -N -r 
> freebios-20030924.old/src/northbridge/via/vt8623/northbridge.c 
> freebios-20030924/src/northbridge/via/vt8623/north
> bridg
> e.c
>
> freebios-20030924.old/src/northbridge/via/vt8623/northbridge.c 
> 2003-06-29 18:23:58.000000000 +0200
> +++ freebios-20030924/src/northbridge/via/vt8623/northbridge.c  2003-09-24 
> 14:10:22.025680920 +0200
> @@ -9,10 +9,14 @@
>  {
>         unsigned long totalmem;
>         unsigned char bank, mem, prevmem;
> +#if 0
>         // fix me later -- there are two more banks at 0x56 and 0x57
>         unsigned long firstbank = 0x5a, lastbank = 0x5d;
> +#endif
>   unsigned long banks[] = { 0x56, 0x57, 0x5a, 0x5b, 0x5c, 0x5d };
>   const unsigned long nbanks = 6;
>   unsigned long i;
>   u8 sma_status, sma_size, sma_size_bits;
>   u8 val;
>
>    struct pci_dev *pcidev;
>
> @@ -28,8 +32,9 @@
>         else
>                 sma_size = 0x01 << sma_size_bits;
>   for(totalmem = mem = prevmem = 0, bank = firstbank;
>       bank <= lastbank; bank++) {
>   totalmem = mem = prevmem = 0;
>   for(i=0; i<nbanks; i++) {
>           bank = banks[i];
>           pci_read_config_byte(pcidev, bank, &mem);
>           // sanity check. If the mem value is < prevmem,
>           // that is an error, so skip this step.
>
> @@ -41,7 +46,7 @@
>                         totalmem += (mem - prevmem) * 16;
>                 prevmem = mem;
>         }
>   totalmem -= sma_size;
>   totalmem *= 1024;
> #if 0
>
> but that did not help.
>
> this is no urgent problem, because 128M is enough for the system i want
> to build. but it could be a problem for other people.
>
> niki
> _______________________________________________
> Linuxbios mailing list
> [e-mail]
> http://www.clustermatic.org/mailman/listinfo/linuxbios

[Niki Waibel]

hi ian,
> The first is that I think the comments in the code may be a bit misleading 
> (apologies to the original author!)
>
> AIUI the registers at 0x56 and 0x57 (and 0x5E and 0x5F as well) should be 
> set to the same value as 0x5D i.e. the DRAM ending address for your highest 
> populated bank of memory.
>
> Looking through northbridge/via/vt8623/raminit.inc it looks like 0x56 and 
> 0x56 are set to 0x10, which I think would equate to 128MB as you are seeing.

hmmm
> I think if you possibly remove the references to 0x56 and 0x57 in 
> northbridge.c (and set the number of banks to 4), then set the values in 
> raminit.inc to what you want i.e.
>
> 0x5A = 0x20
> 0x5B = 0x40
> 0x5C = 0x40
> 0x5D = 0x40
> 0x56 = 0x40
> 0x57 = 0x40
>
> then the size detect code might just work.
>
> Of course if your 512MB module actually has two banks of memory then you 
> might need to add some extra code to initialise the second bank (not sure 
> about this though.
>
> I need to get this working for the project I'm working on (as well as 
> getting banks 2 and 3 going too),

all the work which has to be done (regarding this) is almost impossible
without the knowledge of the registers.

because of that i cannot help much ... i dont want to write wrong code
just because of lack of information.
> but at the moment I'm trying to get the 
> VGA working so it might be a few days before I will the time to do some 
> proper investigation.

so we need to wait for you, because it seems that you know
how to program the beast :)
> Hope this helps anyway

as i sayed -- this is not urgent for me.

it is just a bit annoying that via (and also other companies)
are really slowing down the process of developement. i dont see
the point in doing this. any fully working software make the
companies, who produce hardware, more famous -> more money.
hiding information is not a good way in my opinion.

niki

[Ian Smith]

Niki Waibel wrote:
> hi ian,
> > The first is that I think the comments in the code may be a bit misleading 
> > (apologies to the original author!)
> >
> > AIUI the registers at 0x56 and 0x57 (and 0x5E and 0x5F as well) should be 
> > set to the same value as 0x5D i.e. the DRAM ending address for your highest 
> > populated bank of memory.
> >
> > Looking through northbridge/via/vt8623/raminit.inc it looks like 0x56 and 
> > 0x56 are set to 0x10, which I think would equate to 128MB as you are seeing.
>
> hmmm
> > I think if you possibly remove the references to 0x56 and 0x57 in 
> > northbridge.c (and set the number of banks to 4), then set the values in 
> > raminit.inc to what you want i.e.
> >
> > 0x5A = 0x20
> > 0x5B = 0x40
> > 0x5C = 0x40
> > 0x5D = 0x40
> > 0x56 = 0x40
> > 0x57 = 0x40
> >
> > then the size detect code might just work.

Rats - got this wrong (no coffee yet today :-)

The units are 16MB in these registers so 0x5A should be 0x10 and the 
other should be 0x20. Sorry for any confusion.

Blows a hole in my theory about the 128MB being detected....
> > Of course if your 512MB module actually has two banks of memory then you 
> > might need to add some extra code to initialise the second bank (not sure 
> > about this though.
> >
> > I need to get this working for the project I'm working on (as well as 
> > getting banks 2 and 3 going too),
>
> all the work which has to be done (regarding this) is almost impossible
> without the knowledge of the registers.
>
> because of that i cannot help much ... i dont want to write wrong code
> just because of lack of information.
> > but at the moment I'm trying to get the 
> > VGA working so it might be a few days before I will the time to do some 
> > proper investigation.
>
> so we need to wait for you, because it seems that you know
> how to program the beast :)

I think I may have just disproved that theory :-)
> > Hope this helps anyway
>
> as i sayed -- this is not urgent for me.
>
> it is just a bit annoying that via (and also other companies)
> are really slowing down the process of developement. i dont see
> the point in doing this. any fully working software make the
> companies, who produce hardware, more famous -> more money.
> hiding information is not a good way in my opinion.

It does seem odd that they are so secretive. I've worked with a lot of 
chip vendors, both bigger and smaller, and I can't recall any of them 
being so paranoid about their data sheets.
> niki

Cheers

Ian

[ron minnich]

On Thu, 25 Sep 2003, Ian Smith wrote:
> Blows a hole in my theory about the 128MB being detected....

sorry, but those registers you are mentioning have *zero* impact on size 
detection. That's not what's going on here. Size detect is via SPD.

We wrote a lot of that code here 3 years ago, and it was a hack then in an
attempt to get the 8601 to work at all.

If you look at how it works now:

// Initial setting, 256MB in each bank, will be rewritten later.
        CS_WRITE($0x5A, $0x20)
        CS_WRITE($0x5B, $0x40)
        CS_WRITE($0x5C, $0x60)
        CS_WRITE($0x5D, $0x80)
        CS_WRITE($0x5E, $0xA0)
        CS_WRITE($0x5F, $0xC0)

So the ram size is set to 256MB per bank. Then we proceed to initialize 
all the DRAM as though it were there. It is sufficient for SDRAM to do 
this. It is probably not sufficient for DDR to do this.

Then, later, in C, we size it up via SPD (I think SONE did this work?) and
set the right values in.

Anyone who is setting values in just by jamming things in registers is 
going at it the wrong way and is doomed to fail. There are complex 
problems with the 8601, such as buffer strength issues, that require more 
sophistication.

The right thing to do here is cut to freebios2 ASAP and write all this in 
C. It's just too hard in assembly.

ron

[Andrew Ip]

Hi Ron,
> The right thing to do here is cut to freebios2 ASAP and write all this in 
> C. It's just too hard in assembly.

Is there any platform has been ported to freebios2 besides AMD64?  Any
porting guide for that?  Is it as easy as running buildtarget to generate
the build directory?

-Andrew

[Stefan Reinauer]

* Andrew Ip  [030925 16:03]:
> > The right thing to do here is cut to freebios2 ASAP and write all this in 
> > C. It's just too hard in assembly.
>
> Is there any platform has been ported to freebios2 besides AMD64?  Any

Some PPC machines are supported as well.
> porting guide for that?  Is it as easy as running buildtarget to generate
> the build directory?

yes. calling buildtarget and then doing make in the freshly created
directory will build you a flashable image "linuxbios.rom"

Stefan

[ron minnich]

Let's just start. Andrew, I will try to populate a skeleton epia directory 
in freebios2, and we can start filling it in.

ron

[SONE Takeshi]

On Thu, Sep 25, 2003 at 07:40:06AM -0600, ron minnich wrote:
> On Thu, 25 Sep 2003, Ian Smith wrote:
> > Blows a hole in my theory about the 128MB being detected....
>
> sorry, but those registers you are mentioning have *zero* impact on size 
> detection. That's not what's going on here. Size detect is via SPD.
>
> We wrote a lot of that code here 3 years ago, and it was a hack then in an
> attempt to get the 8601 to work at all.
>
> If you look at how it works now:
>     // Initial setting, 256MB in each bank, will be rewritten later.
>     CS_WRITE($0x5A, $0x20)
>     CS_WRITE($0x5B, $0x40)
>     CS_WRITE($0x5C, $0x60)
>     CS_WRITE($0x5D, $0x80)
>     CS_WRITE($0x5E, $0xA0)
>     CS_WRITE($0x5F, $0xC0)

Just to clarify, Ron, people are talking about EPIA-M here.
And the code snippet above is from vt8601/raminit.inc.
EPIA-M doesn't use vt8601.
EPIA and EPIA-M are two totally different boards (different chipsets,
etc).

People with EPIA are seemingly OK with my hack to the SDRAM code of 8601.
However, EPIA-M users need to tweak the hardcoded magic numbers
in the DDR code of vt8623.

So, please open a epia-m directory, instead of epia, in the freebios2 tree.

[ron minnich]

On Fri, 26 Sep 2003, SONE Takeshi wrote:
> EPIA and EPIA-M are two totally different boards (different chipsets,
> etc).

stupid ofme. I got mixed up because so many of the registers are the same.
> So, please open a epia-m directory, instead of epia, in the freebios2
> tree.

I'm going to do both. I don't have any epia-m just yet. I understand the 
EPIA, so I'll fight one battle at a time.

ron