Re: Atari Updates for d-i rc2
V Čt, 12. 08. 2004 v 14:23, Christian T. Steigies píše:
> I'd prefer if your patches are in the linx-m68k CVS.
the stram_swap fix has been accepted by Geert into linux-m68k CVS some
time ago, as I thought had clearly written in the original mail:
http://linux-m68k-cvs.apia.dhs.org/~geert/linux-m68k-2.4.x-merging/161-stram.diff
The penguin logo fix was sent to everybody concerned a hour ago. Not
sure if Geert accepts it into linux-m68k CVS or if it has to go via the
fb guys to Linus and then back.
> > > OK, enough theory, now to the real life: on Falcon with at least AB40
> > > and CT2 (accelerators providing also FastRAM) the bootstrap makes sure
> > > to quit if either of these bits is set. In order to make it easier for
> > > the user I would suggest to always clear the "Load to TT/FastRAM" flag.
> > > As for the "Allocate from" flag, it cannot be cleared for all users,
> > > unfortunately (it would cause problems on machines with low ST-RAM that
> > > have good TT-RAM, like TT030 or CT60). I am working on a solution (not
> > > sure if I get it ready for rc2 - how much time is it, anyway?).
>
> Please do not break CT60 support.
I surely won't.
The issue with these two bits is as follows:
1) Load to TT-RAM
if this bit is set (as it currently is) then the bootstrap is loaded to
TT/FastRAM (if available) and runs there. The bootstrap specifically
checks for AB40 and CT2 machines and refuses to run when it's in
FastRAM. The reason is that as soon as it disables MMU it would
basically disappear from memory because the FastRAM mapping on AB40
might not and on CT2 is not 1:1.
Other machines (including TT030 and CT60) do not care because they have
1:1 mapping.
When this bit is cleared then the bootstrap is loaded to ST-RAM and runs
there. This is OK for all machines. There is no problem with running
bootstrap in ST-RAM on any Atari hardware AFAIK.
Thus I would like to have this bit cleared since it can only help (AB40
and CT2) and doesn't hurt.
The bootstrap could probably be improved so that the MMU would be
disabled in a code that was first copied to ST-RAM but clearing the
"Load to TT RAM" bit is way simpler solution and is available now.
2) Allocate from TT-RAM
if this bit is set (as it currently is) then the bootstrap allocates RAM
for kernel and ramdisk from TT/FastRAM (if available). Later the
bootstrap makes sure that on AB40 and CT2 machines the allocated memory
is not from FastRAM and if it is (thanks to the bit set) then it simply
refuses to continue booting. It doesn't even offer allocating RAM from
ST-RAM. This is not good and should be fixed in the code. Besides, I
have a working code here that allows allocating the FastRAM. But the
code is unfinished and untested on more machines. Clearing the Allocate
bit is again simpler, proven and works for AB40 and CT2 users.
Clearing the bit for all machines (=in default d-i) itself wouldn't
break any other machine (not even CT60). But I am afraid that it could
potentially create problems together with the broken ST-RAM swap and so
I cannot suggest it.
That's basically what I said in the original mail. Clear the Load flag,
don't clear the Allocate flag. Although I have just realized that this
half solution doesn't help anyone yet. So I'll better finish the
bootstrap changes.
The open question is who is able to build the bootstrap so it's only 53
kB?
Petr
Reply to: