[U-Boot] [PATCH 0/3] Ethernet support for QEMU sifive_u machine

Mon Dec 24 06:31:12 UTC 2018

Hi Anup,

On Mon, Dec 24, 2018 at 1:41 PM Anup Patel <anup at brainfault.org> wrote:
>
> On Mon, Dec 24, 2018 at 6:59 AM Bin Meng <bmeng.cn at gmail.com> wrote:
> >
> > Hi Anup,
> >
> > On Wed, Dec 19, 2018 at 5:05 PM Bin Meng <bmeng.cn at gmail.com> wrote:
> > >
> > > Hi Anup,
> > >
> > > On Wed, Dec 19, 2018 at 2:32 PM Anup Patel <anup at brainfault.org> wrote:
> > > >
> > > > On Wed, Dec 19, 2018 at 11:02 AM Bin Meng <bmeng.cn at gmail.com> wrote:
> > > > >
> > > > > Hi Anup,
> > > > >
> > > > > On Wed, Dec 19, 2018 at 12:41 PM Anup Patel <anup at brainfault.org> wrote:
> > > > > >
> > > > > > On Tue, Dec 18, 2018 at 4:06 PM Bin Meng <bmeng.cn at gmail.com> wrote:
> > > > > > >
> > > > > > > Hi Anup,
> > > > > > >
> > > > > > > On Tue, Dec 18, 2018 at 6:33 PM Anup Patel <anup at brainfault.org> wrote:
> > > > > > > >
> > > > > > > > On Tue, Dec 18, 2018 at 3:21 PM Bin Meng <bmeng.cn at gmail.com> wrote:
> > > > > > > > >
> > > > > > > > > Hi Anup,
> > > > > > > > >
> > > > > > > > > On Mon, Dec 17, 2018 at 7:51 PM Anup Patel <anup at brainfault.org> wrote:
> > > > > > > > > >
> > > > > > > > > > This patchset enables Cadance MACB ethernet driver for
> > > > > > > > > > QEMU sifive_u machine. The Cadance MACB ethernet driver
> > > > > > > > > > works fine for QEMU sifive_u machince in both M-mode and
> > > > > > > > > > S-mode with some minor fixes.
> > > > > > > > > >
> > > > > > > > > > The patches are based upon latest RISC-V U-Boot tree
> > > > > > > > > > (git://git.denx.de/u-boot-riscv.git) at commit id
> > > > > > > > > > 9deb8d2fcd13d4a40a4e63c396fe4376af46efac
> > > > > > > > > >
> > > > > > > > > > To try on QEMU, please ensure following patches are
> > > > > > > > > > applied to QEMU sources:
> > > > > > > > > > https://patchwork.kernel.org/patch/10729579/
> > > > > > > > > > https://patchwork.kernel.org/patch/10729581/
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > What "-device " parameter should I tell QEMU to instantiate the MACB?
> > > > > > > > > "-device ?" does not give me anything that looks like MACB. Without a
> > > > > > > > > proper "-device " parameter, I can boot U-Boot on QEMU sifive_u and
> > > > > > > > > see U-Boot driver is probed, but a simple 'ping' test does not work.
> > > > > > > >
> > > > > > > > Try the following:
> > > > > > > > # setenv ipaddr 10.0.2.1
> > > > > > > > # ping 10.0.2.2
> > > > > > > >
> > > > > > >
> > > > > > > Yes, I have set up all the required network parameters.
> > > > > > >
> > > > > > > > The above works for me on QEMU.
> > > > > > >
> > > > > > > My understanding is that we need enable QEMU network via "-netdev "
> > > > > > > (either usr, or tap), with a corresponding "-device". I don't know how
> > > > > > > to set it up. What's your command line to test this?
> > > > > > >
> > > > > >
> > > > > > "-netdev" or "-device" parameters are not mandatory. By default, virtual
> > > > > > NICs are in NAT mode. The QEMU NAT gateway is at IP address
> > > > > > 10.0.2.2. We can always ping the NAT gateway when virtual NIC is in
> > > > > > NAT mode.
> > > > > >
> > > > > > Here's how I compile for M-mode:
> > > > > > # ARCH=riscv
> > > > > > # CROSS_COMPILE=riscv64-unknown-linux-gnu-
> > > > > > # make qemu-riscv64_defconfig
> > > > > > # make
> > > > > >
> > > > > > My U-boot log is as follows:
> > > > > >
> > > > > > anup at anup-ubuntu64:~/Work/riscv-test/u-boot$ qemu-system-riscv64 -M
> > > > > > sifive_u -m 256M -display none -serial stdio -kernel ./u-boot
> > > > > >
> > > > > >
> > > > > > U-Boot 2019.01-rc1-00948-ge6b3cdafd0 (Dec 19 2018 - 10:05:50 +0530)
> > > > > >
> > > > > > CPU:   rv64imafdcsu
> > > > > > Model: ucbbar,spike-bare,qemu
> > > > > > DRAM:  256 MiB
> > > > > > In:    uart at 10013000
> > > > > > Out:   uart at 10013000
> > > > > > Err:   uart at 10013000
> > > > > > Net:
> > > > > > Warning: ethernet at 100900fc (eth0) using random MAC address - f6:1f:8c:13:83:c0
> > > > > > eth0: ethernet at 100900fc
> > > > > > Hit any key to stop autoboot:  0
> > > > > >
> > > > > > Device 0: unknown device
> > > > > > ethernet at 100900fc: PHY present at 0
> > > > > > ethernet at 100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1)
> > > > > > BOOTP broadcast 1
> > > > > > DHCP client bound to address 10.0.2.15 (2 ms)
> > > > > > Using ethernet at 100900fc device
> > > > > > TFTP from server 10.0.2.2; our IP address is 10.0.2.15
> > > > > > Filename 'boot.scr.uimg'.
> > > > > > Load address: 0x82100000
> > > > > > Loading: *
> > > > > > TFTP error: 'Access violation' (2)
> > > > > > Not retrying...
> > > > > > ethernet at 100900fc: PHY present at 0
> > > > > > ethernet at 100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1)
> > > > > > BOOTP broadcast 1
> > > > > > DHCP client bound to address 10.0.2.15 (1 ms)
> > > > > > Using ethernet at 100900fc device
> > > > > > TFTP from server 10.0.2.2; our IP address is 10.0.2.15
> > > > > > Filename 'boot.scr.uimg'.
> > > > > > Load address: 0x81000000
> > > > > > Loading: *
> > > > > > TFTP error: 'Access violation' (2)
> > > > > > Not retrying...
> > > > > > => ping 10.0.2.2
> > > > > > ethernet at 100900fc: PHY present at 0
> > > > > > ethernet at 100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1)
> > > > > > Using ethernet at 100900fc device
> > > > > > host 10.0.2.2 is alive
> > > > > > =>
> > > > > > ethernet at 100900fc: PHY present at 0
> > > > > > ethernet at 100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1)
> > > > > > Using ethernet at 100900fc device
> > > > > > host 10.0.2.2 is alive
> > > > > > => qemu-system-riscv64: terminating on signal 2
> > > > > >
> > > > >
> > > > > I have always been using "qemu-system-riscv64 -nographic -M sifive_u
> > > > > -kernel u-boot" to test U-Boot on qemu risc-v.
> > > > > With above command, I can "ping 10.0.2.2" and get the exact the same
> > > > > result as yours.
> > > > >
> > > > > However I wanted to connect the tap interface to the emulated network
> > > > > controller for testing, that's why I wanted to use "-device" and
> > > > > "-netdev", but I don't know which device string I need to tell QEMU.
> > > > > After a bit googleing I got the following page:
> > > > > https://forums.xilinx.com/t5/Embedded-Processor-System-Design/Zynq-QEMU-Network-Issues/td-p/797050
> > > > >
> > > > > From the page it looks that the device should be "-device
> > > > > cadence_gem", but when I pass it to QEMU I got:
> > > > >
> > > > > qemu-system-riscv64: -device cadence_gem,netdev=net0: Parameter
> > > > > 'driver' expects pluggable device type
> > > > >
> > > > > It looks cadence_gem is not a pluggable device. Any ideas?
> > > >
> > > > I have mostly tried TAP devices with VirtIO-Net. I believe this could be
> > > > some bug in Cadence GEM emulation of QEMU.
> > >
> > > I managed to get tap interface connected to the cadence_gem
> > > controller. The QEMU command line is "qemu-system-riscv64 -nographic
> > > -M sifive_u -kernel u-boot -nic tap,model=cadence_gem"
> > >
> > > A single "ping" works after I set related network environments in the
> > > shell. But "tftp" test fails. It looks the driver just time out.
> > >
> > > => tftp 84000000 bmeng/uImage.riscv
> > > ethernet at 100900fc: PHY present at 0
> > > ethernet at 100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1)
> > > Using ethernet at 100900fc device
> > > TFTP from server 10.10.0.100; our IP address is 10.10.0.108
> > > Filename 'bmeng/uImage.riscv'.
> > > Load address: 0x84000000
> > > Loading: #T T #T T #T #T T #T #T T #
> > > Retry count exceeded; starting again
> > >
> > > Can you please take a look?
> >
> > Any idea about the timeouts?
>
> Sorry, I got busy with other stuff.
>
> I think this is specific to QEMU environment. The ethernet driver
> also few udelay calls which can further slow things down.
>
> From your log it seems that, it is working functionally but you
> are seeing too many timeouts. Try playing with "TIMEOUT" or
> "TIMEOUT_COUNT" in net/tftp.c
>

I suspect there are some issues with the MACB driver to be used with RISC-V.

> You can also try same thing over VirtIO net of QEMU virt machine.

The default same settings with VirtIO net interface works like a charm.

Regards,
Bin