Well, discontiguous memory works on all other arches I know (PPC and x86, at least), so why not here too? 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
