On Mon 05 Jan 1998, Julian Coleman wrote:
> Leo Weppelman wrote:
> > It looks like the same problem Benny had a while back. Making sure the
> > kernel runs in ST-ram fixed the problem. The 1.3 kernels will no longer
> > relocate by default, meaning that you have to force them out of ST-ram
> > instead of TT-ram. I don't remember if this was already the case in the
> > 1.3 alpha kernels. If you try to let the kernel _only_ use ST ram, it
> > probably will lockup because it has not enough memory to do the fsck's.
> >
> Thanks.  Yes.  However, I'm slightly confused now!  I compiled a kernel
> and when I ran loadbsd.ttp, it couldn't load it because the kernel was
> larger than the free ST-RAM.  I configured loadbsd.ttp to allocate memory
> from TT-RAM.  I assume that this makes it load the kernel into TT-RAM.

There are 3 things here:
  1) Loadbsd.ttp, first reads the kernel in an area it reserves by use of
     malloc(3). I it just loaded the kernel starting at phys. address 0,
     things start breaking a bit too soon ;-) So, the first complaint
     meant that loadbsd.ttp was not able to allocate enough space to read
     the kernel image.
  2) After loadbsd.ttp finishes reading the image, it turns off the MMU
     (amongst some other bookkeeping) and jumps into the image. Now, take
     a look at the code at the 'start' label in locore.s. The kernel image
     first copies itself (in 2 phases) to address 0! This is independent
     of a (possible) later relocation to TT-ram.
  3) When the kernel enters it's first C-function (start_c), it might
     decide to relocate again. This is controlled with the 'RELOC_KERNEL'
     option (see options(4) - whee, I _did_ document this!). You can also
     binpatch(1) the 'reloc_kernel' variable. Pre-1.3 kernels _always_
     relocated when enough TT-ram was found. The current 1.3 kernel _never_
     relocs unless specifically told.


> Does that mean that when I had the MMU fault panics with the bootx kernel,
> it was running in ST-RAM?  (I had a look through the kernel initialisation
> code, and I see that it doesn't relocate itself).  Can I tell if the kernel
> I'm running is in ST-RAM or TT-RAM?

It depends on the kernel version and the 'RELOC_KERNEL' option.

 [ ... ]
> I haven't had a MMU fault since I compiled a kernel, but I haven't done a
> large amount of compiling in one go yet.  I've been trying to get a driver
> for the Crazy Dots card to work :
> 
> I took the grfabs_et.c driver and tried to get a grfet attached to the  
> card.  I couldn't get that to work.  Then, I looked at the leo.c and
> if_le_vme.c files and now have a device that is probed and attached at
> boot time :

You _did_ take out the
    if(!(machineid & ATARI_HADES))
        return(0);

lines from ite_et.c? Actually while looking at this, this test should
be moved to 'et_probe_card()'. I agree that the ite/grf stuff is overly
complex. It should however not be too hard to get the vme card to work.


>         et0 at vme0 port 0xfebf000-0xfebfffff iomem 0xfec00000-0xfecfffff
> 
> I thought I should use the et4000 routines in the existing files, instead of
> (more or less) duplicating them.  For the moment, I put values into the
> et_priv struct (apart from pci_tag (which doesn't seem to be used anywhere))
> and just copied the routines from grfabs_et.c

Ideally, the grafabs_et.c code should be able to handle the PCI/ISA and VME
variants of the card. The differences are not _that_ big ;-)

> Presumably to use the card, I need to attach a grfet to it?  I'm not quite
> sure how to do that.  Also presumably, I should look at the XFree86 SVGA
> server for X?  I've seen some references to XFree86 - I take it that it is
> the same source?  Will there be an X distribution for 1.3, or should I just
> grab Xdaniver (aka 1.2)?

There will no X distrib for 1.3 very soon. Thomas Gerner is the one giving
the authoritative answers here (or going to be ;-)


> 
> Unrelated things -
> 
> I can't run gdb because of :
> 
> 	/usr/libexec/ld.so:gdb: libbfd.so.0.0: No such file or directory
> 
> I notice a libbfd directory in the gnu src, but I can't find it installed
> anywhere.

This file is in the 1.3 base set:
  leo: tar ztvf base.tgz | grep libbfd 
  -r--r--r-- bin/bin       309791 Dec 31 01:16 1997 ./usr/lib/libbfd.so.0.0

There were some things missing in the 1.3_ALPHA - sorry.

> I notice that date doesn't change the clock.  Is there any way to set it
> from NetBSD?  My battery is dead and I noticed when I rebooted that the
> date had gone back to 1989!  BTW, the system freezes for about 40 secs
> when you change the time 8.5 years!

There is some info on the clock-stuff in the FAQ. If I recall correctly,
there was a loop somewhere adding values to a timeval or something like
that. I forgot the exact info :-(

Leo.