Re: Linux/m68k on Atari
> > I think I reported first FastRAM problems like 10-12 years ago. The
> > symptoms were that time was running much faster (the bogomips value was
> > 3-4 times higher than normal) and there were many spurious interrupts
> > (/proc/interrupts). And the IDE was not running correctly (because of
> > that?).
> > We never figured out what was wrong - mainly because I was the only one
> > with an AfterBurner040 - so the workaround with kernel in ST-RAM became
> > sort of a given thing. I think I remember some TT030 were having similar
> > problems...
The TTs had similar problems, that's where the ST-RAM boot option was for IIRC.
I remember we had that discussion at that time, and I could not really figure
out what went wrong.
> Here is a rough timing between the two settings:
> 060 73MHz, 64MB Fast, boot from IDE hard disk partition, 2.6.26 kernel.
> FastRam ST-Ram
> 0 0 Press key to boot Linux, in ataboot.tos
> 7s 15s Start loading stuff from disk
> - 6mn50s INIT: Entering runlevel: 2
> 60s 7mn25s Login prompt
> 0 0 Enter 'reboot' command in shell
> 15s 1mn12s Reset
> (ST-Ram = Nice handbreak, isn't it?)
We knew that :-)
> Note: I blindly guessed the time for FastRam, as I get a black screen,
> but I was able to login and type reboot, so the console was ready. I
> suppose it's the problem of atafb screen being wrongly allocated in
> FastRam. I still did not manage to get serial console working, which
Thanks for testing this - sounds hopeful indeed.
Entirely possible. I'll have to look at the code but I suspect having the
kernel in FastRAM will make that chunk come mapped at 0x0 virtual, and be the
first in the memory bootinfo list.
I'll have a look at this.
> I'll need if someone fixes this atafb problem and I want to test the
Serial console is not more than directing output at SCC channel B, so no login
on the serial interface if you use serial console. You'd have to compile in the
SCC driver and have init run a getty process on the serial line if you want to
use serial for login.
A successful fix for the atafb problem should manifest itself by showing the
boot process on the screen :-)
> The various machines can be detected with cookies inside ataboot.tos,
> and I remember there was a routine originally that copied the kernel
> and the ramdisk to the final place where they execute. So it should be
> possible to get the most optimal setup on a given configuration.
Might be done, but just omitting the -s should already use FastRAM.