Re: Atari TT (next)

Geert Uytterhoeven
2012-01-08T10:20:58Z

On Sun, Jan 8, 2012 at 05:13, Michael Schmitz <schmitzmic@googlemail.com> 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@linux-m68k.org

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