On Thu, Aug 12, 2004 at 10:19:26AM +0200, Petr Stehlik wrote: > V ?t, 12. 08. 2004 v 02:21, Stephen R Marenka pí?e: > > We're planning d-i rc2. What atari kernel changes do ya'll want > > in there? bootloader? If we can get them into the archive, we can > > probably get them into rc2. > > I am glad you ask. The more I am looking into it the more work I see > that has to be done. Let me divide my thoughts into three areas: kernel, > bootstrap and installer. > > 1) Kernel: there is a fatal problem with the ST-RAM swap on Atari and a > cosmetic issue with penguin logo at bootup in monochrome mode on Atari > and Amiga. > > - first the cosmetic thing: I hope to send a simple patch to Chris > sometime today that will end this years known problem that just > irritates old or scares new linux users. That would be good to have in > rc2. > > - now the fatal thing: ST-RAM swap enabled (as it was before I suggested > to turn it off at compile time) causes immediate crash on both CT60 and > AB40. That's why I convinced you to turn it off sometime in late July. > However, at that time I didn't know that without ST-RAM swap the whole > system for allocation ST-RAM in kernel fails miserably. Luckily in the > meantime I developed a fix for the previously non-working stram_swap > runtime kernel parameter that has been included in m68k kernel (not sure > if Chris accepted it from me or if he gets it from upstream in a while). > With the patch applied it is safe to enable the ST-RAM swap at compile > time - which is what I would suggest to do in the debian kernels and > d-i. > > Please note that the ST-RAM swap is set to zero size (thus inactive) by > default and so the ST-RAM allocation (for example when video parameter > is not set to 'keep') is still buggy. The 'stram_swap' parameter allows > to play with it (enable it, disable it, enable but reserve only part of > ST-RAM to swap). The only question is what to set in the d-i bootstrap > so that most Atari users would be happy. As I wrote elsewhere I had > success with "stram_swap=1,400" (enable ST-RAM swap but allocate just > 400 kB). But I don't have the confidence to suggest this parameter in > the d-i bootstrap. What if it causes problem on one of the many > machines. I'd need more time for tests. > > Ideally, the ST-RAM swap support would be fixed but it is probably > matter of weeks. Roman Hodek (the author) is quiet and there is no other > Atari kernel developer, it seems. Even if we don't know what to set, it's seems worth having that patched kernel in debian. If Christian will build it and ya'll can test it, then we'll go for putting it in. > 2) the Atari bootstrap: > > first, the most important question is who builds the bootstra.prg and > how. Roman Hodek (the atari-bootstrap.deb maintainer) does not have > crosscompiler anymore so he is unable to build it. But I noticed the > timestamp of the bootstrap changes in the daily builds so is it being > rebuilt daily or not? I am asking because I am able to build the > bootstrap but it's over twice the size of the bootstrap you provide. It's just being copied into the archive daily. > Then, even without recompiling there is a simple thing that would make > users happy: each Atari binary has a header where two bits have special > meaning. "Load to TT/FastRAM" and "Allocate from TT/FastRAM". The neat > thing is that user himself can decide whether a program runs in ST or > TT/FastRAM and whether it allocates RAM from ST-RAM or TT/FastRAM. The > unfortunate thing with d-i is that users cannot change these bits easily > when the binary is hidden in floppy-boot.img. Hey, does that mean floppy-boot.img actually works? That would be good to know. > 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?). We don't have a firm date, but it's supposed to be released by the end of the month. So anything going in had probably better already be working in the archive a week before that. > I can clear the flags in the bootstra.prg for you but if it's recompiled > daily then we need to find a way how to clear them automatically. It's not. > Note that the bootstrap needs a lot of other work and I am working on it > but this simple change would make it easier for users, I believe. > > BTW, I wish there was more active Falcon and TT users in the debian-m68k > list so that these proposal I am making could be immediately discussed > in the list and tested by the users. You and me both. > 3) the d-i itself > > Here only the 'bogl' makes problems. As it simply doesn't implement > bitplane graphics support the d-i must be able to fall back to non-fb > mode (or something) as soon as the bogl returns "don't know screen type > 2". > > As always, the correct solution is to write the bitplanes support into > bogl. I looked into it and I believe in a two or four days it could be > done. I just don't have enough time for all these tasks :-( > > If it's impossible to provide the clean fallback when bogl fails then I > am afraid we'd have to give up on the framebuffer altogether. Since > forcing the users to always install in monochrome mode (or truecolor) > might not be the best option... Or perhaps put all available manpower > into fixing bogl? Amiga users would be happy, too. I can't tell you what the right thing to do is. Probably this should be the last of the three. > That's it. Most parts of this mail should better go to the mailing list > for discussion by other Atari users but as I said, I am afraid there > aren't many of them. Feel free to forward it there or whatever. Done. -- Stephen R. Marenka If life's not fun, you're not doing it right! <stephen@marenka.net>
Attachment:
signature.asc
Description: Digital signature