Re: [Qemu-devel] Customizing ARM Emulation boards?

[Peter Maydell]

On 14 April 2016 at 18:03, Alexander Duff <address@hidden> wrote:
> (This is cross-posted from the general discussion mailing list)

(Doesn't appear to be cc'd anywhere but qemu-devel ?)

> I'm emulating routers running OpenWrt for ARM using the realview-eb-mpcore
> machine and I've run into the problem of not being able to create more than
> one NIC. For what it's worth, when specifying that the NIC should be an
> smc91c111, qemu-system-arm -M realview-eb-mpcore says that this machine
> doesn't support that device. When the device is unspecified, it defaults to
> the smc91c111 once the machine is booted. Every NIC after the first defaults
> to rtl8139, but emulation of the PCI bus is missing (I am unsure if it's
> missing due to the OpenWrt kernel built for ARM or something in QEMU) so
> these devices show in QEMU's monitor, but not on the guest. Since it's a
> router, I would very much like to have more than one ethernet port. I
> downloaded the QEMU source and looked through it to see how the devices are
> created and assigned. In realview.c (lines 265 through 281), I found the
> following code:
>
>     for(n = 0; n < nb_nics; n++) {
>         nd = &nd_table[n];
>
>         if (!done_nic && (!nd->model ||
>
> strcmp(nd->model, is_pb ? "lan9118" : "smc91c111") == 0)) {
>
>             if (is_pb) {
>                 lan9118_init(nd, 0x4e000000, pic[28]);
>             } else {
>                 smc91c111_init(nd, 0x4e000000, pic[28]);
>             }
>             done_nic = 1;
>         } else {
>             if (pci_bus) {
>                 pci_nic_init_nofail(nd, pci_bus, "rtl8139", NULL);
>             }
>         }
>     }
>
> So my understanding is that it checks to see if a NIC has been created. If
> it hasn't, it creates an smc91c111 NIC and maps it to 0x4e000000, then sets
> "done_nic" to 1 and creates all subsequent NICs as rtl8139 devices.

Yes (assuming you have PCI on the board, which I think for
realview-eb-mpcore you do).

> So, I have the following questions:
>
> 1) Could I make my own customized board by more-or-less copying the
> realview.c file and changing this section so that the first 8 or so NICs
> (however many I can fit in that memory space) are smc91c111 devices and
> offset them by the space it takes (I want to say 16 but I'll double check
> first)? The next address on the memory map is 0x4f00000000 (USB, which I
> don't need anyway).

Your problem would be that the kernel doesn't expect any other
NICs in this board, just the one in the standard location,
so it will ignore all the hardware it doesn't think exists.
(Also you would need to give them all IRQ lines.)

More generally, the realview board is a very very old one for QEMU,
and so the way it is written is a long way from current coding
recommended practices. Something added more recently (like one of
the xilinx boards or the raspi2 board) is more in line with how
you'd write a new board these days.

> 2) Is there any documentation on programming a custom board? In this case, I
> don't think I need it, but it would be good to have. I apologize if I've
> missed it, there are a lot of moving parts in this endeavor.

There isn't really, because adding a new board means writing a
lot of new C code. The rough answer is "look at the last ARM
board that got added and look at the commits where its devices,
SoC model and board model were added".

> 3) Is there a simpler way to get more than one ethernet port on a
> virtualized ARM machine? I've been working on this for a long time and I'm
> afraid I'm getting tunnel vision and missing an obvious solution.

If your board supports PCI (which I think this one does) then you
can just plug in more emulated PCI devices. e1000 is one, or you
can compile virtio support into your guest kernel and use the virtio
network device.

Roughly, if your guest doesn't care what hardware it's running
on then your best bet is to use "virt", which is intended mainly
for running virtual machines on but which has support for a
bunch of features like PCI and thus decent networking, disks,
larger RAM sizes, etc, as well as being better maintained and less
likely to have lurking bugs.

If your guest does care what hardware it's running on then unfortunately
you have to write code to emulate the realworld devices and board
that it wants to run on (and it's not likely to run right on
a frankenstein-board that's an eb-mpcore with nonstandard changes).

> 4) Is this the right mailing list?If there's a better place to ask this
> question or if anyone can point me in the right direction, I would be
> grateful for that information. I already posted on the OpenWrt forums and
> received 0 replies.

Yes, this is a good place to ask.

thanks
-- PMM