Seems to me that the one thing that I had to do when net booting on a  
MCP750/MCPN750 was to switch the net boot mode within PPCBUG.  For  
some reason, though my memory may be wrong, it had to use the  older,  
non-prep, boot mode.

Check the mailing PREP mailing lists as I posted some patches (v1.6  
kernel) that I required to get the kernel booted successfully on an  
MCP750/MPCN750.

Unfortunately I don't have much time at the moment, and not likely to  
have any until mid summer!  Otherwise I'd be quite happy to help out  
sanitizing a port to these boards.

Cheers,
Michael



On May 4, 2005, at 10:15 AM, Christos Zoulas wrote:

> In article <20050504135715.GA23700@pell.home.ka8zrt.com>,
> Douglas Wade Needham  <cinnion@ka8zrt.com> wrote:
>
> Actually I have changed my mind and I am working on fixing make so
> that dependencies work when specified on these targets. I have it
> working on compat-mode, but not in parallel make mode, because it
> is complicated to cleanup the state of the parallel issued jobs to
> handle the .INTERRUPT case. I might punt and issue the .BEGIN,
> .INTERRUPT, and .END jobs serially.
>
> christos
>
>
>> 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!
>>
>>
>
>
>
>