Re: linux-2.4.20 CVS kernel-image for atari
> > > +#define NVRAM_BYTES (128-NVRAM_FIRST_BYTE)
> > > +
> >
> > That's guesswork?? I'll check my Atari tree to see what did work for me
> > last time I tried. I'm rather certain I posted the diff to linux-m68k at
> > the time.
>
> Entirely guesswork, I just copied what I saw in other arches. But Bjoern
> Buske sent me a private mail, explaining that it should be 50, or
> (64-NVRAM_FIRST_BYTE).
Sounds about right.
> > There's another change to the RTC code that's required to make it link, I
> > think.
>
> That whas to only change I needed to compile this file.
Fine, so that bit got fixed, finally.
> > > +#define PCIBIOS_MIN_IO 0x1000
> > > +#define PCIBIOS_MIN_MEM 0x10000000
> > > +
> > > struct pci_ops;
> > >
> > > /*
> > >
> > > It would be nice if somebody with atari knowlegde could check these (in if
> > > they are correct) and fix the problem.
> >
> > There's no PCI on Atari. These constants should be meaningless. If they're
> > actually used for something else (i.e. access to hardware registers), it
> > would be important to know if these are physical or kernel virtual
> > addresses.
>
> Well, guessed as well, it just needed some number to compile. I have no
> means of testing atari kernels... but it failed later, maybe I should switch
> off hades and co completely, just to get a kernel built.
Forgot the hades there... The hades PCI range should be found in the older
kernels:
/*
* On the Hades map the PCI memory, I/O and configuration areas
* (0x80000000 - 0xbfffffff).
*
* Settings: supervisor only, non-cacheable, serialized, read and write.
*/
if (MACH_IS_HADES) {
__asm__ __volatile__ ("movel %0,%/d0\n\t"
".chip 68040\n\t"
"movec %%d0,%%itt0\n\t"
"movec %%d0,%%dtt0\n\t"
".chip 68k\n\t"
: /* no outputs */
: "g" (0x803fa040)
: "d0");
}
There you are. IO is in the same space as memory physically; the PPC code
might be a good starting point to see how memory vs. IO access is handled
there. 0x1000 physical is going to hurt a lot :-)
> BTW
> buildd@aahz:~>uname -a
> Linux aahz 2.4.20 #1 Tue Mar 4 03:02:52 EST 2003 m68k unknown
> buildd@aahz:~>uptime
> 10:02:18 up 1 day, 13:09, 1 user, load average: 1.18, 1.09, 1.02
>
> Looks pretty stable till now, if we could get this built for the other
> subarches, too, we might still be in business for the next release.
Drop me a kernel image, or a short note where to get your source. Plus I'd
need a recent cross-gcc, it seems I misplaced the instructions/sources
from my last cross compiler build. The TT is still alive, the Falcon died
a while ago so I could at least test on TT. Not that I'm too optimistic
there (did someone fix the stram swap issues).
> Note: this is not the kernel that I suggested for the boot-floppies, this
> one is optimized for my box. It is missing devfs, will try that next time,
> and gvpscsi, since that made my box unhappy in 2.2.20, and maybe a few more
> details.
>
> But since nobody but me is testing amiga kernels nowadays, I might just as
> well declare this stable, build new boot-floppies with it, get rid of the
> other subarches and things become much easier. Objections? Oh, affs has
Keep 2.2 kernels around for boot-floppies. What are 2.4 features used for
on boot-floppies, exactly?
Since I'm only keeping the Atari for hysteric reasons, and not for any
real work we could reasonably drop Atari in the long term. Macs still make
up part of the buildd pool so be careful what you wish for :-)
> always been failing for me with 2.4.x kernels, so you still need a 2.2
> kernel if you want to copy a vmlinuz file to an amiga partition...
Someone (tm) needs to get into fs hacking and port hfs, affs and some
other legacy filesystems over to 2.4 ... or come up with a user space tool
for this, see hfsplusutils :-)
Michael
Reply to: