On Sun, Jan 8, 2012 at 05:13, Michael Schmitz <schmitzmic@xxxxxxxxxxxxxx> wrote:
For this option to work, ST-RAM first has to be accepted by memory init
(i.e. it has to be in the first chunk). We might have to resort to reserving
the entire ST-RAM for the kernel's use if the kernel is not residing in
ST-RAM (breaking the above assumption). Something similar is done for Amiga
chip RAM - exactly how does the chip RAM situation differ, Geert? Is chip
RAM being claimed by mem_init or is it being left aside?
Chip RAM is different in that Linux (unlike AmigaOS) doesn't use it as
system RAM.
Being on the Zorro II bus (first 16 MiB), it's slow on most machines and doesn't
support RMW cycles (needed for page tables) on Zorro III-capable machines.
In general, we don't use Z2 RAM as system memory on Z3 capable machines.
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.
static void set_screen_base(void *s_base)
{
unsigned long addr;
addr = virt_to_phys(s_base);
/* Setup Screen Memory */
shifter.bas_hi = (unsigned char)((addr & 0xff0000) >> 16);
shifter.bas_md = (unsigned char)((addr & 0x00ff00) >> 8);
shifter.bas_lo = (unsigned char)(addr & 0x0000ff);
}
It's limited to 24-bit addresses.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
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
