Date: Mon, 20 Oct 2014 08:05:52 -0600 From: Warner Losh <imp@bsdimp.com> To: Ben Morrow <ben@morrow.me.uk> Cc: freebsd-mips@freebsd.org Subject: Re: Trying to get MALTA64 running under qemu Message-ID: <3A1572B8-1CCE-49FD-BA08-476D0B9D8AB2@bsdimp.com> In-Reply-To: <20141019223447.GB12023@anubis.morrow.me.uk> References: <20141018225950.GA12023@anubis.morrow.me.uk> <CAJ-Vmon5yFb7z5gDAZ4StAOY%2B05dBjd8w9u1PWZHR_ihynk9Ow@mail.gmail.com> <20141019223447.GB12023@anubis.morrow.me.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] On Oct 19, 2014, at 4:34 PM, Ben Morrow <ben@morrow.me.uk> wrote: > Adrian Chadd <adrian@freebsd.org> wrote: >> On 18 October 2014 15:59, Ben Morrow <ben@morrow.me.uk> wrote: >>> I'm considering buying an ERL to use as a local router, but before I did >>> I thought I'd make sure the ports I want to run work properly with MIPS, >>> so I'm trying to bring up a qemu-system-mips64 instance. I've built >>> world and kernel (using MALTA64) for mips.mips64, and built a disk image >>> following the instructions on the MipsEmulation page on the wiki. The >>> source I am using is a slightly patched 10-STABLE from 2014-09-09; the >>> patches have nothing to do with MIPS. >>> >>> However, when I try to bring qemu up, the system appears to hang after >>> probing the ata devices. Over the course of about 30 seconds the qemu >>> process goes up to 100% of one CPU, and no more output appears on the >>> console. This appears to happen regardless of the disk images I pass to >>> qemu; I've tried passing a UFS image, a file full of zeros, no disks at >>> all, and (just in case) both -hda and -hdc. I've included the boot log >>> below; I'd appreciate any advice. >> >> can you try qemu-devel? > > Thank you, that works. (Good God, it's slow... I wonder how hard it > would be to replace cc with something that runs a cross-compiler on the > host? Maybe I can do something with distcc...) I’ve been helping Sean Bruno do exactly this, but I think for mips32. You build a chroot with the full world, then you build x86 binaries to produce mips32/64 output and replace the cc, et al, in the chroot with those. Makes things quite a bit faster. Still not quite as fast as a full native cross build, but much faster than pure user mode and more reliable than the current state of the art in cross building. Warner [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJURRbAAAoJEGwc0Sh9sBEAwnoP/3Euqbp/5sMc9JAP/ygQh8NX ZxpZalataAzZodceCE7kpzWY3CQ/ggHUwq+uCYC0S/nipTBG+Odrwy3azdCvFZXq Jm4hmMfLhzGwzchBbMIDSK9Ak1ioUgl4/4EgD3FYOTaHHfUXha/hdCyE/puKEN5z jyAjeV7a9CWKJ+D91B6zfX5UXL6QK4be+ZGit4Y8gvBdJY0CH6EA3ZTQpo1fmAfn d5GGee8S+bobgZG3gYQ7nXelWlB4E3wcjYkq07cwv7/H0iqql+Il73lmxlb5KX4h WGIcphc+hlepAuhdOnEM+mJYgph8ApsU2aQ/RaTiydaLlAw75PcbEjLzTWQXZpFs g867bYMdCjajmnPMntrYWTksPGu9COOunWaR0rCAi+JxEF961A7Yafb7jzc66he5 vcgw7x8dgiwOnRMYW2U1pBEVo47u3uQVvZdIAYK6FkWatXCluCHzlI2zjTUEGNmx BkTeqtoB1r6kl1/PBJB1th/jEu4aB4QZXRtalLf90gzgN8TKLVqoImkoar0aJzjg 2GqVVMxEtGJPAPd7TCvpvvGbwaMRCI1Jud4Z14oq+Ynj8BSCTXWavNQt/Wd7MIG8 ND8IKYs5JrmmKfSXcAovZL2Itc4RyAPmwLISMPqbe1f7kOrvOtyL+hqMJwnLnzXn t9EGMO8LUZ/sOOta96FQ =aevB -----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3A1572B8-1CCE-49FD-BA08-476D0B9D8AB2>