Hi Matthieu --
--- In Matthieu Crapet <> wrote:
>
> Greetings,
>
> I only tested on 32mo SDRAM. Anyone succesfully runned that kernel with
> 64mb ?
Maybe I am missing something obvious, but in this post:
http://marc.info/?l=linux-arm&m=122754446724900&w=4
Russel is suggesting a phys <-> virt mapping that should work for the
64MB TS boards:
<quote>
You want all these memory banks to end up between 0xc0000000 and something
reasonable below 0xff000000. You can't easily fit this sparsely populated
physical address space into that area without wasting a lot of virtual
memory space.
So, what about a non-linear mapping like this:
0x00000000 => 0xc0000000
0x01000000 => 0xc1000000
0x04000000 => 0xc4000000
0x05000000 => 0xc5000000
0xe0000000 => 0xc8000000
0xe1000000 => 0xc9000000
0xe4000000 => 0xcc000000
0xe5000000 => 0xcd000000
which can be achieved by:
static inline unsigned long __phys_to_virt(unsigned long pa)
{
return (pa & 0x07ffffff) | ((pa & 0xe0000000) ? 0x08000000 : 0);
}
static inline unsigned long __virt_to_phys(unsigned long va)
{
return (va & 0x07ffffff) | ((va & 0x08000000) ? 0xe0000000 : 0);
}
</quote>
These mapping functions are what you use in your patch. But the
functions don't do the mapping that is suggested: Don't they need an
additional " | 0xc000000"? As defined above, __phys_to_virt for
example, will map:
0x00000000 --> 0x00000000
0x05000000 --> 0x05000000
0xe5000000 --> 0x0d000000 etc, instead of what's listed above.
Adding a " | 0xc0000000" will produce the right mappings for
__phys_to_virt. __virt_to_phys would need to be fixed too. But like
I said, I might be missing something (maybe it is done elsewhere?).
Another post from Russel, this time for PXA300 moving to sparsemem,
has a different mapping suggestion here:
http://marc.info/?l=linux-arm-kernel&m=123187407030295&w=4
But I haven't worked through that or changed it for the (8) x 8MB case.
If this looks reasonable, I can test this tonight.
regards, .......... Charlie
>
> charliem_1216 wrote:
> >
> > --- In <ts-7000%40yahoogroups.com>,
> > "charliem_1216" <charliem_1216@> wrote:
> > >
> > > Hi Christian --
> > >
> > > I can help testing in the next day or so.
> > >
> > > regards, ...... Charlie
> > >
> >
> > OK, I spent some time tonight coming up to speed on this, and I think
> > there is still a problem with a 64M board (using 2 chip selects).
> > Mine is a TS-7250.
> >
> > After enabling debug_ll, and stuffing a printascii in kernel/printk.c,
> > I see:
> >
> > Using base address 0x00218000 and length 0x001d17a0
> > Uncompressing
> >
Linux.........................................................................................................................
> > done, booting .
> > <5>Linux version 2.6.28.4-m (gcc version 4.1.1
> > (CodeSourcery ARM Sourcery G++ 2006q3-26)) #4 PREEMPT Mon Feb 9
> > 23:43:46 EST 2009
> > CPU: ARM920T [41129200] revision 0 (ARMv4T), cr=40007177
> > CPU: VIVT data cache, VIVT instruction cache
> > Machine: Technologic Systems TS-72xx SBC
> > Memory policy: ECC disabled, Data cache writeback
> > <4>BUG: not creating mapping for 0xe0000000 at 0xa0000000 in user
region
> > <4>BUG: not creating mapping for 0xe1000000 at 0xa1000000 in user
region
> > <4>BUG: not creating mapping for 0xe4000000 at 0xa4000000 in user
region
> > <4>BUG: not creating mapping for 0xe5000000 at 0xa5000000 in user
region
> >
> > This is exactly what was happening before Brett's discontig patch.
> > Like Christian, I can boot OK with 32M by adding:
> > mem= mem= mem= mem= to the kernel command
line.
> >
> > [Oddly, the vmsplit config parameter was changed from ts7200_defconfig
> > after I ran menuconfig (but without changing the vmsplit setting).
> > VMSPLIT_3G was changed to VMSPLIT_1G. Same with PAGE_OFFSET, which
> > changed from 0xC0000000 to 0x4000000. Returning those to the values
> > in TS7250_defconfig did not fix the problem. Strange ... something to
> > watch out for]
> >
> > I even tried "#define SECTION_SIZE_BITS 23" rather than 24, since I
> > thought each node should be 8M not 16M, but that did not make any
> > progress.
> >
> > I'm not sure where to go from here. There have been a few other posts
> > to linux arm kernel ML with this problem (physical RAM needing more
> > that 1G address space), but I haven't seen any success stories yet.
> >
> > regards, ........ Charlie
> >
> > > > Any idea?
> > > >
> > > > Chris
> > > >
> > > >
> > > >
> > >
> >
> >
>
------------------------------------
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/ts-7000/
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
http://groups.yahoo.com/group/ts-7000/join
(Yahoo! ID required)
<*> To change settings via email:
<*> To unsubscribe from this group, send an email to:
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
|