public inbox for linux-m68k@lists.linux-m68k.org
 help / color / mirror / Atom feed
From: Alan Hourihane <alanh@fairlite.co.uk>
To: Michael Schmitz <schmitzmic@googlemail.com>
Cc: Linux/m68k <linux-m68k@vger.kernel.org>,
	Geert Uytterhoeven <geert@linux-m68k.org>
Subject: Re: Atari TT (next)
Date: Sun, 08 Jan 2012 23:59:12 +0000	[thread overview]
Message-ID: <4F0A2DD0.4000707@fairlite.co.uk> (raw)
In-Reply-To: <CAOmrzkLH18VCY0dzJPM14dn5ccWmSBkiPzq8EFqnCDHiM3bECQ@mail.gmail.com>

On 08/01/12 23:51, Michael Schmitz wrote:
> Hi Alan,
>
>>> 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.

I understand, but the STRAM allocator is broken. It gives out TT-RAM. It
should never do that on a TT.

>>> 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.

Already tried that. Still too big, because we need buffers from STRAM too.

>>> 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.
> Much appreciated.
>

No probs. I'll report back when I have something.

Alan.

  reply	other threads:[~2012-01-08 23:59 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-07  1:27 Atari TT (next) Alan Hourihane
2012-01-07  6:47 ` Michael Schmitz
2012-01-07 16:59   ` Alan Hourihane
2012-01-08  0:46   ` Alan Hourihane
2012-01-08  4:13     ` Michael Schmitz
2012-01-08  9:35       ` Andreas Schwab
2012-01-08  9:42       ` Alan Hourihane
2012-01-08 23:51         ` Michael Schmitz
2012-01-08 23:59           ` Alan Hourihane [this message]
2012-01-09  0:05             ` Michael Schmitz
2012-01-09  0:14               ` Alan Hourihane
2012-01-09  0:23               ` Andreas Schwab
2012-01-09  3:17                 ` Michael Schmitz
2012-01-09  1:03               ` Alan Hourihane
2012-01-09  1:25                 ` Alan Hourihane
2012-01-09 10:40                   ` Andreas Schwab
2012-01-09 11:22                     ` Alan Hourihane
2012-01-09 12:14                     ` Geert Uytterhoeven
2012-01-09 12:40                       ` Tuomas Vainikka
2012-01-09 14:10                       ` [PATCH] m68k: fix assembler constraint to prevent overeager gcc optimisation Andreas Schwab
2012-01-22 10:15                         ` Geert Uytterhoeven
2012-01-22 10:53                           ` Geert Uytterhoeven
2012-01-22 12:42                           ` Andreas Schwab
2012-01-09  3:16                 ` Atari TT (next) Michael Schmitz
2012-01-27 17:01           ` Thorsten Glaser
2012-01-28 20:33             ` Michael Schmitz
2012-01-29  0:57               ` Thorsten Glaser
2012-01-29  9:42                 ` Geert Uytterhoeven
2012-01-29 19:55                   ` Thorsten Glaser
2012-01-29 21:56                     ` Geert Uytterhoeven
2012-01-08 10:20       ` Geert Uytterhoeven
2012-01-08 19:21         ` Michael Schmitz
2012-01-08 19:53           ` Geert Uytterhoeven
2012-01-08 23:42             ` Michael Schmitz
2012-01-08 22:05           ` Andreas Schwab
2012-01-08 23:39             ` Michael Schmitz
2012-01-08 23:49               ` Alan Hourihane
2012-01-08 23:58                 ` Michael Schmitz
2012-01-08 13:36 ` Andreas Schwab
2012-01-08 14:42   ` Alan Hourihane
2012-01-08 19:24   ` Michael Schmitz
2012-01-08 17:45 ` Geert Uytterhoeven
2012-01-08 19:50   ` Alan Hourihane

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4F0A2DD0.4000707@fairlite.co.uk \
    --to=alanh@fairlite.co.uk \
    --cc=geert@linux-m68k.org \
    --cc=linux-m68k@vger.kernel.org \
    --cc=schmitzmic@googlemail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox