|
From: | steve freyder |
Subject: | Re: Emulation of armv7+e1000e+/dev/sda or /dev/mmcblk0 devices |
Date: | Sun, 18 Apr 2021 16:50:11 -0500 |
User-agent: | Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.9.1 |
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
[Prev in Thread] | Current Thread | [Next in Thread] |