MIPs Multilib network boot panics when looking for init

Michael J. Hammel cross-lfs at graphics-muse.org
Thu Jan 19 08:50:05 PST 2006


On Thu, 2006-01-19 at 07:53 -0800, Jim Gifford wrote:
> > And it appears to be the right kind of file (built with -meb -mabi=64 -
> > mtune=sb1 -march=mips64 for a Broadcom Bigsur board:
> > mjhammel(tty5)$ file /mnt/lfs-mips/sbin/init
> > /mnt/lfs-mips/sbin/init: ELF 64-bit MSB MIPS32 executable, MIPS, version
> > 1 (SYSV), for GNU/Linux 2.6.0, dynamically linked (uses shared libs),
> > stripped
> >
> >   
> I see something odd here. MIPS32 executable. 

I *think* this is correct - at least the MontaVista version says the
same thing for their 2.4 based distro on this platform.  If I leave out
-mtune=sb1 and -march=mips64 then I get MIPS-III executables. I don't
know if those work on the Broadcom bigsur board or not.  Since I'm
pretty sure using mtune and march is correct for this platform I'll
stick (for now) with what I get from those.

> Now I've seen this problem 
> before with my RaQ2, if the filesystem is not exported to what the 
> NFSROOT is expected to be with the firmware. In the case of the  RaQ2 it 
> was nfsroot. 

Not sure I know what you mean here.  The firmware for this particular
board is Broadcom's CFE and it passes the nfsroot path it gets via dhcp
to the Linux kernel via an environment variable, kind of like what LILO
and GRUB do in their config files.  So the nfs rootpath that's set up in
dhcp is what the kernel is getting - the kernel does print the correct
rootpath at boot time right before it mounts the remote path as the root
fs.

> The other time I've seen this issue the nfs server wasn't 
> advertising correctly, normally fixed by restarting the nfs server.

I checked that to be certain.  It's exported correctly.  

I think Ken's suggestion about the /tools path will help here.  I'll
take a look at that too.

Thanks.
-- 
Michael J. Hammel <cross-lfs at graphics-muse.org>




More information about the cross-lfs mailing list