On 07/01/12 06:47, Michael Schmitz wrote:
Hi Guys,
O.k. I'm passed the unexpected interrupt problem.
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.
You need to reserve ST-RAM for use by late initializing drivers -
stram_pool=512k would be a good start. Not sure this works with only
4MB of ST-RAM though.
I saw this option and I don't understand why it even exists. ST-RAM is
being sent by the bootloader with it's start (0) and size. ST-RAM always
starts at 0. So it's perfectly detectable, so why the need for an option
to specify the ST-RAM pool size ?
But there's also this further up the boot log.
Ignoring memory chunk at 0x0:0x400000 before the first chunk
Fix your bootloader or use a memfile to make use of this area!
I tried a memfile, but that just produces the same message.
Looks like your kernel gets placed in TT-RAM (because of size?) and
hence TT-RAM is listed as the first memory chunk. I don't think
ataboot supports a memfile, so it remains the first chunk?
No, because I don't use "-s" on the bootloader. That means it loads the
kernel in TTRAM.
I've tried to play around with the MM init code to circumvent this in
the past, to no avail. I think memory chunks have to be listed in
strict order for MM init to work. I don't think reordering the memory
chunk list once the kernel has started will work, so implementing the
memfile option in ataboot may be necessary.
I think anyone with ARanyM should be able to see this problem, by
setting their STRAM to 4MB and removing the "-s" flag from the
bootstra.tos app, to load the kernel in TTRAM.
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
