Re: Emulation of armv7+e1000e+/dev/sda or /dev/mmcblk0 devices

[steve freyder]

On 4/18/2021 7:48 AM, Peter Maydell wrote:

> On Sun, 18 Apr 2021 at 02:42, steve freyder <steve@freyder.net> wrote:
> > I'm a new qemu-arm list member and looking to get an emulation of an
> > armv7 processor with a PCI bus, supporting an e1000e NIC, and some form
> > of storage device preferably SATA and [e]MMC - I have an iMX6 SOM custom
> > board with an e1000e on the carrier board via PCI that I'm attempting to
> > approximate.  I want to boot U-Boot (I've built U-Boot 5.2 with support
> > for MMC, SATA, and e100e networking).  I have the "virt" machine able to
> > boot U-Boot and see the e1000e, but I have found nothing that allows the
> > booted U-Boot see any MMC or SATA devices.  All attempts to use -sd, or
> > -drive to create some kind of MMC/SATA device have failed with what
> > appear to be (as I have been able to understand) the standard reasons,
> > missing busses, missing properties, etc, etc. A majority of searches
> > result in documentation from developers that's 5-10 or more years old,
> > so I'm hard-pressed to determine whether this is my own lack of
> > knowledge (probably YES), or whether I'm simply looking at stuff that's
> > been overcome by events.
> >       
> You have a couple of options:
>  (1) if one of the existing iMX6 board models (like sabrelite)
>      has enough of the devices that you need, you could use that
>  (2) you could use the 'virt' board. You don't say what command line
>      you've been trying, but it sounds to me like the problem is that
>      you aren't passing the command line options to either:
>       * use a virtio blk device (this is usually good if you just want
>         "some kind of disk storage"; u-boot should support virtio-blk
>         over pci, but I don't know if it's compiled in by default)
>       * provide a PCI emulation of some kind of disk controller
>         (eg scsi, ahci) as well as an emulation of the disk itself.
> Using a -drive option alone is sort of like asking to emulate "a board,
> and a disk drive on the table next to it, but not actually plugged into
> anything" :-)
>
> The upstream 'u-boot' has support for a qemu-arm board type which
> is documented to work on the 'virt' board and to support SATA disks
> via AHCI, including the command line options to set that up:
>
> https://github.com/u-boot/u-boot/blob/4f48163201f991de6d4a31b1c98a79e19971f57f/doc/board/emulation/qemu-arm.rst
>
> Have you tried those? If they don't work, what is the error that
> QEMU reports?
>
> thanks
> -- PMM
>
>

Peter, thanks for the quick response, I'm doing what you said and that's working much better, here's what I have now:

./qemu-system-arm -machine virt -bios u-boot.bin -nographic \
    -drive  if=pflash,format=raw,index=1,file=envstore.img  \
    -drive  if=none,format=raw,file=disk.img,id=mydisk -device ich9-ahci,id=ahci \
    -device ide-hd,drive=mydisk,bus=ahci.0 \
    -netdev user,id=net0 -device e1000,netdev=net0 \
    -device usb-ehci,id=ehci

I started with the example, got some errors about format on the disk.img and that ide-drive was unknown, so I added the ",format=raw" for disk.img, and changed what was originally "ide-drive" to "ide-hd".

This gets u-boot booted (excellent!), and it seems to be able to read the MAC from the E1000, and it's able to read and write the environment flash in "envstore.img".  When I go to access the SATA, (sata init) u-boot appears to be attempting to do so, but then a reset occurs:

U-Boot 2021.04-00640-g3f2e3c7845 (Apr 17 2021 - 19:34:25 +0000)

DRAM:  128 MiB
Flash: 64 MiB
MMC:
Loading Environment from Flash... OK
In:    serial
Out:   serial
Err:   serial
Net:   e1000: 52:54:00:12:34:56
       eth0: e1000#0
Hit any key to stop autoboot:  0
=> sata init
Target spinup took 0 ms.
SATA link 1 timeout.
SATA link 2 timeout.
SATA link 3 timeout.
SATA link 4 timeout.
SATA link 5 timeout.
AHCI 0001.0000 32 slots 6 ports 1.5 Gbps 0x3f impl SATA mode
flags: 64bit ncq only
prefetch abort
pc : [<e59ff010>]          lr : [<47f5853c>]
reloc pc : [<9dab7010>]    lr : [<0001053c>]
sp : 46e07d60  ip : 00000000     fp : 47f6be2c
r10: 00000002  r9 : 46f07ec0     r8 : 47fe5cc0
r7 : 46f0a190  r6 : 00000000     r5 : 47fe3dd8  r4 : 00000000
r3 : e59ff014  r2 : 00000002     r1 : 00000000  r0 : 46f09378
Flags: NzCv  IRQs off  FIQs off  Mode SVC_32
Code: data abort
pc : [<47f4a14c>]          lr : [<47f4a138>]
reloc pc : [<0000214c>]    lr : [<00002138>]
sp : 46e07c70  ip : 47fdb961     fp : 47f6be2c
r10: 00000002  r9 : 46f07ec0     r8 : 47fe5cc0
r7 : 47fd5ac2  r6 : 47fd5aca     r5 : e59ff010  r4 : fffffffc
r3 : 09000000  r2 : 46f08eb0     r1 : 00000000  r0 : 00000006
Flags: NzCv  IRQs on  FIQs on  Mode SVC_32
Code: e59f706c e59f606c e3c55003 e3540000 (e7952104)
Resetting CPU ...

resetting ...

U-Boot 2021.04-00640-g3f2e3c7845 (Apr 17 2021 - 19:34:25 +0000)

My physical board's u-boot outputs this when I do "sata init":

U-Boot> sata init

AHCI 0001.0300 32 slots 1 ports 3 Gbps 0x1 impl SATA mode
flags: ncq stag pm led clo only pmp pio slum part

So I'm thinking the timeouts are probably understandable and then the "prefetch abort" and "data abort" with those accompanying register dumps must be coming from QEMU perhaps because of some device register accesses that u-boot performed during its sata init processing, is that a reasonable interpretation?

Thanks Peter, this is very encouraging!

Steve