tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: armv6 on QEMU

Havard Eidnes <> writes:

> Hi,
> thanks for the recipe.
>> 4) Pull a copy down of the armv7.img.gz or build the earmv7hf release.
> If all you need this for, is the bootarm.efi file, you can get
> that from
> or corresponding for the release you want to spin up.

Ya, I realized that bootarm.efi is present in the artifact directory for
the earmv7hf release after I sent the email.  Further, you can also get
the userland of a evbarm6hf release by using the sets, so all you may
need to do if just build the earmv6hf tools so you can build the
GENERICV6 kernel.  I am pretty sure that you must build the GENERICV6
kernel to get the proper platform set (i.e. the output from uname -p)
and/or spoof the platform somehow and use the GENERIC kernel (i.e. a
armv7+ kernel) with a armv6 userland.

>> 6) There are a couple of ways to proceed at this point..  if you can get
>> the FFS mounted from the armv7.img and rpi.img images you can create the
>> needed parts from those (I was not able to do this from a amd64 box,
>> BTW, but YMMV).  If that doesn't work for whatever reason, create a
>> image with a MSDOS MBR on it that has a 80MB 32bit FAT and a FFS format
>> 1 filesystem for the rest of the disk (newfs -O1 ....).  Don't forget to
>> put a MBR on it with fdisk and make the MS-DOS filesystem active.
> I managed to do this part on NetBSD/amd64 8.0 by using a vnd
> device:
> vnconfig -c /dev/vnd0d rpi.img
> fdisk vnd0
> disklabel vnd0
> mount -t msdos /dev/vnd0e /mnt
> ...
> umount /mnt
> mount -t ffs /dev/vnd0a /mnt
> ...
> umount /mnt
> vnconfig -u vnd0

Oh sure.. However, I have a amd64/9.2_STABLE Xen DOMU where if I try
doing that I get some sort of "invalid superblock" from the mount
command for the FFS side.  The MS-DOS side works fine.  Futher, it works
just fine in other places, just not on that DOMU...  hence the YMMV.

> I do not yet have liftoff in my effort to boot an armv6 kernel
> yet, though; I'm hitting a kernel assert in config_vsearch() in
> subr_autoconf.c:
>    KASSERT(ifattr || cfdriver_iattr_count(parent->dv_cfdriver) < 2);
> fires for me.  I mistakenly built from a 9.99.92 tree, though, so
> I'm reverting my tree and re-trying with 9.0.

You will REALLY want to build a very recent kernel if you try -current.
There was a fatal bug in the vio driver set (it effects vioif and the
blk driver) that was fixed very recently that will panic on boot in
QEMU.  I don't remember if the assert you mentioned is it, but it could
have been.

I have now done this technique for a very recent 9.99.101 and a
9.2_STABLE worlds that I typically use and it appears to work just fine.

> Regards,
> - Håvard

Brad Spencer - - KC8VKS -

Home | Main Index | Thread Index | Old Index