[linux-cirrus] Re: bootmem_init_node failure with 64M TS-7250

Thanks for the quick response!

On Fri, 2006-12-29 at 03:20 +0100, Lennert Buytenhek wrote:
> On Thu, Dec 28, 2006 at 08:33:18PM -0500, Charles Moschel wrote:
> > Booting with four mem=8M@ (lower banks) on the command line works OK,
> > but only with 32M of course.  Adding any one of the single higher
> > 0xex000000 banks results in a hang.
> 
> The problem here is that Linux 2.6 ep93xx port is somewhat naive and
> expects all RAM to be within a 1G physical address range.  This isn't
> always true on ep93xx hardware (such as your board), but it _is_ true
> for all ep93xx hardware I have access to (for example, I have the 32M
> variant of the TS7250), so I never fixed the problem, even though Linux
> supports not having all RAM within a 1G range just fine.

Is it _worth_ fixing?  This board has (2) 32MB SDRAM chips, but there
are other TS boards that have a single 64M chip which would (I guess)
still have this problem [1].  I don't know the market, are there other
boards / manufacturers that would benefit from a proper fix?

> > 
> > Should I try a DISCONTIGMEM or SPARSEMEM build?
> 
> Yes, this is exactly what needs to be done to fix the problem in a
> generic way, but it does involve writing a bit of code.

Well, if it's more that sprinkling printks, tweaking #DEFINEs, or
editing .config files, I'm out of my league :)
> 
> Another option _might_ be to set PHYS_OFFSET to e0000000, and tell
> Redboot to load the kernel at 0xe0008000.  This will likely mess up ATAG
> passing (so you'll have to comment out the boot_params line in ts7250.c,
> hardcode the machine ID and pass mem= parameters for every memory block
> by hand), but it'll cause physical RAM to be within a 1G range (e0000000
> .. 1fffffff, (ab)using 4G address wrap) and might just work.

Yes, I saw that you made the suggestion of setting PHYS_OFFSET to
e0000000 earlier this year on the ts-7000 yahoo list [2].  I tried that
as well, but naively, didn't realize the other changes needed to be
made.  

Is it relatively simple for you to properly fix the problem once you
have access to an afflicted board?  Or would you prefer to go for the
SPARSEMEM fix, which I guess is more involved?

> (The kernel mapped the 0....... physical address range to c.......
> virtual, and if you use that rule (virtual = physical + 0xc0000000)
> for the e....... physical address range, you end up with a.......,
> which is under the c0000000-ffffffff kernel virtual area.)

Thanks!  A simple explanation that told me more than poring through the
code!

If I limit the kernel to 32M, could I use the upper banks as a 32M RAM
disk?  I remember seeing a driver for that under x86, don't know if it's
possible under arm.

Thanks again ........ Charlie


[1] http://tech.groups.yahoo.com/group/ts-7000/message/2698
[2] http://tech.groups.yahoo.com/group/ts-7000/message/2681

Other related posts: