Re: [Qemu-devel] QEMU+Linux ARMv7A current state

[Peter Crosthwaite]

On Sun, Oct 4, 2015 at 12:56 PM, Beniamino Galvani <address@hidden> wrote:
> On Sat, Oct 03, 2015 at 02:31:08PM -0700, Peter Crosthwaite wrote:
>> QEMU cubieboard has no usable storage media, but the real hardware
>> does have AHCI sata. I added sysbus-ahci at the right place but turns
>> out the SATA controller has some custom power/clock (not really
>> sure??) registers specific to this SoC. It sets/clears bits then polls
>> them back expecting them to change to the other value asynchronously.
>> The kernel device probe then times-out. So I subclassed sysbus-ahci
>> and added the missing registers and forced the polled registers to the
>> "I'm done" state. It works.
>
> Cool, are you going to submit patches for this?
>
>> I am using meta-sunxi Yocto-layer to build out the allwinner custom
>> kernel/rootfs etc, and with the clock and Sata changes I get a boot.
>> But when I change to the unedited kernel+dtb+rootfs I get stuck. RTC
>> messages are around the point of failure which is not modelled in
>> QEMU, so that is suspect.
>
> I don't know, this needs some investigation; on my side a recent
> multi_v7_defconfig kernel, unmodified sun4i-a10-cubieboard.dtb and a
> rootfs built with buildroot mounted through NFS work just fine, with
> the mentioned warnings regarding clk registers and also these:
>

False alarm. There were some guest-side issues getting the login
console. With just the SATA (and/or Guenters initrd fix) we are good.

I'm dropping the CCM patches as they don't add anything real and don't
stop any real functionality.

Regards,
Peter

> Ignoring attempt to switch CPSR_A flag from non-secure world with SCR.AW bit 
> clear
> Ignoring attempt to switch CPSR_F flag from non-secure world with SCR.FW bit 
> clear
>
> which probably would be solved by setting the property 'has_el3' of
> the CPU to false before realization.
>
> Beniamino