Jesse Off wrote:
> --- In uhmgawa <> wrote:
>
> > The edp9302 board has a 256Mb (32MB) SDRAM configured
> > as (IIRC) 16MB+16MB. The only memory usage scenario
> > where I seem to squeak by for hours is with mem=
> > but not otherwise. Even specifying a single bank of
> > mem= results in the above crash scenario after
> > a few minutes. Unsure whether this relates to a HW
> > problem in this particular patient though..
>
> Its very unlikely a hardware problem. The boards sit on a burn-in
> table for many hours (sometimes days) before shipment running
> various SDRAM tests (among other things) and there a very few SDRAM
> failure modes that manifest with aging.
Note this is a Cirrus edp9302 board. Also u-boot's memory
test complained sporadically of discovering inverted data so
that brought the target hardware under suspicion. Now I
strongly suspect this is a u-boot memory mis-mapping issue.
> Actually, the type of crash
> you describe is exactly what we were running into trying to get 2.6
> to work in late 2004.
See below.
> The ep9302 fragments memory differently than the ep9312,ep9315,
> etc.. A 32 MB SDRAM appears in 4 8MB chunks at 0x0, 0x100000,
> 0x4000000, and 0x5000000.
I'm assuming you intended 0x01000000 rather than
0x00100000 above. I could have sworn that had
resulted in a similar failure as I described
previously. However I just retried doing so and
haven't hit the problem.
Looking at the user manual for the ep9301/2 table
10-11 indicates a 256Mb sdram would be seen as 8
segments of 4MB, which empirically doesn't appear
to be correct. Interpreting table 10-10 it is
logical A23 which isn't present in the dram
ras/cas address multiplex. So this gives a bank
size of (A22:A1) 2^22 -> 4M 16 bit words or 8MB.
The omission of logical A23 causes indexing to
continue with A24 so the banks appear on 2^24
0x0100,0000 (16MB) boundaries. However logical
A25 which multiplexes to sdram physical pin A9
is a n/c for the cas cycle such that we have
another hole at 2^25 0x0200,0000 address bit
giving:
0x0000,0000 8MB bank 0 at +0x0..0x3f,ffff (alias at +0x40,0000)
0x0100,0000 8MB bank 1 at +0x0..0x3f,ffff (alias at +0x40,0000)
0x0200,0000 alias of 0x0000,0000
0x0300,0000 alias of 0x0100,0000
0x0400,0000 8MB bank 2 at +0x0..0x3f,ffff (alias at +0x40,0000)
0x0500,0000 8MB bank 3 at +0x0..0x3f,ffff (alias at +0x40,0000)
0x0600,0000 alias of 0x0400,0000
0x0700,0000 alias of 0x0500,0000
The result is there being quite a bit of memory
mapped onto the bus in the above interval but
there is more aliased space than actual memory.
I suspect this is the cause of these the seemingly
related memory corruption failures.
> We had to gut some
> of the VM system stuff in 2.4 to get this to work properly and even
> then it was a major PITA-- definitely more work than we were hoping
> to have to do for a BSP.
Haven't spent much time with 2.4 on the 93xx. I take it
you found "mem=" to be problematic?
In any case it would be better for the corresponding 93xx
config/setup to init meminfo.bank[] and dismiss the need
for the verbose shopping list on the kernel command line.
--
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/ts-7000/
<*> To unsubscribe from this group, send an email to:
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
|