Hi Anup, On Mon, Dec 24, 2018 at 3:23 PM Anup Patel <a...@brainfault.org> wrote: > > On Mon, Dec 24, 2018 at 12:45 PM Bin Meng <bmeng...@gmail.com> wrote: > > > > Hi Anup, > > > > On Mon, Dec 24, 2018 at 2:42 PM Anup Patel <a...@brainfault.org> wrote: > > > > > > On Mon, Dec 24, 2018 at 12:01 PM Bin Meng <bmeng...@gmail.com> wrote: > > > > > > > > Hi Anup, > > > > > > > > On Mon, Dec 24, 2018 at 1:41 PM Anup Patel <a...@brainfault.org> wrote: > > > > > > > > > > On Mon, Dec 24, 2018 at 6:59 AM Bin Meng <bmeng...@gmail.com> wrote: > > > > > > > > > > > > Hi Anup, > > > > > > > > > > > > On Wed, Dec 19, 2018 at 5:05 PM Bin Meng <bmeng...@gmail.com> wrote: > > > > > > > > > > > > > > Hi Anup, > > > > > > > > > > > > > > On Wed, Dec 19, 2018 at 2:32 PM Anup Patel <a...@brainfault.org> > > > > > > > wrote: > > > > > > > > > > > > > > > > On Wed, Dec 19, 2018 at 11:02 AM Bin Meng <bmeng...@gmail.com> > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > Hi Anup, > > > > > > > > > > > > > > > > > > On Wed, Dec 19, 2018 at 12:41 PM Anup Patel > > > > > > > > > <a...@brainfault.org> wrote: > > > > > > > > > > > > > > > > > > > > On Tue, Dec 18, 2018 at 4:06 PM Bin Meng > > > > > > > > > > <bmeng...@gmail.com> wrote: > > > > > > > > > > > > > > > > > > > > > > Hi Anup, > > > > > > > > > > > > > > > > > > > > > > On Tue, Dec 18, 2018 at 6:33 PM Anup Patel > > > > > > > > > > > <a...@brainfault.org> wrote: > > > > > > > > > > > > > > > > > > > > > > > > On Tue, Dec 18, 2018 at 3:21 PM Bin Meng > > > > > > > > > > > > <bmeng...@gmail.com> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Anup, > > > > > > > > > > > > > > > > > > > > > > > > > > On Mon, Dec 17, 2018 at 7:51 PM Anup Patel > > > > > > > > > > > > > <a...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
