Come to think of it - does the TT video chipset actually require
screen memory to reside in ST-RAM? If it's fully 32 bit addressed we
should not have any problems with TT-RAM. The problems you see might
be caused by a fault in the TT codepath in atafb - I'm unsure this has
been tested since the last atafb rewrite.
Looking at atafb, we always allocate FB memory from STRAM unless it's an
external video card, i.e. VME, ISA etc.
That's right - but in your case ST-RAM is not being mapped at all so
it can't be used. You will get a chunk of TT-RAM assigned to atafb
(fallback in case there's no more ST-RAM), the framebuffer code will
happily draw there but the shifter cannot access it.
Can you try to have the kernel placed in ST-RAM?
No, the kernel is too big. I've only got 4MB ST-RAM. And getting more on
the TT is pretty rare as the only other option is 10MB using the onboard
2MB and an 8MB upgrade board.
You may have to pare the kernel down to the bare minimum (i.e.
modularize about everything you don't need to boot to initrd). Not
sure where the limit for this is these days.
You're right, this should be possible to test with ARAnyM - the
behavior is not new though. Loading the kernel in TT-RAM has been
problematic on the Falcon for a long time now.
Sure, but by default Falcon's have only 4MB ST-RAM too, and yes lots of
people have 14MB of ST-RAM now, but it's not uncommon to have 4MB ST-RAM.
I think my Falcon is the only machine kernels have been tested on in
the last few years - I've got 14MB ST-RAM so I was never affected. I
had played with getting the kernel run in TT-RAM briefly but MM is not
my strong suit so I never got anywhere.
I'll dig in.
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