mbox series

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

Message ID 20181217115143.18373-1-anup@brainfault.org
Headers show
Series Ethernet support for QEMU sifive_u machine | expand

Message

Anup Patel Dec. 17, 2018, 11:51 a.m. UTC
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/

Anup Patel (3):
  riscv: Add asm/dma-mapping.h for DMA mappings
  net: macb: Fix clk API usage for RISC-V systems
  riscv: qemu: Imply MACB ethernet for emulation

 arch/riscv/include/asm/dma-mapping.h | 37 ++++++++++++++++++++++++++++
 board/emulation/qemu-riscv/Kconfig   |  4 +++
 drivers/net/macb.c                   |  4 ++-
 3 files changed, 44 insertions(+), 1 deletion(-)
 create mode 100644 arch/riscv/include/asm/dma-mapping.h

Comments

Bin Meng Dec. 18, 2018, 9:51 a.m. UTC | #1
Hi Anup,

On Mon, Dec 17, 2018 at 7:51 PM Anup Patel <anup@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.

> Anup Patel (3):
>   riscv: Add asm/dma-mapping.h for DMA mappings
>   net: macb: Fix clk API usage for RISC-V systems
>   riscv: qemu: Imply MACB ethernet for emulation
>
>  arch/riscv/include/asm/dma-mapping.h | 37 ++++++++++++++++++++++++++++
>  board/emulation/qemu-riscv/Kconfig   |  4 +++
>  drivers/net/macb.c                   |  4 ++-
>  3 files changed, 44 insertions(+), 1 deletion(-)
>  create mode 100644 arch/riscv/include/asm/dma-mapping.h
>
> --

Regards,
Bin
Anup Patel Dec. 18, 2018, 10:33 a.m. UTC | #2
On Tue, Dec 18, 2018 at 3:21 PM Bin Meng <bmeng.cn@gmail.com> wrote:
>
> Hi Anup,
>
> On Mon, Dec 17, 2018 at 7:51 PM Anup Patel <anup@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

The above works for me on QEMU.

Regards,
Anup
Bin Meng Dec. 18, 2018, 10:36 a.m. UTC | #3
Hi Anup,

On Tue, Dec 18, 2018 at 6:33 PM Anup Patel <anup@brainfault.org> wrote:
>
> On Tue, Dec 18, 2018 at 3:21 PM Bin Meng <bmeng.cn@gmail.com> wrote:
> >
> > Hi Anup,
> >
> > On Mon, Dec 17, 2018 at 7:51 PM Anup Patel <anup@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?

Regards,
Bin
Anup Patel Dec. 19, 2018, 4:40 a.m. UTC | #4
On Tue, Dec 18, 2018 at 4:06 PM Bin Meng <bmeng.cn@gmail.com> wrote:
>
> Hi Anup,
>
> On Tue, Dec 18, 2018 at 6:33 PM Anup Patel <anup@brainfault.org> wrote:
> >
> > On Tue, Dec 18, 2018 at 3:21 PM Bin Meng <bmeng.cn@gmail.com> wrote:
> > >
> > > Hi Anup,
> > >
> > > On Mon, Dec 17, 2018 at 7:51 PM Anup Patel <anup@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@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@10013000
Out:   uart@10013000
Err:   uart@10013000
Net:
Warning: ethernet@100900fc (eth0) using random MAC address - f6:1f:8c:13:83:c0
eth0: ethernet@100900fc
Hit any key to stop autoboot:  0

Device 0: unknown device
ethernet@100900fc: PHY present at 0
ethernet@100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1)
BOOTP broadcast 1
DHCP client bound to address 10.0.2.15 (2 ms)
Using ethernet@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@100900fc: PHY present at 0
ethernet@100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1)
BOOTP broadcast 1
DHCP client bound to address 10.0.2.15 (1 ms)
Using ethernet@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@100900fc: PHY present at 0
ethernet@100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1)
Using ethernet@100900fc device
host 10.0.2.2 is alive
=>
ethernet@100900fc: PHY present at 0
ethernet@100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1)
Using ethernet@100900fc device
host 10.0.2.2 is alive
=> qemu-system-riscv64: terminating on signal 2


Regards,
Anup
Bin Meng Dec. 19, 2018, 5:32 a.m. UTC | #5
Hi Anup,

On Wed, Dec 19, 2018 at 12:41 PM Anup Patel <anup@brainfault.org> wrote:
>
> On Tue, Dec 18, 2018 at 4:06 PM Bin Meng <bmeng.cn@gmail.com> wrote:
> >
> > Hi Anup,
> >
> > On Tue, Dec 18, 2018 at 6:33 PM Anup Patel <anup@brainfault.org> wrote:
> > >
> > > On Tue, Dec 18, 2018 at 3:21 PM Bin Meng <bmeng.cn@gmail.com> wrote:
> > > >
> > > > Hi Anup,
> > > >
> > > > On Mon, Dec 17, 2018 at 7:51 PM Anup Patel <anup@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@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@10013000
> Out:   uart@10013000
> Err:   uart@10013000
> Net:
> Warning: ethernet@100900fc (eth0) using random MAC address - f6:1f:8c:13:83:c0
> eth0: ethernet@100900fc
> Hit any key to stop autoboot:  0
>
> Device 0: unknown device
> ethernet@100900fc: PHY present at 0
> ethernet@100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1)
> BOOTP broadcast 1
> DHCP client bound to address 10.0.2.15 (2 ms)
> Using ethernet@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@100900fc: PHY present at 0
> ethernet@100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1)
> BOOTP broadcast 1
> DHCP client bound to address 10.0.2.15 (1 ms)
> Using ethernet@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@100900fc: PHY present at 0
> ethernet@100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1)
> Using ethernet@100900fc device
> host 10.0.2.2 is alive
> =>
> ethernet@100900fc: PHY present at 0
> ethernet@100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1)
> Using ethernet@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?

Regards,
Bin
Anup Patel Dec. 19, 2018, 6:32 a.m. UTC | #6
On Wed, Dec 19, 2018 at 11:02 AM Bin Meng <bmeng.cn@gmail.com> wrote:
>
> Hi Anup,
>
> On Wed, Dec 19, 2018 at 12:41 PM Anup Patel <anup@brainfault.org> wrote:
> >
> > On Tue, Dec 18, 2018 at 4:06 PM Bin Meng <bmeng.cn@gmail.com> wrote:
> > >
> > > Hi Anup,
> > >
> > > On Tue, Dec 18, 2018 at 6:33 PM Anup Patel <anup@brainfault.org> wrote:
> > > >
> > > > On Tue, Dec 18, 2018 at 3:21 PM Bin Meng <bmeng.cn@gmail.com> wrote:
> > > > >
> > > > > Hi Anup,
> > > > >
> > > > > On Mon, Dec 17, 2018 at 7:51 PM Anup Patel <anup@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@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@10013000
> > Out:   uart@10013000
> > Err:   uart@10013000
> > Net:
> > Warning: ethernet@100900fc (eth0) using random MAC address - f6:1f:8c:13:83:c0
> > eth0: ethernet@100900fc
> > Hit any key to stop autoboot:  0
> >
> > Device 0: unknown device
> > ethernet@100900fc: PHY present at 0
> > ethernet@100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1)
> > BOOTP broadcast 1
> > DHCP client bound to address 10.0.2.15 (2 ms)
> > Using ethernet@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@100900fc: PHY present at 0
> > ethernet@100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1)
> > BOOTP broadcast 1
> > DHCP client bound to address 10.0.2.15 (1 ms)
> > Using ethernet@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@100900fc: PHY present at 0
> > ethernet@100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1)
> > Using ethernet@100900fc device
> > host 10.0.2.2 is alive
> > =>
> > ethernet@100900fc: PHY present at 0
> > ethernet@100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1)
> > Using ethernet@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.

Regards,
Anup
Bin Meng Dec. 19, 2018, 9:05 a.m. UTC | #7
Hi Anup,

On Wed, Dec 19, 2018 at 2:32 PM Anup Patel <anup@brainfault.org> wrote:
>
> On Wed, Dec 19, 2018 at 11:02 AM Bin Meng <bmeng.cn@gmail.com> wrote:
> >
> > Hi Anup,
> >
> > On Wed, Dec 19, 2018 at 12:41 PM Anup Patel <anup@brainfault.org> wrote:
> > >
> > > On Tue, Dec 18, 2018 at 4:06 PM Bin Meng <bmeng.cn@gmail.com> wrote:
> > > >
> > > > Hi Anup,
> > > >
> > > > On Tue, Dec 18, 2018 at 6:33 PM Anup Patel <anup@brainfault.org> wrote:
> > > > >
> > > > > On Tue, Dec 18, 2018 at 3:21 PM Bin Meng <bmeng.cn@gmail.com> wrote:
> > > > > >
> > > > > > Hi Anup,
> > > > > >
> > > > > > On Mon, Dec 17, 2018 at 7:51 PM Anup Patel <anup@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@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@10013000
> > > Out:   uart@10013000
> > > Err:   uart@10013000
> > > Net:
> > > Warning: ethernet@100900fc (eth0) using random MAC address - f6:1f:8c:13:83:c0
> > > eth0: ethernet@100900fc
> > > Hit any key to stop autoboot:  0
> > >
> > > Device 0: unknown device
> > > ethernet@100900fc: PHY present at 0
> > > ethernet@100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1)
> > > BOOTP broadcast 1
> > > DHCP client bound to address 10.0.2.15 (2 ms)
> > > Using ethernet@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@100900fc: PHY present at 0
> > > ethernet@100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1)
> > > BOOTP broadcast 1
> > > DHCP client bound to address 10.0.2.15 (1 ms)
> > > Using ethernet@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@100900fc: PHY present at 0
> > > ethernet@100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1)
> > > Using ethernet@100900fc device
> > > host 10.0.2.2 is alive
> > > =>
> > > ethernet@100900fc: PHY present at 0
> > > ethernet@100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1)
> > > Using ethernet@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@100900fc: PHY present at 0
ethernet@100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1)
Using ethernet@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?

Regards,
Bin
Bin Meng Dec. 24, 2018, 1:29 a.m. UTC | #8
Hi Anup,

On Wed, Dec 19, 2018 at 5:05 PM Bin Meng <bmeng.cn@gmail.com> wrote:
>
> Hi Anup,
>
> On Wed, Dec 19, 2018 at 2:32 PM Anup Patel <anup@brainfault.org> wrote:
> >
> > On Wed, Dec 19, 2018 at 11:02 AM Bin Meng <bmeng.cn@gmail.com> wrote:
> > >
> > > Hi Anup,
> > >
> > > On Wed, Dec 19, 2018 at 12:41 PM Anup Patel <anup@brainfault.org> wrote:
> > > >
> > > > On Tue, Dec 18, 2018 at 4:06 PM Bin Meng <bmeng.cn@gmail.com> wrote:
> > > > >
> > > > > Hi Anup,
> > > > >
> > > > > On Tue, Dec 18, 2018 at 6:33 PM Anup Patel <anup@brainfault.org> wrote:
> > > > > >
> > > > > > On Tue, Dec 18, 2018 at 3:21 PM Bin Meng <bmeng.cn@gmail.com> wrote:
> > > > > > >
> > > > > > > Hi Anup,
> > > > > > >
> > > > > > > On Mon, Dec 17, 2018 at 7:51 PM Anup Patel <anup@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@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@10013000
> > > > Out:   uart@10013000
> > > > Err:   uart@10013000
> > > > Net:
> > > > Warning: ethernet@100900fc (eth0) using random MAC address - f6:1f:8c:13:83:c0
> > > > eth0: ethernet@100900fc
> > > > Hit any key to stop autoboot:  0
> > > >
> > > > Device 0: unknown device
> > > > ethernet@100900fc: PHY present at 0
> > > > ethernet@100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1)
> > > > BOOTP broadcast 1
> > > > DHCP client bound to address 10.0.2.15 (2 ms)
> > > > Using ethernet@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@100900fc: PHY present at 0
> > > > ethernet@100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1)
> > > > BOOTP broadcast 1
> > > > DHCP client bound to address 10.0.2.15 (1 ms)
> > > > Using ethernet@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@100900fc: PHY present at 0
> > > > ethernet@100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1)
> > > > Using ethernet@100900fc device
> > > > host 10.0.2.2 is alive
> > > > =>
> > > > ethernet@100900fc: PHY present at 0
> > > > ethernet@100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1)
> > > > Using ethernet@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@100900fc: PHY present at 0
> ethernet@100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1)
> Using ethernet@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?

Regards,
Bin
Anup Patel Dec. 24, 2018, 5:41 a.m. UTC | #9
On Mon, Dec 24, 2018 at 6:59 AM Bin Meng <bmeng.cn@gmail.com> wrote:
>
> Hi Anup,
>
> On Wed, Dec 19, 2018 at 5:05 PM Bin Meng <bmeng.cn@gmail.com> wrote:
> >
> > Hi Anup,
> >
> > On Wed, Dec 19, 2018 at 2:32 PM Anup Patel <anup@brainfault.org> wrote:
> > >
> > > On Wed, Dec 19, 2018 at 11:02 AM Bin Meng <bmeng.cn@gmail.com> wrote:
> > > >
> > > > Hi Anup,
> > > >
> > > > On Wed, Dec 19, 2018 at 12:41 PM Anup Patel <anup@brainfault.org> wrote:
> > > > >
> > > > > On Tue, Dec 18, 2018 at 4:06 PM Bin Meng <bmeng.cn@gmail.com> wrote:
> > > > > >
> > > > > > Hi Anup,
> > > > > >
> > > > > > On Tue, Dec 18, 2018 at 6:33 PM Anup Patel <anup@brainfault.org> wrote:
> > > > > > >
> > > > > > > On Tue, Dec 18, 2018 at 3:21 PM Bin Meng <bmeng.cn@gmail.com> wrote:
> > > > > > > >
> > > > > > > > Hi Anup,
> > > > > > > >
> > > > > > > > On Mon, Dec 17, 2018 at 7:51 PM Anup Patel <anup@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@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@10013000
> > > > > Out:   uart@10013000
> > > > > Err:   uart@10013000
> > > > > Net:
> > > > > Warning: ethernet@100900fc (eth0) using random MAC address - f6:1f:8c:13:83:c0
> > > > > eth0: ethernet@100900fc
> > > > > Hit any key to stop autoboot:  0
> > > > >
> > > > > Device 0: unknown device
> > > > > ethernet@100900fc: PHY present at 0
> > > > > ethernet@100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1)
> > > > > BOOTP broadcast 1
> > > > > DHCP client bound to address 10.0.2.15 (2 ms)
> > > > > Using ethernet@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@100900fc: PHY present at 0
> > > > > ethernet@100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1)
> > > > > BOOTP broadcast 1
> > > > > DHCP client bound to address 10.0.2.15 (1 ms)
> > > > > Using ethernet@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@100900fc: PHY present at 0
> > > > > ethernet@100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1)
> > > > > Using ethernet@100900fc device
> > > > > host 10.0.2.2 is alive
> > > > > =>
> > > > > ethernet@100900fc: PHY present at 0
> > > > > ethernet@100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1)
> > > > > Using ethernet@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@100900fc: PHY present at 0
> > ethernet@100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1)
> > Using ethernet@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

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

Regards,
Anup
Bin Meng Dec. 24, 2018, 6:31 a.m. UTC | #10
Hi Anup,

On Mon, Dec 24, 2018 at 1:41 PM Anup Patel <anup@brainfault.org> wrote:
>
> On Mon, Dec 24, 2018 at 6:59 AM Bin Meng <bmeng.cn@gmail.com> wrote:
> >
> > Hi Anup,
> >
> > On Wed, Dec 19, 2018 at 5:05 PM Bin Meng <bmeng.cn@gmail.com> wrote:
> > >
> > > Hi Anup,
> > >
> > > On Wed, Dec 19, 2018 at 2:32 PM Anup Patel <anup@brainfault.org> wrote:
> > > >
> > > > On Wed, Dec 19, 2018 at 11:02 AM Bin Meng <bmeng.cn@gmail.com> wrote:
> > > > >
> > > > > Hi Anup,
> > > > >
> > > > > On Wed, Dec 19, 2018 at 12:41 PM Anup Patel <anup@brainfault.org> wrote:
> > > > > >
> > > > > > On Tue, Dec 18, 2018 at 4:06 PM Bin Meng <bmeng.cn@gmail.com> wrote:
> > > > > > >
> > > > > > > Hi Anup,
> > > > > > >
> > > > > > > On Tue, Dec 18, 2018 at 6:33 PM Anup Patel <anup@brainfault.org> wrote:
> > > > > > > >
> > > > > > > > On Tue, Dec 18, 2018 at 3:21 PM Bin Meng <bmeng.cn@gmail.com> wrote:
> > > > > > > > >
> > > > > > > > > Hi Anup,
> > > > > > > > >
> > > > > > > > > On Mon, Dec 17, 2018 at 7:51 PM Anup Patel <anup@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@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@10013000
> > > > > > Out:   uart@10013000
> > > > > > Err:   uart@10013000
> > > > > > Net:
> > > > > > Warning: ethernet@100900fc (eth0) using random MAC address - f6:1f:8c:13:83:c0
> > > > > > eth0: ethernet@100900fc
> > > > > > Hit any key to stop autoboot:  0
> > > > > >
> > > > > > Device 0: unknown device
> > > > > > ethernet@100900fc: PHY present at 0
> > > > > > ethernet@100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1)
> > > > > > BOOTP broadcast 1
> > > > > > DHCP client bound to address 10.0.2.15 (2 ms)
> > > > > > Using ethernet@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@100900fc: PHY present at 0
> > > > > > ethernet@100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1)
> > > > > > BOOTP broadcast 1
> > > > > > DHCP client bound to address 10.0.2.15 (1 ms)
> > > > > > Using ethernet@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@100900fc: PHY present at 0
> > > > > > ethernet@100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1)
> > > > > > Using ethernet@100900fc device
> > > > > > host 10.0.2.2 is alive
> > > > > > =>
> > > > > > ethernet@100900fc: PHY present at 0
> > > > > > ethernet@100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1)
> > > > > > Using ethernet@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@100900fc: PHY present at 0
> > > ethernet@100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1)
> > > Using ethernet@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
Anup Patel Dec. 24, 2018, 6:42 a.m. UTC | #11
On Mon, Dec 24, 2018 at 12:01 PM Bin Meng <bmeng.cn@gmail.com> wrote:
>
> Hi Anup,
>
> On Mon, Dec 24, 2018 at 1:41 PM Anup Patel <anup@brainfault.org> wrote:
> >
> > On Mon, Dec 24, 2018 at 6:59 AM Bin Meng <bmeng.cn@gmail.com> wrote:
> > >
> > > Hi Anup,
> > >
> > > On Wed, Dec 19, 2018 at 5:05 PM Bin Meng <bmeng.cn@gmail.com> wrote:
> > > >
> > > > Hi Anup,
> > > >
> > > > On Wed, Dec 19, 2018 at 2:32 PM Anup Patel <anup@brainfault.org> wrote:
> > > > >
> > > > > On Wed, Dec 19, 2018 at 11:02 AM Bin Meng <bmeng.cn@gmail.com> wrote:
> > > > > >
> > > > > > Hi Anup,
> > > > > >
> > > > > > On Wed, Dec 19, 2018 at 12:41 PM Anup Patel <anup@brainfault.org> wrote:
> > > > > > >
> > > > > > > On Tue, Dec 18, 2018 at 4:06 PM Bin Meng <bmeng.cn@gmail.com> wrote:
> > > > > > > >
> > > > > > > > Hi Anup,
> > > > > > > >
> > > > > > > > On Tue, Dec 18, 2018 at 6:33 PM Anup Patel <anup@brainfault.org> wrote:
> > > > > > > > >
> > > > > > > > > On Tue, Dec 18, 2018 at 3:21 PM Bin Meng <bmeng.cn@gmail.com> wrote:
> > > > > > > > > >
> > > > > > > > > > Hi Anup,
> > > > > > > > > >
> > > > > > > > > > On Mon, Dec 17, 2018 at 7:51 PM Anup Patel <anup@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@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@10013000
> > > > > > > Out:   uart@10013000
> > > > > > > Err:   uart@10013000
> > > > > > > Net:
> > > > > > > Warning: ethernet@100900fc (eth0) using random MAC address - f6:1f:8c:13:83:c0
> > > > > > > eth0: ethernet@100900fc
> > > > > > > Hit any key to stop autoboot:  0
> > > > > > >
> > > > > > > Device 0: unknown device
> > > > > > > ethernet@100900fc: PHY present at 0
> > > > > > > ethernet@100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1)
> > > > > > > BOOTP broadcast 1
> > > > > > > DHCP client bound to address 10.0.2.15 (2 ms)
> > > > > > > Using ethernet@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@100900fc: PHY present at 0
> > > > > > > ethernet@100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1)
> > > > > > > BOOTP broadcast 1
> > > > > > > DHCP client bound to address 10.0.2.15 (1 ms)
> > > > > > > Using ethernet@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@100900fc: PHY present at 0
> > > > > > > ethernet@100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1)
> > > > > > > Using ethernet@100900fc device
> > > > > > > host 10.0.2.2 is alive
> > > > > > > =>
> > > > > > > ethernet@100900fc: PHY present at 0
> > > > > > > ethernet@100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1)
> > > > > > > Using ethernet@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@100900fc: PHY present at 0
> > > > ethernet@100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1)
> > > > Using ethernet@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.

Unlikely because Microsemi folks seems to use it on HiFive Unleashed board.
https://github.com/Microsemi-SoC-IP/HiFive_U-Boot

We are still debugging on HiFive Unleashed board so stay tuned for
more patches.

Regards,
Anup
Bin Meng Dec. 24, 2018, 7:15 a.m. UTC | #12
Hi Anup,

On Mon, Dec 24, 2018 at 2:42 PM Anup Patel <anup@brainfault.org> wrote:
>
> On Mon, Dec 24, 2018 at 12:01 PM Bin Meng <bmeng.cn@gmail.com> wrote:
> >
> > Hi Anup,
> >
> > On Mon, Dec 24, 2018 at 1:41 PM Anup Patel <anup@brainfault.org> wrote:
> > >
> > > On Mon, Dec 24, 2018 at 6:59 AM Bin Meng <bmeng.cn@gmail.com> wrote:
> > > >
> > > > Hi Anup,
> > > >
> > > > On Wed, Dec 19, 2018 at 5:05 PM Bin Meng <bmeng.cn@gmail.com> wrote:
> > > > >
> > > > > Hi Anup,
> > > > >
> > > > > On Wed, Dec 19, 2018 at 2:32 PM Anup Patel <anup@brainfault.org> wrote:
> > > > > >
> > > > > > On Wed, Dec 19, 2018 at 11:02 AM Bin Meng <bmeng.cn@gmail.com> wrote:
> > > > > > >
> > > > > > > Hi Anup,
> > > > > > >
> > > > > > > On Wed, Dec 19, 2018 at 12:41 PM Anup Patel <anup@brainfault.org> wrote:
> > > > > > > >
> > > > > > > > On Tue, Dec 18, 2018 at 4:06 PM Bin Meng <bmeng.cn@gmail.com> wrote:
> > > > > > > > >
> > > > > > > > > Hi Anup,
> > > > > > > > >
> > > > > > > > > On Tue, Dec 18, 2018 at 6:33 PM Anup Patel <anup@brainfault.org> wrote:
> > > > > > > > > >
> > > > > > > > > > On Tue, Dec 18, 2018 at 3:21 PM Bin Meng <bmeng.cn@gmail.com> wrote:
> > > > > > > > > > >
> > > > > > > > > > > Hi Anup,
> > > > > > > > > > >
> > > > > > > > > > > On Mon, Dec 17, 2018 at 7:51 PM Anup Patel <anup@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@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@10013000
> > > > > > > > Out:   uart@10013000
> > > > > > > > Err:   uart@10013000
> > > > > > > > Net:
> > > > > > > > Warning: ethernet@100900fc (eth0) using random MAC address - f6:1f:8c:13:83:c0
> > > > > > > > eth0: ethernet@100900fc
> > > > > > > > Hit any key to stop autoboot:  0
> > > > > > > >
> > > > > > > > Device 0: unknown device
> > > > > > > > ethernet@100900fc: PHY present at 0
> > > > > > > > ethernet@100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1)
> > > > > > > > BOOTP broadcast 1
> > > > > > > > DHCP client bound to address 10.0.2.15 (2 ms)
> > > > > > > > Using ethernet@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@100900fc: PHY present at 0
> > > > > > > > ethernet@100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1)
> > > > > > > > BOOTP broadcast 1
> > > > > > > > DHCP client bound to address 10.0.2.15 (1 ms)
> > > > > > > > Using ethernet@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@100900fc: PHY present at 0
> > > > > > > > ethernet@100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1)
> > > > > > > > Using ethernet@100900fc device
> > > > > > > > host 10.0.2.2 is alive
> > > > > > > > =>
> > > > > > > > ethernet@100900fc: PHY present at 0
> > > > > > > > ethernet@100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1)
> > > > > > > > Using ethernet@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@100900fc: PHY present at 0
> > > > > ethernet@100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1)
> > > > > Using ethernet@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.
>
> Unlikely because Microsemi folks seems to use it on HiFive Unleashed board.
> https://github.com/Microsemi-SoC-IP/HiFive_U-Boot
>

It looks Microsemi's port is using the non-DM version of MACB driver
while this series is using DM version. Something is wrong when working
with QEMU's MACB controller.

> We are still debugging on HiFive Unleashed board so stay tuned for
> more patches.
>

Regards,
Bin
Anup Patel Dec. 24, 2018, 7:23 a.m. UTC | #13
On Mon, Dec 24, 2018 at 12:45 PM Bin Meng <bmeng.cn@gmail.com> wrote:
>
> Hi Anup,
>
> On Mon, Dec 24, 2018 at 2:42 PM Anup Patel <anup@brainfault.org> wrote:
> >
> > On Mon, Dec 24, 2018 at 12:01 PM Bin Meng <bmeng.cn@gmail.com> wrote:
> > >
> > > Hi Anup,
> > >
> > > On Mon, Dec 24, 2018 at 1:41 PM Anup Patel <anup@brainfault.org> wrote:
> > > >
> > > > On Mon, Dec 24, 2018 at 6:59 AM Bin Meng <bmeng.cn@gmail.com> wrote:
> > > > >
> > > > > Hi Anup,
> > > > >
> > > > > On Wed, Dec 19, 2018 at 5:05 PM Bin Meng <bmeng.cn@gmail.com> wrote:
> > > > > >
> > > > > > Hi Anup,
> > > > > >
> > > > > > On Wed, Dec 19, 2018 at 2:32 PM Anup Patel <anup@brainfault.org> wrote:
> > > > > > >
> > > > > > > On Wed, Dec 19, 2018 at 11:02 AM Bin Meng <bmeng.cn@gmail.com> wrote:
> > > > > > > >
> > > > > > > > Hi Anup,
> > > > > > > >
> > > > > > > > On Wed, Dec 19, 2018 at 12:41 PM Anup Patel <anup@brainfault.org> wrote:
> > > > > > > > >
> > > > > > > > > On Tue, Dec 18, 2018 at 4:06 PM Bin Meng <bmeng.cn@gmail.com> wrote:
> > > > > > > > > >
> > > > > > > > > > Hi Anup,
> > > > > > > > > >
> > > > > > > > > > On Tue, Dec 18, 2018 at 6:33 PM Anup Patel <anup@brainfault.org> wrote:
> > > > > > > > > > >
> > > > > > > > > > > On Tue, Dec 18, 2018 at 3:21 PM Bin Meng <bmeng.cn@gmail.com> wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > Hi Anup,
> > > > > > > > > > > >
> > > > > > > > > > > > On Mon, Dec 17, 2018 at 7:51 PM Anup Patel <anup@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@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@10013000
> > > > > > > > > Out:   uart@10013000
> > > > > > > > > Err:   uart@10013000
> > > > > > > > > Net:
> > > > > > > > > Warning: ethernet@100900fc (eth0) using random MAC address - f6:1f:8c:13:83:c0
> > > > > > > > > eth0: ethernet@100900fc
> > > > > > > > > Hit any key to stop autoboot:  0
> > > > > > > > >
> > > > > > > > > Device 0: unknown device
> > > > > > > > > ethernet@100900fc: PHY present at 0
> > > > > > > > > ethernet@100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1)
> > > > > > > > > BOOTP broadcast 1
> > > > > > > > > DHCP client bound to address 10.0.2.15 (2 ms)
> > > > > > > > > Using ethernet@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@100900fc: PHY present at 0
> > > > > > > > > ethernet@100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1)
> > > > > > > > > BOOTP broadcast 1
> > > > > > > > > DHCP client bound to address 10.0.2.15 (1 ms)
> > > > > > > > > Using ethernet@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@100900fc: PHY present at 0
> > > > > > > > > ethernet@100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1)
> > > > > > > > > Using ethernet@100900fc device
> > > > > > > > > host 10.0.2.2 is alive
> > > > > > > > > =>
> > > > > > > > > ethernet@100900fc: PHY present at 0
> > > > > > > > > ethernet@100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1)
> > > > > > > > > Using ethernet@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@100900fc: PHY present at 0
> > > > > > ethernet@100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1)
> > > > > > Using ethernet@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.
> >
> > Unlikely because Microsemi folks seems to use it on HiFive Unleashed board.
> > https://github.com/Microsemi-SoC-IP/HiFive_U-Boot
> >
>
> It looks Microsemi's port is using the non-DM version of MACB driver
> while this series is using DM version. Something is wrong when working
> with QEMU's MACB controller.

Yes, could be some issue with QEMU MACB emulation.

Anyway, we have U-Boot booting on Unleashed board with few
fixes in SiFive UART driver (Atish will send-out the fixes after
more testing).

This means same u-boot.bin boots on QEMU virt, QEMU sifive_u
and HiFive unleashed. We are on path towards having unified
u-boot.bin for multiple targets.

Regards,
Anup
Bin Meng Dec. 24, 2018, 7:36 a.m. UTC | #14
Hi Anup,

On Mon, Dec 24, 2018 at 3:23 PM Anup Patel <anup@brainfault.org> wrote:
>
> On Mon, Dec 24, 2018 at 12:45 PM Bin Meng <bmeng.cn@gmail.com> wrote:
> >
> > Hi Anup,
> >
> > On Mon, Dec 24, 2018 at 2:42 PM Anup Patel <anup@brainfault.org> wrote:
> > >
> > > On Mon, Dec 24, 2018 at 12:01 PM Bin Meng <bmeng.cn@gmail.com> wrote:
> > > >
> > > > Hi Anup,
> > > >
> > > > On Mon, Dec 24, 2018 at 1:41 PM Anup Patel <anup@brainfault.org> wrote:
> > > > >
> > > > > On Mon, Dec 24, 2018 at 6:59 AM Bin Meng <bmeng.cn@gmail.com> wrote:
> > > > > >
> > > > > > Hi Anup,
> > > > > >
> > > > > > On Wed, Dec 19, 2018 at 5:05 PM Bin Meng <bmeng.cn@gmail.com> wrote:
> > > > > > >
> > > > > > > Hi Anup,
> > > > > > >
> > > > > > > On Wed, Dec 19, 2018 at 2:32 PM Anup Patel <anup@brainfault.org> wrote:
> > > > > > > >
> > > > > > > > On Wed, Dec 19, 2018 at 11:02 AM Bin Meng <bmeng.cn@gmail.com> wrote:
> > > > > > > > >
> > > > > > > > > Hi Anup,
> > > > > > > > >
> > > > > > > > > On Wed, Dec 19, 2018 at 12:41 PM Anup Patel <anup@brainfault.org> wrote:
> > > > > > > > > >
> > > > > > > > > > On Tue, Dec 18, 2018 at 4:06 PM Bin Meng <bmeng.cn@gmail.com> wrote:
> > > > > > > > > > >
> > > > > > > > > > > Hi Anup,
> > > > > > > > > > >
> > > > > > > > > > > On Tue, Dec 18, 2018 at 6:33 PM Anup Patel <anup@brainfault.org> wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > On Tue, Dec 18, 2018 at 3:21 PM Bin Meng <bmeng.cn@gmail.com> wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > Hi Anup,
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Mon, Dec 17, 2018 at 7:51 PM Anup Patel <anup@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@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@10013000
> > > > > > > > > > Out:   uart@10013000
> > > > > > > > > > Err:   uart@10013000
> > > > > > > > > > Net:
> > > > > > > > > > Warning: ethernet@100900fc (eth0) using random MAC address - f6:1f:8c:13:83:c0
> > > > > > > > > > eth0: ethernet@100900fc
> > > > > > > > > > Hit any key to stop autoboot:  0
> > > > > > > > > >
> > > > > > > > > > Device 0: unknown device
> > > > > > > > > > ethernet@100900fc: PHY present at 0
> > > > > > > > > > ethernet@100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1)
> > > > > > > > > > BOOTP broadcast 1
> > > > > > > > > > DHCP client bound to address 10.0.2.15 (2 ms)
> > > > > > > > > > Using ethernet@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@100900fc: PHY present at 0
> > > > > > > > > > ethernet@100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1)
> > > > > > > > > > BOOTP broadcast 1
> > > > > > > > > > DHCP client bound to address 10.0.2.15 (1 ms)
> > > > > > > > > > Using ethernet@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@100900fc: PHY present at 0
> > > > > > > > > > ethernet@100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1)
> > > > > > > > > > Using ethernet@100900fc device
> > > > > > > > > > host 10.0.2.2 is alive
> > > > > > > > > > =>
> > > > > > > > > > ethernet@100900fc: PHY present at 0
> > > > > > > > > > ethernet@100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1)
> > > > > > > > > > Using ethernet@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@100900fc: PHY present at 0
> > > > > > > ethernet@100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1)
> > > > > > > Using ethernet@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.
> > >
> > > Unlikely because Microsemi folks seems to use it on HiFive Unleashed board.
> > > https://github.com/Microsemi-SoC-IP/HiFive_U-Boot
> > >
> >
> > It looks Microsemi's port is using the non-DM version of MACB driver
> > while this series is using DM version. Something is wrong when working
> > with QEMU's MACB controller.
>
> Yes, could be some issue with QEMU MACB emulation.
>
> Anyway, we have U-Boot booting on Unleashed board with few
> fixes in SiFive UART driver (Atish will send-out the fixes after
> more testing).
>
> This means same u-boot.bin boots on QEMU virt, QEMU sifive_u
> and HiFive unleashed. We are on path towards having unified
> u-boot.bin for multiple targets.

This is great! Once it's ready I can help the testing.

Regards,
Bin
Anup Patel Dec. 24, 2018, 11:34 a.m. UTC | #15
On Mon, Dec 24, 2018 at 1:06 PM Bin Meng <bmeng.cn@gmail.com> wrote:
>
> Hi Anup,
>
> On Mon, Dec 24, 2018 at 3:23 PM Anup Patel <anup@brainfault.org> wrote:
> >
> > On Mon, Dec 24, 2018 at 12:45 PM Bin Meng <bmeng.cn@gmail.com> wrote:
> > >
> > > Hi Anup,
> > >
> > > On Mon, Dec 24, 2018 at 2:42 PM Anup Patel <anup@brainfault.org> wrote:
> > > >
> > > > On Mon, Dec 24, 2018 at 12:01 PM Bin Meng <bmeng.cn@gmail.com> wrote:
> > > > >
> > > > > Hi Anup,
> > > > >
> > > > > On Mon, Dec 24, 2018 at 1:41 PM Anup Patel <anup@brainfault.org> wrote:
> > > > > >
> > > > > > On Mon, Dec 24, 2018 at 6:59 AM Bin Meng <bmeng.cn@gmail.com> wrote:
> > > > > > >
> > > > > > > Hi Anup,
> > > > > > >
> > > > > > > On Wed, Dec 19, 2018 at 5:05 PM Bin Meng <bmeng.cn@gmail.com> wrote:
> > > > > > > >
> > > > > > > > Hi Anup,
> > > > > > > >
> > > > > > > > On Wed, Dec 19, 2018 at 2:32 PM Anup Patel <anup@brainfault.org> wrote:
> > > > > > > > >
> > > > > > > > > On Wed, Dec 19, 2018 at 11:02 AM Bin Meng <bmeng.cn@gmail.com> wrote:
> > > > > > > > > >
> > > > > > > > > > Hi Anup,
> > > > > > > > > >
> > > > > > > > > > On Wed, Dec 19, 2018 at 12:41 PM Anup Patel <anup@brainfault.org> wrote:
> > > > > > > > > > >
> > > > > > > > > > > On Tue, Dec 18, 2018 at 4:06 PM Bin Meng <bmeng.cn@gmail.com> wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > Hi Anup,
> > > > > > > > > > > >
> > > > > > > > > > > > On Tue, Dec 18, 2018 at 6:33 PM Anup Patel <anup@brainfault.org> wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Tue, Dec 18, 2018 at 3:21 PM Bin Meng <bmeng.cn@gmail.com> wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Hi Anup,
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Mon, Dec 17, 2018 at 7:51 PM Anup Patel <anup@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@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@10013000
> > > > > > > > > > > Out:   uart@10013000
> > > > > > > > > > > Err:   uart@10013000
> > > > > > > > > > > Net:
> > > > > > > > > > > Warning: ethernet@100900fc (eth0) using random MAC address - f6:1f:8c:13:83:c0
> > > > > > > > > > > eth0: ethernet@100900fc
> > > > > > > > > > > Hit any key to stop autoboot:  0
> > > > > > > > > > >
> > > > > > > > > > > Device 0: unknown device
> > > > > > > > > > > ethernet@100900fc: PHY present at 0
> > > > > > > > > > > ethernet@100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1)
> > > > > > > > > > > BOOTP broadcast 1
> > > > > > > > > > > DHCP client bound to address 10.0.2.15 (2 ms)
> > > > > > > > > > > Using ethernet@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@100900fc: PHY present at 0
> > > > > > > > > > > ethernet@100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1)
> > > > > > > > > > > BOOTP broadcast 1
> > > > > > > > > > > DHCP client bound to address 10.0.2.15 (1 ms)
> > > > > > > > > > > Using ethernet@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@100900fc: PHY present at 0
> > > > > > > > > > > ethernet@100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1)
> > > > > > > > > > > Using ethernet@100900fc device
> > > > > > > > > > > host 10.0.2.2 is alive
> > > > > > > > > > > =>
> > > > > > > > > > > ethernet@100900fc: PHY present at 0
> > > > > > > > > > > ethernet@100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1)
> > > > > > > > > > > Using ethernet@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@100900fc: PHY present at 0
> > > > > > > > ethernet@100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1)
> > > > > > > > Using ethernet@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.
> > > >
> > > > Unlikely because Microsemi folks seems to use it on HiFive Unleashed board.
> > > > https://github.com/Microsemi-SoC-IP/HiFive_U-Boot
> > > >
> > >
> > > It looks Microsemi's port is using the non-DM version of MACB driver
> > > while this series is using DM version. Something is wrong when working
> > > with QEMU's MACB controller.
> >
> > Yes, could be some issue with QEMU MACB emulation.
> >
> > Anyway, we have U-Boot booting on Unleashed board with few
> > fixes in SiFive UART driver (Atish will send-out the fixes after
> > more testing).
> >
> > This means same u-boot.bin boots on QEMU virt, QEMU sifive_u
> > and HiFive unleashed. We are on path towards having unified
> > u-boot.bin for multiple targets.
>
> This is great! Once it's ready I can help the testing.

Thanks in-advance.

I would suggest to get this series for U-Boot 2019.01. What say?

Regards,
Anup
Bin Meng Aug. 7, 2019, 3:37 p.m. UTC | #16
Hi,

On Wed, Dec 19, 2018 at 5:05 PM Bin Meng <bmeng.cn@gmail.com> wrote:
>
> Hi Anup,
>
> On Wed, Dec 19, 2018 at 2:32 PM Anup Patel <anup@brainfault.org> wrote:
> >
> > On Wed, Dec 19, 2018 at 11:02 AM Bin Meng <bmeng.cn@gmail.com> wrote:
> > >
> > > Hi Anup,
> > >
> > > On Wed, Dec 19, 2018 at 12:41 PM Anup Patel <anup@brainfault.org> wrote:
> > > >
> > > > On Tue, Dec 18, 2018 at 4:06 PM Bin Meng <bmeng.cn@gmail.com> wrote:
> > > > >
> > > > > Hi Anup,
> > > > >
> > > > > On Tue, Dec 18, 2018 at 6:33 PM Anup Patel <anup@brainfault.org> wrote:
> > > > > >
> > > > > > On Tue, Dec 18, 2018 at 3:21 PM Bin Meng <bmeng.cn@gmail.com> wrote:
> > > > > > >
> > > > > > > Hi Anup,
> > > > > > >
> > > > > > > On Mon, Dec 17, 2018 at 7:51 PM Anup Patel <anup@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@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@10013000
> > > > Out:   uart@10013000
> > > > Err:   uart@10013000
> > > > Net:
> > > > Warning: ethernet@100900fc (eth0) using random MAC address - f6:1f:8c:13:83:c0
> > > > eth0: ethernet@100900fc
> > > > Hit any key to stop autoboot:  0
> > > >
> > > > Device 0: unknown device
> > > > ethernet@100900fc: PHY present at 0
> > > > ethernet@100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1)
> > > > BOOTP broadcast 1
> > > > DHCP client bound to address 10.0.2.15 (2 ms)
> > > > Using ethernet@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@100900fc: PHY present at 0
> > > > ethernet@100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1)
> > > > BOOTP broadcast 1
> > > > DHCP client bound to address 10.0.2.15 (1 ms)
> > > > Using ethernet@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@100900fc: PHY present at 0
> > > > ethernet@100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1)
> > > > Using ethernet@100900fc device
> > > > host 10.0.2.2 is alive
> > > > =>
> > > > ethernet@100900fc: PHY present at 0
> > > > ethernet@100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1)
> > > > Using ethernet@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@100900fc: PHY present at 0
> ethernet@100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1)
> Using ethernet@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?

Just let everyone know that this GEM emulation issue has been fixed by
the following QEMU patch (series):
http://patchwork.ozlabs.org/patch/1143358/

Regards,
Bin