Re: evbarm-earmv6hf in qemu

[email protected] (Michael van Elst) writes:

> [email protected] (Benny Siegert) writes:
>
>>I also just remembered that I do in fact have a RPi2 lying around =
>>somewhere, maybe that would work in terms of real hardware.
>
> While RPI2 can run earmv6hf, it's an arm v7. It might not be sufficient
> to test v6 compatibility.

I mentioned that too in the repost of the technique...

There is no doubt that the kernel will report itself as earmv6hf and if
you use userland from earmv6hf you are about as close as you can get
using the technique I mentioned.  However, if there is something or
other that probes the CPU for v7 features or uses instructions that are
present in v7 but not in v6 they will work with the A7 cpu and wouldn't
on a real v6 CPU type.  You would probably core dump on a real v6 CPU...

I suspect that it would have to be something or other that probes during
a BUILD of a particular package or something that dynamically determines
which instructions to use at run time.  If all it does is more or less
uses the results of "uname -p" than it will always choose the v6 path.

I have personally never ever come across anything like this, but I do
not discount that it might exist.  At one time I ran the same earmv6hf
userland (NetBSD userland and "product" code) on RPI0, RPI2 and RPI3
devices.  The kernels were, of course, different but all reported
themselves as earmv6hf.  Now, I routinely build everything for earmv6hf
on my qemu VM using the v7 CPU and the technique I mentioned, and run it
on a RPI0 which is a real v6 CPU.







-- 
Brad Spencer - [email protected] - KC8VKS - http://anduin.eldar.org