Roger:

> I'm now done with the Cross-Compiler env. Running on a i386 Netbsd 1.4.1

Great!

> How about compering our Cross env?

Sure.  Remember that my host is also NetBSD-1.4.1.  My first stage is to
practice cross-building the NetBSD-current tree using the cross-development
tools in /usr/pkgsrc/cross/i386-netbsdelf.  When successful, I will have an
i386 NetBSD-current system.

I first downloaded the tarballs from the NetBSD-current/tar_balls directory,
then cracked them and updated them with cvs.  To do the actual build, I've
created a little script I call /usr/local/bin/xmake:

    #!/bin/sh

    # Cross-make using any NetBSD source tree


    # choose target

    XGNU_ARCH=i386-netbsdelf
    export MACHINE_ARCH=i386
    export MACHINE=i386


    # set up cross translators

    XPREFIX="/usr/pkg/cross/bin/${XGNU_ARCH}-"

    export AR=${XPREFIX}ar
    export RANLIB=${XPREFIX}ranlib
    export AS=${XPREFIX}as
    export "CPP=${XPREFIX}cc -E -"
    export CC=${XPREFIX}cc
    export CXX=${XPREFIX}c++
    export FC=${XPREFIX}f77
    export LD=${XPREFIX}ld
    export NM=${XPREFIX}nm


    # set up directory structure

    BASEDIR=/usr/current

    export DESTDIR=${BASEDIR}/dst.${MACHINE}
    export BSDSRCDIR=${BASEDIR}/src
    export BSDOBJDIR=${BASEDIR}/obj 
    export OBJMACHINE=1
    export USR_OBJMACHINE=1


    # run make with include files from new source tree

    export MAKEFLAGS="-m ${BASEDIR}/src/share/mk"

    make $*

In this script, I can change my target architecture using XGNU_ARCH,
MACHINE_ARCH, and MACHINE.  My NetBSD-current sources, objects, and
destination directory are all in BASEDIR.

I call the script with the following sequence:

    cd /usr/current
    mkdir dst.i386
    mkdir obj.i386
    cd src
    make obj
    make build

So far, I can build the libraries and some of the programs in /usr/bin. 
I've encountered two problems so far:

1.  In bin/dd/dd.c (for example, there is at least one other):  The function
err(3) is specified in the man page to accept either a printf-style
formatting string, or NULL.  The header file <err.h> which provides err(3)
uses the gcc printf-format checking attribute to get gcc to test the format
string for correctness.

Unfortunately, the printf checker in egcs-1.1.1 seems to have been tightend
up so it now rejects both NULL pointers and null strings ("").  I've patched
around this by adding -Wno-format to CFLAGS in share/mk/bsd.sys.mk.

This is obviously not a good long-term solution.  One of the following is
probably necessary:

  a.  Patch egcs to accept NULL pointers in format strings.
  b.  Fix dd.c (and at least one other, I forget now which one) to use a
      nearly-empty string (" ") instead of the NULL pointer.

I'm willing to do either one, but being new to NetBSD, I'm not sure who can
say which one to choose.  (Personally, I think "a" is probably a better
choice.)

2.  In lib/libipsec (and at least one other), the makefile has CFLAGS+=-g,
which turns on debugging.  This causes undefined references to symbols like
"Ltext0" and "Ltext1" in the .stabs statements at the beginning of the
compiler's assembly output.  (The actual definitions are ".Ltext0" and
".Ltext1", which is the correct form for ELF, where leading underscores are
not used.)

This seems to be a side effect of the change from using leading underscores
in aout format to not using leading underscores in ELF format, but I haven't
tracked down the exact cause yet.
 
> To morrow i will throw my self deep into the kernel.
> I will copy the ofpcc too m8xx.
> 1. Aim to document the locore.s for every function and what it should 
> do.
> 2. Will try to wright som buffer code for the administrator serial port.
>     I have not checked how compatibla the adm serial port is between 
> 821 and 850.
> This is what i will do this weekend.
> 
> Do you want a update of what i discover?

Absolutely.
 
> I belive that you will have code runing before me, our self made
> develop-card is almost ready to be send to a card manucahter.

You may be faster, as my time is somewhat limited.

> Question 1:
> will you have interupt vector table in Eprom or Ram?

The board we will use comes with a boot ROM with a hex monitor which can
load the NetBSD kernel automatically from Flash ROM, floppy disk, or BOOTP
and TFTP via ethernet (!).  The reset vectors will, of course, be in the
ROM, but I expect to move the interrupt vector table to RAM after my code is
loaded and gets control.

Regards,

David Querbach
Real-Time Systems Inc.