I think that you are very close to the solution.
charliem_1216 wrote:
>
> Hi Matthieu --
>
> --- In <ts-7000%40yahoogroups.com>,
> 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
> <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
> <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>
> <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/
|