[U-Boot] [PATCH 00/12] riscv: Add QEMU virt board support

[U-Boot] [PATCH 00/12] riscv: Add QEMU virt board support

[Bin Meng]

This series adds QEMU RISC-V 'virt' board target support, with the
hope of helping people easily test U-Boot on RISC-V.

Some existing RISC-V codes have been changed to make it easily to
support new targets. Some spotted coding style issues are fixed.

This series is available at u-boot-x86/riscv-working for testing.


Bin Meng (12):
  riscv: kconfig: Normalize architecture name spelling
  riscv: Remove setup.h
  riscv: bootm: Correct the 1st kernel argument to hart id
  riscv: Remove mach type
  riscv: Move the linker script to the CPU root directory
  riscv: Fix coding style issues in the linker script
  riscv: Explicitly pass -march and -mabi to the compiler
  riscv: Add a helper routine to print CPU information
  riscv: Make start.S available for all targets
  riscv: ae350: Clean up mixed tabs and spaces in the dts
  riscv: kconfig: Select DM and OF_CONTROL
  riscv: Add QEMU virt board support

 arch/Kconfig                            |   5 +-
 arch/riscv/Kconfig                      |  10 +-
 arch/riscv/Makefile                     |   3 +-
 arch/riscv/config.mk                    |   9 +-
 arch/riscv/cpu/Makefile                 |   7 ++
 arch/riscv/cpu/ax25/Makefile            |   2 -
 arch/riscv/cpu/cpu.c                    |  49 ++++++++
 arch/riscv/cpu/qemu/Makefile            |   6 +
 arch/riscv/cpu/qemu/cpu.c               |  29 +++++
 arch/riscv/cpu/qemu/dram.c              |  17 +++
 arch/riscv/cpu/{ax25 => }/start.S       |   0
 arch/riscv/cpu/{ax25 => }/u-boot.lds    |  60 +++++-----
 arch/riscv/dts/ae350.dts                | 177 +++++++++++++++--------------
 arch/riscv/include/asm/bootm.h          |  13 ---
 arch/riscv/include/asm/csr.h            | 124 ++++++++++++++++++++
 arch/riscv/include/asm/mach-types.h     |  29 -----
 arch/riscv/include/asm/setup.h          | 194 --------------------------------
 arch/riscv/include/asm/u-boot.h         |   1 -
 arch/riscv/lib/bootm.c                  |  19 +---
 board/AndesTech/ax25-ae350/ax25-ae350.c |   2 -
 board/emulation/qemu-riscv/Kconfig      |  21 ++++
 board/emulation/qemu-riscv/MAINTAINERS  |   7 ++
 board/emulation/qemu-riscv/Makefile     |   5 +
 board/emulation/qemu-riscv/qemu-riscv.c |  23 ++++
 cmd/bdinfo.c                            |   1 -
 configs/ax25-ae350_defconfig            |   2 -
 configs/qemu-riscv32_defconfig          |  10 ++
 configs/qemu-riscv64_defconfig          |  11 ++
 doc/README.qemu-riscv                   |  46 ++++++++
 include/configs/qemu-riscv.h            |  21 ++++
 30 files changed, 520 insertions(+), 383 deletions(-)
 create mode 100644 arch/riscv/cpu/Makefile
 create mode 100644 arch/riscv/cpu/cpu.c
 create mode 100644 arch/riscv/cpu/qemu/Makefile
 create mode 100644 arch/riscv/cpu/qemu/cpu.c
 create mode 100644 arch/riscv/cpu/qemu/dram.c
 rename arch/riscv/cpu/{ax25 => }/start.S (100%)
 rename arch/riscv/cpu/{ax25 => }/u-boot.lds (54%)
 delete mode 100644 arch/riscv/include/asm/bootm.h
 create mode 100644 arch/riscv/include/asm/csr.h
 delete mode 100644 arch/riscv/include/asm/mach-types.h
 delete mode 100644 arch/riscv/include/asm/setup.h
 create mode 100644 board/emulation/qemu-riscv/Kconfig
 create mode 100644 board/emulation/qemu-riscv/MAINTAINERS
 create mode 100644 board/emulation/qemu-riscv/Makefile
 create mode 100644 board/emulation/qemu-riscv/qemu-riscv.c
 create mode 100644 configs/qemu-riscv32_defconfig
 create mode 100644 configs/qemu-riscv64_defconfig
 create mode 100644 doc/README.qemu-riscv
 create mode 100644 include/configs/qemu-riscv.h

-- 
2.7.4

[U-Boot] [PATCH 01/12] riscv: kconfig: Normalize architecture name spelling

[Bin Meng]

It's RISC-V that is the official name, not RISCV.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
---

 arch/Kconfig       | 2 +-
 arch/riscv/Kconfig | 6 +++---
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/Kconfig b/arch/Kconfig
index bf1b4a9..42c23b5 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -60,7 +60,7 @@ config PPC
 	select SYS_BOOT_GET_KBD
 
 config RISCV
-	bool "riscv architecture"
+	bool "RISC-V architecture"
 	select SUPPORT_OF_CONTROL
 
 config SANDBOX
diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 20a43d8..49f87de 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -1,4 +1,4 @@
-menu "RISCV architecture"
+menu "RISC-V architecture"
 	depends on RISCV
 
 config SYS_ARCH
@@ -20,13 +20,13 @@ choice
 	default CPU_RISCV_32
 
 config CPU_RISCV_32
-	bool "RISCV 32 bit"
+	bool "RISC-V 32-bit"
 	select 32BIT
 	help
 	  Choose this option to build an U-Boot for RISCV32 architecture.
 
 config CPU_RISCV_64
-	bool "RISCV 64 bit"
+	bool "RISC-V 64-bit"
 	select 64BIT
 	help
 	  Choose this option to build an U-Boot for RISCV64 architecture.
-- 
2.7.4

[U-Boot] [PATCH 02/12] riscv: Remove setup.h

[Bin Meng]

This was copied from ARM, and does not apply to RISC-V. While we
are here, bootm.h is eventually removed as its content is only
the inclusion of setup.h.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
---

 arch/riscv/include/asm/bootm.h |  13 ---
 arch/riscv/include/asm/setup.h | 194 -----------------------------------------
 arch/riscv/lib/bootm.c         |   1 -
 3 files changed, 208 deletions(-)
 delete mode 100644 arch/riscv/include/asm/bootm.h
 delete mode 100644 arch/riscv/include/asm/setup.h

diff --git a/arch/riscv/include/asm/bootm.h b/arch/riscv/include/asm/bootm.h
deleted file mode 100644
index 6786345..0000000
--- a/arch/riscv/include/asm/bootm.h
+++ /dev/null
@@ -1,13 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0+ */
-/*
- * Copyright (c) 2013, Google Inc.
- *
- * Copyright (C) 2011
- * Corscience GmbH & Co. KG - Simon Schwarz <schwarz@corscience.de>
- */
-#ifndef NDS32_BOOTM_H
-#define NDS32_BOOTM_H
-
-#include <asm/setup.h>
-
-#endif
diff --git a/arch/riscv/include/asm/setup.h b/arch/riscv/include/asm/setup.h
deleted file mode 100644
index ff8de16..0000000
--- a/arch/riscv/include/asm/setup.h
+++ /dev/null
@@ -1,194 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 */
-/*
- *  linux/arch/nds32/include/asm/setup.h
- *
- * Copyright (C) 1997-1999 Russell King
- * Copyright (C) 2008 Andes Technology Corporation
- * Copyright (C) 2013 Ken Kuo (ken_kuo at andestech.com)
- * Copyright (C) 2017 Rick Chen (rick at andestech.com)
- *
- *  Structure passed to kernel to tell it about the
- *  hardware it's running on.  See Documentation/arm/Setup
- *  for more info.
- */
-#ifndef __RISCV_SETUP_H
-#define __RISCV_SETUP_H
-
-#define COMMAND_LINE_SIZE 256
-
-/* The list ends with an ATAG_NONE node. */
-#define ATAG_NONE	0x00000000
-
-struct tag_header {
-	u32 size;
-	u32 tag;
-};
-
-/* The list must start with an ATAG_CORE node */
-#define ATAG_CORE	0x54410001
-
-struct tag_core {
-	u32 flags;		/* bit 0 = read-only */
-	u32 pagesize;
-	u32 rootdev;
-};
-
-/* it is allowed to have multiple ATAG_MEM nodes */
-#define ATAG_MEM	0x54410002
-
-struct tag_mem32 {
-	u32	size;
-	u32	start;	/* physical start address */
-};
-
-/* VGA text type displays */
-#define ATAG_VIDEOTEXT	0x54410003
-
-struct tag_videotext {
-	u8		x;
-	u8		y;
-	u16		video_page;
-	u8		video_mode;
-	u8		video_cols;
-	u16		video_ega_bx;
-	u8		video_lines;
-	u8		video_isvga;
-	u16		video_points;
-};
-
-/* describes how the ramdisk will be used in kernel */
-#define ATAG_RAMDISK	0x54410004
-
-struct tag_ramdisk {
-	u32 flags;	/* bit 0 = load, bit 1 = prompt */
-	u32 size;	/* decompressed ramdisk size in _kilo_ bytes */
-	u32 start;	/* starting block of floppy-based RAM disk image */
-};
-
-/*
- * this one accidentally used virtual addresses - as such,
- * it's deprecated.
- * describes where the compressed ramdisk image lives (virtual address)
- */
-#define ATAG_INITRD		0x54410005
-
-/* describes where the compressed ramdisk image lives (physical address) */
-#define ATAG_INITRD2	0x54420005
-
-struct tag_initrd {
-	u32 start;	/* physical start address */
-	u32 size;	/* size of compressed ramdisk image in bytes */
-};
-
-/* board serial number. "64 bits should be enough for everybody" */
-#define ATAG_SERIAL		0x54410006
-
-struct tag_serialnr {
-	u32 low;
-	u32 high;
-};
-
-/* board revision */
-#define ATAG_REVISION	0x54410007
-
-struct tag_revision {
-	u32 rev;
-};
-
-/* initial values for vesafb-type framebuffers. see struct screen_info
- * in include/linux/tty.h
- */
-#define ATAG_VIDEOLFB	0x54410008
-
-struct tag_videolfb {
-	u16		lfb_width;
-	u16		lfb_height;
-	u16		lfb_depth;
-	u16		lfb_linelength;
-	u32		lfb_base;
-	u32		lfb_size;
-	u8		red_size;
-	u8		red_pos;
-	u8		green_size;
-	u8		green_pos;
-	u8		blue_size;
-	u8		blue_pos;
-	u8		rsvd_size;
-	u8		rsvd_pos;
-};
-
-/* command line: \0 terminated string */
-#define ATAG_CMDLINE	0x54410009
-
-struct tag_cmdline {
-	char	cmdline[COMMAND_LINE_SIZE];
-};
-
-struct tag {
-	struct tag_header hdr;
-	union {
-		struct tag_core		core;
-		struct tag_mem32	mem;
-		struct tag_videotext	videotext;
-		struct tag_ramdisk	ramdisk;
-		struct tag_initrd	initrd;
-		struct tag_serialnr	serialnr;
-		struct tag_revision	revision;
-		struct tag_videolfb	videolfb;
-		struct tag_cmdline	cmdline;
-	} u;
-};
-
-struct tagtable {
-	u32 tag;
-	int (*parse)(const struct tag *);
-};
-
-#define tag_member_present(_tag, member)				\
-	typeof(_tag) (tag) = (_tag); \
-	((unsigned long)(&((struct tag *)0L)->member + 1)	\
-		<= (tag)->hdr.size * 4)
-
-#define tag_next(_t)	\
-	typeof(_t) (t) = (_t); \
-	((struct tag *)((u32 *)(t) + (t)->hdr.size))
-#define tag_size(type)	((sizeof(struct tag_header) + sizeof(struct type)) >> 2)
-
-#define for_each_tag(_t, base) \
-	typeof(_t) (t) = (_t); \
-	for (t = base; t->hdr.size; t = tag_next(t))
-
-#ifdef __KERNEL__
-
-#define __tag __used __attribute__((__section__(".taglist")))
-#define __tagtable(tag, fn) \
-static struct tagtable __tagtable_##fn __tag = { tag, fn }
-
-/*
- * Memory map description
- */
-#define NR_BANKS 8
-
-struct meminfo {
-	int nr_banks;
-	struct {
-		unsigned long start;
-		unsigned long size;
-		int           node;
-	} bank[NR_BANKS];
-};
-
-/*
- * Early command line parameters.
- */
-struct early_params {
-	const char *arg;
-	void (*fn)(char **p);
-};
-
-#define __early_param(name, fn)					\
-static struct early_params __early_##fn __used	\
-__attribute__((__section__("__early_param"))) = { name, fn }
-
-#endif
-#endif
diff --git a/arch/riscv/lib/bootm.c b/arch/riscv/lib/bootm.c
index 2610a57..6662aff 100644
--- a/arch/riscv/lib/bootm.c
+++ b/arch/riscv/lib/bootm.c
@@ -11,7 +11,6 @@
 #include <image.h>
 #include <u-boot/zlib.h>
 #include <asm/byteorder.h>
-#include <asm/bootm.h>
 
 DECLARE_GLOBAL_DATA_PTR;
 
-- 
2.7.4

[U-Boot] [PATCH 03/12] riscv: bootm: Correct the 1st kernel argument to hart id

[Bin Meng]

The first argument of Linux kernel is the risc-v core hart id,
from which the kernel is booted from. It is not the mach_id,
which seems to be copied from arm.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
---

 arch/riscv/lib/bootm.c | 18 +++++-------------
 1 file changed, 5 insertions(+), 13 deletions(-)

diff --git a/arch/riscv/lib/bootm.c b/arch/riscv/lib/bootm.c
index 6662aff..754bbff 100644
--- a/arch/riscv/lib/bootm.c
+++ b/arch/riscv/lib/bootm.c
@@ -25,10 +25,7 @@ int arch_fixup_fdt(void *blob)
 
 int do_bootm_linux(int flag, int argc, char *argv[], bootm_headers_t *images)
 {
-	bd_t	*bd = gd->bd;
-	char	*s;
-	int	machid = bd->bi_arch_number;
-	void	(*theKernel)(int arch, uint params);
+	void	(*kernel)(int hart, uint dtb);
 
 	/*
 	 * allow the PREP bootm subcommand, it is required for bootm to work
@@ -39,18 +36,12 @@ int do_bootm_linux(int flag, int argc, char *argv[], bootm_headers_t *images)
 	if ((flag != 0) && (flag != BOOTM_STATE_OS_GO))
 		return 1;
 
-	theKernel = (void (*)(int, uint))images->ep;
-
-	s = env_get("machid");
-	if (s) {
-		machid = simple_strtoul(s, NULL, 16);
-		printf("Using machid 0x%x from environment\n", machid);
-	}
+	kernel = (void (*)(int, uint))images->ep;
 
 	bootstage_mark(BOOTSTAGE_ID_RUN_OS);
 
 	debug("## Transferring control to Linux (at address %08lx) ...\n",
-	       (ulong)theKernel);
+	       (ulong)kernel);
 
 	if (IMAGE_ENABLE_OF_LIBFDT && images->ft_len) {
 #ifdef CONFIG_OF_LIBFDT
@@ -66,8 +57,9 @@ int do_bootm_linux(int flag, int argc, char *argv[], bootm_headers_t *images)
 	printf("\nStarting kernel ...\n\n");
 
 	cleanup_before_linux();
+	/* TODO: hardcode the hart id to zero for now */
 	if (IMAGE_ENABLE_OF_LIBFDT && images->ft_len)
-		theKernel(machid, (unsigned long)images->ft_addr);
+		kernel(0, (unsigned long)images->ft_addr);
 
 	/* does not return */
 
-- 
2.7.4

[U-Boot] [PATCH 03/12] riscv: bootm: Correct the 1st kernel argument to hart id

[Rick Chen]

 > From: Bin Meng [mailto:bmeng.cn at gmail.com]
 > Sent: Thursday, August 30, 2018 3:54 PM
 > To: Rick Jian-Zhi Chen(陳建志); U-Boot Mailing List
 > Subject: [PATCH 03/12] riscv: bootm: Correct the 1st kernel
argument to hart id
 >
 > The first argument of Linux kernel is the risc-v core hart id, from
which the kernel
 > is booted from. It is not the mach_id, which seems to be copied from arm.
 >
 > Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
 > ---
 >
 >  arch/riscv/lib/bootm.c | 18 +++++-------------
 >  1 file changed, 5 insertions(+), 13 deletions(-)
 >
 > diff --git a/arch/riscv/lib/bootm.c b/arch/riscv/lib/bootm.c index
6662aff..754bbff
 > 100644
 > --- a/arch/riscv/lib/bootm.c
 > +++ b/arch/riscv/lib/bootm.c
 > @@ -25,10 +25,7 @@ int arch_fixup_fdt(void *blob)
 >
 >  int do_bootm_linux(int flag, int argc, char *argv[],
bootm_headers_t *images)
 > {
 > -     bd_t    *bd = gd->bd;
 > -     char    *s;
 > -     int     machid = bd->bi_arch_number;
 > -     void    (*theKernel)(int arch, uint params);
 > +     void    (*kernel)(int hart, uint dtb);
 >
 >       /*
 >        * allow the PREP bootm subcommand, it is required for bootm to work
 > @@ -39,18 +36,12 @@ int do_bootm_linux(int flag, int argc, char *argv[],
 > bootm_headers_t *images)
 >       if ((flag != 0) && (flag != BOOTM_STATE_OS_GO))
 >               return 1;
 >
 > -     theKernel = (void (*)(int, uint))images->ep;
 > -
 > -     s = env_get("machid");

Hi Bin

Actually I have check this earlier.
It was changed to hartid and pass to kernel when execute
enter_supervisor_mode( ) by bbl
    enter_supervisor_mode(entry, hartid, dtb_output());
But I have no time to solve it.
I was trapped and busy about linux drivers porting currently.
And planed to fix it when I switch back to u-boot jobs later.

Thank you for fix it.

Rick

 > -     if (s) {
 > -             machid = simple_strtoul(s, NULL, 16);
 > -             printf("Using machid 0x%x from environment\n", machid);
 > -     }
 > +     kernel = (void (*)(int, uint))images->ep;
 >
 >       bootstage_mark(BOOTSTAGE_ID_RUN_OS);
 >
 >       debug("## Transferring control to Linux (at address %08lx) ...\n",
 > -            (ulong)theKernel);
 > +            (ulong)kernel);
 >
 >       if (IMAGE_ENABLE_OF_LIBFDT && images->ft_len) {  #ifdef
 > CONFIG_OF_LIBFDT @@ -66,8 +57,9 @@ int do_bootm_linux(int flag, int argc,
 > char *argv[], bootm_headers_t *images)
 >       printf("\nStarting kernel ...\n\n");
 >
 >       cleanup_before_linux();
 > +     /* TODO: hardcode the hart id to zero for now */
 >       if (IMAGE_ENABLE_OF_LIBFDT && images->ft_len)
 > -             theKernel(machid, (unsigned long)images->ft_addr);
 > +             kernel(0, (unsigned long)images->ft_addr);
 >
 >       /* does not return */
 >
 > --
 > 2.7.4

[U-Boot] [PATCH 03/12] riscv: bootm: Correct the 1st kernel argument to hart id

[Auer, Lukas]

On Thu, 2018-08-30 at 00:54 -0700, Bin Meng wrote:
> The first argument of Linux kernel is the risc-v core hart id,
> from which the kernel is booted from. It is not the mach_id,
> which seems to be copied from arm.
> 
> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
> ---
> 
>  arch/riscv/lib/bootm.c | 18 +++++-------------
>  1 file changed, 5 insertions(+), 13 deletions(-)
> 
> diff --git a/arch/riscv/lib/bootm.c b/arch/riscv/lib/bootm.c
> index 6662aff..754bbff 100644
> --- a/arch/riscv/lib/bootm.c
> +++ b/arch/riscv/lib/bootm.c
> @@ -25,10 +25,7 @@ int arch_fixup_fdt(void *blob)
>  
>  int do_bootm_linux(int flag, int argc, char *argv[], bootm_headers_t
> *images)
>  {
> -	bd_t	*bd = gd->bd;
> -	char	*s;
> -	int	machid = bd->bi_arch_number;
> -	void	(*theKernel)(int arch, uint params);
> +	void	(*kernel)(int hart, uint dtb);

This probably does not cause any issues in u-boot, but the second
parameter should be 32 bit or 64 bit depending on the architecture.
Since you are already changing the kernel arguments it would make sense
to also change dtb from uint to ulong or void *.

>  
>  	/*
>  	 * allow the PREP bootm subcommand, it is required for bootm to
> work
> @@ -39,18 +36,12 @@ int do_bootm_linux(int flag, int argc, char
> *argv[], bootm_headers_t *images)
>  	if ((flag != 0) && (flag != BOOTM_STATE_OS_GO))
>  		return 1;
>  
> -	theKernel = (void (*)(int, uint))images->ep;
> -
> -	s = env_get("machid");
> -	if (s) {
> -		machid = simple_strtoul(s, NULL, 16);
> -		printf("Using machid 0x%x from environment\n", machid);
> -	}
> +	kernel = (void (*)(int, uint))images->ep;
>  
>  	bootstage_mark(BOOTSTAGE_ID_RUN_OS);
>  
>  	debug("## Transferring control to Linux (at address %08lx)
> ...\n",
> -	       (ulong)theKernel);
> +	       (ulong)kernel);
>  
>  	if (IMAGE_ENABLE_OF_LIBFDT && images->ft_len) {
>  #ifdef CONFIG_OF_LIBFDT
> @@ -66,8 +57,9 @@ int do_bootm_linux(int flag, int argc, char
> *argv[], bootm_headers_t *images)
>  	printf("\nStarting kernel ...\n\n");
>  
>  	cleanup_before_linux();
> +	/* TODO: hardcode the hart id to zero for now */
>  	if (IMAGE_ENABLE_OF_LIBFDT && images->ft_len)
> -		theKernel(machid, (unsigned long)images->ft_addr);
> +		kernel(0, (unsigned long)images->ft_addr);
>  

You can use the mhartid CSR to get the hart id. This will limit u-boot
to running in machine mode however. Alternatively you can also use the
hart id, which is passed in a0 by the bootloader.

Thanks,
Lukas

>  	/* does not return */
>  

[U-Boot] [PATCH 03/12] riscv: bootm: Correct the 1st kernel argument to hart id

[Bin Meng]

Hi Lukas,

On Tue, Sep 4, 2018 at 5:41 AM Auer, Lukas
<lukas.auer@aisec.fraunhofer.de> wrote:
>
> On Thu, 2018-08-30 at 00:54 -0700, Bin Meng wrote:
> > The first argument of Linux kernel is the risc-v core hart id,
> > from which the kernel is booted from. It is not the mach_id,
> > which seems to be copied from arm.
> >
> > Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
> > ---
> >
> >  arch/riscv/lib/bootm.c | 18 +++++-------------
> >  1 file changed, 5 insertions(+), 13 deletions(-)
> >
> > diff --git a/arch/riscv/lib/bootm.c b/arch/riscv/lib/bootm.c
> > index 6662aff..754bbff 100644
> > --- a/arch/riscv/lib/bootm.c
> > +++ b/arch/riscv/lib/bootm.c
> > @@ -25,10 +25,7 @@ int arch_fixup_fdt(void *blob)
> >
> >  int do_bootm_linux(int flag, int argc, char *argv[], bootm_headers_t
> > *images)
> >  {
> > -     bd_t    *bd = gd->bd;
> > -     char    *s;
> > -     int     machid = bd->bi_arch_number;
> > -     void    (*theKernel)(int arch, uint params);
> > +     void    (*kernel)(int hart, uint dtb);
>
> This probably does not cause any issues in u-boot, but the second
> parameter should be 32 bit or 64 bit depending on the architecture.
> Since you are already changing the kernel arguments it would make sense
> to also change dtb from uint to ulong or void *.
>

Yes. Will address this in v2.

> >
> >       /*
> >        * allow the PREP bootm subcommand, it is required for bootm to
> > work
> > @@ -39,18 +36,12 @@ int do_bootm_linux(int flag, int argc, char
> > *argv[], bootm_headers_t *images)
> >       if ((flag != 0) && (flag != BOOTM_STATE_OS_GO))
> >               return 1;
> >
> > -     theKernel = (void (*)(int, uint))images->ep;
> > -
> > -     s = env_get("machid");
> > -     if (s) {
> > -             machid = simple_strtoul(s, NULL, 16);
> > -             printf("Using machid 0x%x from environment\n", machid);
> > -     }
> > +     kernel = (void (*)(int, uint))images->ep;
> >
> >       bootstage_mark(BOOTSTAGE_ID_RUN_OS);
> >
> >       debug("## Transferring control to Linux (at address %08lx)
> > ...\n",
> > -            (ulong)theKernel);
> > +            (ulong)kernel);
> >
> >       if (IMAGE_ENABLE_OF_LIBFDT && images->ft_len) {
> >  #ifdef CONFIG_OF_LIBFDT
> > @@ -66,8 +57,9 @@ int do_bootm_linux(int flag, int argc, char
> > *argv[], bootm_headers_t *images)
> >       printf("\nStarting kernel ...\n\n");
> >
> >       cleanup_before_linux();
> > +     /* TODO: hardcode the hart id to zero for now */
> >       if (IMAGE_ENABLE_OF_LIBFDT && images->ft_len)
> > -             theKernel(machid, (unsigned long)images->ft_addr);
> > +             kernel(0, (unsigned long)images->ft_addr);
> >
>
> You can use the mhartid CSR to get the hart id. This will limit u-boot
> to running in machine mode however. Alternatively you can also use the
> hart id, which is passed in a0 by the bootloader.
>

If the goal is to use U-Boot to directly boot Linux, I think we need
more changes. I believe we should allow only one hart to execute this
function. For other harts, they should be waked up and jump to kernel
directly.

Regards,
Bin

[U-Boot] [PATCH 03/12] riscv: bootm: Correct the 1st kernel argument to hart id

[Auer, Lukas]

Hi Bin,

On Thu, 2018-09-06 at 10:57 +0800, Bin Meng wrote:
> Hi Lukas,
> 
> On Tue, Sep 4, 2018 at 5:41 AM Auer, Lukas
> <lukas.auer@aisec.fraunhofer.de> wrote:
> > 
> > On Thu, 2018-08-30 at 00:54 -0700, Bin Meng wrote:
> > > The first argument of Linux kernel is the risc-v core hart id,
> > > from which the kernel is booted from. It is not the mach_id,
> > > which seems to be copied from arm.
> > > 
> > > Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
> > > ---
> > > 
> > >  arch/riscv/lib/bootm.c | 18 +++++-------------
> > >  1 file changed, 5 insertions(+), 13 deletions(-)
> > > 
> > > diff --git a/arch/riscv/lib/bootm.c b/arch/riscv/lib/bootm.c
> > > index 6662aff..754bbff 100644
> > > --- a/arch/riscv/lib/bootm.c
> > > +++ b/arch/riscv/lib/bootm.c
> > > @@ -25,10 +25,7 @@ int arch_fixup_fdt(void *blob)
> > > 
> > >  int do_bootm_linux(int flag, int argc, char *argv[],
> > > bootm_headers_t
> > > *images)
> > >  {
> > > -     bd_t    *bd = gd->bd;
> > > -     char    *s;
> > > -     int     machid = bd->bi_arch_number;
> > > -     void    (*theKernel)(int arch, uint params);
> > > +     void    (*kernel)(int hart, uint dtb);
> > 
> > This probably does not cause any issues in u-boot, but the second
> > parameter should be 32 bit or 64 bit depending on the architecture.
> > Since you are already changing the kernel arguments it would make
> > sense
> > to also change dtb from uint to ulong or void *.
> > 
> 
> Yes. Will address this in v2.
> 
> > > 
> > >       /*
> > >        * allow the PREP bootm subcommand, it is required for
> > > bootm to
> > > work
> > > @@ -39,18 +36,12 @@ int do_bootm_linux(int flag, int argc, char
> > > *argv[], bootm_headers_t *images)
> > >       if ((flag != 0) && (flag != BOOTM_STATE_OS_GO))
> > >               return 1;
> > > 
> > > -     theKernel = (void (*)(int, uint))images->ep;
> > > -
> > > -     s = env_get("machid");
> > > -     if (s) {
> > > -             machid = simple_strtoul(s, NULL, 16);
> > > -             printf("Using machid 0x%x from environment\n",
> > > machid);
> > > -     }
> > > +     kernel = (void (*)(int, uint))images->ep;
> > > 
> > >       bootstage_mark(BOOTSTAGE_ID_RUN_OS);
> > > 
> > >       debug("## Transferring control to Linux (at address %08lx)
> > > ...\n",
> > > -            (ulong)theKernel);
> > > +            (ulong)kernel);
> > > 
> > >       if (IMAGE_ENABLE_OF_LIBFDT && images->ft_len) {
> > >  #ifdef CONFIG_OF_LIBFDT
> > > @@ -66,8 +57,9 @@ int do_bootm_linux(int flag, int argc, char
> > > *argv[], bootm_headers_t *images)
> > >       printf("\nStarting kernel ...\n\n");
> > > 
> > >       cleanup_before_linux();
> > > +     /* TODO: hardcode the hart id to zero for now */
> > >       if (IMAGE_ENABLE_OF_LIBFDT && images->ft_len)
> > > -             theKernel(machid, (unsigned long)images->ft_addr);
> > > +             kernel(0, (unsigned long)images->ft_addr);
> > > 
> > 
> > You can use the mhartid CSR to get the hart id. This will limit u-
> > boot
> > to running in machine mode however. Alternatively you can also use
> > the
> > hart id, which is passed in a0 by the bootloader.
> > 
> 
> If the goal is to use U-Boot to directly boot Linux, I think we need
> more changes. I believe we should allow only one hart to execute this
> function. For other harts, they should be waked up and jump to kernel
> directly.
> 

Yes, that's true. We should be able to pick which hart executes it
though. This is useful for chips like SiFive's U54, where hart 0 is a
smaller hart for monitoring tasks. Here it would make sense to run   
u-boot on one of the other harts.

Thanks,
Lukas

[U-Boot] [PATCH 04/12] riscv: Remove mach type

[Bin Meng]

Since the mach_id is not used by RISC-V, remove it.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
---

 arch/riscv/include/asm/mach-types.h     | 29 -----------------------------
 arch/riscv/include/asm/u-boot.h         |  1 -
 board/AndesTech/ax25-ae350/ax25-ae350.c |  2 --
 cmd/bdinfo.c                            |  1 -
 4 files changed, 33 deletions(-)
 delete mode 100644 arch/riscv/include/asm/mach-types.h

diff --git a/arch/riscv/include/asm/mach-types.h b/arch/riscv/include/asm/mach-types.h
deleted file mode 100644
index f219ced..0000000
--- a/arch/riscv/include/asm/mach-types.h
+++ /dev/null
@@ -1,29 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0+ */
-/*
- * Copyright (C) 2017 Andes Technology Corporation
- * Rick Chen, Andes Technology Corporation <rick@andestech.com>
- */
-
-#ifndef __ASM_RISCV_MACH_TYPE_H
-#define __ASM_RISCV_MACH_TYPE_H
-
-#ifndef __ASSEMBLY__
-/* The type of machine we're running on */
-extern unsigned int __machine_arch_type;
-#endif
-
-#define MACH_TYPE_AE350		1
-
-#ifdef CONFIG_ARCH_AE350
-# ifdef machine_arch_type
-#  undef machine_arch_type
-#  define machine_arch_type __machine_arch_type
-# else
-#  define machine_arch_type MACH_TYPE_AE350
-# endif
-# define machine_is_ae350() (machine_arch_type == MACH_TYPE_AE350)
-#else
-# define machine_is_ae350() (1)
-#endif
-
-#endif /* __ASM_RISCV_MACH_TYPE_H */
diff --git a/arch/riscv/include/asm/u-boot.h b/arch/riscv/include/asm/u-boot.h
index 9e5b32d..3186835 100644
--- a/arch/riscv/include/asm/u-boot.h
+++ b/arch/riscv/include/asm/u-boot.h
@@ -23,7 +23,6 @@
 #include <environment.h>
 
 typedef struct bd_info {
-	unsigned long	bi_arch_number;	/* unique id for this board */
 	unsigned long	bi_boot_params;	/* where this board expects params */
 	unsigned long	bi_memstart;	/* start of DRAM memory */
 	unsigned long	bi_memsize;	/* size	 of DRAM memory in bytes */
diff --git a/board/AndesTech/ax25-ae350/ax25-ae350.c b/board/AndesTech/ax25-ae350/ax25-ae350.c
index fd5aaa1..5f4ca0f 100644
--- a/board/AndesTech/ax25-ae350/ax25-ae350.c
+++ b/board/AndesTech/ax25-ae350/ax25-ae350.c
@@ -4,7 +4,6 @@
  * Rick Chen, Andes Technology Corporation <rick@andestech.com>
  */
 
-#include <asm/mach-types.h>
 #include <common.h>
 #if defined(CONFIG_FTMAC100) && !defined(CONFIG_DM_ETH)
 #include <netdev.h>
@@ -21,7 +20,6 @@ DECLARE_GLOBAL_DATA_PTR;
 
 int board_init(void)
 {
-	gd->bd->bi_arch_number = MACH_TYPE_AE350;
 	gd->bd->bi_boot_params = PHYS_SDRAM_0 + 0x400;
 
 	return 0;
diff --git a/cmd/bdinfo.c b/cmd/bdinfo.c
index 397dd15..bc440e4 100644
--- a/cmd/bdinfo.c
+++ b/cmd/bdinfo.c
@@ -424,7 +424,6 @@ int do_bdinfo(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
 {
 	bd_t *bd = gd->bd;
 
-	print_num("arch_number", bd->bi_arch_number);
 	print_bi_boot_params(bd);
 	print_bi_dram(bd);
 	print_eth_ip_addr();
-- 
2.7.4

[U-Boot] [PATCH 05/12] riscv: Move the linker script to the CPU root directory

[Bin Meng]

The linker script can be shared by all RISC-V targets. Move it to
a common place.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
---

 arch/riscv/cpu/{ax25 => }/u-boot.lds | 0
 1 file changed, 0 insertions(+), 0 deletions(-)
 rename arch/riscv/cpu/{ax25 => }/u-boot.lds (100%)

diff --git a/arch/riscv/cpu/ax25/u-boot.lds b/arch/riscv/cpu/u-boot.lds
similarity index 100%
rename from arch/riscv/cpu/ax25/u-boot.lds
rename to arch/riscv/cpu/u-boot.lds
-- 
2.7.4

[U-Boot] [PATCH 06/12] riscv: Fix coding style issues in the linker script

[Bin Meng]

There are several coding style issues in the linker script. Fix them.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
---

 arch/riscv/cpu/u-boot.lds | 58 +++++++++++++++++++++++------------------------
 1 file changed, 28 insertions(+), 30 deletions(-)

diff --git a/arch/riscv/cpu/u-boot.lds b/arch/riscv/cpu/u-boot.lds
index c50b964..f414473 100644
--- a/arch/riscv/cpu/u-boot.lds
+++ b/arch/riscv/cpu/u-boot.lds
@@ -3,28 +3,27 @@
  * Copyright (C) 2017 Andes Technology Corporation
  * Rick Chen, Andes Technology Corporation <rick@andestech.com>
  */
+
 OUTPUT_ARCH("riscv")
 ENTRY(_start)
 
 SECTIONS
 {
 	. = ALIGN(4);
-	.text :
-	{
+	.text : {
 		arch/riscv/cpu/ax25/start.o	(.text)
 	}
 
 	/* This needs to come before *(.text*) */
 	.efi_runtime : {
-                __efi_runtime_start = .;
+		__efi_runtime_start = .;
 		*(.text.efi_runtime*)
 		*(.rodata.efi_runtime*)
 		*(.data.efi_runtime*)
-                __efi_runtime_stop = .;
+		__efi_runtime_stop = .;
 	}
 
-	.text_rest :
-	{
+	.text_rest : {
 		*(.text*)
 	}
 
@@ -39,10 +38,10 @@ SECTIONS
 	. = ALIGN(4);
 
 	.got : {
-	   __got_start = .;
-	   *(.got.plt) *(.got)
-	   __got_end = .;
-    }
+		__got_start = .;
+		*(.got.plt) *(.got)
+		__got_end = .;
+	}
 
 	. = ALIGN(4);
 
@@ -50,41 +49,40 @@ SECTIONS
 		KEEP(*(SORT(.u_boot_list*)));
 	}
 
-    . = ALIGN(4);
+	. = ALIGN(4);
 
 	.efi_runtime_rel : {
-                __efi_runtime_rel_start = .;
+		__efi_runtime_rel_start = .;
 		*(.rel*.efi_runtime)
 		*(.rel*.efi_runtime.*)
-                __efi_runtime_rel_stop = .;
+		__efi_runtime_rel_stop = .;
 	}
 
-    . = ALIGN(4);
+	. = ALIGN(4);
 
-    /DISCARD/ : { *(.rela.plt*) }
-    .rela.dyn : {
-        __rel_dyn_start = .;
-        *(.rela*)
-        __rel_dyn_end = .;
-    }
+	/DISCARD/ : { *(.rela.plt*) }
+	.rela.dyn : {
+		__rel_dyn_start = .;
+		*(.rela*)
+		__rel_dyn_end = .;
+	}
 
-    . = ALIGN(4);
+	. = ALIGN(4);
 
-    .dynsym : {
-        __dyn_sym_start = .;
-        *(.dynsym)
-        __dyn_sym_end = .;
-    }
+	.dynsym : {
+		__dyn_sym_start = .;
+		*(.dynsym)
+		__dyn_sym_end = .;
+	}
 
-    . = ALIGN(4);
+	. = ALIGN(4);
 
 	_end = .;
 
 	.bss : {
-        __bss_start = .;
-        *(.bss*)
+		__bss_start = .;
+		*(.bss*)
 		. = ALIGN(4);
 		__bss_end = .;
 	}
-
 }
-- 
2.7.4

[U-Boot] [PATCH 07/12] riscv: Explicitly pass -march and -mabi to the compiler

[Bin Meng]

At present the compiler flag against which architecture and abi
variant the riscv image is built for is not explicitly indicated
which means the default compiler configuration is used. But this
does not work if we want to build a different target (eg: 32-bit
riscv images using a toolchain configured for 64-bit riscv).

Fix this by explicitly passing -march and -mabi to the compiler.
Since generically we don't use floating point in U-Boot, specify
the RV[32|64]IMA ISA and software floating ABI.

This also fix some alignment coding style issues.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
---

 arch/riscv/config.mk | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/arch/riscv/config.mk b/arch/riscv/config.mk
index 219e666..1484887 100644
--- a/arch/riscv/config.mk
+++ b/arch/riscv/config.mk
@@ -18,12 +18,16 @@ endif
 64bit-emul		:= elf64lriscv
 
 ifdef CONFIG_32BIT
+PLATFORM_CPPFLAGS	+= -march=rv32ima -mabi=ilp32
 PLATFORM_LDFLAGS	+= -m $(32bit-emul)
+CFLAGS_EFI		+= -march=rv32ima -mabi=ilp32
 EFI_LDS			:= elf_riscv32_efi.lds
 endif
 
 ifdef CONFIG_64BIT
+PLATFORM_CPPFLAGS	+= -march=rv64ima -mabi=lp64
 PLATFORM_LDFLAGS	+= -m $(64bit-emul)
+CFLAGS_EFI		+= -march=rv64ima -mabi=lp64
 EFI_LDS			:= elf_riscv64_efi.lds
 endif
 
@@ -31,8 +35,9 @@ CONFIG_STANDALONE_LOAD_ADDR = 0x00000000 \
 			      -T $(srctree)/examples/standalone/riscv.lds
 
 PLATFORM_CPPFLAGS	+= -ffixed-gp -fpic
-PLATFORM_RELFLAGS += -fno-strict-aliasing -fno-common -gdwarf-2 -ffunction-sections
-LDFLAGS_u-boot += --gc-sections -static -pie
+PLATFORM_RELFLAGS	+= -fno-strict-aliasing -fno-common -gdwarf-2 \
+			   -ffunction-sections
+LDFLAGS_u-boot		+= --gc-sections -static -pie
 
 EFI_CRT0		:= crt0_riscv_efi.o
 EFI_RELOC		:= reloc_riscv_efi.o
-- 
2.7.4

[U-Boot] [PATCH 08/12] riscv: Add a helper routine to print CPU information

[Bin Meng]

This adds a helper routine to print CPU information. Currently
it prints all the instruction set extensions that the processor
core supports.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
---

 arch/riscv/Makefile          |   1 +
 arch/riscv/cpu/Makefile      |   5 ++
 arch/riscv/cpu/cpu.c         |  49 +++++++++++++++++
 arch/riscv/include/asm/csr.h | 124 +++++++++++++++++++++++++++++++++++++++++++
 4 files changed, 179 insertions(+)
 create mode 100644 arch/riscv/cpu/Makefile
 create mode 100644 arch/riscv/cpu/cpu.c
 create mode 100644 arch/riscv/include/asm/csr.h

diff --git a/arch/riscv/Makefile b/arch/riscv/Makefile
index 084888a..af432e1 100644
--- a/arch/riscv/Makefile
+++ b/arch/riscv/Makefile
@@ -5,5 +5,6 @@
 
 head-y := arch/riscv/cpu/$(CPU)/start.o
 
+libs-y += arch/riscv/cpu/
 libs-y += arch/riscv/cpu/$(CPU)/
 libs-y += arch/riscv/lib/
diff --git a/arch/riscv/cpu/Makefile b/arch/riscv/cpu/Makefile
new file mode 100644
index 0000000..63de163
--- /dev/null
+++ b/arch/riscv/cpu/Makefile
@@ -0,0 +1,5 @@
+# SPDX-License-Identifier: GPL-2.0+
+#
+# Copyright (C) 2018, Bin Meng <bmeng.cn@gmail.com>
+
+obj-y += cpu.o
diff --git a/arch/riscv/cpu/cpu.c b/arch/riscv/cpu/cpu.c
new file mode 100644
index 0000000..ae57fb8
--- /dev/null
+++ b/arch/riscv/cpu/cpu.c
@@ -0,0 +1,49 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2018, Bin Meng <bmeng.cn@gmail.com>
+ */
+
+#include <common.h>
+#include <asm/csr.h>
+
+enum {
+	ISA_INVALID = 0,
+	ISA_32BIT,
+	ISA_64BIT,
+	ISA_128BIT
+};
+
+static const char * const isa_bits[] = {
+	[ISA_INVALID] = NULL,
+	[ISA_32BIT]   = "32",
+	[ISA_64BIT]   = "64",
+	[ISA_128BIT]  = "128"
+};
+
+static inline bool supports_extension(char ext)
+{
+	return csr_read(misa) & (1 << (ext - 'a'));
+}
+
+int print_cpuinfo(void)
+{
+	char name[32];
+	char *s = name;
+	int bit;
+
+	s += sprintf(name, "rv");
+	bit = csr_read(misa) >> (sizeof(long) * 8 - 2);
+	s += sprintf(s, isa_bits[bit]);
+
+	supports_extension('i') ? *s++ = 'i' : 'r';
+	supports_extension('m') ? *s++ = 'm' : 'i';
+	supports_extension('a') ? *s++ = 'a' : 's';
+	supports_extension('f') ? *s++ = 'f' : 'c';
+	supports_extension('d') ? *s++ = 'd' : '-';
+	supports_extension('c') ? *s++ = 'c' : 'v';
+	*s++ = '\0';
+
+	printf("CPU:   %s\n", name);
+
+	return 0;
+}
diff --git a/arch/riscv/include/asm/csr.h b/arch/riscv/include/asm/csr.h
new file mode 100644
index 0000000..50fccea
--- /dev/null
+++ b/arch/riscv/include/asm/csr.h
@@ -0,0 +1,124 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (C) 2015 Regents of the University of California
+ *
+ * Taken from Linux arch/riscv/include/asm/csr.h
+ */
+
+#ifndef _ASM_RISCV_CSR_H
+#define _ASM_RISCV_CSR_H
+
+/* Status register flags */
+#define SR_SIE		_AC(0x00000002, UL) /* Supervisor Interrupt Enable */
+#define SR_SPIE		_AC(0x00000020, UL) /* Previous Supervisor IE */
+#define SR_SPP		_AC(0x00000100, UL) /* Previously Supervisor */
+#define SR_SUM		_AC(0x00040000, UL) /* Supervisor access User Memory */
+
+#define SR_FS		_AC(0x00006000, UL) /* Floating-point Status */
+#define SR_FS_OFF	_AC(0x00000000, UL)
+#define SR_FS_INITIAL	_AC(0x00002000, UL)
+#define SR_FS_CLEAN	_AC(0x00004000, UL)
+#define SR_FS_DIRTY	_AC(0x00006000, UL)
+
+#define SR_XS		_AC(0x00018000, UL) /* Extension Status */
+#define SR_XS_OFF	_AC(0x00000000, UL)
+#define SR_XS_INITIAL	_AC(0x00008000, UL)
+#define SR_XS_CLEAN	_AC(0x00010000, UL)
+#define SR_XS_DIRTY	_AC(0x00018000, UL)
+
+#ifndef CONFIG_64BIT
+#define SR_SD		_AC(0x80000000, UL) /* FS/XS dirty */
+#else
+#define SR_SD		_AC(0x8000000000000000, UL) /* FS/XS dirty */
+#endif
+
+/* SATP flags */
+#if __riscv_xlen == 32
+#define SATP_PPN	_AC(0x003FFFFF, UL)
+#define SATP_MODE_32	_AC(0x80000000, UL)
+#define SATP_MODE	SATP_MODE_32
+#else
+#define SATP_PPN	_AC(0x00000FFFFFFFFFFF, UL)
+#define SATP_MODE_39	_AC(0x8000000000000000, UL)
+#define SATP_MODE	SATP_MODE_39
+#endif
+
+/* Interrupt Enable and Interrupt Pending flags */
+#define SIE_SSIE	_AC(0x00000002, UL) /* Software Interrupt Enable */
+#define SIE_STIE	_AC(0x00000020, UL) /* Timer Interrupt Enable */
+
+#define EXC_INST_MISALIGNED	0
+#define EXC_INST_ACCESS		1
+#define EXC_BREAKPOINT		3
+#define EXC_LOAD_ACCESS		5
+#define EXC_STORE_ACCESS	7
+#define EXC_SYSCALL		8
+#define EXC_INST_PAGE_FAULT	12
+#define EXC_LOAD_PAGE_FAULT	13
+#define EXC_STORE_PAGE_FAULT	15
+
+#ifndef __ASSEMBLY__
+
+#define csr_swap(csr, val)					\
+({								\
+	unsigned long __v = (unsigned long)(val);		\
+	__asm__ __volatile__ ("csrrw %0, " #csr ", %1"		\
+			      : "=r" (__v) : "rK" (__v)		\
+			      : "memory");			\
+	__v;							\
+})
+
+#define csr_read(csr)						\
+({								\
+	register unsigned long __v;				\
+	__asm__ __volatile__ ("csrr %0, " #csr			\
+			      : "=r" (__v) :			\
+			      : "memory");			\
+	__v;							\
+})
+
+#define csr_write(csr, val)					\
+({								\
+	unsigned long __v = (unsigned long)(val);		\
+	__asm__ __volatile__ ("csrw " #csr ", %0"		\
+			      : : "rK" (__v)			\
+			      : "memory");			\
+})
+
+#define csr_read_set(csr, val)					\
+({								\
+	unsigned long __v = (unsigned long)(val);		\
+	__asm__ __volatile__ ("csrrs %0, " #csr ", %1"		\
+			      : "=r" (__v) : "rK" (__v)		\
+			      : "memory");			\
+	__v;							\
+})
+
+#define csr_set(csr, val)					\
+({								\
+	unsigned long __v = (unsigned long)(val);		\
+	__asm__ __volatile__ ("csrs " #csr ", %0"		\
+			      : : "rK" (__v)			\
+			      : "memory");			\
+})
+
+#define csr_read_clear(csr, val)				\
+({								\
+	unsigned long __v = (unsigned long)(val);		\
+	__asm__ __volatile__ ("csrrc %0, " #csr ", %1"		\
+			      : "=r" (__v) : "rK" (__v)		\
+			      : "memory");			\
+	__v;							\
+})
+
+#define csr_clear(csr, val)					\
+({								\
+	unsigned long __v = (unsigned long)(val);		\
+	__asm__ __volatile__ ("csrc " #csr ", %0"		\
+			      : : "rK" (__v)			\
+			      : "memory");			\
+})
+
+#endif /* __ASSEMBLY__ */
+
+#endif /* _ASM_RISCV_CSR_H */
-- 
2.7.4

[U-Boot] [PATCH 08/12] riscv: Add a helper routine to print CPU information

[Auer, Lukas]

On Thu, 2018-08-30 at 00:54 -0700, Bin Meng wrote:
> This adds a helper routine to print CPU information. Currently
> it prints all the instruction set extensions that the processor
> core supports.
> 
> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
> ---
> 
>  arch/riscv/Makefile          |   1 +
>  arch/riscv/cpu/Makefile      |   5 ++
>  arch/riscv/cpu/cpu.c         |  49 +++++++++++++++++
>  arch/riscv/include/asm/csr.h | 124
> +++++++++++++++++++++++++++++++++++++++++++
>  4 files changed, 179 insertions(+)
>  create mode 100644 arch/riscv/cpu/Makefile
>  create mode 100644 arch/riscv/cpu/cpu.c
>  create mode 100644 arch/riscv/include/asm/csr.h
> 
> diff --git a/arch/riscv/Makefile b/arch/riscv/Makefile
> index 084888a..af432e1 100644
> --- a/arch/riscv/Makefile
> +++ b/arch/riscv/Makefile
> @@ -5,5 +5,6 @@
>  
>  head-y := arch/riscv/cpu/$(CPU)/start.o
>  
> +libs-y += arch/riscv/cpu/
>  libs-y += arch/riscv/cpu/$(CPU)/
>  libs-y += arch/riscv/lib/
> diff --git a/arch/riscv/cpu/Makefile b/arch/riscv/cpu/Makefile
> new file mode 100644
> index 0000000..63de163
> --- /dev/null
> +++ b/arch/riscv/cpu/Makefile
> @@ -0,0 +1,5 @@
> +# SPDX-License-Identifier: GPL-2.0+
> +#
> +# Copyright (C) 2018, Bin Meng <bmeng.cn@gmail.com>
> +
> +obj-y += cpu.o
> diff --git a/arch/riscv/cpu/cpu.c b/arch/riscv/cpu/cpu.c
> new file mode 100644
> index 0000000..ae57fb8
> --- /dev/null
> +++ b/arch/riscv/cpu/cpu.c
> @@ -0,0 +1,49 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2018, Bin Meng <bmeng.cn@gmail.com>
> + */
> +
> +#include <common.h>
> +#include <asm/csr.h>
> +
> +enum {
> +	ISA_INVALID = 0,
> +	ISA_32BIT,
> +	ISA_64BIT,
> +	ISA_128BIT
> +};
> +
> +static const char * const isa_bits[] = {
> +	[ISA_INVALID] = NULL,
> +	[ISA_32BIT]   = "32",
> +	[ISA_64BIT]   = "64",
> +	[ISA_128BIT]  = "128"
> +};
> +
> +static inline bool supports_extension(char ext)
> +{
> +	return csr_read(misa) & (1 << (ext - 'a'));
> +}
> +
> +int print_cpuinfo(void)
> +{
> +	char name[32];
> +	char *s = name;
> +	int bit;
> +
> +	s += sprintf(name, "rv");
> +	bit = csr_read(misa) >> (sizeof(long) * 8 - 2);
> +	s += sprintf(s, isa_bits[bit]);
> +
> +	supports_extension('i') ? *s++ = 'i' : 'r';
> +	supports_extension('m') ? *s++ = 'm' : 'i';
> +	supports_extension('a') ? *s++ = 'a' : 's';
> +	supports_extension('f') ? *s++ = 'f' : 'c';
> +	supports_extension('d') ? *s++ = 'd' : '-';
> +	supports_extension('c') ? *s++ = 'c' : 'v';
> +	*s++ = '\0';
> +
> +	printf("CPU:   %s\n", name);
> +
> +	return 0;
> +}
> diff --git a/arch/riscv/include/asm/csr.h
> b/arch/riscv/include/asm/csr.h
> new file mode 100644
> index 0000000..50fccea
> --- /dev/null
> +++ b/arch/riscv/include/asm/csr.h
> @@ -0,0 +1,124 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Copyright (C) 2015 Regents of the University of California
> + *
> + * Taken from Linux arch/riscv/include/asm/csr.h
> + */
> +
> +#ifndef _ASM_RISCV_CSR_H
> +#define _ASM_RISCV_CSR_H
> +
> +/* Status register flags */
> +#define SR_SIE		_AC(0x00000002, UL) /* Supervisor
> Interrupt Enable */
> +#define SR_SPIE		_AC(0x00000020, UL) /* Previous
> Supervisor IE */
> +#define SR_SPP		_AC(0x00000100, UL) /* Previously
> Supervisor */
> +#define SR_SUM		_AC(0x00040000, UL) /* Supervisor
> access User Memory */
> +
> +#define SR_FS		_AC(0x00006000, UL) /* Floating-point
> Status */
> +#define SR_FS_OFF	_AC(0x00000000, UL)
> +#define SR_FS_INITIAL	_AC(0x00002000, UL)
> +#define SR_FS_CLEAN	_AC(0x00004000, UL)
> +#define SR_FS_DIRTY	_AC(0x00006000, UL)
> +
> +#define SR_XS		_AC(0x00018000, UL) /* Extension Status
> */
> +#define SR_XS_OFF	_AC(0x00000000, UL)
> +#define SR_XS_INITIAL	_AC(0x00008000, UL)
> +#define SR_XS_CLEAN	_AC(0x00010000, UL)
> +#define SR_XS_DIRTY	_AC(0x00018000, UL)
> +
> +#ifndef CONFIG_64BIT
> +#define SR_SD		_AC(0x80000000, UL) /* FS/XS dirty */
> +#else
> +#define SR_SD		_AC(0x8000000000000000, UL) /* FS/XS
> dirty */
> +#endif
> +
> +/* SATP flags */
> +#if __riscv_xlen == 32
> +#define SATP_PPN	_AC(0x003FFFFF, UL)
> +#define SATP_MODE_32	_AC(0x80000000, UL)
> +#define SATP_MODE	SATP_MODE_32
> +#else
> +#define SATP_PPN	_AC(0x00000FFFFFFFFFFF, UL)
> +#define SATP_MODE_39	_AC(0x8000000000000000, UL)
> +#define SATP_MODE	SATP_MODE_39
> +#endif
> +
> +/* Interrupt Enable and Interrupt Pending flags */
> +#define SIE_SSIE	_AC(0x00000002, UL) /* Software Interrupt
> Enable */
> +#define SIE_STIE	_AC(0x00000020, UL) /* Timer Interrupt Enable
> */
> +
> +#define EXC_INST_MISALIGNED	0
> +#define EXC_INST_ACCESS		1
> +#define EXC_BREAKPOINT		3
> +#define EXC_LOAD_ACCESS		5
> +#define EXC_STORE_ACCESS	7
> +#define EXC_SYSCALL		8
> +#define EXC_INST_PAGE_FAULT	12
> +#define EXC_LOAD_PAGE_FAULT	13
> +#define EXC_STORE_PAGE_FAULT	15
> +
> +#ifndef __ASSEMBLY__
> +
> +#define csr_swap(csr, val)					\
> +({								\
> +	unsigned long __v = (unsigned long)(val);		\
> +	__asm__ __volatile__ ("csrrw %0, " #csr ", %1"		\
> +			      : "=r" (__v) : "rK" (__v)		\
> +			      : "memory");			\
> +	__v;							\
> +})
> +
> +#define csr_read(csr)						
> \
> +({								\
> +	register unsigned long __v;				\
> +	__asm__ __volatile__ ("csrr %0, " #csr			\
> +			      : "=r" (__v) :			\
> +			      : "memory");			\
> +	__v;							\
> +})
> +
> +#define csr_write(csr, val)					\
> +({								\
> +	unsigned long __v = (unsigned long)(val);		\
> +	__asm__ __volatile__ ("csrw " #csr ", %0"		\
> +			      : : "rK" (__v)			\
> +			      : "memory");			\
> +})
> +
> +#define csr_read_set(csr, val)					
> \
> +({								\
> +	unsigned long __v = (unsigned long)(val);		\
> +	__asm__ __volatile__ ("csrrs %0, " #csr ", %1"		\
> +			      : "=r" (__v) : "rK" (__v)		\
> +			      : "memory");			\
> +	__v;							\
> +})
> +
> +#define csr_set(csr, val)					\
> +({								\
> +	unsigned long __v = (unsigned long)(val);		\
> +	__asm__ __volatile__ ("csrs " #csr ", %0"		\
> +			      : : "rK" (__v)			\
> +			      : "memory");			\
> +})
> +
> +#define csr_read_clear(csr, val)				\
> +({								\
> +	unsigned long __v = (unsigned long)(val);		\
> +	__asm__ __volatile__ ("csrrc %0, " #csr ", %1"		\
> +			      : "=r" (__v) : "rK" (__v)		\
> +			      : "memory");			\
> +	__v;							\
> +})
> +
> +#define csr_clear(csr, val)					\
> +({								\
> +	unsigned long __v = (unsigned long)(val);		\
> +	__asm__ __volatile__ ("csrc " #csr ", %0"		\
> +			      : : "rK" (__v)			\
> +			      : "memory");			\
> +})
> +
> +#endif /* __ASSEMBLY__ */
> +
> +#endif /* _ASM_RISCV_CSR_H */

The RISC-V arch already has functions for accessing CSRs in encoding.h.
I don't think it makes sense to keep both versions. I would tend
towards keeping this version since this allows us to just sync with the
Linux kernel if there are any changes.

Thanks,
Lukas

[U-Boot] [PATCH 08/12] riscv: Add a helper routine to print CPU information

[Bin Meng]

Hi Lukas,

On Tue, Sep 4, 2018 at 5:42 AM Auer, Lukas
<lukas.auer@aisec.fraunhofer.de> wrote:
>
> On Thu, 2018-08-30 at 00:54 -0700, Bin Meng wrote:
> > This adds a helper routine to print CPU information. Currently
> > it prints all the instruction set extensions that the processor
> > core supports.
> >
> > Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
> > ---
> >
> >  arch/riscv/Makefile          |   1 +
> >  arch/riscv/cpu/Makefile      |   5 ++
> >  arch/riscv/cpu/cpu.c         |  49 +++++++++++++++++
> >  arch/riscv/include/asm/csr.h | 124
> > +++++++++++++++++++++++++++++++++++++++++++
> >  4 files changed, 179 insertions(+)
> >  create mode 100644 arch/riscv/cpu/Makefile
> >  create mode 100644 arch/riscv/cpu/cpu.c
> >  create mode 100644 arch/riscv/include/asm/csr.h
> >
> > diff --git a/arch/riscv/Makefile b/arch/riscv/Makefile
> > index 084888a..af432e1 100644
> > --- a/arch/riscv/Makefile
> > +++ b/arch/riscv/Makefile
> > @@ -5,5 +5,6 @@
> >
> >  head-y := arch/riscv/cpu/$(CPU)/start.o
> >
> > +libs-y += arch/riscv/cpu/
> >  libs-y += arch/riscv/cpu/$(CPU)/
> >  libs-y += arch/riscv/lib/
> > diff --git a/arch/riscv/cpu/Makefile b/arch/riscv/cpu/Makefile
> > new file mode 100644
> > index 0000000..63de163
> > --- /dev/null
> > +++ b/arch/riscv/cpu/Makefile
> > @@ -0,0 +1,5 @@
> > +# SPDX-License-Identifier: GPL-2.0+
> > +#
> > +# Copyright (C) 2018, Bin Meng <bmeng.cn@gmail.com>
> > +
> > +obj-y += cpu.o
> > diff --git a/arch/riscv/cpu/cpu.c b/arch/riscv/cpu/cpu.c
> > new file mode 100644
> > index 0000000..ae57fb8
> > --- /dev/null
> > +++ b/arch/riscv/cpu/cpu.c
> > @@ -0,0 +1,49 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * Copyright (C) 2018, Bin Meng <bmeng.cn@gmail.com>
> > + */
> > +
> > +#include <common.h>
> > +#include <asm/csr.h>
> > +
> > +enum {
> > +     ISA_INVALID = 0,
> > +     ISA_32BIT,
> > +     ISA_64BIT,
> > +     ISA_128BIT
> > +};
> > +
> > +static const char * const isa_bits[] = {
> > +     [ISA_INVALID] = NULL,
> > +     [ISA_32BIT]   = "32",
> > +     [ISA_64BIT]   = "64",
> > +     [ISA_128BIT]  = "128"
> > +};
> > +
> > +static inline bool supports_extension(char ext)
> > +{
> > +     return csr_read(misa) & (1 << (ext - 'a'));
> > +}
> > +
> > +int print_cpuinfo(void)
> > +{
> > +     char name[32];
> > +     char *s = name;
> > +     int bit;
> > +
> > +     s += sprintf(name, "rv");
> > +     bit = csr_read(misa) >> (sizeof(long) * 8 - 2);
> > +     s += sprintf(s, isa_bits[bit]);
> > +
> > +     supports_extension('i') ? *s++ = 'i' : 'r';
> > +     supports_extension('m') ? *s++ = 'm' : 'i';
> > +     supports_extension('a') ? *s++ = 'a' : 's';
> > +     supports_extension('f') ? *s++ = 'f' : 'c';
> > +     supports_extension('d') ? *s++ = 'd' : '-';
> > +     supports_extension('c') ? *s++ = 'c' : 'v';
> > +     *s++ = '\0';
> > +
> > +     printf("CPU:   %s\n", name);
> > +
> > +     return 0;
> > +}
> > diff --git a/arch/riscv/include/asm/csr.h
> > b/arch/riscv/include/asm/csr.h
> > new file mode 100644
> > index 0000000..50fccea
> > --- /dev/null
> > +++ b/arch/riscv/include/asm/csr.h
> > @@ -0,0 +1,124 @@
> > +/* SPDX-License-Identifier: GPL-2.0 */
> > +/*
> > + * Copyright (C) 2015 Regents of the University of California
> > + *
> > + * Taken from Linux arch/riscv/include/asm/csr.h
> > + */
> > +
> > +#ifndef _ASM_RISCV_CSR_H
> > +#define _ASM_RISCV_CSR_H
> > +
> > +/* Status register flags */
> > +#define SR_SIE               _AC(0x00000002, UL) /* Supervisor
> > Interrupt Enable */
> > +#define SR_SPIE              _AC(0x00000020, UL) /* Previous
> > Supervisor IE */
> > +#define SR_SPP               _AC(0x00000100, UL) /* Previously
> > Supervisor */
> > +#define SR_SUM               _AC(0x00040000, UL) /* Supervisor
> > access User Memory */
> > +
> > +#define SR_FS                _AC(0x00006000, UL) /* Floating-point
> > Status */
> > +#define SR_FS_OFF    _AC(0x00000000, UL)
> > +#define SR_FS_INITIAL        _AC(0x00002000, UL)
> > +#define SR_FS_CLEAN  _AC(0x00004000, UL)
> > +#define SR_FS_DIRTY  _AC(0x00006000, UL)
> > +
> > +#define SR_XS                _AC(0x00018000, UL) /* Extension Status
> > */
> > +#define SR_XS_OFF    _AC(0x00000000, UL)
> > +#define SR_XS_INITIAL        _AC(0x00008000, UL)
> > +#define SR_XS_CLEAN  _AC(0x00010000, UL)
> > +#define SR_XS_DIRTY  _AC(0x00018000, UL)
> > +
> > +#ifndef CONFIG_64BIT
> > +#define SR_SD                _AC(0x80000000, UL) /* FS/XS dirty */
> > +#else
> > +#define SR_SD                _AC(0x8000000000000000, UL) /* FS/XS
> > dirty */
> > +#endif
> > +
> > +/* SATP flags */
> > +#if __riscv_xlen == 32
> > +#define SATP_PPN     _AC(0x003FFFFF, UL)
> > +#define SATP_MODE_32 _AC(0x80000000, UL)
> > +#define SATP_MODE    SATP_MODE_32
> > +#else
> > +#define SATP_PPN     _AC(0x00000FFFFFFFFFFF, UL)
> > +#define SATP_MODE_39 _AC(0x8000000000000000, UL)
> > +#define SATP_MODE    SATP_MODE_39
> > +#endif
> > +
> > +/* Interrupt Enable and Interrupt Pending flags */
> > +#define SIE_SSIE     _AC(0x00000002, UL) /* Software Interrupt
> > Enable */
> > +#define SIE_STIE     _AC(0x00000020, UL) /* Timer Interrupt Enable
> > */
> > +
> > +#define EXC_INST_MISALIGNED  0
> > +#define EXC_INST_ACCESS              1
> > +#define EXC_BREAKPOINT               3
> > +#define EXC_LOAD_ACCESS              5
> > +#define EXC_STORE_ACCESS     7
> > +#define EXC_SYSCALL          8
> > +#define EXC_INST_PAGE_FAULT  12
> > +#define EXC_LOAD_PAGE_FAULT  13
> > +#define EXC_STORE_PAGE_FAULT 15
> > +
> > +#ifndef __ASSEMBLY__
> > +
> > +#define csr_swap(csr, val)                                   \
> > +({                                                           \
> > +     unsigned long __v = (unsigned long)(val);               \
> > +     __asm__ __volatile__ ("csrrw %0, " #csr ", %1"          \
> > +                           : "=r" (__v) : "rK" (__v)         \
> > +                           : "memory");                      \
> > +     __v;                                                    \
> > +})
> > +
> > +#define csr_read(csr)
> > \
> > +({                                                           \
> > +     register unsigned long __v;                             \
> > +     __asm__ __volatile__ ("csrr %0, " #csr                  \
> > +                           : "=r" (__v) :                    \
> > +                           : "memory");                      \
> > +     __v;                                                    \
> > +})
> > +
> > +#define csr_write(csr, val)                                  \
> > +({                                                           \
> > +     unsigned long __v = (unsigned long)(val);               \
> > +     __asm__ __volatile__ ("csrw " #csr ", %0"               \
> > +                           : : "rK" (__v)                    \
> > +                           : "memory");                      \
> > +})
> > +
> > +#define csr_read_set(csr, val)
> > \
> > +({                                                           \
> > +     unsigned long __v = (unsigned long)(val);               \
> > +     __asm__ __volatile__ ("csrrs %0, " #csr ", %1"          \
> > +                           : "=r" (__v) : "rK" (__v)         \
> > +                           : "memory");                      \
> > +     __v;                                                    \
> > +})
> > +
> > +#define csr_set(csr, val)                                    \
> > +({                                                           \
> > +     unsigned long __v = (unsigned long)(val);               \
> > +     __asm__ __volatile__ ("csrs " #csr ", %0"               \
> > +                           : : "rK" (__v)                    \
> > +                           : "memory");                      \
> > +})
> > +
> > +#define csr_read_clear(csr, val)                             \
> > +({                                                           \
> > +     unsigned long __v = (unsigned long)(val);               \
> > +     __asm__ __volatile__ ("csrrc %0, " #csr ", %1"          \
> > +                           : "=r" (__v) : "rK" (__v)         \
> > +                           : "memory");                      \
> > +     __v;                                                    \
> > +})
> > +
> > +#define csr_clear(csr, val)                                  \
> > +({                                                           \
> > +     unsigned long __v = (unsigned long)(val);               \
> > +     __asm__ __volatile__ ("csrc " #csr ", %0"               \
> > +                           : : "rK" (__v)                    \
> > +                           : "memory");                      \
> > +})
> > +
> > +#endif /* __ASSEMBLY__ */
> > +
> > +#endif /* _ASM_RISCV_CSR_H */
>
> The RISC-V arch already has functions for accessing CSRs in encoding.h.
> I don't think it makes sense to keep both versions. I would tend
> towards keeping this version since this allows us to just sync with the
> Linux kernel if there are any changes.

Thanks for pointing out. But I checked current Linux tree, and there
is no encoding.h. Maybe encoding.h was from some old kernel tree? I
can clean this up and leaving only csr.h in v2.

Regards,
Bin

[U-Boot] [PATCH 08/12] riscv: Add a helper routine to print CPU information

[Auer, Lukas]

Hi Bin,

On Thu, 2018-09-06 at 11:03 +0800, Bin Meng wrote:
> Hi Lukas,
> 
> On Tue, Sep 4, 2018 at 5:42 AM Auer, Lukas
> <lukas.auer@aisec.fraunhofer.de> wrote:
> > 
> > On Thu, 2018-08-30 at 00:54 -0700, Bin Meng wrote:
> > > This adds a helper routine to print CPU information. Currently
> > > it prints all the instruction set extensions that the processor
> > > core supports.
> > > 
> > > Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
> > > ---
> > > 
> > >  arch/riscv/Makefile          |   1 +
> > >  arch/riscv/cpu/Makefile      |   5 ++
> > >  arch/riscv/cpu/cpu.c         |  49 +++++++++++++++++
> > >  arch/riscv/include/asm/csr.h | 124
> > > +++++++++++++++++++++++++++++++++++++++++++
> > >  4 files changed, 179 insertions(+)
> > >  create mode 100644 arch/riscv/cpu/Makefile
> > >  create mode 100644 arch/riscv/cpu/cpu.c
> > >  create mode 100644 arch/riscv/include/asm/csr.h
> > > 
> > > diff --git a/arch/riscv/Makefile b/arch/riscv/Makefile
> > > index 084888a..af432e1 100644
> > > --- a/arch/riscv/Makefile
> > > +++ b/arch/riscv/Makefile
> > > @@ -5,5 +5,6 @@
> > > 
> > >  head-y := arch/riscv/cpu/$(CPU)/start.o
> > > 
> > > +libs-y += arch/riscv/cpu/
> > >  libs-y += arch/riscv/cpu/$(CPU)/
> > >  libs-y += arch/riscv/lib/
> > > diff --git a/arch/riscv/cpu/Makefile b/arch/riscv/cpu/Makefile
> > > new file mode 100644
> > > index 0000000..63de163
> > > --- /dev/null
> > > +++ b/arch/riscv/cpu/Makefile
> > > @@ -0,0 +1,5 @@
> > > +# SPDX-License-Identifier: GPL-2.0+
> > > +#
> > > +# Copyright (C) 2018, Bin Meng <bmeng.cn@gmail.com>
> > > +
> > > +obj-y += cpu.o
> > > diff --git a/arch/riscv/cpu/cpu.c b/arch/riscv/cpu/cpu.c
> > > new file mode 100644
> > > index 0000000..ae57fb8
> > > --- /dev/null
> > > +++ b/arch/riscv/cpu/cpu.c
> > > @@ -0,0 +1,49 @@
> > > +// SPDX-License-Identifier: GPL-2.0+
> > > +/*
> > > + * Copyright (C) 2018, Bin Meng <bmeng.cn@gmail.com>
> > > + */
> > > +
> > > +#include <common.h>
> > > +#include <asm/csr.h>
> > > +
> > > +enum {
> > > +     ISA_INVALID = 0,
> > > +     ISA_32BIT,
> > > +     ISA_64BIT,
> > > +     ISA_128BIT
> > > +};
> > > +
> > > +static const char * const isa_bits[] = {
> > > +     [ISA_INVALID] = NULL,
> > > +     [ISA_32BIT]   = "32",
> > > +     [ISA_64BIT]   = "64",
> > > +     [ISA_128BIT]  = "128"
> > > +};
> > > +
> > > +static inline bool supports_extension(char ext)
> > > +{
> > > +     return csr_read(misa) & (1 << (ext - 'a'));
> > > +}
> > > +
> > > +int print_cpuinfo(void)
> > > +{
> > > +     char name[32];
> > > +     char *s = name;
> > > +     int bit;
> > > +
> > > +     s += sprintf(name, "rv");
> > > +     bit = csr_read(misa) >> (sizeof(long) * 8 - 2);
> > > +     s += sprintf(s, isa_bits[bit]);
> > > +
> > > +     supports_extension('i') ? *s++ = 'i' : 'r';
> > > +     supports_extension('m') ? *s++ = 'm' : 'i';
> > > +     supports_extension('a') ? *s++ = 'a' : 's';
> > > +     supports_extension('f') ? *s++ = 'f' : 'c';
> > > +     supports_extension('d') ? *s++ = 'd' : '-';
> > > +     supports_extension('c') ? *s++ = 'c' : 'v';
> > > +     *s++ = '\0';
> > > +
> > > +     printf("CPU:   %s\n", name);
> > > +
> > > +     return 0;
> > > +}
> > > diff --git a/arch/riscv/include/asm/csr.h
> > > b/arch/riscv/include/asm/csr.h
> > > new file mode 100644
> > > index 0000000..50fccea
> > > --- /dev/null
> > > +++ b/arch/riscv/include/asm/csr.h
> > > @@ -0,0 +1,124 @@
> > > +/* SPDX-License-Identifier: GPL-2.0 */
> > > +/*
> > > + * Copyright (C) 2015 Regents of the University of California
> > > + *
> > > + * Taken from Linux arch/riscv/include/asm/csr.h
> > > + */
> > > +
> > > +#ifndef _ASM_RISCV_CSR_H
> > > +#define _ASM_RISCV_CSR_H
> > > +
> > > +/* Status register flags */
> > > +#define SR_SIE               _AC(0x00000002, UL) /* Supervisor
> > > Interrupt Enable */
> > > +#define SR_SPIE              _AC(0x00000020, UL) /* Previous
> > > Supervisor IE */
> > > +#define SR_SPP               _AC(0x00000100, UL) /* Previously
> > > Supervisor */
> > > +#define SR_SUM               _AC(0x00040000, UL) /* Supervisor
> > > access User Memory */
> > > +
> > > +#define SR_FS                _AC(0x00006000, UL) /* Floating-
> > > point
> > > Status */
> > > +#define SR_FS_OFF    _AC(0x00000000, UL)
> > > +#define SR_FS_INITIAL        _AC(0x00002000, UL)
> > > +#define SR_FS_CLEAN  _AC(0x00004000, UL)
> > > +#define SR_FS_DIRTY  _AC(0x00006000, UL)
> > > +
> > > +#define SR_XS                _AC(0x00018000, UL) /* Extension
> > > Status
> > > */
> > > +#define SR_XS_OFF    _AC(0x00000000, UL)
> > > +#define SR_XS_INITIAL        _AC(0x00008000, UL)
> > > +#define SR_XS_CLEAN  _AC(0x00010000, UL)
> > > +#define SR_XS_DIRTY  _AC(0x00018000, UL)
> > > +
> > > +#ifndef CONFIG_64BIT
> > > +#define SR_SD                _AC(0x80000000, UL) /* FS/XS dirty
> > > */
> > > +#else
> > > +#define SR_SD                _AC(0x8000000000000000, UL) /*
> > > FS/XS
> > > dirty */
> > > +#endif
> > > +
> > > +/* SATP flags */
> > > +#if __riscv_xlen == 32
> > > +#define SATP_PPN     _AC(0x003FFFFF, UL)
> > > +#define SATP_MODE_32 _AC(0x80000000, UL)
> > > +#define SATP_MODE    SATP_MODE_32
> > > +#else
> > > +#define SATP_PPN     _AC(0x00000FFFFFFFFFFF, UL)
> > > +#define SATP_MODE_39 _AC(0x8000000000000000, UL)
> > > +#define SATP_MODE    SATP_MODE_39
> > > +#endif
> > > +
> > > +/* Interrupt Enable and Interrupt Pending flags */
> > > +#define SIE_SSIE     _AC(0x00000002, UL) /* Software Interrupt
> > > Enable */
> > > +#define SIE_STIE     _AC(0x00000020, UL) /* Timer Interrupt
> > > Enable
> > > */
> > > +
> > > +#define EXC_INST_MISALIGNED  0
> > > +#define EXC_INST_ACCESS              1
> > > +#define EXC_BREAKPOINT               3
> > > +#define EXC_LOAD_ACCESS              5
> > > +#define EXC_STORE_ACCESS     7
> > > +#define EXC_SYSCALL          8
> > > +#define EXC_INST_PAGE_FAULT  12
> > > +#define EXC_LOAD_PAGE_FAULT  13
> > > +#define EXC_STORE_PAGE_FAULT 15
> > > +
> > > +#ifndef __ASSEMBLY__
> > > +
> > > +#define csr_swap(csr, val)                                   \
> > > +({                                                           \
> > > +     unsigned long __v = (unsigned long)(val);               \
> > > +     __asm__ __volatile__ ("csrrw %0, " #csr ", %1"          \
> > > +                           : "=r" (__v) : "rK" (__v)         \
> > > +                           : "memory");                      \
> > > +     __v;                                                    \
> > > +})
> > > +
> > > +#define csr_read(csr)
> > > \
> > > +({                                                           \
> > > +     register unsigned long __v;                             \
> > > +     __asm__ __volatile__ ("csrr %0, " #csr                  \
> > > +                           : "=r" (__v) :                    \
> > > +                           : "memory");                      \
> > > +     __v;                                                    \
> > > +})
> > > +
> > > +#define csr_write(csr, val)                                  \
> > > +({                                                           \
> > > +     unsigned long __v = (unsigned long)(val);               \
> > > +     __asm__ __volatile__ ("csrw " #csr ", %0"               \
> > > +                           : : "rK" (__v)                    \
> > > +                           : "memory");                      \
> > > +})
> > > +
> > > +#define csr_read_set(csr, val)
> > > \
> > > +({                                                           \
> > > +     unsigned long __v = (unsigned long)(val);               \
> > > +     __asm__ __volatile__ ("csrrs %0, " #csr ", %1"          \
> > > +                           : "=r" (__v) : "rK" (__v)         \
> > > +                           : "memory");                      \
> > > +     __v;                                                    \
> > > +})
> > > +
> > > +#define csr_set(csr, val)                                    \
> > > +({                                                           \
> > > +     unsigned long __v = (unsigned long)(val);               \
> > > +     __asm__ __volatile__ ("csrs " #csr ", %0"               \
> > > +                           : : "rK" (__v)                    \
> > > +                           : "memory");                      \
> > > +})
> > > +
> > > +#define csr_read_clear(csr, val)                             \
> > > +({                                                           \
> > > +     unsigned long __v = (unsigned long)(val);               \
> > > +     __asm__ __volatile__ ("csrrc %0, " #csr ", %1"          \
> > > +                           : "=r" (__v) : "rK" (__v)         \
> > > +                           : "memory");                      \
> > > +     __v;                                                    \
> > > +})
> > > +
> > > +#define csr_clear(csr, val)                                  \
> > > +({                                                           \
> > > +     unsigned long __v = (unsigned long)(val);               \
> > > +     __asm__ __volatile__ ("csrc " #csr ", %0"               \
> > > +                           : : "rK" (__v)                    \
> > > +                           : "memory");                      \
> > > +})
> > > +
> > > +#endif /* __ASSEMBLY__ */
> > > +
> > > +#endif /* _ASM_RISCV_CSR_H */
> > 
> > The RISC-V arch already has functions for accessing CSRs in
> > encoding.h.
> > I don't think it makes sense to keep both versions. I would tend
> > towards keeping this version since this allows us to just sync with
> > the
> > Linux kernel if there are any changes.
> 
> Thanks for pointing out. But I checked current Linux tree, and there
> is no encoding.h. Maybe encoding.h was from some old kernel tree? I
> can clean this up and leaving only csr.h in v2.
> 
> Regards,
> Bin

Sorry, I meant that encoding.h is in the u-boot RISC-V arch (
arch/riscv/include/asm/encoding.h). I think it's from bbl.

Thanks,
Lukas

[U-Boot] [PATCH 08/12] riscv: Add a helper routine to print CPU information

[Bin Meng]

Hi Lucas,

On Fri, Sep 7, 2018 at 5:29 AM Auer, Lukas
<lukas.auer@aisec.fraunhofer.de> wrote:
>
> Hi Bin,
>
> On Thu, 2018-09-06 at 11:03 +0800, Bin Meng wrote:
> > Hi Lukas,
> >
> > On Tue, Sep 4, 2018 at 5:42 AM Auer, Lukas
> > <lukas.auer@aisec.fraunhofer.de> wrote:
> > >
> > > On Thu, 2018-08-30 at 00:54 -0700, Bin Meng wrote:
> > > > This adds a helper routine to print CPU information. Currently
> > > > it prints all the instruction set extensions that the processor
> > > > core supports.
> > > >
> > > > Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
> > > > ---
> > > >
> > > >  arch/riscv/Makefile          |   1 +
> > > >  arch/riscv/cpu/Makefile      |   5 ++
> > > >  arch/riscv/cpu/cpu.c         |  49 +++++++++++++++++
> > > >  arch/riscv/include/asm/csr.h | 124
> > > > +++++++++++++++++++++++++++++++++++++++++++
> > > >  4 files changed, 179 insertions(+)
> > > >  create mode 100644 arch/riscv/cpu/Makefile
> > > >  create mode 100644 arch/riscv/cpu/cpu.c
> > > >  create mode 100644 arch/riscv/include/asm/csr.h
> > > >
> > > > diff --git a/arch/riscv/Makefile b/arch/riscv/Makefile
> > > > index 084888a..af432e1 100644
> > > > --- a/arch/riscv/Makefile
> > > > +++ b/arch/riscv/Makefile
> > > > @@ -5,5 +5,6 @@
> > > >
> > > >  head-y := arch/riscv/cpu/$(CPU)/start.o
> > > >
> > > > +libs-y += arch/riscv/cpu/
> > > >  libs-y += arch/riscv/cpu/$(CPU)/
> > > >  libs-y += arch/riscv/lib/
> > > > diff --git a/arch/riscv/cpu/Makefile b/arch/riscv/cpu/Makefile
> > > > new file mode 100644
> > > > index 0000000..63de163
> > > > --- /dev/null
> > > > +++ b/arch/riscv/cpu/Makefile
> > > > @@ -0,0 +1,5 @@
> > > > +# SPDX-License-Identifier: GPL-2.0+
> > > > +#
> > > > +# Copyright (C) 2018, Bin Meng <bmeng.cn@gmail.com>
> > > > +
> > > > +obj-y += cpu.o
> > > > diff --git a/arch/riscv/cpu/cpu.c b/arch/riscv/cpu/cpu.c
> > > > new file mode 100644
> > > > index 0000000..ae57fb8
> > > > --- /dev/null
> > > > +++ b/arch/riscv/cpu/cpu.c
> > > > @@ -0,0 +1,49 @@
> > > > +// SPDX-License-Identifier: GPL-2.0+
> > > > +/*
> > > > + * Copyright (C) 2018, Bin Meng <bmeng.cn@gmail.com>
> > > > + */
> > > > +
> > > > +#include <common.h>
> > > > +#include <asm/csr.h>
> > > > +
> > > > +enum {
> > > > +     ISA_INVALID = 0,
> > > > +     ISA_32BIT,
> > > > +     ISA_64BIT,
> > > > +     ISA_128BIT
> > > > +};
> > > > +
> > > > +static const char * const isa_bits[] = {
> > > > +     [ISA_INVALID] = NULL,
> > > > +     [ISA_32BIT]   = "32",
> > > > +     [ISA_64BIT]   = "64",
> > > > +     [ISA_128BIT]  = "128"
> > > > +};
> > > > +
> > > > +static inline bool supports_extension(char ext)
> > > > +{
> > > > +     return csr_read(misa) & (1 << (ext - 'a'));
> > > > +}
> > > > +
> > > > +int print_cpuinfo(void)
> > > > +{
> > > > +     char name[32];
> > > > +     char *s = name;
> > > > +     int bit;
> > > > +
> > > > +     s += sprintf(name, "rv");
> > > > +     bit = csr_read(misa) >> (sizeof(long) * 8 - 2);
> > > > +     s += sprintf(s, isa_bits[bit]);
> > > > +
> > > > +     supports_extension('i') ? *s++ = 'i' : 'r';
> > > > +     supports_extension('m') ? *s++ = 'm' : 'i';
> > > > +     supports_extension('a') ? *s++ = 'a' : 's';
> > > > +     supports_extension('f') ? *s++ = 'f' : 'c';
> > > > +     supports_extension('d') ? *s++ = 'd' : '-';
> > > > +     supports_extension('c') ? *s++ = 'c' : 'v';
> > > > +     *s++ = '\0';
> > > > +
> > > > +     printf("CPU:   %s\n", name);
> > > > +
> > > > +     return 0;
> > > > +}
> > > > diff --git a/arch/riscv/include/asm/csr.h
> > > > b/arch/riscv/include/asm/csr.h
> > > > new file mode 100644
> > > > index 0000000..50fccea
> > > > --- /dev/null
> > > > +++ b/arch/riscv/include/asm/csr.h
> > > > @@ -0,0 +1,124 @@
> > > > +/* SPDX-License-Identifier: GPL-2.0 */
> > > > +/*
> > > > + * Copyright (C) 2015 Regents of the University of California
> > > > + *
> > > > + * Taken from Linux arch/riscv/include/asm/csr.h
> > > > + */
> > > > +
> > > > +#ifndef _ASM_RISCV_CSR_H
> > > > +#define _ASM_RISCV_CSR_H
> > > > +
> > > > +/* Status register flags */
> > > > +#define SR_SIE               _AC(0x00000002, UL) /* Supervisor
> > > > Interrupt Enable */
> > > > +#define SR_SPIE              _AC(0x00000020, UL) /* Previous
> > > > Supervisor IE */
> > > > +#define SR_SPP               _AC(0x00000100, UL) /* Previously
> > > > Supervisor */
> > > > +#define SR_SUM               _AC(0x00040000, UL) /* Supervisor
> > > > access User Memory */
> > > > +
> > > > +#define SR_FS                _AC(0x00006000, UL) /* Floating-
> > > > point
> > > > Status */
> > > > +#define SR_FS_OFF    _AC(0x00000000, UL)
> > > > +#define SR_FS_INITIAL        _AC(0x00002000, UL)
> > > > +#define SR_FS_CLEAN  _AC(0x00004000, UL)
> > > > +#define SR_FS_DIRTY  _AC(0x00006000, UL)
> > > > +
> > > > +#define SR_XS                _AC(0x00018000, UL) /* Extension
> > > > Status
> > > > */
> > > > +#define SR_XS_OFF    _AC(0x00000000, UL)
> > > > +#define SR_XS_INITIAL        _AC(0x00008000, UL)
> > > > +#define SR_XS_CLEAN  _AC(0x00010000, UL)
> > > > +#define SR_XS_DIRTY  _AC(0x00018000, UL)
> > > > +
> > > > +#ifndef CONFIG_64BIT
> > > > +#define SR_SD                _AC(0x80000000, UL) /* FS/XS dirty
> > > > */
> > > > +#else
> > > > +#define SR_SD                _AC(0x8000000000000000, UL) /*
> > > > FS/XS
> > > > dirty */
> > > > +#endif
> > > > +
> > > > +/* SATP flags */
> > > > +#if __riscv_xlen == 32
> > > > +#define SATP_PPN     _AC(0x003FFFFF, UL)
> > > > +#define SATP_MODE_32 _AC(0x80000000, UL)
> > > > +#define SATP_MODE    SATP_MODE_32
> > > > +#else
> > > > +#define SATP_PPN     _AC(0x00000FFFFFFFFFFF, UL)
> > > > +#define SATP_MODE_39 _AC(0x8000000000000000, UL)
> > > > +#define SATP_MODE    SATP_MODE_39
> > > > +#endif
> > > > +
> > > > +/* Interrupt Enable and Interrupt Pending flags */
> > > > +#define SIE_SSIE     _AC(0x00000002, UL) /* Software Interrupt
> > > > Enable */
> > > > +#define SIE_STIE     _AC(0x00000020, UL) /* Timer Interrupt
> > > > Enable
> > > > */
> > > > +
> > > > +#define EXC_INST_MISALIGNED  0
> > > > +#define EXC_INST_ACCESS              1
> > > > +#define EXC_BREAKPOINT               3
> > > > +#define EXC_LOAD_ACCESS              5
> > > > +#define EXC_STORE_ACCESS     7
> > > > +#define EXC_SYSCALL          8
> > > > +#define EXC_INST_PAGE_FAULT  12
> > > > +#define EXC_LOAD_PAGE_FAULT  13
> > > > +#define EXC_STORE_PAGE_FAULT 15
> > > > +
> > > > +#ifndef __ASSEMBLY__
> > > > +
> > > > +#define csr_swap(csr, val)                                   \
> > > > +({                                                           \
> > > > +     unsigned long __v = (unsigned long)(val);               \
> > > > +     __asm__ __volatile__ ("csrrw %0, " #csr ", %1"          \
> > > > +                           : "=r" (__v) : "rK" (__v)         \
> > > > +                           : "memory");                      \
> > > > +     __v;                                                    \
> > > > +})
> > > > +
> > > > +#define csr_read(csr)
> > > > \
> > > > +({                                                           \
> > > > +     register unsigned long __v;                             \
> > > > +     __asm__ __volatile__ ("csrr %0, " #csr                  \
> > > > +                           : "=r" (__v) :                    \
> > > > +                           : "memory");                      \
> > > > +     __v;                                                    \
> > > > +})
> > > > +
> > > > +#define csr_write(csr, val)                                  \
> > > > +({                                                           \
> > > > +     unsigned long __v = (unsigned long)(val);               \
> > > > +     __asm__ __volatile__ ("csrw " #csr ", %0"               \
> > > > +                           : : "rK" (__v)                    \
> > > > +                           : "memory");                      \
> > > > +})
> > > > +
> > > > +#define csr_read_set(csr, val)
> > > > \
> > > > +({                                                           \
> > > > +     unsigned long __v = (unsigned long)(val);               \
> > > > +     __asm__ __volatile__ ("csrrs %0, " #csr ", %1"          \
> > > > +                           : "=r" (__v) : "rK" (__v)         \
> > > > +                           : "memory");                      \
> > > > +     __v;                                                    \
> > > > +})
> > > > +
> > > > +#define csr_set(csr, val)                                    \
> > > > +({                                                           \
> > > > +     unsigned long __v = (unsigned long)(val);               \
> > > > +     __asm__ __volatile__ ("csrs " #csr ", %0"               \
> > > > +                           : : "rK" (__v)                    \
> > > > +                           : "memory");                      \
> > > > +})
> > > > +
> > > > +#define csr_read_clear(csr, val)                             \
> > > > +({                                                           \
> > > > +     unsigned long __v = (unsigned long)(val);               \
> > > > +     __asm__ __volatile__ ("csrrc %0, " #csr ", %1"          \
> > > > +                           : "=r" (__v) : "rK" (__v)         \
> > > > +                           : "memory");                      \
> > > > +     __v;                                                    \
> > > > +})
> > > > +
> > > > +#define csr_clear(csr, val)                                  \
> > > > +({                                                           \
> > > > +     unsigned long __v = (unsigned long)(val);               \
> > > > +     __asm__ __volatile__ ("csrc " #csr ", %0"               \
> > > > +                           : : "rK" (__v)                    \
> > > > +                           : "memory");                      \
> > > > +})
> > > > +
> > > > +#endif /* __ASSEMBLY__ */
> > > > +
> > > > +#endif /* _ASM_RISCV_CSR_H */
> > >
> > > The RISC-V arch already has functions for accessing CSRs in
> > > encoding.h.
> > > I don't think it makes sense to keep both versions. I would tend
> > > towards keeping this version since this allows us to just sync with
> > > the
> > > Linux kernel if there are any changes.
> >
> > Thanks for pointing out. But I checked current Linux tree, and there
> > is no encoding.h. Maybe encoding.h was from some old kernel tree? I
> > can clean this up and leaving only csr.h in v2.
> >
> > Regards,
> > Bin
>
> Sorry, I meant that encoding.h is in the u-boot RISC-V arch (
> arch/riscv/include/asm/encoding.h). I think it's from bbl.

Thanks. I believe we will just need the Linux version of csr.h and
drop the bbl one.

Regards,
Bin

[U-Boot] [PATCH 09/12] riscv: Make start.S available for all targets

[Bin Meng]

Currently start.S is inside arch/riscv/cpu/ax25/, but it can be
common for all RISC-V targets.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
---

 arch/riscv/Makefile               | 2 +-
 arch/riscv/cpu/Makefile           | 2 ++
 arch/riscv/cpu/ax25/Makefile      | 2 --
 arch/riscv/cpu/{ax25 => }/start.S | 0
 arch/riscv/cpu/u-boot.lds         | 2 +-
 5 files changed, 4 insertions(+), 4 deletions(-)
 rename arch/riscv/cpu/{ax25 => }/start.S (100%)

diff --git a/arch/riscv/Makefile b/arch/riscv/Makefile
index af432e1..8fb6a88 100644
--- a/arch/riscv/Makefile
+++ b/arch/riscv/Makefile
@@ -3,7 +3,7 @@
 # Copyright (C) 2017 Andes Technology Corporation.
 # Rick Chen, Andes Technology Corporation <rick@andestech.com>
 
-head-y := arch/riscv/cpu/$(CPU)/start.o
+head-y := arch/riscv/cpu/start.o
 
 libs-y += arch/riscv/cpu/
 libs-y += arch/riscv/cpu/$(CPU)/
diff --git a/arch/riscv/cpu/Makefile b/arch/riscv/cpu/Makefile
index 63de163..2cc6757 100644
--- a/arch/riscv/cpu/Makefile
+++ b/arch/riscv/cpu/Makefile
@@ -2,4 +2,6 @@
 #
 # Copyright (C) 2018, Bin Meng <bmeng.cn@gmail.com>
 
+extra-y = start.o
+
 obj-y += cpu.o
diff --git a/arch/riscv/cpu/ax25/Makefile b/arch/riscv/cpu/ax25/Makefile
index c3f164c..2ab0342 100644
--- a/arch/riscv/cpu/ax25/Makefile
+++ b/arch/riscv/cpu/ax25/Makefile
@@ -3,6 +3,4 @@
 # Copyright (C) 2017 Andes Technology Corporation
 # Rick Chen, Andes Technology Corporation <rick@andestech.com>
 
-extra-y	= start.o
-
 obj-y	:= cpu.o
diff --git a/arch/riscv/cpu/ax25/start.S b/arch/riscv/cpu/start.S
similarity index 100%
rename from arch/riscv/cpu/ax25/start.S
rename to arch/riscv/cpu/start.S
diff --git a/arch/riscv/cpu/u-boot.lds b/arch/riscv/cpu/u-boot.lds
index f414473..11bc4a7 100644
--- a/arch/riscv/cpu/u-boot.lds
+++ b/arch/riscv/cpu/u-boot.lds
@@ -11,7 +11,7 @@ SECTIONS
 {
 	. = ALIGN(4);
 	.text : {
-		arch/riscv/cpu/ax25/start.o	(.text)
+		arch/riscv/cpu/start.o	(.text)
 	}
 
 	/* This needs to come before *(.text*) */
-- 
2.7.4

[U-Boot] [PATCH 10/12] riscv: ae350: Clean up mixed tabs and spaces in the dts

[Bin Meng]

There are quite a lot of mixed tabs and spaces in the ae350.dts.
Clean them up.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
---

 arch/riscv/dts/ae350.dts | 177 ++++++++++++++++++++++++-----------------------
 1 file changed, 90 insertions(+), 87 deletions(-)

diff --git a/arch/riscv/dts/ae350.dts b/arch/riscv/dts/ae350.dts
index 2927e41..4717ae8 100644
--- a/arch/riscv/dts/ae350.dts
+++ b/arch/riscv/dts/ae350.dts
@@ -1,144 +1,147 @@
 /dts-v1/;
 
 / {
-  #address-cells = <2>;
-  #size-cells = <2>;
-  compatible = "andestech,ax25";
-  model = "andestech,ax25";
+	#address-cells = <2>;
+	#size-cells = <2>;
+	compatible = "andestech,ax25";
+	model = "andestech,ax25";
 
 	aliases {
 		uart0 = &serial0;
 		spi0 = &spi;
-	} ;
+	};
 
 	chosen {
 		bootargs = "console=ttyS0,38400n8 earlyprintk=uart8250-32bit,0xf0300000 debug loglevel=7";
 		stdout-path = "uart0:38400n8";
-  };
-
-  cpus {
-    #address-cells = <1>;
-    #size-cells = <0>;
-    timebase-frequency = <10000000>;
-    CPU0: cpu at 0 {
-      device_type = "cpu";
-      reg = <0>;
-      status = "okay";
-      compatible = "riscv";
-      riscv,isa = "rv64imafdc";
-      mmu-type = "riscv,sv39";
-      clock-frequency = <60000000>;
-      CPU0_intc: interrupt-controller {
-        #interrupt-cells = <1>;
-        interrupt-controller;
-        compatible = "riscv,cpu-intc";
-      };
-    };
+	};
+
+	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+		timebase-frequency = <10000000>;
+
+		CPU0: cpu at 0 {
+			device_type = "cpu";
+			reg = <0>;
+			status = "okay";
+			compatible = "riscv";
+			riscv,isa = "rv64imafdc";
+			mmu-type = "riscv,sv39";
+			clock-frequency = <60000000>;
+
+			CPU0_intc: interrupt-controller {
+				#interrupt-cells = <1>;
+				interrupt-controller;
+				compatible = "riscv,cpu-intc";
+			};
+		};
 	};
 
 	memory at 0 {
 		device_type = "memory";
-    reg = <0x0 0x00000000 0x0 0x40000000>;
+		reg = <0x0 0x00000000 0x0 0x40000000>;
 	};
 
-  soc {
-    #address-cells = <2>;
-    #size-cells = <2>;
-    compatible = "andestech,riscv-ae350-soc";
-    ranges;
+	soc {
+		#address-cells = <2>;
+		#size-cells = <2>;
+		compatible = "andestech,riscv-ae350-soc";
+		ranges;
 	};
 
-  plmt0 at e6000000 {
-    compatible = "riscv,plmt0";
-    interrupts-extended = <&CPU0_intc 7>;
-    reg = <0x0 0xe6000000 0x0 0x100000>;
-		};
+	plmt0 at e6000000 {
+		compatible = "riscv,plmt0";
+		interrupts-extended = <&CPU0_intc 7>;
+		reg = <0x0 0xe6000000 0x0 0x100000>;
+	};
 
-  plic0: interrupt-controller at e4000000 {
-    compatible = "riscv,plic0";
-    #address-cells = <2>;
-    #interrupt-cells = <2>;
-    interrupt-controller;
-    reg = <0x0 0xe4000000 0x0 0x2000000>;
-    riscv,ndev=<31>;
-    interrupts-extended = <&CPU0_intc 11 &CPU0_intc 9>;
+	plic0: interrupt-controller at e4000000 {
+		compatible = "riscv,plic0";
+		#address-cells = <2>;
+		#interrupt-cells = <2>;
+		interrupt-controller;
+		reg = <0x0 0xe4000000 0x0 0x2000000>;
+		riscv,ndev=<31>;
+		interrupts-extended = <&CPU0_intc 11 &CPU0_intc 9>;
 	};
 
-  plic1: interrupt-controller at e6400000 {
-    compatible = "riscv,plic1";
-    #address-cells = <2>;
-    #interrupt-cells = <2>;
+	plic1: interrupt-controller at e6400000 {
+		compatible = "riscv,plic1";
+		#address-cells = <2>;
+		#interrupt-cells = <2>;
 		interrupt-controller;
-    reg = <0x0 0xe6400000 0x0 0x400000>;
-    riscv,ndev=<1>;
-    interrupts-extended = <&CPU0_intc 3>;
-  };
+		reg = <0x0 0xe6400000 0x0 0x400000>;
+		riscv,ndev=<1>;
+		interrupts-extended = <&CPU0_intc 3>;
+	};
 
-  spiclk: virt_100mhz {
-    #clock-cells = <0>;
-    compatible = "fixed-clock";
-    clock-frequency = <100000000>;
-  };
+	spiclk: virt_100mhz {
+		#clock-cells = <0>;
+		compatible = "fixed-clock";
+		clock-frequency = <100000000>;
+	};
 
-  timer0: timer at f0400000 {
-    compatible = "andestech,atcpit100";
-    reg = <0x0 0xf0400000 0x0 0x1000>;
-    clock-frequency = <40000000>;
-    interrupts = <3 4>;
-    interrupt-parent = <&plic0>;
+	timer0: timer at f0400000 {
+		compatible = "andestech,atcpit100";
+		reg = <0x0 0xf0400000 0x0 0x1000>;
+		clock-frequency = <40000000>;
+		interrupts = <3 4>;
+		interrupt-parent = <&plic0>;
 	};
 
 	serial0: serial at f0300000 {
 		compatible = "andestech,uart16550", "ns16550a";
-    reg = <0x0 0xf0300000 0x0 0x1000>;
-    interrupts = <9 4>;
+		reg = <0x0 0xf0300000 0x0 0x1000>;
+		interrupts = <9 4>;
 		clock-frequency = <19660800>;
 		reg-shift = <2>;
 		reg-offset = <32>;
 		no-loopback-test = <1>;
-    interrupt-parent = <&plic0>;
+		interrupt-parent = <&plic0>;
 	};
 
 	mac0: mac at e0100000 {
 		compatible = "andestech,atmac100";
-    reg = <0x0 0xe0100000 0x0 0x1000>;
-    interrupts = <19 4>;
-    interrupt-parent = <&plic0>;
+		reg = <0x0 0xe0100000 0x0 0x1000>;
+		interrupts = <19 4>;
+		interrupt-parent = <&plic0>;
 	};
 
 	mmc0: mmc at f0e00000 {
-    compatible = "andestech,atfsdc010";
+		compatible = "andestech,atfsdc010";
 		max-frequency = <100000000>;
-    clock-freq-min-max = <400000 100000000>;
+		clock-freq-min-max = <400000 100000000>;
 		fifo-depth = <0x10>;
-    reg = <0x0 0xf0e00000 0x0 0x1000>;
-    interrupts = <18 4>;
+		reg = <0x0 0xf0e00000 0x0 0x1000>;
+		interrupts = <18 4>;
 		cap-sd-highspeed;
-    interrupt-parent = <&plic0>;
+		interrupt-parent = <&plic0>;
 	};
 
-  smc0: smc at e0400000 {
-    compatible = "andestech,atfsmc020";
-    reg = <0x0 0xe0400000 0x0 0x1000>;
-  };
+	smc0: smc at e0400000 {
+		compatible = "andestech,atfsmc020";
+		reg = <0x0 0xe0400000 0x0 0x1000>;
+	};
 
-  nor at 0,0 {
-    compatible = "cfi-flash";
-    reg = <0x0 0x88000000 0x0 0x1000>;
-    bank-width = <2>;
-    device-width = <1>;
-  };
+	nor at 0,0 {
+		compatible = "cfi-flash";
+		reg = <0x0 0x88000000 0x0 0x1000>;
+		bank-width = <2>;
+		device-width = <1>;
+	};
 
 	spi: spi at f0b00000 {
 		compatible = "andestech,atcspi200";
-    reg = <0x0 0xf0b00000 0x0 0x1000>;
+		reg = <0x0 0xf0b00000 0x0 0x1000>;
 		#address-cells = <1>;
 		#size-cells = <0>;
 		num-cs = <1>;
 		clocks = <&spiclk>;
 		interrupts = <3 4>;
-    interrupt-parent = <&plic0>;
-			flash at 0 {
+		interrupt-parent = <&plic0>;
+
+		flash at 0 {
 			compatible = "spi-flash";
 			spi-max-frequency = <50000000>;
 			reg = <0>;
-- 
2.7.4

[U-Boot] [PATCH 11/12] riscv: kconfig: Select DM and OF_CONTROL

[Bin Meng]

RISC-V is a pretty new architecture and should support DM and
OF_CONTROL by default.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
---

 arch/Kconfig                 | 3 +++
 configs/ax25-ae350_defconfig | 2 --
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/Kconfig b/arch/Kconfig
index 42c23b5..01330a4 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -62,6 +62,9 @@ config PPC
 config RISCV
 	bool "RISC-V architecture"
 	select SUPPORT_OF_CONTROL
+	select OF_CONTROL
+	select DM
+	imply CMD_DM
 
 config SANDBOX
 	bool "Sandbox"
diff --git a/configs/ax25-ae350_defconfig b/configs/ax25-ae350_defconfig
index a853c99..9a05eed 100644
--- a/configs/ax25-ae350_defconfig
+++ b/configs/ax25-ae350_defconfig
@@ -16,11 +16,9 @@ CONFIG_CMD_SF_TEST=y
 # CONFIG_CMD_SETEXPR is not set
 CONFIG_BOOTP_PREFER_SERVERIP=y
 CONFIG_CMD_CACHE=y
-CONFIG_OF_CONTROL=y
 CONFIG_OF_BOARD=y
 CONFIG_ENV_IS_IN_SPI_FLASH=y
 CONFIG_NET_RANDOM_ETHADDR=y
-CONFIG_DM=y
 CONFIG_CLK=y
 CONFIG_MMC=y
 CONFIG_DM_MMC=y
-- 
2.7.4

[U-Boot] [PATCH 12/12] riscv: Add QEMU virt board support

[Bin Meng]

This adds QEMU RISC-V 'virt' board target support, with the hope of
helping people easily test U-Boot on RISC-V.

The QEMU virt machine models a generic RISC-V virtual machine with
support for the VirtIO standard networking and block storage devices.
It has CLINT, PLIC, 16550A UART devices in addition to VirtIO and
it also uses device-tree to pass configuration information to guest
software. It implements RISC-V privileged architecture spec v1.10.

Both 32-bit and 64-bit builds are supported. Support is pretty much
preliminary, only booting to U-Boot shell with the UART driver on
a single core. Booting Linux is not supported yet.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>

---

 arch/riscv/Kconfig                      |  4 +++
 arch/riscv/cpu/qemu/Makefile            |  6 +++++
 arch/riscv/cpu/qemu/cpu.c               | 29 +++++++++++++++++++++
 arch/riscv/cpu/qemu/dram.c              | 17 ++++++++++++
 board/emulation/qemu-riscv/Kconfig      | 21 +++++++++++++++
 board/emulation/qemu-riscv/MAINTAINERS  |  7 +++++
 board/emulation/qemu-riscv/Makefile     |  5 ++++
 board/emulation/qemu-riscv/qemu-riscv.c | 23 +++++++++++++++++
 configs/qemu-riscv32_defconfig          | 10 +++++++
 configs/qemu-riscv64_defconfig          | 11 ++++++++
 doc/README.qemu-riscv                   | 46 +++++++++++++++++++++++++++++++++
 include/configs/qemu-riscv.h            | 21 +++++++++++++++
 12 files changed, 200 insertions(+)
 create mode 100644 arch/riscv/cpu/qemu/Makefile
 create mode 100644 arch/riscv/cpu/qemu/cpu.c
 create mode 100644 arch/riscv/cpu/qemu/dram.c
 create mode 100644 board/emulation/qemu-riscv/Kconfig
 create mode 100644 board/emulation/qemu-riscv/MAINTAINERS
 create mode 100644 board/emulation/qemu-riscv/Makefile
 create mode 100644 board/emulation/qemu-riscv/qemu-riscv.c
 create mode 100644 configs/qemu-riscv32_defconfig
 create mode 100644 configs/qemu-riscv64_defconfig
 create mode 100644 doc/README.qemu-riscv
 create mode 100644 include/configs/qemu-riscv.h

diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 49f87de..168ca3d 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -11,9 +11,13 @@ choice
 config TARGET_AX25_AE350
 	bool "Support ax25-ae350"
 
+config TARGET_QEMU_VIRT
+	bool "Support QEMU Virt Board"
+
 endchoice
 
 source "board/AndesTech/ax25-ae350/Kconfig"
+source "board/emulation/qemu-riscv/Kconfig"
 
 choice
 	prompt "CPU selection"
diff --git a/arch/riscv/cpu/qemu/Makefile b/arch/riscv/cpu/qemu/Makefile
new file mode 100644
index 0000000..258e462
--- /dev/null
+++ b/arch/riscv/cpu/qemu/Makefile
@@ -0,0 +1,6 @@
+# SPDX-License-Identifier: GPL-2.0+
+#
+# Copyright (C) 2018, Bin Meng <bmeng.cn@gmail.com>
+
+obj-y += dram.o
+obj-y += cpu.o
diff --git a/arch/riscv/cpu/qemu/cpu.c b/arch/riscv/cpu/qemu/cpu.c
new file mode 100644
index 0000000..a064639
--- /dev/null
+++ b/arch/riscv/cpu/qemu/cpu.c
@@ -0,0 +1,29 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2018, Bin Meng <bmeng.cn@gmail.com>
+ */
+
+#include <common.h>
+#include <command.h>
+
+/*
+ * cleanup_before_linux() is called just before we call linux
+ * it prepares the processor for linux
+ *
+ * we disable interrupt and caches.
+ */
+int cleanup_before_linux(void)
+{
+	disable_interrupts();
+
+	/* turn off I/D-cache */
+
+	return 0;
+}
+
+int do_reset(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
+{
+	printf("reset unsupported yet\n");
+
+	return 0;
+}
diff --git a/arch/riscv/cpu/qemu/dram.c b/arch/riscv/cpu/qemu/dram.c
new file mode 100644
index 0000000..84d87d2
--- /dev/null
+++ b/arch/riscv/cpu/qemu/dram.c
@@ -0,0 +1,17 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2018, Bin Meng <bmeng.cn@gmail.com>
+ */
+
+#include <common.h>
+#include <fdtdec.h>
+
+int dram_init(void)
+{
+	return fdtdec_setup_mem_size_base();
+}
+
+int dram_init_banksize(void)
+{
+	return fdtdec_setup_memory_banksize();
+}
diff --git a/board/emulation/qemu-riscv/Kconfig b/board/emulation/qemu-riscv/Kconfig
new file mode 100644
index 0000000..029f5efb
--- /dev/null
+++ b/board/emulation/qemu-riscv/Kconfig
@@ -0,0 +1,21 @@
+if TARGET_QEMU_VIRT
+
+config SYS_BOARD
+	default "qemu-riscv"
+
+config SYS_VENDOR
+	default "emulation"
+
+config SYS_CPU
+	default "qemu"
+
+config SYS_CONFIG_NAME
+	default "qemu-riscv"
+
+config SYS_TEXT_BASE
+	default 0x80000000
+
+config BOARD_SPECIFIC_OPTIONS # dummy
+	def_bool y
+
+endif
diff --git a/board/emulation/qemu-riscv/MAINTAINERS b/board/emulation/qemu-riscv/MAINTAINERS
new file mode 100644
index 0000000..3c6eb4f
--- /dev/null
+++ b/board/emulation/qemu-riscv/MAINTAINERS
@@ -0,0 +1,7 @@
+QEMU RISC-V 'VIRT' BOARD
+M:	Bin Meng <bmeng.cn@gmail.com>
+S:	Maintained
+F:	board/emulation/qemu-riscv/
+F:	include/configs/qemu-riscv.h
+F:	configs/qemu-riscv32_defconfig
+F:	configs/qemu-riscv64_defconfig
diff --git a/board/emulation/qemu-riscv/Makefile b/board/emulation/qemu-riscv/Makefile
new file mode 100644
index 0000000..3f29b90
--- /dev/null
+++ b/board/emulation/qemu-riscv/Makefile
@@ -0,0 +1,5 @@
+# SPDX-License-Identifier: GPL-2.0+
+#
+# Copyright (C) 2018, Bin Meng <bmeng.cn@gmail.com>
+
+obj-y	+= qemu-riscv.o
diff --git a/board/emulation/qemu-riscv/qemu-riscv.c b/board/emulation/qemu-riscv/qemu-riscv.c
new file mode 100644
index 0000000..041e716
--- /dev/null
+++ b/board/emulation/qemu-riscv/qemu-riscv.c
@@ -0,0 +1,23 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2018, Bin Meng <bmeng.cn@gmail.com>
+ */
+
+#include <common.h>
+#include <fdtdec.h>
+
+#define MROM_FDT_ADDR	0x1020
+
+int board_init(void)
+{
+	return 0;
+}
+
+void *board_fdt_blob_setup(void)
+{
+	/*
+	 * QEMU loads a generated DTB for us immediately
+	 * after the reset vectors in the MROM
+	 */
+	return (void *)MROM_FDT_ADDR;
+}
diff --git a/configs/qemu-riscv32_defconfig b/configs/qemu-riscv32_defconfig
new file mode 100644
index 0000000..cbd2c91
--- /dev/null
+++ b/configs/qemu-riscv32_defconfig
@@ -0,0 +1,10 @@
+CONFIG_RISCV=y
+CONFIG_TARGET_QEMU_VIRT=y
+CONFIG_NR_DRAM_BANKS=1
+CONFIG_BOOTDELAY=3
+CONFIG_DISPLAY_CPUINFO=y
+CONFIG_DISPLAY_BOARDINFO=y
+CONFIG_OF_BOARD=y
+CONFIG_DM_SERIAL=y
+CONFIG_SYS_NS16550=y
+CONFIG_TIMER=y
diff --git a/configs/qemu-riscv64_defconfig b/configs/qemu-riscv64_defconfig
new file mode 100644
index 0000000..af8b307
--- /dev/null
+++ b/configs/qemu-riscv64_defconfig
@@ -0,0 +1,11 @@
+CONFIG_RISCV=y
+CONFIG_TARGET_QEMU_VIRT=y
+CONFIG_CPU_RISCV_64=y
+CONFIG_NR_DRAM_BANKS=1
+CONFIG_BOOTDELAY=3
+CONFIG_DISPLAY_CPUINFO=y
+CONFIG_DISPLAY_BOARDINFO=y
+CONFIG_OF_BOARD=y
+CONFIG_DM_SERIAL=y
+CONFIG_SYS_NS16550=y
+CONFIG_TIMER=y
diff --git a/doc/README.qemu-riscv b/doc/README.qemu-riscv
new file mode 100644
index 0000000..e2e4804
--- /dev/null
+++ b/doc/README.qemu-riscv
@@ -0,0 +1,46 @@
+# SPDX-License-Identifier: GPL-2.0+
+#
+# Copyright (C) 2018, Bin Meng <bmeng.cn@gmail.com>
+
+U-Boot on QEMU's 'virt' machine on RISC-V
+=========================================
+
+QEMU for RISC-V supports a special 'virt' machine designed for emulation and
+virtualization purposes. This document describes how to run U-Boot under it.
+Both 32-bit 64-bit targets are supported.
+
+The QEMU virt machine models a generic RISC-V virtual machine with support for
+the VirtIO standard networking and block storage devices. It has CLINT, PLIC,
+16550A UART devices in addition to VirtIO and it also uses device-tree to pass
+configuration information to guest software. It implements RISC-V privileged
+architecture spec v1.10.
+
+Building U-Boot
+---------------
+Set the CROSS_COMPILE environment variable as usual, and run:
+
+- For 32-bit RISC-V:
+    make qemu-riscv32_defconfig
+    make
+
+- For 64-bit RISC-V:
+    make qemu-riscv64_defconfig
+    make
+
+Running U-Boot
+--------------
+The minimal QEMU command line to get U-Boot up and running is:
+
+- For 32-bit RISC-V:
+    qemu-system-riscv32 -nographic -machine virt -kernel u-boot
+
+- For 64-bit RISC-V:
+    qemu-system-riscv64 -nographic -machine virt -kernel u-boot
+
+The commands above create targets with 128MiB memory by default.
+A freely configurable amount of RAM can be created via the '-m'
+parameter. For example, '-m 2G' creates 2GiB memory for the target,
+and the memory node in the embedded DTB created by QEMU reflects
+the new setting.
+
+These have been tested in QEMU 3.0.0.
diff --git a/include/configs/qemu-riscv.h b/include/configs/qemu-riscv.h
new file mode 100644
index 0000000..d279c23
--- /dev/null
+++ b/include/configs/qemu-riscv.h
@@ -0,0 +1,21 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright (C) 2018, Bin Meng <bmeng.cn@gmail.com>
+ */
+
+#ifndef __CONFIG_H
+#define __CONFIG_H
+
+#include <linux/sizes.h>
+
+#define CONFIG_SYS_SDRAM_BASE		0x80000000
+#define CONFIG_SYS_INIT_SP_ADDR		(CONFIG_SYS_SDRAM_BASE + SZ_2M)
+
+#define CONFIG_SYS_LOAD_ADDR		(CONFIG_SYS_SDRAM_BASE + SZ_2M)
+
+#define CONFIG_SYS_MALLOC_LEN		SZ_8M
+
+/* Environment options */
+#define CONFIG_ENV_SIZE			SZ_4K
+
+#endif /* __CONFIG_H */
-- 
2.7.4

[U-Boot] [PATCH 12/12] riscv: Add QEMU virt board support

[Auer, Lukas]

On Thu, 2018-08-30 at 00:54 -0700, Bin Meng wrote:
> This adds QEMU RISC-V 'virt' board target support, with the hope of
> helping people easily test U-Boot on RISC-V.
> 
> The QEMU virt machine models a generic RISC-V virtual machine with
> support for the VirtIO standard networking and block storage devices.
> It has CLINT, PLIC, 16550A UART devices in addition to VirtIO and
> it also uses device-tree to pass configuration information to guest
> software. It implements RISC-V privileged architecture spec v1.10.
> 
> Both 32-bit and 64-bit builds are supported. Support is pretty much
> preliminary, only booting to U-Boot shell with the UART driver on
> a single core. Booting Linux is not supported yet.
> 

For your information and to avoid duplicate work, I am working on a
patch set that improves RISC-V support in u-boot. I am currently able
to boot Linux on a multi-core setup in QEMU, but they are not quite
ready to submit yet.

Thank you for your patches, it's great to see better support for RISC-V 
in u-boot! I will add a few comments based on what I have learned so
far from working with u-boot on RISC-V.

> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
> 
> ---
> 
>  arch/riscv/Kconfig                      |  4 +++
>  arch/riscv/cpu/qemu/Makefile            |  6 +++++
>  arch/riscv/cpu/qemu/cpu.c               | 29 +++++++++++++++++++++
>  arch/riscv/cpu/qemu/dram.c              | 17 ++++++++++++
>  board/emulation/qemu-riscv/Kconfig      | 21 +++++++++++++++
>  board/emulation/qemu-riscv/MAINTAINERS  |  7 +++++
>  board/emulation/qemu-riscv/Makefile     |  5 ++++
>  board/emulation/qemu-riscv/qemu-riscv.c | 23 +++++++++++++++++
>  configs/qemu-riscv32_defconfig          | 10 +++++++
>  configs/qemu-riscv64_defconfig          | 11 ++++++++
>  doc/README.qemu-riscv                   | 46
> +++++++++++++++++++++++++++++++++
>  include/configs/qemu-riscv.h            | 21 +++++++++++++++
>  12 files changed, 200 insertions(+)
>  create mode 100644 arch/riscv/cpu/qemu/Makefile
>  create mode 100644 arch/riscv/cpu/qemu/cpu.c
>  create mode 100644 arch/riscv/cpu/qemu/dram.c
>  create mode 100644 board/emulation/qemu-riscv/Kconfig
>  create mode 100644 board/emulation/qemu-riscv/MAINTAINERS
>  create mode 100644 board/emulation/qemu-riscv/Makefile
>  create mode 100644 board/emulation/qemu-riscv/qemu-riscv.c
>  create mode 100644 configs/qemu-riscv32_defconfig
>  create mode 100644 configs/qemu-riscv64_defconfig
>  create mode 100644 doc/README.qemu-riscv
>  create mode 100644 include/configs/qemu-riscv.h
> 
> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> index 49f87de..168ca3d 100644
> --- a/arch/riscv/Kconfig
> +++ b/arch/riscv/Kconfig
> @@ -11,9 +11,13 @@ choice
>  config TARGET_AX25_AE350
>  	bool "Support ax25-ae350"
>  
> +config TARGET_QEMU_VIRT
> +	bool "Support QEMU Virt Board"
> +
>  endchoice
>  
>  source "board/AndesTech/ax25-ae350/Kconfig"
> +source "board/emulation/qemu-riscv/Kconfig"
>  
>  choice
>  	prompt "CPU selection"
> diff --git a/arch/riscv/cpu/qemu/Makefile
> b/arch/riscv/cpu/qemu/Makefile
> new file mode 100644
> index 0000000..258e462
> --- /dev/null
> +++ b/arch/riscv/cpu/qemu/Makefile
> @@ -0,0 +1,6 @@
> +# SPDX-License-Identifier: GPL-2.0+
> +#
> +# Copyright (C) 2018, Bin Meng <bmeng.cn@gmail.com>
> +
> +obj-y += dram.o
> +obj-y += cpu.o
> diff --git a/arch/riscv/cpu/qemu/cpu.c b/arch/riscv/cpu/qemu/cpu.c
> new file mode 100644
> index 0000000..a064639
> --- /dev/null
> +++ b/arch/riscv/cpu/qemu/cpu.c
> @@ -0,0 +1,29 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2018, Bin Meng <bmeng.cn@gmail.com>
> + */
> +
> +#include <common.h>
> +#include <command.h>
> +
> +/*
> + * cleanup_before_linux() is called just before we call linux
> + * it prepares the processor for linux
> + *
> + * we disable interrupt and caches.
> + */
> +int cleanup_before_linux(void)
> +{
> +	disable_interrupts();
> +
> +	/* turn off I/D-cache */
> +
> +	return 0;
> +}
> +
> +int do_reset(cmd_tbl_t *cmdtp, int flag, int argc, char * const
> argv[])
> +{
> +	printf("reset unsupported yet\n");
> +
> +	return 0;
> +}

We don't have a reset method on any RISC-V board yet. Instead of adding
the same 'unsupported' message for each CPU variant it might make more
sense to add a generic do_reset function for all CPU variants to lib/,
similar to the one for ARM (arch/arm/lib/reset.c).

> diff --git a/arch/riscv/cpu/qemu/dram.c b/arch/riscv/cpu/qemu/dram.c
> new file mode 100644
> index 0000000..84d87d2
> --- /dev/null
> +++ b/arch/riscv/cpu/qemu/dram.c
> @@ -0,0 +1,17 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2018, Bin Meng <bmeng.cn@gmail.com>
> + */
> +
> +#include <common.h>
> +#include <fdtdec.h>
> +
> +int dram_init(void)
> +{
> +	return fdtdec_setup_mem_size_base();
> +}
> +
> +int dram_init_banksize(void)
> +{
> +	return fdtdec_setup_memory_banksize();
> +}
> diff --git a/board/emulation/qemu-riscv/Kconfig
> b/board/emulation/qemu-riscv/Kconfig
> new file mode 100644
> index 0000000..029f5efb
> --- /dev/null
> +++ b/board/emulation/qemu-riscv/Kconfig
> @@ -0,0 +1,21 @@
> +if TARGET_QEMU_VIRT
> +
> +config SYS_BOARD
> +	default "qemu-riscv"
> +
> +config SYS_VENDOR
> +	default "emulation"
> +
> +config SYS_CPU
> +	default "qemu"
> +
> +config SYS_CONFIG_NAME
> +	default "qemu-riscv"
> +
> +config SYS_TEXT_BASE
> +	default 0x80000000
> +
> +config BOARD_SPECIFIC_OPTIONS # dummy
> +	def_bool y
> +
> +endif
> diff --git a/board/emulation/qemu-riscv/MAINTAINERS
> b/board/emulation/qemu-riscv/MAINTAINERS
> new file mode 100644
> index 0000000..3c6eb4f
> --- /dev/null
> +++ b/board/emulation/qemu-riscv/MAINTAINERS
> @@ -0,0 +1,7 @@
> +QEMU RISC-V 'VIRT' BOARD
> +M:	Bin Meng <bmeng.cn@gmail.com>
> +S:	Maintained
> +F:	board/emulation/qemu-riscv/
> +F:	include/configs/qemu-riscv.h
> +F:	configs/qemu-riscv32_defconfig
> +F:	configs/qemu-riscv64_defconfig
> diff --git a/board/emulation/qemu-riscv/Makefile
> b/board/emulation/qemu-riscv/Makefile
> new file mode 100644
> index 0000000..3f29b90
> --- /dev/null
> +++ b/board/emulation/qemu-riscv/Makefile
> @@ -0,0 +1,5 @@
> +# SPDX-License-Identifier: GPL-2.0+
> +#
> +# Copyright (C) 2018, Bin Meng <bmeng.cn@gmail.com>
> +
> +obj-y	+= qemu-riscv.o
> diff --git a/board/emulation/qemu-riscv/qemu-riscv.c
> b/board/emulation/qemu-riscv/qemu-riscv.c
> new file mode 100644
> index 0000000..041e716
> --- /dev/null
> +++ b/board/emulation/qemu-riscv/qemu-riscv.c
> @@ -0,0 +1,23 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2018, Bin Meng <bmeng.cn@gmail.com>
> + */
> +
> +#include <common.h>
> +#include <fdtdec.h>
> +
> +#define MROM_FDT_ADDR	0x1020

This value is not specified anywhere, so it could change without prior
warning. The value is also passed in a1 by ROM. If you want I can
update the code to use this value when I submit my patches.

Thanks,
Lukas

> +
> +int board_init(void)
> +{
> +	return 0;
> +}
> +
> +void *board_fdt_blob_setup(void)
> +{
> +	/*
> +	 * QEMU loads a generated DTB for us immediately
> +	 * after the reset vectors in the MROM
> +	 */
> +	return (void *)MROM_FDT_ADDR;
> +}
> diff --git a/configs/qemu-riscv32_defconfig b/configs/qemu-
> riscv32_defconfig
> new file mode 100644
> index 0000000..cbd2c91
> --- /dev/null
> +++ b/configs/qemu-riscv32_defconfig
> @@ -0,0 +1,10 @@
> +CONFIG_RISCV=y
> +CONFIG_TARGET_QEMU_VIRT=y
> +CONFIG_NR_DRAM_BANKS=1
> +CONFIG_BOOTDELAY=3
> +CONFIG_DISPLAY_CPUINFO=y
> +CONFIG_DISPLAY_BOARDINFO=y
> +CONFIG_OF_BOARD=y
> +CONFIG_DM_SERIAL=y
> +CONFIG_SYS_NS16550=y
> +CONFIG_TIMER=y
> diff --git a/configs/qemu-riscv64_defconfig b/configs/qemu-
> riscv64_defconfig
> new file mode 100644
> index 0000000..af8b307
> --- /dev/null
> +++ b/configs/qemu-riscv64_defconfig
> @@ -0,0 +1,11 @@
> +CONFIG_RISCV=y
> +CONFIG_TARGET_QEMU_VIRT=y
> +CONFIG_CPU_RISCV_64=y
> +CONFIG_NR_DRAM_BANKS=1
> +CONFIG_BOOTDELAY=3
> +CONFIG_DISPLAY_CPUINFO=y
> +CONFIG_DISPLAY_BOARDINFO=y
> +CONFIG_OF_BOARD=y
> +CONFIG_DM_SERIAL=y
> +CONFIG_SYS_NS16550=y
> +CONFIG_TIMER=y
> diff --git a/doc/README.qemu-riscv b/doc/README.qemu-riscv
> new file mode 100644
> index 0000000..e2e4804
> --- /dev/null
> +++ b/doc/README.qemu-riscv
> @@ -0,0 +1,46 @@
> +# SPDX-License-Identifier: GPL-2.0+
> +#
> +# Copyright (C) 2018, Bin Meng <bmeng.cn@gmail.com>
> +
> +U-Boot on QEMU's 'virt' machine on RISC-V
> +=========================================
> +
> +QEMU for RISC-V supports a special 'virt' machine designed for
> emulation and
> +virtualization purposes. This document describes how to run U-Boot
> under it.
> +Both 32-bit 64-bit targets are supported.
> +
> +The QEMU virt machine models a generic RISC-V virtual machine with
> support for
> +the VirtIO standard networking and block storage devices. It has
> CLINT, PLIC,
> +16550A UART devices in addition to VirtIO and it also uses device-
> tree to pass
> +configuration information to guest software. It implements RISC-V
> privileged
> +architecture spec v1.10.
> +
> +Building U-Boot
> +---------------
> +Set the CROSS_COMPILE environment variable as usual, and run:
> +
> +- For 32-bit RISC-V:
> +    make qemu-riscv32_defconfig
> +    make
> +
> +- For 64-bit RISC-V:
> +    make qemu-riscv64_defconfig
> +    make
> +
> +Running U-Boot
> +--------------
> +The minimal QEMU command line to get U-Boot up and running is:
> +
> +- For 32-bit RISC-V:
> +    qemu-system-riscv32 -nographic -machine virt -kernel u-boot
> +
> +- For 64-bit RISC-V:
> +    qemu-system-riscv64 -nographic -machine virt -kernel u-boot
> +
> +The commands above create targets with 128MiB memory by default.
> +A freely configurable amount of RAM can be created via the '-m'
> +parameter. For example, '-m 2G' creates 2GiB memory for the target,
> +and the memory node in the embedded DTB created by QEMU reflects
> +the new setting.
> +
> +These have been tested in QEMU 3.0.0.
> diff --git a/include/configs/qemu-riscv.h b/include/configs/qemu-
> riscv.h
> new file mode 100644
> index 0000000..d279c23
> --- /dev/null
> +++ b/include/configs/qemu-riscv.h
> @@ -0,0 +1,21 @@
> +/* SPDX-License-Identifier: GPL-2.0+ */
> +/*
> + * Copyright (C) 2018, Bin Meng <bmeng.cn@gmail.com>
> + */
> +
> +#ifndef __CONFIG_H
> +#define __CONFIG_H
> +
> +#include <linux/sizes.h>
> +
> +#define CONFIG_SYS_SDRAM_BASE		0x80000000
> +#define CONFIG_SYS_INIT_SP_ADDR		(CONFIG_SYS_SDRAM_BASE
> + SZ_2M)
> +
> +#define CONFIG_SYS_LOAD_ADDR		(CONFIG_SYS_SDRAM_BASE + SZ_2M)
> +
> +#define CONFIG_SYS_MALLOC_LEN		SZ_8M
> +
> +/* Environment options */
> +#define CONFIG_ENV_SIZE			SZ_4K
> +
> +#endif /* __CONFIG_H */

[U-Boot] [PATCH 12/12] riscv: Add QEMU virt board support

[Bin Meng]

Hi Lukas,

On Tue, Sep 4, 2018 at 5:39 AM Auer, Lukas
<lukas.auer@aisec.fraunhofer.de> wrote:
>
> On Thu, 2018-08-30 at 00:54 -0700, Bin Meng wrote:
> > This adds QEMU RISC-V 'virt' board target support, with the hope of
> > helping people easily test U-Boot on RISC-V.
> >
> > The QEMU virt machine models a generic RISC-V virtual machine with
> > support for the VirtIO standard networking and block storage devices.
> > It has CLINT, PLIC, 16550A UART devices in addition to VirtIO and
> > it also uses device-tree to pass configuration information to guest
> > software. It implements RISC-V privileged architecture spec v1.10.
> >
> > Both 32-bit and 64-bit builds are supported. Support is pretty much
> > preliminary, only booting to U-Boot shell with the UART driver on
> > a single core. Booting Linux is not supported yet.
> >
>
> For your information and to avoid duplicate work, I am working on a
> patch set that improves RISC-V support in u-boot. I am currently able
> to boot Linux on a multi-core setup in QEMU, but they are not quite
> ready to submit yet.
>

This is great! My next step is to work on virtio driver support in
U-Boot as qemu-riscv virt machine has these devices but we don't have
corresponding drivers in U-Boot. Then I will try to boot Linux after
that. Good to hear you already boot Linux with qemu-riscv! Have you
already supported virtio drivers in your port? If yes, I will just
hold on and wait for your patch series :-)

> Thank you for your patches, it's great to see better support for RISC-V
> in u-boot! I will add a few comments based on what I have learned so
> far from working with u-boot on RISC-V.
>

It's a good start. RISC-V is pretty new and needs more developers :-)

> > Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
> >
> > ---
> >
> >  arch/riscv/Kconfig                      |  4 +++
> >  arch/riscv/cpu/qemu/Makefile            |  6 +++++
> >  arch/riscv/cpu/qemu/cpu.c               | 29 +++++++++++++++++++++
> >  arch/riscv/cpu/qemu/dram.c              | 17 ++++++++++++
> >  board/emulation/qemu-riscv/Kconfig      | 21 +++++++++++++++
> >  board/emulation/qemu-riscv/MAINTAINERS  |  7 +++++
> >  board/emulation/qemu-riscv/Makefile     |  5 ++++
> >  board/emulation/qemu-riscv/qemu-riscv.c | 23 +++++++++++++++++
> >  configs/qemu-riscv32_defconfig          | 10 +++++++
> >  configs/qemu-riscv64_defconfig          | 11 ++++++++
> >  doc/README.qemu-riscv                   | 46
> > +++++++++++++++++++++++++++++++++
> >  include/configs/qemu-riscv.h            | 21 +++++++++++++++
> >  12 files changed, 200 insertions(+)
> >  create mode 100644 arch/riscv/cpu/qemu/Makefile
> >  create mode 100644 arch/riscv/cpu/qemu/cpu.c
> >  create mode 100644 arch/riscv/cpu/qemu/dram.c
> >  create mode 100644 board/emulation/qemu-riscv/Kconfig
> >  create mode 100644 board/emulation/qemu-riscv/MAINTAINERS
> >  create mode 100644 board/emulation/qemu-riscv/Makefile
> >  create mode 100644 board/emulation/qemu-riscv/qemu-riscv.c
> >  create mode 100644 configs/qemu-riscv32_defconfig
> >  create mode 100644 configs/qemu-riscv64_defconfig
> >  create mode 100644 doc/README.qemu-riscv
> >  create mode 100644 include/configs/qemu-riscv.h
> >
> > diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> > index 49f87de..168ca3d 100644
> > --- a/arch/riscv/Kconfig
> > +++ b/arch/riscv/Kconfig
> > @@ -11,9 +11,13 @@ choice
> >  config TARGET_AX25_AE350
> >       bool "Support ax25-ae350"
> >
> > +config TARGET_QEMU_VIRT
> > +     bool "Support QEMU Virt Board"
> > +
> >  endchoice
> >
> >  source "board/AndesTech/ax25-ae350/Kconfig"
> > +source "board/emulation/qemu-riscv/Kconfig"
> >
> >  choice
> >       prompt "CPU selection"
> > diff --git a/arch/riscv/cpu/qemu/Makefile
> > b/arch/riscv/cpu/qemu/Makefile
> > new file mode 100644
> > index 0000000..258e462
> > --- /dev/null
> > +++ b/arch/riscv/cpu/qemu/Makefile
> > @@ -0,0 +1,6 @@
> > +# SPDX-License-Identifier: GPL-2.0+
> > +#
> > +# Copyright (C) 2018, Bin Meng <bmeng.cn@gmail.com>
> > +
> > +obj-y += dram.o
> > +obj-y += cpu.o
> > diff --git a/arch/riscv/cpu/qemu/cpu.c b/arch/riscv/cpu/qemu/cpu.c
> > new file mode 100644
> > index 0000000..a064639
> > --- /dev/null
> > +++ b/arch/riscv/cpu/qemu/cpu.c
> > @@ -0,0 +1,29 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * Copyright (C) 2018, Bin Meng <bmeng.cn@gmail.com>
> > + */
> > +
> > +#include <common.h>
> > +#include <command.h>
> > +
> > +/*
> > + * cleanup_before_linux() is called just before we call linux
> > + * it prepares the processor for linux
> > + *
> > + * we disable interrupt and caches.
> > + */
> > +int cleanup_before_linux(void)
> > +{
> > +     disable_interrupts();
> > +
> > +     /* turn off I/D-cache */
> > +
> > +     return 0;
> > +}
> > +
> > +int do_reset(cmd_tbl_t *cmdtp, int flag, int argc, char * const
> > argv[])
> > +{
> > +     printf("reset unsupported yet\n");
> > +
> > +     return 0;
> > +}
>
> We don't have a reset method on any RISC-V board yet. Instead of adding
> the same 'unsupported' message for each CPU variant it might make more
> sense to add a generic do_reset function for all CPU variants to lib/,
> similar to the one for ARM (arch/arm/lib/reset.c).
>

Agreed. I can address this in v2.

> > diff --git a/arch/riscv/cpu/qemu/dram.c b/arch/riscv/cpu/qemu/dram.c
> > new file mode 100644
> > index 0000000..84d87d2
> > --- /dev/null
> > +++ b/arch/riscv/cpu/qemu/dram.c
> > @@ -0,0 +1,17 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * Copyright (C) 2018, Bin Meng <bmeng.cn@gmail.com>
> > + */
> > +
> > +#include <common.h>
> > +#include <fdtdec.h>
> > +
> > +int dram_init(void)
> > +{
> > +     return fdtdec_setup_mem_size_base();
> > +}
> > +
> > +int dram_init_banksize(void)
> > +{
> > +     return fdtdec_setup_memory_banksize();
> > +}
> > diff --git a/board/emulation/qemu-riscv/Kconfig
> > b/board/emulation/qemu-riscv/Kconfig
> > new file mode 100644
> > index 0000000..029f5efb
> > --- /dev/null
> > +++ b/board/emulation/qemu-riscv/Kconfig
> > @@ -0,0 +1,21 @@
> > +if TARGET_QEMU_VIRT
> > +
> > +config SYS_BOARD
> > +     default "qemu-riscv"
> > +
> > +config SYS_VENDOR
> > +     default "emulation"
> > +
> > +config SYS_CPU
> > +     default "qemu"
> > +
> > +config SYS_CONFIG_NAME
> > +     default "qemu-riscv"
> > +
> > +config SYS_TEXT_BASE
> > +     default 0x80000000
> > +
> > +config BOARD_SPECIFIC_OPTIONS # dummy
> > +     def_bool y
> > +
> > +endif
> > diff --git a/board/emulation/qemu-riscv/MAINTAINERS
> > b/board/emulation/qemu-riscv/MAINTAINERS
> > new file mode 100644
> > index 0000000..3c6eb4f
> > --- /dev/null
> > +++ b/board/emulation/qemu-riscv/MAINTAINERS
> > @@ -0,0 +1,7 @@
> > +QEMU RISC-V 'VIRT' BOARD
> > +M:   Bin Meng <bmeng.cn@gmail.com>
> > +S:   Maintained
> > +F:   board/emulation/qemu-riscv/
> > +F:   include/configs/qemu-riscv.h
> > +F:   configs/qemu-riscv32_defconfig
> > +F:   configs/qemu-riscv64_defconfig
> > diff --git a/board/emulation/qemu-riscv/Makefile
> > b/board/emulation/qemu-riscv/Makefile
> > new file mode 100644
> > index 0000000..3f29b90
> > --- /dev/null
> > +++ b/board/emulation/qemu-riscv/Makefile
> > @@ -0,0 +1,5 @@
> > +# SPDX-License-Identifier: GPL-2.0+
> > +#
> > +# Copyright (C) 2018, Bin Meng <bmeng.cn@gmail.com>
> > +
> > +obj-y        += qemu-riscv.o
> > diff --git a/board/emulation/qemu-riscv/qemu-riscv.c
> > b/board/emulation/qemu-riscv/qemu-riscv.c
> > new file mode 100644
> > index 0000000..041e716
> > --- /dev/null
> > +++ b/board/emulation/qemu-riscv/qemu-riscv.c
> > @@ -0,0 +1,23 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * Copyright (C) 2018, Bin Meng <bmeng.cn@gmail.com>
> > + */
> > +
> > +#include <common.h>
> > +#include <fdtdec.h>
> > +
> > +#define MROM_FDT_ADDR        0x1020
>
> This value is not specified anywhere, so it could change without prior
> warning. The value is also passed in a1 by ROM. If you want I can
> update the code to use this value when I submit my patches.
>

Yes, it's not specified *explicitly* anywhere. I got this after
reading the code logic in QEMU's source codes :) I agree with you that
hardcode this is not good. I am OK to have your patch to update this.

[snip]

Regards,
Bin

[U-Boot] [PATCH 12/12] riscv: Add QEMU virt board support

[Auer, Lukas]

On Tue, 2018-09-04 at 17:31 +0800, Bin Meng wrote:
> Hi Lukas,
> 
> On Tue, Sep 4, 2018 at 5:39 AM Auer, Lukas
> <lukas.auer@aisec.fraunhofer.de> wrote:
> > 
> > On Thu, 2018-08-30 at 00:54 -0700, Bin Meng wrote:
> > > This adds QEMU RISC-V 'virt' board target support, with the hope
> > > of
> > > helping people easily test U-Boot on RISC-V.
> > > 
> > > The QEMU virt machine models a generic RISC-V virtual machine
> > > with
> > > support for the VirtIO standard networking and block storage
> > > devices.
> > > It has CLINT, PLIC, 16550A UART devices in addition to VirtIO and
> > > it also uses device-tree to pass configuration information to
> > > guest
> > > software. It implements RISC-V privileged architecture spec
> > > v1.10.
> > > 
> > > Both 32-bit and 64-bit builds are supported. Support is pretty
> > > much
> > > preliminary, only booting to U-Boot shell with the UART driver on
> > > a single core. Booting Linux is not supported yet.
> > > 
> > 
> > For your information and to avoid duplicate work, I am working on a
> > patch set that improves RISC-V support in u-boot. I am currently
> > able
> > to boot Linux on a multi-core setup in QEMU, but they are not quite
> > ready to submit yet.
> > 
> 
> This is great! My next step is to work on virtio driver support in
> U-Boot as qemu-riscv virt machine has these devices but we don't have
> corresponding drivers in U-Boot. Then I will try to boot Linux after
> that. Good to hear you already boot Linux with qemu-riscv! Have you
> already supported virtio drivers in your port? If yes, I will just
> hold on and wait for your patch series :-)
> 

Hi Bin,

Support for the virtio devices would be great! I don't support them in
my port, I can only boot a kernel image from RAM. 
I only have a driver for the clint0 (core local interrupt controller),
which I need for software interrupts to other cores and as a timer.
Software interrupts also work over the supervisor binary interface
(SBI), which allows u-boot to run in supervisor mode with bbl running
in machine mode to handle the SBI calls.

> > Thank you for your patches, it's great to see better support for
> > RISC-V
> > in u-boot! I will add a few comments based on what I have learned
> > so
> > far from working with u-boot on RISC-V.
> > 
> 
> It's a good start. RISC-V is pretty new and needs more developers :-)
> 

Exactly :)

Thanks,
Lukas

[U-Boot] [PATCH 12/12] riscv: Add QEMU virt board support

[Rick Chen]

 > > From: Auer, Lukas [mailto:lukas.auer at aisec.fraunhofer.de]
 > > Sent: Wednesday, September 05, 2018 5:53 AM
 > > To: bmeng.cn at gmail.com
 > > Cc: Rick Jian-Zhi Chen(陳建志); u-boot at lists.denx.de
 > > Subject: Re: [U-Boot] [PATCH 12/12] riscv: Add QEMU virt board support
 > >
 > > On Tue, 2018-09-04 at 17:31 +0800, Bin Meng wrote:
 > > > Hi Lukas,
 > > >
 > > > On Tue, Sep 4, 2018 at 5:39 AM Auer, Lukas
 > > > <lukas.auer@aisec.fraunhofer.de> wrote:
 > > > >
 > > > > On Thu, 2018-08-30 at 00:54 -0700, Bin Meng wrote:
 > > > > > This adds QEMU RISC-V 'virt' board target support, with the hope
 > > > > > of helping people easily test U-Boot on RISC-V.
 > > > > >
 > > > > > The QEMU virt machine models a generic RISC-V virtual machine
 > > > > > with support for the VirtIO standard networking and block
 > > > > > storage devices.
 > > > > > It has CLINT, PLIC, 16550A UART devices in addition to VirtIO
 > > > > > and it also uses device-tree to pass configuration information
 > > > > > to guest software. It implements RISC-V privileged architecture
 > > > > > spec v1.10.
 > > > > >
 > > > > > Both 32-bit and 64-bit builds are supported. Support is pretty
 > > > > > much preliminary, only booting to U-Boot shell with the UART
 > > > > > driver on a single core. Booting Linux is not supported yet.
 > > > > >
 > > > >
 > > > > For your information and to avoid duplicate work, I am working on
 > > > > a patch set that improves RISC-V support in u-boot. I am currently
 > > > > able to boot Linux on a multi-core setup in QEMU, but they are not
 > > > > quite ready to submit yet.
 > > > >
 > > >
 > > > This is great! My next step is to work on virtio driver support in
 > > > U-Boot as qemu-riscv virt machine has these devices but we don't
 > > > have corresponding drivers in U-Boot. Then I will try to boot Linux
 > > > after that. Good to hear you already boot Linux with qemu-riscv!
 > > > Have you already supported virtio drivers in your port? If yes, I
 > > > will just hold on and wait for your patch series :-)
 > > >
 > >
 > > Hi Bin,
 > >
 > > Support for the virtio devices would be great! I don't support them in
 > > my port, I can only boot a kernel image from RAM.
 > > I only have a driver for the clint0 (core local interrupt controller),
 > > which I need for software interrupts to other cores and as a timer.
 > > Software interrupts also work over the supervisor binary interface
 > > (SBI), which allows u-boot to run in supervisor mode with bbl running
 > > in machine mode to handle the SBI calls.
 > >

Hi Bin and Auer

I have already boot bbl run in S-mode and riscv-linux in M-mode via
u-boot from SD card or FLASH.
It mean after booting riscv-linux, u-boot will be dead. And no matter
about kernel.
Please refer to doc/README.ae350

May I figure out more clearly what are you going to do ?
What are you going to do is let u-boot run in S-mode and boot bbl and
riscv-linux in M-mode, right ?
It mean after booting bbl and riscv-linux, u-boot will still alive and
handle SBI calls and somethings in S-mode.

Or u-boot is going to replace the role of bbl ?

Rick



 > > > > Thank you for your patches, it's great to see better support for
 > > > > RISC-V in u-boot! I will add a few comments based on what I have
 > > > > learned so far from working with u-boot on RISC-V.
 > > > >
 > > >
 > > > It's a good start. RISC-V is pretty new and needs more developers
 > > > :-)
 > > >
 > >
 > > Exactly :)
 > >
 > > Thanks,
 > > Lukas

[U-Boot] [PATCH 12/12] riscv: Add QEMU virt board support

[Rick Chen]

Rick Chen <rickchen36@gmail.com> 於 2018年9月5日 週三 上午9:28寫道：
>
>  > > From: Auer, Lukas [mailto:lukas.auer at aisec.fraunhofer.de]
>  > > Sent: Wednesday, September 05, 2018 5:53 AM
>  > > To: bmeng.cn at gmail.com
>  > > Cc: Rick Jian-Zhi Chen(陳建志); u-boot at lists.denx.de
>  > > Subject: Re: [U-Boot] [PATCH 12/12] riscv: Add QEMU virt board support
>  > >
>  > > On Tue, 2018-09-04 at 17:31 +0800, Bin Meng wrote:
>  > > > Hi Lukas,
>  > > >
>  > > > On Tue, Sep 4, 2018 at 5:39 AM Auer, Lukas
>  > > > <lukas.auer@aisec.fraunhofer.de> wrote:
>  > > > >
>  > > > > On Thu, 2018-08-30 at 00:54 -0700, Bin Meng wrote:
>  > > > > > This adds QEMU RISC-V 'virt' board target support, with the hope
>  > > > > > of helping people easily test U-Boot on RISC-V.
>  > > > > >
>  > > > > > The QEMU virt machine models a generic RISC-V virtual machine
>  > > > > > with support for the VirtIO standard networking and block
>  > > > > > storage devices.
>  > > > > > It has CLINT, PLIC, 16550A UART devices in addition to VirtIO
>  > > > > > and it also uses device-tree to pass configuration information
>  > > > > > to guest software. It implements RISC-V privileged architecture
>  > > > > > spec v1.10.
>  > > > > >
>  > > > > > Both 32-bit and 64-bit builds are supported. Support is pretty
>  > > > > > much preliminary, only booting to U-Boot shell with the UART
>  > > > > > driver on a single core. Booting Linux is not supported yet.
>  > > > > >
>  > > > >
>  > > > > For your information and to avoid duplicate work, I am working on
>  > > > > a patch set that improves RISC-V support in u-boot. I am currently
>  > > > > able to boot Linux on a multi-core setup in QEMU, but they are not
>  > > > > quite ready to submit yet.
>  > > > >
>  > > >
>  > > > This is great! My next step is to work on virtio driver support in
>  > > > U-Boot as qemu-riscv virt machine has these devices but we don't
>  > > > have corresponding drivers in U-Boot. Then I will try to boot Linux
>  > > > after that. Good to hear you already boot Linux with qemu-riscv!
>  > > > Have you already supported virtio drivers in your port? If yes, I
>  > > > will just hold on and wait for your patch series :-)
>  > > >
>  > >
>  > > Hi Bin,
>  > >
>  > > Support for the virtio devices would be great! I don't support them in
>  > > my port, I can only boot a kernel image from RAM.
>  > > I only have a driver for the clint0 (core local interrupt controller),
>  > > which I need for software interrupts to other cores and as a timer.
>  > > Software interrupts also work over the supervisor binary interface
>  > > (SBI), which allows u-boot to run in supervisor mode with bbl running
>  > > in machine mode to handle the SBI calls.
>  > >
>
> Hi Bin and Auer
>
> I have already boot bbl run in S-mode and riscv-linux in M-mode via

Sorry ! Correct some descriptions about S-mode and M-mode
I have already boot bbl run in M-mode and riscv-linux in S-mode via
u-boot from SD card or FLASH.


> u-boot from SD card or FLASH.
> It mean after booting riscv-linux, u-boot will be dead. And no matter
> about kernel.
> Please refer to doc/README.ae350
>
> May I figure out more clearly what are you going to do ?
> What are you going to do is let u-boot run in S-mode and boot bbl and
> riscv-linux in M-mode, right ?
> It mean after booting bbl and riscv-linux, u-boot will still alive and
> handle SBI calls and somethings in S-mode.



>
> Or u-boot is going to replace the role of bbl ?
>
> Rick
>
>
>
>  > > > > Thank you for your patches, it's great to see better support for
>  > > > > RISC-V in u-boot! I will add a few comments based on what I have
>  > > > > learned so far from working with u-boot on RISC-V.
>  > > > >
>  > > >
>  > > > It's a good start. RISC-V is pretty new and needs more developers
>  > > > :-)
>  > > >
>  > >
>  > > Exactly :)
>  > >
>  > > Thanks,
>  > > Lukas

[U-Boot] [PATCH 12/12] riscv: Add QEMU virt board support

[Bin Meng]

Hi Rick,

On Wed, Sep 5, 2018 at 9:27 AM Rick Chen <rickchen36@gmail.com> wrote:
>
>  > > From: Auer, Lukas [mailto:lukas.auer at aisec.fraunhofer.de]
>  > > Sent: Wednesday, September 05, 2018 5:53 AM
>  > > To: bmeng.cn at gmail.com
>  > > Cc: Rick Jian-Zhi Chen(陳建志); u-boot at lists.denx.de
>  > > Subject: Re: [U-Boot] [PATCH 12/12] riscv: Add QEMU virt board support
>  > >
>  > > On Tue, 2018-09-04 at 17:31 +0800, Bin Meng wrote:
>  > > > Hi Lukas,
>  > > >
>  > > > On Tue, Sep 4, 2018 at 5:39 AM Auer, Lukas
>  > > > <lukas.auer@aisec.fraunhofer.de> wrote:
>  > > > >
>  > > > > On Thu, 2018-08-30 at 00:54 -0700, Bin Meng wrote:
>  > > > > > This adds QEMU RISC-V 'virt' board target support, with the hope
>  > > > > > of helping people easily test U-Boot on RISC-V.
>  > > > > >
>  > > > > > The QEMU virt machine models a generic RISC-V virtual machine
>  > > > > > with support for the VirtIO standard networking and block
>  > > > > > storage devices.
>  > > > > > It has CLINT, PLIC, 16550A UART devices in addition to VirtIO
>  > > > > > and it also uses device-tree to pass configuration information
>  > > > > > to guest software. It implements RISC-V privileged architecture
>  > > > > > spec v1.10.
>  > > > > >
>  > > > > > Both 32-bit and 64-bit builds are supported. Support is pretty
>  > > > > > much preliminary, only booting to U-Boot shell with the UART
>  > > > > > driver on a single core. Booting Linux is not supported yet.
>  > > > > >
>  > > > >
>  > > > > For your information and to avoid duplicate work, I am working on
>  > > > > a patch set that improves RISC-V support in u-boot. I am currently
>  > > > > able to boot Linux on a multi-core setup in QEMU, but they are not
>  > > > > quite ready to submit yet.
>  > > > >
>  > > >
>  > > > This is great! My next step is to work on virtio driver support in
>  > > > U-Boot as qemu-riscv virt machine has these devices but we don't
>  > > > have corresponding drivers in U-Boot. Then I will try to boot Linux
>  > > > after that. Good to hear you already boot Linux with qemu-riscv!
>  > > > Have you already supported virtio drivers in your port? If yes, I
>  > > > will just hold on and wait for your patch series :-)
>  > > >
>  > >
>  > > Hi Bin,
>  > >
>  > > Support for the virtio devices would be great! I don't support them in
>  > > my port, I can only boot a kernel image from RAM.
>  > > I only have a driver for the clint0 (core local interrupt controller),
>  > > which I need for software interrupts to other cores and as a timer.
>  > > Software interrupts also work over the supervisor binary interface
>  > > (SBI), which allows u-boot to run in supervisor mode with bbl running
>  > > in machine mode to handle the SBI calls.
>  > >
>
> Hi Bin and Auer
>
> I have already boot bbl run in S-mode and riscv-linux in M-mode via
> u-boot from SD card or FLASH.
> It mean after booting riscv-linux, u-boot will be dead. And no matter
> about kernel.
> Please refer to doc/README.ae350
>

Thanks for pointing out the doc for ae350. I just read it, and have
one question. There is a chapter in that doc "Boot bbl and riscv-linux
via U-Boot on QEMU", yet I don't see what QEMU command is invoked. Can
you please clarify? AFAIK mainline QEMU does not have support to ae350
board. Also there is no instructions on how bbl was built. Is that the
mainline bbl that can work on every riscv board? I doubt that.

> May I figure out more clearly what are you going to do ?
> What are you going to do is let u-boot run in S-mode and boot bbl and
> riscv-linux in M-mode, right ?

I want to use U-Boot to directly boot Linux, but seems Lukas is using
bbl for SBI implementation.

> It mean after booting bbl and riscv-linux, u-boot will still alive and
> handle SBI calls and somethings in S-mode.
>
> Or u-boot is going to replace the role of bbl ?
>

That's my plan. I don't see a need to use bbl which is quite feature limited.

Regards,
Bin

[U-Boot] [PATCH 12/12] riscv: Add QEMU virt board support

[Rick Chen]

Bin Meng <bmeng.cn@gmail.com> 於 2018年9月5日 週三 上午10:34寫道：
>
> Hi Rick,
>
> On Wed, Sep 5, 2018 at 9:27 AM Rick Chen <rickchen36@gmail.com> wrote:
> >
> >  > > From: Auer, Lukas [mailto:lukas.auer at aisec.fraunhofer.de]
> >  > > Sent: Wednesday, September 05, 2018 5:53 AM
> >  > > To: bmeng.cn at gmail.com
> >  > > Cc: Rick Jian-Zhi Chen(陳建志); u-boot at lists.denx.de
> >  > > Subject: Re: [U-Boot] [PATCH 12/12] riscv: Add QEMU virt board support
> >  > >
> >  > > On Tue, 2018-09-04 at 17:31 +0800, Bin Meng wrote:
> >  > > > Hi Lukas,
> >  > > >
> >  > > > On Tue, Sep 4, 2018 at 5:39 AM Auer, Lukas
> >  > > > <lukas.auer@aisec.fraunhofer.de> wrote:
> >  > > > >
> >  > > > > On Thu, 2018-08-30 at 00:54 -0700, Bin Meng wrote:
> >  > > > > > This adds QEMU RISC-V 'virt' board target support, with the hope
> >  > > > > > of helping people easily test U-Boot on RISC-V.
> >  > > > > >
> >  > > > > > The QEMU virt machine models a generic RISC-V virtual machine
> >  > > > > > with support for the VirtIO standard networking and block
> >  > > > > > storage devices.
> >  > > > > > It has CLINT, PLIC, 16550A UART devices in addition to VirtIO
> >  > > > > > and it also uses device-tree to pass configuration information
> >  > > > > > to guest software. It implements RISC-V privileged architecture
> >  > > > > > spec v1.10.
> >  > > > > >
> >  > > > > > Both 32-bit and 64-bit builds are supported. Support is pretty
> >  > > > > > much preliminary, only booting to U-Boot shell with the UART
> >  > > > > > driver on a single core. Booting Linux is not supported yet.
> >  > > > > >
> >  > > > >
> >  > > > > For your information and to avoid duplicate work, I am working on
> >  > > > > a patch set that improves RISC-V support in u-boot. I am currently
> >  > > > > able to boot Linux on a multi-core setup in QEMU, but they are not
> >  > > > > quite ready to submit yet.
> >  > > > >
> >  > > >
> >  > > > This is great! My next step is to work on virtio driver support in
> >  > > > U-Boot as qemu-riscv virt machine has these devices but we don't
> >  > > > have corresponding drivers in U-Boot. Then I will try to boot Linux
> >  > > > after that. Good to hear you already boot Linux with qemu-riscv!
> >  > > > Have you already supported virtio drivers in your port? If yes, I
> >  > > > will just hold on and wait for your patch series :-)
> >  > > >
> >  > >
> >  > > Hi Bin,
> >  > >
> >  > > Support for the virtio devices would be great! I don't support them in
> >  > > my port, I can only boot a kernel image from RAM.
> >  > > I only have a driver for the clint0 (core local interrupt controller),
> >  > > which I need for software interrupts to other cores and as a timer.
> >  > > Software interrupts also work over the supervisor binary interface
> >  > > (SBI), which allows u-boot to run in supervisor mode with bbl running
> >  > > in machine mode to handle the SBI calls.
> >  > >
> >
> > Hi Bin and Auer
> >
> > I have already boot bbl run in S-mode and riscv-linux in M-mode via
> > u-boot from SD card or FLASH.
> > It mean after booting riscv-linux, u-boot will be dead. And no matter
> > about kernel.
> > Please refer to doc/README.ae350
> >
>
> Thanks for pointing out the doc for ae350. I just read it, and have
> one question. There is a chapter in that doc "Boot bbl and riscv-linux
> via U-Boot on QEMU", yet I don't see what QEMU command is invoked. Can
> you please clarify? AFAIK mainline QEMU does not have support to ae350
> board. Also there is no instructions on how bbl was built. Is that the
> mainline bbl that can work on every riscv board? I doubt that.
>

There are some teammates who are responsible for bbl, riscv-linux,
u-boot, qemu individually.
As I know they just pull source from mainline and have relative hooks
for ax25-ae350.
I am in charge of booting kernel via u-boot.
And drivers (timer, serial, spi flash, smc flash, sd, mac, rtc,
wdt,i2c, sound, lcd) verification on u-boot and kernel.
That is why I am pending u-boot for a while.

When I finish booting riscv-linux via u-boot function. Then I have
pushed them to u-boot upstream.
And describe simply the build and run flow in doc/README.ae350.
As I know, the implementations about bbl and qemu still not been
pushed to upstream yet.
Maybe I can ask them how about the upstream schedule !

Hope this can answer your question !

> > May I figure out more clearly what are you going to do ?
> > What are you going to do is let u-boot run in S-mode and boot bbl and
> > riscv-linux in M-mode, right ?
>
> I want to use U-Boot to directly boot Linux, but seems Lukas is using
> bbl for SBI implementation.
>
> > It mean after booting bbl and riscv-linux, u-boot will still alive and
> > handle SBI calls and somethings in S-mode.
> >
> > Or u-boot is going to replace the role of bbl ?
> >
>
> That's my plan. I don't see a need to use bbl which is quite feature limited.
>

Sounds great !
Very looking forward to this achievement !

Rick

> Regards,
> Bin

[U-Boot] [PATCH 12/12] riscv: Add QEMU virt board support

[Auer, Lukas]

On Wed, 2018-09-05 at 10:34 +0800, Bin Meng wrote:
> Hi Rick,
> 
> On Wed, Sep 5, 2018 at 9:27 AM Rick Chen <rickchen36@gmail.com>
> wrote:
> > 
> >  > > From: Auer, Lukas [mailto:lukas.auer at aisec.fraunhofer.de]
> >  > > Sent: Wednesday, September 05, 2018 5:53 AM
> >  > > To: bmeng.cn at gmail.com
> >  > > Cc: Rick Jian-Zhi Chen(陳建志); u-boot at lists.denx.de
> >  > > Subject: Re: [U-Boot] [PATCH 12/12] riscv: Add QEMU virt board
> > support
> >  > >
> >  > > On Tue, 2018-09-04 at 17:31 +0800, Bin Meng wrote:
> >  > > > Hi Lukas,
> >  > > >
> >  > > > On Tue, Sep 4, 2018 at 5:39 AM Auer, Lukas
> >  > > > <lukas.auer@aisec.fraunhofer.de> wrote:
> >  > > > >
> >  > > > > On Thu, 2018-08-30 at 00:54 -0700, Bin Meng wrote:
> >  > > > > > This adds QEMU RISC-V 'virt' board target support, with
> > the hope
> >  > > > > > of helping people easily test U-Boot on RISC-V.
> >  > > > > >
> >  > > > > > The QEMU virt machine models a generic RISC-V virtual
> > machine
> >  > > > > > with support for the VirtIO standard networking and
> > block
> >  > > > > > storage devices.
> >  > > > > > It has CLINT, PLIC, 16550A UART devices in addition to
> > VirtIO
> >  > > > > > and it also uses device-tree to pass configuration
> > information
> >  > > > > > to guest software. It implements RISC-V privileged
> > architecture
> >  > > > > > spec v1.10.
> >  > > > > >
> >  > > > > > Both 32-bit and 64-bit builds are supported. Support is
> > pretty
> >  > > > > > much preliminary, only booting to U-Boot shell with the
> > UART
> >  > > > > > driver on a single core. Booting Linux is not supported
> > yet.
> >  > > > > >
> >  > > > >
> >  > > > > For your information and to avoid duplicate work, I am
> > working on
> >  > > > > a patch set that improves RISC-V support in u-boot. I am
> > currently
> >  > > > > able to boot Linux on a multi-core setup in QEMU, but they
> > are not
> >  > > > > quite ready to submit yet.
> >  > > > >
> >  > > >
> >  > > > This is great! My next step is to work on virtio driver
> > support in
> >  > > > U-Boot as qemu-riscv virt machine has these devices but we
> > don't
> >  > > > have corresponding drivers in U-Boot. Then I will try to
> > boot Linux
> >  > > > after that. Good to hear you already boot Linux with qemu-
> > riscv!
> >  > > > Have you already supported virtio drivers in your port? If
> > yes, I
> >  > > > will just hold on and wait for your patch series :-)
> >  > > >
> >  > >
> >  > > Hi Bin,
> >  > >
> >  > > Support for the virtio devices would be great! I don't support
> > them in
> >  > > my port, I can only boot a kernel image from RAM.
> >  > > I only have a driver for the clint0 (core local interrupt
> > controller),
> >  > > which I need for software interrupts to other cores and as a
> > timer.
> >  > > Software interrupts also work over the supervisor binary
> > interface
> >  > > (SBI), which allows u-boot to run in supervisor mode with bbl
> > running
> >  > > in machine mode to handle the SBI calls.
> >  > >
> > 
> > Hi Bin and Auer
> > 
> > I have already boot bbl run in S-mode and riscv-linux in M-mode via
> > u-boot from SD card or FLASH.
> > It mean after booting riscv-linux, u-boot will be dead. And no
> > matter
> > about kernel.
> > Please refer to doc/README.ae350
> > 
> 
> Thanks for pointing out the doc for ae350. I just read it, and have
> one question. There is a chapter in that doc "Boot bbl and riscv-
> linux
> via U-Boot on QEMU", yet I don't see what QEMU command is invoked.
> Can
> you please clarify? AFAIK mainline QEMU does not have support to
> ae350
> board. Also there is no instructions on how bbl was built. Is that
> the
> mainline bbl that can work on every riscv board? I doubt that.
> 
> > May I figure out more clearly what are you going to do ?
> > What are you going to do is let u-boot run in S-mode and boot bbl
> > and
> > riscv-linux in M-mode, right ?
> 
> I want to use U-Boot to directly boot Linux, but seems Lukas is using
> bbl for SBI implementation.
> 

Hi Bin,

I don't really need bbl to run u-boot. I use it for Linux, which
expects the SBI to be present.

> > It mean after booting bbl and riscv-linux, u-boot will still alive
> > and
> > handle SBI calls and somethings in S-mode.
> > 
> > Or u-boot is going to replace the role of bbl ?
> > 
> 
> That's my plan. I don't see a need to use bbl which is quite feature
> limited.
> 

That's a good idea! At the very least, all the device initialization in
bbl should be moved into u-boot.
I do think a bootloader-independent SBI implementation makes sense
though. That way all bootloaders can use the same implementation, which
should make adding new SBI calls easier.

Thanks,
Lukas

> Regards,
> Bin

[U-Boot] [PATCH 12/12] riscv: Add QEMU virt board support

[Bin Meng]

Hi Lukas,

On Wed, Sep 5, 2018 at 5:37 PM Auer, Lukas
<lukas.auer@aisec.fraunhofer.de> wrote:
>
> On Wed, 2018-09-05 at 10:34 +0800, Bin Meng wrote:
> > Hi Rick,
> >
> > On Wed, Sep 5, 2018 at 9:27 AM Rick Chen <rickchen36@gmail.com>
> > wrote:
> > >
> > >  > > From: Auer, Lukas [mailto:lukas.auer at aisec.fraunhofer.de]
> > >  > > Sent: Wednesday, September 05, 2018 5:53 AM
> > >  > > To: bmeng.cn at gmail.com
> > >  > > Cc: Rick Jian-Zhi Chen(陳建志); u-boot at lists.denx.de
> > >  > > Subject: Re: [U-Boot] [PATCH 12/12] riscv: Add QEMU virt board
> > > support
> > >  > >
> > >  > > On Tue, 2018-09-04 at 17:31 +0800, Bin Meng wrote:
> > >  > > > Hi Lukas,
> > >  > > >
> > >  > > > On Tue, Sep 4, 2018 at 5:39 AM Auer, Lukas
> > >  > > > <lukas.auer@aisec.fraunhofer.de> wrote:
> > >  > > > >
> > >  > > > > On Thu, 2018-08-30 at 00:54 -0700, Bin Meng wrote:
> > >  > > > > > This adds QEMU RISC-V 'virt' board target support, with
> > > the hope
> > >  > > > > > of helping people easily test U-Boot on RISC-V.
> > >  > > > > >
> > >  > > > > > The QEMU virt machine models a generic RISC-V virtual
> > > machine
> > >  > > > > > with support for the VirtIO standard networking and
> > > block
> > >  > > > > > storage devices.
> > >  > > > > > It has CLINT, PLIC, 16550A UART devices in addition to
> > > VirtIO
> > >  > > > > > and it also uses device-tree to pass configuration
> > > information
> > >  > > > > > to guest software. It implements RISC-V privileged
> > > architecture
> > >  > > > > > spec v1.10.
> > >  > > > > >
> > >  > > > > > Both 32-bit and 64-bit builds are supported. Support is
> > > pretty
> > >  > > > > > much preliminary, only booting to U-Boot shell with the
> > > UART
> > >  > > > > > driver on a single core. Booting Linux is not supported
> > > yet.
> > >  > > > > >
> > >  > > > >
> > >  > > > > For your information and to avoid duplicate work, I am
> > > working on
> > >  > > > > a patch set that improves RISC-V support in u-boot. I am
> > > currently
> > >  > > > > able to boot Linux on a multi-core setup in QEMU, but they
> > > are not
> > >  > > > > quite ready to submit yet.
> > >  > > > >
> > >  > > >
> > >  > > > This is great! My next step is to work on virtio driver
> > > support in
> > >  > > > U-Boot as qemu-riscv virt machine has these devices but we
> > > don't
> > >  > > > have corresponding drivers in U-Boot. Then I will try to
> > > boot Linux
> > >  > > > after that. Good to hear you already boot Linux with qemu-
> > > riscv!
> > >  > > > Have you already supported virtio drivers in your port? If
> > > yes, I
> > >  > > > will just hold on and wait for your patch series :-)
> > >  > > >
> > >  > >
> > >  > > Hi Bin,
> > >  > >
> > >  > > Support for the virtio devices would be great! I don't support
> > > them in
> > >  > > my port, I can only boot a kernel image from RAM.
> > >  > > I only have a driver for the clint0 (core local interrupt
> > > controller),
> > >  > > which I need for software interrupts to other cores and as a
> > > timer.
> > >  > > Software interrupts also work over the supervisor binary
> > > interface
> > >  > > (SBI), which allows u-boot to run in supervisor mode with bbl
> > > running
> > >  > > in machine mode to handle the SBI calls.
> > >  > >
> > >
> > > Hi Bin and Auer
> > >
> > > I have already boot bbl run in S-mode and riscv-linux in M-mode via
> > > u-boot from SD card or FLASH.
> > > It mean after booting riscv-linux, u-boot will be dead. And no
> > > matter
> > > about kernel.
> > > Please refer to doc/README.ae350
> > >
> >
> > Thanks for pointing out the doc for ae350. I just read it, and have
> > one question. There is a chapter in that doc "Boot bbl and riscv-
> > linux
> > via U-Boot on QEMU", yet I don't see what QEMU command is invoked.
> > Can
> > you please clarify? AFAIK mainline QEMU does not have support to
> > ae350
> > board. Also there is no instructions on how bbl was built. Is that
> > the
> > mainline bbl that can work on every riscv board? I doubt that.
> >
> > > May I figure out more clearly what are you going to do ?
> > > What are you going to do is let u-boot run in S-mode and boot bbl
> > > and
> > > riscv-linux in M-mode, right ?
> >
> > I want to use U-Boot to directly boot Linux, but seems Lukas is using
> > bbl for SBI implementation.
> >
>
> Hi Bin,
>
> I don't really need bbl to run u-boot. I use it for Linux, which
> expects the SBI to be present.
>
> > > It mean after booting bbl and riscv-linux, u-boot will still alive
> > > and
> > > handle SBI calls and somethings in S-mode.
> > >
> > > Or u-boot is going to replace the role of bbl ?
> > >
> >
> > That's my plan. I don't see a need to use bbl which is quite feature
> > limited.
> >
>
> That's a good idea! At the very least, all the device initialization in
> bbl should be moved into u-boot.
> I do think a bootloader-independent SBI implementation makes sense
> though. That way all bootloaders can use the same implementation, which
> should make adding new SBI calls easier.

But I doubt we can have a generic SBI implementation. At least the
console I/O SBI call can vary from board to board due to different
UART devices are used.

Regards,
Bin

[U-Boot] [PATCH 12/12] riscv: Add QEMU virt board support

[Auer, Lukas]

Hi Bin,

On Thu, 2018-09-06 at 11:15 +0800, Bin Meng wrote:
> Hi Lukas,
> 
> On Wed, Sep 5, 2018 at 5:37 PM Auer, Lukas
> <lukas.auer@aisec.fraunhofer.de> wrote:
> > 
> > On Wed, 2018-09-05 at 10:34 +0800, Bin Meng wrote:
> > > Hi Rick,
> > > 
> > > On Wed, Sep 5, 2018 at 9:27 AM Rick Chen <rickchen36@gmail.com>
> > > wrote:
> > > > 
> > > >  > > From: Auer, Lukas [mailto:lukas.auer at aisec.fraunhofer.de]
> > > >  > > Sent: Wednesday, September 05, 2018 5:53 AM
> > > >  > > To: bmeng.cn at gmail.com
> > > >  > > Cc: Rick Jian-Zhi Chen(陳建志); u-boot at lists.denx.de
> > > >  > > Subject: Re: [U-Boot] [PATCH 12/12] riscv: Add QEMU virt
> > > > board
> > > > support
> > > >  > >
> > > >  > > On Tue, 2018-09-04 at 17:31 +0800, Bin Meng wrote:
> > > >  > > > Hi Lukas,
> > > >  > > >
> > > >  > > > On Tue, Sep 4, 2018 at 5:39 AM Auer, Lukas
> > > >  > > > <lukas.auer@aisec.fraunhofer.de> wrote:
> > > >  > > > >
> > > >  > > > > On Thu, 2018-08-30 at 00:54 -0700, Bin Meng wrote:
> > > >  > > > > > This adds QEMU RISC-V 'virt' board target support,
> > > > with
> > > > the hope
> > > >  > > > > > of helping people easily test U-Boot on RISC-V.
> > > >  > > > > >
> > > >  > > > > > The QEMU virt machine models a generic RISC-V
> > > > virtual
> > > > machine
> > > >  > > > > > with support for the VirtIO standard networking and
> > > > block
> > > >  > > > > > storage devices.
> > > >  > > > > > It has CLINT, PLIC, 16550A UART devices in addition
> > > > to
> > > > VirtIO
> > > >  > > > > > and it also uses device-tree to pass configuration
> > > > information
> > > >  > > > > > to guest software. It implements RISC-V privileged
> > > > architecture
> > > >  > > > > > spec v1.10.
> > > >  > > > > >
> > > >  > > > > > Both 32-bit and 64-bit builds are supported. Support
> > > > is
> > > > pretty
> > > >  > > > > > much preliminary, only booting to U-Boot shell with
> > > > the
> > > > UART
> > > >  > > > > > driver on a single core. Booting Linux is not
> > > > supported
> > > > yet.
> > > >  > > > > >
> > > >  > > > >
> > > >  > > > > For your information and to avoid duplicate work, I am
> > > > working on
> > > >  > > > > a patch set that improves RISC-V support in u-boot. I
> > > > am
> > > > currently
> > > >  > > > > able to boot Linux on a multi-core setup in QEMU, but
> > > > they
> > > > are not
> > > >  > > > > quite ready to submit yet.
> > > >  > > > >
> > > >  > > >
> > > >  > > > This is great! My next step is to work on virtio driver
> > > > support in
> > > >  > > > U-Boot as qemu-riscv virt machine has these devices but
> > > > we
> > > > don't
> > > >  > > > have corresponding drivers in U-Boot. Then I will try to
> > > > boot Linux
> > > >  > > > after that. Good to hear you already boot Linux with
> > > > qemu-
> > > > riscv!
> > > >  > > > Have you already supported virtio drivers in your port?
> > > > If
> > > > yes, I
> > > >  > > > will just hold on and wait for your patch series :-)
> > > >  > > >
> > > >  > >
> > > >  > > Hi Bin,
> > > >  > >
> > > >  > > Support for the virtio devices would be great! I don't
> > > > support
> > > > them in
> > > >  > > my port, I can only boot a kernel image from RAM.
> > > >  > > I only have a driver for the clint0 (core local interrupt
> > > > controller),
> > > >  > > which I need for software interrupts to other cores and as
> > > > a
> > > > timer.
> > > >  > > Software interrupts also work over the supervisor binary
> > > > interface
> > > >  > > (SBI), which allows u-boot to run in supervisor mode with
> > > > bbl
> > > > running
> > > >  > > in machine mode to handle the SBI calls.
> > > >  > >
> > > > 
> > > > Hi Bin and Auer
> > > > 
> > > > I have already boot bbl run in S-mode and riscv-linux in M-mode 
> > > > via
> > > > u-boot from SD card or FLASH.
> > > > It mean after booting riscv-linux, u-boot will be dead. And no
> > > > matter
> > > > about kernel.
> > > > Please refer to doc/README.ae350
> > > > 
> > > 
> > > Thanks for pointing out the doc for ae350. I just read it, and
> > > have
> > > one question. There is a chapter in that doc "Boot bbl and riscv-
> > > linux
> > > via U-Boot on QEMU", yet I don't see what QEMU command is
> > > invoked.
> > > Can
> > > you please clarify? AFAIK mainline QEMU does not have support to
> > > ae350
> > > board. Also there is no instructions on how bbl was built. Is
> > > that
> > > the
> > > mainline bbl that can work on every riscv board? I doubt that.
> > > 
> > > > May I figure out more clearly what are you going to do ?
> > > > What are you going to do is let u-boot run in S-mode and boot
> > > > bbl
> > > > and
> > > > riscv-linux in M-mode, right ?
> > > 
> > > I want to use U-Boot to directly boot Linux, but seems Lukas is
> > > using
> > > bbl for SBI implementation.
> > > 
> > 
> > Hi Bin,
> > 
> > I don't really need bbl to run u-boot. I use it for Linux, which
> > expects the SBI to be present.
> > 
> > > > It mean after booting bbl and riscv-linux, u-boot will still
> > > > alive
> > > > and
> > > > handle SBI calls and somethings in S-mode.
> > > > 
> > > > Or u-boot is going to replace the role of bbl ?
> > > > 
> > > 
> > > That's my plan. I don't see a need to use bbl which is quite
> > > feature
> > > limited.
> > > 
> > 
> > That's a good idea! At the very least, all the device
> > initialization in
> > bbl should be moved into u-boot.
> > I do think a bootloader-independent SBI implementation makes sense
> > though. That way all bootloaders can use the same implementation,
> > which
> > should make adding new SBI calls easier.
> 
> But I doubt we can have a generic SBI implementation. At least the
> console I/O SBI call can vary from board to board due to different
> UART devices are used.
> 
> Regards,
> Bin

hm yes, you are right that wouldn't really work. At the same time,
console I/O in the SBI is probably not that important.
It would be good to have a proper specification for the SBI / machine
mode firmware. At the moment there is only the documentation on Github
[1]. As far as I know, the instruction emulation in bbl is also not
specified anywhere.

Thanks,
Lukas

[1]: https://github.com/riscv/riscv-sbi-doc/blob/master/riscv-sbi.md

[U-Boot] [PATCH 12/12] riscv: Add QEMU virt board support

[Auer, Lukas]

On Wed, 2018-09-05 at 09:28 +0800, Rick Chen wrote:
>  > > From: Auer, Lukas [mailto:lukas.auer at aisec.fraunhofer.de]
>  > > Sent: Wednesday, September 05, 2018 5:53 AM
>  > > To: bmeng.cn at gmail.com
>  > > Cc: Rick Jian-Zhi Chen(陳建志); u-boot at lists.denx.de
>  > > Subject: Re: [U-Boot] [PATCH 12/12] riscv: Add QEMU virt board
> support
>  > >
>  > > On Tue, 2018-09-04 at 17:31 +0800, Bin Meng wrote:
>  > > > Hi Lukas,
>  > > >
>  > > > On Tue, Sep 4, 2018 at 5:39 AM Auer, Lukas
>  > > > <lukas.auer@aisec.fraunhofer.de> wrote:
>  > > > >
>  > > > > On Thu, 2018-08-30 at 00:54 -0700, Bin Meng wrote:
>  > > > > > This adds QEMU RISC-V 'virt' board target support, with
> the hope
>  > > > > > of helping people easily test U-Boot on RISC-V.
>  > > > > >
>  > > > > > The QEMU virt machine models a generic RISC-V virtual
> machine
>  > > > > > with support for the VirtIO standard networking and block
>  > > > > > storage devices.
>  > > > > > It has CLINT, PLIC, 16550A UART devices in addition to
> VirtIO
>  > > > > > and it also uses device-tree to pass configuration
> information
>  > > > > > to guest software. It implements RISC-V privileged
> architecture
>  > > > > > spec v1.10.
>  > > > > >
>  > > > > > Both 32-bit and 64-bit builds are supported. Support is
> pretty
>  > > > > > much preliminary, only booting to U-Boot shell with the
> UART
>  > > > > > driver on a single core. Booting Linux is not supported
> yet.
>  > > > > >
>  > > > >
>  > > > > For your information and to avoid duplicate work, I am
> working on
>  > > > > a patch set that improves RISC-V support in u-boot. I am
> currently
>  > > > > able to boot Linux on a multi-core setup in QEMU, but they
> are not
>  > > > > quite ready to submit yet.
>  > > > >
>  > > >
>  > > > This is great! My next step is to work on virtio driver
> support in
>  > > > U-Boot as qemu-riscv virt machine has these devices but we
> don't
>  > > > have corresponding drivers in U-Boot. Then I will try to boot
> Linux
>  > > > after that. Good to hear you already boot Linux with qemu-
> riscv!
>  > > > Have you already supported virtio drivers in your port? If
> yes, I
>  > > > will just hold on and wait for your patch series :-)
>  > > >
>  > >
>  > > Hi Bin,
>  > >
>  > > Support for the virtio devices would be great! I don't support
> them in
>  > > my port, I can only boot a kernel image from RAM.
>  > > I only have a driver for the clint0 (core local interrupt
> controller),
>  > > which I need for software interrupts to other cores and as a
> timer.
>  > > Software interrupts also work over the supervisor binary
> interface
>  > > (SBI), which allows u-boot to run in supervisor mode with bbl
> running
>  > > in machine mode to handle the SBI calls.
>  > >
> 
> Hi Bin and Auer
> 
> I have already boot bbl run in S-mode and riscv-linux in M-mode via
> u-boot from SD card or FLASH.
> It mean after booting riscv-linux, u-boot will be dead. And no matter
> about kernel.
> Please refer to doc/README.ae350
> 
> May I figure out more clearly what are you going to do ?
> What are you going to do is let u-boot run in S-mode and boot bbl and
> riscv-linux in M-mode, right ?
> It mean after booting bbl and riscv-linux, u-boot will still alive
> and
> handle SBI calls and somethings in S-mode.
> 
> Or u-boot is going to replace the role of bbl ?
> 
> Rick
> 

Hi Rick,

Not exactly, my current boot flow is as follows.

1. u-boot SPL starts in machine mode and jumps to bbl
2. bbl starts u-boot proper in supervisor mode
3. u-boot boots the kernel

bbl is still active once Linux has booted and is used there for its SBI
implementation. Hope this helps.

Thanks,
Lukas

> 
> 
>  > > > > Thank you for your patches, it's great to see better support
> for
>  > > > > RISC-V in u-boot! I will add a few comments based on what I
> have
>  > > > > learned so far from working with u-boot on RISC-V.
>  > > > >
>  > > >
>  > > > It's a good start. RISC-V is pretty new and needs more
> developers
>  > > > :-)
>  > > >
>  > >
>  > > Exactly :)
>  > >
>  > > Thanks,
>  > > Lukas

[U-Boot] [PATCH 12/12] riscv: Add QEMU virt board support

[Bin Meng]

Hi Lukas,

On Wed, Sep 5, 2018 at 5:35 PM Auer, Lukas
<lukas.auer@aisec.fraunhofer.de> wrote:
>
> On Wed, 2018-09-05 at 09:28 +0800, Rick Chen wrote:
> >  > > From: Auer, Lukas [mailto:lukas.auer at aisec.fraunhofer.de]
> >  > > Sent: Wednesday, September 05, 2018 5:53 AM
> >  > > To: bmeng.cn at gmail.com
> >  > > Cc: Rick Jian-Zhi Chen(陳建志); u-boot at lists.denx.de
> >  > > Subject: Re: [U-Boot] [PATCH 12/12] riscv: Add QEMU virt board
> > support
> >  > >
> >  > > On Tue, 2018-09-04 at 17:31 +0800, Bin Meng wrote:
> >  > > > Hi Lukas,
> >  > > >
> >  > > > On Tue, Sep 4, 2018 at 5:39 AM Auer, Lukas
> >  > > > <lukas.auer@aisec.fraunhofer.de> wrote:
> >  > > > >
> >  > > > > On Thu, 2018-08-30 at 00:54 -0700, Bin Meng wrote:
> >  > > > > > This adds QEMU RISC-V 'virt' board target support, with
> > the hope
> >  > > > > > of helping people easily test U-Boot on RISC-V.
> >  > > > > >
> >  > > > > > The QEMU virt machine models a generic RISC-V virtual
> > machine
> >  > > > > > with support for the VirtIO standard networking and block
> >  > > > > > storage devices.
> >  > > > > > It has CLINT, PLIC, 16550A UART devices in addition to
> > VirtIO
> >  > > > > > and it also uses device-tree to pass configuration
> > information
> >  > > > > > to guest software. It implements RISC-V privileged
> > architecture
> >  > > > > > spec v1.10.
> >  > > > > >
> >  > > > > > Both 32-bit and 64-bit builds are supported. Support is
> > pretty
> >  > > > > > much preliminary, only booting to U-Boot shell with the
> > UART
> >  > > > > > driver on a single core. Booting Linux is not supported
> > yet.
> >  > > > > >
> >  > > > >
> >  > > > > For your information and to avoid duplicate work, I am
> > working on
> >  > > > > a patch set that improves RISC-V support in u-boot. I am
> > currently
> >  > > > > able to boot Linux on a multi-core setup in QEMU, but they
> > are not
> >  > > > > quite ready to submit yet.
> >  > > > >
> >  > > >
> >  > > > This is great! My next step is to work on virtio driver
> > support in
> >  > > > U-Boot as qemu-riscv virt machine has these devices but we
> > don't
> >  > > > have corresponding drivers in U-Boot. Then I will try to boot
> > Linux
> >  > > > after that. Good to hear you already boot Linux with qemu-
> > riscv!
> >  > > > Have you already supported virtio drivers in your port? If
> > yes, I
> >  > > > will just hold on and wait for your patch series :-)
> >  > > >
> >  > >
> >  > > Hi Bin,
> >  > >
> >  > > Support for the virtio devices would be great! I don't support
> > them in
> >  > > my port, I can only boot a kernel image from RAM.
> >  > > I only have a driver for the clint0 (core local interrupt
> > controller),
> >  > > which I need for software interrupts to other cores and as a
> > timer.
> >  > > Software interrupts also work over the supervisor binary
> > interface
> >  > > (SBI), which allows u-boot to run in supervisor mode with bbl
> > running
> >  > > in machine mode to handle the SBI calls.
> >  > >
> >
> > Hi Bin and Auer
> >
> > I have already boot bbl run in S-mode and riscv-linux in M-mode via
> > u-boot from SD card or FLASH.
> > It mean after booting riscv-linux, u-boot will be dead. And no matter
> > about kernel.
> > Please refer to doc/README.ae350
> >
> > May I figure out more clearly what are you going to do ?
> > What are you going to do is let u-boot run in S-mode and boot bbl and
> > riscv-linux in M-mode, right ?
> > It mean after booting bbl and riscv-linux, u-boot will still alive
> > and
> > handle SBI calls and somethings in S-mode.
> >
> > Or u-boot is going to replace the role of bbl ?
> >
> > Rick
> >
>
> Hi Rick,
>
> Not exactly, my current boot flow is as follows.
>
> 1. u-boot SPL starts in machine mode and jumps to bbl
> 2. bbl starts u-boot proper in supervisor mode
> 3. u-boot boots the kernel
>

If this is QEMU virt target, there is no need to boot from SPL then
U-Boot proper.

> bbl is still active once Linux has booted and is used there for its SBI
> implementation. Hope this helps.

Yes, I am not quite convinced why Linux kernel was designed this way.
This is something like x86's SMM or EFI runtime services...

Regards,
Bin

[U-Boot] [PATCH 12/12] riscv: Add QEMU virt board support

[Auer, Lukas]

Hi Bin,

On Thu, 2018-09-06 at 11:14 +0800, Bin Meng wrote:
> Hi Lukas,
> 
> On Wed, Sep 5, 2018 at 5:35 PM Auer, Lukas
> <lukas.auer@aisec.fraunhofer.de> wrote:
> > 
> > On Wed, 2018-09-05 at 09:28 +0800, Rick Chen wrote:
> > >  > > From: Auer, Lukas [mailto:lukas.auer at aisec.fraunhofer.de]
> > >  > > Sent: Wednesday, September 05, 2018 5:53 AM
> > >  > > To: bmeng.cn at gmail.com
> > >  > > Cc: Rick Jian-Zhi Chen(陳建志); u-boot at lists.denx.de
> > >  > > Subject: Re: [U-Boot] [PATCH 12/12] riscv: Add QEMU virt
> > > board
> > > support
> > >  > >
> > >  > > On Tue, 2018-09-04 at 17:31 +0800, Bin Meng wrote:
> > >  > > > Hi Lukas,
> > >  > > >
> > >  > > > On Tue, Sep 4, 2018 at 5:39 AM Auer, Lukas
> > >  > > > <lukas.auer@aisec.fraunhofer.de> wrote:
> > >  > > > >
> > >  > > > > On Thu, 2018-08-30 at 00:54 -0700, Bin Meng wrote:
> > >  > > > > > This adds QEMU RISC-V 'virt' board target support,
> > > with
> > > the hope
> > >  > > > > > of helping people easily test U-Boot on RISC-V.
> > >  > > > > >
> > >  > > > > > The QEMU virt machine models a generic RISC-V virtual
> > > machine
> > >  > > > > > with support for the VirtIO standard networking and
> > > block
> > >  > > > > > storage devices.
> > >  > > > > > It has CLINT, PLIC, 16550A UART devices in addition to
> > > VirtIO
> > >  > > > > > and it also uses device-tree to pass configuration
> > > information
> > >  > > > > > to guest software. It implements RISC-V privileged
> > > architecture
> > >  > > > > > spec v1.10.
> > >  > > > > >
> > >  > > > > > Both 32-bit and 64-bit builds are supported. Support
> > > is
> > > pretty
> > >  > > > > > much preliminary, only booting to U-Boot shell with
> > > the
> > > UART
> > >  > > > > > driver on a single core. Booting Linux is not
> > > supported
> > > yet.
> > >  > > > > >
> > >  > > > >
> > >  > > > > For your information and to avoid duplicate work, I am
> > > working on
> > >  > > > > a patch set that improves RISC-V support in u-boot. I am
> > > currently
> > >  > > > > able to boot Linux on a multi-core setup in QEMU, but
> > > they
> > > are not
> > >  > > > > quite ready to submit yet.
> > >  > > > >
> > >  > > >
> > >  > > > This is great! My next step is to work on virtio driver
> > > support in
> > >  > > > U-Boot as qemu-riscv virt machine has these devices but we
> > > don't
> > >  > > > have corresponding drivers in U-Boot. Then I will try to
> > > boot
> > > Linux
> > >  > > > after that. Good to hear you already boot Linux with qemu-
> > > riscv!
> > >  > > > Have you already supported virtio drivers in your port? If
> > > yes, I
> > >  > > > will just hold on and wait for your patch series :-)
> > >  > > >
> > >  > >
> > >  > > Hi Bin,
> > >  > >
> > >  > > Support for the virtio devices would be great! I don't
> > > support
> > > them in
> > >  > > my port, I can only boot a kernel image from RAM.
> > >  > > I only have a driver for the clint0 (core local interrupt
> > > controller),
> > >  > > which I need for software interrupts to other cores and as a
> > > timer.
> > >  > > Software interrupts also work over the supervisor binary
> > > interface
> > >  > > (SBI), which allows u-boot to run in supervisor mode with
> > > bbl
> > > running
> > >  > > in machine mode to handle the SBI calls.
> > >  > >
> > > 
> > > Hi Bin and Auer
> > > 
> > > I have already boot bbl run in S-mode and riscv-linux in M-mode
> > > via
> > > u-boot from SD card or FLASH.
> > > It mean after booting riscv-linux, u-boot will be dead. And no
> > > matter
> > > about kernel.
> > > Please refer to doc/README.ae350
> > > 
> > > May I figure out more clearly what are you going to do ?
> > > What are you going to do is let u-boot run in S-mode and boot bbl
> > > and
> > > riscv-linux in M-mode, right ?
> > > It mean after booting bbl and riscv-linux, u-boot will still
> > > alive
> > > and
> > > handle SBI calls and somethings in S-mode.
> > > 
> > > Or u-boot is going to replace the role of bbl ?
> > > 
> > > Rick
> > > 
> > 
> > Hi Rick,
> > 
> > Not exactly, my current boot flow is as follows.
> > 
> > 1. u-boot SPL starts in machine mode and jumps to bbl
> > 2. bbl starts u-boot proper in supervisor mode
> > 3. u-boot boots the kernel
> > 
> 
> If this is QEMU virt target, there is no need to boot from SPL then
> U-Boot proper.
> 

That's true. My goal was to load bbl without having to embed either  
u-boot or Linux in it. That boot flow is similar to armv8, where ARM
trusted firmware can be loaded by SPL.
With an SBI implementation in u-boot this is not required of course. I
think I'll simplify my boot flow for now and remove SPL. Either u-boot
or Linux must then be embedded into bbl until we have our own SBI
implementation.

Thanks,
Lukas

> > bbl is still active once Linux has booted and is used there for its
> > SBI
> > implementation. Hope this helps.
> 
> Yes, I am not quite convinced why Linux kernel was designed this way.
> This is something like x86's SMM or EFI runtime services...
> 
> Regards,
> Bin

[U-Boot] [PATCH 12/12] riscv: Add QEMU virt board support

[Tuomas Tynkkynen]

Hi Bin,

On 09/04/2018 12:31 PM, Bin Meng wrote:
> Hi Lukas,
> 
> On Tue, Sep 4, 2018 at 5:39 AM Auer, Lukas
> <lukas.auer@aisec.fraunhofer.de> wrote:
>>
>> On Thu, 2018-08-30 at 00:54 -0700, Bin Meng wrote:
>>> This adds QEMU RISC-V 'virt' board target support, with the hope of
>>> helping people easily test U-Boot on RISC-V.
>>>
>>> The QEMU virt machine models a generic RISC-V virtual machine with
>>> support for the VirtIO standard networking and block storage devices.
>>> It has CLINT, PLIC, 16550A UART devices in addition to VirtIO and
>>> it also uses device-tree to pass configuration information to guest
>>> software. It implements RISC-V privileged architecture spec v1.10.
>>>
>>> Both 32-bit and 64-bit builds are supported. Support is pretty much
>>> preliminary, only booting to U-Boot shell with the UART driver on
>>> a single core. Booting Linux is not supported yet.
>>>
>>
>> For your information and to avoid duplicate work, I am working on a
>> patch set that improves RISC-V support in u-boot. I am currently able
>> to boot Linux on a multi-core setup in QEMU, but they are not quite
>> ready to submit yet.
>>
> 
> This is great! My next step is to work on virtio driver support in
> U-Boot as qemu-riscv virt machine has these devices but we don't have
> corresponding drivers in U-Boot. 
At some point I was working on porting the virtio stack from Linux to
U-Boot and IIRC got virtio-blk and virtio-net working on ARM. But other
things consumed my time and I never quite finished that work. Let me
know if you want to take a look.

- Tuomas

[U-Boot] [PATCH 12/12] riscv: Add QEMU virt board support

[Bin Meng]

Hi Tuomas,

On Fri, Sep 7, 2018 at 5:03 AM Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi> wrote:
>
> Hi Bin,
>
> On 09/04/2018 12:31 PM, Bin Meng wrote:
> > Hi Lukas,
> >
> > On Tue, Sep 4, 2018 at 5:39 AM Auer, Lukas
> > <lukas.auer@aisec.fraunhofer.de> wrote:
> >>
> >> On Thu, 2018-08-30 at 00:54 -0700, Bin Meng wrote:
> >>> This adds QEMU RISC-V 'virt' board target support, with the hope of
> >>> helping people easily test U-Boot on RISC-V.
> >>>
> >>> The QEMU virt machine models a generic RISC-V virtual machine with
> >>> support for the VirtIO standard networking and block storage devices.
> >>> It has CLINT, PLIC, 16550A UART devices in addition to VirtIO and
> >>> it also uses device-tree to pass configuration information to guest
> >>> software. It implements RISC-V privileged architecture spec v1.10.
> >>>
> >>> Both 32-bit and 64-bit builds are supported. Support is pretty much
> >>> preliminary, only booting to U-Boot shell with the UART driver on
> >>> a single core. Booting Linux is not supported yet.
> >>>
> >>
> >> For your information and to avoid duplicate work, I am working on a
> >> patch set that improves RISC-V support in u-boot. I am currently able
> >> to boot Linux on a multi-core setup in QEMU, but they are not quite
> >> ready to submit yet.
> >>
> >
> > This is great! My next step is to work on virtio driver support in
> > U-Boot as qemu-riscv virt machine has these devices but we don't have
> > corresponding drivers in U-Boot.
> At some point I was working on porting the virtio stack from Linux to
> U-Boot and IIRC got virtio-blk and virtio-net working on ARM. But other
> things consumed my time and I never quite finished that work. Let me
> know if you want to take a look.

This is great. I just finished reading the virtio 1.0 spec and was
about to start the work. My interest was to add virtio-blk and
virtio-net driver to U-Boot too since they are most common devices
(others are not used too much I believe). If you already have the
drivers working, I can help to bring them upstream.

Regards,
Bin

[U-Boot] [PATCH 12/12] riscv: Add QEMU virt board support

[Tuomas Tynkkynen]

Hi Bin,

On Fri, 7 Sep 2018 09:49:24 +0800
Bin Meng <bmeng.cn@gmail.com> wrote:

> Hi Tuomas,
> 
> On Fri, Sep 7, 2018 at 5:03 AM Tuomas Tynkkynen
> <tuomas.tynkkynen@iki.fi> wrote:
> >
> > Hi Bin,
> >
> > On 09/04/2018 12:31 PM, Bin Meng wrote:  
> > > Hi Lukas,
> > >
> > > On Tue, Sep 4, 2018 at 5:39 AM Auer, Lukas
> > > <lukas.auer@aisec.fraunhofer.de> wrote:  
> > >>
> > >> On Thu, 2018-08-30 at 00:54 -0700, Bin Meng wrote:  
> > >>> This adds QEMU RISC-V 'virt' board target support, with the
> > >>> hope of helping people easily test U-Boot on RISC-V.
> > >>>
> > >>> The QEMU virt machine models a generic RISC-V virtual machine
> > >>> with support for the VirtIO standard networking and block
> > >>> storage devices. It has CLINT, PLIC, 16550A UART devices in
> > >>> addition to VirtIO and it also uses device-tree to pass
> > >>> configuration information to guest software. It implements
> > >>> RISC-V privileged architecture spec v1.10.
> > >>>
> > >>> Both 32-bit and 64-bit builds are supported. Support is pretty
> > >>> much preliminary, only booting to U-Boot shell with the UART
> > >>> driver on a single core. Booting Linux is not supported yet.
> > >>>  
> > >>
> > >> For your information and to avoid duplicate work, I am working
> > >> on a patch set that improves RISC-V support in u-boot. I am
> > >> currently able to boot Linux on a multi-core setup in QEMU, but
> > >> they are not quite ready to submit yet.
> > >>  
> > >
> > > This is great! My next step is to work on virtio driver support in
> > > U-Boot as qemu-riscv virt machine has these devices but we don't
> > > have corresponding drivers in U-Boot.  
> > At some point I was working on porting the virtio stack from Linux
> > to U-Boot and IIRC got virtio-blk and virtio-net working on ARM.
> > But other things consumed my time and I never quite finished that
> > work. Let me know if you want to take a look.  
> 
> This is great. I just finished reading the virtio 1.0 spec and was
> about to start the work. My interest was to add virtio-blk and
> virtio-net driver to U-Boot too since they are most common devices
> (others are not used too much I believe). If you already have the
> drivers working, I can help to bring them upstream.

You can find my branch here:

https://github.com/dezgeg/u-boot/tree/virtio

It should work under qemu_arm64_defconfig as follows:

qemu-system-aarch64 -machine virt -cpu cortex-a57 -m 512 \
  -bios u-boot.bin -s -nographic \
  -netdev user,id=net0 -device virtio-net-device,netdev=net0 \
  -drive if=none,file=disk.img,id=disk0 \
  -device virtio-blk-device,drive=disk0

I tried with Fedora-Server-netinst-aarch64-28-1.1.iso I had lying
around and letting it auto-boot worked fine.

Also interrupting the boot and doing 'virtio scan; dhcp' gets a
successful DHCP lease from QEMU's internal server.

I took a brief look and these things still need work:

- Some of the virtio headers imported verbatim cause compiler
  warnings because we don't disable strict aliasing.

- Architectures need to import various definitions from Linux.
  At least PAGE_SIZE & PAGE_SHIFT and wmb() & rmb().
  (currently there are just gross hacks around this)

- Feature negotiation (needed for virtio-net to be able to
  set/get a MAC address) is not implemented yet.

- The virtio-pci transport is not implemented, only virtio-mmio.

- Error handling is missing in many places.

- Resource cleanup in some places, like virtio-net which needs to
  remove live buffers from the RX virtqueue on shutdown and I haven't
  looked into how to do that.

- Lots of small things like removing debug/commented out code, wrong
  kerneldoc comments, dead/uneeded code etc. to be cleaned up.

Have fun and let me know if you have questions.

- Tuomas

[U-Boot] [PATCH 12/12] riscv: Add QEMU virt board support

[Bin Meng]

Hi Tuomas,

On Sat, Sep 8, 2018 at 7:14 AM Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi> wrote:
>
> Hi Bin,
>
> On Fri, 7 Sep 2018 09:49:24 +0800
> Bin Meng <bmeng.cn@gmail.com> wrote:
>
> > Hi Tuomas,
> >
> > On Fri, Sep 7, 2018 at 5:03 AM Tuomas Tynkkynen
> > <tuomas.tynkkynen@iki.fi> wrote:
> > >
> > > Hi Bin,
> > >
> > > On 09/04/2018 12:31 PM, Bin Meng wrote:
> > > > Hi Lukas,
> > > >
> > > > On Tue, Sep 4, 2018 at 5:39 AM Auer, Lukas
> > > > <lukas.auer@aisec.fraunhofer.de> wrote:
> > > >>
> > > >> On Thu, 2018-08-30 at 00:54 -0700, Bin Meng wrote:
> > > >>> This adds QEMU RISC-V 'virt' board target support, with the
> > > >>> hope of helping people easily test U-Boot on RISC-V.
> > > >>>
> > > >>> The QEMU virt machine models a generic RISC-V virtual machine
> > > >>> with support for the VirtIO standard networking and block
> > > >>> storage devices. It has CLINT, PLIC, 16550A UART devices in
> > > >>> addition to VirtIO and it also uses device-tree to pass
> > > >>> configuration information to guest software. It implements
> > > >>> RISC-V privileged architecture spec v1.10.
> > > >>>
> > > >>> Both 32-bit and 64-bit builds are supported. Support is pretty
> > > >>> much preliminary, only booting to U-Boot shell with the UART
> > > >>> driver on a single core. Booting Linux is not supported yet.
> > > >>>
> > > >>
> > > >> For your information and to avoid duplicate work, I am working
> > > >> on a patch set that improves RISC-V support in u-boot. I am
> > > >> currently able to boot Linux on a multi-core setup in QEMU, but
> > > >> they are not quite ready to submit yet.
> > > >>
> > > >
> > > > This is great! My next step is to work on virtio driver support in
> > > > U-Boot as qemu-riscv virt machine has these devices but we don't
> > > > have corresponding drivers in U-Boot.
> > > At some point I was working on porting the virtio stack from Linux
> > > to U-Boot and IIRC got virtio-blk and virtio-net working on ARM.
> > > But other things consumed my time and I never quite finished that
> > > work. Let me know if you want to take a look.
> >
> > This is great. I just finished reading the virtio 1.0 spec and was
> > about to start the work. My interest was to add virtio-blk and
> > virtio-net driver to U-Boot too since they are most common devices
> > (others are not used too much I believe). If you already have the
> > drivers working, I can help to bring them upstream.
>
> You can find my branch here:
>
> https://github.com/dezgeg/u-boot/tree/virtio
>
> It should work under qemu_arm64_defconfig as follows:
>
> qemu-system-aarch64 -machine virt -cpu cortex-a57 -m 512 \
>   -bios u-boot.bin -s -nographic \
>   -netdev user,id=net0 -device virtio-net-device,netdev=net0 \
>   -drive if=none,file=disk.img,id=disk0 \
>   -device virtio-blk-device,drive=disk0
>
> I tried with Fedora-Server-netinst-aarch64-28-1.1.iso I had lying
> around and letting it auto-boot worked fine.
>
> Also interrupting the boot and doing 'virtio scan; dhcp' gets a
> successful DHCP lease from QEMU's internal server.
>

Thank you for sharing your WIP. I just did a quick look and it seems
that you implemented the virtio uclass in a similar way like pci
uclass. My implementation is slightly different. I don't introduce
VIRTIO_GENERIC device and a complex driver matching logci like PCI. I
just did simple driver matching based on virtio device id. I wrote
some skeleton drivers to verify this can work with both virtio-mmio
and virtio-pci devices.

> I took a brief look and these things still need work:
>
> - Some of the virtio headers imported verbatim cause compiler
>   warnings because we don't disable strict aliasing.
>
> - Architectures need to import various definitions from Linux.
>   At least PAGE_SIZE & PAGE_SHIFT and wmb() & rmb().
>   (currently there are just gross hacks around this)
>
> - Feature negotiation (needed for virtio-net to be able to
>   set/get a MAC address) is not implemented yet.
>
> - The virtio-pci transport is not implemented, only virtio-mmio.
>
> - Error handling is missing in many places.
>
> - Resource cleanup in some places, like virtio-net which needs to
>   remove live buffers from the RX virtqueue on shutdown and I haven't
>   looked into how to do that.
>
> - Lots of small things like removing debug/commented out code, wrong
>   kerneldoc comments, dead/uneeded code etc. to be cleaned up.
>
> Have fun and let me know if you have questions.
>

Thanks for all these details! I will try integrating some of your WIP
with mine. I think I can directly use the virtio-blk and virtio-net
drivers from your tree as a start.

Regards,
Bin

[U-Boot] [PATCH 12/12] riscv: Add QEMU virt board support

[Tuomas Tynkkynen]

On 09/08/2018 04:28 AM, Bin Meng wrote:
> Hi Tuomas,
> 
> On Sat, Sep 8, 2018 at 7:14 AM Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi> wrote:
[...]
>>
>> You can find my branch here:
>>
>> https://github.com/dezgeg/u-boot/tree/virtio
>>
>> It should work under qemu_arm64_defconfig as follows:
>>
>> qemu-system-aarch64 -machine virt -cpu cortex-a57 -m 512 \
>>    -bios u-boot.bin -s -nographic \
>>    -netdev user,id=net0 -device virtio-net-device,netdev=net0 \
>>    -drive if=none,file=disk.img,id=disk0 \
>>    -device virtio-blk-device,drive=disk0
>>
>> I tried with Fedora-Server-netinst-aarch64-28-1.1.iso I had lying
>> around and letting it auto-boot worked fine.
>>
>> Also interrupting the boot and doing 'virtio scan; dhcp' gets a
>> successful DHCP lease from QEMU's internal server.
>>
> 
> Thank you for sharing your WIP. I just did a quick look and it seems
> that you implemented the virtio uclass in a similar way like pci
> uclass. My implementation is slightly different. I don't introduce
> VIRTIO_GENERIC device and a complex driver matching logci like PCI. I

Yeah, VIRTIO_GENERIC ended up looking quite weird. It's not even used
normally, e.g. virtio-net doesn't end up using it at all:

=> dm tree
  Class    index  Probed  Driver      Name
-----------------------------------------
  virtio      31  [ + ]   virtio_mmi  |-- virtio_mmio at a003e00
  eth          1  [ + ]   virtio_net  |   `-- virtio_net

It does get used for virtio-blk though:

  virtio      30  [ + ]   virtio_mmi  |-- virtio_mmio at a003c00
  virtio_gen   0  [ + ]   virtio_blk  |   `-- virtio_blk
  blk          0  [ + ]   virtblk     |       `-- virtio_blk.blk

But that is only because I couldn't make the block device (i.e.
the one with UCLASS_BLK) without introducing some device in the
middle. All of the functions like blk_create_device() seem to be
designed for the use cases of say, an AHCI controller having
multiple SATA ports or an SCSI device having multiple LUNs.

I guess the right thing to do would be to split blk_create_device()
so that it would be possible to have a tree like this:

  virtio      30  [ + ]   virtio_mmi  |-- virtio_mmio at a003c00
  blk          0  [ + ]   virtio_blk  |   `-- virtio_blk

Then the need for UCLASS_VIRTIO_GENERIC would go away.

> just did simple driver matching based on virtio device id. I wrote
> some skeleton drivers to verify this can work with both virtio-mmio
> and virtio-pci devices.
> 
>> I took a brief look and these things still need work:
>>
>> - Some of the virtio headers imported verbatim cause compiler
>>    warnings because we don't disable strict aliasing.
>>
>> - Architectures need to import various definitions from Linux.
>>    At least PAGE_SIZE & PAGE_SHIFT and wmb() & rmb().
>>    (currently there are just gross hacks around this)
>>
>> - Feature negotiation (needed for virtio-net to be able to
>>    set/get a MAC address) is not implemented yet.
>>
>> - The virtio-pci transport is not implemented, only virtio-mmio.
>>
>> - Error handling is missing in many places.
>>
>> - Resource cleanup in some places, like virtio-net which needs to
>>    remove live buffers from the RX virtqueue on shutdown and I haven't
>>    looked into how to do that.
>>
>> - Lots of small things like removing debug/commented out code, wrong
>>    kerneldoc comments, dead/uneeded code etc. to be cleaned up.
>>
>> Have fun and let me know if you have questions.
>>
> 
> Thanks for all these details! I will try integrating some of your WIP
> with mine. I think I can directly use the virtio-blk and virtio-net
> drivers from your tree as a start.
> 
> Regards,
> Bin
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> https://lists.denx.de/listinfo/u-boot
> 

[U-Boot] [PATCH 12/12] riscv: Add QEMU virt board support

[Bin Meng]

Hi Tuomas,

On Mon, Sep 10, 2018 at 8:16 AM Tuomas Tynkkynen
<tuomas.tynkkynen@iki.fi> wrote:
>
> On 09/08/2018 04:28 AM, Bin Meng wrote:
> > Hi Tuomas,
> >
> > On Sat, Sep 8, 2018 at 7:14 AM Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi> wrote:
> [...]
> >>
> >> You can find my branch here:
> >>
> >> https://github.com/dezgeg/u-boot/tree/virtio
> >>
> >> It should work under qemu_arm64_defconfig as follows:
> >>
> >> qemu-system-aarch64 -machine virt -cpu cortex-a57 -m 512 \
> >>    -bios u-boot.bin -s -nographic \
> >>    -netdev user,id=net0 -device virtio-net-device,netdev=net0 \
> >>    -drive if=none,file=disk.img,id=disk0 \
> >>    -device virtio-blk-device,drive=disk0
> >>
> >> I tried with Fedora-Server-netinst-aarch64-28-1.1.iso I had lying
> >> around and letting it auto-boot worked fine.
> >>
> >> Also interrupting the boot and doing 'virtio scan; dhcp' gets a
> >> successful DHCP lease from QEMU's internal server.
> >>
> >
> > Thank you for sharing your WIP. I just did a quick look and it seems
> > that you implemented the virtio uclass in a similar way like pci
> > uclass. My implementation is slightly different. I don't introduce
> > VIRTIO_GENERIC device and a complex driver matching logci like PCI. I
>
> Yeah, VIRTIO_GENERIC ended up looking quite weird. It's not even used
> normally, e.g. virtio-net doesn't end up using it at all:
>
> => dm tree
>   Class    index  Probed  Driver      Name
> -----------------------------------------
>   virtio      31  [ + ]   virtio_mmi  |-- virtio_mmio at a003e00
>   eth          1  [ + ]   virtio_net  |   `-- virtio_net
>
> It does get used for virtio-blk though:
>
>   virtio      30  [ + ]   virtio_mmi  |-- virtio_mmio at a003c00
>   virtio_gen   0  [ + ]   virtio_blk  |   `-- virtio_blk
>   blk          0  [ + ]   virtblk     |       `-- virtio_blk.blk
>
> But that is only because I couldn't make the block device (i.e.
> the one with UCLASS_BLK) without introducing some device in the
> middle. All of the functions like blk_create_device() seem to be
> designed for the use cases of say, an AHCI controller having
> multiple SATA ports or an SCSI device having multiple LUNs.
>
> I guess the right thing to do would be to split blk_create_device()
> so that it would be possible to have a tree like this:
>
>   virtio      30  [ + ]   virtio_mmi  |-- virtio_mmio at a003c00
>   blk          0  [ + ]   virtio_blk  |   `-- virtio_blk
>
> Then the need for UCLASS_VIRTIO_GENERIC would go away.

I used another way to do this, by not calling blk_create_device API
and some other changes. I now get the virtio-blk driver working with
my uclass implementation. Stay tuned :)

>
> > just did simple driver matching based on virtio device id. I wrote
> > some skeleton drivers to verify this can work with both virtio-mmio
> > and virtio-pci devices.
> >
> >> I took a brief look and these things still need work:
> >>
> >> - Some of the virtio headers imported verbatim cause compiler
> >>    warnings because we don't disable strict aliasing.
> >>
> >> - Architectures need to import various definitions from Linux.
> >>    At least PAGE_SIZE & PAGE_SHIFT and wmb() & rmb().
> >>    (currently there are just gross hacks around this)
> >>
> >> - Feature negotiation (needed for virtio-net to be able to
> >>    set/get a MAC address) is not implemented yet.
> >>
> >> - The virtio-pci transport is not implemented, only virtio-mmio.
> >>
> >> - Error handling is missing in many places.
> >>
> >> - Resource cleanup in some places, like virtio-net which needs to
> >>    remove live buffers from the RX virtqueue on shutdown and I haven't
> >>    looked into how to do that.
> >>
> >> - Lots of small things like removing debug/commented out code, wrong
> >>    kerneldoc comments, dead/uneeded code etc. to be cleaned up.
> >>
> >> Have fun and let me know if you have questions.
> >>
> >
> > Thanks for all these details! I will try integrating some of your WIP
> > with mine. I think I can directly use the virtio-blk and virtio-net
> > drivers from your tree as a start.

Regards,
Bin

[U-Boot] [PATCH 00/12] riscv: Add QEMU virt board support

[Rick Chen]

 > From: Bin Meng [mailto:bmeng.cn at gmail.com]
 > Sent: Thursday, August 30, 2018 3:54 PM
 > To: Rick Jian-Zhi Chen(陳建志); U-Boot Mailing List
 > Subject: [PATCH 00/12] riscv: Add QEMU virt board support
 >
 > This series adds QEMU RISC-V 'virt' board target support, with the hope of
 > helping people easily test U-Boot on RISC-V.
 >
 > Some existing RISC-V codes have been changed to make it easily to support new
 > targets. Some spotted coding style issues are fixed.
 >
 > This series is available at u-boot-x86/riscv-working for testing.
 >
 >
 > Bin Meng (12):
 >   riscv: kconfig: Normalize architecture name spelling
 >   riscv: Remove setup.h
 >   riscv: bootm: Correct the 1st kernel argument to hart id
 >   riscv: Remove mach type
 >   riscv: Move the linker script to the CPU root directory
 >   riscv: Fix coding style issues in the linker script
 >   riscv: Explicitly pass -march and -mabi to the compiler
 >   riscv: Add a helper routine to print CPU information
 >   riscv: Make start.S available for all targets
 >   riscv: ae350: Clean up mixed tabs and spaces in the dts
 >   riscv: kconfig: Select DM and OF_CONTROL
 >   riscv: Add QEMU virt board support
 >
 >  arch/Kconfig                            |   5 +-
 >  arch/riscv/Kconfig                      |  10 +-
 >  arch/riscv/Makefile                     |   3 +-
 >  arch/riscv/config.mk                    |   9 +-
 >  arch/riscv/cpu/Makefile                 |   7 ++
 >  arch/riscv/cpu/ax25/Makefile            |   2 -
 >  arch/riscv/cpu/cpu.c                    |  49 ++++++++
 >  arch/riscv/cpu/qemu/Makefile            |   6 +
 >  arch/riscv/cpu/qemu/cpu.c               |  29 +++++
 >  arch/riscv/cpu/qemu/dram.c              |  17 +++
 >  arch/riscv/cpu/{ax25 => }/start.S       |   0
 >  arch/riscv/cpu/{ax25 => }/u-boot.lds    |  60 +++++-----
 >  arch/riscv/dts/ae350.dts                | 177 +++++++++++++++--------------
 >  arch/riscv/include/asm/bootm.h          |  13 ---
 >  arch/riscv/include/asm/csr.h            | 124 ++++++++++++++++++++
 >  arch/riscv/include/asm/mach-types.h     |  29 -----
 >  arch/riscv/include/asm/setup.h          | 194
--------------------------------
 >  arch/riscv/include/asm/u-boot.h         |   1 -
 >  arch/riscv/lib/bootm.c                  |  19 +---
 >  board/AndesTech/ax25-ae350/ax25-ae350.c |   2 -
 >  board/emulation/qemu-riscv/Kconfig      |  21 ++++
 >  board/emulation/qemu-riscv/MAINTAINERS  |   7 ++
 >  board/emulation/qemu-riscv/Makefile     |   5 +
 >  board/emulation/qemu-riscv/qemu-riscv.c |  23 ++++
 >  cmd/bdinfo.c                            |   1 -
 >  configs/ax25-ae350_defconfig            |   2 -
 >  configs/qemu-riscv32_defconfig          |  10 ++
 >  configs/qemu-riscv64_defconfig          |  11 ++
 >  doc/README.qemu-riscv                   |  46 ++++++++
 >  include/configs/qemu-riscv.h            |  21 ++++
 >  30 files changed, 520 insertions(+), 383 deletions(-)  create mode 100644
 > arch/riscv/cpu/Makefile  create mode 100644 arch/riscv/cpu/cpu.c  create
 > mode 100644 arch/riscv/cpu/qemu/Makefile  create mode 100644
 > arch/riscv/cpu/qemu/cpu.c  create mode 100644 arch/riscv/cpu/qemu/dram.c
 > rename arch/riscv/cpu/{ax25 => }/start.S (100%)  rename arch/riscv/cpu/{ax25
 > => }/u-boot.lds (54%)  delete mode 100644 arch/riscv/include/asm/bootm.h
 > create mode 100644 arch/riscv/include/asm/csr.h  delete mode 100644
 > arch/riscv/include/asm/mach-types.h
 >  delete mode 100644 arch/riscv/include/asm/setup.h  create mode 100644
 > board/emulation/qemu-riscv/Kconfig
 >  create mode 100644 board/emulation/qemu-riscv/MAINTAINERS
 >  create mode 100644 board/emulation/qemu-riscv/Makefile
 >  create mode 100644 board/emulation/qemu-riscv/qemu-riscv.c
 >  create mode 100644 configs/qemu-riscv32_defconfig  create mode 100644
 > configs/qemu-riscv64_defconfig  create mode 100644 doc/README.qemu-riscv
 > create mode 100644 include/configs/qemu-riscv.h
 >
 > --
 > 2.7.4
>

Hi Bin

Thanks for your reviewing for code clean and make it easier to support
new targets.
I will merge this series to u-boot-riscv when next merge window open. :)

B.R

Rick