On 08/01/12 13:36, Andreas Schwab wrote:
Alan Hourihane <alanh@xxxxxxxxxxxxxx> writes:
Now the next problem is that the console is all corrupted because atafb
initializes and shows this...
atafb_init: start
atafb_init: initializing TT hw
atafb: screen_base 0046e000 real_screen_base 0046e000 screen_len 311296
Determined 640x480, depth 4
virtual 640x972
Now, that screen_base is above 4MB, and I've only got 4MB STRAM.
screen_base is a virtual address, the physical address is actually
0x146e000.
I thought that might be the case, given the TTRAM segment offset. But
still, it's in the wrong area.
But there's also this further up the boot log.
Ignoring memory chunk at 0x0:0x400000 before the first chunk
Since 12d810c1b8c2b913d48e629e2b5c01d105029839 (m68k: discontinuous
memory support) there is no longer support for memory regions with
physical addresses that are out of order. Before that, if the kernel
was loaded to TT-RAM the ST-RAM was virtually mapped just after TT-RAM.
Thanks for the pointer.
Alan.
--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
