version=3.0.2
Sender: port-prep-owner@NetBSD.org

First, a quick question...  I see that Christos and at least one other
person have fixed some of the files listed, other files such as
prep/stand/boot/Makefile are still needing fixed.  I was wondering if
anyone knew when prep/stand/boot/Makefile might possibly be fixed?
This is making it a real pain to do my nightly builds which I am using
to work on a port to the Motorola MCP-750 and Force CPCI-680.

Also, was there a message posted warning about the possible breakage
of builds when the changes to make were checked in?  Besides the two
messages in this thread, I could find none.  By my count, builds for
at least 7 different ports besides i386 were broken by this fix, and
something like this ideally should have warranted a heads up.

BTW, for those who are wondering, these CPCI cards show some promise.
From my reading, the MCP-750 appears to be configurable to be fully
compliant with v1.1 of the PREP specification.  It is presenting the
residual data as expected, and it will manually boot a binary
boot_com0 image from across the network.  Unfortunately, it does
something odd when autobooting which I have yet to fully diagnose, but
may have to do with a bug in PPCBUG not loading the image and
executing it properly.  I have been working on producing a library for
interfacing with PPCBUG, and once I get that done, I will be writing a
bootloader which will configure the Raven and Falcon chips and load a
kernel using DHCP and TFTP.

As for the CPCI-680, it appears to be at least partially compliant
with PREP v1.1, but boot_com0 hangs totally and requires a reset to
clear.  It may be that the registers are not being set properly when
transferring control over to boot_com0.  I figure after I get a boot
loader working on the MCP-750, I will try to get something going on
this board as well.  It may be that I will have to write a new
firmware and flash to these boards.  We shall see.

- Doug

Quoting Christos Zoulas (christos@tac.gw.com):
> In article <20050430233729.GA27406@spathi.chuq.com>,
> Chuck Silvers  <chuq@chuq.com> wrote:
> >I've noticed for a long time now that "build.sh -j 8 release" on i386
> >usually dies in the middle with errors like:
> >
> >...
> >--- dependall-ne2000_isa ---
> >ln -s /build/obj/build/src/sys/arch/i386/stand/netboot/lib .
> >--- dependall-3c90xb ---
> >--- __always_make_zlib ---
> >--- dependall-ne2000_isa ---
> >[ -d /build/obj/build/src/sys/arch/i386/stand/netboot/lib ] || mkdir
> >/build/obj/build/src/sys/arch/i386/stand/netboot/lib
> >--- dependall-pcnet_isapnp ---
> >--- lib ---
> >ln: ./lib: File exists
> >--- dependall-ne2000_isa ---
> >--- __always_make_kernlib ---
> >--- dependall-3c590 ---
> >--- netif_small.o ---
> >--- dependall-pcnet_isapnp ---
> >*** [lib] Error code 1
> >
> >
> >more recently I noticed that this problem is described by these PRs:
> >
> >9566	.BEGIN target does not follow dependencies
> >9567	.BEGIN targets use depencencies
> >
> >
> >so should we apply the changes from the PRs, or does someone want to change
> >make to actually process dependencies of .BEGIN?
> >
> >here's the list of makefiles under sys/arch that have this problem:
> >
> >./arc/stand/boot/Makefile:.BEGIN: machine mips
> >./evbarm/stand/gzboot/Makefile.gzboot:.BEGIN: machine
> >./hp700/stand/Makefile.inc:.BEGIN: machine hp700 hppa
> >./i386/stand/boot/Makefile.boot:.BEGIN: machine x86 lib
> >./i386/stand/bootxx/Makefile.bootxx:.BEGIN: machine x86 lib
> >./i386/stand/mbr/Makefile.mbr:.BEGIN: machine x86
> >./i386/stand/Makefile.booters:.BEGIN: machine x86 lib
> >./mvme68k/stand/installboot/Makefile:.BEGIN: machine
> >./news68k/stand/boot/Makefile:.BEGIN: machine m68k
> >./news68k/stand/bootxx/Makefile:.BEGIN: machine m68k
> >./prep/stand/boot/Makefile:.BEGIN: machine powerpc
> >./sun68k/stand/Makefile.inc:.BEGIN: machine m68k sun68k
> >
> >
> >I see that at least one of the instances mentioned in the PR,
> >pmax/stand/Makefile.booters, has been fixed differently than the PR suggests.
> >it would be good to be consistent with this.
> >
> >if we opt to leave .BEGIN the way it is now and not process its dependencies,
> >can we at least make it an error to specify dependencies for .BEGIN?
> 
> We should....
> 
> christos

-- 
Douglas Wade Needham - KA8ZRT        UN*X Consultant & UW/BSD kernel programmer
Email:  cinnion @ ka8zrt . com       http://cinnion.ka8zrt.com
Disclaimer: My opinions are my own.  Since I don't want them, why
            should my employer, or anybody else for that matter!