Re: Fixes for Tyan s2880

[YhLu]

Ron.

Changes in raminit.c add fill_last function.
So remove following error while kernel booting:

" Scanning NUMA topology in Northbridge 24
Node 0 MemBase 0000000000000000 Limit 000000007fffffff
Node 1 MemBase 0000000080000000 Limit 00000000f0000000
Node map not sorted 80000000,0
No NUMA configuration found
Faking a node at 0000000000000000-00000000f0000000
Bootmem setup node 0 0000000000000000-00000000f0000000
"

To:
" Scanning NUMA topology in Northbridge 24
Node 0 MemBase 0000000000000000 Limit 000000007fffffff
Node 1 MemBase 0000000080000000 Limit 00000000f0000000
Using node hash shift of 24
Bootmem setup node 0 0000000000000000-000000007fffffff
Bootmem setup node 1 0000000080000000-00000000f0000000
"

Is the raminit.c taken care by ERIC? Is he planning to add 4G support in
that?

Regards

Yinghai Lu

Fixes for Tyan s2880

[ron minnich]

Yh Lu, this will take me a little time to integrate your patches, I hope 
to be done tomorrow. Some of the things you have patched I have also 
fixed, but due to the 24-hour delay at sourceforge.net, we are out of 
sync.

Thanks for your patches, I hpoe to commit by tomorrow.

ron

Fixes for Tyan s2880

[ron minnich]

OK, I have applied Yh Lu's patches for the most part. In almost all cases 
they are tyan 2880-specific. There are three things I can see that might 
affect others:

#ifdef some-variable 
no longer works in many places, it has to be
#if some-variable == 1

to work.

-  for the new config too, there is no longer a default for _RAMBASE, 
    due to PPC and K8 differences

raminit.c sees the following changes:
Index: src/northbridge/amd/amdk8/raminit.c
===================================================================
RCS file: /cvsroot/freebios/freebios2/src/northbridge/amd/amdk8/raminit.c,v
retrieving revision 1.12
diff -r1.12 raminit.c
921a922,927
> //BY LYH  add IOMMU 64M APERTURE
>    PCI_ADDR(0, 0x18, 3, 0x94), 0xffff8000, 0x00000f70,
>    PCI_ADDR(0, 0x18, 3, 0x90), 0xffffff80, 0x00000002,
>         PCI_ADDR(0, 0x18, 3, 0x98), 0x0000000f, 0x00068300,
>
> //BY LYH END

1119c1125,1141
< 
---
> static void fill_last(unsigned long node_id,unsigned long base)
> {
> //BY LYH //Fill next base reg with right value
>         unsigned i;
>         unsigned base_reg;
>         base &=0xffff0000;
>    device_t device;
>         for(device = PCI_DEV(0, 0x18, 1); device <= PCI_DEV(0, 0x1f, 1); device
> += PCI_DEV(0, 1, 0)) {
>         	for(i=node_id+1;i<=7;i++) {
>                 	base_reg=0x40+(i<<3);
>                  	pci_write_config32(device,base_reg,base);
>    	}
>         }
> //BY LYH END
> }

1128a1151
>

1145a1169
>

1254,1256c1278,1280
< 		print_debug("csbase=");
< 		print_debug_hex32(csbase);
< 		print_debug("\r\n");
---
> //		print_debug("csbase=");
> //		print_debug_hex32(csbase);
> //		print_debug("\r\n");

1285a1310,1312
> //BY LYH
>         fill_last(ctrl->node_id, tom_k<<2);
> //BY LYH END

1288,1291c1315,1319
< 	if(ctrl->node_id==1) {
< 		pci_write_config32(ctrl->f2, DRAM_CSBASE, 0x00000001);
< 	
< 	}	
---
>     dump_pci_device(PCI_DEV(0, 0x18, 1));
>
> //	if(ctrl->node_id==1) {
> //		pci_write_config32(ctrl->f2, DRAM_CSBASE, 0x00000001);
> //	}

and the amd8111 sees this:

Index: src/southbridge/amd/amd8111/amd8111_ldtstop.c
===================================================================
RCS file: /cvsroot/freebios/freebios2/src/southbridge/amd/amd8111/amd8111_ldtstop.c,v
retrieving revision 1.4
diff -r1.4 amd8111_ldtstop.c
22c22
< 	pci_write_config16(dev, 0x48, pci_read_config16(dev,0x48) & ~CPUPIN);
---
> pci_write_config32(dev, 0x48, pci_read_config32(dev,0x48) & ~CPUPIN);

If this is trouble, let me know.

You are going to have to set _RAMBASE in your mainboard Config.lb now.

ron

Fixes for Tyan s2880

ron minnich  writes:
> OK, I have applied Yh Lu's patches for the most part. In almost all cases 
> they are tyan 2880-specific. There are three things I can see that might 
> affect others:
>
> #ifdef some-variable 
> no longer works in many places, it has to be
> #if some-variable == 1
>
> to work.
> for the new config too, there is no longer a default for _RAMBASE, 
> due to PPC and K8 differences

Hmm.  We can't have a per architecture default _RAMBASE?

As long as there is an error if you don't set it I guess that
is ok.
> raminit.c sees the following changes:
> Index: src/northbridge/amd/amdk8/raminit.c

Ron on these kind of things please use diff -u or cvs diff -u
it is much, much, much more readable.
> ===================================================================
> RCS file: /cvsroot/freebios/freebios2/src/northbridge/amd/amdk8/raminit.c,v
> retrieving revision 1.12
> diff -r1.12 raminit.c
> 921a922,927
> > //BY LYH  add IOMMU 64M APERTURE
> >    PCI_ADDR(0, 0x18, 3, 0x94), 0xffff8000, 0x00000f70,
> >    PCI_ADDR(0, 0x18, 3, 0x90), 0xffffff80, 0x00000002,
> >         PCI_ADDR(0, 0x18, 3, 0x98), 0x0000000f, 0x00068300,
> >
> > //BY LYH END
>
> 1119c1125,1141
> <

With YhLu's observation that Function 2 dram base addresses are per
memory controller local addresses there are a number of pieces in here
that just need to be fixed.

Hopefully I can get at it tomorrow.  The current code base does not
have the second memory controller working for me.
> > static void fill_last(unsigned long node_id,unsigned long base)
> > {
> > //BY LYH //Fill next base reg with right value
> >         unsigned i;
> >         unsigned base_reg;
> >         base &=0xffff0000;
> >    device_t device;
> > for(device = PCI_DEV(0, 0x18, 1); device <= PCI_DEV(0, 0x1f, 1); device
> > += PCI_DEV(0, 1, 0)) {
> >         	for(i=node_id+1;i<=7;i++) {
> >                 	base_reg=0x40+(i<<3);
> >                  	pci_write_config32(device,base_reg,base);
> >    	}
> >         }
> > //BY LYH END
> > }
>
> 1128a1151
> >
>
> 1145a1169
> >
>
> 1254,1256c1278,1280
> < 		print_debug("csbase=");
> < 		print_debug_hex32(csbase);
> < 		print_debug("\r\n");
> > //		print_debug("csbase=");
> > //		print_debug_hex32(csbase);
> > //		print_debug("\r\n");
>
> 1285a1310,1312
> > //BY LYH
> >         fill_last(ctrl->node_id, tom_k<<2);
> > //BY LYH END
>
> 1288,1291c1315,1319
> < 	if(ctrl->node_id==1) {
> < 		pci_write_config32(ctrl->f2, DRAM_CSBASE, 0x00000001);
> <
> < 	}
> >     dump_pci_device(PCI_DEV(0, 0x18, 1));
> >
> > //	if(ctrl->node_id==1) {
> > //		pci_write_config32(ctrl->f2, DRAM_CSBASE, 0x00000001);
> > //	}
> and the amd8111 sees this:
> Index: src/southbridge/amd/amd8111/amd8111_ldtstop.c
>
> RCS file:
> /cvsroot/freebios/freebios2/src/southbridge/amd/amd8111/amd8111_ldtstop.c,v
>
> retrieving revision 1.4
> diff -r1.4 amd8111_ldtstop.c
> 22c22
> < 	pci_write_config16(dev, 0x48, pci_read_config16(dev,0x48) & ~CPUPIN);
> > pci_write_config32(dev, 0x48, pci_read_config32(dev,0x48) & ~CPUPIN);

That looks to be a noop so it should not cause trouble.
> If this is trouble, let me know.
>
> You are going to have to set _RAMBASE in your mainboard Config.lb
> now.

Unfortunate but it should be a large problem.

Ron while we are thinking about it where should we place tables on the
ARM?  It has a ROM chip as the first thing in memory.

Eric

Fixes for Tyan s2880

[Stefan Reinauer]

* Eric W. Biederman  [030730 07:55]:
> > Index: src/southbridge/amd/amd8111/amd8111_ldtstop.c
> >
> > RCS file:
> > /cvsroot/freebios/freebios2/src/southbridge/amd/amd8111/amd8111_ldtstop.c,v
> >
> > retrieving revision 1.4
> > diff -r1.4 amd8111_ldtstop.c
> > 22c22
> > < 	pci_write_config16(dev, 0x48, pci_read_config16(dev,0x48) & ~CPUPIN);
> > > pci_write_config32(dev, 0x48, pci_read_config32(dev,0x48) & ~CPUPIN);

The Bios and kernel developers guide specifies 16bit for that register.
But since it's all Little Endian it really does not matter.

OTOH, if Tom gets his warm reboot code in place after setting link
speed, we can probably get rid of ldtstop assertion completely.

How does doing a warm boot there affect boot time?

Stefan

Fixes for Tyan s2880

Stefan Reinauer  writes:
> Eric W. Biederman  [030730 07:55]:
> > > Index: src/southbridge/amd/amd8111/amd8111_ldtstop.c
> > >
> > > RCS file:
> > > /cvsroot/freebios/freebios2/src/southbridge/amd/amd8111/amd8111_ldtstop.c,v
> > >
> > > retrieving revision 1.4
> > > diff -r1.4 amd8111_ldtstop.c
> > > 22c22
> > > < 	pci_write_config16(dev, 0x48, pci_read_config16(dev,0x48) & ~CPUPIN);
> > > > pci_write_config32(dev, 0x48, pci_read_config32(dev,0x48) & ~CPUPIN);
>
> The Bios and kernel developers guide specifies 16bit for that register.
> But since it's all Little Endian it really does not matter.
>
> OTOH, if Tom gets his warm reboot code in place after setting link
> speed, we can probably get rid of ldtstop assertion completely.

The code is there.  There is a challenge because of errata #48 that
says the 8131 cannot operate at 800Mhz reliably, but it reports that it can.
> How does doing a warm boot there affect boot time?

It pretty much doubles the time before the booloader.  And there is
the large delay that you see on current Opteron systems.

My plan for today is to see about integrating all of these divergent
pieces so I have everything working in one tree.

Eric

Fixes for Tyan s2880

[ron minnich]

On 29 Jul 2003, Eric W. Biederman wrote:
> Hmm.  We can't have a per architecture default _RAMBASE?

not sure if it makes sense per architecture. Consider those Alpha boards 
where rambase depended on chip type, board type, engineer's last name, and 
phase of the moon. I'm sure we'll see more of that.
> Ron while we are thinking about it where should we place tables on the
> ARM?  It has a ROM chip as the first thing in memory.

cool! you're looking at ARM?

possibly at put tables at the other end of memory? Is there an ARM 
standard for this?

ron

Fixes for Tyan s2880

ron minnich  writes:
> On 29 Jul 2003, Eric W. Biederman wrote:
> > Hmm.  We can't have a per architecture default _RAMBASE?
>
> not sure if it makes sense per architecture. Consider those Alpha boards 
> where rambase depended on chip type, board type, engineer's last name, and 
> phase of the moon. I'm sure we'll see more of that.

Hmm.  Perhaps.  The SGI Itanium nodes start their memory at 196GB.

For commodity stuff standardization is the rule of the game, so
how much of this we will have to deal with LinuxBIOS wise is an interesting
question.  Mostly on the embedded stuff I would suspect.
> > Ron while we are thinking about it where should we place tables on the
> > ARM?  It has a ROM chip as the first thing in memory.
>
> cool! you're looking at ARM?

No, I have just been talking to a lot of people doing embedded stuff.
And I like to look at problems long before I actually have to cope with
them.
> possibly at put tables at the other end of memory? Is there an ARM 
> standard for this?

ARM kernels currently have a fair amount of board specific knowledge
in them.  An ARM BIOS is so far to easy to share code with LinuxBIOS,
but we may be able to share a table structure with.

Eric