* [U-Boot] [PATCH 0/3] Ethernet support for QEMU sifive_u machine @ 2018-12-17 11:51 Anup Patel 2018-12-17 11:51 ` [U-Boot] [PATCH 1/3] riscv: Add asm/dma-mapping.h for DMA mappings Anup Patel ` (3 more replies) 0 siblings, 4 replies; 26+ messages in thread From: Anup Patel @ 2018-12-17 11:51 UTC (permalink / raw) To: u-boot 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 -- 2.17.1 ^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] [PATCH 1/3] riscv: Add asm/dma-mapping.h for DMA mappings 2018-12-17 11:51 [U-Boot] [PATCH 0/3] Ethernet support for QEMU sifive_u machine Anup Patel @ 2018-12-17 11:51 ` Anup Patel 2018-12-18 9:45 ` Bin Meng 2018-12-20 5:26 ` Anup Patel 2018-12-17 11:51 ` [U-Boot] [PATCH 2/3] net: macb: Fix clk API usage for RISC-V systems Anup Patel ` (2 subsequent siblings) 3 siblings, 2 replies; 26+ messages in thread From: Anup Patel @ 2018-12-17 11:51 UTC (permalink / raw) To: u-boot From: Anup Patel <anup.patel@wdc.com> This patch adds asm/dma-mapping.h for Linux-like DMA mappings APIs required by some of the drivers (such as, Cadance MACB Ethernet driver). Signed-off-by: Anup Patel <anup.patel@wdc.com> --- arch/riscv/include/asm/dma-mapping.h | 37 ++++++++++++++++++++++++++++ 1 file changed, 37 insertions(+) create mode 100644 arch/riscv/include/asm/dma-mapping.h diff --git a/arch/riscv/include/asm/dma-mapping.h b/arch/riscv/include/asm/dma-mapping.h new file mode 100644 index 0000000000..9782b6f168 --- /dev/null +++ b/arch/riscv/include/asm/dma-mapping.h @@ -0,0 +1,37 @@ +/* SPDX-License-Identifier: GPL-2.0+ */ +/* + * Copyright (c) 2018 Western Digital Corporation or its affiliates. + * + * Authors: + * Anup Patel <anup.patel@wdc.com> + */ +#ifndef __ASM_RISCV_DMA_MAPPING_H +#define __ASM_RISCV_DMA_MAPPING_H + +#include <linux/dma-direction.h> + +#define dma_mapping_error(x, y) 0 + +static inline void *dma_alloc_coherent(size_t len, unsigned long *handle) +{ + *handle = (unsigned long)memalign(ARCH_DMA_MINALIGN, len); + return (void *)*handle; +} + +static inline void dma_free_coherent(void *addr) +{ + free(addr); +} + +static inline unsigned long dma_map_single(volatile void *vaddr, size_t len, + enum dma_data_direction dir) +{ + return (unsigned long)vaddr; +} + +static inline void dma_unmap_single(volatile void *vaddr, size_t len, + unsigned long paddr) +{ +} + +#endif /* __ASM_RISCV_DMA_MAPPING_H */ -- 2.17.1 ^ permalink raw reply related [flat|nested] 26+ messages in thread
* [U-Boot] [PATCH 1/3] riscv: Add asm/dma-mapping.h for DMA mappings 2018-12-17 11:51 ` [U-Boot] [PATCH 1/3] riscv: Add asm/dma-mapping.h for DMA mappings Anup Patel @ 2018-12-18 9:45 ` Bin Meng 2018-12-19 8:09 ` Anup Patel 2018-12-20 5:26 ` Anup Patel 1 sibling, 1 reply; 26+ messages in thread From: Bin Meng @ 2018-12-18 9:45 UTC (permalink / raw) To: u-boot On Mon, Dec 17, 2018 at 7:52 PM Anup Patel <anup@brainfault.org> wrote: > > From: Anup Patel <anup.patel@wdc.com> > > This patch adds asm/dma-mapping.h for Linux-like DMA mappings > APIs required by some of the drivers (such as, Cadance MACB > Ethernet driver). > > Signed-off-by: Anup Patel <anup.patel@wdc.com> > --- > arch/riscv/include/asm/dma-mapping.h | 37 ++++++++++++++++++++++++++++ > 1 file changed, 37 insertions(+) > create mode 100644 arch/riscv/include/asm/dma-mapping.h > Reviewed-by: Bin Meng <bmeng.cn@gmail.com> But please see nits below: > diff --git a/arch/riscv/include/asm/dma-mapping.h b/arch/riscv/include/asm/dma-mapping.h > new file mode 100644 > index 0000000000..9782b6f168 > --- /dev/null > +++ b/arch/riscv/include/asm/dma-mapping.h > @@ -0,0 +1,37 @@ > +/* SPDX-License-Identifier: GPL-2.0+ */ > +/* > + * Copyright (c) 2018 Western Digital Corporation or its affiliates. > + * > + * Authors: > + * Anup Patel <anup.patel@wdc.com> > + */ nits: should have one blank line here > +#ifndef __ASM_RISCV_DMA_MAPPING_H > +#define __ASM_RISCV_DMA_MAPPING_H > + > +#include <linux/dma-direction.h> > + > +#define dma_mapping_error(x, y) 0 nits: no <tab> between #define and dma_ > + > +static inline void *dma_alloc_coherent(size_t len, unsigned long *handle) > +{ > + *handle = (unsigned long)memalign(ARCH_DMA_MINALIGN, len); > + return (void *)*handle; > +} > + > +static inline void dma_free_coherent(void *addr) > +{ > + free(addr); > +} > + > +static inline unsigned long dma_map_single(volatile void *vaddr, size_t len, > + enum dma_data_direction dir) > +{ > + return (unsigned long)vaddr; > +} > + > +static inline void dma_unmap_single(volatile void *vaddr, size_t len, > + unsigned long paddr) > +{ > +} > + > +#endif /* __ASM_RISCV_DMA_MAPPING_H */ > -- Regards, Bin ^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] [PATCH 1/3] riscv: Add asm/dma-mapping.h for DMA mappings 2018-12-18 9:45 ` Bin Meng @ 2018-12-19 8:09 ` Anup Patel 0 siblings, 0 replies; 26+ messages in thread From: Anup Patel @ 2018-12-19 8:09 UTC (permalink / raw) To: u-boot On Tue, Dec 18, 2018 at 3:15 PM Bin Meng <bmeng.cn@gmail.com> wrote: > > On Mon, Dec 17, 2018 at 7:52 PM Anup Patel <anup@brainfault.org> wrote: > > > > From: Anup Patel <anup.patel@wdc.com> > > > > This patch adds asm/dma-mapping.h for Linux-like DMA mappings > > APIs required by some of the drivers (such as, Cadance MACB > > Ethernet driver). > > > > Signed-off-by: Anup Patel <anup.patel@wdc.com> > > --- > > arch/riscv/include/asm/dma-mapping.h | 37 ++++++++++++++++++++++++++++ > > 1 file changed, 37 insertions(+) > > create mode 100644 arch/riscv/include/asm/dma-mapping.h > > > > Reviewed-by: Bin Meng <bmeng.cn@gmail.com> > > But please see nits below: > > > diff --git a/arch/riscv/include/asm/dma-mapping.h b/arch/riscv/include/asm/dma-mapping.h > > new file mode 100644 > > index 0000000000..9782b6f168 > > --- /dev/null > > +++ b/arch/riscv/include/asm/dma-mapping.h > > @@ -0,0 +1,37 @@ > > +/* SPDX-License-Identifier: GPL-2.0+ */ > > +/* > > + * Copyright (c) 2018 Western Digital Corporation or its affiliates. > > + * > > + * Authors: > > + * Anup Patel <anup.patel@wdc.com> > > + */ > > nits: should have one blank line here OK, will update. > > > +#ifndef __ASM_RISCV_DMA_MAPPING_H > > +#define __ASM_RISCV_DMA_MAPPING_H > > + > > +#include <linux/dma-direction.h> > > + > > +#define dma_mapping_error(x, y) 0 > > nits: no <tab> between #define and dma_ OK, will update. > > > + > > +static inline void *dma_alloc_coherent(size_t len, unsigned long *handle) > > +{ > > + *handle = (unsigned long)memalign(ARCH_DMA_MINALIGN, len); > > + return (void *)*handle; > > +} > > + > > +static inline void dma_free_coherent(void *addr) > > +{ > > + free(addr); > > +} > > + > > +static inline unsigned long dma_map_single(volatile void *vaddr, size_t len, > > + enum dma_data_direction dir) > > +{ > > + return (unsigned long)vaddr; > > +} > > + > > +static inline void dma_unmap_single(volatile void *vaddr, size_t len, > > + unsigned long paddr) > > +{ > > +} > > + > > +#endif /* __ASM_RISCV_DMA_MAPPING_H */ > > -- > > Regards, > Bin Regards, Anup ^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] [PATCH 1/3] riscv: Add asm/dma-mapping.h for DMA mappings 2018-12-17 11:51 ` [U-Boot] [PATCH 1/3] riscv: Add asm/dma-mapping.h for DMA mappings Anup Patel 2018-12-18 9:45 ` Bin Meng @ 2018-12-20 5:26 ` Anup Patel 1 sibling, 0 replies; 26+ messages in thread From: Anup Patel @ 2018-12-20 5:26 UTC (permalink / raw) To: u-boot +Michal On Mon, Dec 17, 2018 at 5:21 PM Anup Patel <anup@brainfault.org> wrote: > > From: Anup Patel <anup.patel@wdc.com> > > This patch adds asm/dma-mapping.h for Linux-like DMA mappings > APIs required by some of the drivers (such as, Cadance MACB > Ethernet driver). > > Signed-off-by: Anup Patel <anup.patel@wdc.com> > --- > arch/riscv/include/asm/dma-mapping.h | 37 ++++++++++++++++++++++++++++ > 1 file changed, 37 insertions(+) > create mode 100644 arch/riscv/include/asm/dma-mapping.h > > diff --git a/arch/riscv/include/asm/dma-mapping.h b/arch/riscv/include/asm/dma-mapping.h > new file mode 100644 > index 0000000000..9782b6f168 > --- /dev/null > +++ b/arch/riscv/include/asm/dma-mapping.h > @@ -0,0 +1,37 @@ > +/* SPDX-License-Identifier: GPL-2.0+ */ > +/* > + * Copyright (c) 2018 Western Digital Corporation or its affiliates. > + * > + * Authors: > + * Anup Patel <anup.patel@wdc.com> > + */ > +#ifndef __ASM_RISCV_DMA_MAPPING_H > +#define __ASM_RISCV_DMA_MAPPING_H > + > +#include <linux/dma-direction.h> > + > +#define dma_mapping_error(x, y) 0 > + > +static inline void *dma_alloc_coherent(size_t len, unsigned long *handle) > +{ > + *handle = (unsigned long)memalign(ARCH_DMA_MINALIGN, len); > + return (void *)*handle; > +} > + > +static inline void dma_free_coherent(void *addr) > +{ > + free(addr); > +} > + > +static inline unsigned long dma_map_single(volatile void *vaddr, size_t len, > + enum dma_data_direction dir) > +{ > + return (unsigned long)vaddr; > +} > + > +static inline void dma_unmap_single(volatile void *vaddr, size_t len, > + unsigned long paddr) > +{ > +} > + > +#endif /* __ASM_RISCV_DMA_MAPPING_H */ > -- > 2.17.1 > ^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] [PATCH 2/3] net: macb: Fix clk API usage for RISC-V systems 2018-12-17 11:51 [U-Boot] [PATCH 0/3] Ethernet support for QEMU sifive_u machine Anup Patel 2018-12-17 11:51 ` [U-Boot] [PATCH 1/3] riscv: Add asm/dma-mapping.h for DMA mappings Anup Patel @ 2018-12-17 11:51 ` Anup Patel 2018-12-18 9:45 ` Bin Meng 2018-12-17 11:51 ` [U-Boot] [PATCH 3/3] riscv: qemu: Imply MACB ethernet for emulation Anup Patel 2018-12-18 9:51 ` [U-Boot] [PATCH 0/3] Ethernet support for QEMU sifive_u machine Bin Meng 3 siblings, 1 reply; 26+ messages in thread From: Anup Patel @ 2018-12-17 11:51 UTC (permalink / raw) To: u-boot From: Anup Patel <anup.patel@wdc.com> This patch does following fixes in MACB ethernet driver for using it on RISC-V systems (particularly QEMU sifive_u machine): 1. asm/arch/clk.h is not available on RISC-V port so include it only for non-RISC-V systems. 2. Don't fail in macb_enable_clk() if clk_enable() returns -ENOSYS because we get -ENOSYS for fixed-rate clocks. Signed-off-by: Anup Patel <anup.patel@wdc.com> --- drivers/net/macb.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/net/macb.c b/drivers/net/macb.c index 94c89c762b..9a06b523cc 100644 --- a/drivers/net/macb.c +++ b/drivers/net/macb.c @@ -38,7 +38,9 @@ #include <linux/mii.h> #include <asm/io.h> #include <asm/dma-mapping.h> +#ifndef CONFIG_RISCV #include <asm/arch/clk.h> +#endif #include <linux/errno.h> #include "macb.h" @@ -1066,7 +1068,7 @@ static int macb_enable_clk(struct udevice *dev) */ #ifndef CONFIG_MACB_ZYNQ ret = clk_enable(&clk); - if (ret) + if (ret && ret != -ENOSYS) return ret; #endif -- 2.17.1 ^ permalink raw reply related [flat|nested] 26+ messages in thread
* [U-Boot] [PATCH 2/3] net: macb: Fix clk API usage for RISC-V systems 2018-12-17 11:51 ` [U-Boot] [PATCH 2/3] net: macb: Fix clk API usage for RISC-V systems Anup Patel @ 2018-12-18 9:45 ` Bin Meng 2018-12-19 8:15 ` Anup Patel 0 siblings, 1 reply; 26+ messages in thread From: Bin Meng @ 2018-12-18 9:45 UTC (permalink / raw) To: u-boot On Mon, Dec 17, 2018 at 7:52 PM Anup Patel <anup@brainfault.org> wrote: > > From: Anup Patel <anup.patel@wdc.com> > > This patch does following fixes in MACB ethernet driver > for using it on RISC-V systems (particularly QEMU sifive_u > machine): > 1. asm/arch/clk.h is not available on RISC-V port so include > it only for non-RISC-V systems. > 2. Don't fail in macb_enable_clk() if clk_enable() returns > -ENOSYS because we get -ENOSYS for fixed-rate clocks. > > Signed-off-by: Anup Patel <anup.patel@wdc.com> > --- > drivers/net/macb.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > Reviewed-by: Bin Meng <bmeng.cn@gmail.com> But please see comments below: > diff --git a/drivers/net/macb.c b/drivers/net/macb.c > index 94c89c762b..9a06b523cc 100644 > --- a/drivers/net/macb.c > +++ b/drivers/net/macb.c > @@ -38,7 +38,9 @@ > #include <linux/mii.h> > #include <asm/io.h> > #include <asm/dma-mapping.h> > +#ifndef CONFIG_RISCV > #include <asm/arch/clk.h> > +#endif > #include <linux/errno.h> > > #include "macb.h" > @@ -1066,7 +1068,7 @@ static int macb_enable_clk(struct udevice *dev) > */ > #ifndef CONFIG_MACB_ZYNQ I suspect this "#ifndef CONFIG_MACB_ZYNQ" can be removed per the comments below, with the adding check of (ret != -ENOSYS). /* * Zynq clock driver didn't support for enable or disable * clock. Hence, clk_enable() didn't apply for Zynq */ Someone else who has access to Zynq targets need to confirm. > ret = clk_enable(&clk); > - if (ret) > + if (ret && ret != -ENOSYS) > return ret; > #endif > > -- Regards, Bin ^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] [PATCH 2/3] net: macb: Fix clk API usage for RISC-V systems 2018-12-18 9:45 ` Bin Meng @ 2018-12-19 8:15 ` Anup Patel 0 siblings, 0 replies; 26+ messages in thread From: Anup Patel @ 2018-12-19 8:15 UTC (permalink / raw) To: u-boot On Tue, Dec 18, 2018 at 3:15 PM Bin Meng <bmeng.cn@gmail.com> wrote: > > On Mon, Dec 17, 2018 at 7:52 PM Anup Patel <anup@brainfault.org> wrote: > > > > From: Anup Patel <anup.patel@wdc.com> > > > > This patch does following fixes in MACB ethernet driver > > for using it on RISC-V systems (particularly QEMU sifive_u > > machine): > > 1. asm/arch/clk.h is not available on RISC-V port so include > > it only for non-RISC-V systems. > > 2. Don't fail in macb_enable_clk() if clk_enable() returns > > -ENOSYS because we get -ENOSYS for fixed-rate clocks. > > > > Signed-off-by: Anup Patel <anup.patel@wdc.com> > > --- > > drivers/net/macb.c | 4 +++- > > 1 file changed, 3 insertions(+), 1 deletion(-) > > > > Reviewed-by: Bin Meng <bmeng.cn@gmail.com> > > But please see comments below: > > > diff --git a/drivers/net/macb.c b/drivers/net/macb.c > > index 94c89c762b..9a06b523cc 100644 > > --- a/drivers/net/macb.c > > +++ b/drivers/net/macb.c > > @@ -38,7 +38,9 @@ > > #include <linux/mii.h> > > #include <asm/io.h> > > #include <asm/dma-mapping.h> > > +#ifndef CONFIG_RISCV > > #include <asm/arch/clk.h> > > +#endif > > #include <linux/errno.h> > > > > #include "macb.h" > > @@ -1066,7 +1068,7 @@ static int macb_enable_clk(struct udevice *dev) > > */ > > #ifndef CONFIG_MACB_ZYNQ > > I suspect this "#ifndef CONFIG_MACB_ZYNQ" can be removed per the > comments below, with the adding check of (ret != -ENOSYS). > > /* > * Zynq clock driver didn't support for enable or disable > * clock. Hence, clk_enable() didn't apply for Zynq > */ > > Someone else who has access to Zynq targets need to confirm. I think let someone with Zynq SOC based board remove this. Regards, Anup ^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] [PATCH 3/3] riscv: qemu: Imply MACB ethernet for emulation 2018-12-17 11:51 [U-Boot] [PATCH 0/3] Ethernet support for QEMU sifive_u machine Anup Patel 2018-12-17 11:51 ` [U-Boot] [PATCH 1/3] riscv: Add asm/dma-mapping.h for DMA mappings Anup Patel 2018-12-17 11:51 ` [U-Boot] [PATCH 2/3] net: macb: Fix clk API usage for RISC-V systems Anup Patel @ 2018-12-17 11:51 ` Anup Patel 2018-12-18 9:45 ` Bin Meng 2018-12-18 9:51 ` [U-Boot] [PATCH 0/3] Ethernet support for QEMU sifive_u machine Bin Meng 3 siblings, 1 reply; 26+ messages in thread From: Anup Patel @ 2018-12-17 11:51 UTC (permalink / raw) To: u-boot From: Anup Patel <anup.patel@wdc.com> This patch enables Cadence MACB ethernet driver for QEMU RISC-V emulation by implying MACB, MII, RGMII and NET_RANDOM_ETHADDR on BOARD_SPECIFIC_OPTIONS. Signed-off-by: Anup Patel <anup.patel@wdc.com> --- board/emulation/qemu-riscv/Kconfig | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/board/emulation/qemu-riscv/Kconfig b/board/emulation/qemu-riscv/Kconfig index 0d865acf10..5d9611bdc7 100644 --- a/board/emulation/qemu-riscv/Kconfig +++ b/board/emulation/qemu-riscv/Kconfig @@ -34,5 +34,9 @@ config BOARD_SPECIFIC_OPTIONS # dummy imply BOARD_LATE_INIT imply OF_BOARD_SETUP imply SIFIVE_SERIAL + imply MACB + imply RGMII + imply MII + imply NET_RANDOM_ETHADDR endif -- 2.17.1 ^ permalink raw reply related [flat|nested] 26+ messages in thread
* [U-Boot] [PATCH 3/3] riscv: qemu: Imply MACB ethernet for emulation 2018-12-17 11:51 ` [U-Boot] [PATCH 3/3] riscv: qemu: Imply MACB ethernet for emulation Anup Patel @ 2018-12-18 9:45 ` Bin Meng 0 siblings, 0 replies; 26+ messages in thread From: Bin Meng @ 2018-12-18 9:45 UTC (permalink / raw) To: u-boot On Mon, Dec 17, 2018 at 7:52 PM Anup Patel <anup@brainfault.org> wrote: > > From: Anup Patel <anup.patel@wdc.com> > > This patch enables Cadence MACB ethernet driver for QEMU RISC-V > emulation by implying MACB, MII, RGMII and NET_RANDOM_ETHADDR on > BOARD_SPECIFIC_OPTIONS. > > Signed-off-by: Anup Patel <anup.patel@wdc.com> > --- > board/emulation/qemu-riscv/Kconfig | 4 ++++ > 1 file changed, 4 insertions(+) > Reviewed-by: Bin Meng <bmeng.cn@gmail.com> ^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] [PATCH 0/3] Ethernet support for QEMU sifive_u machine 2018-12-17 11:51 [U-Boot] [PATCH 0/3] Ethernet support for QEMU sifive_u machine Anup Patel ` (2 preceding siblings ...) 2018-12-17 11:51 ` [U-Boot] [PATCH 3/3] riscv: qemu: Imply MACB ethernet for emulation Anup Patel @ 2018-12-18 9:51 ` Bin Meng 2018-12-18 10:33 ` Anup Patel 3 siblings, 1 reply; 26+ messages in thread From: Bin Meng @ 2018-12-18 9:51 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] [PATCH 0/3] Ethernet support for QEMU sifive_u machine 2018-12-18 9:51 ` [U-Boot] [PATCH 0/3] Ethernet support for QEMU sifive_u machine Bin Meng @ 2018-12-18 10:33 ` Anup Patel 2018-12-18 10:36 ` Bin Meng 0 siblings, 1 reply; 26+ messages in thread From: Anup Patel @ 2018-12-18 10:33 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] [PATCH 0/3] Ethernet support for QEMU sifive_u machine 2018-12-18 10:33 ` Anup Patel @ 2018-12-18 10:36 ` Bin Meng 2018-12-19 4:40 ` Anup Patel 0 siblings, 1 reply; 26+ messages in thread From: Bin Meng @ 2018-12-18 10:36 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] [PATCH 0/3] Ethernet support for QEMU sifive_u machine 2018-12-18 10:36 ` Bin Meng @ 2018-12-19 4:40 ` Anup Patel 2018-12-19 5:32 ` Bin Meng 0 siblings, 1 reply; 26+ messages in thread From: Anup Patel @ 2018-12-19 4:40 UTC (permalink / raw) To: u-boot 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 at anup-ubuntu64:~/Work/riscv-test/u-boot$ qemu-system-riscv64 -M sifive_u -m 256M -display none -serial stdio -kernel ./u-boot U-Boot 2019.01-rc1-00948-ge6b3cdafd0 (Dec 19 2018 - 10:05:50 +0530) CPU: rv64imafdcsu Model: ucbbar,spike-bare,qemu DRAM: 256 MiB In: uart at 10013000 Out: uart at 10013000 Err: uart at 10013000 Net: Warning: ethernet at 100900fc (eth0) using random MAC address - f6:1f:8c:13:83:c0 eth0: ethernet at 100900fc Hit any key to stop autoboot: 0 Device 0: unknown device ethernet at 100900fc: PHY present at 0 ethernet at 100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1) BOOTP broadcast 1 DHCP client bound to address 10.0.2.15 (2 ms) Using ethernet at 100900fc device TFTP from server 10.0.2.2; our IP address is 10.0.2.15 Filename 'boot.scr.uimg'. Load address: 0x82100000 Loading: * TFTP error: 'Access violation' (2) Not retrying... ethernet at 100900fc: PHY present at 0 ethernet at 100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1) BOOTP broadcast 1 DHCP client bound to address 10.0.2.15 (1 ms) Using ethernet at 100900fc device TFTP from server 10.0.2.2; our IP address is 10.0.2.15 Filename 'boot.scr.uimg'. Load address: 0x81000000 Loading: * TFTP error: 'Access violation' (2) Not retrying... => ping 10.0.2.2 ethernet at 100900fc: PHY present at 0 ethernet at 100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1) Using ethernet at 100900fc device host 10.0.2.2 is alive => ethernet at 100900fc: PHY present at 0 ethernet at 100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1) Using ethernet at 100900fc device host 10.0.2.2 is alive => qemu-system-riscv64: terminating on signal 2 Regards, Anup ^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] [PATCH 0/3] Ethernet support for QEMU sifive_u machine 2018-12-19 4:40 ` Anup Patel @ 2018-12-19 5:32 ` Bin Meng 2018-12-19 6:32 ` Anup Patel 0 siblings, 1 reply; 26+ messages in thread From: Bin Meng @ 2018-12-19 5:32 UTC (permalink / raw) To: u-boot 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 at anup-ubuntu64:~/Work/riscv-test/u-boot$ qemu-system-riscv64 -M > sifive_u -m 256M -display none -serial stdio -kernel ./u-boot > > > U-Boot 2019.01-rc1-00948-ge6b3cdafd0 (Dec 19 2018 - 10:05:50 +0530) > > CPU: rv64imafdcsu > Model: ucbbar,spike-bare,qemu > DRAM: 256 MiB > In: uart at 10013000 > Out: uart at 10013000 > Err: uart at 10013000 > Net: > Warning: ethernet at 100900fc (eth0) using random MAC address - f6:1f:8c:13:83:c0 > eth0: ethernet at 100900fc > Hit any key to stop autoboot: 0 > > Device 0: unknown device > ethernet at 100900fc: PHY present at 0 > ethernet at 100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1) > BOOTP broadcast 1 > DHCP client bound to address 10.0.2.15 (2 ms) > Using ethernet at 100900fc device > TFTP from server 10.0.2.2; our IP address is 10.0.2.15 > Filename 'boot.scr.uimg'. > Load address: 0x82100000 > Loading: * > TFTP error: 'Access violation' (2) > Not retrying... > ethernet at 100900fc: PHY present at 0 > ethernet at 100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1) > BOOTP broadcast 1 > DHCP client bound to address 10.0.2.15 (1 ms) > Using ethernet at 100900fc device > TFTP from server 10.0.2.2; our IP address is 10.0.2.15 > Filename 'boot.scr.uimg'. > Load address: 0x81000000 > Loading: * > TFTP error: 'Access violation' (2) > Not retrying... > => ping 10.0.2.2 > ethernet at 100900fc: PHY present at 0 > ethernet at 100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1) > Using ethernet at 100900fc device > host 10.0.2.2 is alive > => > ethernet at 100900fc: PHY present at 0 > ethernet at 100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1) > Using ethernet at 100900fc device > host 10.0.2.2 is alive > => qemu-system-riscv64: terminating on signal 2 > I have always been using "qemu-system-riscv64 -nographic -M sifive_u -kernel u-boot" to test U-Boot on qemu risc-v. With above command, I can "ping 10.0.2.2" and get the exact the same result as yours. However I wanted to connect the tap interface to the emulated network controller for testing, that's why I wanted to use "-device" and "-netdev", but I don't know which device string I need to tell QEMU. After a bit googleing I got the following page: https://forums.xilinx.com/t5/Embedded-Processor-System-Design/Zynq-QEMU-Network-Issues/td-p/797050 From the page it looks that the device should be "-device cadence_gem", but when I pass it to QEMU I got: qemu-system-riscv64: -device cadence_gem,netdev=net0: Parameter 'driver' expects pluggable device type It looks cadence_gem is not a pluggable device. Any ideas? Regards, Bin ^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] [PATCH 0/3] Ethernet support for QEMU sifive_u machine 2018-12-19 5:32 ` Bin Meng @ 2018-12-19 6:32 ` Anup Patel 2018-12-19 9:05 ` Bin Meng 0 siblings, 1 reply; 26+ messages in thread From: Anup Patel @ 2018-12-19 6:32 UTC (permalink / raw) To: u-boot 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 at anup-ubuntu64:~/Work/riscv-test/u-boot$ qemu-system-riscv64 -M > > sifive_u -m 256M -display none -serial stdio -kernel ./u-boot > > > > > > U-Boot 2019.01-rc1-00948-ge6b3cdafd0 (Dec 19 2018 - 10:05:50 +0530) > > > > CPU: rv64imafdcsu > > Model: ucbbar,spike-bare,qemu > > DRAM: 256 MiB > > In: uart at 10013000 > > Out: uart at 10013000 > > Err: uart at 10013000 > > Net: > > Warning: ethernet at 100900fc (eth0) using random MAC address - f6:1f:8c:13:83:c0 > > eth0: ethernet at 100900fc > > Hit any key to stop autoboot: 0 > > > > Device 0: unknown device > > ethernet at 100900fc: PHY present at 0 > > ethernet at 100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1) > > BOOTP broadcast 1 > > DHCP client bound to address 10.0.2.15 (2 ms) > > Using ethernet at 100900fc device > > TFTP from server 10.0.2.2; our IP address is 10.0.2.15 > > Filename 'boot.scr.uimg'. > > Load address: 0x82100000 > > Loading: * > > TFTP error: 'Access violation' (2) > > Not retrying... > > ethernet at 100900fc: PHY present at 0 > > ethernet at 100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1) > > BOOTP broadcast 1 > > DHCP client bound to address 10.0.2.15 (1 ms) > > Using ethernet at 100900fc device > > TFTP from server 10.0.2.2; our IP address is 10.0.2.15 > > Filename 'boot.scr.uimg'. > > Load address: 0x81000000 > > Loading: * > > TFTP error: 'Access violation' (2) > > Not retrying... > > => ping 10.0.2.2 > > ethernet at 100900fc: PHY present at 0 > > ethernet at 100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1) > > Using ethernet at 100900fc device > > host 10.0.2.2 is alive > > => > > ethernet at 100900fc: PHY present at 0 > > ethernet at 100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1) > > Using ethernet at 100900fc device > > host 10.0.2.2 is alive > > => qemu-system-riscv64: terminating on signal 2 > > > > I have always been using "qemu-system-riscv64 -nographic -M sifive_u > -kernel u-boot" to test U-Boot on qemu risc-v. > With above command, I can "ping 10.0.2.2" and get the exact the same > result as yours. > > However I wanted to connect the tap interface to the emulated network > controller for testing, that's why I wanted to use "-device" and > "-netdev", but I don't know which device string I need to tell QEMU. > After a bit googleing I got the following page: > https://forums.xilinx.com/t5/Embedded-Processor-System-Design/Zynq-QEMU-Network-Issues/td-p/797050 > > From the page it looks that the device should be "-device > cadence_gem", but when I pass it to QEMU I got: > > qemu-system-riscv64: -device cadence_gem,netdev=net0: Parameter > 'driver' expects pluggable device type > > It looks cadence_gem is not a pluggable device. Any ideas? I have mostly tried TAP devices with VirtIO-Net. I believe this could be some bug in Cadence GEM emulation of QEMU. Regards, Anup ^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] [PATCH 0/3] Ethernet support for QEMU sifive_u machine 2018-12-19 6:32 ` Anup Patel @ 2018-12-19 9:05 ` Bin Meng 2018-12-24 1:29 ` Bin Meng 2019-08-07 15:37 ` Bin Meng 0 siblings, 2 replies; 26+ messages in thread From: Bin Meng @ 2018-12-19 9:05 UTC (permalink / raw) To: u-boot 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 at anup-ubuntu64:~/Work/riscv-test/u-boot$ qemu-system-riscv64 -M > > > sifive_u -m 256M -display none -serial stdio -kernel ./u-boot > > > > > > > > > U-Boot 2019.01-rc1-00948-ge6b3cdafd0 (Dec 19 2018 - 10:05:50 +0530) > > > > > > CPU: rv64imafdcsu > > > Model: ucbbar,spike-bare,qemu > > > DRAM: 256 MiB > > > In: uart at 10013000 > > > Out: uart at 10013000 > > > Err: uart at 10013000 > > > Net: > > > Warning: ethernet at 100900fc (eth0) using random MAC address - f6:1f:8c:13:83:c0 > > > eth0: ethernet at 100900fc > > > Hit any key to stop autoboot: 0 > > > > > > Device 0: unknown device > > > ethernet at 100900fc: PHY present at 0 > > > ethernet at 100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1) > > > BOOTP broadcast 1 > > > DHCP client bound to address 10.0.2.15 (2 ms) > > > Using ethernet at 100900fc device > > > TFTP from server 10.0.2.2; our IP address is 10.0.2.15 > > > Filename 'boot.scr.uimg'. > > > Load address: 0x82100000 > > > Loading: * > > > TFTP error: 'Access violation' (2) > > > Not retrying... > > > ethernet at 100900fc: PHY present at 0 > > > ethernet at 100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1) > > > BOOTP broadcast 1 > > > DHCP client bound to address 10.0.2.15 (1 ms) > > > Using ethernet at 100900fc device > > > TFTP from server 10.0.2.2; our IP address is 10.0.2.15 > > > Filename 'boot.scr.uimg'. > > > Load address: 0x81000000 > > > Loading: * > > > TFTP error: 'Access violation' (2) > > > Not retrying... > > > => ping 10.0.2.2 > > > ethernet at 100900fc: PHY present at 0 > > > ethernet at 100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1) > > > Using ethernet at 100900fc device > > > host 10.0.2.2 is alive > > > => > > > ethernet at 100900fc: PHY present at 0 > > > ethernet at 100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1) > > > Using ethernet at 100900fc device > > > host 10.0.2.2 is alive > > > => qemu-system-riscv64: terminating on signal 2 > > > > > > > I have always been using "qemu-system-riscv64 -nographic -M sifive_u > > -kernel u-boot" to test U-Boot on qemu risc-v. > > With above command, I can "ping 10.0.2.2" and get the exact the same > > result as yours. > > > > However I wanted to connect the tap interface to the emulated network > > controller for testing, that's why I wanted to use "-device" and > > "-netdev", but I don't know which device string I need to tell QEMU. > > After a bit googleing I got the following page: > > https://forums.xilinx.com/t5/Embedded-Processor-System-Design/Zynq-QEMU-Network-Issues/td-p/797050 > > > > From the page it looks that the device should be "-device > > cadence_gem", but when I pass it to QEMU I got: > > > > qemu-system-riscv64: -device cadence_gem,netdev=net0: Parameter > > 'driver' expects pluggable device type > > > > It looks cadence_gem is not a pluggable device. Any ideas? > > I have mostly tried TAP devices with VirtIO-Net. I believe this could be > some bug in Cadence GEM emulation of QEMU. I managed to get tap interface connected to the cadence_gem controller. The QEMU command line is "qemu-system-riscv64 -nographic -M sifive_u -kernel u-boot -nic tap,model=cadence_gem" A single "ping" works after I set related network environments in the shell. But "tftp" test fails. It looks the driver just time out. => tftp 84000000 bmeng/uImage.riscv ethernet at 100900fc: PHY present at 0 ethernet at 100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1) Using ethernet at 100900fc device TFTP from server 10.10.0.100; our IP address is 10.10.0.108 Filename 'bmeng/uImage.riscv'. Load address: 0x84000000 Loading: #T T #T T #T #T T #T #T T # Retry count exceeded; starting again Can you please take a look? Regards, Bin ^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] [PATCH 0/3] Ethernet support for QEMU sifive_u machine 2018-12-19 9:05 ` Bin Meng @ 2018-12-24 1:29 ` Bin Meng 2018-12-24 5:41 ` Anup Patel 2019-08-07 15:37 ` Bin Meng 1 sibling, 1 reply; 26+ messages in thread From: Bin Meng @ 2018-12-24 1:29 UTC (permalink / raw) To: u-boot 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 at anup-ubuntu64:~/Work/riscv-test/u-boot$ qemu-system-riscv64 -M > > > > sifive_u -m 256M -display none -serial stdio -kernel ./u-boot > > > > > > > > > > > > U-Boot 2019.01-rc1-00948-ge6b3cdafd0 (Dec 19 2018 - 10:05:50 +0530) > > > > > > > > CPU: rv64imafdcsu > > > > Model: ucbbar,spike-bare,qemu > > > > DRAM: 256 MiB > > > > In: uart at 10013000 > > > > Out: uart at 10013000 > > > > Err: uart at 10013000 > > > > Net: > > > > Warning: ethernet at 100900fc (eth0) using random MAC address - f6:1f:8c:13:83:c0 > > > > eth0: ethernet at 100900fc > > > > Hit any key to stop autoboot: 0 > > > > > > > > Device 0: unknown device > > > > ethernet at 100900fc: PHY present at 0 > > > > ethernet at 100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1) > > > > BOOTP broadcast 1 > > > > DHCP client bound to address 10.0.2.15 (2 ms) > > > > Using ethernet at 100900fc device > > > > TFTP from server 10.0.2.2; our IP address is 10.0.2.15 > > > > Filename 'boot.scr.uimg'. > > > > Load address: 0x82100000 > > > > Loading: * > > > > TFTP error: 'Access violation' (2) > > > > Not retrying... > > > > ethernet at 100900fc: PHY present at 0 > > > > ethernet at 100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1) > > > > BOOTP broadcast 1 > > > > DHCP client bound to address 10.0.2.15 (1 ms) > > > > Using ethernet at 100900fc device > > > > TFTP from server 10.0.2.2; our IP address is 10.0.2.15 > > > > Filename 'boot.scr.uimg'. > > > > Load address: 0x81000000 > > > > Loading: * > > > > TFTP error: 'Access violation' (2) > > > > Not retrying... > > > > => ping 10.0.2.2 > > > > ethernet at 100900fc: PHY present at 0 > > > > ethernet at 100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1) > > > > Using ethernet at 100900fc device > > > > host 10.0.2.2 is alive > > > > => > > > > ethernet at 100900fc: PHY present at 0 > > > > ethernet at 100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1) > > > > Using ethernet at 100900fc device > > > > host 10.0.2.2 is alive > > > > => qemu-system-riscv64: terminating on signal 2 > > > > > > > > > > I have always been using "qemu-system-riscv64 -nographic -M sifive_u > > > -kernel u-boot" to test U-Boot on qemu risc-v. > > > With above command, I can "ping 10.0.2.2" and get the exact the same > > > result as yours. > > > > > > However I wanted to connect the tap interface to the emulated network > > > controller for testing, that's why I wanted to use "-device" and > > > "-netdev", but I don't know which device string I need to tell QEMU. > > > After a bit googleing I got the following page: > > > https://forums.xilinx.com/t5/Embedded-Processor-System-Design/Zynq-QEMU-Network-Issues/td-p/797050 > > > > > > From the page it looks that the device should be "-device > > > cadence_gem", but when I pass it to QEMU I got: > > > > > > qemu-system-riscv64: -device cadence_gem,netdev=net0: Parameter > > > 'driver' expects pluggable device type > > > > > > It looks cadence_gem is not a pluggable device. Any ideas? > > > > I have mostly tried TAP devices with VirtIO-Net. I believe this could be > > some bug in Cadence GEM emulation of QEMU. > > I managed to get tap interface connected to the cadence_gem > controller. The QEMU command line is "qemu-system-riscv64 -nographic > -M sifive_u -kernel u-boot -nic tap,model=cadence_gem" > > A single "ping" works after I set related network environments in the > shell. But "tftp" test fails. It looks the driver just time out. > > => tftp 84000000 bmeng/uImage.riscv > ethernet at 100900fc: PHY present at 0 > ethernet at 100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1) > Using ethernet at 100900fc device > TFTP from server 10.10.0.100; our IP address is 10.10.0.108 > Filename 'bmeng/uImage.riscv'. > Load address: 0x84000000 > Loading: #T T #T T #T #T T #T #T T # > Retry count exceeded; starting again > > Can you please take a look? Any idea about the timeouts? Regards, Bin ^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] [PATCH 0/3] Ethernet support for QEMU sifive_u machine 2018-12-24 1:29 ` Bin Meng @ 2018-12-24 5:41 ` Anup Patel 2018-12-24 6:31 ` Bin Meng 0 siblings, 1 reply; 26+ messages in thread From: Anup Patel @ 2018-12-24 5:41 UTC (permalink / raw) To: u-boot 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 at anup-ubuntu64:~/Work/riscv-test/u-boot$ qemu-system-riscv64 -M > > > > > sifive_u -m 256M -display none -serial stdio -kernel ./u-boot > > > > > > > > > > > > > > > U-Boot 2019.01-rc1-00948-ge6b3cdafd0 (Dec 19 2018 - 10:05:50 +0530) > > > > > > > > > > CPU: rv64imafdcsu > > > > > Model: ucbbar,spike-bare,qemu > > > > > DRAM: 256 MiB > > > > > In: uart at 10013000 > > > > > Out: uart at 10013000 > > > > > Err: uart at 10013000 > > > > > Net: > > > > > Warning: ethernet at 100900fc (eth0) using random MAC address - f6:1f:8c:13:83:c0 > > > > > eth0: ethernet at 100900fc > > > > > Hit any key to stop autoboot: 0 > > > > > > > > > > Device 0: unknown device > > > > > ethernet at 100900fc: PHY present at 0 > > > > > ethernet at 100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1) > > > > > BOOTP broadcast 1 > > > > > DHCP client bound to address 10.0.2.15 (2 ms) > > > > > Using ethernet at 100900fc device > > > > > TFTP from server 10.0.2.2; our IP address is 10.0.2.15 > > > > > Filename 'boot.scr.uimg'. > > > > > Load address: 0x82100000 > > > > > Loading: * > > > > > TFTP error: 'Access violation' (2) > > > > > Not retrying... > > > > > ethernet at 100900fc: PHY present at 0 > > > > > ethernet at 100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1) > > > > > BOOTP broadcast 1 > > > > > DHCP client bound to address 10.0.2.15 (1 ms) > > > > > Using ethernet at 100900fc device > > > > > TFTP from server 10.0.2.2; our IP address is 10.0.2.15 > > > > > Filename 'boot.scr.uimg'. > > > > > Load address: 0x81000000 > > > > > Loading: * > > > > > TFTP error: 'Access violation' (2) > > > > > Not retrying... > > > > > => ping 10.0.2.2 > > > > > ethernet at 100900fc: PHY present at 0 > > > > > ethernet at 100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1) > > > > > Using ethernet at 100900fc device > > > > > host 10.0.2.2 is alive > > > > > => > > > > > ethernet at 100900fc: PHY present at 0 > > > > > ethernet at 100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1) > > > > > Using ethernet at 100900fc device > > > > > host 10.0.2.2 is alive > > > > > => qemu-system-riscv64: terminating on signal 2 > > > > > > > > > > > > > I have always been using "qemu-system-riscv64 -nographic -M sifive_u > > > > -kernel u-boot" to test U-Boot on qemu risc-v. > > > > With above command, I can "ping 10.0.2.2" and get the exact the same > > > > result as yours. > > > > > > > > However I wanted to connect the tap interface to the emulated network > > > > controller for testing, that's why I wanted to use "-device" and > > > > "-netdev", but I don't know which device string I need to tell QEMU. > > > > After a bit googleing I got the following page: > > > > https://forums.xilinx.com/t5/Embedded-Processor-System-Design/Zynq-QEMU-Network-Issues/td-p/797050 > > > > > > > > From the page it looks that the device should be "-device > > > > cadence_gem", but when I pass it to QEMU I got: > > > > > > > > qemu-system-riscv64: -device cadence_gem,netdev=net0: Parameter > > > > 'driver' expects pluggable device type > > > > > > > > It looks cadence_gem is not a pluggable device. Any ideas? > > > > > > I have mostly tried TAP devices with VirtIO-Net. I believe this could be > > > some bug in Cadence GEM emulation of QEMU. > > > > I managed to get tap interface connected to the cadence_gem > > controller. The QEMU command line is "qemu-system-riscv64 -nographic > > -M sifive_u -kernel u-boot -nic tap,model=cadence_gem" > > > > A single "ping" works after I set related network environments in the > > shell. But "tftp" test fails. It looks the driver just time out. > > > > => tftp 84000000 bmeng/uImage.riscv > > ethernet at 100900fc: PHY present at 0 > > ethernet at 100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1) > > Using ethernet at 100900fc device > > TFTP from server 10.10.0.100; our IP address is 10.10.0.108 > > Filename 'bmeng/uImage.riscv'. > > Load address: 0x84000000 > > Loading: #T T #T T #T #T T #T #T T # > > Retry count exceeded; starting again > > > > Can you please take a look? > > Any idea about the timeouts? Sorry, I got busy with other stuff. I think this is specific to QEMU environment. The ethernet driver also few udelay calls which can further slow things down. From your log it seems that, it is working functionally but you are seeing too many timeouts. Try playing with "TIMEOUT" or "TIMEOUT_COUNT" in net/tftp.c You can also try same thing over VirtIO net of QEMU virt machine. Regards, Anup ^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] [PATCH 0/3] Ethernet support for QEMU sifive_u machine 2018-12-24 5:41 ` Anup Patel @ 2018-12-24 6:31 ` Bin Meng 2018-12-24 6:42 ` Anup Patel 0 siblings, 1 reply; 26+ messages in thread From: Bin Meng @ 2018-12-24 6:31 UTC (permalink / raw) To: u-boot 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 at anup-ubuntu64:~/Work/riscv-test/u-boot$ qemu-system-riscv64 -M > > > > > > sifive_u -m 256M -display none -serial stdio -kernel ./u-boot > > > > > > > > > > > > > > > > > > U-Boot 2019.01-rc1-00948-ge6b3cdafd0 (Dec 19 2018 - 10:05:50 +0530) > > > > > > > > > > > > CPU: rv64imafdcsu > > > > > > Model: ucbbar,spike-bare,qemu > > > > > > DRAM: 256 MiB > > > > > > In: uart at 10013000 > > > > > > Out: uart at 10013000 > > > > > > Err: uart at 10013000 > > > > > > Net: > > > > > > Warning: ethernet at 100900fc (eth0) using random MAC address - f6:1f:8c:13:83:c0 > > > > > > eth0: ethernet at 100900fc > > > > > > Hit any key to stop autoboot: 0 > > > > > > > > > > > > Device 0: unknown device > > > > > > ethernet at 100900fc: PHY present at 0 > > > > > > ethernet at 100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1) > > > > > > BOOTP broadcast 1 > > > > > > DHCP client bound to address 10.0.2.15 (2 ms) > > > > > > Using ethernet at 100900fc device > > > > > > TFTP from server 10.0.2.2; our IP address is 10.0.2.15 > > > > > > Filename 'boot.scr.uimg'. > > > > > > Load address: 0x82100000 > > > > > > Loading: * > > > > > > TFTP error: 'Access violation' (2) > > > > > > Not retrying... > > > > > > ethernet at 100900fc: PHY present at 0 > > > > > > ethernet at 100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1) > > > > > > BOOTP broadcast 1 > > > > > > DHCP client bound to address 10.0.2.15 (1 ms) > > > > > > Using ethernet at 100900fc device > > > > > > TFTP from server 10.0.2.2; our IP address is 10.0.2.15 > > > > > > Filename 'boot.scr.uimg'. > > > > > > Load address: 0x81000000 > > > > > > Loading: * > > > > > > TFTP error: 'Access violation' (2) > > > > > > Not retrying... > > > > > > => ping 10.0.2.2 > > > > > > ethernet at 100900fc: PHY present at 0 > > > > > > ethernet at 100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1) > > > > > > Using ethernet at 100900fc device > > > > > > host 10.0.2.2 is alive > > > > > > => > > > > > > ethernet at 100900fc: PHY present at 0 > > > > > > ethernet at 100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1) > > > > > > Using ethernet at 100900fc device > > > > > > host 10.0.2.2 is alive > > > > > > => qemu-system-riscv64: terminating on signal 2 > > > > > > > > > > > > > > > > I have always been using "qemu-system-riscv64 -nographic -M sifive_u > > > > > -kernel u-boot" to test U-Boot on qemu risc-v. > > > > > With above command, I can "ping 10.0.2.2" and get the exact the same > > > > > result as yours. > > > > > > > > > > However I wanted to connect the tap interface to the emulated network > > > > > controller for testing, that's why I wanted to use "-device" and > > > > > "-netdev", but I don't know which device string I need to tell QEMU. > > > > > After a bit googleing I got the following page: > > > > > https://forums.xilinx.com/t5/Embedded-Processor-System-Design/Zynq-QEMU-Network-Issues/td-p/797050 > > > > > > > > > > From the page it looks that the device should be "-device > > > > > cadence_gem", but when I pass it to QEMU I got: > > > > > > > > > > qemu-system-riscv64: -device cadence_gem,netdev=net0: Parameter > > > > > 'driver' expects pluggable device type > > > > > > > > > > It looks cadence_gem is not a pluggable device. Any ideas? > > > > > > > > I have mostly tried TAP devices with VirtIO-Net. I believe this could be > > > > some bug in Cadence GEM emulation of QEMU. > > > > > > I managed to get tap interface connected to the cadence_gem > > > controller. The QEMU command line is "qemu-system-riscv64 -nographic > > > -M sifive_u -kernel u-boot -nic tap,model=cadence_gem" > > > > > > A single "ping" works after I set related network environments in the > > > shell. But "tftp" test fails. It looks the driver just time out. > > > > > > => tftp 84000000 bmeng/uImage.riscv > > > ethernet at 100900fc: PHY present at 0 > > > ethernet at 100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1) > > > Using ethernet at 100900fc device > > > TFTP from server 10.10.0.100; our IP address is 10.10.0.108 > > > Filename 'bmeng/uImage.riscv'. > > > Load address: 0x84000000 > > > Loading: #T T #T T #T #T T #T #T T # > > > Retry count exceeded; starting again > > > > > > Can you please take a look? > > > > Any idea about the timeouts? > > Sorry, I got busy with other stuff. > > I think this is specific to QEMU environment. The ethernet driver > also few udelay calls which can further slow things down. > > From your log it seems that, it is working functionally but you > are seeing too many timeouts. Try playing with "TIMEOUT" or > "TIMEOUT_COUNT" in net/tftp.c > I suspect there are some issues with the MACB driver to be used with RISC-V. > You can also try same thing over VirtIO net of QEMU virt machine. The default same settings with VirtIO net interface works like a charm. Regards, Bin ^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] [PATCH 0/3] Ethernet support for QEMU sifive_u machine 2018-12-24 6:31 ` Bin Meng @ 2018-12-24 6:42 ` Anup Patel 2018-12-24 7:15 ` Bin Meng 0 siblings, 1 reply; 26+ messages in thread From: Anup Patel @ 2018-12-24 6:42 UTC (permalink / raw) To: u-boot 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 at anup-ubuntu64:~/Work/riscv-test/u-boot$ qemu-system-riscv64 -M > > > > > > > sifive_u -m 256M -display none -serial stdio -kernel ./u-boot > > > > > > > > > > > > > > > > > > > > > U-Boot 2019.01-rc1-00948-ge6b3cdafd0 (Dec 19 2018 - 10:05:50 +0530) > > > > > > > > > > > > > > CPU: rv64imafdcsu > > > > > > > Model: ucbbar,spike-bare,qemu > > > > > > > DRAM: 256 MiB > > > > > > > In: uart at 10013000 > > > > > > > Out: uart at 10013000 > > > > > > > Err: uart at 10013000 > > > > > > > Net: > > > > > > > Warning: ethernet at 100900fc (eth0) using random MAC address - f6:1f:8c:13:83:c0 > > > > > > > eth0: ethernet at 100900fc > > > > > > > Hit any key to stop autoboot: 0 > > > > > > > > > > > > > > Device 0: unknown device > > > > > > > ethernet at 100900fc: PHY present at 0 > > > > > > > ethernet at 100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1) > > > > > > > BOOTP broadcast 1 > > > > > > > DHCP client bound to address 10.0.2.15 (2 ms) > > > > > > > Using ethernet at 100900fc device > > > > > > > TFTP from server 10.0.2.2; our IP address is 10.0.2.15 > > > > > > > Filename 'boot.scr.uimg'. > > > > > > > Load address: 0x82100000 > > > > > > > Loading: * > > > > > > > TFTP error: 'Access violation' (2) > > > > > > > Not retrying... > > > > > > > ethernet at 100900fc: PHY present at 0 > > > > > > > ethernet at 100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1) > > > > > > > BOOTP broadcast 1 > > > > > > > DHCP client bound to address 10.0.2.15 (1 ms) > > > > > > > Using ethernet at 100900fc device > > > > > > > TFTP from server 10.0.2.2; our IP address is 10.0.2.15 > > > > > > > Filename 'boot.scr.uimg'. > > > > > > > Load address: 0x81000000 > > > > > > > Loading: * > > > > > > > TFTP error: 'Access violation' (2) > > > > > > > Not retrying... > > > > > > > => ping 10.0.2.2 > > > > > > > ethernet at 100900fc: PHY present at 0 > > > > > > > ethernet at 100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1) > > > > > > > Using ethernet at 100900fc device > > > > > > > host 10.0.2.2 is alive > > > > > > > => > > > > > > > ethernet at 100900fc: PHY present at 0 > > > > > > > ethernet at 100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1) > > > > > > > Using ethernet at 100900fc device > > > > > > > host 10.0.2.2 is alive > > > > > > > => qemu-system-riscv64: terminating on signal 2 > > > > > > > > > > > > > > > > > > > I have always been using "qemu-system-riscv64 -nographic -M sifive_u > > > > > > -kernel u-boot" to test U-Boot on qemu risc-v. > > > > > > With above command, I can "ping 10.0.2.2" and get the exact the same > > > > > > result as yours. > > > > > > > > > > > > However I wanted to connect the tap interface to the emulated network > > > > > > controller for testing, that's why I wanted to use "-device" and > > > > > > "-netdev", but I don't know which device string I need to tell QEMU. > > > > > > After a bit googleing I got the following page: > > > > > > https://forums.xilinx.com/t5/Embedded-Processor-System-Design/Zynq-QEMU-Network-Issues/td-p/797050 > > > > > > > > > > > > From the page it looks that the device should be "-device > > > > > > cadence_gem", but when I pass it to QEMU I got: > > > > > > > > > > > > qemu-system-riscv64: -device cadence_gem,netdev=net0: Parameter > > > > > > 'driver' expects pluggable device type > > > > > > > > > > > > It looks cadence_gem is not a pluggable device. Any ideas? > > > > > > > > > > I have mostly tried TAP devices with VirtIO-Net. I believe this could be > > > > > some bug in Cadence GEM emulation of QEMU. > > > > > > > > I managed to get tap interface connected to the cadence_gem > > > > controller. The QEMU command line is "qemu-system-riscv64 -nographic > > > > -M sifive_u -kernel u-boot -nic tap,model=cadence_gem" > > > > > > > > A single "ping" works after I set related network environments in the > > > > shell. But "tftp" test fails. It looks the driver just time out. > > > > > > > > => tftp 84000000 bmeng/uImage.riscv > > > > ethernet at 100900fc: PHY present at 0 > > > > ethernet at 100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1) > > > > Using ethernet at 100900fc device > > > > TFTP from server 10.10.0.100; our IP address is 10.10.0.108 > > > > Filename 'bmeng/uImage.riscv'. > > > > Load address: 0x84000000 > > > > Loading: #T T #T T #T #T T #T #T T # > > > > Retry count exceeded; starting again > > > > > > > > Can you please take a look? > > > > > > Any idea about the timeouts? > > > > Sorry, I got busy with other stuff. > > > > I think this is specific to QEMU environment. The ethernet driver > > also few udelay calls which can further slow things down. > > > > From your log it seems that, it is working functionally but you > > are seeing too many timeouts. Try playing with "TIMEOUT" or > > "TIMEOUT_COUNT" in net/tftp.c > > > > I suspect there are some issues with the MACB driver to be used with RISC-V. 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] [PATCH 0/3] Ethernet support for QEMU sifive_u machine 2018-12-24 6:42 ` Anup Patel @ 2018-12-24 7:15 ` Bin Meng 2018-12-24 7:23 ` Anup Patel 0 siblings, 1 reply; 26+ messages in thread From: Bin Meng @ 2018-12-24 7:15 UTC (permalink / raw) To: u-boot 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 at anup-ubuntu64:~/Work/riscv-test/u-boot$ qemu-system-riscv64 -M > > > > > > > > sifive_u -m 256M -display none -serial stdio -kernel ./u-boot > > > > > > > > > > > > > > > > > > > > > > > > U-Boot 2019.01-rc1-00948-ge6b3cdafd0 (Dec 19 2018 - 10:05:50 +0530) > > > > > > > > > > > > > > > > CPU: rv64imafdcsu > > > > > > > > Model: ucbbar,spike-bare,qemu > > > > > > > > DRAM: 256 MiB > > > > > > > > In: uart at 10013000 > > > > > > > > Out: uart at 10013000 > > > > > > > > Err: uart at 10013000 > > > > > > > > Net: > > > > > > > > Warning: ethernet at 100900fc (eth0) using random MAC address - f6:1f:8c:13:83:c0 > > > > > > > > eth0: ethernet at 100900fc > > > > > > > > Hit any key to stop autoboot: 0 > > > > > > > > > > > > > > > > Device 0: unknown device > > > > > > > > ethernet at 100900fc: PHY present at 0 > > > > > > > > ethernet at 100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1) > > > > > > > > BOOTP broadcast 1 > > > > > > > > DHCP client bound to address 10.0.2.15 (2 ms) > > > > > > > > Using ethernet at 100900fc device > > > > > > > > TFTP from server 10.0.2.2; our IP address is 10.0.2.15 > > > > > > > > Filename 'boot.scr.uimg'. > > > > > > > > Load address: 0x82100000 > > > > > > > > Loading: * > > > > > > > > TFTP error: 'Access violation' (2) > > > > > > > > Not retrying... > > > > > > > > ethernet at 100900fc: PHY present at 0 > > > > > > > > ethernet at 100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1) > > > > > > > > BOOTP broadcast 1 > > > > > > > > DHCP client bound to address 10.0.2.15 (1 ms) > > > > > > > > Using ethernet at 100900fc device > > > > > > > > TFTP from server 10.0.2.2; our IP address is 10.0.2.15 > > > > > > > > Filename 'boot.scr.uimg'. > > > > > > > > Load address: 0x81000000 > > > > > > > > Loading: * > > > > > > > > TFTP error: 'Access violation' (2) > > > > > > > > Not retrying... > > > > > > > > => ping 10.0.2.2 > > > > > > > > ethernet at 100900fc: PHY present at 0 > > > > > > > > ethernet at 100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1) > > > > > > > > Using ethernet at 100900fc device > > > > > > > > host 10.0.2.2 is alive > > > > > > > > => > > > > > > > > ethernet at 100900fc: PHY present at 0 > > > > > > > > ethernet at 100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1) > > > > > > > > Using ethernet at 100900fc device > > > > > > > > host 10.0.2.2 is alive > > > > > > > > => qemu-system-riscv64: terminating on signal 2 > > > > > > > > > > > > > > > > > > > > > > I have always been using "qemu-system-riscv64 -nographic -M sifive_u > > > > > > > -kernel u-boot" to test U-Boot on qemu risc-v. > > > > > > > With above command, I can "ping 10.0.2.2" and get the exact the same > > > > > > > result as yours. > > > > > > > > > > > > > > However I wanted to connect the tap interface to the emulated network > > > > > > > controller for testing, that's why I wanted to use "-device" and > > > > > > > "-netdev", but I don't know which device string I need to tell QEMU. > > > > > > > After a bit googleing I got the following page: > > > > > > > https://forums.xilinx.com/t5/Embedded-Processor-System-Design/Zynq-QEMU-Network-Issues/td-p/797050 > > > > > > > > > > > > > > From the page it looks that the device should be "-device > > > > > > > cadence_gem", but when I pass it to QEMU I got: > > > > > > > > > > > > > > qemu-system-riscv64: -device cadence_gem,netdev=net0: Parameter > > > > > > > 'driver' expects pluggable device type > > > > > > > > > > > > > > It looks cadence_gem is not a pluggable device. Any ideas? > > > > > > > > > > > > I have mostly tried TAP devices with VirtIO-Net. I believe this could be > > > > > > some bug in Cadence GEM emulation of QEMU. > > > > > > > > > > I managed to get tap interface connected to the cadence_gem > > > > > controller. The QEMU command line is "qemu-system-riscv64 -nographic > > > > > -M sifive_u -kernel u-boot -nic tap,model=cadence_gem" > > > > > > > > > > A single "ping" works after I set related network environments in the > > > > > shell. But "tftp" test fails. It looks the driver just time out. > > > > > > > > > > => tftp 84000000 bmeng/uImage.riscv > > > > > ethernet at 100900fc: PHY present at 0 > > > > > ethernet at 100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1) > > > > > Using ethernet at 100900fc device > > > > > TFTP from server 10.10.0.100; our IP address is 10.10.0.108 > > > > > Filename 'bmeng/uImage.riscv'. > > > > > Load address: 0x84000000 > > > > > Loading: #T T #T T #T #T T #T #T T # > > > > > Retry count exceeded; starting again > > > > > > > > > > Can you please take a look? > > > > > > > > Any idea about the timeouts? > > > > > > Sorry, I got busy with other stuff. > > > > > > I think this is specific to QEMU environment. The ethernet driver > > > also few udelay calls which can further slow things down. > > > > > > From your log it seems that, it is working functionally but you > > > are seeing too many timeouts. Try playing with "TIMEOUT" or > > > "TIMEOUT_COUNT" in net/tftp.c > > > > > > > I suspect there are some issues with the MACB driver to be used with RISC-V. > > 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] [PATCH 0/3] Ethernet support for QEMU sifive_u machine 2018-12-24 7:15 ` Bin Meng @ 2018-12-24 7:23 ` Anup Patel 2018-12-24 7:36 ` Bin Meng 0 siblings, 1 reply; 26+ messages in thread From: Anup Patel @ 2018-12-24 7:23 UTC (permalink / raw) To: u-boot 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 at anup-ubuntu64:~/Work/riscv-test/u-boot$ qemu-system-riscv64 -M > > > > > > > > > sifive_u -m 256M -display none -serial stdio -kernel ./u-boot > > > > > > > > > > > > > > > > > > > > > > > > > > > U-Boot 2019.01-rc1-00948-ge6b3cdafd0 (Dec 19 2018 - 10:05:50 +0530) > > > > > > > > > > > > > > > > > > CPU: rv64imafdcsu > > > > > > > > > Model: ucbbar,spike-bare,qemu > > > > > > > > > DRAM: 256 MiB > > > > > > > > > In: uart at 10013000 > > > > > > > > > Out: uart at 10013000 > > > > > > > > > Err: uart at 10013000 > > > > > > > > > Net: > > > > > > > > > Warning: ethernet at 100900fc (eth0) using random MAC address - f6:1f:8c:13:83:c0 > > > > > > > > > eth0: ethernet at 100900fc > > > > > > > > > Hit any key to stop autoboot: 0 > > > > > > > > > > > > > > > > > > Device 0: unknown device > > > > > > > > > ethernet at 100900fc: PHY present at 0 > > > > > > > > > ethernet at 100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1) > > > > > > > > > BOOTP broadcast 1 > > > > > > > > > DHCP client bound to address 10.0.2.15 (2 ms) > > > > > > > > > Using ethernet at 100900fc device > > > > > > > > > TFTP from server 10.0.2.2; our IP address is 10.0.2.15 > > > > > > > > > Filename 'boot.scr.uimg'. > > > > > > > > > Load address: 0x82100000 > > > > > > > > > Loading: * > > > > > > > > > TFTP error: 'Access violation' (2) > > > > > > > > > Not retrying... > > > > > > > > > ethernet at 100900fc: PHY present at 0 > > > > > > > > > ethernet at 100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1) > > > > > > > > > BOOTP broadcast 1 > > > > > > > > > DHCP client bound to address 10.0.2.15 (1 ms) > > > > > > > > > Using ethernet at 100900fc device > > > > > > > > > TFTP from server 10.0.2.2; our IP address is 10.0.2.15 > > > > > > > > > Filename 'boot.scr.uimg'. > > > > > > > > > Load address: 0x81000000 > > > > > > > > > Loading: * > > > > > > > > > TFTP error: 'Access violation' (2) > > > > > > > > > Not retrying... > > > > > > > > > => ping 10.0.2.2 > > > > > > > > > ethernet at 100900fc: PHY present at 0 > > > > > > > > > ethernet at 100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1) > > > > > > > > > Using ethernet at 100900fc device > > > > > > > > > host 10.0.2.2 is alive > > > > > > > > > => > > > > > > > > > ethernet at 100900fc: PHY present at 0 > > > > > > > > > ethernet at 100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1) > > > > > > > > > Using ethernet at 100900fc device > > > > > > > > > host 10.0.2.2 is alive > > > > > > > > > => qemu-system-riscv64: terminating on signal 2 > > > > > > > > > > > > > > > > > > > > > > > > > I have always been using "qemu-system-riscv64 -nographic -M sifive_u > > > > > > > > -kernel u-boot" to test U-Boot on qemu risc-v. > > > > > > > > With above command, I can "ping 10.0.2.2" and get the exact the same > > > > > > > > result as yours. > > > > > > > > > > > > > > > > However I wanted to connect the tap interface to the emulated network > > > > > > > > controller for testing, that's why I wanted to use "-device" and > > > > > > > > "-netdev", but I don't know which device string I need to tell QEMU. > > > > > > > > After a bit googleing I got the following page: > > > > > > > > https://forums.xilinx.com/t5/Embedded-Processor-System-Design/Zynq-QEMU-Network-Issues/td-p/797050 > > > > > > > > > > > > > > > > From the page it looks that the device should be "-device > > > > > > > > cadence_gem", but when I pass it to QEMU I got: > > > > > > > > > > > > > > > > qemu-system-riscv64: -device cadence_gem,netdev=net0: Parameter > > > > > > > > 'driver' expects pluggable device type > > > > > > > > > > > > > > > > It looks cadence_gem is not a pluggable device. Any ideas? > > > > > > > > > > > > > > I have mostly tried TAP devices with VirtIO-Net. I believe this could be > > > > > > > some bug in Cadence GEM emulation of QEMU. > > > > > > > > > > > > I managed to get tap interface connected to the cadence_gem > > > > > > controller. The QEMU command line is "qemu-system-riscv64 -nographic > > > > > > -M sifive_u -kernel u-boot -nic tap,model=cadence_gem" > > > > > > > > > > > > A single "ping" works after I set related network environments in the > > > > > > shell. But "tftp" test fails. It looks the driver just time out. > > > > > > > > > > > > => tftp 84000000 bmeng/uImage.riscv > > > > > > ethernet at 100900fc: PHY present at 0 > > > > > > ethernet at 100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1) > > > > > > Using ethernet at 100900fc device > > > > > > TFTP from server 10.10.0.100; our IP address is 10.10.0.108 > > > > > > Filename 'bmeng/uImage.riscv'. > > > > > > Load address: 0x84000000 > > > > > > Loading: #T T #T T #T #T T #T #T T # > > > > > > Retry count exceeded; starting again > > > > > > > > > > > > Can you please take a look? > > > > > > > > > > Any idea about the timeouts? > > > > > > > > Sorry, I got busy with other stuff. > > > > > > > > I think this is specific to QEMU environment. The ethernet driver > > > > also few udelay calls which can further slow things down. > > > > > > > > From your log it seems that, it is working functionally but you > > > > are seeing too many timeouts. Try playing with "TIMEOUT" or > > > > "TIMEOUT_COUNT" in net/tftp.c > > > > > > > > > > I suspect there are some issues with the MACB driver to be used with RISC-V. > > > > 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] [PATCH 0/3] Ethernet support for QEMU sifive_u machine 2018-12-24 7:23 ` Anup Patel @ 2018-12-24 7:36 ` Bin Meng 2018-12-24 11:34 ` Anup Patel 0 siblings, 1 reply; 26+ messages in thread From: Bin Meng @ 2018-12-24 7:36 UTC (permalink / raw) To: u-boot 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 at anup-ubuntu64:~/Work/riscv-test/u-boot$ qemu-system-riscv64 -M > > > > > > > > > > sifive_u -m 256M -display none -serial stdio -kernel ./u-boot > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > U-Boot 2019.01-rc1-00948-ge6b3cdafd0 (Dec 19 2018 - 10:05:50 +0530) > > > > > > > > > > > > > > > > > > > > CPU: rv64imafdcsu > > > > > > > > > > Model: ucbbar,spike-bare,qemu > > > > > > > > > > DRAM: 256 MiB > > > > > > > > > > In: uart at 10013000 > > > > > > > > > > Out: uart at 10013000 > > > > > > > > > > Err: uart at 10013000 > > > > > > > > > > Net: > > > > > > > > > > Warning: ethernet at 100900fc (eth0) using random MAC address - f6:1f:8c:13:83:c0 > > > > > > > > > > eth0: ethernet at 100900fc > > > > > > > > > > Hit any key to stop autoboot: 0 > > > > > > > > > > > > > > > > > > > > Device 0: unknown device > > > > > > > > > > ethernet at 100900fc: PHY present at 0 > > > > > > > > > > ethernet at 100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1) > > > > > > > > > > BOOTP broadcast 1 > > > > > > > > > > DHCP client bound to address 10.0.2.15 (2 ms) > > > > > > > > > > Using ethernet at 100900fc device > > > > > > > > > > TFTP from server 10.0.2.2; our IP address is 10.0.2.15 > > > > > > > > > > Filename 'boot.scr.uimg'. > > > > > > > > > > Load address: 0x82100000 > > > > > > > > > > Loading: * > > > > > > > > > > TFTP error: 'Access violation' (2) > > > > > > > > > > Not retrying... > > > > > > > > > > ethernet at 100900fc: PHY present at 0 > > > > > > > > > > ethernet at 100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1) > > > > > > > > > > BOOTP broadcast 1 > > > > > > > > > > DHCP client bound to address 10.0.2.15 (1 ms) > > > > > > > > > > Using ethernet at 100900fc device > > > > > > > > > > TFTP from server 10.0.2.2; our IP address is 10.0.2.15 > > > > > > > > > > Filename 'boot.scr.uimg'. > > > > > > > > > > Load address: 0x81000000 > > > > > > > > > > Loading: * > > > > > > > > > > TFTP error: 'Access violation' (2) > > > > > > > > > > Not retrying... > > > > > > > > > > => ping 10.0.2.2 > > > > > > > > > > ethernet at 100900fc: PHY present at 0 > > > > > > > > > > ethernet at 100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1) > > > > > > > > > > Using ethernet at 100900fc device > > > > > > > > > > host 10.0.2.2 is alive > > > > > > > > > > => > > > > > > > > > > ethernet at 100900fc: PHY present at 0 > > > > > > > > > > ethernet at 100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1) > > > > > > > > > > Using ethernet at 100900fc device > > > > > > > > > > host 10.0.2.2 is alive > > > > > > > > > > => qemu-system-riscv64: terminating on signal 2 > > > > > > > > > > > > > > > > > > > > > > > > > > > > I have always been using "qemu-system-riscv64 -nographic -M sifive_u > > > > > > > > > -kernel u-boot" to test U-Boot on qemu risc-v. > > > > > > > > > With above command, I can "ping 10.0.2.2" and get the exact the same > > > > > > > > > result as yours. > > > > > > > > > > > > > > > > > > However I wanted to connect the tap interface to the emulated network > > > > > > > > > controller for testing, that's why I wanted to use "-device" and > > > > > > > > > "-netdev", but I don't know which device string I need to tell QEMU. > > > > > > > > > After a bit googleing I got the following page: > > > > > > > > > https://forums.xilinx.com/t5/Embedded-Processor-System-Design/Zynq-QEMU-Network-Issues/td-p/797050 > > > > > > > > > > > > > > > > > > From the page it looks that the device should be "-device > > > > > > > > > cadence_gem", but when I pass it to QEMU I got: > > > > > > > > > > > > > > > > > > qemu-system-riscv64: -device cadence_gem,netdev=net0: Parameter > > > > > > > > > 'driver' expects pluggable device type > > > > > > > > > > > > > > > > > > It looks cadence_gem is not a pluggable device. Any ideas? > > > > > > > > > > > > > > > > I have mostly tried TAP devices with VirtIO-Net. I believe this could be > > > > > > > > some bug in Cadence GEM emulation of QEMU. > > > > > > > > > > > > > > I managed to get tap interface connected to the cadence_gem > > > > > > > controller. The QEMU command line is "qemu-system-riscv64 -nographic > > > > > > > -M sifive_u -kernel u-boot -nic tap,model=cadence_gem" > > > > > > > > > > > > > > A single "ping" works after I set related network environments in the > > > > > > > shell. But "tftp" test fails. It looks the driver just time out. > > > > > > > > > > > > > > => tftp 84000000 bmeng/uImage.riscv > > > > > > > ethernet at 100900fc: PHY present at 0 > > > > > > > ethernet at 100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1) > > > > > > > Using ethernet at 100900fc device > > > > > > > TFTP from server 10.10.0.100; our IP address is 10.10.0.108 > > > > > > > Filename 'bmeng/uImage.riscv'. > > > > > > > Load address: 0x84000000 > > > > > > > Loading: #T T #T T #T #T T #T #T T # > > > > > > > Retry count exceeded; starting again > > > > > > > > > > > > > > Can you please take a look? > > > > > > > > > > > > Any idea about the timeouts? > > > > > > > > > > Sorry, I got busy with other stuff. > > > > > > > > > > I think this is specific to QEMU environment. The ethernet driver > > > > > also few udelay calls which can further slow things down. > > > > > > > > > > From your log it seems that, it is working functionally but you > > > > > are seeing too many timeouts. Try playing with "TIMEOUT" or > > > > > "TIMEOUT_COUNT" in net/tftp.c > > > > > > > > > > > > > I suspect there are some issues with the MACB driver to be used with RISC-V. > > > > > > 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] [PATCH 0/3] Ethernet support for QEMU sifive_u machine 2018-12-24 7:36 ` Bin Meng @ 2018-12-24 11:34 ` Anup Patel 0 siblings, 0 replies; 26+ messages in thread From: Anup Patel @ 2018-12-24 11:34 UTC (permalink / raw) To: u-boot 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 at anup-ubuntu64:~/Work/riscv-test/u-boot$ qemu-system-riscv64 -M > > > > > > > > > > > sifive_u -m 256M -display none -serial stdio -kernel ./u-boot > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > U-Boot 2019.01-rc1-00948-ge6b3cdafd0 (Dec 19 2018 - 10:05:50 +0530) > > > > > > > > > > > > > > > > > > > > > > CPU: rv64imafdcsu > > > > > > > > > > > Model: ucbbar,spike-bare,qemu > > > > > > > > > > > DRAM: 256 MiB > > > > > > > > > > > In: uart at 10013000 > > > > > > > > > > > Out: uart at 10013000 > > > > > > > > > > > Err: uart at 10013000 > > > > > > > > > > > Net: > > > > > > > > > > > Warning: ethernet at 100900fc (eth0) using random MAC address - f6:1f:8c:13:83:c0 > > > > > > > > > > > eth0: ethernet at 100900fc > > > > > > > > > > > Hit any key to stop autoboot: 0 > > > > > > > > > > > > > > > > > > > > > > Device 0: unknown device > > > > > > > > > > > ethernet at 100900fc: PHY present at 0 > > > > > > > > > > > ethernet at 100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1) > > > > > > > > > > > BOOTP broadcast 1 > > > > > > > > > > > DHCP client bound to address 10.0.2.15 (2 ms) > > > > > > > > > > > Using ethernet at 100900fc device > > > > > > > > > > > TFTP from server 10.0.2.2; our IP address is 10.0.2.15 > > > > > > > > > > > Filename 'boot.scr.uimg'. > > > > > > > > > > > Load address: 0x82100000 > > > > > > > > > > > Loading: * > > > > > > > > > > > TFTP error: 'Access violation' (2) > > > > > > > > > > > Not retrying... > > > > > > > > > > > ethernet at 100900fc: PHY present at 0 > > > > > > > > > > > ethernet at 100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1) > > > > > > > > > > > BOOTP broadcast 1 > > > > > > > > > > > DHCP client bound to address 10.0.2.15 (1 ms) > > > > > > > > > > > Using ethernet at 100900fc device > > > > > > > > > > > TFTP from server 10.0.2.2; our IP address is 10.0.2.15 > > > > > > > > > > > Filename 'boot.scr.uimg'. > > > > > > > > > > > Load address: 0x81000000 > > > > > > > > > > > Loading: * > > > > > > > > > > > TFTP error: 'Access violation' (2) > > > > > > > > > > > Not retrying... > > > > > > > > > > > => ping 10.0.2.2 > > > > > > > > > > > ethernet at 100900fc: PHY present at 0 > > > > > > > > > > > ethernet at 100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1) > > > > > > > > > > > Using ethernet at 100900fc device > > > > > > > > > > > host 10.0.2.2 is alive > > > > > > > > > > > => > > > > > > > > > > > ethernet at 100900fc: PHY present at 0 > > > > > > > > > > > ethernet at 100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1) > > > > > > > > > > > Using ethernet at 100900fc device > > > > > > > > > > > host 10.0.2.2 is alive > > > > > > > > > > > => qemu-system-riscv64: terminating on signal 2 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I have always been using "qemu-system-riscv64 -nographic -M sifive_u > > > > > > > > > > -kernel u-boot" to test U-Boot on qemu risc-v. > > > > > > > > > > With above command, I can "ping 10.0.2.2" and get the exact the same > > > > > > > > > > result as yours. > > > > > > > > > > > > > > > > > > > > However I wanted to connect the tap interface to the emulated network > > > > > > > > > > controller for testing, that's why I wanted to use "-device" and > > > > > > > > > > "-netdev", but I don't know which device string I need to tell QEMU. > > > > > > > > > > After a bit googleing I got the following page: > > > > > > > > > > https://forums.xilinx.com/t5/Embedded-Processor-System-Design/Zynq-QEMU-Network-Issues/td-p/797050 > > > > > > > > > > > > > > > > > > > > From the page it looks that the device should be "-device > > > > > > > > > > cadence_gem", but when I pass it to QEMU I got: > > > > > > > > > > > > > > > > > > > > qemu-system-riscv64: -device cadence_gem,netdev=net0: Parameter > > > > > > > > > > 'driver' expects pluggable device type > > > > > > > > > > > > > > > > > > > > It looks cadence_gem is not a pluggable device. Any ideas? > > > > > > > > > > > > > > > > > > I have mostly tried TAP devices with VirtIO-Net. I believe this could be > > > > > > > > > some bug in Cadence GEM emulation of QEMU. > > > > > > > > > > > > > > > > I managed to get tap interface connected to the cadence_gem > > > > > > > > controller. The QEMU command line is "qemu-system-riscv64 -nographic > > > > > > > > -M sifive_u -kernel u-boot -nic tap,model=cadence_gem" > > > > > > > > > > > > > > > > A single "ping" works after I set related network environments in the > > > > > > > > shell. But "tftp" test fails. It looks the driver just time out. > > > > > > > > > > > > > > > > => tftp 84000000 bmeng/uImage.riscv > > > > > > > > ethernet at 100900fc: PHY present at 0 > > > > > > > > ethernet at 100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1) > > > > > > > > Using ethernet at 100900fc device > > > > > > > > TFTP from server 10.10.0.100; our IP address is 10.10.0.108 > > > > > > > > Filename 'bmeng/uImage.riscv'. > > > > > > > > Load address: 0x84000000 > > > > > > > > Loading: #T T #T T #T #T T #T #T T # > > > > > > > > Retry count exceeded; starting again > > > > > > > > > > > > > > > > Can you please take a look? > > > > > > > > > > > > > > Any idea about the timeouts? > > > > > > > > > > > > Sorry, I got busy with other stuff. > > > > > > > > > > > > I think this is specific to QEMU environment. The ethernet driver > > > > > > also few udelay calls which can further slow things down. > > > > > > > > > > > > From your log it seems that, it is working functionally but you > > > > > > are seeing too many timeouts. Try playing with "TIMEOUT" or > > > > > > "TIMEOUT_COUNT" in net/tftp.c > > > > > > > > > > > > > > > > I suspect there are some issues with the MACB driver to be used with RISC-V. > > > > > > > > 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] [PATCH 0/3] Ethernet support for QEMU sifive_u machine 2018-12-19 9:05 ` Bin Meng 2018-12-24 1:29 ` Bin Meng @ 2019-08-07 15:37 ` Bin Meng 1 sibling, 0 replies; 26+ messages in thread From: Bin Meng @ 2019-08-07 15:37 UTC (permalink / raw) To: u-boot 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 at anup-ubuntu64:~/Work/riscv-test/u-boot$ qemu-system-riscv64 -M > > > > sifive_u -m 256M -display none -serial stdio -kernel ./u-boot > > > > > > > > > > > > U-Boot 2019.01-rc1-00948-ge6b3cdafd0 (Dec 19 2018 - 10:05:50 +0530) > > > > > > > > CPU: rv64imafdcsu > > > > Model: ucbbar,spike-bare,qemu > > > > DRAM: 256 MiB > > > > In: uart at 10013000 > > > > Out: uart at 10013000 > > > > Err: uart at 10013000 > > > > Net: > > > > Warning: ethernet at 100900fc (eth0) using random MAC address - f6:1f:8c:13:83:c0 > > > > eth0: ethernet at 100900fc > > > > Hit any key to stop autoboot: 0 > > > > > > > > Device 0: unknown device > > > > ethernet at 100900fc: PHY present at 0 > > > > ethernet at 100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1) > > > > BOOTP broadcast 1 > > > > DHCP client bound to address 10.0.2.15 (2 ms) > > > > Using ethernet at 100900fc device > > > > TFTP from server 10.0.2.2; our IP address is 10.0.2.15 > > > > Filename 'boot.scr.uimg'. > > > > Load address: 0x82100000 > > > > Loading: * > > > > TFTP error: 'Access violation' (2) > > > > Not retrying... > > > > ethernet at 100900fc: PHY present at 0 > > > > ethernet at 100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1) > > > > BOOTP broadcast 1 > > > > DHCP client bound to address 10.0.2.15 (1 ms) > > > > Using ethernet at 100900fc device > > > > TFTP from server 10.0.2.2; our IP address is 10.0.2.15 > > > > Filename 'boot.scr.uimg'. > > > > Load address: 0x81000000 > > > > Loading: * > > > > TFTP error: 'Access violation' (2) > > > > Not retrying... > > > > => ping 10.0.2.2 > > > > ethernet at 100900fc: PHY present at 0 > > > > ethernet at 100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1) > > > > Using ethernet at 100900fc device > > > > host 10.0.2.2 is alive > > > > => > > > > ethernet at 100900fc: PHY present at 0 > > > > ethernet at 100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1) > > > > Using ethernet at 100900fc device > > > > host 10.0.2.2 is alive > > > > => qemu-system-riscv64: terminating on signal 2 > > > > > > > > > > I have always been using "qemu-system-riscv64 -nographic -M sifive_u > > > -kernel u-boot" to test U-Boot on qemu risc-v. > > > With above command, I can "ping 10.0.2.2" and get the exact the same > > > result as yours. > > > > > > However I wanted to connect the tap interface to the emulated network > > > controller for testing, that's why I wanted to use "-device" and > > > "-netdev", but I don't know which device string I need to tell QEMU. > > > After a bit googleing I got the following page: > > > https://forums.xilinx.com/t5/Embedded-Processor-System-Design/Zynq-QEMU-Network-Issues/td-p/797050 > > > > > > From the page it looks that the device should be "-device > > > cadence_gem", but when I pass it to QEMU I got: > > > > > > qemu-system-riscv64: -device cadence_gem,netdev=net0: Parameter > > > 'driver' expects pluggable device type > > > > > > It looks cadence_gem is not a pluggable device. Any ideas? > > > > I have mostly tried TAP devices with VirtIO-Net. I believe this could be > > some bug in Cadence GEM emulation of QEMU. > > I managed to get tap interface connected to the cadence_gem > controller. The QEMU command line is "qemu-system-riscv64 -nographic > -M sifive_u -kernel u-boot -nic tap,model=cadence_gem" > > A single "ping" works after I set related network environments in the > shell. But "tftp" test fails. It looks the driver just time out. > > => tftp 84000000 bmeng/uImage.riscv > ethernet at 100900fc: PHY present at 0 > ethernet at 100900fc: link up, 100Mbps full-duplex (lpa: 0xcde1) > Using ethernet at 100900fc device > TFTP from server 10.10.0.100; our IP address is 10.10.0.108 > Filename 'bmeng/uImage.riscv'. > Load address: 0x84000000 > Loading: #T T #T T #T #T T #T #T T # > Retry count exceeded; starting again > > Can you please take a look? 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
end of thread, other threads:[~2019-08-07 15:37 UTC | newest] Thread overview: 26+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-12-17 11:51 [U-Boot] [PATCH 0/3] Ethernet support for QEMU sifive_u machine Anup Patel 2018-12-17 11:51 ` [U-Boot] [PATCH 1/3] riscv: Add asm/dma-mapping.h for DMA mappings Anup Patel 2018-12-18 9:45 ` Bin Meng 2018-12-19 8:09 ` Anup Patel 2018-12-20 5:26 ` Anup Patel 2018-12-17 11:51 ` [U-Boot] [PATCH 2/3] net: macb: Fix clk API usage for RISC-V systems Anup Patel 2018-12-18 9:45 ` Bin Meng 2018-12-19 8:15 ` Anup Patel 2018-12-17 11:51 ` [U-Boot] [PATCH 3/3] riscv: qemu: Imply MACB ethernet for emulation Anup Patel 2018-12-18 9:45 ` Bin Meng 2018-12-18 9:51 ` [U-Boot] [PATCH 0/3] Ethernet support for QEMU sifive_u machine Bin Meng 2018-12-18 10:33 ` Anup Patel 2018-12-18 10:36 ` Bin Meng 2018-12-19 4:40 ` Anup Patel 2018-12-19 5:32 ` Bin Meng 2018-12-19 6:32 ` Anup Patel 2018-12-19 9:05 ` Bin Meng 2018-12-24 1:29 ` Bin Meng 2018-12-24 5:41 ` Anup Patel 2018-12-24 6:31 ` Bin Meng 2018-12-24 6:42 ` Anup Patel 2018-12-24 7:15 ` Bin Meng 2018-12-24 7:23 ` Anup Patel 2018-12-24 7:36 ` Bin Meng 2018-12-24 11:34 ` Anup Patel 2019-08-07 15:37 ` Bin Meng
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.