Re: More data: I've made a CVS build that doesn't crash!

[Pete Popov <ppopov@pacbell.net>]

On Thu, 2002-01-31 at 01:30, Matthew Dharm wrote:
> Well, discontiguous memory works on all other arches I know (PPC and x86,
> at least), so why not here too?

PPC and x86 are unfortunately ahead of mips in some areas.  For one,
there's a lot more cheap hardware out there for developers to play with
and thus more developers.  Not many hackers can afford to shell out
$3-$5k for a ref board.   We definitely need something like the Sony PS2
to attract more mips developers, I think.  But I digress.  

I could be wrong but I thought you need explicit support for
discontiguous memory.   "find . -name *.[ch] |xarsg grep
CONFIG_DISCONTIGMEM"  doesn't show anything in arch/mips, though there
appears to be support for some mips64 target(s).  Like I said though, I
could be wrong, but do check with someone who knows before you waste too
much time down that path.

Pete
 
> Matt
> 
> On Wed, Jan 30, 2002 at 06:55:52PM -0800, Pete Popov wrote:
> > On Wed, 2002-01-30 at 18:45, Matthew Dharm wrote:
> > > (I aplogize for the duplicate... this message has more information
> > > than the other one... Outlook decided that I meant "send" not
> > > "paste"... grr...)
> > > 
> > > Well, I've figured out my crashing problem, but I'm not certain how to
> > > fix it... I've got a couple of choices, and my first choice doesn't
> > > seem to work too well, tho I'm not sure if that's my fault or another
> > > bug...
> > > 
> > > Basically, what happens is this:  The SDRAM is in two banks (0,2) in
> > > equal parts.  So, on our 128MByte boards, it's two banks of 64MBytes.
> > > On our 512MByte boards, it's 2 banks of 256MBytes each.
> > > 
> > > The bridge is programmed to place the first bank at 0x0, and the other
> > > bank at 256MBytes.  add_memory_region() is called earlier in the boot
> > > sequence to set up the first 64MBytes at address 0.  Now we call
> > > add_memory_region() with incorrect parameters.
> > > 
> > > So, I thought to myself, let's just change the 'start' address of the
> > > add_memory_region() call.  For good luck, I even threw in some calls
> > > with BOOT_MEM_RESERVED, so we now have (printed on bootup):
> > 
> > Can you actually do that and have discontiguous memory work??  Why don't
> > you program the bridge based on your memory size, so that it would place
> > the first mem module at 0 and the second at 64MB?
> > 
> > Pete
> >  
> > > Determined physical RAM map:
> > >  memory: 04000000 @ 00000000 (usable)
> > >  memory: 0c000000 @ 04000000 (reserved)
> > >  memory: 04000000 @ 10000000 (usable)
> > >  memory: 0c000000 @ 14000000 (reserved)
> > > 
> > > Which looks okay to me.  The problem is, my ethernet driver has gone
> > > to the dogs.  It works, but it's _really_ slow and the console is
> > > printing out messages like:
> > > 
> > > eth0: Transmit timed out: status 0050  0c00 at 9710/9738 command
> > > 00000c00.
> > > eth0: Transmit timed out: status 0050  0c00 at 9745/9773 command
> > > 00000c00.
> > > eth0: Transmit timed out: status 0050  0c00 at 9801/9829 command
> > > 00000c00.
> > > 
> > > I'm guessing that something bad has happened in terms of what part of
> > > memory the ethernet controller allocates for it's descriptors... or
> > > something like that.  The fact that it works at all is puzzling.. I
> > > would have expected a more fatal mode of failure.
> > > 
> > > So, am I doing something wrong in setting up my memory map?  Is there
> > > something else I need to do when calling add_memory_region()?
> > > 
> > > Also, how are DMAable addresses handed out?  I'm wondering if the
> > > conversion between CPU address and PCI address is working correctly...
> > > I'm going to try to get a PCI analyizer, but I don't know how long
> > > that will take.
> > > 
> > > Thanks everyone for all your help... hopefully, I'll have this problem
> > > put to bed soon.
> > > 
> > > Matthew Dharm
> > > 
> > > --
> > > Matthew D. Dharm                            Senior Software Designer
> > > Momentum Computer Inc.                      1815 Aston Ave.  Suite 107
> > > (760) 431-8663 X-115                        Carlsbad, CA 92008-7310
> > > Momentum Works For You                      www.momenco.com
> > > 
> > > > -----Original Message-----
> > > > From: Pete Popov [mailto:ppopov@pacbell.net]
> > > > Sent: Wednesday, January 30, 2002 5:35 PM
> > > > To: Matthew Dharm
> > > > Cc: linux-mips
> > > > Subject: RE: More data: I've made a CVS build that doesn't crash!
> > > >
> > > >
> > > > On Wed, 2002-01-30 at 17:23, Matthew Dharm wrote:
> > > > > Well, I'm closer... and more confused.
> > > > >
> > > > > I've managed to make a 2.4.3 build which does not exhibit
> > > > any of the
> > > > > instability or crashing... but I did it by disabling half of the
> > > > > memory!
> > > > >
> > > > > In linux/arch/mips/gt64120/momenco_ocelot/setup.c is some
> > > > code to read
> > > > > a PLD and add a memory region.  64MByte is already added
> > > > much earlier,
> > > > > and now we're adding the rest.  The board I'm testing on
> > > > is 128MByte,
> > > > > so it tries to add another 64MByte region which is physically
> > > > > contiguous to the first region.
> > > > >
> > > > > As far as I can tell, all of my memory works perfectly.
> > > > I'm going to
> > > > > do some more tests, but both vxWorks and OpenBSD run on this board
> > > > > without any problems.
> > > > >
> > > > > So, can anyone think of some likely culprits for what is
> > > > wrong here?
> > > > > Some piece of code which only works with addresses under 64MByte,
> > > > > perhaps?
> > > >
> > > > And 2.4.2 works with all of the memory?
> > > >
> > > > Pete
> > > >
> > > 
> > 
> 
> -- 
> Matthew Dharm                              Work: mdharm@momenco.com
> Senior Software Designer, Momentum Computer
>