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:
>

Looks like I am hanging in userspace, here is my hang:

[    4.064068] scsi 0:0:0:0: Direct-Access     ATA      QEMU HARDDISK
  50   PQ: 0 ANSI: 5
[    4.075977] sd 0:0:0:0: [sda] 16464 512-byte logical blocks: (8.42
MB/8.03 MiB)
[    4.082427] sd 0:0:0:0: [sda] Write Protect is off
[    4.085379] sd 0:0:0:0: [sda] Write cache: enabled, read cache:
enabled, doesn't support DPO or FUA
[    4.118143] sd 0:0:0:0: [sda] Attached SCSI disk
[    5.972385] sun4i-emac 1c0b000.ethernet eth0: Link is Up -
100Mbps/Full - flow control off
[    5.988629] Sending DHCP requests ., OK
[    6.011625] IP-Config: Got DHCP answer from 10.0.2.2, my address is 10.0.2.15
[    6.021258] IP-Config: Complete:
[    6.022075]      device=eth0, hwaddr=0a:80:64:4f:43:ec,
ipaddr=10.0.2.15, mask=255.255.255.0, gw=10.0.2.2
[    6.023220]      host=10.0.2.15, domain=, nis-domain=(none)
[    6.023751]      bootserver=10.0.2.2, rootserver=10.0.2.2, rootpath=
[    6.024436]      nameserver0=10.0.2.3
[    6.025489] usb2-vbus: disabling
[    6.025876] usb1-vbus: disabling
[    6.026194] vcc5v0: disabling
[    6.026514] vcc3v0: disabling
[    6.148152] EXT4-fs (sda): recovery complete
[    6.150995] EXT4-fs (sda): mounted filesystem with ordered data
mode. Opts: (null)
[    6.153751] VFS: Mounted root (ext4 filesystem) on device 8:0.
[    6.157800] devtmpfs: mounted
[    6.179159] Freeing unused kernel memory: 944K (c0d5c000 - c0e48000)
[    7.442057] udevd[76]: starting version 182
[   11.549686] random: nonblocking pool is initialized
[   13.536968] EXT4-fs (sda): re-mounted. Opts: data=ordered
[   16.163781] sunxi-rtc 1c20d00.rtc: Failed to set rtc time.

It is highly likely that someone from sunxi knows what is up, given
the yocto meta-layer works if you have anyone you can CC.

> 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.
>

That sounds like a bug and should definately be fixed. We should have
cpus that do support EL3 saying they dont (due to legacy and lack of
testing) but not the other way round.

Regards,
Peter

> Beniamino