[U-Boot] [PATCH v5 0/4] RISC-V S-mode support

[U-Boot] [PATCH v5 0/4] RISC-V S-mode support

[Anup Patel]

This patchset allows us runing u-boot in S-mode which is
useful on platforms where M-mode runtime firmware is an
independent firmware and u-boot is used as last stage OS
bootloader.

The patchset based upon git://git.denx.de/u-boot-riscv.git
and is tested on QEMU in both M-mode and S-mode.

For S-mode testing, we have used u-boot.bin as payload of
latest BBL (at commit 6ebd0f2a46255d0c76dad3c05b16c1d154795d26)
applied with following changes:

diff --git a/machine/emulation.c b/machine/emulation.c
index 132e977..def75e1 100644
--- a/machine/emulation.c
+++ b/machine/emulation.c
@@ -162,6 +162,12 @@ static inline int emulate_read_csr(int num, uintptr_t mstatus, uintptr_t* result
 
   switch (num)
   {
+    case CSR_MISA:
+      *result = read_csr(misa);
+      return 0;
+    case CSR_MHARTID:
+      *result = read_csr(mhartid);
+      return 0;
     case CSR_CYCLE:
       if (!((counteren >> (CSR_CYCLE - CSR_CYCLE)) & 1))
         return -1;

Changes since v4:
 - Rebased series based on commit 52923c6db7f00e0197ec894c8c1bb8a7681974bb
   of git://git.denx.de/u-boot-riscv.git
 - Added a patch to remove redundant a2 store on DRAM base. This
   store was creating problem booting U-Boot in S-mode using BBL.

Changes since v3:
 - Replaced 'u-boot' with 'U-Boot' in commit message
 - Dropped 'an' in RISCV_SMODE kconfig option help message
 - Added appropriate #ifdef in arch/riscv/lib/interrupts.c

Changes since v2:
 - Dropped 'default n" from RISCV_SMODE kconfig option
 - Replaced '-smode_' in defconfig names with '_smode_'

Changes since v1:
 - Rebased upon latest git://git.denx.de/u-boot-riscv.git
 - Add details in cover letter for running u-boot in S-mode
   using BBL

Anup Patel (4):
  riscv: Add kconfig option to run U-Boot in S-mode
  riscv: qemu: Use different SYS_TEXT_BASE for S-mode
  riscv: Add S-mode defconfigs for QEMU virt machine
  riscv: Remove redundant a2 store on DRAM base in start.S

 arch/riscv/Kconfig                     |  5 ++++
 arch/riscv/cpu/start.S                 | 35 +++++++++++++++++++++++--
 arch/riscv/include/asm/encoding.h      |  2 ++
 arch/riscv/lib/interrupts.c            | 36 +++++++++++++++++++-------
 board/emulation/qemu-riscv/Kconfig     |  3 ++-
 board/emulation/qemu-riscv/MAINTAINERS |  2 ++
 configs/qemu-riscv32_smode_defconfig   | 10 +++++++
 configs/qemu-riscv64_smode_defconfig   | 11 ++++++++
 8 files changed, 92 insertions(+), 12 deletions(-)
 create mode 100644 configs/qemu-riscv32_smode_defconfig
 create mode 100644 configs/qemu-riscv64_smode_defconfig

-- 
2.17.1

[U-Boot] [PATCH v5 1/4] riscv: Add kconfig option to run U-Boot in S-mode

[Anup Patel]

This patch adds kconfig option RISCV_SMODE to run U-Boot in
S-mode. When this opition is enabled we use s<xyz> CSRs instead
of m<xyz> CSRs.

It is important to note that there is no equivalent S-mode CSR
for misa and mhartid CSRs so we expect M-mode runtime firmware
(BBL or equivalent) to emulate misa and mhartid CSR read.

In-future, we will have more patches to avoid accessing misa and
mhartid CSRs from S-mode.

Signed-off-by: Anup Patel <anup@brainfault.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Lukas Auer <lukas.auer@aisec.fraunhofer.de>
---
 arch/riscv/Kconfig                |  5 +++++
 arch/riscv/cpu/start.S            | 33 ++++++++++++++++++++++++++++
 arch/riscv/include/asm/encoding.h |  2 ++
 arch/riscv/lib/interrupts.c       | 36 +++++++++++++++++++++++--------
 4 files changed, 67 insertions(+), 9 deletions(-)

diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 3e0af55e71..732a357a99 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -55,6 +55,11 @@ config RISCV_ISA_C
 config RISCV_ISA_A
 	def_bool y
 
+config RISCV_SMODE
+	bool "Run in S-Mode"
+	help
+	  Enable this option to build U-Boot for RISC-V S-Mode
+
 config 32BIT
 	bool
 
diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S
index 15e1b8199a..704190f946 100644
--- a/arch/riscv/cpu/start.S
+++ b/arch/riscv/cpu/start.S
@@ -41,10 +41,18 @@ _start:
 	li	t0, CONFIG_SYS_SDRAM_BASE
 	SREG	a2, 0(t0)
 	la	t0, trap_entry
+#ifdef CONFIG_RISCV_SMODE
+	csrw	stvec, t0
+#else
 	csrw	mtvec, t0
+#endif
 
 	/* mask all interrupts */
+#ifdef CONFIG_RISCV_SMODE
+	csrw	sie, zero
+#else
 	csrw	mie, zero
+#endif
 
 	/* Enable cache */
 	jal	icache_enable
@@ -166,7 +174,11 @@ fix_rela_dyn:
 */
 	la	t0, trap_entry
 	add	t0, t0, t6
+#ifdef CONFIG_RISCV_SMODE
+	csrw	stvec, t0
+#else
 	csrw	mtvec, t0
+#endif
 
 clear_bss:
 	la	t0, __bss_start		/* t0 <- rel __bss_start in FLASH */
@@ -238,17 +250,34 @@ trap_entry:
 	SREG	x29, 29*REGBYTES(sp)
 	SREG	x30, 30*REGBYTES(sp)
 	SREG	x31, 31*REGBYTES(sp)
+#ifdef CONFIG_RISCV_SMODE
+	csrr	a0, scause
+	csrr	a1, sepc
+#else
 	csrr	a0, mcause
 	csrr	a1, mepc
+#endif
 	mv	a2, sp
 	jal	handle_trap
+#ifdef CONFIG_RISCV_SMODE
+	csrw	sepc, a0
+#else
 	csrw	mepc, a0
+#endif
 
+#ifdef CONFIG_RISCV_SMODE
+/*
+ * Remain in S-mode after sret
+ */
+	li	t0, SSTATUS_SPP
+	csrs	sstatus, t0
+#else
 /*
  * Remain in M-mode after mret
  */
 	li	t0, MSTATUS_MPP
 	csrs	mstatus, t0
+#endif
 	LREG	x1, 1*REGBYTES(sp)
 	LREG	x2, 2*REGBYTES(sp)
 	LREG	x3, 3*REGBYTES(sp)
@@ -281,4 +310,8 @@ trap_entry:
 	LREG	x30, 30*REGBYTES(sp)
 	LREG	x31, 31*REGBYTES(sp)
 	addi	sp, sp, 32*REGBYTES
+#ifdef CONFIG_RISCV_SMODE
+	sret
+#else
 	mret
+#endif
diff --git a/arch/riscv/include/asm/encoding.h b/arch/riscv/include/asm/encoding.h
index 9ea50ce640..153f5af2ff 100644
--- a/arch/riscv/include/asm/encoding.h
+++ b/arch/riscv/include/asm/encoding.h
@@ -143,6 +143,8 @@
 # define MCAUSE_CAUSE MCAUSE32_CAUSE
 #endif
 
+#define SCAUSE_INT MCAUSE_INT
+
 #define RISCV_PGSHIFT 12
 #define RISCV_PGSIZE BIT(RISCV_PGSHIFT)
 
diff --git a/arch/riscv/lib/interrupts.c b/arch/riscv/lib/interrupts.c
index 903a1c4cd5..8793f233d0 100644
--- a/arch/riscv/lib/interrupts.c
+++ b/arch/riscv/lib/interrupts.c
@@ -34,17 +34,35 @@ int disable_interrupts(void)
 	return 0;
 }
 
-ulong handle_trap(ulong mcause, ulong epc, struct pt_regs *regs)
+ulong handle_trap(ulong cause, ulong epc, struct pt_regs *regs)
 {
-	ulong is_int;
+	ulong is_irq, irq;
 
-	is_int = (mcause & MCAUSE_INT);
-	if ((is_int) && ((mcause & MCAUSE_CAUSE)  == IRQ_M_EXT))
-		external_interrupt(0);	/* handle_m_ext_interrupt */
-	else if ((is_int) && ((mcause & MCAUSE_CAUSE)  == IRQ_M_TIMER))
-		timer_interrupt(0);	/* handle_m_timer_interrupt */
-	else
-		_exit_trap(mcause, epc, regs);
+#ifdef CONFIG_RISCV_SMODE
+	is_irq = (cause & SCAUSE_INT);
+	irq = (cause & ~SCAUSE_INT);
+#else
+	is_irq = (cause & MCAUSE_INT);
+	irq = (cause & ~MCAUSE_INT);
+#endif
+
+	if (is_irq) {
+		switch (irq) {
+		case IRQ_M_EXT:
+		case IRQ_S_EXT:
+			external_interrupt(0);	/* handle external interrupt */
+			break;
+		case IRQ_M_TIMER:
+		case IRQ_S_TIMER:
+			timer_interrupt(0);	/* handle timer interrupt */
+			break;
+		default:
+			_exit_trap(cause, epc, regs);
+			break;
+		};
+	} else {
+		_exit_trap(cause, epc, regs);
+	}
 
 	return epc;
 }
-- 
2.17.1

[U-Boot] [PATCH v5 1/4] riscv: Add kconfig option to run U-Boot in S-mode

[Rick Chen]

> > Subject: [PATCH v5 1/4] riscv: Add kconfig option to run U-Boot in S-mode
> >
> > This patch adds kconfig option RISCV_SMODE to run U-Boot in S-mode. When this
> > opition is enabled we use s<xyz> CSRs instead of m<xyz> CSRs.
> >
> > It is important to note that there is no equivalent S-mode CSR for misa and
> > mhartid CSRs so we expect M-mode runtime firmware (BBL or equivalent) to
> > emulate misa and mhartid CSR read.
> >
> > In-future, we will have more patches to avoid accessing misa and mhartid CSRs
> > from S-mode.
> >
> > Signed-off-by: Anup Patel <anup@brainfault.org>
> > Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
> > Tested-by: Bin Meng <bmeng.cn@gmail.com>
> > Reviewed-by: Lukas Auer <lukas.auer@aisec.fraunhofer.de>
> > ---
> >  arch/riscv/Kconfig                |  5 +++++
> >  arch/riscv/cpu/start.S            | 33 ++++++++++++++++++++++++++++
> >  arch/riscv/include/asm/encoding.h |  2 ++
> >  arch/riscv/lib/interrupts.c       | 36 +++++++++++++++++++++++--------
> >  4 files changed, 67 insertions(+), 9 deletions(-)
> >
> > diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig index 3e0af55e71..732a357a99
> > 100644
> > --- a/arch/riscv/Kconfig
> > +++ b/arch/riscv/Kconfig
> > @@ -55,6 +55,11 @@ config RISCV_ISA_C
> >  config RISCV_ISA_A
> >       def_bool y
> >
> > +config RISCV_SMODE
> > +     bool "Run in S-Mode"
> > +     help
> > +       Enable this option to build U-Boot for RISC-V S-Mode
> > +
> >  config 32BIT
> >       bool
> >
> > diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S index
> > 15e1b8199a..704190f946 100644
> > --- a/arch/riscv/cpu/start.S
> > +++ b/arch/riscv/cpu/start.S
> > @@ -41,10 +41,18 @@ _start:
> >       li      t0, CONFIG_SYS_SDRAM_BASE
> >       SREG    a2, 0(t0)
> >       la      t0, trap_entry
> > +#ifdef CONFIG_RISCV_SMODE
> > +     csrw    stvec, t0
> > +#else
> >       csrw    mtvec, t0
> > +#endif
> >
> >       /* mask all interrupts */
> > +#ifdef CONFIG_RISCV_SMODE
> > +     csrw    sie, zero
> > +#else
> >       csrw    mie, zero
> > +#endif
> >
> >       /* Enable cache */
> >       jal     icache_enable
> > @@ -166,7 +174,11 @@ fix_rela_dyn:
> >  */
> >       la      t0, trap_entry
> >       add     t0, t0, t6
> > +#ifdef CONFIG_RISCV_SMODE
> > +     csrw    stvec, t0
> > +#else
> >       csrw    mtvec, t0
> > +#endif
> >
> >  clear_bss:
> >       la      t0, __bss_start         /* t0 <- rel __bss_start in FLASH */
> > @@ -238,17 +250,34 @@ trap_entry:
> >       SREG    x29, 29*REGBYTES(sp)
> >       SREG    x30, 30*REGBYTES(sp)
> >       SREG    x31, 31*REGBYTES(sp)
> > +#ifdef CONFIG_RISCV_SMODE
> > +     csrr    a0, scause
> > +     csrr    a1, sepc
> > +#else
> >       csrr    a0, mcause
> >       csrr    a1, mepc
> > +#endif
> >       mv      a2, sp
> >       jal     handle_trap
> > +#ifdef CONFIG_RISCV_SMODE
> > +     csrw    sepc, a0
> > +#else
> >       csrw    mepc, a0
> > +#endif
> >
> > +#ifdef CONFIG_RISCV_SMODE
> > +/*
> > + * Remain in S-mode after sret
> > + */
> > +     li      t0, SSTATUS_SPP
> > +     csrs    sstatus, t0
> > +#else
> >  /*
> >   * Remain in M-mode after mret
> >   */
> >       li      t0, MSTATUS_MPP
> >       csrs    mstatus, t0
> > +#endif

It only the difference between s and m in csr.
The code seem to be duplicate too much.
Can you implement it in macro ?
or consider to separate it in different .S file

It may too complex to maintain in the future.

B.R
Rick


> >       LREG    x1, 1*REGBYTES(sp)
> >       LREG    x2, 2*REGBYTES(sp)
> >       LREG    x3, 3*REGBYTES(sp)
> > @@ -281,4 +310,8 @@ trap_entry:
> >       LREG    x30, 30*REGBYTES(sp)
> >       LREG    x31, 31*REGBYTES(sp)
> >       addi    sp, sp, 32*REGBYTES
> > +#ifdef CONFIG_RISCV_SMODE
> > +     sret
> > +#else
> >       mret
> > +#endif
> > diff --git a/arch/riscv/include/asm/encoding.h
> > b/arch/riscv/include/asm/encoding.h
> > index 9ea50ce640..153f5af2ff 100644
> > --- a/arch/riscv/include/asm/encoding.h
> > +++ b/arch/riscv/include/asm/encoding.h
> > @@ -143,6 +143,8 @@
> >  # define MCAUSE_CAUSE MCAUSE32_CAUSE
> >  #endif
> >
> > +#define SCAUSE_INT MCAUSE_INT
> > +
> >  #define RISCV_PGSHIFT 12
> >  #define RISCV_PGSIZE BIT(RISCV_PGSHIFT)
> >
> > diff --git a/arch/riscv/lib/interrupts.c b/arch/riscv/lib/interrupts.c index
> > 903a1c4cd5..8793f233d0 100644
> > --- a/arch/riscv/lib/interrupts.c
> > +++ b/arch/riscv/lib/interrupts.c
> > @@ -34,17 +34,35 @@ int disable_interrupts(void)
> >       return 0;
> >  }
> >
> > -ulong handle_trap(ulong mcause, ulong epc, struct pt_regs *regs)
> > +ulong handle_trap(ulong cause, ulong epc, struct pt_regs *regs)
> >  {
> > -     ulong is_int;
> > +     ulong is_irq, irq;
> >
> > -     is_int = (mcause & MCAUSE_INT);
> > -     if ((is_int) && ((mcause & MCAUSE_CAUSE)  == IRQ_M_EXT))
> > -             external_interrupt(0);  /* handle_m_ext_interrupt */
> > -     else if ((is_int) && ((mcause & MCAUSE_CAUSE)  == IRQ_M_TIMER))
> > -             timer_interrupt(0);     /* handle_m_timer_interrupt */
> > -     else
> > -             _exit_trap(mcause, epc, regs);
> > +#ifdef CONFIG_RISCV_SMODE
> > +     is_irq = (cause & SCAUSE_INT);
> > +     irq = (cause & ~SCAUSE_INT);
> > +#else
> > +     is_irq = (cause & MCAUSE_INT);
> > +     irq = (cause & ~MCAUSE_INT);
> > +#endif
> > +
> > +     if (is_irq) {
> > +             switch (irq) {
> > +             case IRQ_M_EXT:
> > +             case IRQ_S_EXT:
> > +                     external_interrupt(0);  /* handle external interrupt */
> > +                     break;
> > +             case IRQ_M_TIMER:
> > +             case IRQ_S_TIMER:
> > +                     timer_interrupt(0);     /* handle timer interrupt */
> > +                     break;
> > +             default:
> > +                     _exit_trap(cause, epc, regs);
> > +                     break;
> > +             };
> > +     } else {
> > +             _exit_trap(cause, epc, regs);
> > +     }
> >
> >       return epc;
> >  }
> > --
> > 2.17.1
>

[U-Boot] [PATCH v5 1/4] riscv: Add kconfig option to run U-Boot in S-mode

[Anup Patel]

On Tue, Nov 27, 2018 at 12:09 PM Rick Chen <rickchen36@gmail.com> wrote:
>
> > > Subject: [PATCH v5 1/4] riscv: Add kconfig option to run U-Boot in S-mode
> > >
> > > This patch adds kconfig option RISCV_SMODE to run U-Boot in S-mode. When this
> > > opition is enabled we use s<xyz> CSRs instead of m<xyz> CSRs.
> > >
> > > It is important to note that there is no equivalent S-mode CSR for misa and
> > > mhartid CSRs so we expect M-mode runtime firmware (BBL or equivalent) to
> > > emulate misa and mhartid CSR read.
> > >
> > > In-future, we will have more patches to avoid accessing misa and mhartid CSRs
> > > from S-mode.
> > >
> > > Signed-off-by: Anup Patel <anup@brainfault.org>
> > > Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
> > > Tested-by: Bin Meng <bmeng.cn@gmail.com>
> > > Reviewed-by: Lukas Auer <lukas.auer@aisec.fraunhofer.de>
> > > ---
> > >  arch/riscv/Kconfig                |  5 +++++
> > >  arch/riscv/cpu/start.S            | 33 ++++++++++++++++++++++++++++
> > >  arch/riscv/include/asm/encoding.h |  2 ++
> > >  arch/riscv/lib/interrupts.c       | 36 +++++++++++++++++++++++--------
> > >  4 files changed, 67 insertions(+), 9 deletions(-)
> > >
> > > diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig index 3e0af55e71..732a357a99
> > > 100644
> > > --- a/arch/riscv/Kconfig
> > > +++ b/arch/riscv/Kconfig
> > > @@ -55,6 +55,11 @@ config RISCV_ISA_C
> > >  config RISCV_ISA_A
> > >       def_bool y
> > >
> > > +config RISCV_SMODE
> > > +     bool "Run in S-Mode"
> > > +     help
> > > +       Enable this option to build U-Boot for RISC-V S-Mode
> > > +
> > >  config 32BIT
> > >       bool
> > >
> > > diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S index
> > > 15e1b8199a..704190f946 100644
> > > --- a/arch/riscv/cpu/start.S
> > > +++ b/arch/riscv/cpu/start.S
> > > @@ -41,10 +41,18 @@ _start:
> > >       li      t0, CONFIG_SYS_SDRAM_BASE
> > >       SREG    a2, 0(t0)
> > >       la      t0, trap_entry
> > > +#ifdef CONFIG_RISCV_SMODE
> > > +     csrw    stvec, t0
> > > +#else
> > >       csrw    mtvec, t0
> > > +#endif
> > >
> > >       /* mask all interrupts */
> > > +#ifdef CONFIG_RISCV_SMODE
> > > +     csrw    sie, zero
> > > +#else
> > >       csrw    mie, zero
> > > +#endif
> > >
> > >       /* Enable cache */
> > >       jal     icache_enable
> > > @@ -166,7 +174,11 @@ fix_rela_dyn:
> > >  */
> > >       la      t0, trap_entry
> > >       add     t0, t0, t6
> > > +#ifdef CONFIG_RISCV_SMODE
> > > +     csrw    stvec, t0
> > > +#else
> > >       csrw    mtvec, t0
> > > +#endif
> > >
> > >  clear_bss:
> > >       la      t0, __bss_start         /* t0 <- rel __bss_start in FLASH */
> > > @@ -238,17 +250,34 @@ trap_entry:
> > >       SREG    x29, 29*REGBYTES(sp)
> > >       SREG    x30, 30*REGBYTES(sp)
> > >       SREG    x31, 31*REGBYTES(sp)
> > > +#ifdef CONFIG_RISCV_SMODE
> > > +     csrr    a0, scause
> > > +     csrr    a1, sepc
> > > +#else
> > >       csrr    a0, mcause
> > >       csrr    a1, mepc
> > > +#endif
> > >       mv      a2, sp
> > >       jal     handle_trap
> > > +#ifdef CONFIG_RISCV_SMODE
> > > +     csrw    sepc, a0
> > > +#else
> > >       csrw    mepc, a0
> > > +#endif
> > >
> > > +#ifdef CONFIG_RISCV_SMODE
> > > +/*
> > > + * Remain in S-mode after sret
> > > + */
> > > +     li      t0, SSTATUS_SPP
> > > +     csrs    sstatus, t0
> > > +#else
> > >  /*
> > >   * Remain in M-mode after mret
> > >   */
> > >       li      t0, MSTATUS_MPP
> > >       csrs    mstatus, t0
> > > +#endif
>
> It only the difference between s and m in csr.
> The code seem to be duplicate too much.
> Can you implement it in macro ?
> or consider to separate it in different .S file
>
> It may too complex to maintain in the future.
>

Here are few reasons why not to do this:
1. We don't have same set of CSRs for M-mode and S-mode. For
certain, M-mode CSRs we don't have any corresponding S-mode
CSRs.
2. Number of CSRs for each mode are really few so there won't be
much #ifdef in code. Having separate .S will be total overkill and
too much code duplication.
3. Using macro would mean we use incomplete CSR names
examples: "status" for "mstatus"/"sstatus", "epc" for "mepc"/"sepc",
etc. This means we cannot grep code for use of a CSR. I think this
is less readable compared to using #ifdef

Despite above reasons, above can always be attempted as
separate patch.

Regards,
Anup

[U-Boot] [PATCH v5 1/4] riscv: Add kconfig option to run U-Boot in S-mode

[Alexander Graf]

On 27.11.18 07:52, Anup Patel wrote:
> On Tue, Nov 27, 2018 at 12:09 PM Rick Chen <rickchen36@gmail.com> wrote:
>>
>>>> Subject: [PATCH v5 1/4] riscv: Add kconfig option to run U-Boot in S-mode
>>>>
>>>> This patch adds kconfig option RISCV_SMODE to run U-Boot in S-mode. When this
>>>> opition is enabled we use s<xyz> CSRs instead of m<xyz> CSRs.
>>>>
>>>> It is important to note that there is no equivalent S-mode CSR for misa and
>>>> mhartid CSRs so we expect M-mode runtime firmware (BBL or equivalent) to
>>>> emulate misa and mhartid CSR read.
>>>>
>>>> In-future, we will have more patches to avoid accessing misa and mhartid CSRs
>>>> from S-mode.
>>>>
>>>> Signed-off-by: Anup Patel <anup@brainfault.org>
>>>> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
>>>> Tested-by: Bin Meng <bmeng.cn@gmail.com>
>>>> Reviewed-by: Lukas Auer <lukas.auer@aisec.fraunhofer.de>
>>>> ---
>>>>  arch/riscv/Kconfig                |  5 +++++
>>>>  arch/riscv/cpu/start.S            | 33 ++++++++++++++++++++++++++++
>>>>  arch/riscv/include/asm/encoding.h |  2 ++
>>>>  arch/riscv/lib/interrupts.c       | 36 +++++++++++++++++++++++--------
>>>>  4 files changed, 67 insertions(+), 9 deletions(-)
>>>>
>>>> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig index 3e0af55e71..732a357a99
>>>> 100644
>>>> --- a/arch/riscv/Kconfig
>>>> +++ b/arch/riscv/Kconfig
>>>> @@ -55,6 +55,11 @@ config RISCV_ISA_C
>>>>  config RISCV_ISA_A
>>>>       def_bool y
>>>>
>>>> +config RISCV_SMODE
>>>> +     bool "Run in S-Mode"
>>>> +     help
>>>> +       Enable this option to build U-Boot for RISC-V S-Mode
>>>> +
>>>>  config 32BIT
>>>>       bool
>>>>
>>>> diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S index
>>>> 15e1b8199a..704190f946 100644
>>>> --- a/arch/riscv/cpu/start.S
>>>> +++ b/arch/riscv/cpu/start.S
>>>> @@ -41,10 +41,18 @@ _start:
>>>>       li      t0, CONFIG_SYS_SDRAM_BASE
>>>>       SREG    a2, 0(t0)
>>>>       la      t0, trap_entry
>>>> +#ifdef CONFIG_RISCV_SMODE
>>>> +     csrw    stvec, t0
>>>> +#else
>>>>       csrw    mtvec, t0
>>>> +#endif
>>>>
>>>>       /* mask all interrupts */
>>>> +#ifdef CONFIG_RISCV_SMODE
>>>> +     csrw    sie, zero
>>>> +#else
>>>>       csrw    mie, zero
>>>> +#endif
>>>>
>>>>       /* Enable cache */
>>>>       jal     icache_enable
>>>> @@ -166,7 +174,11 @@ fix_rela_dyn:
>>>>  */
>>>>       la      t0, trap_entry
>>>>       add     t0, t0, t6
>>>> +#ifdef CONFIG_RISCV_SMODE
>>>> +     csrw    stvec, t0
>>>> +#else
>>>>       csrw    mtvec, t0
>>>> +#endif
>>>>
>>>>  clear_bss:
>>>>       la      t0, __bss_start         /* t0 <- rel __bss_start in FLASH */
>>>> @@ -238,17 +250,34 @@ trap_entry:
>>>>       SREG    x29, 29*REGBYTES(sp)
>>>>       SREG    x30, 30*REGBYTES(sp)
>>>>       SREG    x31, 31*REGBYTES(sp)
>>>> +#ifdef CONFIG_RISCV_SMODE
>>>> +     csrr    a0, scause
>>>> +     csrr    a1, sepc
>>>> +#else
>>>>       csrr    a0, mcause
>>>>       csrr    a1, mepc
>>>> +#endif
>>>>       mv      a2, sp
>>>>       jal     handle_trap
>>>> +#ifdef CONFIG_RISCV_SMODE
>>>> +     csrw    sepc, a0
>>>> +#else
>>>>       csrw    mepc, a0
>>>> +#endif
>>>>
>>>> +#ifdef CONFIG_RISCV_SMODE
>>>> +/*
>>>> + * Remain in S-mode after sret
>>>> + */
>>>> +     li      t0, SSTATUS_SPP
>>>> +     csrs    sstatus, t0
>>>> +#else
>>>>  /*
>>>>   * Remain in M-mode after mret
>>>>   */
>>>>       li      t0, MSTATUS_MPP
>>>>       csrs    mstatus, t0
>>>> +#endif
>>
>> It only the difference between s and m in csr.
>> The code seem to be duplicate too much.
>> Can you implement it in macro ?
>> or consider to separate it in different .S file
>>
>> It may too complex to maintain in the future.
>>
> 
> Here are few reasons why not to do this:
> 1. We don't have same set of CSRs for M-mode and S-mode. For
> certain, M-mode CSRs we don't have any corresponding S-mode
> CSRs.
> 2. Number of CSRs for each mode are really few so there won't be
> much #ifdef in code. Having separate .S will be total overkill and
> too much code duplication.
> 3. Using macro would mean we use incomplete CSR names
> examples: "status" for "mstatus"/"sstatus", "epc" for "mepc"/"sepc",
> etc. This means we cannot grep code for use of a CSR. I think this
> is less readable compared to using #ifdef
> 
> Despite above reasons, above can always be attempted as
> separate patch.

On AArch64, we determine the current EL during runtime and then branch
to respective labels for different ELs (see the switch_el macro for asm
as well as current_el() for C).

Wouldn't it make sense to attempt something similar with S-mode, so that
the same binary can run either in M or in S depending on how it was started?


Alex

[U-Boot] [PATCH v5 1/4] riscv: Add kconfig option to run U-Boot in S-mode

[Anup Patel]

On Tue, Nov 27, 2018 at 4:17 PM Alexander Graf <agraf@suse.de> wrote:
>
>
>
> On 27.11.18 07:52, Anup Patel wrote:
> > On Tue, Nov 27, 2018 at 12:09 PM Rick Chen <rickchen36@gmail.com> wrote:
> >>
> >>>> Subject: [PATCH v5 1/4] riscv: Add kconfig option to run U-Boot in S-mode
> >>>>
> >>>> This patch adds kconfig option RISCV_SMODE to run U-Boot in S-mode. When this
> >>>> opition is enabled we use s<xyz> CSRs instead of m<xyz> CSRs.
> >>>>
> >>>> It is important to note that there is no equivalent S-mode CSR for misa and
> >>>> mhartid CSRs so we expect M-mode runtime firmware (BBL or equivalent) to
> >>>> emulate misa and mhartid CSR read.
> >>>>
> >>>> In-future, we will have more patches to avoid accessing misa and mhartid CSRs
> >>>> from S-mode.
> >>>>
> >>>> Signed-off-by: Anup Patel <anup@brainfault.org>
> >>>> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
> >>>> Tested-by: Bin Meng <bmeng.cn@gmail.com>
> >>>> Reviewed-by: Lukas Auer <lukas.auer@aisec.fraunhofer.de>
> >>>> ---
> >>>>  arch/riscv/Kconfig                |  5 +++++
> >>>>  arch/riscv/cpu/start.S            | 33 ++++++++++++++++++++++++++++
> >>>>  arch/riscv/include/asm/encoding.h |  2 ++
> >>>>  arch/riscv/lib/interrupts.c       | 36 +++++++++++++++++++++++--------
> >>>>  4 files changed, 67 insertions(+), 9 deletions(-)
> >>>>
> >>>> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig index 3e0af55e71..732a357a99
> >>>> 100644
> >>>> --- a/arch/riscv/Kconfig
> >>>> +++ b/arch/riscv/Kconfig
> >>>> @@ -55,6 +55,11 @@ config RISCV_ISA_C
> >>>>  config RISCV_ISA_A
> >>>>       def_bool y
> >>>>
> >>>> +config RISCV_SMODE
> >>>> +     bool "Run in S-Mode"
> >>>> +     help
> >>>> +       Enable this option to build U-Boot for RISC-V S-Mode
> >>>> +
> >>>>  config 32BIT
> >>>>       bool
> >>>>
> >>>> diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S index
> >>>> 15e1b8199a..704190f946 100644
> >>>> --- a/arch/riscv/cpu/start.S
> >>>> +++ b/arch/riscv/cpu/start.S
> >>>> @@ -41,10 +41,18 @@ _start:
> >>>>       li      t0, CONFIG_SYS_SDRAM_BASE
> >>>>       SREG    a2, 0(t0)
> >>>>       la      t0, trap_entry
> >>>> +#ifdef CONFIG_RISCV_SMODE
> >>>> +     csrw    stvec, t0
> >>>> +#else
> >>>>       csrw    mtvec, t0
> >>>> +#endif
> >>>>
> >>>>       /* mask all interrupts */
> >>>> +#ifdef CONFIG_RISCV_SMODE
> >>>> +     csrw    sie, zero
> >>>> +#else
> >>>>       csrw    mie, zero
> >>>> +#endif
> >>>>
> >>>>       /* Enable cache */
> >>>>       jal     icache_enable
> >>>> @@ -166,7 +174,11 @@ fix_rela_dyn:
> >>>>  */
> >>>>       la      t0, trap_entry
> >>>>       add     t0, t0, t6
> >>>> +#ifdef CONFIG_RISCV_SMODE
> >>>> +     csrw    stvec, t0
> >>>> +#else
> >>>>       csrw    mtvec, t0
> >>>> +#endif
> >>>>
> >>>>  clear_bss:
> >>>>       la      t0, __bss_start         /* t0 <- rel __bss_start in FLASH */
> >>>> @@ -238,17 +250,34 @@ trap_entry:
> >>>>       SREG    x29, 29*REGBYTES(sp)
> >>>>       SREG    x30, 30*REGBYTES(sp)
> >>>>       SREG    x31, 31*REGBYTES(sp)
> >>>> +#ifdef CONFIG_RISCV_SMODE
> >>>> +     csrr    a0, scause
> >>>> +     csrr    a1, sepc
> >>>> +#else
> >>>>       csrr    a0, mcause
> >>>>       csrr    a1, mepc
> >>>> +#endif
> >>>>       mv      a2, sp
> >>>>       jal     handle_trap
> >>>> +#ifdef CONFIG_RISCV_SMODE
> >>>> +     csrw    sepc, a0
> >>>> +#else
> >>>>       csrw    mepc, a0
> >>>> +#endif
> >>>>
> >>>> +#ifdef CONFIG_RISCV_SMODE
> >>>> +/*
> >>>> + * Remain in S-mode after sret
> >>>> + */
> >>>> +     li      t0, SSTATUS_SPP
> >>>> +     csrs    sstatus, t0
> >>>> +#else
> >>>>  /*
> >>>>   * Remain in M-mode after mret
> >>>>   */
> >>>>       li      t0, MSTATUS_MPP
> >>>>       csrs    mstatus, t0
> >>>> +#endif
> >>
> >> It only the difference between s and m in csr.
> >> The code seem to be duplicate too much.
> >> Can you implement it in macro ?
> >> or consider to separate it in different .S file
> >>
> >> It may too complex to maintain in the future.
> >>
> >
> > Here are few reasons why not to do this:
> > 1. We don't have same set of CSRs for M-mode and S-mode. For
> > certain, M-mode CSRs we don't have any corresponding S-mode
> > CSRs.
> > 2. Number of CSRs for each mode are really few so there won't be
> > much #ifdef in code. Having separate .S will be total overkill and
> > too much code duplication.
> > 3. Using macro would mean we use incomplete CSR names
> > examples: "status" for "mstatus"/"sstatus", "epc" for "mepc"/"sepc",
> > etc. This means we cannot grep code for use of a CSR. I think this
> > is less readable compared to using #ifdef
> >
> > Despite above reasons, above can always be attempted as
> > separate patch.
>
> On AArch64, we determine the current EL during runtime and then branch
> to respective labels for different ELs (see the switch_el macro for asm
> as well as current_el() for C).
>
> Wouldn't it make sense to attempt something similar with S-mode, so that
> the same binary can run either in M or in S depending on how it was started?

As-per my understand, there is no direct way of knowing current
execution mode in RISC-V at runtime.

Of course, software can step from M to S/U using mret OR from
S to U using sret. Further software running in U-mode can do
ecall to S-mode and S-mode can do ecall to M-mode.

Software is generally written for a particular execution mode (M, S, or U).

Regards,
Anup

[U-Boot] [PATCH v5 1/4] riscv: Add kconfig option to run U-Boot in S-mode

[Rick Chen]

Anup Patel <anup@brainfault.org> 於 2018年11月27日 週二 下午8:38寫道：
>
> On Tue, Nov 27, 2018 at 4:17 PM Alexander Graf <agraf@suse.de> wrote:
> >
> >
> >
> > On 27.11.18 07:52, Anup Patel wrote:
> > > On Tue, Nov 27, 2018 at 12:09 PM Rick Chen <rickchen36@gmail.com> wrote:
> > >>
> > >>>> Subject: [PATCH v5 1/4] riscv: Add kconfig option to run U-Boot in S-mode
> > >>>>
> > >>>> This patch adds kconfig option RISCV_SMODE to run U-Boot in S-mode. When this
> > >>>> opition is enabled we use s<xyz> CSRs instead of m<xyz> CSRs.
> > >>>>
> > >>>> It is important to note that there is no equivalent S-mode CSR for misa and
> > >>>> mhartid CSRs so we expect M-mode runtime firmware (BBL or equivalent) to
> > >>>> emulate misa and mhartid CSR read.
> > >>>>
> > >>>> In-future, we will have more patches to avoid accessing misa and mhartid CSRs
> > >>>> from S-mode.
> > >>>>
> > >>>> Signed-off-by: Anup Patel <anup@brainfault.org>
> > >>>> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
> > >>>> Tested-by: Bin Meng <bmeng.cn@gmail.com>
> > >>>> Reviewed-by: Lukas Auer <lukas.auer@aisec.fraunhofer.de>
> > >>>> ---
> > >>>>  arch/riscv/Kconfig                |  5 +++++
> > >>>>  arch/riscv/cpu/start.S            | 33 ++++++++++++++++++++++++++++
> > >>>>  arch/riscv/include/asm/encoding.h |  2 ++
> > >>>>  arch/riscv/lib/interrupts.c       | 36 +++++++++++++++++++++++--------
> > >>>>  4 files changed, 67 insertions(+), 9 deletions(-)
> > >>>>
> > >>>> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig index 3e0af55e71..732a357a99
> > >>>> 100644
> > >>>> --- a/arch/riscv/Kconfig
> > >>>> +++ b/arch/riscv/Kconfig
> > >>>> @@ -55,6 +55,11 @@ config RISCV_ISA_C
> > >>>>  config RISCV_ISA_A
> > >>>>       def_bool y
> > >>>>
> > >>>> +config RISCV_SMODE
> > >>>> +     bool "Run in S-Mode"
> > >>>> +     help
> > >>>> +       Enable this option to build U-Boot for RISC-V S-Mode
> > >>>> +
> > >>>>  config 32BIT
> > >>>>       bool
> > >>>>
> > >>>> diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S index
> > >>>> 15e1b8199a..704190f946 100644
> > >>>> --- a/arch/riscv/cpu/start.S
> > >>>> +++ b/arch/riscv/cpu/start.S
> > >>>> @@ -41,10 +41,18 @@ _start:
> > >>>>       li      t0, CONFIG_SYS_SDRAM_BASE
> > >>>>       SREG    a2, 0(t0)
> > >>>>       la      t0, trap_entry
> > >>>> +#ifdef CONFIG_RISCV_SMODE
> > >>>> +     csrw    stvec, t0
> > >>>> +#else
> > >>>>       csrw    mtvec, t0
> > >>>> +#endif
> > >>>>
> > >>>>       /* mask all interrupts */
> > >>>> +#ifdef CONFIG_RISCV_SMODE
> > >>>> +     csrw    sie, zero
> > >>>> +#else
> > >>>>       csrw    mie, zero
> > >>>> +#endif
> > >>>>
> > >>>>       /* Enable cache */
> > >>>>       jal     icache_enable
> > >>>> @@ -166,7 +174,11 @@ fix_rela_dyn:
> > >>>>  */
> > >>>>       la      t0, trap_entry
> > >>>>       add     t0, t0, t6
> > >>>> +#ifdef CONFIG_RISCV_SMODE
> > >>>> +     csrw    stvec, t0
> > >>>> +#else
> > >>>>       csrw    mtvec, t0
> > >>>> +#endif
> > >>>>
> > >>>>  clear_bss:
> > >>>>       la      t0, __bss_start         /* t0 <- rel __bss_start in FLASH */
> > >>>> @@ -238,17 +250,34 @@ trap_entry:
> > >>>>       SREG    x29, 29*REGBYTES(sp)
> > >>>>       SREG    x30, 30*REGBYTES(sp)
> > >>>>       SREG    x31, 31*REGBYTES(sp)
> > >>>> +#ifdef CONFIG_RISCV_SMODE
> > >>>> +     csrr    a0, scause
> > >>>> +     csrr    a1, sepc
> > >>>> +#else
> > >>>>       csrr    a0, mcause
> > >>>>       csrr    a1, mepc
> > >>>> +#endif
> > >>>>       mv      a2, sp
> > >>>>       jal     handle_trap
> > >>>> +#ifdef CONFIG_RISCV_SMODE
> > >>>> +     csrw    sepc, a0
> > >>>> +#else
> > >>>>       csrw    mepc, a0
> > >>>> +#endif
> > >>>>
> > >>>> +#ifdef CONFIG_RISCV_SMODE
> > >>>> +/*
> > >>>> + * Remain in S-mode after sret
> > >>>> + */
> > >>>> +     li      t0, SSTATUS_SPP
> > >>>> +     csrs    sstatus, t0
> > >>>> +#else
> > >>>>  /*
> > >>>>   * Remain in M-mode after mret
> > >>>>   */
> > >>>>       li      t0, MSTATUS_MPP
> > >>>>       csrs    mstatus, t0
> > >>>> +#endif
> > >>
> > >> It only the difference between s and m in csr.
> > >> The code seem to be duplicate too much.
> > >> Can you implement it in macro ?
> > >> or consider to separate it in different .S file
> > >>
> > >> It may too complex to maintain in the future.
> > >>
> > >
> > > Here are few reasons why not to do this:
> > > 1. We don't have same set of CSRs for M-mode and S-mode. For
> > > certain, M-mode CSRs we don't have any corresponding S-mode
> > > CSRs.
> > > 2. Number of CSRs for each mode are really few so there won't be
> > > much #ifdef in code. Having separate .S will be total overkill and
> > > too much code duplication.
> > > 3. Using macro would mean we use incomplete CSR names
> > > examples: "status" for "mstatus"/"sstatus", "epc" for "mepc"/"sepc",
> > > etc. This means we cannot grep code for use of a CSR. I think this
> > > is less readable compared to using #ifdef
> > >
> > > Despite above reasons, above can always be attempted as
> > > separate patch.
> >

Hi Anup

I mean it is not a good way to switch s and m mode like that
#ifdef CONFIG_RISCV_SMODE
   csrw    sepc, a0
#else
   csrw    mepc, a0
#endif


You can use ## to get stvec ot mtvec in different CONFIG
It can be refered to some kernel code as below:
glue.h
#define ____glue(name,fn) name##fn
#define __glue(name,fn) ____glue(name,fn)

glue-proc.h
#ifdef CONFIG_CPU_ARM720T
#define CPU_NAME cpu_arm720
#else
#define CPU_NAME cpu_arm7tdmi
#endif

#define cpu_proc_init __glue(CPU_NAME,_proc_init)

Then It will compile as cpu_arm720_proc_init or cpu_arm7tdmi_proc_init
in different configuration.
stvec and mtvce can be implement by the same way.

B.R
Rick




> > On AArch64, we determine the current EL during runtime and then branch
> > to respective labels for different ELs (see the switch_el macro for asm
> > as well as current_el() for C).
> >
> > Wouldn't it make sense to attempt something similar with S-mode, so that
> > the same binary can run either in M or in S depending on how it was started?
>
> As-per my understand, there is no direct way of knowing current
> execution mode in RISC-V at runtime.
>
> Of course, software can step from M to S/U using mret OR from
> S to U using sret. Further software running in U-mode can do
> ecall to S-mode and S-mode can do ecall to M-mode.
>
> Software is generally written for a particular execution mode (M, S, or U).
>
> Regards,
> Anup

[U-Boot] [PATCH v5 1/4] riscv: Add kconfig option to run U-Boot in S-mode

[Anup Patel]

On Fri, Nov 30, 2018 at 12:34 PM Rick Chen <rickchen36@gmail.com> wrote:
>
> Anup Patel <anup@brainfault.org> 於 2018年11月27日 週二 下午8:38寫道：
> >
> > On Tue, Nov 27, 2018 at 4:17 PM Alexander Graf <agraf@suse.de> wrote:
> > >
> > >
> > >
> > > On 27.11.18 07:52, Anup Patel wrote:
> > > > On Tue, Nov 27, 2018 at 12:09 PM Rick Chen <rickchen36@gmail.com> wrote:
> > > >>
> > > >>>> Subject: [PATCH v5 1/4] riscv: Add kconfig option to run U-Boot in S-mode
> > > >>>>
> > > >>>> This patch adds kconfig option RISCV_SMODE to run U-Boot in S-mode. When this
> > > >>>> opition is enabled we use s<xyz> CSRs instead of m<xyz> CSRs.
> > > >>>>
> > > >>>> It is important to note that there is no equivalent S-mode CSR for misa and
> > > >>>> mhartid CSRs so we expect M-mode runtime firmware (BBL or equivalent) to
> > > >>>> emulate misa and mhartid CSR read.
> > > >>>>
> > > >>>> In-future, we will have more patches to avoid accessing misa and mhartid CSRs
> > > >>>> from S-mode.
> > > >>>>
> > > >>>> Signed-off-by: Anup Patel <anup@brainfault.org>
> > > >>>> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
> > > >>>> Tested-by: Bin Meng <bmeng.cn@gmail.com>
> > > >>>> Reviewed-by: Lukas Auer <lukas.auer@aisec.fraunhofer.de>
> > > >>>> ---
> > > >>>>  arch/riscv/Kconfig                |  5 +++++
> > > >>>>  arch/riscv/cpu/start.S            | 33 ++++++++++++++++++++++++++++
> > > >>>>  arch/riscv/include/asm/encoding.h |  2 ++
> > > >>>>  arch/riscv/lib/interrupts.c       | 36 +++++++++++++++++++++++--------
> > > >>>>  4 files changed, 67 insertions(+), 9 deletions(-)
> > > >>>>
> > > >>>> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig index 3e0af55e71..732a357a99
> > > >>>> 100644
> > > >>>> --- a/arch/riscv/Kconfig
> > > >>>> +++ b/arch/riscv/Kconfig
> > > >>>> @@ -55,6 +55,11 @@ config RISCV_ISA_C
> > > >>>>  config RISCV_ISA_A
> > > >>>>       def_bool y
> > > >>>>
> > > >>>> +config RISCV_SMODE
> > > >>>> +     bool "Run in S-Mode"
> > > >>>> +     help
> > > >>>> +       Enable this option to build U-Boot for RISC-V S-Mode
> > > >>>> +
> > > >>>>  config 32BIT
> > > >>>>       bool
> > > >>>>
> > > >>>> diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S index
> > > >>>> 15e1b8199a..704190f946 100644
> > > >>>> --- a/arch/riscv/cpu/start.S
> > > >>>> +++ b/arch/riscv/cpu/start.S
> > > >>>> @@ -41,10 +41,18 @@ _start:
> > > >>>>       li      t0, CONFIG_SYS_SDRAM_BASE
> > > >>>>       SREG    a2, 0(t0)
> > > >>>>       la      t0, trap_entry
> > > >>>> +#ifdef CONFIG_RISCV_SMODE
> > > >>>> +     csrw    stvec, t0
> > > >>>> +#else
> > > >>>>       csrw    mtvec, t0
> > > >>>> +#endif
> > > >>>>
> > > >>>>       /* mask all interrupts */
> > > >>>> +#ifdef CONFIG_RISCV_SMODE
> > > >>>> +     csrw    sie, zero
> > > >>>> +#else
> > > >>>>       csrw    mie, zero
> > > >>>> +#endif
> > > >>>>
> > > >>>>       /* Enable cache */
> > > >>>>       jal     icache_enable
> > > >>>> @@ -166,7 +174,11 @@ fix_rela_dyn:
> > > >>>>  */
> > > >>>>       la      t0, trap_entry
> > > >>>>       add     t0, t0, t6
> > > >>>> +#ifdef CONFIG_RISCV_SMODE
> > > >>>> +     csrw    stvec, t0
> > > >>>> +#else
> > > >>>>       csrw    mtvec, t0
> > > >>>> +#endif
> > > >>>>
> > > >>>>  clear_bss:
> > > >>>>       la      t0, __bss_start         /* t0 <- rel __bss_start in FLASH */
> > > >>>> @@ -238,17 +250,34 @@ trap_entry:
> > > >>>>       SREG    x29, 29*REGBYTES(sp)
> > > >>>>       SREG    x30, 30*REGBYTES(sp)
> > > >>>>       SREG    x31, 31*REGBYTES(sp)
> > > >>>> +#ifdef CONFIG_RISCV_SMODE
> > > >>>> +     csrr    a0, scause
> > > >>>> +     csrr    a1, sepc
> > > >>>> +#else
> > > >>>>       csrr    a0, mcause
> > > >>>>       csrr    a1, mepc
> > > >>>> +#endif
> > > >>>>       mv      a2, sp
> > > >>>>       jal     handle_trap
> > > >>>> +#ifdef CONFIG_RISCV_SMODE
> > > >>>> +     csrw    sepc, a0
> > > >>>> +#else
> > > >>>>       csrw    mepc, a0
> > > >>>> +#endif
> > > >>>>
> > > >>>> +#ifdef CONFIG_RISCV_SMODE
> > > >>>> +/*
> > > >>>> + * Remain in S-mode after sret
> > > >>>> + */
> > > >>>> +     li      t0, SSTATUS_SPP
> > > >>>> +     csrs    sstatus, t0
> > > >>>> +#else
> > > >>>>  /*
> > > >>>>   * Remain in M-mode after mret
> > > >>>>   */
> > > >>>>       li      t0, MSTATUS_MPP
> > > >>>>       csrs    mstatus, t0
> > > >>>> +#endif
> > > >>
> > > >> It only the difference between s and m in csr.
> > > >> The code seem to be duplicate too much.
> > > >> Can you implement it in macro ?
> > > >> or consider to separate it in different .S file
> > > >>
> > > >> It may too complex to maintain in the future.
> > > >>
> > > >
> > > > Here are few reasons why not to do this:
> > > > 1. We don't have same set of CSRs for M-mode and S-mode. For
> > > > certain, M-mode CSRs we don't have any corresponding S-mode
> > > > CSRs.
> > > > 2. Number of CSRs for each mode are really few so there won't be
> > > > much #ifdef in code. Having separate .S will be total overkill and
> > > > too much code duplication.
> > > > 3. Using macro would mean we use incomplete CSR names
> > > > examples: "status" for "mstatus"/"sstatus", "epc" for "mepc"/"sepc",
> > > > etc. This means we cannot grep code for use of a CSR. I think this
> > > > is less readable compared to using #ifdef
> > > >
> > > > Despite above reasons, above can always be attempted as
> > > > separate patch.
> > >
>
> Hi Anup
>
> I mean it is not a good way to switch s and m mode like that
> #ifdef CONFIG_RISCV_SMODE
>    csrw    sepc, a0
> #else
>    csrw    mepc, a0
> #endif
>
>
> You can use ## to get stvec ot mtvec in different CONFIG
> It can be refered to some kernel code as below:
> glue.h
> #define ____glue(name,fn) name##fn
> #define __glue(name,fn) ____glue(name,fn)
>
> glue-proc.h
> #ifdef CONFIG_CPU_ARM720T
> #define CPU_NAME cpu_arm720
> #else
> #define CPU_NAME cpu_arm7tdmi
> #endif
>
> #define cpu_proc_init __glue(CPU_NAME,_proc_init)
>
> Then It will compile as cpu_arm720_proc_init or cpu_arm7tdmi_proc_init
> in different configuration.
> stvec and mtvce can be implement by the same way.

I had understood your suggestion previously.

Though I am not fan of this approach, I will change it
anyway.

Thanks,
Anup

[U-Boot] [PATCH v5 2/4] riscv: qemu: Use different SYS_TEXT_BASE for S-mode

[Anup Patel]

When u-boot runs in S-mode, the M-mode runtime firmware
(BBL or equivalent) uses memory range in 0x80000000 to
0x80200000. Due to this, we cannot use 0x80000000 as
SYS_TEXT_BASE when running in S-mode. Instead for S-mode,
we use 0x80200000 as SYS_TEXT_BASE.

Even Linux RISC-V kernel ignores/reserves memory range
0x80000000 to 0x80200000 because it runs in S-mode.

Signed-off-by: Anup Patel <anup@brainfault.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Lukas Auer <lukas.auer@aisec.fraunhofer.de>
---
 board/emulation/qemu-riscv/Kconfig | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/board/emulation/qemu-riscv/Kconfig b/board/emulation/qemu-riscv/Kconfig
index 33ca253432..56bb5337d4 100644
--- a/board/emulation/qemu-riscv/Kconfig
+++ b/board/emulation/qemu-riscv/Kconfig
@@ -13,7 +13,8 @@ config SYS_CONFIG_NAME
 	default "qemu-riscv"
 
 config SYS_TEXT_BASE
-	default 0x80000000
+	default 0x80000000 if !RISCV_SMODE
+	default 0x80200000 if RISCV_SMODE
 
 config BOARD_SPECIFIC_OPTIONS # dummy
 	def_bool y
-- 
2.17.1

[U-Boot] [PATCH v5 3/4] riscv: Add S-mode defconfigs for QEMU virt machine

[Anup Patel]

This patch adds S-mode defconfigs for QEMU virt machine so
that we can run u-boot in S-mode on QEMU using M-mode runtime
firmware (BBL or equivalent).

Signed-off-by: Anup Patel <anup@brainfault.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Lukas Auer <lukas.auer@aisec.fraunhofer.de>
---
 board/emulation/qemu-riscv/MAINTAINERS |  2 ++
 configs/qemu-riscv32_smode_defconfig   | 10 ++++++++++
 configs/qemu-riscv64_smode_defconfig   | 11 +++++++++++
 3 files changed, 23 insertions(+)
 create mode 100644 configs/qemu-riscv32_smode_defconfig
 create mode 100644 configs/qemu-riscv64_smode_defconfig

diff --git a/board/emulation/qemu-riscv/MAINTAINERS b/board/emulation/qemu-riscv/MAINTAINERS
index 3c6eb4f844..c701c83d77 100644
--- a/board/emulation/qemu-riscv/MAINTAINERS
+++ b/board/emulation/qemu-riscv/MAINTAINERS
@@ -4,4 +4,6 @@ S:	Maintained
 F:	board/emulation/qemu-riscv/
 F:	include/configs/qemu-riscv.h
 F:	configs/qemu-riscv32_defconfig
+F:	configs/qemu-riscv32_smode_defconfig
 F:	configs/qemu-riscv64_defconfig
+F:	configs/qemu-riscv64_smode_defconfig
diff --git a/configs/qemu-riscv32_smode_defconfig b/configs/qemu-riscv32_smode_defconfig
new file mode 100644
index 0000000000..0a84ec1874
--- /dev/null
+++ b/configs/qemu-riscv32_smode_defconfig
@@ -0,0 +1,10 @@
+CONFIG_RISCV=y
+CONFIG_TARGET_QEMU_VIRT=y
+CONFIG_RISCV_SMODE=y
+CONFIG_DISTRO_DEFAULTS=y
+CONFIG_NR_DRAM_BANKS=1
+CONFIG_FIT=y
+CONFIG_DISPLAY_CPUINFO=y
+CONFIG_DISPLAY_BOARDINFO=y
+# CONFIG_CMD_MII is not set
+CONFIG_OF_PRIOR_STAGE=y
diff --git a/configs/qemu-riscv64_smode_defconfig b/configs/qemu-riscv64_smode_defconfig
new file mode 100644
index 0000000000..b012443370
--- /dev/null
+++ b/configs/qemu-riscv64_smode_defconfig
@@ -0,0 +1,11 @@
+CONFIG_RISCV=y
+CONFIG_TARGET_QEMU_VIRT=y
+CONFIG_ARCH_RV64I=y
+CONFIG_RISCV_SMODE=y
+CONFIG_DISTRO_DEFAULTS=y
+CONFIG_NR_DRAM_BANKS=1
+CONFIG_FIT=y
+CONFIG_DISPLAY_CPUINFO=y
+CONFIG_DISPLAY_BOARDINFO=y
+# CONFIG_CMD_MII is not set
+CONFIG_OF_PRIOR_STAGE=y
-- 
2.17.1

[U-Boot] [PATCH v5 4/4] riscv: Remove redundant a2 store on DRAM base in start.S

[Anup Patel]

Currently, the RISC-V U-Boot is saving a2 register at
CONFIG_SYS_DRAM_BASE in start.S which does not make sense
because there is no information passed by previous booting
stage in a2 register.

This patch removes redundant a2 store on DRAM base.

Signed-off-by: Anup Patel <anup@brainfault.org>
---
 arch/riscv/cpu/start.S | 2 --
 1 file changed, 2 deletions(-)

diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S
index 704190f946..e4276e8e19 100644
--- a/arch/riscv/cpu/start.S
+++ b/arch/riscv/cpu/start.S
@@ -38,8 +38,6 @@ _start:
 	mv	s0, a0
 	mv	s1, a1
 
-	li	t0, CONFIG_SYS_SDRAM_BASE
-	SREG	a2, 0(t0)
 	la	t0, trap_entry
 #ifdef CONFIG_RISCV_SMODE
 	csrw	stvec, t0
-- 
2.17.1

[U-Boot] [PATCH v5 4/4] riscv: Remove redundant a2 store on DRAM base in start.S

[Bin Meng]

On Mon, Nov 26, 2018 at 6:43 PM Anup Patel <anup@brainfault.org> wrote:
>
> Currently, the RISC-V U-Boot is saving a2 register at
> CONFIG_SYS_DRAM_BASE in start.S which does not make sense
> because there is no information passed by previous booting
> stage in a2 register.
>
> This patch removes redundant a2 store on DRAM base.
>
> Signed-off-by: Anup Patel <anup@brainfault.org>
> ---
>  arch/riscv/cpu/start.S | 2 --
>  1 file changed, 2 deletions(-)
>
> diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S
> index 704190f946..e4276e8e19 100644
> --- a/arch/riscv/cpu/start.S
> +++ b/arch/riscv/cpu/start.S
> @@ -38,8 +38,6 @@ _start:
>         mv      s0, a0
>         mv      s1, a1
>
> -       li      t0, CONFIG_SYS_SDRAM_BASE
> -       SREG    a2, 0(t0)
>         la      t0, trap_entry
>  #ifdef CONFIG_RISCV_SMODE
>         csrw    stvec, t0
> --

This is weird. I remember these two lines were already removed by
Lukas's patch series before? Did not have time to dig out the history
though.

Regards,
Bin

[U-Boot] [PATCH v5 4/4] riscv: Remove redundant a2 store on DRAM base in start.S

[Auer, Lukas]

On Mon, 2018-11-26 at 23:10 +0800, Bin Meng wrote:
> On Mon, Nov 26, 2018 at 6:43 PM Anup Patel <anup@brainfault.org>
> wrote:
> > 
> > Currently, the RISC-V U-Boot is saving a2 register at
> > CONFIG_SYS_DRAM_BASE in start.S which does not make sense
> > because there is no information passed by previous booting
> > stage in a2 register.
> > 
> > This patch removes redundant a2 store on DRAM base.
> > 
> > Signed-off-by: Anup Patel <anup@brainfault.org>
> > ---
> >  arch/riscv/cpu/start.S | 2 --
> >  1 file changed, 2 deletions(-)
> > 
> > diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S
> > index 704190f946..e4276e8e19 100644
> > --- a/arch/riscv/cpu/start.S
> > +++ b/arch/riscv/cpu/start.S
> > @@ -38,8 +38,6 @@ _start:
> >         mv      s0, a0
> >         mv      s1, a1
> > 
> > -       li      t0, CONFIG_SYS_SDRAM_BASE
> > -       SREG    a2, 0(t0)
> >         la      t0, trap_entry
> >  #ifdef CONFIG_RISCV_SMODE
> >         csrw    stvec, t0
> > --
> 
> This is weird. I remember these two lines were already removed by
> Lukas's patch series before? Did not have time to dig out the history
> though.
> 
> Regards,
> Bin

You are correct, however I removed it again, because I did not want to
break Rick's board. He did add a commit to the last pull request that
removes these two lines and adjusts his board accordingly, but it is
not in the current one.

Thanks,
Lukas

[U-Boot] [PATCH v5 4/4] riscv: Remove redundant a2 store on DRAM base in start.S

[Rick Chen]

> > > > Currently, the RISC-V U-Boot is saving a2 register at
> > > > CONFIG_SYS_DRAM_BASE in start.S which does not make sense because
> > > > there is no information passed by previous booting stage in a2
> > > > register.
> > > >
> > > > This patch removes redundant a2 store on DRAM base.
> > > >
> > > > Signed-off-by: Anup Patel <anup@brainfault.org>
> > > > ---
> > > >  arch/riscv/cpu/start.S | 2 --
> > > >  1 file changed, 2 deletions(-)
> > > >
> > > > diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S index
> > > > 704190f946..e4276e8e19 100644
> > > > --- a/arch/riscv/cpu/start.S
> > > > +++ b/arch/riscv/cpu/start.S
> > > > @@ -38,8 +38,6 @@ _start:
> > > >         mv      s0, a0
> > > >         mv      s1, a1
> > > >
> > > > -       li      t0, CONFIG_SYS_SDRAM_BASE
> > > > -       SREG    a2, 0(t0)
> > > >         la      t0, trap_entry
> > > >  #ifdef CONFIG_RISCV_SMODE
> > > >         csrw    stvec, t0
> > > > --
> > >
> > > This is weird. I remember these two lines were already removed by
> > > Lukas's patch series before? Did not have time to dig out the history
> > > though.
> > >

> > > Regards,
> > > Bin
> >
> > You are correct, however I removed it again, because I did not want to break
> > Rick's board. He did add a commit to the last pull request that removes these
> > two lines and adjusts his board accordingly, but it is not in the current one.
> >

Hi Likas

Thanks for your explanation.

RIck's commit as below
https://www.mail-archive.com/u-boot at lists.denx.de/msg305880.html

B.R
Rick

> > Thanks,
> > Lukas

[U-Boot] [PATCH v5 4/4] riscv: Remove redundant a2 store on DRAM base in start.S

[Anup Patel]

On Tue, Nov 27, 2018 at 8:50 AM Rick Chen <rickchen36@gmail.com> wrote:
>
> > > > > Currently, the RISC-V U-Boot is saving a2 register at
> > > > > CONFIG_SYS_DRAM_BASE in start.S which does not make sense because
> > > > > there is no information passed by previous booting stage in a2
> > > > > register.
> > > > >
> > > > > This patch removes redundant a2 store on DRAM base.
> > > > >
> > > > > Signed-off-by: Anup Patel <anup@brainfault.org>
> > > > > ---
> > > > >  arch/riscv/cpu/start.S | 2 --
> > > > >  1 file changed, 2 deletions(-)
> > > > >
> > > > > diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S index
> > > > > 704190f946..e4276e8e19 100644
> > > > > --- a/arch/riscv/cpu/start.S
> > > > > +++ b/arch/riscv/cpu/start.S
> > > > > @@ -38,8 +38,6 @@ _start:
> > > > >         mv      s0, a0
> > > > >         mv      s1, a1
> > > > >
> > > > > -       li      t0, CONFIG_SYS_SDRAM_BASE
> > > > > -       SREG    a2, 0(t0)
> > > > >         la      t0, trap_entry
> > > > >  #ifdef CONFIG_RISCV_SMODE
> > > > >         csrw    stvec, t0
> > > > > --
> > > >
> > > > This is weird. I remember these two lines were already removed by
> > > > Lukas's patch series before? Did not have time to dig out the history
> > > > though.
> > > >
>
> > > > Regards,
> > > > Bin
> > >
> > > You are correct, however I removed it again, because I did not want to break
> > > Rick's board. He did add a commit to the last pull request that removes these
> > > two lines and adjusts his board accordingly, but it is not in the current one.
> > >
>
> Hi Likas
>
> Thanks for your explanation.
>
> RIck's commit as below
> https://www.mail-archive.com/u-boot at lists.denx.de/msg305880.html

When we run U-Boot in S-mode the BBL runs from 0x80000000 so this
two lines corrupts BBL instructions.

If this is important for some board then please have it around #ifdef.

My apologies for the noise.

Regards,
Anup

[U-Boot] [PATCH v5 4/4] riscv: Remove redundant a2 store on DRAM base in start.S

[Rick Chen]

Anup Patel <anup@brainfault.org> 於 2018年11月27日 週二 上午11:28寫道：
>
> On Tue, Nov 27, 2018 at 8:50 AM Rick Chen <rickchen36@gmail.com> wrote:
> >
> > > > > > Currently, the RISC-V U-Boot is saving a2 register at
> > > > > > CONFIG_SYS_DRAM_BASE in start.S which does not make sense because
> > > > > > there is no information passed by previous booting stage in a2
> > > > > > register.
> > > > > >
> > > > > > This patch removes redundant a2 store on DRAM base.
> > > > > >
> > > > > > Signed-off-by: Anup Patel <anup@brainfault.org>
> > > > > > ---
> > > > > >  arch/riscv/cpu/start.S | 2 --
> > > > > >  1 file changed, 2 deletions(-)
> > > > > >
> > > > > > diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S index
> > > > > > 704190f946..e4276e8e19 100644
> > > > > > --- a/arch/riscv/cpu/start.S
> > > > > > +++ b/arch/riscv/cpu/start.S
> > > > > > @@ -38,8 +38,6 @@ _start:
> > > > > >         mv      s0, a0
> > > > > >         mv      s1, a1
> > > > > >
> > > > > > -       li      t0, CONFIG_SYS_SDRAM_BASE
> > > > > > -       SREG    a2, 0(t0)
> > > > > >         la      t0, trap_entry
> > > > > >  #ifdef CONFIG_RISCV_SMODE
> > > > > >         csrw    stvec, t0
> > > > > > --
> > > > >
> > > > > This is weird. I remember these two lines were already removed by
> > > > > Lukas's patch series before? Did not have time to dig out the history
> > > > > though.
> > > > >
> >
> > > > > Regards,
> > > > > Bin
> > > >
> > > > You are correct, however I removed it again, because I did not want to break
> > > > Rick's board. He did add a commit to the last pull request that removes these
> > > > two lines and adjusts his board accordingly, but it is not in the current one.
> > > >
> >
> > Hi Likas
> >
> > Thanks for your explanation.
> >
> > RIck's commit as below
> > https://www.mail-archive.com/u-boot at lists.denx.de/msg305880.html
>
> When we run U-Boot in S-mode the BBL runs from 0x80000000 so this
> two lines corrupts BBL instructions.
>
> If this is important for some board then please have it around #ifdef.
>

Hi Anup

In the discussion as below :
https://www.mail-archive.com/u-boot at lists.denx.de/msg305880.html

I try to solve this issue with the aptch
[PATCH] riscv: ax25-ae350: Pass dtb address to u-boot with a1 register
diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S
-       li      t0, CONFIG_SYS_SDRAM_BASE
-       SREG    a2, 0(t0)

diff --git a/board/AndesTech/ax25-ae350/ax25-ae350.c
b/board/AndesTech/ax25-ae350/ax25-ae350.c
 void *board_fdt_blob_setup(void)
 {
-       void **ptr = (void *)CONFIG_SYS_SDRAM_BASE;
+       void **ptr = (void *)&prior_stage_fdt_address;

in the previous pull request.

But Bin do not agree with that I use prior_stage_fdt_address in
board_fdt_blob_setup( )
I try to explain why I use it like that way.
Then Bin have not any reply in the following mail.
Finally I decide to drop this patch in the next pull request.

Hi Bin

How do you think about I recovery this patch to fix this issue ?

B.R
Rick

> My apologies for the noise.
>
> Regards,
> Anup

[U-Boot] [PATCH v5 4/4] riscv: Remove redundant a2 store on DRAM base in start.S

[Anup Patel]

On Tue, Nov 27, 2018 at 10:50 AM Rick Chen <rickchen36@gmail.com> wrote:
>
> Anup Patel <anup@brainfault.org> 於 2018年11月27日 週二 上午11:28寫道：
> >
> > On Tue, Nov 27, 2018 at 8:50 AM Rick Chen <rickchen36@gmail.com> wrote:
> > >
> > > > > > > Currently, the RISC-V U-Boot is saving a2 register at
> > > > > > > CONFIG_SYS_DRAM_BASE in start.S which does not make sense because
> > > > > > > there is no information passed by previous booting stage in a2
> > > > > > > register.
> > > > > > >
> > > > > > > This patch removes redundant a2 store on DRAM base.
> > > > > > >
> > > > > > > Signed-off-by: Anup Patel <anup@brainfault.org>
> > > > > > > ---
> > > > > > >  arch/riscv/cpu/start.S | 2 --
> > > > > > >  1 file changed, 2 deletions(-)
> > > > > > >
> > > > > > > diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S index
> > > > > > > 704190f946..e4276e8e19 100644
> > > > > > > --- a/arch/riscv/cpu/start.S
> > > > > > > +++ b/arch/riscv/cpu/start.S
> > > > > > > @@ -38,8 +38,6 @@ _start:
> > > > > > >         mv      s0, a0
> > > > > > >         mv      s1, a1
> > > > > > >
> > > > > > > -       li      t0, CONFIG_SYS_SDRAM_BASE
> > > > > > > -       SREG    a2, 0(t0)
> > > > > > >         la      t0, trap_entry
> > > > > > >  #ifdef CONFIG_RISCV_SMODE
> > > > > > >         csrw    stvec, t0
> > > > > > > --
> > > > > >
> > > > > > This is weird. I remember these two lines were already removed by
> > > > > > Lukas's patch series before? Did not have time to dig out the history
> > > > > > though.
> > > > > >
> > >
> > > > > > Regards,
> > > > > > Bin
> > > > >
> > > > > You are correct, however I removed it again, because I did not want to break
> > > > > Rick's board. He did add a commit to the last pull request that removes these
> > > > > two lines and adjusts his board accordingly, but it is not in the current one.
> > > > >
> > >
> > > Hi Likas
> > >
> > > Thanks for your explanation.
> > >
> > > RIck's commit as below
> > > https://www.mail-archive.com/u-boot at lists.denx.de/msg305880.html
> >
> > When we run U-Boot in S-mode the BBL runs from 0x80000000 so this
> > two lines corrupts BBL instructions.
> >
> > If this is important for some board then please have it around #ifdef.
> >
>
> Hi Anup
>
> In the discussion as below :
> https://www.mail-archive.com/u-boot at lists.denx.de/msg305880.html
>
> I try to solve this issue with the aptch
> [PATCH] riscv: ax25-ae350: Pass dtb address to u-boot with a1 register
> diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S
> -       li      t0, CONFIG_SYS_SDRAM_BASE
> -       SREG    a2, 0(t0)
>
> diff --git a/board/AndesTech/ax25-ae350/ax25-ae350.c
> b/board/AndesTech/ax25-ae350/ax25-ae350.c
>  void *board_fdt_blob_setup(void)
>  {
> -       void **ptr = (void *)CONFIG_SYS_SDRAM_BASE;
> +       void **ptr = (void *)&prior_stage_fdt_address;
>
> in the previous pull request.
>
> But Bin do not agree with that I use prior_stage_fdt_address in
> board_fdt_blob_setup( )
> I try to explain why I use it like that way.
> Then Bin have not any reply in the following mail.
> Finally I decide to drop this patch in the next pull request.
>
> Hi Bin
>
> How do you think about I recovery this patch to fix this issue ?

Actually, previous booting stage can pass location of FDT stored in flash
to U-Boot. U-Boot requires FDT at a DRAM location which it can modify
in-place before passing on to Linux kernel so we should relocate the FDT
passed by previous booting stage to some board specific DRAM location.

My suggestion is as follows:

Instead of SDRAM_BASE, we can have new board specific config
CONFIG_RISCV_PRIOR_FDT_BASE

If CONFIG_RISCV_PRIOR_FDT_BASE is defined/selected by
config then in start.S copy-over the FDT from location pointed by
"a1" register to location pointed by CONFIG_RISCV_PRIOR_FDT_BASE.

In your board_fdt_blob_setup(), you can safely do:
void **ptr = (void *)CONFIG_RISCV_PRIOR_FDT_BASE;

Regards,
Anup

[U-Boot] [PATCH v5 4/4] riscv: Remove redundant a2 store on DRAM base in start.S

[Anup Patel]

On Tue, Nov 27, 2018 at 11:14 AM Anup Patel <anup@brainfault.org> wrote:
>
> On Tue, Nov 27, 2018 at 10:50 AM Rick Chen <rickchen36@gmail.com> wrote:
> >
> > Anup Patel <anup@brainfault.org> 於 2018年11月27日 週二 上午11:28寫道：
> > >
> > > On Tue, Nov 27, 2018 at 8:50 AM Rick Chen <rickchen36@gmail.com> wrote:
> > > >
> > > > > > > > Currently, the RISC-V U-Boot is saving a2 register at
> > > > > > > > CONFIG_SYS_DRAM_BASE in start.S which does not make sense because
> > > > > > > > there is no information passed by previous booting stage in a2
> > > > > > > > register.
> > > > > > > >
> > > > > > > > This patch removes redundant a2 store on DRAM base.
> > > > > > > >
> > > > > > > > Signed-off-by: Anup Patel <anup@brainfault.org>
> > > > > > > > ---
> > > > > > > >  arch/riscv/cpu/start.S | 2 --
> > > > > > > >  1 file changed, 2 deletions(-)
> > > > > > > >
> > > > > > > > diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S index
> > > > > > > > 704190f946..e4276e8e19 100644
> > > > > > > > --- a/arch/riscv/cpu/start.S
> > > > > > > > +++ b/arch/riscv/cpu/start.S
> > > > > > > > @@ -38,8 +38,6 @@ _start:
> > > > > > > >         mv      s0, a0
> > > > > > > >         mv      s1, a1
> > > > > > > >
> > > > > > > > -       li      t0, CONFIG_SYS_SDRAM_BASE
> > > > > > > > -       SREG    a2, 0(t0)
> > > > > > > >         la      t0, trap_entry
> > > > > > > >  #ifdef CONFIG_RISCV_SMODE
> > > > > > > >         csrw    stvec, t0
> > > > > > > > --
> > > > > > >
> > > > > > > This is weird. I remember these two lines were already removed by
> > > > > > > Lukas's patch series before? Did not have time to dig out the history
> > > > > > > though.
> > > > > > >
> > > >
> > > > > > > Regards,
> > > > > > > Bin
> > > > > >
> > > > > > You are correct, however I removed it again, because I did not want to break
> > > > > > Rick's board. He did add a commit to the last pull request that removes these
> > > > > > two lines and adjusts his board accordingly, but it is not in the current one.
> > > > > >
> > > >
> > > > Hi Likas
> > > >
> > > > Thanks for your explanation.
> > > >
> > > > RIck's commit as below
> > > > https://www.mail-archive.com/u-boot at lists.denx.de/msg305880.html
> > >
> > > When we run U-Boot in S-mode the BBL runs from 0x80000000 so this
> > > two lines corrupts BBL instructions.
> > >
> > > If this is important for some board then please have it around #ifdef.
> > >
> >
> > Hi Anup
> >
> > In the discussion as below :
> > https://www.mail-archive.com/u-boot at lists.denx.de/msg305880.html
> >
> > I try to solve this issue with the aptch
> > [PATCH] riscv: ax25-ae350: Pass dtb address to u-boot with a1 register
> > diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S
> > -       li      t0, CONFIG_SYS_SDRAM_BASE
> > -       SREG    a2, 0(t0)
> >
> > diff --git a/board/AndesTech/ax25-ae350/ax25-ae350.c
> > b/board/AndesTech/ax25-ae350/ax25-ae350.c
> >  void *board_fdt_blob_setup(void)
> >  {
> > -       void **ptr = (void *)CONFIG_SYS_SDRAM_BASE;
> > +       void **ptr = (void *)&prior_stage_fdt_address;
> >
> > in the previous pull request.
> >
> > But Bin do not agree with that I use prior_stage_fdt_address in
> > board_fdt_blob_setup( )
> > I try to explain why I use it like that way.
> > Then Bin have not any reply in the following mail.
> > Finally I decide to drop this patch in the next pull request.
> >
> > Hi Bin
> >
> > How do you think about I recovery this patch to fix this issue ?
>
> Actually, previous booting stage can pass location of FDT stored in flash
> to U-Boot. U-Boot requires FDT at a DRAM location which it can modify
> in-place before passing on to Linux kernel so we should relocate the FDT
> passed by previous booting stage to some board specific DRAM location.
>
> My suggestion is as follows:
>
> Instead of SDRAM_BASE, we can have new board specific config
> CONFIG_RISCV_PRIOR_FDT_BASE
>
> If CONFIG_RISCV_PRIOR_FDT_BASE is defined/selected by
> config then in start.S copy-over the FDT from location pointed by
> "a1" register to location pointed by CONFIG_RISCV_PRIOR_FDT_BASE.

I think you can copy-over FDT in C code too. You don't need to do
in start.S.

>
> In your board_fdt_blob_setup(), you can safely do:
> void **ptr = (void *)CONFIG_RISCV_PRIOR_FDT_BASE;
>
> Regards,
> Anup

[U-Boot] [PATCH v5 4/4] riscv: Remove redundant a2 store on DRAM base in start.S

[Rick Chen]

Anup Patel <anup@brainfault.org> 於 2018年11月27日 週二 下午1:47寫道：
>
> On Tue, Nov 27, 2018 at 11:14 AM Anup Patel <anup@brainfault.org> wrote:
> >
> > On Tue, Nov 27, 2018 at 10:50 AM Rick Chen <rickchen36@gmail.com> wrote:
> > >
> > > Anup Patel <anup@brainfault.org> 於 2018年11月27日 週二 上午11:28寫道：
> > > >
> > > > On Tue, Nov 27, 2018 at 8:50 AM Rick Chen <rickchen36@gmail.com> wrote:
> > > > >
> > > > > > > > > Currently, the RISC-V U-Boot is saving a2 register at
> > > > > > > > > CONFIG_SYS_DRAM_BASE in start.S which does not make sense because
> > > > > > > > > there is no information passed by previous booting stage in a2
> > > > > > > > > register.
> > > > > > > > >
> > > > > > > > > This patch removes redundant a2 store on DRAM base.
> > > > > > > > >
> > > > > > > > > Signed-off-by: Anup Patel <anup@brainfault.org>
> > > > > > > > > ---
> > > > > > > > >  arch/riscv/cpu/start.S | 2 --
> > > > > > > > >  1 file changed, 2 deletions(-)
> > > > > > > > >
> > > > > > > > > diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S index
> > > > > > > > > 704190f946..e4276e8e19 100644
> > > > > > > > > --- a/arch/riscv/cpu/start.S
> > > > > > > > > +++ b/arch/riscv/cpu/start.S
> > > > > > > > > @@ -38,8 +38,6 @@ _start:
> > > > > > > > >         mv      s0, a0
> > > > > > > > >         mv      s1, a1
> > > > > > > > >
> > > > > > > > > -       li      t0, CONFIG_SYS_SDRAM_BASE
> > > > > > > > > -       SREG    a2, 0(t0)
> > > > > > > > >         la      t0, trap_entry
> > > > > > > > >  #ifdef CONFIG_RISCV_SMODE
> > > > > > > > >         csrw    stvec, t0
> > > > > > > > > --
> > > > > > > >
> > > > > > > > This is weird. I remember these two lines were already removed by
> > > > > > > > Lukas's patch series before? Did not have time to dig out the history
> > > > > > > > though.
> > > > > > > >
> > > > >
> > > > > > > > Regards,
> > > > > > > > Bin
> > > > > > >
> > > > > > > You are correct, however I removed it again, because I did not want to break
> > > > > > > Rick's board. He did add a commit to the last pull request that removes these
> > > > > > > two lines and adjusts his board accordingly, but it is not in the current one.
> > > > > > >
> > > > >
> > > > > Hi Likas
> > > > >
> > > > > Thanks for your explanation.
> > > > >
> > > > > RIck's commit as below
> > > > > https://www.mail-archive.com/u-boot at lists.denx.de/msg305880.html
> > > >
> > > > When we run U-Boot in S-mode the BBL runs from 0x80000000 so this
> > > > two lines corrupts BBL instructions.
> > > >
> > > > If this is important for some board then please have it around #ifdef.
> > > >
> > >
> > > Hi Anup
> > >
> > > In the discussion as below :
> > > https://www.mail-archive.com/u-boot at lists.denx.de/msg305880.html
> > >
> > > I try to solve this issue with the aptch
> > > [PATCH] riscv: ax25-ae350: Pass dtb address to u-boot with a1 register
> > > diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S
> > > -       li      t0, CONFIG_SYS_SDRAM_BASE
> > > -       SREG    a2, 0(t0)
> > >
> > > diff --git a/board/AndesTech/ax25-ae350/ax25-ae350.c
> > > b/board/AndesTech/ax25-ae350/ax25-ae350.c
> > >  void *board_fdt_blob_setup(void)
> > >  {
> > > -       void **ptr = (void *)CONFIG_SYS_SDRAM_BASE;
> > > +       void **ptr = (void *)&prior_stage_fdt_address;
> > >
> > > in the previous pull request.
> > >
> > > But Bin do not agree with that I use prior_stage_fdt_address in
> > > board_fdt_blob_setup( )
> > > I try to explain why I use it like that way.
> > > Then Bin have not any reply in the following mail.
> > > Finally I decide to drop this patch in the next pull request.
> > >
> > > Hi Bin
> > >
> > > How do you think about I recovery this patch to fix this issue ?
> >
> > Actually, previous booting stage can pass location of FDT stored in flash
> > to U-Boot. U-Boot requires FDT at a DRAM location which it can modify
> > in-place before passing on to Linux kernel so we should relocate the FDT
> > passed by previous booting stage to some board specific DRAM location.
> >
> > My suggestion is as follows:
> >
> > Instead of SDRAM_BASE, we can have new board specific config
> > CONFIG_RISCV_PRIOR_FDT_BASE
> >
> > If CONFIG_RISCV_PRIOR_FDT_BASE is defined/selected by
> > config then in start.S copy-over the FDT from location pointed by
> > "a1" register to location pointed by CONFIG_RISCV_PRIOR_FDT_BASE.
>

Hi Anup

It can not achieve dtb delivery at runtime.

Rick

> I think you can copy-over FDT in C code too. You don't need to do
> in start.S.
>
> >
> > In your board_fdt_blob_setup(), you can safely do:
> > void **ptr = (void *)CONFIG_RISCV_PRIOR_FDT_BASE;
> >
> > Regards,
> > Anup

[U-Boot] [PATCH v5 4/4] riscv: Remove redundant a2 store on DRAM base in start.S

[Anup Patel]

On Tue, 27 Nov, 2018, 11:38 AM Rick Chen <rickchen36@gmail.com wrote:

> Anup Patel <anup@brainfault.org> 於 2018年11月27日 週二 下午1:47寫道：
> >
> > On Tue, Nov 27, 2018 at 11:14 AM Anup Patel <anup@brainfault.org> wrote:
> > >
> > > On Tue, Nov 27, 2018 at 10:50 AM Rick Chen <rickchen36@gmail.com>
> wrote:
> > > >
> > > > Anup Patel <anup@brainfault.org> 於 2018年11月27日 週二 上午11:28寫道：
> > > > >
> > > > > On Tue, Nov 27, 2018 at 8:50 AM Rick Chen <rickchen36@gmail.com>
> wrote:
> > > > > >
> > > > > > > > > > Currently, the RISC-V U-Boot is saving a2 register at
> > > > > > > > > > CONFIG_SYS_DRAM_BASE in start.S which does not make
> sense because
> > > > > > > > > > there is no information passed by previous booting stage
> in a2
> > > > > > > > > > register.
> > > > > > > > > >
> > > > > > > > > > This patch removes redundant a2 store on DRAM base.
> > > > > > > > > >
> > > > > > > > > > Signed-off-by: Anup Patel <anup@brainfault.org>
> > > > > > > > > > ---
> > > > > > > > > >  arch/riscv/cpu/start.S | 2 --
> > > > > > > > > >  1 file changed, 2 deletions(-)
> > > > > > > > > >
> > > > > > > > > > diff --git a/arch/riscv/cpu/start.S
> b/arch/riscv/cpu/start.S index
> > > > > > > > > > 704190f946..e4276e8e19 100644
> > > > > > > > > > --- a/arch/riscv/cpu/start.S
> > > > > > > > > > +++ b/arch/riscv/cpu/start.S
> > > > > > > > > > @@ -38,8 +38,6 @@ _start:
> > > > > > > > > >         mv      s0, a0
> > > > > > > > > >         mv      s1, a1
> > > > > > > > > >
> > > > > > > > > > -       li      t0, CONFIG_SYS_SDRAM_BASE
> > > > > > > > > > -       SREG    a2, 0(t0)
> > > > > > > > > >         la      t0, trap_entry
> > > > > > > > > >  #ifdef CONFIG_RISCV_SMODE
> > > > > > > > > >         csrw    stvec, t0
> > > > > > > > > > --
> > > > > > > > >
> > > > > > > > > This is weird. I remember these two lines were already
> removed by
> > > > > > > > > Lukas's patch series before? Did not have time to dig out
> the history
> > > > > > > > > though.
> > > > > > > > >
> > > > > >
> > > > > > > > > Regards,
> > > > > > > > > Bin
> > > > > > > >
> > > > > > > > You are correct, however I removed it again, because I did
> not want to break
> > > > > > > > Rick's board. He did add a commit to the last pull request
> that removes these
> > > > > > > > two lines and adjusts his board accordingly, but it is not
> in the current one.
> > > > > > > >
> > > > > >
> > > > > > Hi Likas
> > > > > >
> > > > > > Thanks for your explanation.
> > > > > >
> > > > > > RIck's commit as below
> > > > > > https://www.mail-archive.com/u-boot at lists.denx.de/msg305880.html
> > > > >
> > > > > When we run U-Boot in S-mode the BBL runs from 0x80000000 so this
> > > > > two lines corrupts BBL instructions.
> > > > >
> > > > > If this is important for some board then please have it around
> #ifdef.
> > > > >
> > > >
> > > > Hi Anup
> > > >
> > > > In the discussion as below :
> > > > https://www.mail-archive.com/u-boot at lists.denx.de/msg305880.html
> > > >
> > > > I try to solve this issue with the aptch
> > > > [PATCH] riscv: ax25-ae350: Pass dtb address to u-boot with a1
> register
> > > > diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S
> > > > -       li      t0, CONFIG_SYS_SDRAM_BASE
> > > > -       SREG    a2, 0(t0)
> > > >
> > > > diff --git a/board/AndesTech/ax25-ae350/ax25-ae350.c
> > > > b/board/AndesTech/ax25-ae350/ax25-ae350.c
> > > >  void *board_fdt_blob_setup(void)
> > > >  {
> > > > -       void **ptr = (void *)CONFIG_SYS_SDRAM_BASE;
> > > > +       void **ptr = (void *)&prior_stage_fdt_address;
> > > >
> > > > in the previous pull request.
> > > >
> > > > But Bin do not agree with that I use prior_stage_fdt_address in
> > > > board_fdt_blob_setup( )
> > > > I try to explain why I use it like that way.
> > > > Then Bin have not any reply in the following mail.
> > > > Finally I decide to drop this patch in the next pull request.
> > > >
> > > > Hi Bin
> > > >
> > > > How do you think about I recovery this patch to fix this issue ?
> > >
> > > Actually, previous booting stage can pass location of FDT stored in
> flash
> > > to U-Boot. U-Boot requires FDT at a DRAM location which it can modify
> > > in-place before passing on to Linux kernel so we should relocate the
> FDT
> > > passed by previous booting stage to some board specific DRAM location.
> > >
> > > My suggestion is as follows:
> > >
> > > Instead of SDRAM_BASE, we can have new board specific config
> > > CONFIG_RISCV_PRIOR_FDT_BASE
> > >
> > > If CONFIG_RISCV_PRIOR_FDT_BASE is defined/selected by
> > > config then in start.S copy-over the FDT from location pointed by
> > > "a1" register to location pointed by CONFIG_RISCV_PRIOR_FDT_BASE.
> >
>
> Hi Anup
>
> It can not achieve dtb delivery at runtime.
>

Can you elaborate why?

I am sure we can always relocate FDT passed by previous stage to some safer
location and use it from there.

Regards,
Anup


> Rick
>
> > I think you can copy-over FDT in C code too. You don't need to do
> > in start.S.
> >
> > >
> > > In your board_fdt_blob_setup(), you can safely do:
> > > void **ptr = (void *)CONFIG_RISCV_PRIOR_FDT_BASE;
> > >
> > > Regards,
> > > Anup
>

[U-Boot] [PATCH v5 4/4] riscv: Remove redundant a2 store on DRAM base in start.S

[Rick Chen]

Anup Patel <anup@brainfault.org> 於 2018年11月27日 週二 下午2:14寫道：
>
>
>
> On Tue, 27 Nov, 2018, 11:38 AM Rick Chen <rickchen36@gmail.com wrote:
>>
>> Anup Patel <anup@brainfault.org> 於 2018年11月27日 週二 下午1:47寫道：
>> >
>> > On Tue, Nov 27, 2018 at 11:14 AM Anup Patel <anup@brainfault.org> wrote:
>> > >
>> > > On Tue, Nov 27, 2018 at 10:50 AM Rick Chen <rickchen36@gmail.com> wrote:
>> > > >
>> > > > Anup Patel <anup@brainfault.org> 於 2018年11月27日 週二 上午11:28寫道：
>> > > > >
>> > > > > On Tue, Nov 27, 2018 at 8:50 AM Rick Chen <rickchen36@gmail.com> wrote:
>> > > > > >
>> > > > > > > > > > Currently, the RISC-V U-Boot is saving a2 register at
>> > > > > > > > > > CONFIG_SYS_DRAM_BASE in start.S which does not make sense because
>> > > > > > > > > > there is no information passed by previous booting stage in a2
>> > > > > > > > > > register.
>> > > > > > > > > >
>> > > > > > > > > > This patch removes redundant a2 store on DRAM base.
>> > > > > > > > > >
>> > > > > > > > > > Signed-off-by: Anup Patel <anup@brainfault.org>
>> > > > > > > > > > ---
>> > > > > > > > > >  arch/riscv/cpu/start.S | 2 --
>> > > > > > > > > >  1 file changed, 2 deletions(-)
>> > > > > > > > > >
>> > > > > > > > > > diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S index
>> > > > > > > > > > 704190f946..e4276e8e19 100644
>> > > > > > > > > > --- a/arch/riscv/cpu/start.S
>> > > > > > > > > > +++ b/arch/riscv/cpu/start.S
>> > > > > > > > > > @@ -38,8 +38,6 @@ _start:
>> > > > > > > > > >         mv      s0, a0
>> > > > > > > > > >         mv      s1, a1
>> > > > > > > > > >
>> > > > > > > > > > -       li      t0, CONFIG_SYS_SDRAM_BASE
>> > > > > > > > > > -       SREG    a2, 0(t0)
>> > > > > > > > > >         la      t0, trap_entry
>> > > > > > > > > >  #ifdef CONFIG_RISCV_SMODE
>> > > > > > > > > >         csrw    stvec, t0
>> > > > > > > > > > --
>> > > > > > > > >
>> > > > > > > > > This is weird. I remember these two lines were already removed by
>> > > > > > > > > Lukas's patch series before? Did not have time to dig out the history
>> > > > > > > > > though.
>> > > > > > > > >
>> > > > > >
>> > > > > > > > > Regards,
>> > > > > > > > > Bin
>> > > > > > > >
>> > > > > > > > You are correct, however I removed it again, because I did not want to break
>> > > > > > > > Rick's board. He did add a commit to the last pull request that removes these
>> > > > > > > > two lines and adjusts his board accordingly, but it is not in the current one.
>> > > > > > > >
>> > > > > >
>> > > > > > Hi Likas
>> > > > > >
>> > > > > > Thanks for your explanation.
>> > > > > >
>> > > > > > RIck's commit as below
>> > > > > > https://www.mail-archive.com/u-boot at lists.denx.de/msg305880.html
>> > > > >
>> > > > > When we run U-Boot in S-mode the BBL runs from 0x80000000 so this
>> > > > > two lines corrupts BBL instructions.
>> > > > >
>> > > > > If this is important for some board then please have it around #ifdef.
>> > > > >
>> > > >
>> > > > Hi Anup
>> > > >
>> > > > In the discussion as below :
>> > > > https://www.mail-archive.com/u-boot at lists.denx.de/msg305880.html
>> > > >
>> > > > I try to solve this issue with the aptch
>> > > > [PATCH] riscv: ax25-ae350: Pass dtb address to u-boot with a1 register
>> > > > diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S
>> > > > -       li      t0, CONFIG_SYS_SDRAM_BASE
>> > > > -       SREG    a2, 0(t0)
>> > > >
>> > > > diff --git a/board/AndesTech/ax25-ae350/ax25-ae350.c
>> > > > b/board/AndesTech/ax25-ae350/ax25-ae350.c
>> > > >  void *board_fdt_blob_setup(void)
>> > > >  {
>> > > > -       void **ptr = (void *)CONFIG_SYS_SDRAM_BASE;
>> > > > +       void **ptr = (void *)&prior_stage_fdt_address;
>> > > >
>> > > > in the previous pull request.
>> > > >
>> > > > But Bin do not agree with that I use prior_stage_fdt_address in
>> > > > board_fdt_blob_setup( )
>> > > > I try to explain why I use it like that way.
>> > > > Then Bin have not any reply in the following mail.
>> > > > Finally I decide to drop this patch in the next pull request.
>> > > >
>> > > > Hi Bin
>> > > >
>> > > > How do you think about I recovery this patch to fix this issue ?
>> > >
>> > > Actually, previous booting stage can pass location of FDT stored in flash
>> > > to U-Boot. U-Boot requires FDT at a DRAM location which it can modify
>> > > in-place before passing on to Linux kernel so we should relocate the FDT
>> > > passed by previous booting stage to some board specific DRAM location.
>> > >
>> > > My suggestion is as follows:
>> > >
>> > > Instead of SDRAM_BASE, we can have new board specific config
>> > > CONFIG_RISCV_PRIOR_FDT_BASE
>> > >
>> > > If CONFIG_RISCV_PRIOR_FDT_BASE is defined/selected by
>> > > config then in start.S copy-over the FDT from location pointed by
>> > > "a1" register to location pointed by CONFIG_RISCV_PRIOR_FDT_BASE.
>> >
>>
>> Hi Anup
>>
>> It can not achieve dtb delivery at runtime.
>
>
> Can you elaborate why?
>

CONFIG_RISCV_PRIOR_FDT_BASE is determined at compile time.
I am wondering how it can be modified at run time ?


> I am sure we can always relocate FDT passed by previous stage to some safer location and use it from there.

My original patch also can achieve that dtb passed by a1 and relocated and boot.

>
> Regards,
> Anup
>
>>
>> Rick
>>
>> > I think you can copy-over FDT in C code too. You don't need to do
>> > in start.S.
>> >
>> > >
>> > > In your board_fdt_blob_setup(), you can safely do:
>> > > void **ptr = (void *)CONFIG_RISCV_PRIOR_FDT_BASE;
>> > >
>> > > Regards,
>> > > Anup

[U-Boot] [PATCH v5 4/4] riscv: Remove redundant a2 store on DRAM base in start.S

[Anup Patel]

On Tue, Nov 27, 2018 at 12:00 PM Rick Chen <rickchen36@gmail.com> wrote:
>
> Anup Patel <anup@brainfault.org> 於 2018年11月27日 週二 下午2:14寫道：
> >
> >
> >
> > On Tue, 27 Nov, 2018, 11:38 AM Rick Chen <rickchen36@gmail.com wrote:
> >>
> >> Anup Patel <anup@brainfault.org> 於 2018年11月27日 週二 下午1:47寫道：
> >> >
> >> > On Tue, Nov 27, 2018 at 11:14 AM Anup Patel <anup@brainfault.org> wrote:
> >> > >
> >> > > On Tue, Nov 27, 2018 at 10:50 AM Rick Chen <rickchen36@gmail.com> wrote:
> >> > > >
> >> > > > Anup Patel <anup@brainfault.org> 於 2018年11月27日 週二 上午11:28寫道：
> >> > > > >
> >> > > > > On Tue, Nov 27, 2018 at 8:50 AM Rick Chen <rickchen36@gmail.com> wrote:
> >> > > > > >
> >> > > > > > > > > > Currently, the RISC-V U-Boot is saving a2 register at
> >> > > > > > > > > > CONFIG_SYS_DRAM_BASE in start.S which does not make sense because
> >> > > > > > > > > > there is no information passed by previous booting stage in a2
> >> > > > > > > > > > register.
> >> > > > > > > > > >
> >> > > > > > > > > > This patch removes redundant a2 store on DRAM base.
> >> > > > > > > > > >
> >> > > > > > > > > > Signed-off-by: Anup Patel <anup@brainfault.org>
> >> > > > > > > > > > ---
> >> > > > > > > > > >  arch/riscv/cpu/start.S | 2 --
> >> > > > > > > > > >  1 file changed, 2 deletions(-)
> >> > > > > > > > > >
> >> > > > > > > > > > diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S index
> >> > > > > > > > > > 704190f946..e4276e8e19 100644
> >> > > > > > > > > > --- a/arch/riscv/cpu/start.S
> >> > > > > > > > > > +++ b/arch/riscv/cpu/start.S
> >> > > > > > > > > > @@ -38,8 +38,6 @@ _start:
> >> > > > > > > > > >         mv      s0, a0
> >> > > > > > > > > >         mv      s1, a1
> >> > > > > > > > > >
> >> > > > > > > > > > -       li      t0, CONFIG_SYS_SDRAM_BASE
> >> > > > > > > > > > -       SREG    a2, 0(t0)
> >> > > > > > > > > >         la      t0, trap_entry
> >> > > > > > > > > >  #ifdef CONFIG_RISCV_SMODE
> >> > > > > > > > > >         csrw    stvec, t0
> >> > > > > > > > > > --
> >> > > > > > > > >
> >> > > > > > > > > This is weird. I remember these two lines were already removed by
> >> > > > > > > > > Lukas's patch series before? Did not have time to dig out the history
> >> > > > > > > > > though.
> >> > > > > > > > >
> >> > > > > >
> >> > > > > > > > > Regards,
> >> > > > > > > > > Bin
> >> > > > > > > >
> >> > > > > > > > You are correct, however I removed it again, because I did not want to break
> >> > > > > > > > Rick's board. He did add a commit to the last pull request that removes these
> >> > > > > > > > two lines and adjusts his board accordingly, but it is not in the current one.
> >> > > > > > > >
> >> > > > > >
> >> > > > > > Hi Likas
> >> > > > > >
> >> > > > > > Thanks for your explanation.
> >> > > > > >
> >> > > > > > RIck's commit as below
> >> > > > > > https://www.mail-archive.com/u-boot at lists.denx.de/msg305880.html
> >> > > > >
> >> > > > > When we run U-Boot in S-mode the BBL runs from 0x80000000 so this
> >> > > > > two lines corrupts BBL instructions.
> >> > > > >
> >> > > > > If this is important for some board then please have it around #ifdef.
> >> > > > >
> >> > > >
> >> > > > Hi Anup
> >> > > >
> >> > > > In the discussion as below :
> >> > > > https://www.mail-archive.com/u-boot at lists.denx.de/msg305880.html
> >> > > >
> >> > > > I try to solve this issue with the aptch
> >> > > > [PATCH] riscv: ax25-ae350: Pass dtb address to u-boot with a1 register
> >> > > > diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S
> >> > > > -       li      t0, CONFIG_SYS_SDRAM_BASE
> >> > > > -       SREG    a2, 0(t0)
> >> > > >
> >> > > > diff --git a/board/AndesTech/ax25-ae350/ax25-ae350.c
> >> > > > b/board/AndesTech/ax25-ae350/ax25-ae350.c
> >> > > >  void *board_fdt_blob_setup(void)
> >> > > >  {
> >> > > > -       void **ptr = (void *)CONFIG_SYS_SDRAM_BASE;
> >> > > > +       void **ptr = (void *)&prior_stage_fdt_address;
> >> > > >
> >> > > > in the previous pull request.
> >> > > >
> >> > > > But Bin do not agree with that I use prior_stage_fdt_address in
> >> > > > board_fdt_blob_setup( )
> >> > > > I try to explain why I use it like that way.
> >> > > > Then Bin have not any reply in the following mail.
> >> > > > Finally I decide to drop this patch in the next pull request.
> >> > > >
> >> > > > Hi Bin
> >> > > >
> >> > > > How do you think about I recovery this patch to fix this issue ?
> >> > >
> >> > > Actually, previous booting stage can pass location of FDT stored in flash
> >> > > to U-Boot. U-Boot requires FDT at a DRAM location which it can modify
> >> > > in-place before passing on to Linux kernel so we should relocate the FDT
> >> > > passed by previous booting stage to some board specific DRAM location.
> >> > >
> >> > > My suggestion is as follows:
> >> > >
> >> > > Instead of SDRAM_BASE, we can have new board specific config
> >> > > CONFIG_RISCV_PRIOR_FDT_BASE
> >> > >
> >> > > If CONFIG_RISCV_PRIOR_FDT_BASE is defined/selected by
> >> > > config then in start.S copy-over the FDT from location pointed by
> >> > > "a1" register to location pointed by CONFIG_RISCV_PRIOR_FDT_BASE.
> >> >
> >>
> >> Hi Anup
> >>
> >> It can not achieve dtb delivery at runtime.
> >
> >
> > Can you elaborate why?
> >
>
> CONFIG_RISCV_PRIOR_FDT_BASE is determined at compile time.
> I am wondering how it can be modified at run time ?

I think you miss-understood my suggestion. I did not meant changing
CONFIG_RISCV_PRIOR_FDT_BASE at runtime.

>
>
> > I am sure we can always relocate FDT passed by previous stage to some safer location and use it from there.
>
> My original patch also can achieve that dtb passed by a1 and relocated and boot.

Great !!!

Why not update your original patch to relocate FDT and use FDT from
safer location?

My intention is to have these two lines removed from start.S so that
U-Boot S-mode
works fine on QEMU.

Regards,
Anup

[U-Boot] [PATCH v5 4/4] riscv: Remove redundant a2 store on DRAM base in start.S

[Rick Chen]

Anup Patel <anup@brainfault.org> 於 2018年11月27日 週二 下午2:40寫道：
>
> On Tue, Nov 27, 2018 at 12:00 PM Rick Chen <rickchen36@gmail.com> wrote:
> >
> > Anup Patel <anup@brainfault.org> 於 2018年11月27日 週二 下午2:14寫道：
> > >
> > >
> > >
> > > On Tue, 27 Nov, 2018, 11:38 AM Rick Chen <rickchen36@gmail.com wrote:
> > >>
> > >> Anup Patel <anup@brainfault.org> 於 2018年11月27日 週二 下午1:47寫道：
> > >> >
> > >> > On Tue, Nov 27, 2018 at 11:14 AM Anup Patel <anup@brainfault.org> wrote:
> > >> > >
> > >> > > On Tue, Nov 27, 2018 at 10:50 AM Rick Chen <rickchen36@gmail.com> wrote:
> > >> > > >
> > >> > > > Anup Patel <anup@brainfault.org> 於 2018年11月27日 週二 上午11:28寫道：
> > >> > > > >
> > >> > > > > On Tue, Nov 27, 2018 at 8:50 AM Rick Chen <rickchen36@gmail.com> wrote:
> > >> > > > > >
> > >> > > > > > > > > > Currently, the RISC-V U-Boot is saving a2 register at
> > >> > > > > > > > > > CONFIG_SYS_DRAM_BASE in start.S which does not make sense because
> > >> > > > > > > > > > there is no information passed by previous booting stage in a2
> > >> > > > > > > > > > register.
> > >> > > > > > > > > >
> > >> > > > > > > > > > This patch removes redundant a2 store on DRAM base.
> > >> > > > > > > > > >
> > >> > > > > > > > > > Signed-off-by: Anup Patel <anup@brainfault.org>
> > >> > > > > > > > > > ---
> > >> > > > > > > > > >  arch/riscv/cpu/start.S | 2 --
> > >> > > > > > > > > >  1 file changed, 2 deletions(-)
> > >> > > > > > > > > >
> > >> > > > > > > > > > diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S index
> > >> > > > > > > > > > 704190f946..e4276e8e19 100644
> > >> > > > > > > > > > --- a/arch/riscv/cpu/start.S
> > >> > > > > > > > > > +++ b/arch/riscv/cpu/start.S
> > >> > > > > > > > > > @@ -38,8 +38,6 @@ _start:
> > >> > > > > > > > > >         mv      s0, a0
> > >> > > > > > > > > >         mv      s1, a1
> > >> > > > > > > > > >
> > >> > > > > > > > > > -       li      t0, CONFIG_SYS_SDRAM_BASE
> > >> > > > > > > > > > -       SREG    a2, 0(t0)
> > >> > > > > > > > > >         la      t0, trap_entry
> > >> > > > > > > > > >  #ifdef CONFIG_RISCV_SMODE
> > >> > > > > > > > > >         csrw    stvec, t0
> > >> > > > > > > > > > --
> > >> > > > > > > > >
> > >> > > > > > > > > This is weird. I remember these two lines were already removed by
> > >> > > > > > > > > Lukas's patch series before? Did not have time to dig out the history
> > >> > > > > > > > > though.
> > >> > > > > > > > >
> > >> > > > > >
> > >> > > > > > > > > Regards,
> > >> > > > > > > > > Bin
> > >> > > > > > > >
> > >> > > > > > > > You are correct, however I removed it again, because I did not want to break
> > >> > > > > > > > Rick's board. He did add a commit to the last pull request that removes these
> > >> > > > > > > > two lines and adjusts his board accordingly, but it is not in the current one.
> > >> > > > > > > >
> > >> > > > > >
> > >> > > > > > Hi Likas
> > >> > > > > >
> > >> > > > > > Thanks for your explanation.
> > >> > > > > >
> > >> > > > > > RIck's commit as below
> > >> > > > > > https://www.mail-archive.com/u-boot at lists.denx.de/msg305880.html
> > >> > > > >
> > >> > > > > When we run U-Boot in S-mode the BBL runs from 0x80000000 so this
> > >> > > > > two lines corrupts BBL instructions.
> > >> > > > >
> > >> > > > > If this is important for some board then please have it around #ifdef.
> > >> > > > >
> > >> > > >
> > >> > > > Hi Anup
> > >> > > >
> > >> > > > In the discussion as below :
> > >> > > > https://www.mail-archive.com/u-boot at lists.denx.de/msg305880.html
> > >> > > >
> > >> > > > I try to solve this issue with the aptch
> > >> > > > [PATCH] riscv: ax25-ae350: Pass dtb address to u-boot with a1 register
> > >> > > > diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S
> > >> > > > -       li      t0, CONFIG_SYS_SDRAM_BASE
> > >> > > > -       SREG    a2, 0(t0)
> > >> > > >
> > >> > > > diff --git a/board/AndesTech/ax25-ae350/ax25-ae350.c
> > >> > > > b/board/AndesTech/ax25-ae350/ax25-ae350.c
> > >> > > >  void *board_fdt_blob_setup(void)
> > >> > > >  {
> > >> > > > -       void **ptr = (void *)CONFIG_SYS_SDRAM_BASE;
> > >> > > > +       void **ptr = (void *)&prior_stage_fdt_address;
> > >> > > >
> > >> > > > in the previous pull request.
> > >> > > >
> > >> > > > But Bin do not agree with that I use prior_stage_fdt_address in
> > >> > > > board_fdt_blob_setup( )
> > >> > > > I try to explain why I use it like that way.
> > >> > > > Then Bin have not any reply in the following mail.
> > >> > > > Finally I decide to drop this patch in the next pull request.
> > >> > > >
> > >> > > > Hi Bin
> > >> > > >
> > >> > > > How do you think about I recovery this patch to fix this issue ?
> > >> > >
> > >> > > Actually, previous booting stage can pass location of FDT stored in flash
> > >> > > to U-Boot. U-Boot requires FDT at a DRAM location which it can modify
> > >> > > in-place before passing on to Linux kernel so we should relocate the FDT
> > >> > > passed by previous booting stage to some board specific DRAM location.
> > >> > >
> > >> > > My suggestion is as follows:
> > >> > >
> > >> > > Instead of SDRAM_BASE, we can have new board specific config
> > >> > > CONFIG_RISCV_PRIOR_FDT_BASE
> > >> > >
> > >> > > If CONFIG_RISCV_PRIOR_FDT_BASE is defined/selected by
> > >> > > config then in start.S copy-over the FDT from location pointed by
> > >> > > "a1" register to location pointed by CONFIG_RISCV_PRIOR_FDT_BASE.
> > >> >
> > >>
> > >> Hi Anup
> > >>
> > >> It can not achieve dtb delivery at runtime.
> > >
> > >
> > > Can you elaborate why?
> > >
> >
> > CONFIG_RISCV_PRIOR_FDT_BASE is determined at compile time.
> > I am wondering how it can be modified at run time ?
>
> I think you miss-understood my suggestion. I did not meant changing
> CONFIG_RISCV_PRIOR_FDT_BASE at runtime.
>
> >
> >
> > > I am sure we can always relocate FDT passed by previous stage to some safer location and use it from there.
> >
> > My original patch also can achieve that dtb passed by a1 and relocated and boot.
>
> Great !!!
>
> Why not update your original patch to relocate FDT and use FDT from
> safer location?
>

Good question.
Above can see the question I ask for Bin :
How do you think about I recovery this patch to fix this issue ?

Before you talking about CONFIG_RISCV_PRIOR_FDT_BASE !

> My intention is to have these two lines removed from start.S so that
> U-Boot S-mode
> works fine on QEMU.
>
> Regards,
> Anup

[U-Boot] [PATCH v5 4/4] riscv: Remove redundant a2 store on DRAM base in start.S

[Anup Patel]

On Tue, Nov 27, 2018 at 12:30 PM Rick Chen <rickchen36@gmail.com> wrote:
>
> Anup Patel <anup@brainfault.org> 於 2018年11月27日 週二 下午2:40寫道：
> >
> > On Tue, Nov 27, 2018 at 12:00 PM Rick Chen <rickchen36@gmail.com> wrote:
> > >
> > > Anup Patel <anup@brainfault.org> 於 2018年11月27日 週二 下午2:14寫道：
> > > >
> > > >
> > > >
> > > > On Tue, 27 Nov, 2018, 11:38 AM Rick Chen <rickchen36@gmail.com wrote:
> > > >>
> > > >> Anup Patel <anup@brainfault.org> 於 2018年11月27日 週二 下午1:47寫道：
> > > >> >
> > > >> > On Tue, Nov 27, 2018 at 11:14 AM Anup Patel <anup@brainfault.org> wrote:
> > > >> > >
> > > >> > > On Tue, Nov 27, 2018 at 10:50 AM Rick Chen <rickchen36@gmail.com> wrote:
> > > >> > > >
> > > >> > > > Anup Patel <anup@brainfault.org> 於 2018年11月27日 週二 上午11:28寫道：
> > > >> > > > >
> > > >> > > > > On Tue, Nov 27, 2018 at 8:50 AM Rick Chen <rickchen36@gmail.com> wrote:
> > > >> > > > > >
> > > >> > > > > > > > > > Currently, the RISC-V U-Boot is saving a2 register at
> > > >> > > > > > > > > > CONFIG_SYS_DRAM_BASE in start.S which does not make sense because
> > > >> > > > > > > > > > there is no information passed by previous booting stage in a2
> > > >> > > > > > > > > > register.
> > > >> > > > > > > > > >
> > > >> > > > > > > > > > This patch removes redundant a2 store on DRAM base.
> > > >> > > > > > > > > >
> > > >> > > > > > > > > > Signed-off-by: Anup Patel <anup@brainfault.org>
> > > >> > > > > > > > > > ---
> > > >> > > > > > > > > >  arch/riscv/cpu/start.S | 2 --
> > > >> > > > > > > > > >  1 file changed, 2 deletions(-)
> > > >> > > > > > > > > >
> > > >> > > > > > > > > > diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S index
> > > >> > > > > > > > > > 704190f946..e4276e8e19 100644
> > > >> > > > > > > > > > --- a/arch/riscv/cpu/start.S
> > > >> > > > > > > > > > +++ b/arch/riscv/cpu/start.S
> > > >> > > > > > > > > > @@ -38,8 +38,6 @@ _start:
> > > >> > > > > > > > > >         mv      s0, a0
> > > >> > > > > > > > > >         mv      s1, a1
> > > >> > > > > > > > > >
> > > >> > > > > > > > > > -       li      t0, CONFIG_SYS_SDRAM_BASE
> > > >> > > > > > > > > > -       SREG    a2, 0(t0)
> > > >> > > > > > > > > >         la      t0, trap_entry
> > > >> > > > > > > > > >  #ifdef CONFIG_RISCV_SMODE
> > > >> > > > > > > > > >         csrw    stvec, t0
> > > >> > > > > > > > > > --
> > > >> > > > > > > > >
> > > >> > > > > > > > > This is weird. I remember these two lines were already removed by
> > > >> > > > > > > > > Lukas's patch series before? Did not have time to dig out the history
> > > >> > > > > > > > > though.
> > > >> > > > > > > > >
> > > >> > > > > >
> > > >> > > > > > > > > Regards,
> > > >> > > > > > > > > Bin
> > > >> > > > > > > >
> > > >> > > > > > > > You are correct, however I removed it again, because I did not want to break
> > > >> > > > > > > > Rick's board. He did add a commit to the last pull request that removes these
> > > >> > > > > > > > two lines and adjusts his board accordingly, but it is not in the current one.
> > > >> > > > > > > >
> > > >> > > > > >
> > > >> > > > > > Hi Likas
> > > >> > > > > >
> > > >> > > > > > Thanks for your explanation.
> > > >> > > > > >
> > > >> > > > > > RIck's commit as below
> > > >> > > > > > https://www.mail-archive.com/u-boot at lists.denx.de/msg305880.html
> > > >> > > > >
> > > >> > > > > When we run U-Boot in S-mode the BBL runs from 0x80000000 so this
> > > >> > > > > two lines corrupts BBL instructions.
> > > >> > > > >
> > > >> > > > > If this is important for some board then please have it around #ifdef.
> > > >> > > > >
> > > >> > > >
> > > >> > > > Hi Anup
> > > >> > > >
> > > >> > > > In the discussion as below :
> > > >> > > > https://www.mail-archive.com/u-boot at lists.denx.de/msg305880.html
> > > >> > > >
> > > >> > > > I try to solve this issue with the aptch
> > > >> > > > [PATCH] riscv: ax25-ae350: Pass dtb address to u-boot with a1 register
> > > >> > > > diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S
> > > >> > > > -       li      t0, CONFIG_SYS_SDRAM_BASE
> > > >> > > > -       SREG    a2, 0(t0)
> > > >> > > >
> > > >> > > > diff --git a/board/AndesTech/ax25-ae350/ax25-ae350.c
> > > >> > > > b/board/AndesTech/ax25-ae350/ax25-ae350.c
> > > >> > > >  void *board_fdt_blob_setup(void)
> > > >> > > >  {
> > > >> > > > -       void **ptr = (void *)CONFIG_SYS_SDRAM_BASE;
> > > >> > > > +       void **ptr = (void *)&prior_stage_fdt_address;
> > > >> > > >
> > > >> > > > in the previous pull request.
> > > >> > > >
> > > >> > > > But Bin do not agree with that I use prior_stage_fdt_address in
> > > >> > > > board_fdt_blob_setup( )
> > > >> > > > I try to explain why I use it like that way.
> > > >> > > > Then Bin have not any reply in the following mail.
> > > >> > > > Finally I decide to drop this patch in the next pull request.
> > > >> > > >
> > > >> > > > Hi Bin
> > > >> > > >
> > > >> > > > How do you think about I recovery this patch to fix this issue ?
> > > >> > >
> > > >> > > Actually, previous booting stage can pass location of FDT stored in flash
> > > >> > > to U-Boot. U-Boot requires FDT at a DRAM location which it can modify
> > > >> > > in-place before passing on to Linux kernel so we should relocate the FDT
> > > >> > > passed by previous booting stage to some board specific DRAM location.
> > > >> > >
> > > >> > > My suggestion is as follows:
> > > >> > >
> > > >> > > Instead of SDRAM_BASE, we can have new board specific config
> > > >> > > CONFIG_RISCV_PRIOR_FDT_BASE
> > > >> > >
> > > >> > > If CONFIG_RISCV_PRIOR_FDT_BASE is defined/selected by
> > > >> > > config then in start.S copy-over the FDT from location pointed by
> > > >> > > "a1" register to location pointed by CONFIG_RISCV_PRIOR_FDT_BASE.
> > > >> >
> > > >>
> > > >> Hi Anup
> > > >>
> > > >> It can not achieve dtb delivery at runtime.
> > > >
> > > >
> > > > Can you elaborate why?
> > > >
> > >
> > > CONFIG_RISCV_PRIOR_FDT_BASE is determined at compile time.
> > > I am wondering how it can be modified at run time ?
> >
> > I think you miss-understood my suggestion. I did not meant changing
> > CONFIG_RISCV_PRIOR_FDT_BASE at runtime.
> >
> > >
> > >
> > > > I am sure we can always relocate FDT passed by previous stage to some safer location and use it from there.
> > >
> > > My original patch also can achieve that dtb passed by a1 and relocated and boot.
> >
> > Great !!!
> >
> > Why not update your original patch to relocate FDT and use FDT from
> > safer location?
> >
>
> Good question.
> Above can see the question I ask for Bin :
> How do you think about I recovery this patch to fix this issue ?
>
> Before you talking about CONFIG_RISCV_PRIOR_FDT_BASE !

Can you explain why you need CONFIG_OF_BOARD ?
Why can you not use CONFIG_OF_PRIOR_STAGE ?

Regards,
Anup

[U-Boot] [PATCH v5 4/4] riscv: Remove redundant a2 store on DRAM base in start.S

[Anup Patel]

On Tue, Nov 27, 2018 at 1:26 PM Anup Patel <anup@brainfault.org> wrote:
>
> On Tue, Nov 27, 2018 at 12:30 PM Rick Chen <rickchen36@gmail.com> wrote:
> >
> > Anup Patel <anup@brainfault.org> 於 2018年11月27日 週二 下午2:40寫道：
> > >
> > > On Tue, Nov 27, 2018 at 12:00 PM Rick Chen <rickchen36@gmail.com> wrote:
> > > >
> > > > Anup Patel <anup@brainfault.org> 於 2018年11月27日 週二 下午2:14寫道：
> > > > >
> > > > >
> > > > >
> > > > > On Tue, 27 Nov, 2018, 11:38 AM Rick Chen <rickchen36@gmail.com wrote:
> > > > >>
> > > > >> Anup Patel <anup@brainfault.org> 於 2018年11月27日 週二 下午1:47寫道：
> > > > >> >
> > > > >> > On Tue, Nov 27, 2018 at 11:14 AM Anup Patel <anup@brainfault.org> wrote:
> > > > >> > >
> > > > >> > > On Tue, Nov 27, 2018 at 10:50 AM Rick Chen <rickchen36@gmail.com> wrote:
> > > > >> > > >
> > > > >> > > > Anup Patel <anup@brainfault.org> 於 2018年11月27日 週二 上午11:28寫道：
> > > > >> > > > >
> > > > >> > > > > On Tue, Nov 27, 2018 at 8:50 AM Rick Chen <rickchen36@gmail.com> wrote:
> > > > >> > > > > >
> > > > >> > > > > > > > > > Currently, the RISC-V U-Boot is saving a2 register at
> > > > >> > > > > > > > > > CONFIG_SYS_DRAM_BASE in start.S which does not make sense because
> > > > >> > > > > > > > > > there is no information passed by previous booting stage in a2
> > > > >> > > > > > > > > > register.
> > > > >> > > > > > > > > >
> > > > >> > > > > > > > > > This patch removes redundant a2 store on DRAM base.
> > > > >> > > > > > > > > >
> > > > >> > > > > > > > > > Signed-off-by: Anup Patel <anup@brainfault.org>
> > > > >> > > > > > > > > > ---
> > > > >> > > > > > > > > >  arch/riscv/cpu/start.S | 2 --
> > > > >> > > > > > > > > >  1 file changed, 2 deletions(-)
> > > > >> > > > > > > > > >
> > > > >> > > > > > > > > > diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S index
> > > > >> > > > > > > > > > 704190f946..e4276e8e19 100644
> > > > >> > > > > > > > > > --- a/arch/riscv/cpu/start.S
> > > > >> > > > > > > > > > +++ b/arch/riscv/cpu/start.S
> > > > >> > > > > > > > > > @@ -38,8 +38,6 @@ _start:
> > > > >> > > > > > > > > >         mv      s0, a0
> > > > >> > > > > > > > > >         mv      s1, a1
> > > > >> > > > > > > > > >
> > > > >> > > > > > > > > > -       li      t0, CONFIG_SYS_SDRAM_BASE
> > > > >> > > > > > > > > > -       SREG    a2, 0(t0)
> > > > >> > > > > > > > > >         la      t0, trap_entry
> > > > >> > > > > > > > > >  #ifdef CONFIG_RISCV_SMODE
> > > > >> > > > > > > > > >         csrw    stvec, t0
> > > > >> > > > > > > > > > --
> > > > >> > > > > > > > >
> > > > >> > > > > > > > > This is weird. I remember these two lines were already removed by
> > > > >> > > > > > > > > Lukas's patch series before? Did not have time to dig out the history
> > > > >> > > > > > > > > though.
> > > > >> > > > > > > > >
> > > > >> > > > > >
> > > > >> > > > > > > > > Regards,
> > > > >> > > > > > > > > Bin
> > > > >> > > > > > > >
> > > > >> > > > > > > > You are correct, however I removed it again, because I did not want to break
> > > > >> > > > > > > > Rick's board. He did add a commit to the last pull request that removes these
> > > > >> > > > > > > > two lines and adjusts his board accordingly, but it is not in the current one.
> > > > >> > > > > > > >
> > > > >> > > > > >
> > > > >> > > > > > Hi Likas
> > > > >> > > > > >
> > > > >> > > > > > Thanks for your explanation.
> > > > >> > > > > >
> > > > >> > > > > > RIck's commit as below
> > > > >> > > > > > https://www.mail-archive.com/u-boot at lists.denx.de/msg305880.html
> > > > >> > > > >
> > > > >> > > > > When we run U-Boot in S-mode the BBL runs from 0x80000000 so this
> > > > >> > > > > two lines corrupts BBL instructions.
> > > > >> > > > >
> > > > >> > > > > If this is important for some board then please have it around #ifdef.
> > > > >> > > > >
> > > > >> > > >
> > > > >> > > > Hi Anup
> > > > >> > > >
> > > > >> > > > In the discussion as below :
> > > > >> > > > https://www.mail-archive.com/u-boot at lists.denx.de/msg305880.html
> > > > >> > > >
> > > > >> > > > I try to solve this issue with the aptch
> > > > >> > > > [PATCH] riscv: ax25-ae350: Pass dtb address to u-boot with a1 register
> > > > >> > > > diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S
> > > > >> > > > -       li      t0, CONFIG_SYS_SDRAM_BASE
> > > > >> > > > -       SREG    a2, 0(t0)
> > > > >> > > >
> > > > >> > > > diff --git a/board/AndesTech/ax25-ae350/ax25-ae350.c
> > > > >> > > > b/board/AndesTech/ax25-ae350/ax25-ae350.c
> > > > >> > > >  void *board_fdt_blob_setup(void)
> > > > >> > > >  {
> > > > >> > > > -       void **ptr = (void *)CONFIG_SYS_SDRAM_BASE;
> > > > >> > > > +       void **ptr = (void *)&prior_stage_fdt_address;
> > > > >> > > >
> > > > >> > > > in the previous pull request.
> > > > >> > > >
> > > > >> > > > But Bin do not agree with that I use prior_stage_fdt_address in
> > > > >> > > > board_fdt_blob_setup( )
> > > > >> > > > I try to explain why I use it like that way.
> > > > >> > > > Then Bin have not any reply in the following mail.
> > > > >> > > > Finally I decide to drop this patch in the next pull request.
> > > > >> > > >
> > > > >> > > > Hi Bin
> > > > >> > > >
> > > > >> > > > How do you think about I recovery this patch to fix this issue ?
> > > > >> > >
> > > > >> > > Actually, previous booting stage can pass location of FDT stored in flash
> > > > >> > > to U-Boot. U-Boot requires FDT at a DRAM location which it can modify
> > > > >> > > in-place before passing on to Linux kernel so we should relocate the FDT
> > > > >> > > passed by previous booting stage to some board specific DRAM location.
> > > > >> > >
> > > > >> > > My suggestion is as follows:
> > > > >> > >
> > > > >> > > Instead of SDRAM_BASE, we can have new board specific config
> > > > >> > > CONFIG_RISCV_PRIOR_FDT_BASE
> > > > >> > >
> > > > >> > > If CONFIG_RISCV_PRIOR_FDT_BASE is defined/selected by
> > > > >> > > config then in start.S copy-over the FDT from location pointed by
> > > > >> > > "a1" register to location pointed by CONFIG_RISCV_PRIOR_FDT_BASE.
> > > > >> >
> > > > >>
> > > > >> Hi Anup
> > > > >>
> > > > >> It can not achieve dtb delivery at runtime.
> > > > >
> > > > >
> > > > > Can you elaborate why?
> > > > >
> > > >
> > > > CONFIG_RISCV_PRIOR_FDT_BASE is determined at compile time.
> > > > I am wondering how it can be modified at run time ?
> > >
> > > I think you miss-understood my suggestion. I did not meant changing
> > > CONFIG_RISCV_PRIOR_FDT_BASE at runtime.
> > >
> > > >
> > > >
> > > > > I am sure we can always relocate FDT passed by previous stage to some safer location and use it from there.
> > > >
> > > > My original patch also can achieve that dtb passed by a1 and relocated and boot.
> > >
> > > Great !!!
> > >
> > > Why not update your original patch to relocate FDT and use FDT from
> > > safer location?
> > >
> >
> > Good question.
> > Above can see the question I ask for Bin :
> > How do you think about I recovery this patch to fix this issue ?
> >
> > Before you talking about CONFIG_RISCV_PRIOR_FDT_BASE !
>
> Can you explain why you need CONFIG_OF_BOARD ?
> Why can you not use CONFIG_OF_PRIOR_STAGE ?

I think I got your problem with CONFIG_OF_PRIOR_STAGE. U-Boot cannot
update prior_stage_fdt_address when running from ROM/Flash.

Instead of storing FDT pointer on CONFIG_SYS_SDRAM_BASE, you
can have a board specific location to save FDT pointer when booting from
flash.

Here's a simple reference implementation (untested):

diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 732a357a99..e83b9295d6 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -60,6 +60,19 @@ config RISCV_SMODE
  help
    Enable this option to build U-Boot for RISC-V S-Mode

+config RISCV_FDTPTR_SAVE
+ bool "Save FDT pointer for flash booting"
+ help
+   Enable this option to save FDT pointer passed to U-Boot
+          booting from ROM or Flash.
+
+config RISCV_FDTPTR_SAVE_ADDR
+ hex "Location for saving FDT pointer"
+ depends on RISCV_FDTPTR_SAVE
+ help
+   Set this to provide board specific location for saving
+   FDT pointer.
+
 config 32BIT
  bool

diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S
index e4276e8e19..57c4070e0a 100644
--- a/arch/riscv/cpu/start.S
+++ b/arch/riscv/cpu/start.S
@@ -38,6 +38,11 @@ _start:
  mv s0, a0
  mv s1, a1

+#ifdef CONFIG_RISCV_FDTPTR_SAVE
+ li t0, CONFIG_RISCV_FDTPTR_SAVE_ADDR
+ SREG s1, 0(t0)
+#endif
+
  la t0, trap_entry
 #ifdef CONFIG_RISCV_SMODE
  csrw stvec, t0
diff --git a/board/AndesTech/ax25-ae350/ax25-ae350.c
b/board/AndesTech/ax25-ae350/ax25-ae350.c
index 5f4ca0f5a7..f3535a1d52 100644
--- a/board/AndesTech/ax25-ae350/ax25-ae350.c
+++ b/board/AndesTech/ax25-ae350/ax25-ae350.c
@@ -66,9 +66,9 @@ ulong board_flash_get_legacy(ulong base, int
banknum, flash_info_t *info)

 void *board_fdt_blob_setup(void)
 {
- void **ptr = (void *)CONFIG_SYS_SDRAM_BASE;
+ void **ptr = (void *)CONFIG_RISCV_FDTPTR_SAVE_ADDR;
  if (fdt_magic(*ptr) == FDT_MAGIC)
- return (void *)*ptr;
+ return (void *)*ptr;

  return (void *)CONFIG_SYS_FDT_BASE;
 }
diff --git a/configs/ax25-ae350_64_defconfig b/configs/ax25-ae350_64_defconfig
index b250d3fc7e..b4ba2ed18b 100644
--- a/configs/ax25-ae350_64_defconfig
+++ b/configs/ax25-ae350_64_defconfig
@@ -35,3 +35,5 @@ CONFIG_SYS_NS16550=y
 CONFIG_SPI=y
 CONFIG_ATCSPI200_SPI=y
 CONFIG_ATCPIT100_TIMER=y
+CONFIG_RISCV_FDTPTR_SAVE=y
+CONFIG_RISCV_FDTPTR_SAVE_ADDR=0x80000000

Regards,
Anup

[U-Boot] [PATCH v5 4/4] riscv: Remove redundant a2 store on DRAM base in start.S

[Alexander Graf]

On 27.11.18 09:42, Anup Patel wrote:
> On Tue, Nov 27, 2018 at 1:26 PM Anup Patel <anup@brainfault.org> wrote:
>>
>> On Tue, Nov 27, 2018 at 12:30 PM Rick Chen <rickchen36@gmail.com> wrote:
>>>
>>> Anup Patel <anup@brainfault.org> 於 2018年11月27日 週二 下午2:40寫道：
>>>>
>>>> On Tue, Nov 27, 2018 at 12:00 PM Rick Chen <rickchen36@gmail.com> wrote:
>>>>>
>>>>> Anup Patel <anup@brainfault.org> 於 2018年11月27日 週二 下午2:14寫道：
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Tue, 27 Nov, 2018, 11:38 AM Rick Chen <rickchen36@gmail.com wrote:
>>>>>>>
>>>>>>> Anup Patel <anup@brainfault.org> 於 2018年11月27日 週二 下午1:47寫道：
>>>>>>>>
>>>>>>>> On Tue, Nov 27, 2018 at 11:14 AM Anup Patel <anup@brainfault.org> wrote:
>>>>>>>>>
>>>>>>>>> On Tue, Nov 27, 2018 at 10:50 AM Rick Chen <rickchen36@gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>> Anup Patel <anup@brainfault.org> 於 2018年11月27日 週二 上午11:28寫道：
>>>>>>>>>>>
>>>>>>>>>>> On Tue, Nov 27, 2018 at 8:50 AM Rick Chen <rickchen36@gmail.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Currently, the RISC-V U-Boot is saving a2 register at
>>>>>>>>>>>>>>>> CONFIG_SYS_DRAM_BASE in start.S which does not make sense because
>>>>>>>>>>>>>>>> there is no information passed by previous booting stage in a2
>>>>>>>>>>>>>>>> register.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> This patch removes redundant a2 store on DRAM base.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Signed-off-by: Anup Patel <anup@brainfault.org>
>>>>>>>>>>>>>>>> ---
>>>>>>>>>>>>>>>>  arch/riscv/cpu/start.S | 2 --
>>>>>>>>>>>>>>>>  1 file changed, 2 deletions(-)
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S index
>>>>>>>>>>>>>>>> 704190f946..e4276e8e19 100644
>>>>>>>>>>>>>>>> --- a/arch/riscv/cpu/start.S
>>>>>>>>>>>>>>>> +++ b/arch/riscv/cpu/start.S
>>>>>>>>>>>>>>>> @@ -38,8 +38,6 @@ _start:
>>>>>>>>>>>>>>>>         mv      s0, a0
>>>>>>>>>>>>>>>>         mv      s1, a1
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> -       li      t0, CONFIG_SYS_SDRAM_BASE
>>>>>>>>>>>>>>>> -       SREG    a2, 0(t0)
>>>>>>>>>>>>>>>>         la      t0, trap_entry
>>>>>>>>>>>>>>>>  #ifdef CONFIG_RISCV_SMODE
>>>>>>>>>>>>>>>>         csrw    stvec, t0
>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> This is weird. I remember these two lines were already removed by
>>>>>>>>>>>>>>> Lukas's patch series before? Did not have time to dig out the history
>>>>>>>>>>>>>>> though.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>>> Bin
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> You are correct, however I removed it again, because I did not want to break
>>>>>>>>>>>>>> Rick's board. He did add a commit to the last pull request that removes these
>>>>>>>>>>>>>> two lines and adjusts his board accordingly, but it is not in the current one.
>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Hi Likas
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks for your explanation.
>>>>>>>>>>>>
>>>>>>>>>>>> RIck's commit as below
>>>>>>>>>>>> https://www.mail-archive.com/u-boot at lists.denx.de/msg305880.html
>>>>>>>>>>>
>>>>>>>>>>> When we run U-Boot in S-mode the BBL runs from 0x80000000 so this
>>>>>>>>>>> two lines corrupts BBL instructions.
>>>>>>>>>>>
>>>>>>>>>>> If this is important for some board then please have it around #ifdef.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Hi Anup
>>>>>>>>>>
>>>>>>>>>> In the discussion as below :
>>>>>>>>>> https://www.mail-archive.com/u-boot at lists.denx.de/msg305880.html
>>>>>>>>>>
>>>>>>>>>> I try to solve this issue with the aptch
>>>>>>>>>> [PATCH] riscv: ax25-ae350: Pass dtb address to u-boot with a1 register
>>>>>>>>>> diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S
>>>>>>>>>> -       li      t0, CONFIG_SYS_SDRAM_BASE
>>>>>>>>>> -       SREG    a2, 0(t0)
>>>>>>>>>>
>>>>>>>>>> diff --git a/board/AndesTech/ax25-ae350/ax25-ae350.c
>>>>>>>>>> b/board/AndesTech/ax25-ae350/ax25-ae350.c
>>>>>>>>>>  void *board_fdt_blob_setup(void)
>>>>>>>>>>  {
>>>>>>>>>> -       void **ptr = (void *)CONFIG_SYS_SDRAM_BASE;
>>>>>>>>>> +       void **ptr = (void *)&prior_stage_fdt_address;
>>>>>>>>>>
>>>>>>>>>> in the previous pull request.
>>>>>>>>>>
>>>>>>>>>> But Bin do not agree with that I use prior_stage_fdt_address in
>>>>>>>>>> board_fdt_blob_setup( )
>>>>>>>>>> I try to explain why I use it like that way.
>>>>>>>>>> Then Bin have not any reply in the following mail.
>>>>>>>>>> Finally I decide to drop this patch in the next pull request.
>>>>>>>>>>
>>>>>>>>>> Hi Bin
>>>>>>>>>>
>>>>>>>>>> How do you think about I recovery this patch to fix this issue ?
>>>>>>>>>
>>>>>>>>> Actually, previous booting stage can pass location of FDT stored in flash
>>>>>>>>> to U-Boot. U-Boot requires FDT at a DRAM location which it can modify
>>>>>>>>> in-place before passing on to Linux kernel so we should relocate the FDT
>>>>>>>>> passed by previous booting stage to some board specific DRAM location.
>>>>>>>>>
>>>>>>>>> My suggestion is as follows:
>>>>>>>>>
>>>>>>>>> Instead of SDRAM_BASE, we can have new board specific config
>>>>>>>>> CONFIG_RISCV_PRIOR_FDT_BASE
>>>>>>>>>
>>>>>>>>> If CONFIG_RISCV_PRIOR_FDT_BASE is defined/selected by
>>>>>>>>> config then in start.S copy-over the FDT from location pointed by
>>>>>>>>> "a1" register to location pointed by CONFIG_RISCV_PRIOR_FDT_BASE.
>>>>>>>>
>>>>>>>
>>>>>>> Hi Anup
>>>>>>>
>>>>>>> It can not achieve dtb delivery at runtime.
>>>>>>
>>>>>>
>>>>>> Can you elaborate why?
>>>>>>
>>>>>
>>>>> CONFIG_RISCV_PRIOR_FDT_BASE is determined at compile time.
>>>>> I am wondering how it can be modified at run time ?
>>>>
>>>> I think you miss-understood my suggestion. I did not meant changing
>>>> CONFIG_RISCV_PRIOR_FDT_BASE at runtime.
>>>>
>>>>>
>>>>>
>>>>>> I am sure we can always relocate FDT passed by previous stage to some safer location and use it from there.
>>>>>
>>>>> My original patch also can achieve that dtb passed by a1 and relocated and boot.
>>>>
>>>> Great !!!
>>>>
>>>> Why not update your original patch to relocate FDT and use FDT from
>>>> safer location?
>>>>
>>>
>>> Good question.
>>> Above can see the question I ask for Bin :
>>> How do you think about I recovery this patch to fix this issue ?
>>>
>>> Before you talking about CONFIG_RISCV_PRIOR_FDT_BASE !
>>
>> Can you explain why you need CONFIG_OF_BOARD ?
>> Why can you not use CONFIG_OF_PRIOR_STAGE ?
> 
> I think I got your problem with CONFIG_OF_PRIOR_STAGE. U-Boot cannot
> update prior_stage_fdt_address when running from ROM/Flash.
> 
> Instead of storing FDT pointer on CONFIG_SYS_SDRAM_BASE, you
> can have a board specific location to save FDT pointer when booting from
> flash.

I feel like I'm missing something obvious here. Why can't we just
preserve a2 in a callee saved register and then eventually write it
straight into gd?

For example, how about something like this (untested, probably mangled
by mailer):


diff --git a/arch/riscv/cpu/cpu.c b/arch/riscv/cpu/cpu.c
index ae57fb8313..2281ec0537 100644
--- a/arch/riscv/cpu/cpu.c
+++ b/arch/riscv/cpu/cpu.c
@@ -47,3 +47,8 @@ int print_cpuinfo(void)

 	return 0;
 }
+
+void arch_setup_gd(gd_t *new_gd, ulong arg)
+{
+	new_gd->fdt_blob = (const void *)arg;
+}
diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S
index 7cd7755190..2acbd15f7c 100644
--- a/arch/riscv/cpu/start.S
+++ b/arch/riscv/cpu/start.S
@@ -44,8 +44,7 @@ trap_vector:

 .global trap_entry
 handle_reset:
-	li t0, CONFIG_SYS_SDRAM_BASE
-	SREG a2, 0(t0)
+	mv s0, a2
 	la t0, trap_entry
 	csrw mtvec, t0
 	csrwi mstatus, 0
@@ -75,6 +74,7 @@ call_board_init_f_0:
 	mv	a0, sp
 	jal	board_init_f_alloc_reserve
 	mv	sp, a0
+	mv	a1, s0
 	jal	board_init_f_init_reserve

 	mv  a0, zero	/* a0 <-- boot_flags = 0 */
diff --git a/arch/x86/cpu/i386/cpu.c b/arch/x86/cpu/i386/cpu.c
index 208ef08562..c370ae0808 100644
--- a/arch/x86/cpu/i386/cpu.c
+++ b/arch/x86/cpu/i386/cpu.c
@@ -113,7 +113,7 @@ static void load_gdt(const u64 *boot_gdt, u16
num_entries)
 	asm volatile("lgdtl %0\n" : : "m" (gdt));
 }

-void arch_setup_gd(gd_t *new_gd)
+void arch_setup_gd(gd_t *new_gd, ulong arg)
 {
 	u64 *gdt_addr;

diff --git a/arch/x86/cpu/x86_64/cpu.c b/arch/x86/cpu/x86_64/cpu.c
index 6c063e8200..a17ee5fd78 100644
--- a/arch/x86/cpu/x86_64/cpu.c
+++ b/arch/x86/cpu/x86_64/cpu.c
@@ -16,7 +16,7 @@
  */
 struct global_data *global_data_ptr = (struct global_data *)~0;

-void arch_setup_gd(gd_t *new_gd)
+void arch_setup_gd(gd_t *new_gd, ulong arg)
 {
 	global_data_ptr = new_gd;
 }
diff --git a/arch/x86/lib/spl.c b/arch/x86/lib/spl.c
index 7d290740bf..4313ff1e74 100644
--- a/arch/x86/lib/spl.c
+++ b/arch/x86/lib/spl.c
@@ -72,7 +72,7 @@ static int x86_spl_init(void)
 	 */
 	gd->new_gd = (struct global_data *)ptr;
 	memcpy(gd->new_gd, gd, sizeof(*gd));
-	arch_setup_gd(gd->new_gd);
+	arch_setup_gd(gd->new_gd, 0);
 	gd->start_addr_sp = (ulong)ptr;

 	/* Cache the SPI flash. Otherwise copying the code to RAM takes ages */
diff --git a/board/AndesTech/ax25-ae350/ax25-ae350.c
b/board/AndesTech/ax25-ae350/ax25-ae350.c
index 5f4ca0f5a7..74f2d40ec5 100644
--- a/board/AndesTech/ax25-ae350/ax25-ae350.c
+++ b/board/AndesTech/ax25-ae350/ax25-ae350.c
@@ -66,9 +66,8 @@ ulong board_flash_get_legacy(ulong base, int banknum,
flash_info_t *info)

 void *board_fdt_blob_setup(void)
 {
-	void **ptr = (void *)CONFIG_SYS_SDRAM_BASE;
-	if (fdt_magic(*ptr) == FDT_MAGIC)
-			return (void *)*ptr;
+	if (fdt_magic(gd->fdt_blob) == FDT_MAGIC)
+			return (void *)gd->fdt_blob;

 	return (void *)CONFIG_SYS_FDT_BASE;
 }
diff --git a/common/board_f.c b/common/board_f.c
index f1a1432d86..d853480ae7 100644
--- a/common/board_f.c
+++ b/common/board_f.c
@@ -726,7 +726,7 @@ static int jump_to_copy(void)
 	 * with the stack in SDRAM and Global Data in temporary memory
 	 * (CPU cache)
 	 */
-	arch_setup_gd(gd->new_gd);
+	arch_setup_gd(gd->new_gd, 0);
 	board_init_f_r_trampoline(gd->start_addr_sp);
 #else
 	relocate_code(gd->start_addr_sp, gd->new_gd, gd->relocaddr);
diff --git a/common/board_r.c b/common/board_r.c
index c55e33eec2..39ac04d528 100644
--- a/common/board_r.c
+++ b/common/board_r.c
@@ -856,7 +856,7 @@ void board_init_r(gd_t *new_gd, ulong dest_addr)
 	 * dropping the new_gd parameter.
 	 */
 #if CONFIG_IS_ENABLED(X86_64)
-	arch_setup_gd(new_gd);
+	arch_setup_gd(new_gd, 0);
 #endif

 #ifdef CONFIG_NEEDS_MANUAL_RELOC
diff --git a/common/init/board_init.c b/common/init/board_init.c
index 526fee35ff..be57b422f8 100644
--- a/common/init/board_init.c
+++ b/common/init/board_init.c
@@ -12,7 +12,7 @@ DECLARE_GLOBAL_DATA_PTR;

 /* Unfortunately x86 or ARM can't compile this code as gd cannot be
assigned */
 #if !defined(CONFIG_X86) && !defined(CONFIG_ARM)
-__weak void arch_setup_gd(struct global_data *gd_ptr)
+__weak void arch_setup_gd(struct global_data *gd_ptr, ulong arg)
 {
 	gd = gd_ptr;
 }
@@ -96,7 +96,7 @@ ulong board_init_f_alloc_reserve(ulong top)
  * (seemingly useless) incrementation causes no code increase.
  */

-void board_init_f_init_reserve(ulong base)
+void board_init_f_init_reserve(ulong base, ulong arg)
 {
 	struct global_data *gd_ptr;

@@ -110,7 +110,7 @@ void board_init_f_init_reserve(ulong base)
 	memset(gd_ptr, '\0', sizeof(*gd));
 	/* set GD unless architecture did it already */
 #if !defined(CONFIG_ARM)
-	arch_setup_gd(gd_ptr);
+	arch_setup_gd(gd_ptr, arg);
 #endif
 	/* next alloc will be higher by one GD plus 16-byte alignment */
 	base += roundup(sizeof(struct global_data), 16);
diff --git a/include/init.h b/include/init.h
index afc953d51e..d80fa75ed3 100644
--- a/include/init.h
+++ b/include/init.h
@@ -152,6 +152,7 @@ void board_init_f_init_reserve(ulong base);
 /**
  * arch_setup_gd() - Set up the global_data pointer
  * @gd_ptr: Pointer to global data
+ * @arg: Architecture specific opaque data
  *
  * This pointer is special in some architectures and cannot easily be
assigned
  * to. For example on x86 it is implemented by adding a specific record
to its
@@ -160,7 +161,7 @@ void board_init_f_init_reserve(ulong base);
  *
  *    gd = gd_ptr;
  */
-void arch_setup_gd(gd_t *gd_ptr);
+void arch_setup_gd(gd_t *gd_ptr, ulong arg);

 /* common/board_r.c */
 void board_init_r(gd_t *id, ulong dest_addr) __attribute__ ((noreturn));

[U-Boot] [PATCH v5 4/4] riscv: Remove redundant a2 store on DRAM base in start.S

[Rick Chen]

Alexander Graf <agraf@suse.de> 於 2018年11月27日 週二 下午6:42寫道：
>
>
>
> On 27.11.18 09:42, Anup Patel wrote:
> > On Tue, Nov 27, 2018 at 1:26 PM Anup Patel <anup@brainfault.org> wrote:
> >>
> >> On Tue, Nov 27, 2018 at 12:30 PM Rick Chen <rickchen36@gmail.com> wrote:
> >>>
> >>> Anup Patel <anup@brainfault.org> 於 2018年11月27日 週二 下午2:40寫道：
> >>>>
> >>>> On Tue, Nov 27, 2018 at 12:00 PM Rick Chen <rickchen36@gmail.com> wrote:
> >>>>>
> >>>>> Anup Patel <anup@brainfault.org> 於 2018年11月27日 週二 下午2:14寫道：
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On Tue, 27 Nov, 2018, 11:38 AM Rick Chen <rickchen36@gmail.com wrote:
> >>>>>>>
> >>>>>>> Anup Patel <anup@brainfault.org> 於 2018年11月27日 週二 下午1:47寫道：
> >>>>>>>>
> >>>>>>>> On Tue, Nov 27, 2018 at 11:14 AM Anup Patel <anup@brainfault.org> wrote:
> >>>>>>>>>
> >>>>>>>>> On Tue, Nov 27, 2018 at 10:50 AM Rick Chen <rickchen36@gmail.com> wrote:
> >>>>>>>>>>
> >>>>>>>>>> Anup Patel <anup@brainfault.org> 於 2018年11月27日 週二 上午11:28寫道：
> >>>>>>>>>>>
> >>>>>>>>>>> On Tue, Nov 27, 2018 at 8:50 AM Rick Chen <rickchen36@gmail.com> wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Currently, the RISC-V U-Boot is saving a2 register at
> >>>>>>>>>>>>>>>> CONFIG_SYS_DRAM_BASE in start.S which does not make sense because
> >>>>>>>>>>>>>>>> there is no information passed by previous booting stage in a2
> >>>>>>>>>>>>>>>> register.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> This patch removes redundant a2 store on DRAM base.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Signed-off-by: Anup Patel <anup@brainfault.org>
> >>>>>>>>>>>>>>>> ---
> >>>>>>>>>>>>>>>>  arch/riscv/cpu/start.S | 2 --
> >>>>>>>>>>>>>>>>  1 file changed, 2 deletions(-)
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S index
> >>>>>>>>>>>>>>>> 704190f946..e4276e8e19 100644
> >>>>>>>>>>>>>>>> --- a/arch/riscv/cpu/start.S
> >>>>>>>>>>>>>>>> +++ b/arch/riscv/cpu/start.S
> >>>>>>>>>>>>>>>> @@ -38,8 +38,6 @@ _start:
> >>>>>>>>>>>>>>>>         mv      s0, a0
> >>>>>>>>>>>>>>>>         mv      s1, a1
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> -       li      t0, CONFIG_SYS_SDRAM_BASE
> >>>>>>>>>>>>>>>> -       SREG    a2, 0(t0)
> >>>>>>>>>>>>>>>>         la      t0, trap_entry
> >>>>>>>>>>>>>>>>  #ifdef CONFIG_RISCV_SMODE
> >>>>>>>>>>>>>>>>         csrw    stvec, t0
> >>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> This is weird. I remember these two lines were already removed by
> >>>>>>>>>>>>>>> Lukas's patch series before? Did not have time to dig out the history
> >>>>>>>>>>>>>>> though.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>>>> Regards,
> >>>>>>>>>>>>>>> Bin
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> You are correct, however I removed it again, because I did not want to break
> >>>>>>>>>>>>>> Rick's board. He did add a commit to the last pull request that removes these
> >>>>>>>>>>>>>> two lines and adjusts his board accordingly, but it is not in the current one.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> Hi Likas
> >>>>>>>>>>>>
> >>>>>>>>>>>> Thanks for your explanation.
> >>>>>>>>>>>>
> >>>>>>>>>>>> RIck's commit as below
> >>>>>>>>>>>> https://www.mail-archive.com/u-boot at lists.denx.de/msg305880.html
> >>>>>>>>>>>
> >>>>>>>>>>> When we run U-Boot in S-mode the BBL runs from 0x80000000 so this
> >>>>>>>>>>> two lines corrupts BBL instructions.
> >>>>>>>>>>>
> >>>>>>>>>>> If this is important for some board then please have it around #ifdef.
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Hi Anup
> >>>>>>>>>>
> >>>>>>>>>> In the discussion as below :
> >>>>>>>>>> https://www.mail-archive.com/u-boot at lists.denx.de/msg305880.html
> >>>>>>>>>>
> >>>>>>>>>> I try to solve this issue with the aptch
> >>>>>>>>>> [PATCH] riscv: ax25-ae350: Pass dtb address to u-boot with a1 register
> >>>>>>>>>> diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S
> >>>>>>>>>> -       li      t0, CONFIG_SYS_SDRAM_BASE
> >>>>>>>>>> -       SREG    a2, 0(t0)
> >>>>>>>>>>
> >>>>>>>>>> diff --git a/board/AndesTech/ax25-ae350/ax25-ae350.c
> >>>>>>>>>> b/board/AndesTech/ax25-ae350/ax25-ae350.c
> >>>>>>>>>>  void *board_fdt_blob_setup(void)
> >>>>>>>>>>  {
> >>>>>>>>>> -       void **ptr = (void *)CONFIG_SYS_SDRAM_BASE;
> >>>>>>>>>> +       void **ptr = (void *)&prior_stage_fdt_address;
> >>>>>>>>>>
> >>>>>>>>>> in the previous pull request.
> >>>>>>>>>>
> >>>>>>>>>> But Bin do not agree with that I use prior_stage_fdt_address in
> >>>>>>>>>> board_fdt_blob_setup( )
> >>>>>>>>>> I try to explain why I use it like that way.
> >>>>>>>>>> Then Bin have not any reply in the following mail.
> >>>>>>>>>> Finally I decide to drop this patch in the next pull request.
> >>>>>>>>>>
> >>>>>>>>>> Hi Bin
> >>>>>>>>>>
> >>>>>>>>>> How do you think about I recovery this patch to fix this issue ?
> >>>>>>>>>
> >>>>>>>>> Actually, previous booting stage can pass location of FDT stored in flash
> >>>>>>>>> to U-Boot. U-Boot requires FDT at a DRAM location which it can modify
> >>>>>>>>> in-place before passing on to Linux kernel so we should relocate the FDT
> >>>>>>>>> passed by previous booting stage to some board specific DRAM location.
> >>>>>>>>>
> >>>>>>>>> My suggestion is as follows:
> >>>>>>>>>
> >>>>>>>>> Instead of SDRAM_BASE, we can have new board specific config
> >>>>>>>>> CONFIG_RISCV_PRIOR_FDT_BASE
> >>>>>>>>>
> >>>>>>>>> If CONFIG_RISCV_PRIOR_FDT_BASE is defined/selected by
> >>>>>>>>> config then in start.S copy-over the FDT from location pointed by
> >>>>>>>>> "a1" register to location pointed by CONFIG_RISCV_PRIOR_FDT_BASE.
> >>>>>>>>
> >>>>>>>
> >>>>>>> Hi Anup
> >>>>>>>
> >>>>>>> It can not achieve dtb delivery at runtime.
> >>>>>>
> >>>>>>
> >>>>>> Can you elaborate why?
> >>>>>>
> >>>>>
> >>>>> CONFIG_RISCV_PRIOR_FDT_BASE is determined at compile time.
> >>>>> I am wondering how it can be modified at run time ?
> >>>>
> >>>> I think you miss-understood my suggestion. I did not meant changing
> >>>> CONFIG_RISCV_PRIOR_FDT_BASE at runtime.
> >>>>
> >>>>>
> >>>>>
> >>>>>> I am sure we can always relocate FDT passed by previous stage to some safer location and use it from there.
> >>>>>
> >>>>> My original patch also can achieve that dtb passed by a1 and relocated and boot.
> >>>>
> >>>> Great !!!
> >>>>
> >>>> Why not update your original patch to relocate FDT and use FDT from
> >>>> safer location?
> >>>>
> >>>
> >>> Good question.
> >>> Above can see the question I ask for Bin :
> >>> How do you think about I recovery this patch to fix this issue ?
> >>>
> >>> Before you talking about CONFIG_RISCV_PRIOR_FDT_BASE !
> >>
> >> Can you explain why you need CONFIG_OF_BOARD ?
> >> Why can you not use CONFIG_OF_PRIOR_STAGE ?
> >
> > I think I got your problem with CONFIG_OF_PRIOR_STAGE. U-Boot cannot
> > update prior_stage_fdt_address when running from ROM/Flash.
> >
> > Instead of storing FDT pointer on CONFIG_SYS_SDRAM_BASE, you
> > can have a board specific location to save FDT pointer when booting from
> > flash.
>
> I feel like I'm missing something obvious here. Why can't we just
> preserve a2 in a callee saved register and then eventually write it
> straight into gd?
>
> For example, how about something like this (untested, probably mangled
> by mailer):
>
>
> diff --git a/arch/riscv/cpu/cpu.c b/arch/riscv/cpu/cpu.c
> index ae57fb8313..2281ec0537 100644
> --- a/arch/riscv/cpu/cpu.c
> +++ b/arch/riscv/cpu/cpu.c
> @@ -47,3 +47,8 @@ int print_cpuinfo(void)
>
>         return 0;
>  }
> +
> +void arch_setup_gd(gd_t *new_gd, ulong arg)
> +{
> +       new_gd->fdt_blob = (const void *)arg;
> +}
> diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S
> index 7cd7755190..2acbd15f7c 100644
> --- a/arch/riscv/cpu/start.S
> +++ b/arch/riscv/cpu/start.S
> @@ -44,8 +44,7 @@ trap_vector:
>
>  .global trap_entry
>  handle_reset:
> -       li t0, CONFIG_SYS_SDRAM_BASE
> -       SREG a2, 0(t0)
> +       mv s0, a2
>         la t0, trap_entry
>         csrw mtvec, t0
>         csrwi mstatus, 0
> @@ -75,6 +74,7 @@ call_board_init_f_0:
>         mv      a0, sp
>         jal     board_init_f_alloc_reserve
>         mv      sp, a0
> +       mv      a1, s0
>         jal     board_init_f_init_reserve
>
>         mv  a0, zero    /* a0 <-- boot_flags = 0 */
> diff --git a/arch/x86/cpu/i386/cpu.c b/arch/x86/cpu/i386/cpu.c
> index 208ef08562..c370ae0808 100644
> --- a/arch/x86/cpu/i386/cpu.c
> +++ b/arch/x86/cpu/i386/cpu.c
> @@ -113,7 +113,7 @@ static void load_gdt(const u64 *boot_gdt, u16
> num_entries)
>         asm volatile("lgdtl %0\n" : : "m" (gdt));
>  }
>
> -void arch_setup_gd(gd_t *new_gd)
> +void arch_setup_gd(gd_t *new_gd, ulong arg)
>  {
>         u64 *gdt_addr;
>
> diff --git a/arch/x86/cpu/x86_64/cpu.c b/arch/x86/cpu/x86_64/cpu.c
> index 6c063e8200..a17ee5fd78 100644
> --- a/arch/x86/cpu/x86_64/cpu.c
> +++ b/arch/x86/cpu/x86_64/cpu.c
> @@ -16,7 +16,7 @@
>   */
>  struct global_data *global_data_ptr = (struct global_data *)~0;
>
> -void arch_setup_gd(gd_t *new_gd)
> +void arch_setup_gd(gd_t *new_gd, ulong arg)
>  {
>         global_data_ptr = new_gd;
>  }
> diff --git a/arch/x86/lib/spl.c b/arch/x86/lib/spl.c
> index 7d290740bf..4313ff1e74 100644
> --- a/arch/x86/lib/spl.c
> +++ b/arch/x86/lib/spl.c
> @@ -72,7 +72,7 @@ static int x86_spl_init(void)
>          */
>         gd->new_gd = (struct global_data *)ptr;
>         memcpy(gd->new_gd, gd, sizeof(*gd));
> -       arch_setup_gd(gd->new_gd);
> +       arch_setup_gd(gd->new_gd, 0);
>         gd->start_addr_sp = (ulong)ptr;
>
>         /* Cache the SPI flash. Otherwise copying the code to RAM takes ages */
> diff --git a/board/AndesTech/ax25-ae350/ax25-ae350.c
> b/board/AndesTech/ax25-ae350/ax25-ae350.c
> index 5f4ca0f5a7..74f2d40ec5 100644
> --- a/board/AndesTech/ax25-ae350/ax25-ae350.c
> +++ b/board/AndesTech/ax25-ae350/ax25-ae350.c
> @@ -66,9 +66,8 @@ ulong board_flash_get_legacy(ulong base, int banknum,
> flash_info_t *info)
>
>  void *board_fdt_blob_setup(void)
>  {
> -       void **ptr = (void *)CONFIG_SYS_SDRAM_BASE;
> -       if (fdt_magic(*ptr) == FDT_MAGIC)
> -                       return (void *)*ptr;
> +       if (fdt_magic(gd->fdt_blob) == FDT_MAGIC)
> +                       return (void *)gd->fdt_blob;
>
>         return (void *)CONFIG_SYS_FDT_BASE;
>  }
> diff --git a/common/board_f.c b/common/board_f.c
> index f1a1432d86..d853480ae7 100644
> --- a/common/board_f.c
> +++ b/common/board_f.c
> @@ -726,7 +726,7 @@ static int jump_to_copy(void)
>          * with the stack in SDRAM and Global Data in temporary memory
>          * (CPU cache)
>          */
> -       arch_setup_gd(gd->new_gd);
> +       arch_setup_gd(gd->new_gd, 0);
>         board_init_f_r_trampoline(gd->start_addr_sp);
>  #else
>         relocate_code(gd->start_addr_sp, gd->new_gd, gd->relocaddr);
> diff --git a/common/board_r.c b/common/board_r.c
> index c55e33eec2..39ac04d528 100644
> --- a/common/board_r.c
> +++ b/common/board_r.c
> @@ -856,7 +856,7 @@ void board_init_r(gd_t *new_gd, ulong dest_addr)
>          * dropping the new_gd parameter.
>          */
>  #if CONFIG_IS_ENABLED(X86_64)
> -       arch_setup_gd(new_gd);
> +       arch_setup_gd(new_gd, 0);
>  #endif
>
>  #ifdef CONFIG_NEEDS_MANUAL_RELOC
> diff --git a/common/init/board_init.c b/common/init/board_init.c
> index 526fee35ff..be57b422f8 100644
> --- a/common/init/board_init.c
> +++ b/common/init/board_init.c
> @@ -12,7 +12,7 @@ DECLARE_GLOBAL_DATA_PTR;
>
>  /* Unfortunately x86 or ARM can't compile this code as gd cannot be
> assigned */
>  #if !defined(CONFIG_X86) && !defined(CONFIG_ARM)
> -__weak void arch_setup_gd(struct global_data *gd_ptr)
> +__weak void arch_setup_gd(struct global_data *gd_ptr, ulong arg)
>  {
>         gd = gd_ptr;
>  }
> @@ -96,7 +96,7 @@ ulong board_init_f_alloc_reserve(ulong top)
>   * (seemingly useless) incrementation causes no code increase.
>   */
>
> -void board_init_f_init_reserve(ulong base)
> +void board_init_f_init_reserve(ulong base, ulong arg)
>  {
>         struct global_data *gd_ptr;
>
> @@ -110,7 +110,7 @@ void board_init_f_init_reserve(ulong base)
>         memset(gd_ptr, '\0', sizeof(*gd));
>         /* set GD unless architecture did it already */
>  #if !defined(CONFIG_ARM)
> -       arch_setup_gd(gd_ptr);
> +       arch_setup_gd(gd_ptr, arg);
>  #endif
>         /* next alloc will be higher by one GD plus 16-byte alignment */
>         base += roundup(sizeof(struct global_data), 16);
> diff --git a/include/init.h b/include/init.h
> index afc953d51e..d80fa75ed3 100644
> --- a/include/init.h
> +++ b/include/init.h
> @@ -152,6 +152,7 @@ void board_init_f_init_reserve(ulong base);
>  /**
>   * arch_setup_gd() - Set up the global_data pointer
>   * @gd_ptr: Pointer to global data
> + * @arg: Architecture specific opaque data
>   *
>   * This pointer is special in some architectures and cannot easily be
> assigned
>   * to. For example on x86 it is implemented by adding a specific record
> to its
> @@ -160,7 +161,7 @@ void board_init_f_init_reserve(ulong base);
>   *
>   *    gd = gd_ptr;
>   */
> -void arch_setup_gd(gd_t *gd_ptr);
> +void arch_setup_gd(gd_t *gd_ptr, ulong arg);
>
>  /* common/board_r.c */
>  void board_init_r(gd_t *id, ulong dest_addr) __attribute__ ((noreturn));

Hi Alex

I will try and test it.
Thanks a lot

B.R
Rick

[U-Boot] [PATCH v5 4/4] riscv: Remove redundant a2 store on DRAM base in start.S

[Rick Chen]

Anup Patel <anup@brainfault.org> 於 2018年11月27日 週二 下午3:56寫道：
>
> On Tue, Nov 27, 2018 at 12:30 PM Rick Chen <rickchen36@gmail.com> wrote:
> >
> > Anup Patel <anup@brainfault.org> 於 2018年11月27日 週二 下午2:40寫道：
> > >
> > > On Tue, Nov 27, 2018 at 12:00 PM Rick Chen <rickchen36@gmail.com> wrote:
> > > >
> > > > Anup Patel <anup@brainfault.org> 於 2018年11月27日 週二 下午2:14寫道：
> > > > >
> > > > >
> > > > >
> > > > > On Tue, 27 Nov, 2018, 11:38 AM Rick Chen <rickchen36@gmail.com wrote:
> > > > >>
> > > > >> Anup Patel <anup@brainfault.org> 於 2018年11月27日 週二 下午1:47寫道：
> > > > >> >
> > > > >> > On Tue, Nov 27, 2018 at 11:14 AM Anup Patel <anup@brainfault.org> wrote:
> > > > >> > >
> > > > >> > > On Tue, Nov 27, 2018 at 10:50 AM Rick Chen <rickchen36@gmail.com> wrote:
> > > > >> > > >
> > > > >> > > > Anup Patel <anup@brainfault.org> 於 2018年11月27日 週二 上午11:28寫道：
> > > > >> > > > >
> > > > >> > > > > On Tue, Nov 27, 2018 at 8:50 AM Rick Chen <rickchen36@gmail.com> wrote:
> > > > >> > > > > >
> > > > >> > > > > > > > > > Currently, the RISC-V U-Boot is saving a2 register at
> > > > >> > > > > > > > > > CONFIG_SYS_DRAM_BASE in start.S which does not make sense because
> > > > >> > > > > > > > > > there is no information passed by previous booting stage in a2
> > > > >> > > > > > > > > > register.
> > > > >> > > > > > > > > >
> > > > >> > > > > > > > > > This patch removes redundant a2 store on DRAM base.
> > > > >> > > > > > > > > >
> > > > >> > > > > > > > > > Signed-off-by: Anup Patel <anup@brainfault.org>
> > > > >> > > > > > > > > > ---
> > > > >> > > > > > > > > >  arch/riscv/cpu/start.S | 2 --
> > > > >> > > > > > > > > >  1 file changed, 2 deletions(-)
> > > > >> > > > > > > > > >
> > > > >> > > > > > > > > > diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S index
> > > > >> > > > > > > > > > 704190f946..e4276e8e19 100644
> > > > >> > > > > > > > > > --- a/arch/riscv/cpu/start.S
> > > > >> > > > > > > > > > +++ b/arch/riscv/cpu/start.S
> > > > >> > > > > > > > > > @@ -38,8 +38,6 @@ _start:
> > > > >> > > > > > > > > >         mv      s0, a0
> > > > >> > > > > > > > > >         mv      s1, a1
> > > > >> > > > > > > > > >
> > > > >> > > > > > > > > > -       li      t0, CONFIG_SYS_SDRAM_BASE
> > > > >> > > > > > > > > > -       SREG    a2, 0(t0)
> > > > >> > > > > > > > > >         la      t0, trap_entry
> > > > >> > > > > > > > > >  #ifdef CONFIG_RISCV_SMODE
> > > > >> > > > > > > > > >         csrw    stvec, t0
> > > > >> > > > > > > > > > --
> > > > >> > > > > > > > >
> > > > >> > > > > > > > > This is weird. I remember these two lines were already removed by
> > > > >> > > > > > > > > Lukas's patch series before? Did not have time to dig out the history
> > > > >> > > > > > > > > though.
> > > > >> > > > > > > > >
> > > > >> > > > > >
> > > > >> > > > > > > > > Regards,
> > > > >> > > > > > > > > Bin
> > > > >> > > > > > > >
> > > > >> > > > > > > > You are correct, however I removed it again, because I did not want to break
> > > > >> > > > > > > > Rick's board. He did add a commit to the last pull request that removes these
> > > > >> > > > > > > > two lines and adjusts his board accordingly, but it is not in the current one.
> > > > >> > > > > > > >
> > > > >> > > > > >
> > > > >> > > > > > Hi Likas
> > > > >> > > > > >
> > > > >> > > > > > Thanks for your explanation.
> > > > >> > > > > >
> > > > >> > > > > > RIck's commit as below
> > > > >> > > > > > https://www.mail-archive.com/u-boot at lists.denx.de/msg305880.html
> > > > >> > > > >
> > > > >> > > > > When we run U-Boot in S-mode the BBL runs from 0x80000000 so this
> > > > >> > > > > two lines corrupts BBL instructions.
> > > > >> > > > >
> > > > >> > > > > If this is important for some board then please have it around #ifdef.
> > > > >> > > > >
> > > > >> > > >
> > > > >> > > > Hi Anup
> > > > >> > > >
> > > > >> > > > In the discussion as below :
> > > > >> > > > https://www.mail-archive.com/u-boot at lists.denx.de/msg305880.html
> > > > >> > > >
> > > > >> > > > I try to solve this issue with the aptch
> > > > >> > > > [PATCH] riscv: ax25-ae350: Pass dtb address to u-boot with a1 register
> > > > >> > > > diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S
> > > > >> > > > -       li      t0, CONFIG_SYS_SDRAM_BASE
> > > > >> > > > -       SREG    a2, 0(t0)
> > > > >> > > >
> > > > >> > > > diff --git a/board/AndesTech/ax25-ae350/ax25-ae350.c
> > > > >> > > > b/board/AndesTech/ax25-ae350/ax25-ae350.c
> > > > >> > > >  void *board_fdt_blob_setup(void)
> > > > >> > > >  {
> > > > >> > > > -       void **ptr = (void *)CONFIG_SYS_SDRAM_BASE;
> > > > >> > > > +       void **ptr = (void *)&prior_stage_fdt_address;
> > > > >> > > >
> > > > >> > > > in the previous pull request.
> > > > >> > > >
> > > > >> > > > But Bin do not agree with that I use prior_stage_fdt_address in
> > > > >> > > > board_fdt_blob_setup( )
> > > > >> > > > I try to explain why I use it like that way.
> > > > >> > > > Then Bin have not any reply in the following mail.
> > > > >> > > > Finally I decide to drop this patch in the next pull request.
> > > > >> > > >
> > > > >> > > > Hi Bin
> > > > >> > > >
> > > > >> > > > How do you think about I recovery this patch to fix this issue ?
> > > > >> > >
> > > > >> > > Actually, previous booting stage can pass location of FDT stored in flash
> > > > >> > > to U-Boot. U-Boot requires FDT at a DRAM location which it can modify
> > > > >> > > in-place before passing on to Linux kernel so we should relocate the FDT
> > > > >> > > passed by previous booting stage to some board specific DRAM location.
> > > > >> > >
> > > > >> > > My suggestion is as follows:
> > > > >> > >
> > > > >> > > Instead of SDRAM_BASE, we can have new board specific config
> > > > >> > > CONFIG_RISCV_PRIOR_FDT_BASE
> > > > >> > >
> > > > >> > > If CONFIG_RISCV_PRIOR_FDT_BASE is defined/selected by
> > > > >> > > config then in start.S copy-over the FDT from location pointed by
> > > > >> > > "a1" register to location pointed by CONFIG_RISCV_PRIOR_FDT_BASE.
> > > > >> >
> > > > >>
> > > > >> Hi Anup
> > > > >>
> > > > >> It can not achieve dtb delivery at runtime.
> > > > >
> > > > >
> > > > > Can you elaborate why?
> > > > >
> > > >
> > > > CONFIG_RISCV_PRIOR_FDT_BASE is determined at compile time.
> > > > I am wondering how it can be modified at run time ?
> > >
> > > I think you miss-understood my suggestion. I did not meant changing
> > > CONFIG_RISCV_PRIOR_FDT_BASE at runtime.
> > >
> > > >
> > > >
> > > > > I am sure we can always relocate FDT passed by previous stage to some safer location and use it from there.
> > > >
> > > > My original patch also can achieve that dtb passed by a1 and relocated and boot.
> > >
> > > Great !!!
> > >
> > > Why not update your original patch to relocate FDT and use FDT from
> > > safer location?
> > >
> >
> > Good question.
> > Above can see the question I ask for Bin :
> > How do you think about I recovery this patch to fix this issue ?
> >
> > Before you talking about CONFIG_RISCV_PRIOR_FDT_BASE !
>
> Can you explain why you need CONFIG_OF_BOARD ?
> Why can you not use CONFIG_OF_PRIOR_STAGE ?
>

You can find the discussion as below:
https://patchwork.ozlabs.org/patch/988884/

> Regards,
> Anup

[U-Boot] [PATCH v5 4/4] riscv: Remove redundant a2 store on DRAM base in start.S

[Bin Meng]

Hi Rick,

On Tue, Nov 27, 2018 at 4:43 PM Rick Chen <rickchen36@gmail.com> wrote:
>
> Anup Patel <anup@brainfault.org> 於 2018年11月27日 週二 下午3:56寫道：
> >
> > On Tue, Nov 27, 2018 at 12:30 PM Rick Chen <rickchen36@gmail.com> wrote:
> > >
> > > Anup Patel <anup@brainfault.org> 於 2018年11月27日 週二 下午2:40寫道：
> > > >
> > > > On Tue, Nov 27, 2018 at 12:00 PM Rick Chen <rickchen36@gmail.com> wrote:
> > > > >
> > > > > Anup Patel <anup@brainfault.org> 於 2018年11月27日 週二 下午2:14寫道：
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Tue, 27 Nov, 2018, 11:38 AM Rick Chen <rickchen36@gmail.com wrote:
> > > > > >>
> > > > > >> Anup Patel <anup@brainfault.org> 於 2018年11月27日 週二 下午1:47寫道：
> > > > > >> >
> > > > > >> > On Tue, Nov 27, 2018 at 11:14 AM Anup Patel <anup@brainfault.org> wrote:
> > > > > >> > >
> > > > > >> > > On Tue, Nov 27, 2018 at 10:50 AM Rick Chen <rickchen36@gmail.com> wrote:
> > > > > >> > > >
> > > > > >> > > > Anup Patel <anup@brainfault.org> 於 2018年11月27日 週二 上午11:28寫道：
> > > > > >> > > > >
> > > > > >> > > > > On Tue, Nov 27, 2018 at 8:50 AM Rick Chen <rickchen36@gmail.com> wrote:
> > > > > >> > > > > >
> > > > > >> > > > > > > > > > Currently, the RISC-V U-Boot is saving a2 register at
> > > > > >> > > > > > > > > > CONFIG_SYS_DRAM_BASE in start.S which does not make sense because
> > > > > >> > > > > > > > > > there is no information passed by previous booting stage in a2
> > > > > >> > > > > > > > > > register.
> > > > > >> > > > > > > > > >
> > > > > >> > > > > > > > > > This patch removes redundant a2 store on DRAM base.
> > > > > >> > > > > > > > > >
> > > > > >> > > > > > > > > > Signed-off-by: Anup Patel <anup@brainfault.org>
> > > > > >> > > > > > > > > > ---
> > > > > >> > > > > > > > > >  arch/riscv/cpu/start.S | 2 --
> > > > > >> > > > > > > > > >  1 file changed, 2 deletions(-)
> > > > > >> > > > > > > > > >
> > > > > >> > > > > > > > > > diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S index
> > > > > >> > > > > > > > > > 704190f946..e4276e8e19 100644
> > > > > >> > > > > > > > > > --- a/arch/riscv/cpu/start.S
> > > > > >> > > > > > > > > > +++ b/arch/riscv/cpu/start.S
> > > > > >> > > > > > > > > > @@ -38,8 +38,6 @@ _start:
> > > > > >> > > > > > > > > >         mv      s0, a0
> > > > > >> > > > > > > > > >         mv      s1, a1
> > > > > >> > > > > > > > > >
> > > > > >> > > > > > > > > > -       li      t0, CONFIG_SYS_SDRAM_BASE
> > > > > >> > > > > > > > > > -       SREG    a2, 0(t0)
> > > > > >> > > > > > > > > >         la      t0, trap_entry
> > > > > >> > > > > > > > > >  #ifdef CONFIG_RISCV_SMODE
> > > > > >> > > > > > > > > >         csrw    stvec, t0
> > > > > >> > > > > > > > > > --
> > > > > >> > > > > > > > >
> > > > > >> > > > > > > > > This is weird. I remember these two lines were already removed by
> > > > > >> > > > > > > > > Lukas's patch series before? Did not have time to dig out the history
> > > > > >> > > > > > > > > though.
> > > > > >> > > > > > > > >
> > > > > >> > > > > >
> > > > > >> > > > > > > > > Regards,
> > > > > >> > > > > > > > > Bin
> > > > > >> > > > > > > >
> > > > > >> > > > > > > > You are correct, however I removed it again, because I did not want to break
> > > > > >> > > > > > > > Rick's board. He did add a commit to the last pull request that removes these
> > > > > >> > > > > > > > two lines and adjusts his board accordingly, but it is not in the current one.
> > > > > >> > > > > > > >
> > > > > >> > > > > >
> > > > > >> > > > > > Hi Likas
> > > > > >> > > > > >
> > > > > >> > > > > > Thanks for your explanation.
> > > > > >> > > > > >
> > > > > >> > > > > > RIck's commit as below
> > > > > >> > > > > > https://www.mail-archive.com/u-boot at lists.denx.de/msg305880.html
> > > > > >> > > > >
> > > > > >> > > > > When we run U-Boot in S-mode the BBL runs from 0x80000000 so this
> > > > > >> > > > > two lines corrupts BBL instructions.
> > > > > >> > > > >
> > > > > >> > > > > If this is important for some board then please have it around #ifdef.
> > > > > >> > > > >
> > > > > >> > > >
> > > > > >> > > > Hi Anup
> > > > > >> > > >
> > > > > >> > > > In the discussion as below :
> > > > > >> > > > https://www.mail-archive.com/u-boot at lists.denx.de/msg305880.html
> > > > > >> > > >
> > > > > >> > > > I try to solve this issue with the aptch
> > > > > >> > > > [PATCH] riscv: ax25-ae350: Pass dtb address to u-boot with a1 register
> > > > > >> > > > diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S
> > > > > >> > > > -       li      t0, CONFIG_SYS_SDRAM_BASE
> > > > > >> > > > -       SREG    a2, 0(t0)
> > > > > >> > > >
> > > > > >> > > > diff --git a/board/AndesTech/ax25-ae350/ax25-ae350.c
> > > > > >> > > > b/board/AndesTech/ax25-ae350/ax25-ae350.c
> > > > > >> > > >  void *board_fdt_blob_setup(void)
> > > > > >> > > >  {
> > > > > >> > > > -       void **ptr = (void *)CONFIG_SYS_SDRAM_BASE;
> > > > > >> > > > +       void **ptr = (void *)&prior_stage_fdt_address;
> > > > > >> > > >
> > > > > >> > > > in the previous pull request.
> > > > > >> > > >
> > > > > >> > > > But Bin do not agree with that I use prior_stage_fdt_address in
> > > > > >> > > > board_fdt_blob_setup( )
> > > > > >> > > > I try to explain why I use it like that way.
> > > > > >> > > > Then Bin have not any reply in the following mail.
> > > > > >> > > > Finally I decide to drop this patch in the next pull request.
> > > > > >> > > >
> > > > > >> > > > Hi Bin
> > > > > >> > > >
> > > > > >> > > > How do you think about I recovery this patch to fix this issue ?
> > > > > >> > >
> > > > > >> > > Actually, previous booting stage can pass location of FDT stored in flash
> > > > > >> > > to U-Boot. U-Boot requires FDT at a DRAM location which it can modify
> > > > > >> > > in-place before passing on to Linux kernel so we should relocate the FDT
> > > > > >> > > passed by previous booting stage to some board specific DRAM location.
> > > > > >> > >
> > > > > >> > > My suggestion is as follows:
> > > > > >> > >
> > > > > >> > > Instead of SDRAM_BASE, we can have new board specific config
> > > > > >> > > CONFIG_RISCV_PRIOR_FDT_BASE
> > > > > >> > >
> > > > > >> > > If CONFIG_RISCV_PRIOR_FDT_BASE is defined/selected by
> > > > > >> > > config then in start.S copy-over the FDT from location pointed by
> > > > > >> > > "a1" register to location pointed by CONFIG_RISCV_PRIOR_FDT_BASE.
> > > > > >> >
> > > > > >>
> > > > > >> Hi Anup
> > > > > >>
> > > > > >> It can not achieve dtb delivery at runtime.
> > > > > >
> > > > > >
> > > > > > Can you elaborate why?
> > > > > >
> > > > >
> > > > > CONFIG_RISCV_PRIOR_FDT_BASE is determined at compile time.
> > > > > I am wondering how it can be modified at run time ?
> > > >
> > > > I think you miss-understood my suggestion. I did not meant changing
> > > > CONFIG_RISCV_PRIOR_FDT_BASE at runtime.
> > > >
> > > > >
> > > > >
> > > > > > I am sure we can always relocate FDT passed by previous stage to some safer location and use it from there.
> > > > >
> > > > > My original patch also can achieve that dtb passed by a1 and relocated and boot.
> > > >
> > > > Great !!!
> > > >
> > > > Why not update your original patch to relocate FDT and use FDT from
> > > > safer location?
> > > >
> > >
> > > Good question.
> > > Above can see the question I ask for Bin :
> > > How do you think about I recovery this patch to fix this issue ?
> > >
> > > Before you talking about CONFIG_RISCV_PRIOR_FDT_BASE !
> >
> > Can you explain why you need CONFIG_OF_BOARD ?
> > Why can you not use CONFIG_OF_PRIOR_STAGE ?
> >
>
> You can find the discussion as below:
> https://patchwork.ozlabs.org/patch/988884/
>

If I understand correctly, so far we have two scenarios to support:

1. U-Boot is booting directly from reset vector from ROM. This
canonical way to support DT is via CONFIG_OF_EMBED or
CONFIG_OF_SEPARATE. In such configuration, there is no any previous
bootloader so the concept of CONFIG_OF_PRIOR_STAGE does not apply.

2. U-Boot is booting from previous bootloader, and DT is passed in a1
register. Such configuration we can use CONFIG_OF_PRIOR_STAGE.

Regards,
Bin

[U-Boot] [PATCH v5 4/4] riscv: Remove redundant a2 store on DRAM base in start.S

[Rick Chen]

Bin Meng <bmeng.cn@gmail.com> 於 2018年11月27日 週二 下午6:07寫道：
>
> Hi Rick,
>
> On Tue, Nov 27, 2018 at 4:43 PM Rick Chen <rickchen36@gmail.com> wrote:
> >
> > Anup Patel <anup@brainfault.org> 於 2018年11月27日 週二 下午3:56寫道：
> > >
> > > On Tue, Nov 27, 2018 at 12:30 PM Rick Chen <rickchen36@gmail.com> wrote:
> > > >
> > > > Anup Patel <anup@brainfault.org> 於 2018年11月27日 週二 下午2:40寫道：
> > > > >
> > > > > On Tue, Nov 27, 2018 at 12:00 PM Rick Chen <rickchen36@gmail.com> wrote:
> > > > > >
> > > > > > Anup Patel <anup@brainfault.org> 於 2018年11月27日 週二 下午2:14寫道：
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Tue, 27 Nov, 2018, 11:38 AM Rick Chen <rickchen36@gmail.com wrote:
> > > > > > >>
> > > > > > >> Anup Patel <anup@brainfault.org> 於 2018年11月27日 週二 下午1:47寫道：
> > > > > > >> >
> > > > > > >> > On Tue, Nov 27, 2018 at 11:14 AM Anup Patel <anup@brainfault.org> wrote:
> > > > > > >> > >
> > > > > > >> > > On Tue, Nov 27, 2018 at 10:50 AM Rick Chen <rickchen36@gmail.com> wrote:
> > > > > > >> > > >
> > > > > > >> > > > Anup Patel <anup@brainfault.org> 於 2018年11月27日 週二 上午11:28寫道：
> > > > > > >> > > > >
> > > > > > >> > > > > On Tue, Nov 27, 2018 at 8:50 AM Rick Chen <rickchen36@gmail.com> wrote:
> > > > > > >> > > > > >
> > > > > > >> > > > > > > > > > Currently, the RISC-V U-Boot is saving a2 register at
> > > > > > >> > > > > > > > > > CONFIG_SYS_DRAM_BASE in start.S which does not make sense because
> > > > > > >> > > > > > > > > > there is no information passed by previous booting stage in a2
> > > > > > >> > > > > > > > > > register.
> > > > > > >> > > > > > > > > >
> > > > > > >> > > > > > > > > > This patch removes redundant a2 store on DRAM base.
> > > > > > >> > > > > > > > > >
> > > > > > >> > > > > > > > > > Signed-off-by: Anup Patel <anup@brainfault.org>
> > > > > > >> > > > > > > > > > ---
> > > > > > >> > > > > > > > > >  arch/riscv/cpu/start.S | 2 --
> > > > > > >> > > > > > > > > >  1 file changed, 2 deletions(-)
> > > > > > >> > > > > > > > > >
> > > > > > >> > > > > > > > > > diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S index
> > > > > > >> > > > > > > > > > 704190f946..e4276e8e19 100644
> > > > > > >> > > > > > > > > > --- a/arch/riscv/cpu/start.S
> > > > > > >> > > > > > > > > > +++ b/arch/riscv/cpu/start.S
> > > > > > >> > > > > > > > > > @@ -38,8 +38,6 @@ _start:
> > > > > > >> > > > > > > > > >         mv      s0, a0
> > > > > > >> > > > > > > > > >         mv      s1, a1
> > > > > > >> > > > > > > > > >
> > > > > > >> > > > > > > > > > -       li      t0, CONFIG_SYS_SDRAM_BASE
> > > > > > >> > > > > > > > > > -       SREG    a2, 0(t0)
> > > > > > >> > > > > > > > > >         la      t0, trap_entry
> > > > > > >> > > > > > > > > >  #ifdef CONFIG_RISCV_SMODE
> > > > > > >> > > > > > > > > >         csrw    stvec, t0
> > > > > > >> > > > > > > > > > --
> > > > > > >> > > > > > > > >
> > > > > > >> > > > > > > > > This is weird. I remember these two lines were already removed by
> > > > > > >> > > > > > > > > Lukas's patch series before? Did not have time to dig out the history
> > > > > > >> > > > > > > > > though.
> > > > > > >> > > > > > > > >
> > > > > > >> > > > > >
> > > > > > >> > > > > > > > > Regards,
> > > > > > >> > > > > > > > > Bin
> > > > > > >> > > > > > > >
> > > > > > >> > > > > > > > You are correct, however I removed it again, because I did not want to break
> > > > > > >> > > > > > > > Rick's board. He did add a commit to the last pull request that removes these
> > > > > > >> > > > > > > > two lines and adjusts his board accordingly, but it is not in the current one.
> > > > > > >> > > > > > > >
> > > > > > >> > > > > >
> > > > > > >> > > > > > Hi Likas
> > > > > > >> > > > > >
> > > > > > >> > > > > > Thanks for your explanation.
> > > > > > >> > > > > >
> > > > > > >> > > > > > RIck's commit as below
> > > > > > >> > > > > > https://www.mail-archive.com/u-boot at lists.denx.de/msg305880.html
> > > > > > >> > > > >
> > > > > > >> > > > > When we run U-Boot in S-mode the BBL runs from 0x80000000 so this
> > > > > > >> > > > > two lines corrupts BBL instructions.
> > > > > > >> > > > >
> > > > > > >> > > > > If this is important for some board then please have it around #ifdef.
> > > > > > >> > > > >
> > > > > > >> > > >
> > > > > > >> > > > Hi Anup
> > > > > > >> > > >
> > > > > > >> > > > In the discussion as below :
> > > > > > >> > > > https://www.mail-archive.com/u-boot at lists.denx.de/msg305880.html
> > > > > > >> > > >
> > > > > > >> > > > I try to solve this issue with the aptch
> > > > > > >> > > > [PATCH] riscv: ax25-ae350: Pass dtb address to u-boot with a1 register
> > > > > > >> > > > diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S
> > > > > > >> > > > -       li      t0, CONFIG_SYS_SDRAM_BASE
> > > > > > >> > > > -       SREG    a2, 0(t0)
> > > > > > >> > > >
> > > > > > >> > > > diff --git a/board/AndesTech/ax25-ae350/ax25-ae350.c
> > > > > > >> > > > b/board/AndesTech/ax25-ae350/ax25-ae350.c
> > > > > > >> > > >  void *board_fdt_blob_setup(void)
> > > > > > >> > > >  {
> > > > > > >> > > > -       void **ptr = (void *)CONFIG_SYS_SDRAM_BASE;
> > > > > > >> > > > +       void **ptr = (void *)&prior_stage_fdt_address;
> > > > > > >> > > >
> > > > > > >> > > > in the previous pull request.
> > > > > > >> > > >
> > > > > > >> > > > But Bin do not agree with that I use prior_stage_fdt_address in
> > > > > > >> > > > board_fdt_blob_setup( )
> > > > > > >> > > > I try to explain why I use it like that way.
> > > > > > >> > > > Then Bin have not any reply in the following mail.
> > > > > > >> > > > Finally I decide to drop this patch in the next pull request.
> > > > > > >> > > >
> > > > > > >> > > > Hi Bin
> > > > > > >> > > >
> > > > > > >> > > > How do you think about I recovery this patch to fix this issue ?
> > > > > > >> > >
> > > > > > >> > > Actually, previous booting stage can pass location of FDT stored in flash
> > > > > > >> > > to U-Boot. U-Boot requires FDT at a DRAM location which it can modify
> > > > > > >> > > in-place before passing on to Linux kernel so we should relocate the FDT
> > > > > > >> > > passed by previous booting stage to some board specific DRAM location.
> > > > > > >> > >
> > > > > > >> > > My suggestion is as follows:
> > > > > > >> > >
> > > > > > >> > > Instead of SDRAM_BASE, we can have new board specific config
> > > > > > >> > > CONFIG_RISCV_PRIOR_FDT_BASE
> > > > > > >> > >
> > > > > > >> > > If CONFIG_RISCV_PRIOR_FDT_BASE is defined/selected by
> > > > > > >> > > config then in start.S copy-over the FDT from location pointed by
> > > > > > >> > > "a1" register to location pointed by CONFIG_RISCV_PRIOR_FDT_BASE.
> > > > > > >> >
> > > > > > >>
> > > > > > >> Hi Anup
> > > > > > >>
> > > > > > >> It can not achieve dtb delivery at runtime.
> > > > > > >
> > > > > > >
> > > > > > > Can you elaborate why?
> > > > > > >
> > > > > >
> > > > > > CONFIG_RISCV_PRIOR_FDT_BASE is determined at compile time.
> > > > > > I am wondering how it can be modified at run time ?
> > > > >
> > > > > I think you miss-understood my suggestion. I did not meant changing
> > > > > CONFIG_RISCV_PRIOR_FDT_BASE at runtime.
> > > > >
> > > > > >
> > > > > >
> > > > > > > I am sure we can always relocate FDT passed by previous stage to some safer location and use it from there.
> > > > > >
> > > > > > My original patch also can achieve that dtb passed by a1 and relocated and boot.
> > > > >
> > > > > Great !!!
> > > > >
> > > > > Why not update your original patch to relocate FDT and use FDT from
> > > > > safer location?
> > > > >
> > > >
> > > > Good question.
> > > > Above can see the question I ask for Bin :
> > > > How do you think about I recovery this patch to fix this issue ?
> > > >
> > > > Before you talking about CONFIG_RISCV_PRIOR_FDT_BASE !
> > >
> > > Can you explain why you need CONFIG_OF_BOARD ?
> > > Why can you not use CONFIG_OF_PRIOR_STAGE ?
> > >
> >
> > You can find the discussion as below:
> > https://patchwork.ozlabs.org/patch/988884/
> >
>
> If I understand correctly, so far we have two scenarios to support:
>
> 1. U-Boot is booting directly from reset vector from ROM. This
> canonical way to support DT is via CONFIG_OF_EMBED or
> CONFIG_OF_SEPARATE. In such configuration, there is no any previous
> bootloader so the concept of CONFIG_OF_PRIOR_STAGE does not apply.
>
> 2. U-Boot is booting from previous bootloader, and DT is passed in a1
> register. Such configuration we can use CONFIG_OF_PRIOR_STAGE.
>

I use the 3rd way, CONFIG_OF_BOARD.
It can be found in README.
And can be chosen by make menuconfig

It is the most flexible way that I can implement my own board_fdt_blob_setup( )
which can both support boot from RAM or ROM without any configuration change.
I will indeed use CONFIG_OF_EMBED when u-boot is in debug stage.

prior_stage_fdt_address is just a way that a variable was declared in
data section.
It offer a temp memory to preserve a1 for fdt relocation.
If I rename prior_stage_fdt_address as fdt_preserve_address, then it
will look like not belong to CONFIG_OF_PRIOR_STAGE.
But the code will be somehow duplicate. That is why I recycle it and
try to use prior_stage_fdt_address in board_fdt_blob_setup( )

B.R
Rick

> Regards,
> Bin

[U-Boot] [PATCH v5 4/4] riscv: Remove redundant a2 store on DRAM base in start.S

[Rick Chen]

Rick Chen <rickchen36@gmail.com> 於 2018年11月29日 週四 下午6:42寫道：
>
> Bin Meng <bmeng.cn@gmail.com> 於 2018年11月27日 週二 下午6:07寫道：
> >
> > Hi Rick,
> >
> > On Tue, Nov 27, 2018 at 4:43 PM Rick Chen <rickchen36@gmail.com> wrote:
> > >
> > > Anup Patel <anup@brainfault.org> 於 2018年11月27日 週二 下午3:56寫道：
> > > >
> > > > On Tue, Nov 27, 2018 at 12:30 PM Rick Chen <rickchen36@gmail.com> wrote:
> > > > >
> > > > > Anup Patel <anup@brainfault.org> 於 2018年11月27日 週二 下午2:40寫道：
> > > > > >
> > > > > > On Tue, Nov 27, 2018 at 12:00 PM Rick Chen <rickchen36@gmail.com> wrote:
> > > > > > >
> > > > > > > Anup Patel <anup@brainfault.org> 於 2018年11月27日 週二 下午2:14寫道：
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > On Tue, 27 Nov, 2018, 11:38 AM Rick Chen <rickchen36@gmail.com wrote:
> > > > > > > >>
> > > > > > > >> Anup Patel <anup@brainfault.org> 於 2018年11月27日 週二 下午1:47寫道：
> > > > > > > >> >
> > > > > > > >> > On Tue, Nov 27, 2018 at 11:14 AM Anup Patel <anup@brainfault.org> wrote:
> > > > > > > >> > >
> > > > > > > >> > > On Tue, Nov 27, 2018 at 10:50 AM Rick Chen <rickchen36@gmail.com> wrote:
> > > > > > > >> > > >
> > > > > > > >> > > > Anup Patel <anup@brainfault.org> 於 2018年11月27日 週二 上午11:28寫道：
> > > > > > > >> > > > >
> > > > > > > >> > > > > On Tue, Nov 27, 2018 at 8:50 AM Rick Chen <rickchen36@gmail.com> wrote:
> > > > > > > >> > > > > >
> > > > > > > >> > > > > > > > > > Currently, the RISC-V U-Boot is saving a2 register at
> > > > > > > >> > > > > > > > > > CONFIG_SYS_DRAM_BASE in start.S which does not make sense because
> > > > > > > >> > > > > > > > > > there is no information passed by previous booting stage in a2
> > > > > > > >> > > > > > > > > > register.
> > > > > > > >> > > > > > > > > >
> > > > > > > >> > > > > > > > > > This patch removes redundant a2 store on DRAM base.
> > > > > > > >> > > > > > > > > >
> > > > > > > >> > > > > > > > > > Signed-off-by: Anup Patel <anup@brainfault.org>
> > > > > > > >> > > > > > > > > > ---
> > > > > > > >> > > > > > > > > >  arch/riscv/cpu/start.S | 2 --
> > > > > > > >> > > > > > > > > >  1 file changed, 2 deletions(-)
> > > > > > > >> > > > > > > > > >
> > > > > > > >> > > > > > > > > > diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S index
> > > > > > > >> > > > > > > > > > 704190f946..e4276e8e19 100644
> > > > > > > >> > > > > > > > > > --- a/arch/riscv/cpu/start.S
> > > > > > > >> > > > > > > > > > +++ b/arch/riscv/cpu/start.S
> > > > > > > >> > > > > > > > > > @@ -38,8 +38,6 @@ _start:
> > > > > > > >> > > > > > > > > >         mv      s0, a0
> > > > > > > >> > > > > > > > > >         mv      s1, a1
> > > > > > > >> > > > > > > > > >
> > > > > > > >> > > > > > > > > > -       li      t0, CONFIG_SYS_SDRAM_BASE
> > > > > > > >> > > > > > > > > > -       SREG    a2, 0(t0)
> > > > > > > >> > > > > > > > > >         la      t0, trap_entry
> > > > > > > >> > > > > > > > > >  #ifdef CONFIG_RISCV_SMODE
> > > > > > > >> > > > > > > > > >         csrw    stvec, t0
> > > > > > > >> > > > > > > > > > --
> > > > > > > >> > > > > > > > >
> > > > > > > >> > > > > > > > > This is weird. I remember these two lines were already removed by
> > > > > > > >> > > > > > > > > Lukas's patch series before? Did not have time to dig out the history
> > > > > > > >> > > > > > > > > though.
> > > > > > > >> > > > > > > > >
> > > > > > > >> > > > > >
> > > > > > > >> > > > > > > > > Regards,
> > > > > > > >> > > > > > > > > Bin
> > > > > > > >> > > > > > > >
> > > > > > > >> > > > > > > > You are correct, however I removed it again, because I did not want to break
> > > > > > > >> > > > > > > > Rick's board. He did add a commit to the last pull request that removes these
> > > > > > > >> > > > > > > > two lines and adjusts his board accordingly, but it is not in the current one.
> > > > > > > >> > > > > > > >
> > > > > > > >> > > > > >
> > > > > > > >> > > > > > Hi Likas
> > > > > > > >> > > > > >
> > > > > > > >> > > > > > Thanks for your explanation.
> > > > > > > >> > > > > >
> > > > > > > >> > > > > > RIck's commit as below
> > > > > > > >> > > > > > https://www.mail-archive.com/u-boot at lists.denx.de/msg305880.html
> > > > > > > >> > > > >
> > > > > > > >> > > > > When we run U-Boot in S-mode the BBL runs from 0x80000000 so this
> > > > > > > >> > > > > two lines corrupts BBL instructions.
> > > > > > > >> > > > >
> > > > > > > >> > > > > If this is important for some board then please have it around #ifdef.
> > > > > > > >> > > > >
> > > > > > > >> > > >
> > > > > > > >> > > > Hi Anup
> > > > > > > >> > > >
> > > > > > > >> > > > In the discussion as below :
> > > > > > > >> > > > https://www.mail-archive.com/u-boot at lists.denx.de/msg305880.html
> > > > > > > >> > > >
> > > > > > > >> > > > I try to solve this issue with the aptch
> > > > > > > >> > > > [PATCH] riscv: ax25-ae350: Pass dtb address to u-boot with a1 register
> > > > > > > >> > > > diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S
> > > > > > > >> > > > -       li      t0, CONFIG_SYS_SDRAM_BASE
> > > > > > > >> > > > -       SREG    a2, 0(t0)
> > > > > > > >> > > >
> > > > > > > >> > > > diff --git a/board/AndesTech/ax25-ae350/ax25-ae350.c
> > > > > > > >> > > > b/board/AndesTech/ax25-ae350/ax25-ae350.c
> > > > > > > >> > > >  void *board_fdt_blob_setup(void)
> > > > > > > >> > > >  {
> > > > > > > >> > > > -       void **ptr = (void *)CONFIG_SYS_SDRAM_BASE;
> > > > > > > >> > > > +       void **ptr = (void *)&prior_stage_fdt_address;
> > > > > > > >> > > >
> > > > > > > >> > > > in the previous pull request.
> > > > > > > >> > > >
> > > > > > > >> > > > But Bin do not agree with that I use prior_stage_fdt_address in
> > > > > > > >> > > > board_fdt_blob_setup( )
> > > > > > > >> > > > I try to explain why I use it like that way.
> > > > > > > >> > > > Then Bin have not any reply in the following mail.
> > > > > > > >> > > > Finally I decide to drop this patch in the next pull request.
> > > > > > > >> > > >
> > > > > > > >> > > > Hi Bin
> > > > > > > >> > > >
> > > > > > > >> > > > How do you think about I recovery this patch to fix this issue ?
> > > > > > > >> > >
> > > > > > > >> > > Actually, previous booting stage can pass location of FDT stored in flash
> > > > > > > >> > > to U-Boot. U-Boot requires FDT at a DRAM location which it can modify
> > > > > > > >> > > in-place before passing on to Linux kernel so we should relocate the FDT
> > > > > > > >> > > passed by previous booting stage to some board specific DRAM location.
> > > > > > > >> > >
> > > > > > > >> > > My suggestion is as follows:
> > > > > > > >> > >
> > > > > > > >> > > Instead of SDRAM_BASE, we can have new board specific config
> > > > > > > >> > > CONFIG_RISCV_PRIOR_FDT_BASE
> > > > > > > >> > >
> > > > > > > >> > > If CONFIG_RISCV_PRIOR_FDT_BASE is defined/selected by
> > > > > > > >> > > config then in start.S copy-over the FDT from location pointed by
> > > > > > > >> > > "a1" register to location pointed by CONFIG_RISCV_PRIOR_FDT_BASE.
> > > > > > > >> >
> > > > > > > >>
> > > > > > > >> Hi Anup
> > > > > > > >>
> > > > > > > >> It can not achieve dtb delivery at runtime.
> > > > > > > >
> > > > > > > >
> > > > > > > > Can you elaborate why?
> > > > > > > >
> > > > > > >
> > > > > > > CONFIG_RISCV_PRIOR_FDT_BASE is determined at compile time.
> > > > > > > I am wondering how it can be modified at run time ?
> > > > > >
> > > > > > I think you miss-understood my suggestion. I did not meant changing
> > > > > > CONFIG_RISCV_PRIOR_FDT_BASE at runtime.
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > > > I am sure we can always relocate FDT passed by previous stage to some safer location and use it from there.
> > > > > > >
> > > > > > > My original patch also can achieve that dtb passed by a1 and relocated and boot.
> > > > > >
> > > > > > Great !!!
> > > > > >
> > > > > > Why not update your original patch to relocate FDT and use FDT from
> > > > > > safer location?
> > > > > >
> > > > >
> > > > > Good question.
> > > > > Above can see the question I ask for Bin :
> > > > > How do you think about I recovery this patch to fix this issue ?
> > > > >
> > > > > Before you talking about CONFIG_RISCV_PRIOR_FDT_BASE !
> > > >
> > > > Can you explain why you need CONFIG_OF_BOARD ?
> > > > Why can you not use CONFIG_OF_PRIOR_STAGE ?
> > > >
> > >
> > > You can find the discussion as below:
> > > https://patchwork.ozlabs.org/patch/988884/
> > >
> >
> > If I understand correctly, so far we have two scenarios to support:
> >
> > 1. U-Boot is booting directly from reset vector from ROM. This
> > canonical way to support DT is via CONFIG_OF_EMBED or
> > CONFIG_OF_SEPARATE. In such configuration, there is no any previous
> > bootloader so the concept of CONFIG_OF_PRIOR_STAGE does not apply.
> >
> > 2. U-Boot is booting from previous bootloader, and DT is passed in a1
> > register. Such configuration we can use CONFIG_OF_PRIOR_STAGE.
> >
>
> I use the 3rd way, CONFIG_OF_BOARD.
> It can be found in README.
> And can be chosen by make menuconfig
>
> It is the most flexible way that I can implement my own board_fdt_blob_setup( )
> which can both support boot from RAM or ROM without any configuration change.
> I will indeed use CONFIG_OF_EMBED when u-boot is in debug stage.
>
> prior_stage_fdt_address is just a way that a variable was declared in
> data section.
> It offer a temp memory to preserve a1 for fdt relocation.
> If I rename prior_stage_fdt_address as fdt_preserve_address, then it
> will look like not belong to CONFIG_OF_PRIOR_STAGE.
> But the code will be somehow duplicate. That is why I recycle it and
> try to use prior_stage_fdt_address in board_fdt_blob_setup( )
>

If you still think it is not ok.
I can try another way to overcome it. :)

Maybe I can try Alex's way.

Rick


> B.R
> Rick
>
> > Regards,
> > Bin

[U-Boot] [PATCH v5 4/4] riscv: Remove redundant a2 store on DRAM base in start.S

[Bin Meng]

Hi Rick,

On Thu, Nov 29, 2018 at 6:41 PM Rick Chen <rickchen36@gmail.com> wrote:
>
> Bin Meng <bmeng.cn@gmail.com> 於 2018年11月27日 週二 下午6:07寫道：
> >
> > Hi Rick,
> >
> > On Tue, Nov 27, 2018 at 4:43 PM Rick Chen <rickchen36@gmail.com> wrote:
> > >
> > > Anup Patel <anup@brainfault.org> 於 2018年11月27日 週二 下午3:56寫道：
> > > >
> > > > On Tue, Nov 27, 2018 at 12:30 PM Rick Chen <rickchen36@gmail.com> wrote:
> > > > >
> > > > > Anup Patel <anup@brainfault.org> 於 2018年11月27日 週二 下午2:40寫道：
> > > > > >
> > > > > > On Tue, Nov 27, 2018 at 12:00 PM Rick Chen <rickchen36@gmail.com> wrote:
> > > > > > >
> > > > > > > Anup Patel <anup@brainfault.org> 於 2018年11月27日 週二 下午2:14寫道：
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > On Tue, 27 Nov, 2018, 11:38 AM Rick Chen <rickchen36@gmail.com wrote:
> > > > > > > >>
> > > > > > > >> Anup Patel <anup@brainfault.org> 於 2018年11月27日 週二 下午1:47寫道：
> > > > > > > >> >
> > > > > > > >> > On Tue, Nov 27, 2018 at 11:14 AM Anup Patel <anup@brainfault.org> wrote:
> > > > > > > >> > >
> > > > > > > >> > > On Tue, Nov 27, 2018 at 10:50 AM Rick Chen <rickchen36@gmail.com> wrote:
> > > > > > > >> > > >
> > > > > > > >> > > > Anup Patel <anup@brainfault.org> 於 2018年11月27日 週二 上午11:28寫道：
> > > > > > > >> > > > >
> > > > > > > >> > > > > On Tue, Nov 27, 2018 at 8:50 AM Rick Chen <rickchen36@gmail.com> wrote:
> > > > > > > >> > > > > >
> > > > > > > >> > > > > > > > > > Currently, the RISC-V U-Boot is saving a2 register at
> > > > > > > >> > > > > > > > > > CONFIG_SYS_DRAM_BASE in start.S which does not make sense because
> > > > > > > >> > > > > > > > > > there is no information passed by previous booting stage in a2
> > > > > > > >> > > > > > > > > > register.
> > > > > > > >> > > > > > > > > >
> > > > > > > >> > > > > > > > > > This patch removes redundant a2 store on DRAM base.
> > > > > > > >> > > > > > > > > >
> > > > > > > >> > > > > > > > > > Signed-off-by: Anup Patel <anup@brainfault.org>
> > > > > > > >> > > > > > > > > > ---
> > > > > > > >> > > > > > > > > >  arch/riscv/cpu/start.S | 2 --
> > > > > > > >> > > > > > > > > >  1 file changed, 2 deletions(-)
> > > > > > > >> > > > > > > > > >
> > > > > > > >> > > > > > > > > > diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S index
> > > > > > > >> > > > > > > > > > 704190f946..e4276e8e19 100644
> > > > > > > >> > > > > > > > > > --- a/arch/riscv/cpu/start.S
> > > > > > > >> > > > > > > > > > +++ b/arch/riscv/cpu/start.S
> > > > > > > >> > > > > > > > > > @@ -38,8 +38,6 @@ _start:
> > > > > > > >> > > > > > > > > >         mv      s0, a0
> > > > > > > >> > > > > > > > > >         mv      s1, a1
> > > > > > > >> > > > > > > > > >
> > > > > > > >> > > > > > > > > > -       li      t0, CONFIG_SYS_SDRAM_BASE
> > > > > > > >> > > > > > > > > > -       SREG    a2, 0(t0)
> > > > > > > >> > > > > > > > > >         la      t0, trap_entry
> > > > > > > >> > > > > > > > > >  #ifdef CONFIG_RISCV_SMODE
> > > > > > > >> > > > > > > > > >         csrw    stvec, t0
> > > > > > > >> > > > > > > > > > --
> > > > > > > >> > > > > > > > >
> > > > > > > >> > > > > > > > > This is weird. I remember these two lines were already removed by
> > > > > > > >> > > > > > > > > Lukas's patch series before? Did not have time to dig out the history
> > > > > > > >> > > > > > > > > though.
> > > > > > > >> > > > > > > > >
> > > > > > > >> > > > > >
> > > > > > > >> > > > > > > > > Regards,
> > > > > > > >> > > > > > > > > Bin
> > > > > > > >> > > > > > > >
> > > > > > > >> > > > > > > > You are correct, however I removed it again, because I did not want to break
> > > > > > > >> > > > > > > > Rick's board. He did add a commit to the last pull request that removes these
> > > > > > > >> > > > > > > > two lines and adjusts his board accordingly, but it is not in the current one.
> > > > > > > >> > > > > > > >
> > > > > > > >> > > > > >
> > > > > > > >> > > > > > Hi Likas
> > > > > > > >> > > > > >
> > > > > > > >> > > > > > Thanks for your explanation.
> > > > > > > >> > > > > >
> > > > > > > >> > > > > > RIck's commit as below
> > > > > > > >> > > > > > https://www.mail-archive.com/u-boot at lists.denx.de/msg305880.html
> > > > > > > >> > > > >
> > > > > > > >> > > > > When we run U-Boot in S-mode the BBL runs from 0x80000000 so this
> > > > > > > >> > > > > two lines corrupts BBL instructions.
> > > > > > > >> > > > >
> > > > > > > >> > > > > If this is important for some board then please have it around #ifdef.
> > > > > > > >> > > > >
> > > > > > > >> > > >
> > > > > > > >> > > > Hi Anup
> > > > > > > >> > > >
> > > > > > > >> > > > In the discussion as below :
> > > > > > > >> > > > https://www.mail-archive.com/u-boot at lists.denx.de/msg305880.html
> > > > > > > >> > > >
> > > > > > > >> > > > I try to solve this issue with the aptch
> > > > > > > >> > > > [PATCH] riscv: ax25-ae350: Pass dtb address to u-boot with a1 register
> > > > > > > >> > > > diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S
> > > > > > > >> > > > -       li      t0, CONFIG_SYS_SDRAM_BASE
> > > > > > > >> > > > -       SREG    a2, 0(t0)
> > > > > > > >> > > >
> > > > > > > >> > > > diff --git a/board/AndesTech/ax25-ae350/ax25-ae350.c
> > > > > > > >> > > > b/board/AndesTech/ax25-ae350/ax25-ae350.c
> > > > > > > >> > > >  void *board_fdt_blob_setup(void)
> > > > > > > >> > > >  {
> > > > > > > >> > > > -       void **ptr = (void *)CONFIG_SYS_SDRAM_BASE;
> > > > > > > >> > > > +       void **ptr = (void *)&prior_stage_fdt_address;
> > > > > > > >> > > >
> > > > > > > >> > > > in the previous pull request.
> > > > > > > >> > > >
> > > > > > > >> > > > But Bin do not agree with that I use prior_stage_fdt_address in
> > > > > > > >> > > > board_fdt_blob_setup( )
> > > > > > > >> > > > I try to explain why I use it like that way.
> > > > > > > >> > > > Then Bin have not any reply in the following mail.
> > > > > > > >> > > > Finally I decide to drop this patch in the next pull request.
> > > > > > > >> > > >
> > > > > > > >> > > > Hi Bin
> > > > > > > >> > > >
> > > > > > > >> > > > How do you think about I recovery this patch to fix this issue ?
> > > > > > > >> > >
> > > > > > > >> > > Actually, previous booting stage can pass location of FDT stored in flash
> > > > > > > >> > > to U-Boot. U-Boot requires FDT at a DRAM location which it can modify
> > > > > > > >> > > in-place before passing on to Linux kernel so we should relocate the FDT
> > > > > > > >> > > passed by previous booting stage to some board specific DRAM location.
> > > > > > > >> > >
> > > > > > > >> > > My suggestion is as follows:
> > > > > > > >> > >
> > > > > > > >> > > Instead of SDRAM_BASE, we can have new board specific config
> > > > > > > >> > > CONFIG_RISCV_PRIOR_FDT_BASE
> > > > > > > >> > >
> > > > > > > >> > > If CONFIG_RISCV_PRIOR_FDT_BASE is defined/selected by
> > > > > > > >> > > config then in start.S copy-over the FDT from location pointed by
> > > > > > > >> > > "a1" register to location pointed by CONFIG_RISCV_PRIOR_FDT_BASE.
> > > > > > > >> >
> > > > > > > >>
> > > > > > > >> Hi Anup
> > > > > > > >>
> > > > > > > >> It can not achieve dtb delivery at runtime.
> > > > > > > >
> > > > > > > >
> > > > > > > > Can you elaborate why?
> > > > > > > >
> > > > > > >
> > > > > > > CONFIG_RISCV_PRIOR_FDT_BASE is determined at compile time.
> > > > > > > I am wondering how it can be modified at run time ?
> > > > > >
> > > > > > I think you miss-understood my suggestion. I did not meant changing
> > > > > > CONFIG_RISCV_PRIOR_FDT_BASE at runtime.
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > > > I am sure we can always relocate FDT passed by previous stage to some safer location and use it from there.
> > > > > > >
> > > > > > > My original patch also can achieve that dtb passed by a1 and relocated and boot.
> > > > > >
> > > > > > Great !!!
> > > > > >
> > > > > > Why not update your original patch to relocate FDT and use FDT from
> > > > > > safer location?
> > > > > >
> > > > >
> > > > > Good question.
> > > > > Above can see the question I ask for Bin :
> > > > > How do you think about I recovery this patch to fix this issue ?
> > > > >
> > > > > Before you talking about CONFIG_RISCV_PRIOR_FDT_BASE !
> > > >
> > > > Can you explain why you need CONFIG_OF_BOARD ?
> > > > Why can you not use CONFIG_OF_PRIOR_STAGE ?
> > > >
> > >
> > > You can find the discussion as below:
> > > https://patchwork.ozlabs.org/patch/988884/
> > >
> >
> > If I understand correctly, so far we have two scenarios to support:
> >
> > 1. U-Boot is booting directly from reset vector from ROM. This
> > canonical way to support DT is via CONFIG_OF_EMBED or
> > CONFIG_OF_SEPARATE. In such configuration, there is no any previous
> > bootloader so the concept of CONFIG_OF_PRIOR_STAGE does not apply.
> >
> > 2. U-Boot is booting from previous bootloader, and DT is passed in a1
> > register. Such configuration we can use CONFIG_OF_PRIOR_STAGE.
> >
>
> I use the 3rd way, CONFIG_OF_BOARD.
> It can be found in README.
> And can be chosen by make menuconfig
>
> It is the most flexible way that I can implement my own board_fdt_blob_setup( )
> which can both support boot from RAM or ROM without any configuration change.
> I will indeed use CONFIG_OF_EMBED when u-boot is in debug stage.
>

What I don't understand is that if U-Boot is booting directly from the
reset vector, there is no a1 passed by anyone. U-Boot itself should
figure out a way to determine the DT and that's how CONFIG_OF_EMBED or
CONFIG_OF_SEPARATE is doing. Can you elaborate this configuration?

> prior_stage_fdt_address is just a way that a variable was declared in
> data section.
> It offer a temp memory to preserve a1 for fdt relocation.
> If I rename prior_stage_fdt_address as fdt_preserve_address, then it
> will look like not belong to CONFIG_OF_PRIOR_STAGE.
> But the code will be somehow duplicate. That is why I recycle it and
> try to use prior_stage_fdt_address in board_fdt_blob_setup( )
>

+ Simon's comment to hear his thoughts.

Regards,
Bin

[U-Boot] [PATCH v5 4/4] riscv: Remove redundant a2 store on DRAM base in start.S

[Rick Chen]

Bin Meng <bmeng.cn@gmail.com> 於 2018年11月30日 週五 上午9:48寫道：
>
> Hi Rick,
>
> On Thu, Nov 29, 2018 at 6:41 PM Rick Chen <rickchen36@gmail.com> wrote:
> >
> > Bin Meng <bmeng.cn@gmail.com> 於 2018年11月27日 週二 下午6:07寫道：
> > >
> > > Hi Rick,
> > >
> > > On Tue, Nov 27, 2018 at 4:43 PM Rick Chen <rickchen36@gmail.com> wrote:
> > > >
> > > > Anup Patel <anup@brainfault.org> 於 2018年11月27日 週二 下午3:56寫道：
> > > > >
> > > > > On Tue, Nov 27, 2018 at 12:30 PM Rick Chen <rickchen36@gmail.com> wrote:
> > > > > >
> > > > > > Anup Patel <anup@brainfault.org> 於 2018年11月27日 週二 下午2:40寫道：
> > > > > > >
> > > > > > > On Tue, Nov 27, 2018 at 12:00 PM Rick Chen <rickchen36@gmail.com> wrote:
> > > > > > > >
> > > > > > > > Anup Patel <anup@brainfault.org> 於 2018年11月27日 週二 下午2:14寫道：
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On Tue, 27 Nov, 2018, 11:38 AM Rick Chen <rickchen36@gmail.com wrote:
> > > > > > > > >>
> > > > > > > > >> Anup Patel <anup@brainfault.org> 於 2018年11月27日 週二 下午1:47寫道：
> > > > > > > > >> >
> > > > > > > > >> > On Tue, Nov 27, 2018 at 11:14 AM Anup Patel <anup@brainfault.org> wrote:
> > > > > > > > >> > >
> > > > > > > > >> > > On Tue, Nov 27, 2018 at 10:50 AM Rick Chen <rickchen36@gmail.com> wrote:
> > > > > > > > >> > > >
> > > > > > > > >> > > > Anup Patel <anup@brainfault.org> 於 2018年11月27日 週二 上午11:28寫道：
> > > > > > > > >> > > > >
> > > > > > > > >> > > > > On Tue, Nov 27, 2018 at 8:50 AM Rick Chen <rickchen36@gmail.com> wrote:
> > > > > > > > >> > > > > >
> > > > > > > > >> > > > > > > > > > Currently, the RISC-V U-Boot is saving a2 register at
> > > > > > > > >> > > > > > > > > > CONFIG_SYS_DRAM_BASE in start.S which does not make sense because
> > > > > > > > >> > > > > > > > > > there is no information passed by previous booting stage in a2
> > > > > > > > >> > > > > > > > > > register.
> > > > > > > > >> > > > > > > > > >
> > > > > > > > >> > > > > > > > > > This patch removes redundant a2 store on DRAM base.
> > > > > > > > >> > > > > > > > > >
> > > > > > > > >> > > > > > > > > > Signed-off-by: Anup Patel <anup@brainfault.org>
> > > > > > > > >> > > > > > > > > > ---
> > > > > > > > >> > > > > > > > > >  arch/riscv/cpu/start.S | 2 --
> > > > > > > > >> > > > > > > > > >  1 file changed, 2 deletions(-)
> > > > > > > > >> > > > > > > > > >
> > > > > > > > >> > > > > > > > > > diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S index
> > > > > > > > >> > > > > > > > > > 704190f946..e4276e8e19 100644
> > > > > > > > >> > > > > > > > > > --- a/arch/riscv/cpu/start.S
> > > > > > > > >> > > > > > > > > > +++ b/arch/riscv/cpu/start.S
> > > > > > > > >> > > > > > > > > > @@ -38,8 +38,6 @@ _start:
> > > > > > > > >> > > > > > > > > >         mv      s0, a0
> > > > > > > > >> > > > > > > > > >         mv      s1, a1
> > > > > > > > >> > > > > > > > > >
> > > > > > > > >> > > > > > > > > > -       li      t0, CONFIG_SYS_SDRAM_BASE
> > > > > > > > >> > > > > > > > > > -       SREG    a2, 0(t0)
> > > > > > > > >> > > > > > > > > >         la      t0, trap_entry
> > > > > > > > >> > > > > > > > > >  #ifdef CONFIG_RISCV_SMODE
> > > > > > > > >> > > > > > > > > >         csrw    stvec, t0
> > > > > > > > >> > > > > > > > > > --
> > > > > > > > >> > > > > > > > >
> > > > > > > > >> > > > > > > > > This is weird. I remember these two lines were already removed by
> > > > > > > > >> > > > > > > > > Lukas's patch series before? Did not have time to dig out the history
> > > > > > > > >> > > > > > > > > though.
> > > > > > > > >> > > > > > > > >
> > > > > > > > >> > > > > >
> > > > > > > > >> > > > > > > > > Regards,
> > > > > > > > >> > > > > > > > > Bin
> > > > > > > > >> > > > > > > >
> > > > > > > > >> > > > > > > > You are correct, however I removed it again, because I did not want to break
> > > > > > > > >> > > > > > > > Rick's board. He did add a commit to the last pull request that removes these
> > > > > > > > >> > > > > > > > two lines and adjusts his board accordingly, but it is not in the current one.
> > > > > > > > >> > > > > > > >
> > > > > > > > >> > > > > >
> > > > > > > > >> > > > > > Hi Likas
> > > > > > > > >> > > > > >
> > > > > > > > >> > > > > > Thanks for your explanation.
> > > > > > > > >> > > > > >
> > > > > > > > >> > > > > > RIck's commit as below
> > > > > > > > >> > > > > > https://www.mail-archive.com/u-boot at lists.denx.de/msg305880.html
> > > > > > > > >> > > > >
> > > > > > > > >> > > > > When we run U-Boot in S-mode the BBL runs from 0x80000000 so this
> > > > > > > > >> > > > > two lines corrupts BBL instructions.
> > > > > > > > >> > > > >
> > > > > > > > >> > > > > If this is important for some board then please have it around #ifdef.
> > > > > > > > >> > > > >
> > > > > > > > >> > > >
> > > > > > > > >> > > > Hi Anup
> > > > > > > > >> > > >
> > > > > > > > >> > > > In the discussion as below :
> > > > > > > > >> > > > https://www.mail-archive.com/u-boot at lists.denx.de/msg305880.html
> > > > > > > > >> > > >
> > > > > > > > >> > > > I try to solve this issue with the aptch
> > > > > > > > >> > > > [PATCH] riscv: ax25-ae350: Pass dtb address to u-boot with a1 register
> > > > > > > > >> > > > diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S
> > > > > > > > >> > > > -       li      t0, CONFIG_SYS_SDRAM_BASE
> > > > > > > > >> > > > -       SREG    a2, 0(t0)
> > > > > > > > >> > > >
> > > > > > > > >> > > > diff --git a/board/AndesTech/ax25-ae350/ax25-ae350.c
> > > > > > > > >> > > > b/board/AndesTech/ax25-ae350/ax25-ae350.c
> > > > > > > > >> > > >  void *board_fdt_blob_setup(void)
> > > > > > > > >> > > >  {
> > > > > > > > >> > > > -       void **ptr = (void *)CONFIG_SYS_SDRAM_BASE;
> > > > > > > > >> > > > +       void **ptr = (void *)&prior_stage_fdt_address;
> > > > > > > > >> > > >
> > > > > > > > >> > > > in the previous pull request.
> > > > > > > > >> > > >
> > > > > > > > >> > > > But Bin do not agree with that I use prior_stage_fdt_address in
> > > > > > > > >> > > > board_fdt_blob_setup( )
> > > > > > > > >> > > > I try to explain why I use it like that way.
> > > > > > > > >> > > > Then Bin have not any reply in the following mail.
> > > > > > > > >> > > > Finally I decide to drop this patch in the next pull request.
> > > > > > > > >> > > >
> > > > > > > > >> > > > Hi Bin
> > > > > > > > >> > > >
> > > > > > > > >> > > > How do you think about I recovery this patch to fix this issue ?
> > > > > > > > >> > >
> > > > > > > > >> > > Actually, previous booting stage can pass location of FDT stored in flash
> > > > > > > > >> > > to U-Boot. U-Boot requires FDT at a DRAM location which it can modify
> > > > > > > > >> > > in-place before passing on to Linux kernel so we should relocate the FDT
> > > > > > > > >> > > passed by previous booting stage to some board specific DRAM location.
> > > > > > > > >> > >
> > > > > > > > >> > > My suggestion is as follows:
> > > > > > > > >> > >
> > > > > > > > >> > > Instead of SDRAM_BASE, we can have new board specific config
> > > > > > > > >> > > CONFIG_RISCV_PRIOR_FDT_BASE
> > > > > > > > >> > >
> > > > > > > > >> > > If CONFIG_RISCV_PRIOR_FDT_BASE is defined/selected by
> > > > > > > > >> > > config then in start.S copy-over the FDT from location pointed by
> > > > > > > > >> > > "a1" register to location pointed by CONFIG_RISCV_PRIOR_FDT_BASE.
> > > > > > > > >> >
> > > > > > > > >>
> > > > > > > > >> Hi Anup
> > > > > > > > >>
> > > > > > > > >> It can not achieve dtb delivery at runtime.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Can you elaborate why?
> > > > > > > > >
> > > > > > > >
> > > > > > > > CONFIG_RISCV_PRIOR_FDT_BASE is determined at compile time.
> > > > > > > > I am wondering how it can be modified at run time ?
> > > > > > >
> > > > > > > I think you miss-understood my suggestion. I did not meant changing
> > > > > > > CONFIG_RISCV_PRIOR_FDT_BASE at runtime.
> > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > > I am sure we can always relocate FDT passed by previous stage to some safer location and use it from there.
> > > > > > > >
> > > > > > > > My original patch also can achieve that dtb passed by a1 and relocated and boot.
> > > > > > >
> > > > > > > Great !!!
> > > > > > >
> > > > > > > Why not update your original patch to relocate FDT and use FDT from
> > > > > > > safer location?
> > > > > > >
> > > > > >
> > > > > > Good question.
> > > > > > Above can see the question I ask for Bin :
> > > > > > How do you think about I recovery this patch to fix this issue ?
> > > > > >
> > > > > > Before you talking about CONFIG_RISCV_PRIOR_FDT_BASE !
> > > > >
> > > > > Can you explain why you need CONFIG_OF_BOARD ?
> > > > > Why can you not use CONFIG_OF_PRIOR_STAGE ?
> > > > >
> > > >
> > > > You can find the discussion as below:
> > > > https://patchwork.ozlabs.org/patch/988884/
> > > >
> > >
> > > If I understand correctly, so far we have two scenarios to support:
> > >
> > > 1. U-Boot is booting directly from reset vector from ROM. This
> > > canonical way to support DT is via CONFIG_OF_EMBED or
> > > CONFIG_OF_SEPARATE. In such configuration, there is no any previous
> > > bootloader so the concept of CONFIG_OF_PRIOR_STAGE does not apply.
> > >
> > > 2. U-Boot is booting from previous bootloader, and DT is passed in a1
> > > register. Such configuration we can use CONFIG_OF_PRIOR_STAGE.
> > >
> >
> > I use the 3rd way, CONFIG_OF_BOARD.
> > It can be found in README.
> > And can be chosen by make menuconfig
> >
> > It is the most flexible way that I can implement my own board_fdt_blob_setup( )
> > which can both support boot from RAM or ROM without any configuration change.
> > I will indeed use CONFIG_OF_EMBED when u-boot is in debug stage.
> >
>
> What I don't understand is that if U-Boot is booting directly from the
> reset vector, there is no a1 passed by anyone. U-Boot itself should
> figure out a way to determine the DT and that's how CONFIG_OF_EMBED or
> CONFIG_OF_SEPARATE is doing. Can you elaborate this configuration?
>

I use CONFIG_OF_BOARD and board_fdt_blob_setup as below:

void *board_fdt_blob_setup(void)
{
void **ptr = (void *)CONFIG_SYS_SDRAM_BASE;
if (fdt_magic(*ptr) == FDT_MAGIC)
return (void *)*ptr;

return (void *)CONFIG_SYS_FDT_BASE;
}

1. When booting from RAM
    a1 can be passed by loader and reserved in CONFIG_SYS_SDRAM_BASE
temporarily.

2. When booting from FLASH
    a1 can NOT be passed by loader and reserved in
CONFIG_SYS_SDRAM_BASE temporarily.

    So dtb shall be get from CONFIG_SYS_FDT_BASE (flash base) which
the dtb shall be pre-burned in this flash space..
    Or CONFIG_SYS_FDT_BASE maybe a memory map space (NOT RAM or ROM)
provided by HW.

That is why I mean using CONFIG_OF_BOARD can support both boot from
ram or rom with one configuration.

Regards,
Rick




> > prior_stage_fdt_address is just a way that a variable was declared in
> > data section.
> > It offer a temp memory to preserve a1 for fdt relocation.
> > If I rename prior_stage_fdt_address as fdt_preserve_address, then it
> > will look like not belong to CONFIG_OF_PRIOR_STAGE.
> > But the code will be somehow duplicate. That is why I recycle it and
> > try to use prior_stage_fdt_address in board_fdt_blob_setup( )
> >
>
> + Simon's comment to hear his thoughts.
>
> Regards,
> Bin

[U-Boot] [PATCH v5 4/4] riscv: Remove redundant a2 store on DRAM base in start.S

[Bin Meng]

Hi Rick,

On Fri, Nov 30, 2018 at 2:05 PM Rick Chen <rickchen36@gmail.com> wrote:
>
> Bin Meng <bmeng.cn@gmail.com> 於 2018年11月30日 週五 上午9:48寫道：
> >
> > Hi Rick,
> >
> > On Thu, Nov 29, 2018 at 6:41 PM Rick Chen <rickchen36@gmail.com> wrote:
> > >
> > > Bin Meng <bmeng.cn@gmail.com> 於 2018年11月27日 週二 下午6:07寫道：
> > > >
> > > > Hi Rick,
> > > >
> > > > On Tue, Nov 27, 2018 at 4:43 PM Rick Chen <rickchen36@gmail.com> wrote:
> > > > >
> > > > > Anup Patel <anup@brainfault.org> 於 2018年11月27日 週二 下午3:56寫道：
> > > > > >
> > > > > > On Tue, Nov 27, 2018 at 12:30 PM Rick Chen <rickchen36@gmail.com> wrote:
> > > > > > >
> > > > > > > Anup Patel <anup@brainfault.org> 於 2018年11月27日 週二 下午2:40寫道：
> > > > > > > >
> > > > > > > > On Tue, Nov 27, 2018 at 12:00 PM Rick Chen <rickchen36@gmail.com> wrote:
> > > > > > > > >
> > > > > > > > > Anup Patel <anup@brainfault.org> 於 2018年11月27日 週二 下午2:14寫道：
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > On Tue, 27 Nov, 2018, 11:38 AM Rick Chen <rickchen36@gmail.com wrote:
> > > > > > > > > >>
> > > > > > > > > >> Anup Patel <anup@brainfault.org> 於 2018年11月27日 週二 下午1:47寫道：
> > > > > > > > > >> >
> > > > > > > > > >> > On Tue, Nov 27, 2018 at 11:14 AM Anup Patel <anup@brainfault.org> wrote:
> > > > > > > > > >> > >
> > > > > > > > > >> > > On Tue, Nov 27, 2018 at 10:50 AM Rick Chen <rickchen36@gmail.com> wrote:
> > > > > > > > > >> > > >
> > > > > > > > > >> > > > Anup Patel <anup@brainfault.org> 於 2018年11月27日 週二 上午11:28寫道：
> > > > > > > > > >> > > > >
> > > > > > > > > >> > > > > On Tue, Nov 27, 2018 at 8:50 AM Rick Chen <rickchen36@gmail.com> wrote:
> > > > > > > > > >> > > > > >
> > > > > > > > > >> > > > > > > > > > Currently, the RISC-V U-Boot is saving a2 register at
> > > > > > > > > >> > > > > > > > > > CONFIG_SYS_DRAM_BASE in start.S which does not make sense because
> > > > > > > > > >> > > > > > > > > > there is no information passed by previous booting stage in a2
> > > > > > > > > >> > > > > > > > > > register.
> > > > > > > > > >> > > > > > > > > >
> > > > > > > > > >> > > > > > > > > > This patch removes redundant a2 store on DRAM base.
> > > > > > > > > >> > > > > > > > > >
> > > > > > > > > >> > > > > > > > > > Signed-off-by: Anup Patel <anup@brainfault.org>
> > > > > > > > > >> > > > > > > > > > ---
> > > > > > > > > >> > > > > > > > > >  arch/riscv/cpu/start.S | 2 --
> > > > > > > > > >> > > > > > > > > >  1 file changed, 2 deletions(-)
> > > > > > > > > >> > > > > > > > > >
> > > > > > > > > >> > > > > > > > > > diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S index
> > > > > > > > > >> > > > > > > > > > 704190f946..e4276e8e19 100644
> > > > > > > > > >> > > > > > > > > > --- a/arch/riscv/cpu/start.S
> > > > > > > > > >> > > > > > > > > > +++ b/arch/riscv/cpu/start.S
> > > > > > > > > >> > > > > > > > > > @@ -38,8 +38,6 @@ _start:
> > > > > > > > > >> > > > > > > > > >         mv      s0, a0
> > > > > > > > > >> > > > > > > > > >         mv      s1, a1
> > > > > > > > > >> > > > > > > > > >
> > > > > > > > > >> > > > > > > > > > -       li      t0, CONFIG_SYS_SDRAM_BASE
> > > > > > > > > >> > > > > > > > > > -       SREG    a2, 0(t0)
> > > > > > > > > >> > > > > > > > > >         la      t0, trap_entry
> > > > > > > > > >> > > > > > > > > >  #ifdef CONFIG_RISCV_SMODE
> > > > > > > > > >> > > > > > > > > >         csrw    stvec, t0
> > > > > > > > > >> > > > > > > > > > --
> > > > > > > > > >> > > > > > > > >
> > > > > > > > > >> > > > > > > > > This is weird. I remember these two lines were already removed by
> > > > > > > > > >> > > > > > > > > Lukas's patch series before? Did not have time to dig out the history
> > > > > > > > > >> > > > > > > > > though.
> > > > > > > > > >> > > > > > > > >
> > > > > > > > > >> > > > > >
> > > > > > > > > >> > > > > > > > > Regards,
> > > > > > > > > >> > > > > > > > > Bin
> > > > > > > > > >> > > > > > > >
> > > > > > > > > >> > > > > > > > You are correct, however I removed it again, because I did not want to break
> > > > > > > > > >> > > > > > > > Rick's board. He did add a commit to the last pull request that removes these
> > > > > > > > > >> > > > > > > > two lines and adjusts his board accordingly, but it is not in the current one.
> > > > > > > > > >> > > > > > > >
> > > > > > > > > >> > > > > >
> > > > > > > > > >> > > > > > Hi Likas
> > > > > > > > > >> > > > > >
> > > > > > > > > >> > > > > > Thanks for your explanation.
> > > > > > > > > >> > > > > >
> > > > > > > > > >> > > > > > RIck's commit as below
> > > > > > > > > >> > > > > > https://www.mail-archive.com/u-boot at lists.denx.de/msg305880.html
> > > > > > > > > >> > > > >
> > > > > > > > > >> > > > > When we run U-Boot in S-mode the BBL runs from 0x80000000 so this
> > > > > > > > > >> > > > > two lines corrupts BBL instructions.
> > > > > > > > > >> > > > >
> > > > > > > > > >> > > > > If this is important for some board then please have it around #ifdef.
> > > > > > > > > >> > > > >
> > > > > > > > > >> > > >
> > > > > > > > > >> > > > Hi Anup
> > > > > > > > > >> > > >
> > > > > > > > > >> > > > In the discussion as below :
> > > > > > > > > >> > > > https://www.mail-archive.com/u-boot at lists.denx.de/msg305880.html
> > > > > > > > > >> > > >
> > > > > > > > > >> > > > I try to solve this issue with the aptch
> > > > > > > > > >> > > > [PATCH] riscv: ax25-ae350: Pass dtb address to u-boot with a1 register
> > > > > > > > > >> > > > diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S
> > > > > > > > > >> > > > -       li      t0, CONFIG_SYS_SDRAM_BASE
> > > > > > > > > >> > > > -       SREG    a2, 0(t0)
> > > > > > > > > >> > > >
> > > > > > > > > >> > > > diff --git a/board/AndesTech/ax25-ae350/ax25-ae350.c
> > > > > > > > > >> > > > b/board/AndesTech/ax25-ae350/ax25-ae350.c
> > > > > > > > > >> > > >  void *board_fdt_blob_setup(void)
> > > > > > > > > >> > > >  {
> > > > > > > > > >> > > > -       void **ptr = (void *)CONFIG_SYS_SDRAM_BASE;
> > > > > > > > > >> > > > +       void **ptr = (void *)&prior_stage_fdt_address;
> > > > > > > > > >> > > >
> > > > > > > > > >> > > > in the previous pull request.
> > > > > > > > > >> > > >
> > > > > > > > > >> > > > But Bin do not agree with that I use prior_stage_fdt_address in
> > > > > > > > > >> > > > board_fdt_blob_setup( )
> > > > > > > > > >> > > > I try to explain why I use it like that way.
> > > > > > > > > >> > > > Then Bin have not any reply in the following mail.
> > > > > > > > > >> > > > Finally I decide to drop this patch in the next pull request.
> > > > > > > > > >> > > >
> > > > > > > > > >> > > > Hi Bin
> > > > > > > > > >> > > >
> > > > > > > > > >> > > > How do you think about I recovery this patch to fix this issue ?
> > > > > > > > > >> > >
> > > > > > > > > >> > > Actually, previous booting stage can pass location of FDT stored in flash
> > > > > > > > > >> > > to U-Boot. U-Boot requires FDT at a DRAM location which it can modify
> > > > > > > > > >> > > in-place before passing on to Linux kernel so we should relocate the FDT
> > > > > > > > > >> > > passed by previous booting stage to some board specific DRAM location.
> > > > > > > > > >> > >
> > > > > > > > > >> > > My suggestion is as follows:
> > > > > > > > > >> > >
> > > > > > > > > >> > > Instead of SDRAM_BASE, we can have new board specific config
> > > > > > > > > >> > > CONFIG_RISCV_PRIOR_FDT_BASE
> > > > > > > > > >> > >
> > > > > > > > > >> > > If CONFIG_RISCV_PRIOR_FDT_BASE is defined/selected by
> > > > > > > > > >> > > config then in start.S copy-over the FDT from location pointed by
> > > > > > > > > >> > > "a1" register to location pointed by CONFIG_RISCV_PRIOR_FDT_BASE.
> > > > > > > > > >> >
> > > > > > > > > >>
> > > > > > > > > >> Hi Anup
> > > > > > > > > >>
> > > > > > > > > >> It can not achieve dtb delivery at runtime.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Can you elaborate why?
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > CONFIG_RISCV_PRIOR_FDT_BASE is determined at compile time.
> > > > > > > > > I am wondering how it can be modified at run time ?
> > > > > > > >
> > > > > > > > I think you miss-understood my suggestion. I did not meant changing
> > > > > > > > CONFIG_RISCV_PRIOR_FDT_BASE at runtime.
> > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > > I am sure we can always relocate FDT passed by previous stage to some safer location and use it from there.
> > > > > > > > >
> > > > > > > > > My original patch also can achieve that dtb passed by a1 and relocated and boot.
> > > > > > > >
> > > > > > > > Great !!!
> > > > > > > >
> > > > > > > > Why not update your original patch to relocate FDT and use FDT from
> > > > > > > > safer location?
> > > > > > > >
> > > > > > >
> > > > > > > Good question.
> > > > > > > Above can see the question I ask for Bin :
> > > > > > > How do you think about I recovery this patch to fix this issue ?
> > > > > > >
> > > > > > > Before you talking about CONFIG_RISCV_PRIOR_FDT_BASE !
> > > > > >
> > > > > > Can you explain why you need CONFIG_OF_BOARD ?
> > > > > > Why can you not use CONFIG_OF_PRIOR_STAGE ?
> > > > > >
> > > > >
> > > > > You can find the discussion as below:
> > > > > https://patchwork.ozlabs.org/patch/988884/
> > > > >
> > > >
> > > > If I understand correctly, so far we have two scenarios to support:
> > > >
> > > > 1. U-Boot is booting directly from reset vector from ROM. This
> > > > canonical way to support DT is via CONFIG_OF_EMBED or
> > > > CONFIG_OF_SEPARATE. In such configuration, there is no any previous
> > > > bootloader so the concept of CONFIG_OF_PRIOR_STAGE does not apply.
> > > >
> > > > 2. U-Boot is booting from previous bootloader, and DT is passed in a1
> > > > register. Such configuration we can use CONFIG_OF_PRIOR_STAGE.
> > > >
> > >
> > > I use the 3rd way, CONFIG_OF_BOARD.
> > > It can be found in README.
> > > And can be chosen by make menuconfig
> > >
> > > It is the most flexible way that I can implement my own board_fdt_blob_setup( )
> > > which can both support boot from RAM or ROM without any configuration change.
> > > I will indeed use CONFIG_OF_EMBED when u-boot is in debug stage.
> > >
> >
> > What I don't understand is that if U-Boot is booting directly from the
> > reset vector, there is no a1 passed by anyone. U-Boot itself should
> > figure out a way to determine the DT and that's how CONFIG_OF_EMBED or
> > CONFIG_OF_SEPARATE is doing. Can you elaborate this configuration?
> >
>
> I use CONFIG_OF_BOARD and board_fdt_blob_setup as below:
>
> void *board_fdt_blob_setup(void)
> {
> void **ptr = (void *)CONFIG_SYS_SDRAM_BASE;
> if (fdt_magic(*ptr) == FDT_MAGIC)
> return (void *)*ptr;
>
> return (void *)CONFIG_SYS_FDT_BASE;
> }
>
> 1. When booting from RAM
>     a1 can be passed by loader and reserved in CONFIG_SYS_SDRAM_BASE
> temporarily.
>
> 2. When booting from FLASH
>     a1 can NOT be passed by loader and reserved in
> CONFIG_SYS_SDRAM_BASE temporarily.
>
>     So dtb shall be get from CONFIG_SYS_FDT_BASE (flash base) which
> the dtb shall be pre-burned in this flash space..
>     Or CONFIG_SYS_FDT_BASE maybe a memory map space (NOT RAM or ROM)
> provided by HW.
>
> That is why I mean using CONFIG_OF_BOARD can support both boot from
> ram or rom with one configuration.
>

Thanks for the info. So with the latest info, I now understand you
wanted to use CONFIG_OF_BOARD to support both configurations. That
makes sense to me, however I still wanted to point out the canonical
way to support booting from ROM is via CONFIG_OF_SEPARATE or
CONFIG_OF_EMBED. Since your board can support booting from reset
vector directly, what's the need to support the booting from RAM
configuration? In that configuration, what is the first stage
bootloader?

Regards,
Bin

[U-Boot] [PATCH v5 4/4] riscv: Remove redundant a2 store on DRAM base in start.S

[Rick Chen]

Bin Meng <bmeng.cn@gmail.com> 於 2018年11月30日 週五 下午2:21寫道：
>
> Hi Rick,
>
> On Fri, Nov 30, 2018 at 2:05 PM Rick Chen <rickchen36@gmail.com> wrote:
> >
> > Bin Meng <bmeng.cn@gmail.com> 於 2018年11月30日 週五 上午9:48寫道：
> > >
> > > Hi Rick,
> > >
> > > On Thu, Nov 29, 2018 at 6:41 PM Rick Chen <rickchen36@gmail.com> wrote:
> > > >
> > > > Bin Meng <bmeng.cn@gmail.com> 於 2018年11月27日 週二 下午6:07寫道：
> > > > >
> > > > > Hi Rick,
> > > > >
> > > > > On Tue, Nov 27, 2018 at 4:43 PM Rick Chen <rickchen36@gmail.com> wrote:
> > > > > >
> > > > > > Anup Patel <anup@brainfault.org> 於 2018年11月27日 週二 下午3:56寫道：
> > > > > > >
> > > > > > > On Tue, Nov 27, 2018 at 12:30 PM Rick Chen <rickchen36@gmail.com> wrote:
> > > > > > > >
> > > > > > > > Anup Patel <anup@brainfault.org> 於 2018年11月27日 週二 下午2:40寫道：
> > > > > > > > >
> > > > > > > > > On Tue, Nov 27, 2018 at 12:00 PM Rick Chen <rickchen36@gmail.com> wrote:
> > > > > > > > > >
> > > > > > > > > > Anup Patel <anup@brainfault.org> 於 2018年11月27日 週二 下午2:14寫道：
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > On Tue, 27 Nov, 2018, 11:38 AM Rick Chen <rickchen36@gmail.com wrote:
> > > > > > > > > > >>
> > > > > > > > > > >> Anup Patel <anup@brainfault.org> 於 2018年11月27日 週二 下午1:47寫道：
> > > > > > > > > > >> >
> > > > > > > > > > >> > On Tue, Nov 27, 2018 at 11:14 AM Anup Patel <anup@brainfault.org> wrote:
> > > > > > > > > > >> > >
> > > > > > > > > > >> > > On Tue, Nov 27, 2018 at 10:50 AM Rick Chen <rickchen36@gmail.com> wrote:
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > Anup Patel <anup@brainfault.org> 於 2018年11月27日 週二 上午11:28寫道：
> > > > > > > > > > >> > > > >
> > > > > > > > > > >> > > > > On Tue, Nov 27, 2018 at 8:50 AM Rick Chen <rickchen36@gmail.com> wrote:
> > > > > > > > > > >> > > > > >
> > > > > > > > > > >> > > > > > > > > > Currently, the RISC-V U-Boot is saving a2 register at
> > > > > > > > > > >> > > > > > > > > > CONFIG_SYS_DRAM_BASE in start.S which does not make sense because
> > > > > > > > > > >> > > > > > > > > > there is no information passed by previous booting stage in a2
> > > > > > > > > > >> > > > > > > > > > register.
> > > > > > > > > > >> > > > > > > > > >
> > > > > > > > > > >> > > > > > > > > > This patch removes redundant a2 store on DRAM base.
> > > > > > > > > > >> > > > > > > > > >
> > > > > > > > > > >> > > > > > > > > > Signed-off-by: Anup Patel <anup@brainfault.org>
> > > > > > > > > > >> > > > > > > > > > ---
> > > > > > > > > > >> > > > > > > > > >  arch/riscv/cpu/start.S | 2 --
> > > > > > > > > > >> > > > > > > > > >  1 file changed, 2 deletions(-)
> > > > > > > > > > >> > > > > > > > > >
> > > > > > > > > > >> > > > > > > > > > diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S index
> > > > > > > > > > >> > > > > > > > > > 704190f946..e4276e8e19 100644
> > > > > > > > > > >> > > > > > > > > > --- a/arch/riscv/cpu/start.S
> > > > > > > > > > >> > > > > > > > > > +++ b/arch/riscv/cpu/start.S
> > > > > > > > > > >> > > > > > > > > > @@ -38,8 +38,6 @@ _start:
> > > > > > > > > > >> > > > > > > > > >         mv      s0, a0
> > > > > > > > > > >> > > > > > > > > >         mv      s1, a1
> > > > > > > > > > >> > > > > > > > > >
> > > > > > > > > > >> > > > > > > > > > -       li      t0, CONFIG_SYS_SDRAM_BASE
> > > > > > > > > > >> > > > > > > > > > -       SREG    a2, 0(t0)
> > > > > > > > > > >> > > > > > > > > >         la      t0, trap_entry
> > > > > > > > > > >> > > > > > > > > >  #ifdef CONFIG_RISCV_SMODE
> > > > > > > > > > >> > > > > > > > > >         csrw    stvec, t0
> > > > > > > > > > >> > > > > > > > > > --
> > > > > > > > > > >> > > > > > > > >
> > > > > > > > > > >> > > > > > > > > This is weird. I remember these two lines were already removed by
> > > > > > > > > > >> > > > > > > > > Lukas's patch series before? Did not have time to dig out the history
> > > > > > > > > > >> > > > > > > > > though.
> > > > > > > > > > >> > > > > > > > >
> > > > > > > > > > >> > > > > >
> > > > > > > > > > >> > > > > > > > > Regards,
> > > > > > > > > > >> > > > > > > > > Bin
> > > > > > > > > > >> > > > > > > >
> > > > > > > > > > >> > > > > > > > You are correct, however I removed it again, because I did not want to break
> > > > > > > > > > >> > > > > > > > Rick's board. He did add a commit to the last pull request that removes these
> > > > > > > > > > >> > > > > > > > two lines and adjusts his board accordingly, but it is not in the current one.
> > > > > > > > > > >> > > > > > > >
> > > > > > > > > > >> > > > > >
> > > > > > > > > > >> > > > > > Hi Likas
> > > > > > > > > > >> > > > > >
> > > > > > > > > > >> > > > > > Thanks for your explanation.
> > > > > > > > > > >> > > > > >
> > > > > > > > > > >> > > > > > RIck's commit as below
> > > > > > > > > > >> > > > > > https://www.mail-archive.com/u-boot at lists.denx.de/msg305880.html
> > > > > > > > > > >> > > > >
> > > > > > > > > > >> > > > > When we run U-Boot in S-mode the BBL runs from 0x80000000 so this
> > > > > > > > > > >> > > > > two lines corrupts BBL instructions.
> > > > > > > > > > >> > > > >
> > > > > > > > > > >> > > > > If this is important for some board then please have it around #ifdef.
> > > > > > > > > > >> > > > >
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > Hi Anup
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > In the discussion as below :
> > > > > > > > > > >> > > > https://www.mail-archive.com/u-boot at lists.denx.de/msg305880.html
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > I try to solve this issue with the aptch
> > > > > > > > > > >> > > > [PATCH] riscv: ax25-ae350: Pass dtb address to u-boot with a1 register
> > > > > > > > > > >> > > > diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S
> > > > > > > > > > >> > > > -       li      t0, CONFIG_SYS_SDRAM_BASE
> > > > > > > > > > >> > > > -       SREG    a2, 0(t0)
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > diff --git a/board/AndesTech/ax25-ae350/ax25-ae350.c
> > > > > > > > > > >> > > > b/board/AndesTech/ax25-ae350/ax25-ae350.c
> > > > > > > > > > >> > > >  void *board_fdt_blob_setup(void)
> > > > > > > > > > >> > > >  {
> > > > > > > > > > >> > > > -       void **ptr = (void *)CONFIG_SYS_SDRAM_BASE;
> > > > > > > > > > >> > > > +       void **ptr = (void *)&prior_stage_fdt_address;
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > in the previous pull request.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > But Bin do not agree with that I use prior_stage_fdt_address in
> > > > > > > > > > >> > > > board_fdt_blob_setup( )
> > > > > > > > > > >> > > > I try to explain why I use it like that way.
> > > > > > > > > > >> > > > Then Bin have not any reply in the following mail.
> > > > > > > > > > >> > > > Finally I decide to drop this patch in the next pull request.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > Hi Bin
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > How do you think about I recovery this patch to fix this issue ?
> > > > > > > > > > >> > >
> > > > > > > > > > >> > > Actually, previous booting stage can pass location of FDT stored in flash
> > > > > > > > > > >> > > to U-Boot. U-Boot requires FDT at a DRAM location which it can modify
> > > > > > > > > > >> > > in-place before passing on to Linux kernel so we should relocate the FDT
> > > > > > > > > > >> > > passed by previous booting stage to some board specific DRAM location.
> > > > > > > > > > >> > >
> > > > > > > > > > >> > > My suggestion is as follows:
> > > > > > > > > > >> > >
> > > > > > > > > > >> > > Instead of SDRAM_BASE, we can have new board specific config
> > > > > > > > > > >> > > CONFIG_RISCV_PRIOR_FDT_BASE
> > > > > > > > > > >> > >
> > > > > > > > > > >> > > If CONFIG_RISCV_PRIOR_FDT_BASE is defined/selected by
> > > > > > > > > > >> > > config then in start.S copy-over the FDT from location pointed by
> > > > > > > > > > >> > > "a1" register to location pointed by CONFIG_RISCV_PRIOR_FDT_BASE.
> > > > > > > > > > >> >
> > > > > > > > > > >>
> > > > > > > > > > >> Hi Anup
> > > > > > > > > > >>
> > > > > > > > > > >> It can not achieve dtb delivery at runtime.
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > Can you elaborate why?
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > CONFIG_RISCV_PRIOR_FDT_BASE is determined at compile time.
> > > > > > > > > > I am wondering how it can be modified at run time ?
> > > > > > > > >
> > > > > > > > > I think you miss-understood my suggestion. I did not meant changing
> > > > > > > > > CONFIG_RISCV_PRIOR_FDT_BASE at runtime.
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > > I am sure we can always relocate FDT passed by previous stage to some safer location and use it from there.
> > > > > > > > > >
> > > > > > > > > > My original patch also can achieve that dtb passed by a1 and relocated and boot.
> > > > > > > > >
> > > > > > > > > Great !!!
> > > > > > > > >
> > > > > > > > > Why not update your original patch to relocate FDT and use FDT from
> > > > > > > > > safer location?
> > > > > > > > >
> > > > > > > >
> > > > > > > > Good question.
> > > > > > > > Above can see the question I ask for Bin :
> > > > > > > > How do you think about I recovery this patch to fix this issue ?
> > > > > > > >
> > > > > > > > Before you talking about CONFIG_RISCV_PRIOR_FDT_BASE !
> > > > > > >
> > > > > > > Can you explain why you need CONFIG_OF_BOARD ?
> > > > > > > Why can you not use CONFIG_OF_PRIOR_STAGE ?
> > > > > > >
> > > > > >
> > > > > > You can find the discussion as below:
> > > > > > https://patchwork.ozlabs.org/patch/988884/
> > > > > >
> > > > >
> > > > > If I understand correctly, so far we have two scenarios to support:
> > > > >
> > > > > 1. U-Boot is booting directly from reset vector from ROM. This
> > > > > canonical way to support DT is via CONFIG_OF_EMBED or
> > > > > CONFIG_OF_SEPARATE. In such configuration, there is no any previous
> > > > > bootloader so the concept of CONFIG_OF_PRIOR_STAGE does not apply.
> > > > >
> > > > > 2. U-Boot is booting from previous bootloader, and DT is passed in a1
> > > > > register. Such configuration we can use CONFIG_OF_PRIOR_STAGE.
> > > > >
> > > >
> > > > I use the 3rd way, CONFIG_OF_BOARD.
> > > > It can be found in README.
> > > > And can be chosen by make menuconfig
> > > >
> > > > It is the most flexible way that I can implement my own board_fdt_blob_setup( )
> > > > which can both support boot from RAM or ROM without any configuration change.
> > > > I will indeed use CONFIG_OF_EMBED when u-boot is in debug stage.
> > > >
> > >
> > > What I don't understand is that if U-Boot is booting directly from the
> > > reset vector, there is no a1 passed by anyone. U-Boot itself should
> > > figure out a way to determine the DT and that's how CONFIG_OF_EMBED or
> > > CONFIG_OF_SEPARATE is doing. Can you elaborate this configuration?
> > >
> >
> > I use CONFIG_OF_BOARD and board_fdt_blob_setup as below:
> >
> > void *board_fdt_blob_setup(void)
> > {
> > void **ptr = (void *)CONFIG_SYS_SDRAM_BASE;
> > if (fdt_magic(*ptr) == FDT_MAGIC)
> > return (void *)*ptr;
> >
> > return (void *)CONFIG_SYS_FDT_BASE;
> > }
> >
> > 1. When booting from RAM
> >     a1 can be passed by loader and reserved in CONFIG_SYS_SDRAM_BASE
> > temporarily.
> >
> > 2. When booting from FLASH
> >     a1 can NOT be passed by loader and reserved in
> > CONFIG_SYS_SDRAM_BASE temporarily.
> >
> >     So dtb shall be get from CONFIG_SYS_FDT_BASE (flash base) which
> > the dtb shall be pre-burned in this flash space..
> >     Or CONFIG_SYS_FDT_BASE maybe a memory map space (NOT RAM or ROM)
> > provided by HW.
> >
> > That is why I mean using CONFIG_OF_BOARD can support both boot from
> > ram or rom with one configuration.
> >
>
> Thanks for the info. So with the latest info, I now understand you
> wanted to use CONFIG_OF_BOARD to support both configurations. That
> makes sense to me, however I still wanted to point out the canonical
> way to support booting from ROM is via CONFIG_OF_SEPARATE or
> CONFIG_OF_EMBED. Since your board can support booting from reset
> vector directly, what's the need to support the booting from RAM
> configuration?

I will develop u-boot via booting from ram. It will easy for debugging.
After develop complete.
It will be good for demo via booting from flash.
With one configuration, it can decrease to make mistake with wrong
configuration between 2 configuration
for ram or rom individually.

In that configuration, what is the first stage
> bootloader?

When booting from ram
GDB will be the first stage to load u-boot.
So it is not good for demo, because it need a pc to fire gdb.

B.R
Rick

>
> Regards,
> Bin

[U-Boot] [PATCH v5 4/4] riscv: Remove redundant a2 store on DRAM base in start.S

[Bin Meng]

Hi Rick,

On Fri, Nov 30, 2018 at 2:41 PM Rick Chen <rickchen36@gmail.com> wrote:
>
> Bin Meng <bmeng.cn@gmail.com> 於 2018年11月30日 週五 下午2:21寫道：
> >
> > Hi Rick,
> >
> > On Fri, Nov 30, 2018 at 2:05 PM Rick Chen <rickchen36@gmail.com> wrote:
> > >
> > > Bin Meng <bmeng.cn@gmail.com> 於 2018年11月30日 週五 上午9:48寫道：
> > > >
> > > > Hi Rick,
> > > >
> > > > On Thu, Nov 29, 2018 at 6:41 PM Rick Chen <rickchen36@gmail.com> wrote:
> > > > >
> > > > > Bin Meng <bmeng.cn@gmail.com> 於 2018年11月27日 週二 下午6:07寫道：
> > > > > >
> > > > > > Hi Rick,
> > > > > >
> > > > > > On Tue, Nov 27, 2018 at 4:43 PM Rick Chen <rickchen36@gmail.com> wrote:
> > > > > > >
> > > > > > > Anup Patel <anup@brainfault.org> 於 2018年11月27日 週二 下午3:56寫道：
> > > > > > > >
> > > > > > > > On Tue, Nov 27, 2018 at 12:30 PM Rick Chen <rickchen36@gmail.com> wrote:
> > > > > > > > >
> > > > > > > > > Anup Patel <anup@brainfault.org> 於 2018年11月27日 週二 下午2:40寫道：
> > > > > > > > > >
> > > > > > > > > > On Tue, Nov 27, 2018 at 12:00 PM Rick Chen <rickchen36@gmail.com> wrote:
> > > > > > > > > > >
> > > > > > > > > > > Anup Patel <anup@brainfault.org> 於 2018年11月27日 週二 下午2:14寫道：
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > On Tue, 27 Nov, 2018, 11:38 AM Rick Chen <rickchen36@gmail.com wrote:
> > > > > > > > > > > >>
> > > > > > > > > > > >> Anup Patel <anup@brainfault.org> 於 2018年11月27日 週二 下午1:47寫道：
> > > > > > > > > > > >> >
> > > > > > > > > > > >> > On Tue, Nov 27, 2018 at 11:14 AM Anup Patel <anup@brainfault.org> wrote:
> > > > > > > > > > > >> > >
> > > > > > > > > > > >> > > On Tue, Nov 27, 2018 at 10:50 AM Rick Chen <rickchen36@gmail.com> wrote:
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > Anup Patel <anup@brainfault.org> 於 2018年11月27日 週二 上午11:28寫道：
> > > > > > > > > > > >> > > > >
> > > > > > > > > > > >> > > > > On Tue, Nov 27, 2018 at 8:50 AM Rick Chen <rickchen36@gmail.com> wrote:
> > > > > > > > > > > >> > > > > >
> > > > > > > > > > > >> > > > > > > > > > Currently, the RISC-V U-Boot is saving a2 register at
> > > > > > > > > > > >> > > > > > > > > > CONFIG_SYS_DRAM_BASE in start.S which does not make sense because
> > > > > > > > > > > >> > > > > > > > > > there is no information passed by previous booting stage in a2
> > > > > > > > > > > >> > > > > > > > > > register.
> > > > > > > > > > > >> > > > > > > > > >
> > > > > > > > > > > >> > > > > > > > > > This patch removes redundant a2 store on DRAM base.
> > > > > > > > > > > >> > > > > > > > > >
> > > > > > > > > > > >> > > > > > > > > > Signed-off-by: Anup Patel <anup@brainfault.org>
> > > > > > > > > > > >> > > > > > > > > > ---
> > > > > > > > > > > >> > > > > > > > > >  arch/riscv/cpu/start.S | 2 --
> > > > > > > > > > > >> > > > > > > > > >  1 file changed, 2 deletions(-)
> > > > > > > > > > > >> > > > > > > > > >
> > > > > > > > > > > >> > > > > > > > > > diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S index
> > > > > > > > > > > >> > > > > > > > > > 704190f946..e4276e8e19 100644
> > > > > > > > > > > >> > > > > > > > > > --- a/arch/riscv/cpu/start.S
> > > > > > > > > > > >> > > > > > > > > > +++ b/arch/riscv/cpu/start.S
> > > > > > > > > > > >> > > > > > > > > > @@ -38,8 +38,6 @@ _start:
> > > > > > > > > > > >> > > > > > > > > >         mv      s0, a0
> > > > > > > > > > > >> > > > > > > > > >         mv      s1, a1
> > > > > > > > > > > >> > > > > > > > > >
> > > > > > > > > > > >> > > > > > > > > > -       li      t0, CONFIG_SYS_SDRAM_BASE
> > > > > > > > > > > >> > > > > > > > > > -       SREG    a2, 0(t0)
> > > > > > > > > > > >> > > > > > > > > >         la      t0, trap_entry
> > > > > > > > > > > >> > > > > > > > > >  #ifdef CONFIG_RISCV_SMODE
> > > > > > > > > > > >> > > > > > > > > >         csrw    stvec, t0
> > > > > > > > > > > >> > > > > > > > > > --
> > > > > > > > > > > >> > > > > > > > >
> > > > > > > > > > > >> > > > > > > > > This is weird. I remember these two lines were already removed by
> > > > > > > > > > > >> > > > > > > > > Lukas's patch series before? Did not have time to dig out the history
> > > > > > > > > > > >> > > > > > > > > though.
> > > > > > > > > > > >> > > > > > > > >
> > > > > > > > > > > >> > > > > >
> > > > > > > > > > > >> > > > > > > > > Regards,
> > > > > > > > > > > >> > > > > > > > > Bin
> > > > > > > > > > > >> > > > > > > >
> > > > > > > > > > > >> > > > > > > > You are correct, however I removed it again, because I did not want to break
> > > > > > > > > > > >> > > > > > > > Rick's board. He did add a commit to the last pull request that removes these
> > > > > > > > > > > >> > > > > > > > two lines and adjusts his board accordingly, but it is not in the current one.
> > > > > > > > > > > >> > > > > > > >
> > > > > > > > > > > >> > > > > >
> > > > > > > > > > > >> > > > > > Hi Likas
> > > > > > > > > > > >> > > > > >
> > > > > > > > > > > >> > > > > > Thanks for your explanation.
> > > > > > > > > > > >> > > > > >
> > > > > > > > > > > >> > > > > > RIck's commit as below
> > > > > > > > > > > >> > > > > > https://www.mail-archive.com/u-boot at lists.denx.de/msg305880.html
> > > > > > > > > > > >> > > > >
> > > > > > > > > > > >> > > > > When we run U-Boot in S-mode the BBL runs from 0x80000000 so this
> > > > > > > > > > > >> > > > > two lines corrupts BBL instructions.
> > > > > > > > > > > >> > > > >
> > > > > > > > > > > >> > > > > If this is important for some board then please have it around #ifdef.
> > > > > > > > > > > >> > > > >
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > Hi Anup
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > In the discussion as below :
> > > > > > > > > > > >> > > > https://www.mail-archive.com/u-boot at lists.denx.de/msg305880.html
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > I try to solve this issue with the aptch
> > > > > > > > > > > >> > > > [PATCH] riscv: ax25-ae350: Pass dtb address to u-boot with a1 register
> > > > > > > > > > > >> > > > diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S
> > > > > > > > > > > >> > > > -       li      t0, CONFIG_SYS_SDRAM_BASE
> > > > > > > > > > > >> > > > -       SREG    a2, 0(t0)
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > diff --git a/board/AndesTech/ax25-ae350/ax25-ae350.c
> > > > > > > > > > > >> > > > b/board/AndesTech/ax25-ae350/ax25-ae350.c
> > > > > > > > > > > >> > > >  void *board_fdt_blob_setup(void)
> > > > > > > > > > > >> > > >  {
> > > > > > > > > > > >> > > > -       void **ptr = (void *)CONFIG_SYS_SDRAM_BASE;
> > > > > > > > > > > >> > > > +       void **ptr = (void *)&prior_stage_fdt_address;
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > in the previous pull request.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > But Bin do not agree with that I use prior_stage_fdt_address in
> > > > > > > > > > > >> > > > board_fdt_blob_setup( )
> > > > > > > > > > > >> > > > I try to explain why I use it like that way.
> > > > > > > > > > > >> > > > Then Bin have not any reply in the following mail.
> > > > > > > > > > > >> > > > Finally I decide to drop this patch in the next pull request.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > Hi Bin
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > How do you think about I recovery this patch to fix this issue ?
> > > > > > > > > > > >> > >
> > > > > > > > > > > >> > > Actually, previous booting stage can pass location of FDT stored in flash
> > > > > > > > > > > >> > > to U-Boot. U-Boot requires FDT at a DRAM location which it can modify
> > > > > > > > > > > >> > > in-place before passing on to Linux kernel so we should relocate the FDT
> > > > > > > > > > > >> > > passed by previous booting stage to some board specific DRAM location.
> > > > > > > > > > > >> > >
> > > > > > > > > > > >> > > My suggestion is as follows:
> > > > > > > > > > > >> > >
> > > > > > > > > > > >> > > Instead of SDRAM_BASE, we can have new board specific config
> > > > > > > > > > > >> > > CONFIG_RISCV_PRIOR_FDT_BASE
> > > > > > > > > > > >> > >
> > > > > > > > > > > >> > > If CONFIG_RISCV_PRIOR_FDT_BASE is defined/selected by
> > > > > > > > > > > >> > > config then in start.S copy-over the FDT from location pointed by
> > > > > > > > > > > >> > > "a1" register to location pointed by CONFIG_RISCV_PRIOR_FDT_BASE.
> > > > > > > > > > > >> >
> > > > > > > > > > > >>
> > > > > > > > > > > >> Hi Anup
> > > > > > > > > > > >>
> > > > > > > > > > > >> It can not achieve dtb delivery at runtime.
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > Can you elaborate why?
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > CONFIG_RISCV_PRIOR_FDT_BASE is determined at compile time.
> > > > > > > > > > > I am wondering how it can be modified at run time ?
> > > > > > > > > >
> > > > > > > > > > I think you miss-understood my suggestion. I did not meant changing
> > > > > > > > > > CONFIG_RISCV_PRIOR_FDT_BASE at runtime.
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > > I am sure we can always relocate FDT passed by previous stage to some safer location and use it from there.
> > > > > > > > > > >
> > > > > > > > > > > My original patch also can achieve that dtb passed by a1 and relocated and boot.
> > > > > > > > > >
> > > > > > > > > > Great !!!
> > > > > > > > > >
> > > > > > > > > > Why not update your original patch to relocate FDT and use FDT from
> > > > > > > > > > safer location?
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > Good question.
> > > > > > > > > Above can see the question I ask for Bin :
> > > > > > > > > How do you think about I recovery this patch to fix this issue ?
> > > > > > > > >
> > > > > > > > > Before you talking about CONFIG_RISCV_PRIOR_FDT_BASE !
> > > > > > > >
> > > > > > > > Can you explain why you need CONFIG_OF_BOARD ?
> > > > > > > > Why can you not use CONFIG_OF_PRIOR_STAGE ?
> > > > > > > >
> > > > > > >
> > > > > > > You can find the discussion as below:
> > > > > > > https://patchwork.ozlabs.org/patch/988884/
> > > > > > >
> > > > > >
> > > > > > If I understand correctly, so far we have two scenarios to support:
> > > > > >
> > > > > > 1. U-Boot is booting directly from reset vector from ROM. This
> > > > > > canonical way to support DT is via CONFIG_OF_EMBED or
> > > > > > CONFIG_OF_SEPARATE. In such configuration, there is no any previous
> > > > > > bootloader so the concept of CONFIG_OF_PRIOR_STAGE does not apply.
> > > > > >
> > > > > > 2. U-Boot is booting from previous bootloader, and DT is passed in a1
> > > > > > register. Such configuration we can use CONFIG_OF_PRIOR_STAGE.
> > > > > >
> > > > >
> > > > > I use the 3rd way, CONFIG_OF_BOARD.
> > > > > It can be found in README.
> > > > > And can be chosen by make menuconfig
> > > > >
> > > > > It is the most flexible way that I can implement my own board_fdt_blob_setup( )
> > > > > which can both support boot from RAM or ROM without any configuration change.
> > > > > I will indeed use CONFIG_OF_EMBED when u-boot is in debug stage.
> > > > >
> > > >
> > > > What I don't understand is that if U-Boot is booting directly from the
> > > > reset vector, there is no a1 passed by anyone. U-Boot itself should
> > > > figure out a way to determine the DT and that's how CONFIG_OF_EMBED or
> > > > CONFIG_OF_SEPARATE is doing. Can you elaborate this configuration?
> > > >
> > >
> > > I use CONFIG_OF_BOARD and board_fdt_blob_setup as below:
> > >
> > > void *board_fdt_blob_setup(void)
> > > {
> > > void **ptr = (void *)CONFIG_SYS_SDRAM_BASE;
> > > if (fdt_magic(*ptr) == FDT_MAGIC)
> > > return (void *)*ptr;
> > >
> > > return (void *)CONFIG_SYS_FDT_BASE;
> > > }
> > >
> > > 1. When booting from RAM
> > >     a1 can be passed by loader and reserved in CONFIG_SYS_SDRAM_BASE
> > > temporarily.
> > >
> > > 2. When booting from FLASH
> > >     a1 can NOT be passed by loader and reserved in
> > > CONFIG_SYS_SDRAM_BASE temporarily.
> > >
> > >     So dtb shall be get from CONFIG_SYS_FDT_BASE (flash base) which
> > > the dtb shall be pre-burned in this flash space..
> > >     Or CONFIG_SYS_FDT_BASE maybe a memory map space (NOT RAM or ROM)
> > > provided by HW.
> > >
> > > That is why I mean using CONFIG_OF_BOARD can support both boot from
> > > ram or rom with one configuration.
> > >
> >
> > Thanks for the info. So with the latest info, I now understand you
> > wanted to use CONFIG_OF_BOARD to support both configurations. That
> > makes sense to me, however I still wanted to point out the canonical
> > way to support booting from ROM is via CONFIG_OF_SEPARATE or
> > CONFIG_OF_EMBED. Since your board can support booting from reset
> > vector directly, what's the need to support the booting from RAM
> > configuration?
>
> I will develop u-boot via booting from ram. It will easy for debugging.
> After develop complete.
> It will be good for demo via booting from flash.
> With one configuration, it can decrease to make mistake with wrong
> configuration between 2 configuration
> for ram or rom individually.
>
> In that configuration, what is the first stage
> > bootloader?
>
> When booting from ram
> GDB will be the first stage to load u-boot.
> So it is not good for demo, because it need a pc to fire gdb.
>

OK, thanks for the info. For this patch, let's go with your proposal
then, but please add some comments in the codes there for people to
understand later.

Regards,
Bin

[U-Boot] [PATCH v5 4/4] riscv: Remove redundant a2 store on DRAM base in start.S

[Rick Chen]

Bin Meng <bmeng.cn@gmail.com> 於 2018年11月30日 週五 下午2:57寫道：
>
> Hi Rick,
>
> On Fri, Nov 30, 2018 at 2:41 PM Rick Chen <rickchen36@gmail.com> wrote:
> >
> > Bin Meng <bmeng.cn@gmail.com> 於 2018年11月30日 週五 下午2:21寫道：
> > >
> > > Hi Rick,
> > >
> > > On Fri, Nov 30, 2018 at 2:05 PM Rick Chen <rickchen36@gmail.com> wrote:
> > > >
> > > > Bin Meng <bmeng.cn@gmail.com> 於 2018年11月30日 週五 上午9:48寫道：
> > > > >
> > > > > Hi Rick,
> > > > >
> > > > > On Thu, Nov 29, 2018 at 6:41 PM Rick Chen <rickchen36@gmail.com> wrote:
> > > > > >
> > > > > > Bin Meng <bmeng.cn@gmail.com> 於 2018年11月27日 週二 下午6:07寫道：
> > > > > > >
> > > > > > > Hi Rick,
> > > > > > >
> > > > > > > On Tue, Nov 27, 2018 at 4:43 PM Rick Chen <rickchen36@gmail.com> wrote:
> > > > > > > >
> > > > > > > > Anup Patel <anup@brainfault.org> 於 2018年11月27日 週二 下午3:56寫道：
> > > > > > > > >
> > > > > > > > > On Tue, Nov 27, 2018 at 12:30 PM Rick Chen <rickchen36@gmail.com> wrote:
> > > > > > > > > >
> > > > > > > > > > Anup Patel <anup@brainfault.org> 於 2018年11月27日 週二 下午2:40寫道：
> > > > > > > > > > >
> > > > > > > > > > > On Tue, Nov 27, 2018 at 12:00 PM Rick Chen <rickchen36@gmail.com> wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > Anup Patel <anup@brainfault.org> 於 2018年11月27日 週二 下午2:14寫道：
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Tue, 27 Nov, 2018, 11:38 AM Rick Chen <rickchen36@gmail.com wrote:
> > > > > > > > > > > > >>
> > > > > > > > > > > > >> Anup Patel <anup@brainfault.org> 於 2018年11月27日 週二 下午1:47寫道：
> > > > > > > > > > > > >> >
> > > > > > > > > > > > >> > On Tue, Nov 27, 2018 at 11:14 AM Anup Patel <anup@brainfault.org> wrote:
> > > > > > > > > > > > >> > >
> > > > > > > > > > > > >> > > On Tue, Nov 27, 2018 at 10:50 AM Rick Chen <rickchen36@gmail.com> wrote:
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > Anup Patel <anup@brainfault.org> 於 2018年11月27日 週二 上午11:28寫道：
> > > > > > > > > > > > >> > > > >
> > > > > > > > > > > > >> > > > > On Tue, Nov 27, 2018 at 8:50 AM Rick Chen <rickchen36@gmail.com> wrote:
> > > > > > > > > > > > >> > > > > >
> > > > > > > > > > > > >> > > > > > > > > > Currently, the RISC-V U-Boot is saving a2 register at
> > > > > > > > > > > > >> > > > > > > > > > CONFIG_SYS_DRAM_BASE in start.S which does not make sense because
> > > > > > > > > > > > >> > > > > > > > > > there is no information passed by previous booting stage in a2
> > > > > > > > > > > > >> > > > > > > > > > register.
> > > > > > > > > > > > >> > > > > > > > > >
> > > > > > > > > > > > >> > > > > > > > > > This patch removes redundant a2 store on DRAM base.
> > > > > > > > > > > > >> > > > > > > > > >
> > > > > > > > > > > > >> > > > > > > > > > Signed-off-by: Anup Patel <anup@brainfault.org>
> > > > > > > > > > > > >> > > > > > > > > > ---
> > > > > > > > > > > > >> > > > > > > > > >  arch/riscv/cpu/start.S | 2 --
> > > > > > > > > > > > >> > > > > > > > > >  1 file changed, 2 deletions(-)
> > > > > > > > > > > > >> > > > > > > > > >
> > > > > > > > > > > > >> > > > > > > > > > diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S index
> > > > > > > > > > > > >> > > > > > > > > > 704190f946..e4276e8e19 100644
> > > > > > > > > > > > >> > > > > > > > > > --- a/arch/riscv/cpu/start.S
> > > > > > > > > > > > >> > > > > > > > > > +++ b/arch/riscv/cpu/start.S
> > > > > > > > > > > > >> > > > > > > > > > @@ -38,8 +38,6 @@ _start:
> > > > > > > > > > > > >> > > > > > > > > >         mv      s0, a0
> > > > > > > > > > > > >> > > > > > > > > >         mv      s1, a1
> > > > > > > > > > > > >> > > > > > > > > >
> > > > > > > > > > > > >> > > > > > > > > > -       li      t0, CONFIG_SYS_SDRAM_BASE
> > > > > > > > > > > > >> > > > > > > > > > -       SREG    a2, 0(t0)
> > > > > > > > > > > > >> > > > > > > > > >         la      t0, trap_entry
> > > > > > > > > > > > >> > > > > > > > > >  #ifdef CONFIG_RISCV_SMODE
> > > > > > > > > > > > >> > > > > > > > > >         csrw    stvec, t0
> > > > > > > > > > > > >> > > > > > > > > > --
> > > > > > > > > > > > >> > > > > > > > >
> > > > > > > > > > > > >> > > > > > > > > This is weird. I remember these two lines were already removed by
> > > > > > > > > > > > >> > > > > > > > > Lukas's patch series before? Did not have time to dig out the history
> > > > > > > > > > > > >> > > > > > > > > though.
> > > > > > > > > > > > >> > > > > > > > >
> > > > > > > > > > > > >> > > > > >
> > > > > > > > > > > > >> > > > > > > > > Regards,
> > > > > > > > > > > > >> > > > > > > > > Bin
> > > > > > > > > > > > >> > > > > > > >
> > > > > > > > > > > > >> > > > > > > > You are correct, however I removed it again, because I did not want to break
> > > > > > > > > > > > >> > > > > > > > Rick's board. He did add a commit to the last pull request that removes these
> > > > > > > > > > > > >> > > > > > > > two lines and adjusts his board accordingly, but it is not in the current one.
> > > > > > > > > > > > >> > > > > > > >
> > > > > > > > > > > > >> > > > > >
> > > > > > > > > > > > >> > > > > > Hi Likas
> > > > > > > > > > > > >> > > > > >
> > > > > > > > > > > > >> > > > > > Thanks for your explanation.
> > > > > > > > > > > > >> > > > > >
> > > > > > > > > > > > >> > > > > > RIck's commit as below
> > > > > > > > > > > > >> > > > > > https://www.mail-archive.com/u-boot at lists.denx.de/msg305880.html
> > > > > > > > > > > > >> > > > >
> > > > > > > > > > > > >> > > > > When we run U-Boot in S-mode the BBL runs from 0x80000000 so this
> > > > > > > > > > > > >> > > > > two lines corrupts BBL instructions.
> > > > > > > > > > > > >> > > > >
> > > > > > > > > > > > >> > > > > If this is important for some board then please have it around #ifdef.
> > > > > > > > > > > > >> > > > >
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > Hi Anup
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > In the discussion as below :
> > > > > > > > > > > > >> > > > https://www.mail-archive.com/u-boot at lists.denx.de/msg305880.html
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > I try to solve this issue with the aptch
> > > > > > > > > > > > >> > > > [PATCH] riscv: ax25-ae350: Pass dtb address to u-boot with a1 register
> > > > > > > > > > > > >> > > > diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S
> > > > > > > > > > > > >> > > > -       li      t0, CONFIG_SYS_SDRAM_BASE
> > > > > > > > > > > > >> > > > -       SREG    a2, 0(t0)
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > diff --git a/board/AndesTech/ax25-ae350/ax25-ae350.c
> > > > > > > > > > > > >> > > > b/board/AndesTech/ax25-ae350/ax25-ae350.c
> > > > > > > > > > > > >> > > >  void *board_fdt_blob_setup(void)
> > > > > > > > > > > > >> > > >  {
> > > > > > > > > > > > >> > > > -       void **ptr = (void *)CONFIG_SYS_SDRAM_BASE;
> > > > > > > > > > > > >> > > > +       void **ptr = (void *)&prior_stage_fdt_address;
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > in the previous pull request.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > But Bin do not agree with that I use prior_stage_fdt_address in
> > > > > > > > > > > > >> > > > board_fdt_blob_setup( )
> > > > > > > > > > > > >> > > > I try to explain why I use it like that way.
> > > > > > > > > > > > >> > > > Then Bin have not any reply in the following mail.
> > > > > > > > > > > > >> > > > Finally I decide to drop this patch in the next pull request.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > Hi Bin
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > How do you think about I recovery this patch to fix this issue ?
> > > > > > > > > > > > >> > >
> > > > > > > > > > > > >> > > Actually, previous booting stage can pass location of FDT stored in flash
> > > > > > > > > > > > >> > > to U-Boot. U-Boot requires FDT at a DRAM location which it can modify
> > > > > > > > > > > > >> > > in-place before passing on to Linux kernel so we should relocate the FDT
> > > > > > > > > > > > >> > > passed by previous booting stage to some board specific DRAM location.
> > > > > > > > > > > > >> > >
> > > > > > > > > > > > >> > > My suggestion is as follows:
> > > > > > > > > > > > >> > >
> > > > > > > > > > > > >> > > Instead of SDRAM_BASE, we can have new board specific config
> > > > > > > > > > > > >> > > CONFIG_RISCV_PRIOR_FDT_BASE
> > > > > > > > > > > > >> > >
> > > > > > > > > > > > >> > > If CONFIG_RISCV_PRIOR_FDT_BASE is defined/selected by
> > > > > > > > > > > > >> > > config then in start.S copy-over the FDT from location pointed by
> > > > > > > > > > > > >> > > "a1" register to location pointed by CONFIG_RISCV_PRIOR_FDT_BASE.
> > > > > > > > > > > > >> >
> > > > > > > > > > > > >>
> > > > > > > > > > > > >> Hi Anup
> > > > > > > > > > > > >>
> > > > > > > > > > > > >> It can not achieve dtb delivery at runtime.
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > Can you elaborate why?
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > CONFIG_RISCV_PRIOR_FDT_BASE is determined at compile time.
> > > > > > > > > > > > I am wondering how it can be modified at run time ?
> > > > > > > > > > >
> > > > > > > > > > > I think you miss-understood my suggestion. I did not meant changing
> > > > > > > > > > > CONFIG_RISCV_PRIOR_FDT_BASE at runtime.
> > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > > I am sure we can always relocate FDT passed by previous stage to some safer location and use it from there.
> > > > > > > > > > > >
> > > > > > > > > > > > My original patch also can achieve that dtb passed by a1 and relocated and boot.
> > > > > > > > > > >
> > > > > > > > > > > Great !!!
> > > > > > > > > > >
> > > > > > > > > > > Why not update your original patch to relocate FDT and use FDT from
> > > > > > > > > > > safer location?
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Good question.
> > > > > > > > > > Above can see the question I ask for Bin :
> > > > > > > > > > How do you think about I recovery this patch to fix this issue ?
> > > > > > > > > >
> > > > > > > > > > Before you talking about CONFIG_RISCV_PRIOR_FDT_BASE !
> > > > > > > > >
> > > > > > > > > Can you explain why you need CONFIG_OF_BOARD ?
> > > > > > > > > Why can you not use CONFIG_OF_PRIOR_STAGE ?
> > > > > > > > >
> > > > > > > >
> > > > > > > > You can find the discussion as below:
> > > > > > > > https://patchwork.ozlabs.org/patch/988884/
> > > > > > > >
> > > > > > >
> > > > > > > If I understand correctly, so far we have two scenarios to support:
> > > > > > >
> > > > > > > 1. U-Boot is booting directly from reset vector from ROM. This
> > > > > > > canonical way to support DT is via CONFIG_OF_EMBED or
> > > > > > > CONFIG_OF_SEPARATE. In such configuration, there is no any previous
> > > > > > > bootloader so the concept of CONFIG_OF_PRIOR_STAGE does not apply.
> > > > > > >
> > > > > > > 2. U-Boot is booting from previous bootloader, and DT is passed in a1
> > > > > > > register. Such configuration we can use CONFIG_OF_PRIOR_STAGE.
> > > > > > >
> > > > > >
> > > > > > I use the 3rd way, CONFIG_OF_BOARD.
> > > > > > It can be found in README.
> > > > > > And can be chosen by make menuconfig
> > > > > >
> > > > > > It is the most flexible way that I can implement my own board_fdt_blob_setup( )
> > > > > > which can both support boot from RAM or ROM without any configuration change.
> > > > > > I will indeed use CONFIG_OF_EMBED when u-boot is in debug stage.
> > > > > >
> > > > >
> > > > > What I don't understand is that if U-Boot is booting directly from the
> > > > > reset vector, there is no a1 passed by anyone. U-Boot itself should
> > > > > figure out a way to determine the DT and that's how CONFIG_OF_EMBED or
> > > > > CONFIG_OF_SEPARATE is doing. Can you elaborate this configuration?
> > > > >
> > > >
> > > > I use CONFIG_OF_BOARD and board_fdt_blob_setup as below:
> > > >
> > > > void *board_fdt_blob_setup(void)
> > > > {
> > > > void **ptr = (void *)CONFIG_SYS_SDRAM_BASE;
> > > > if (fdt_magic(*ptr) == FDT_MAGIC)
> > > > return (void *)*ptr;
> > > >
> > > > return (void *)CONFIG_SYS_FDT_BASE;
> > > > }
> > > >
> > > > 1. When booting from RAM
> > > >     a1 can be passed by loader and reserved in CONFIG_SYS_SDRAM_BASE
> > > > temporarily.
> > > >
> > > > 2. When booting from FLASH
> > > >     a1 can NOT be passed by loader and reserved in
> > > > CONFIG_SYS_SDRAM_BASE temporarily.
> > > >
> > > >     So dtb shall be get from CONFIG_SYS_FDT_BASE (flash base) which
> > > > the dtb shall be pre-burned in this flash space..
> > > >     Or CONFIG_SYS_FDT_BASE maybe a memory map space (NOT RAM or ROM)
> > > > provided by HW.
> > > >
> > > > That is why I mean using CONFIG_OF_BOARD can support both boot from
> > > > ram or rom with one configuration.
> > > >
> > >
> > > Thanks for the info. So with the latest info, I now understand you
> > > wanted to use CONFIG_OF_BOARD to support both configurations. That
> > > makes sense to me, however I still wanted to point out the canonical
> > > way to support booting from ROM is via CONFIG_OF_SEPARATE or
> > > CONFIG_OF_EMBED. Since your board can support booting from reset
> > > vector directly, what's the need to support the booting from RAM
> > > configuration?
> >
> > I will develop u-boot via booting from ram. It will easy for debugging.
> > After develop complete.
> > It will be good for demo via booting from flash.
> > With one configuration, it can decrease to make mistake with wrong
> > configuration between 2 configuration
> > for ram or rom individually.
> >
> > In that configuration, what is the first stage
> > > bootloader?
> >
> > When booting from ram
> > GDB will be the first stage to load u-boot.
> > So it is not good for demo, because it need a pc to fire gdb.
> >
>
> OK, thanks for the info. For this patch, let's go with your proposal
> then, but please add some comments in the codes there for people to
> understand later.

Hi Bin

You say go with your proposal :
Does that mean you agree with the following modification ?
arch/riscv/cpu/start.S
-       li      t0, CONFIG_SYS_SDRAM_BASE
-       SREG    a2, 0(t0)

board/AndesTech/ax25-ae350/ax25-ae350.c
 void *board_fdt_blob_setup(void)
 {
-       void **ptr = (void *)CONFIG_SYS_SDRAM_BASE;
+       void **ptr = (void *)&prior_stage_fdt_address;

And add some comments in this patch for people to understand it.

Or
I still can NOT borrow prior_stage_fdt_address and shall find another
way to overcome the problem
after remove the two line in start.S ?

B.R
Rick

>
> Regards,
> Bin

[U-Boot] [PATCH v5 4/4] riscv: Remove redundant a2 store on DRAM base in start.S

[Bin Meng]

Hi Rick,

On Fri, Nov 30, 2018 at 3:15 PM Rick Chen <rickchen36@gmail.com> wrote:
>
> Bin Meng <bmeng.cn@gmail.com> 於 2018年11月30日 週五 下午2:57寫道：
> >
> > Hi Rick,
> >
> > On Fri, Nov 30, 2018 at 2:41 PM Rick Chen <rickchen36@gmail.com> wrote:
> > >
> > > Bin Meng <bmeng.cn@gmail.com> 於 2018年11月30日 週五 下午2:21寫道：
> > > >
> > > > Hi Rick,
> > > >
> > > > On Fri, Nov 30, 2018 at 2:05 PM Rick Chen <rickchen36@gmail.com> wrote:
> > > > >
> > > > > Bin Meng <bmeng.cn@gmail.com> 於 2018年11月30日 週五 上午9:48寫道：
> > > > > >
> > > > > > Hi Rick,
> > > > > >
> > > > > > On Thu, Nov 29, 2018 at 6:41 PM Rick Chen <rickchen36@gmail.com> wrote:
> > > > > > >
> > > > > > > Bin Meng <bmeng.cn@gmail.com> 於 2018年11月27日 週二 下午6:07寫道：
> > > > > > > >
> > > > > > > > Hi Rick,
> > > > > > > >
> > > > > > > > On Tue, Nov 27, 2018 at 4:43 PM Rick Chen <rickchen36@gmail.com> wrote:
> > > > > > > > >
> > > > > > > > > Anup Patel <anup@brainfault.org> 於 2018年11月27日 週二 下午3:56寫道：
> > > > > > > > > >
> > > > > > > > > > On Tue, Nov 27, 2018 at 12:30 PM Rick Chen <rickchen36@gmail.com> wrote:
> > > > > > > > > > >
> > > > > > > > > > > Anup Patel <anup@brainfault.org> 於 2018年11月27日 週二 下午2:40寫道：
> > > > > > > > > > > >
> > > > > > > > > > > > On Tue, Nov 27, 2018 at 12:00 PM Rick Chen <rickchen36@gmail.com> wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > Anup Patel <anup@brainfault.org> 於 2018年11月27日 週二 下午2:14寫道：
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Tue, 27 Nov, 2018, 11:38 AM Rick Chen <rickchen36@gmail.com wrote:
> > > > > > > > > > > > > >>
> > > > > > > > > > > > > >> Anup Patel <anup@brainfault.org> 於 2018年11月27日 週二 下午1:47寫道：
> > > > > > > > > > > > > >> >
> > > > > > > > > > > > > >> > On Tue, Nov 27, 2018 at 11:14 AM Anup Patel <anup@brainfault.org> wrote:
> > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > >> > > On Tue, Nov 27, 2018 at 10:50 AM Rick Chen <rickchen36@gmail.com> wrote:
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > Anup Patel <anup@brainfault.org> 於 2018年11月27日 週二 上午11:28寫道：
> > > > > > > > > > > > > >> > > > >
> > > > > > > > > > > > > >> > > > > On Tue, Nov 27, 2018 at 8:50 AM Rick Chen <rickchen36@gmail.com> wrote:
> > > > > > > > > > > > > >> > > > > >
> > > > > > > > > > > > > >> > > > > > > > > > Currently, the RISC-V U-Boot is saving a2 register at
> > > > > > > > > > > > > >> > > > > > > > > > CONFIG_SYS_DRAM_BASE in start.S which does not make sense because
> > > > > > > > > > > > > >> > > > > > > > > > there is no information passed by previous booting stage in a2
> > > > > > > > > > > > > >> > > > > > > > > > register.
> > > > > > > > > > > > > >> > > > > > > > > >
> > > > > > > > > > > > > >> > > > > > > > > > This patch removes redundant a2 store on DRAM base.
> > > > > > > > > > > > > >> > > > > > > > > >
> > > > > > > > > > > > > >> > > > > > > > > > Signed-off-by: Anup Patel <anup@brainfault.org>
> > > > > > > > > > > > > >> > > > > > > > > > ---
> > > > > > > > > > > > > >> > > > > > > > > >  arch/riscv/cpu/start.S | 2 --
> > > > > > > > > > > > > >> > > > > > > > > >  1 file changed, 2 deletions(-)
> > > > > > > > > > > > > >> > > > > > > > > >
> > > > > > > > > > > > > >> > > > > > > > > > diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S index
> > > > > > > > > > > > > >> > > > > > > > > > 704190f946..e4276e8e19 100644
> > > > > > > > > > > > > >> > > > > > > > > > --- a/arch/riscv/cpu/start.S
> > > > > > > > > > > > > >> > > > > > > > > > +++ b/arch/riscv/cpu/start.S
> > > > > > > > > > > > > >> > > > > > > > > > @@ -38,8 +38,6 @@ _start:
> > > > > > > > > > > > > >> > > > > > > > > >         mv      s0, a0
> > > > > > > > > > > > > >> > > > > > > > > >         mv      s1, a1
> > > > > > > > > > > > > >> > > > > > > > > >
> > > > > > > > > > > > > >> > > > > > > > > > -       li      t0, CONFIG_SYS_SDRAM_BASE
> > > > > > > > > > > > > >> > > > > > > > > > -       SREG    a2, 0(t0)
> > > > > > > > > > > > > >> > > > > > > > > >         la      t0, trap_entry
> > > > > > > > > > > > > >> > > > > > > > > >  #ifdef CONFIG_RISCV_SMODE
> > > > > > > > > > > > > >> > > > > > > > > >         csrw    stvec, t0
> > > > > > > > > > > > > >> > > > > > > > > > --
> > > > > > > > > > > > > >> > > > > > > > >
> > > > > > > > > > > > > >> > > > > > > > > This is weird. I remember these two lines were already removed by
> > > > > > > > > > > > > >> > > > > > > > > Lukas's patch series before? Did not have time to dig out the history
> > > > > > > > > > > > > >> > > > > > > > > though.
> > > > > > > > > > > > > >> > > > > > > > >
> > > > > > > > > > > > > >> > > > > >
> > > > > > > > > > > > > >> > > > > > > > > Regards,
> > > > > > > > > > > > > >> > > > > > > > > Bin
> > > > > > > > > > > > > >> > > > > > > >
> > > > > > > > > > > > > >> > > > > > > > You are correct, however I removed it again, because I did not want to break
> > > > > > > > > > > > > >> > > > > > > > Rick's board. He did add a commit to the last pull request that removes these
> > > > > > > > > > > > > >> > > > > > > > two lines and adjusts his board accordingly, but it is not in the current one.
> > > > > > > > > > > > > >> > > > > > > >
> > > > > > > > > > > > > >> > > > > >
> > > > > > > > > > > > > >> > > > > > Hi Likas
> > > > > > > > > > > > > >> > > > > >
> > > > > > > > > > > > > >> > > > > > Thanks for your explanation.
> > > > > > > > > > > > > >> > > > > >
> > > > > > > > > > > > > >> > > > > > RIck's commit as below
> > > > > > > > > > > > > >> > > > > > https://www.mail-archive.com/u-boot at lists.denx.de/msg305880.html
> > > > > > > > > > > > > >> > > > >
> > > > > > > > > > > > > >> > > > > When we run U-Boot in S-mode the BBL runs from 0x80000000 so this
> > > > > > > > > > > > > >> > > > > two lines corrupts BBL instructions.
> > > > > > > > > > > > > >> > > > >
> > > > > > > > > > > > > >> > > > > If this is important for some board then please have it around #ifdef.
> > > > > > > > > > > > > >> > > > >
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > Hi Anup
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > In the discussion as below :
> > > > > > > > > > > > > >> > > > https://www.mail-archive.com/u-boot at lists.denx.de/msg305880.html
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > I try to solve this issue with the aptch
> > > > > > > > > > > > > >> > > > [PATCH] riscv: ax25-ae350: Pass dtb address to u-boot with a1 register
> > > > > > > > > > > > > >> > > > diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S
> > > > > > > > > > > > > >> > > > -       li      t0, CONFIG_SYS_SDRAM_BASE
> > > > > > > > > > > > > >> > > > -       SREG    a2, 0(t0)
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > diff --git a/board/AndesTech/ax25-ae350/ax25-ae350.c
> > > > > > > > > > > > > >> > > > b/board/AndesTech/ax25-ae350/ax25-ae350.c
> > > > > > > > > > > > > >> > > >  void *board_fdt_blob_setup(void)
> > > > > > > > > > > > > >> > > >  {
> > > > > > > > > > > > > >> > > > -       void **ptr = (void *)CONFIG_SYS_SDRAM_BASE;
> > > > > > > > > > > > > >> > > > +       void **ptr = (void *)&prior_stage_fdt_address;
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > in the previous pull request.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > But Bin do not agree with that I use prior_stage_fdt_address in
> > > > > > > > > > > > > >> > > > board_fdt_blob_setup( )
> > > > > > > > > > > > > >> > > > I try to explain why I use it like that way.
> > > > > > > > > > > > > >> > > > Then Bin have not any reply in the following mail.
> > > > > > > > > > > > > >> > > > Finally I decide to drop this patch in the next pull request.
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > Hi Bin
> > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > >> > > > How do you think about I recovery this patch to fix this issue ?
> > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > >> > > Actually, previous booting stage can pass location of FDT stored in flash
> > > > > > > > > > > > > >> > > to U-Boot. U-Boot requires FDT at a DRAM location which it can modify
> > > > > > > > > > > > > >> > > in-place before passing on to Linux kernel so we should relocate the FDT
> > > > > > > > > > > > > >> > > passed by previous booting stage to some board specific DRAM location.
> > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > >> > > My suggestion is as follows:
> > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > >> > > Instead of SDRAM_BASE, we can have new board specific config
> > > > > > > > > > > > > >> > > CONFIG_RISCV_PRIOR_FDT_BASE
> > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > >> > > If CONFIG_RISCV_PRIOR_FDT_BASE is defined/selected by
> > > > > > > > > > > > > >> > > config then in start.S copy-over the FDT from location pointed by
> > > > > > > > > > > > > >> > > "a1" register to location pointed by CONFIG_RISCV_PRIOR_FDT_BASE.
> > > > > > > > > > > > > >> >
> > > > > > > > > > > > > >>
> > > > > > > > > > > > > >> Hi Anup
> > > > > > > > > > > > > >>
> > > > > > > > > > > > > >> It can not achieve dtb delivery at runtime.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Can you elaborate why?
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > CONFIG_RISCV_PRIOR_FDT_BASE is determined at compile time.
> > > > > > > > > > > > > I am wondering how it can be modified at run time ?
> > > > > > > > > > > >
> > > > > > > > > > > > I think you miss-understood my suggestion. I did not meant changing
> > > > > > > > > > > > CONFIG_RISCV_PRIOR_FDT_BASE at runtime.
> > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > > I am sure we can always relocate FDT passed by previous stage to some safer location and use it from there.
> > > > > > > > > > > > >
> > > > > > > > > > > > > My original patch also can achieve that dtb passed by a1 and relocated and boot.
> > > > > > > > > > > >
> > > > > > > > > > > > Great !!!
> > > > > > > > > > > >
> > > > > > > > > > > > Why not update your original patch to relocate FDT and use FDT from
> > > > > > > > > > > > safer location?
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > Good question.
> > > > > > > > > > > Above can see the question I ask for Bin :
> > > > > > > > > > > How do you think about I recovery this patch to fix this issue ?
> > > > > > > > > > >
> > > > > > > > > > > Before you talking about CONFIG_RISCV_PRIOR_FDT_BASE !
> > > > > > > > > >
> > > > > > > > > > Can you explain why you need CONFIG_OF_BOARD ?
> > > > > > > > > > Why can you not use CONFIG_OF_PRIOR_STAGE ?
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > You can find the discussion as below:
> > > > > > > > > https://patchwork.ozlabs.org/patch/988884/
> > > > > > > > >
> > > > > > > >
> > > > > > > > If I understand correctly, so far we have two scenarios to support:
> > > > > > > >
> > > > > > > > 1. U-Boot is booting directly from reset vector from ROM. This
> > > > > > > > canonical way to support DT is via CONFIG_OF_EMBED or
> > > > > > > > CONFIG_OF_SEPARATE. In such configuration, there is no any previous
> > > > > > > > bootloader so the concept of CONFIG_OF_PRIOR_STAGE does not apply.
> > > > > > > >
> > > > > > > > 2. U-Boot is booting from previous bootloader, and DT is passed in a1
> > > > > > > > register. Such configuration we can use CONFIG_OF_PRIOR_STAGE.
> > > > > > > >
> > > > > > >
> > > > > > > I use the 3rd way, CONFIG_OF_BOARD.
> > > > > > > It can be found in README.
> > > > > > > And can be chosen by make menuconfig
> > > > > > >
> > > > > > > It is the most flexible way that I can implement my own board_fdt_blob_setup( )
> > > > > > > which can both support boot from RAM or ROM without any configuration change.
> > > > > > > I will indeed use CONFIG_OF_EMBED when u-boot is in debug stage.
> > > > > > >
> > > > > >
> > > > > > What I don't understand is that if U-Boot is booting directly from the
> > > > > > reset vector, there is no a1 passed by anyone. U-Boot itself should
> > > > > > figure out a way to determine the DT and that's how CONFIG_OF_EMBED or
> > > > > > CONFIG_OF_SEPARATE is doing. Can you elaborate this configuration?
> > > > > >
> > > > >
> > > > > I use CONFIG_OF_BOARD and board_fdt_blob_setup as below:
> > > > >
> > > > > void *board_fdt_blob_setup(void)
> > > > > {
> > > > > void **ptr = (void *)CONFIG_SYS_SDRAM_BASE;
> > > > > if (fdt_magic(*ptr) == FDT_MAGIC)
> > > > > return (void *)*ptr;
> > > > >
> > > > > return (void *)CONFIG_SYS_FDT_BASE;
> > > > > }
> > > > >
> > > > > 1. When booting from RAM
> > > > >     a1 can be passed by loader and reserved in CONFIG_SYS_SDRAM_BASE
> > > > > temporarily.
> > > > >
> > > > > 2. When booting from FLASH
> > > > >     a1 can NOT be passed by loader and reserved in
> > > > > CONFIG_SYS_SDRAM_BASE temporarily.
> > > > >
> > > > >     So dtb shall be get from CONFIG_SYS_FDT_BASE (flash base) which
> > > > > the dtb shall be pre-burned in this flash space..
> > > > >     Or CONFIG_SYS_FDT_BASE maybe a memory map space (NOT RAM or ROM)
> > > > > provided by HW.
> > > > >
> > > > > That is why I mean using CONFIG_OF_BOARD can support both boot from
> > > > > ram or rom with one configuration.
> > > > >
> > > >
> > > > Thanks for the info. So with the latest info, I now understand you
> > > > wanted to use CONFIG_OF_BOARD to support both configurations. That
> > > > makes sense to me, however I still wanted to point out the canonical
> > > > way to support booting from ROM is via CONFIG_OF_SEPARATE or
> > > > CONFIG_OF_EMBED. Since your board can support booting from reset
> > > > vector directly, what's the need to support the booting from RAM
> > > > configuration?
> > >
> > > I will develop u-boot via booting from ram. It will easy for debugging.
> > > After develop complete.
> > > It will be good for demo via booting from flash.
> > > With one configuration, it can decrease to make mistake with wrong
> > > configuration between 2 configuration
> > > for ram or rom individually.
> > >
> > > In that configuration, what is the first stage
> > > > bootloader?
> > >
> > > When booting from ram
> > > GDB will be the first stage to load u-boot.
> > > So it is not good for demo, because it need a pc to fire gdb.
> > >
> >
> > OK, thanks for the info. For this patch, let's go with your proposal
> > then, but please add some comments in the codes there for people to
> > understand later.
>
> Hi Bin
>
> You say go with your proposal :
> Does that mean you agree with the following modification ?
> arch/riscv/cpu/start.S
> -       li      t0, CONFIG_SYS_SDRAM_BASE
> -       SREG    a2, 0(t0)
>
> board/AndesTech/ax25-ae350/ax25-ae350.c
>  void *board_fdt_blob_setup(void)
>  {
> -       void **ptr = (void *)CONFIG_SYS_SDRAM_BASE;
> +       void **ptr = (void *)&prior_stage_fdt_address;
>
> And add some comments in this patch for people to understand it.
>

This one.

> Or
> I still can NOT borrow prior_stage_fdt_address and shall find another
> way to overcome the problem
> after remove the two line in start.S ?
>

Regards,
Bin

[U-Boot] [PATCH v5 4/4] riscv: Remove redundant a2 store on DRAM base in start.S

[Rick Chen]

Bin Meng <bmeng.cn@gmail.com> 於 2018年11月30日 週五 下午3:26寫道：
>
> Hi Rick,
>
> On Fri, Nov 30, 2018 at 3:15 PM Rick Chen <rickchen36@gmail.com> wrote:
> >
> > Bin Meng <bmeng.cn@gmail.com> 於 2018年11月30日 週五 下午2:57寫道：
> > >
> > > Hi Rick,
> > >
> > > On Fri, Nov 30, 2018 at 2:41 PM Rick Chen <rickchen36@gmail.com> wrote:
> > > >
> > > > Bin Meng <bmeng.cn@gmail.com> 於 2018年11月30日 週五 下午2:21寫道：
> > > > >
> > > > > Hi Rick,
> > > > >
> > > > > On Fri, Nov 30, 2018 at 2:05 PM Rick Chen <rickchen36@gmail.com> wrote:
> > > > > >
> > > > > > Bin Meng <bmeng.cn@gmail.com> 於 2018年11月30日 週五 上午9:48寫道：
> > > > > > >
> > > > > > > Hi Rick,
> > > > > > >
> > > > > > > On Thu, Nov 29, 2018 at 6:41 PM Rick Chen <rickchen36@gmail.com> wrote:
> > > > > > > >
> > > > > > > > Bin Meng <bmeng.cn@gmail.com> 於 2018年11月27日 週二 下午6:07寫道：
> > > > > > > > >
> > > > > > > > > Hi Rick,
> > > > > > > > >
> > > > > > > > > On Tue, Nov 27, 2018 at 4:43 PM Rick Chen <rickchen36@gmail.com> wrote:
> > > > > > > > > >
> > > > > > > > > > Anup Patel <anup@brainfault.org> 於 2018年11月27日 週二 下午3:56寫道：
> > > > > > > > > > >
> > > > > > > > > > > On Tue, Nov 27, 2018 at 12:30 PM Rick Chen <rickchen36@gmail.com> wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > Anup Patel <anup@brainfault.org> 於 2018年11月27日 週二 下午2:40寫道：
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Tue, Nov 27, 2018 at 12:00 PM Rick Chen <rickchen36@gmail.com> wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Anup Patel <anup@brainfault.org> 於 2018年11月27日 週二 下午2:14寫道：
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On Tue, 27 Nov, 2018, 11:38 AM Rick Chen <rickchen36@gmail.com wrote:
> > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > >> Anup Patel <anup@brainfault.org> 於 2018年11月27日 週二 下午1:47寫道：
> > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > >> > On Tue, Nov 27, 2018 at 11:14 AM Anup Patel <anup@brainfault.org> wrote:
> > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > >> > > On Tue, Nov 27, 2018 at 10:50 AM Rick Chen <rickchen36@gmail.com> wrote:
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > Anup Patel <anup@brainfault.org> 於 2018年11月27日 週二 上午11:28寫道：
> > > > > > > > > > > > > > >> > > > >
> > > > > > > > > > > > > > >> > > > > On Tue, Nov 27, 2018 at 8:50 AM Rick Chen <rickchen36@gmail.com> wrote:
> > > > > > > > > > > > > > >> > > > > >
> > > > > > > > > > > > > > >> > > > > > > > > > Currently, the RISC-V U-Boot is saving a2 register at
> > > > > > > > > > > > > > >> > > > > > > > > > CONFIG_SYS_DRAM_BASE in start.S which does not make sense because
> > > > > > > > > > > > > > >> > > > > > > > > > there is no information passed by previous booting stage in a2
> > > > > > > > > > > > > > >> > > > > > > > > > register.
> > > > > > > > > > > > > > >> > > > > > > > > >
> > > > > > > > > > > > > > >> > > > > > > > > > This patch removes redundant a2 store on DRAM base.
> > > > > > > > > > > > > > >> > > > > > > > > >
> > > > > > > > > > > > > > >> > > > > > > > > > Signed-off-by: Anup Patel <anup@brainfault.org>
> > > > > > > > > > > > > > >> > > > > > > > > > ---
> > > > > > > > > > > > > > >> > > > > > > > > >  arch/riscv/cpu/start.S | 2 --
> > > > > > > > > > > > > > >> > > > > > > > > >  1 file changed, 2 deletions(-)
> > > > > > > > > > > > > > >> > > > > > > > > >
> > > > > > > > > > > > > > >> > > > > > > > > > diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S index
> > > > > > > > > > > > > > >> > > > > > > > > > 704190f946..e4276e8e19 100644
> > > > > > > > > > > > > > >> > > > > > > > > > --- a/arch/riscv/cpu/start.S
> > > > > > > > > > > > > > >> > > > > > > > > > +++ b/arch/riscv/cpu/start.S
> > > > > > > > > > > > > > >> > > > > > > > > > @@ -38,8 +38,6 @@ _start:
> > > > > > > > > > > > > > >> > > > > > > > > >         mv      s0, a0
> > > > > > > > > > > > > > >> > > > > > > > > >         mv      s1, a1
> > > > > > > > > > > > > > >> > > > > > > > > >
> > > > > > > > > > > > > > >> > > > > > > > > > -       li      t0, CONFIG_SYS_SDRAM_BASE
> > > > > > > > > > > > > > >> > > > > > > > > > -       SREG    a2, 0(t0)
> > > > > > > > > > > > > > >> > > > > > > > > >         la      t0, trap_entry
> > > > > > > > > > > > > > >> > > > > > > > > >  #ifdef CONFIG_RISCV_SMODE
> > > > > > > > > > > > > > >> > > > > > > > > >         csrw    stvec, t0
> > > > > > > > > > > > > > >> > > > > > > > > > --
> > > > > > > > > > > > > > >> > > > > > > > >
> > > > > > > > > > > > > > >> > > > > > > > > This is weird. I remember these two lines were already removed by
> > > > > > > > > > > > > > >> > > > > > > > > Lukas's patch series before? Did not have time to dig out the history
> > > > > > > > > > > > > > >> > > > > > > > > though.
> > > > > > > > > > > > > > >> > > > > > > > >
> > > > > > > > > > > > > > >> > > > > >
> > > > > > > > > > > > > > >> > > > > > > > > Regards,
> > > > > > > > > > > > > > >> > > > > > > > > Bin
> > > > > > > > > > > > > > >> > > > > > > >
> > > > > > > > > > > > > > >> > > > > > > > You are correct, however I removed it again, because I did not want to break
> > > > > > > > > > > > > > >> > > > > > > > Rick's board. He did add a commit to the last pull request that removes these
> > > > > > > > > > > > > > >> > > > > > > > two lines and adjusts his board accordingly, but it is not in the current one.
> > > > > > > > > > > > > > >> > > > > > > >
> > > > > > > > > > > > > > >> > > > > >
> > > > > > > > > > > > > > >> > > > > > Hi Likas
> > > > > > > > > > > > > > >> > > > > >
> > > > > > > > > > > > > > >> > > > > > Thanks for your explanation.
> > > > > > > > > > > > > > >> > > > > >
> > > > > > > > > > > > > > >> > > > > > RIck's commit as below
> > > > > > > > > > > > > > >> > > > > > https://www.mail-archive.com/u-boot at lists.denx.de/msg305880.html
> > > > > > > > > > > > > > >> > > > >
> > > > > > > > > > > > > > >> > > > > When we run U-Boot in S-mode the BBL runs from 0x80000000 so this
> > > > > > > > > > > > > > >> > > > > two lines corrupts BBL instructions.
> > > > > > > > > > > > > > >> > > > >
> > > > > > > > > > > > > > >> > > > > If this is important for some board then please have it around #ifdef.
> > > > > > > > > > > > > > >> > > > >
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > Hi Anup
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > In the discussion as below :
> > > > > > > > > > > > > > >> > > > https://www.mail-archive.com/u-boot at lists.denx.de/msg305880.html
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > I try to solve this issue with the aptch
> > > > > > > > > > > > > > >> > > > [PATCH] riscv: ax25-ae350: Pass dtb address to u-boot with a1 register
> > > > > > > > > > > > > > >> > > > diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S
> > > > > > > > > > > > > > >> > > > -       li      t0, CONFIG_SYS_SDRAM_BASE
> > > > > > > > > > > > > > >> > > > -       SREG    a2, 0(t0)
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > diff --git a/board/AndesTech/ax25-ae350/ax25-ae350.c
> > > > > > > > > > > > > > >> > > > b/board/AndesTech/ax25-ae350/ax25-ae350.c
> > > > > > > > > > > > > > >> > > >  void *board_fdt_blob_setup(void)
> > > > > > > > > > > > > > >> > > >  {
> > > > > > > > > > > > > > >> > > > -       void **ptr = (void *)CONFIG_SYS_SDRAM_BASE;
> > > > > > > > > > > > > > >> > > > +       void **ptr = (void *)&prior_stage_fdt_address;
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > in the previous pull request.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > But Bin do not agree with that I use prior_stage_fdt_address in
> > > > > > > > > > > > > > >> > > > board_fdt_blob_setup( )
> > > > > > > > > > > > > > >> > > > I try to explain why I use it like that way.
> > > > > > > > > > > > > > >> > > > Then Bin have not any reply in the following mail.
> > > > > > > > > > > > > > >> > > > Finally I decide to drop this patch in the next pull request.
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > Hi Bin
> > > > > > > > > > > > > > >> > > >
> > > > > > > > > > > > > > >> > > > How do you think about I recovery this patch to fix this issue ?
> > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > >> > > Actually, previous booting stage can pass location of FDT stored in flash
> > > > > > > > > > > > > > >> > > to U-Boot. U-Boot requires FDT at a DRAM location which it can modify
> > > > > > > > > > > > > > >> > > in-place before passing on to Linux kernel so we should relocate the FDT
> > > > > > > > > > > > > > >> > > passed by previous booting stage to some board specific DRAM location.
> > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > >> > > My suggestion is as follows:
> > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > >> > > Instead of SDRAM_BASE, we can have new board specific config
> > > > > > > > > > > > > > >> > > CONFIG_RISCV_PRIOR_FDT_BASE
> > > > > > > > > > > > > > >> > >
> > > > > > > > > > > > > > >> > > If CONFIG_RISCV_PRIOR_FDT_BASE is defined/selected by
> > > > > > > > > > > > > > >> > > config then in start.S copy-over the FDT from location pointed by
> > > > > > > > > > > > > > >> > > "a1" register to location pointed by CONFIG_RISCV_PRIOR_FDT_BASE.
> > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > >> Hi Anup
> > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > >> It can not achieve dtb delivery at runtime.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Can you elaborate why?
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > CONFIG_RISCV_PRIOR_FDT_BASE is determined at compile time.
> > > > > > > > > > > > > > I am wondering how it can be modified at run time ?
> > > > > > > > > > > > >
> > > > > > > > > > > > > I think you miss-understood my suggestion. I did not meant changing
> > > > > > > > > > > > > CONFIG_RISCV_PRIOR_FDT_BASE at runtime.
> > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > I am sure we can always relocate FDT passed by previous stage to some safer location and use it from there.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > My original patch also can achieve that dtb passed by a1 and relocated and boot.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Great !!!
> > > > > > > > > > > > >
> > > > > > > > > > > > > Why not update your original patch to relocate FDT and use FDT from
> > > > > > > > > > > > > safer location?
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > Good question.
> > > > > > > > > > > > Above can see the question I ask for Bin :
> > > > > > > > > > > > How do you think about I recovery this patch to fix this issue ?
> > > > > > > > > > > >
> > > > > > > > > > > > Before you talking about CONFIG_RISCV_PRIOR_FDT_BASE !
> > > > > > > > > > >
> > > > > > > > > > > Can you explain why you need CONFIG_OF_BOARD ?
> > > > > > > > > > > Why can you not use CONFIG_OF_PRIOR_STAGE ?
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > You can find the discussion as below:
> > > > > > > > > > https://patchwork.ozlabs.org/patch/988884/
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > If I understand correctly, so far we have two scenarios to support:
> > > > > > > > >
> > > > > > > > > 1. U-Boot is booting directly from reset vector from ROM. This
> > > > > > > > > canonical way to support DT is via CONFIG_OF_EMBED or
> > > > > > > > > CONFIG_OF_SEPARATE. In such configuration, there is no any previous
> > > > > > > > > bootloader so the concept of CONFIG_OF_PRIOR_STAGE does not apply.
> > > > > > > > >
> > > > > > > > > 2. U-Boot is booting from previous bootloader, and DT is passed in a1
> > > > > > > > > register. Such configuration we can use CONFIG_OF_PRIOR_STAGE.
> > > > > > > > >
> > > > > > > >
> > > > > > > > I use the 3rd way, CONFIG_OF_BOARD.
> > > > > > > > It can be found in README.
> > > > > > > > And can be chosen by make menuconfig
> > > > > > > >
> > > > > > > > It is the most flexible way that I can implement my own board_fdt_blob_setup( )
> > > > > > > > which can both support boot from RAM or ROM without any configuration change.
> > > > > > > > I will indeed use CONFIG_OF_EMBED when u-boot is in debug stage.
> > > > > > > >
> > > > > > >
> > > > > > > What I don't understand is that if U-Boot is booting directly from the
> > > > > > > reset vector, there is no a1 passed by anyone. U-Boot itself should
> > > > > > > figure out a way to determine the DT and that's how CONFIG_OF_EMBED or
> > > > > > > CONFIG_OF_SEPARATE is doing. Can you elaborate this configuration?
> > > > > > >
> > > > > >
> > > > > > I use CONFIG_OF_BOARD and board_fdt_blob_setup as below:
> > > > > >
> > > > > > void *board_fdt_blob_setup(void)
> > > > > > {
> > > > > > void **ptr = (void *)CONFIG_SYS_SDRAM_BASE;
> > > > > > if (fdt_magic(*ptr) == FDT_MAGIC)
> > > > > > return (void *)*ptr;
> > > > > >
> > > > > > return (void *)CONFIG_SYS_FDT_BASE;
> > > > > > }
> > > > > >
> > > > > > 1. When booting from RAM
> > > > > >     a1 can be passed by loader and reserved in CONFIG_SYS_SDRAM_BASE
> > > > > > temporarily.
> > > > > >
> > > > > > 2. When booting from FLASH
> > > > > >     a1 can NOT be passed by loader and reserved in
> > > > > > CONFIG_SYS_SDRAM_BASE temporarily.
> > > > > >
> > > > > >     So dtb shall be get from CONFIG_SYS_FDT_BASE (flash base) which
> > > > > > the dtb shall be pre-burned in this flash space..
> > > > > >     Or CONFIG_SYS_FDT_BASE maybe a memory map space (NOT RAM or ROM)
> > > > > > provided by HW.
> > > > > >
> > > > > > That is why I mean using CONFIG_OF_BOARD can support both boot from
> > > > > > ram or rom with one configuration.
> > > > > >
> > > > >
> > > > > Thanks for the info. So with the latest info, I now understand you
> > > > > wanted to use CONFIG_OF_BOARD to support both configurations. That
> > > > > makes sense to me, however I still wanted to point out the canonical
> > > > > way to support booting from ROM is via CONFIG_OF_SEPARATE or
> > > > > CONFIG_OF_EMBED. Since your board can support booting from reset
> > > > > vector directly, what's the need to support the booting from RAM
> > > > > configuration?
> > > >
> > > > I will develop u-boot via booting from ram. It will easy for debugging.
> > > > After develop complete.
> > > > It will be good for demo via booting from flash.
> > > > With one configuration, it can decrease to make mistake with wrong
> > > > configuration between 2 configuration
> > > > for ram or rom individually.
> > > >
> > > > In that configuration, what is the first stage
> > > > > bootloader?
> > > >
> > > > When booting from ram
> > > > GDB will be the first stage to load u-boot.
> > > > So it is not good for demo, because it need a pc to fire gdb.
> > > >
> > >
> > > OK, thanks for the info. For this patch, let's go with your proposal
> > > then, but please add some comments in the codes there for people to
> > > understand later.
> >
> > Hi Bin
> >
> > You say go with your proposal :
> > Does that mean you agree with the following modification ?
> > arch/riscv/cpu/start.S
> > -       li      t0, CONFIG_SYS_SDRAM_BASE
> > -       SREG    a2, 0(t0)
> >
> > board/AndesTech/ax25-ae350/ax25-ae350.c
> >  void *board_fdt_blob_setup(void)
> >  {
> > -       void **ptr = (void *)CONFIG_SYS_SDRAM_BASE;
> > +       void **ptr = (void *)&prior_stage_fdt_address;
> >
> > And add some comments in this patch for people to understand it.
> >
>
> This one.

Hi Bin

Thanks for your opinion. :)

Rick

>
> > Or
> > I still can NOT borrow prior_stage_fdt_address and shall find another
> > way to overcome the problem
> > after remove the two line in start.S ?
> >
>
> Regards,
> Bin

[U-Boot] [PATCH v5 4/4] riscv: Remove redundant a2 store on DRAM base in start.S

[Rick Chen]

> > > > > When we run U-Boot in S-mode the BBL runs from 0x80000000 so this
> > > > > two lines corrupts BBL instructions.

Hi Anup

You said
Your patchset based upon git://git.denx.de/u-boot-riscv.git

Why you announce this problem in [PATCH v5 4/4] riscv: Remove
redundant a2 store on DRAM base in start.S
Why you do not find this proble in v1, v2, v3, v4 ?

Rick

> > > > >
> > > > > If this is important for some board then please have it around #ifdef.
> > > > >
> > > >
> > > > Hi Anup
> > > >
> > > > In the discussion as below :
> > > > https://www.mail-archive.com/u-boot at lists.denx.de/msg305880.html
> > > >
> > > > I try to solve this issue with the aptch
> > > > [PATCH] riscv: ax25-ae350: Pass dtb address to u-boot with a1 register
> > > > diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S
> > > > -       li      t0, CONFIG_SYS_SDRAM_BASE
> > > > -       SREG    a2, 0(t0)
> > > >
> > > > diff --git a/board/AndesTech/ax25-ae350/ax25-ae350.c
> > > > b/board/AndesTech/ax25-ae350/ax25-ae350.c
> > > >  void *board_fdt_blob_setup(void)
> > > >  {
> > > > -       void **ptr = (void *)CONFIG_SYS_SDRAM_BASE;
> > > > +       void **ptr = (void *)&prior_stage_fdt_address;
> > > >
> > > > in the previous pull request.
> > > >
> > > > But Bin do not agree with that I use prior_stage_fdt_address in
> > > > board_fdt_blob_setup( )
> > > > I try to explain why I use it like that way.
> > > > Then Bin have not any reply in the following mail.
> > > > Finally I decide to drop this patch in the next pull request.
> > > >
> > > > Hi Bin
> > > >
> > > > How do you think about I recovery this patch to fix this issue ?
> > >
> > > Actually, previous booting stage can pass location of FDT stored in flash
> > > to U-Boot. U-Boot requires FDT at a DRAM location which it can modify
> > > in-place before passing on to Linux kernel so we should relocate the FDT
> > > passed by previous booting stage to some board specific DRAM location.
> > >
> > > My suggestion is as follows:
> > >
> > > Instead of SDRAM_BASE, we can have new board specific config
> > > CONFIG_RISCV_PRIOR_FDT_BASE
> > >
> > > If CONFIG_RISCV_PRIOR_FDT_BASE is defined/selected by
> > > config then in start.S copy-over the FDT from location pointed by
> > > "a1" register to location pointed by CONFIG_RISCV_PRIOR_FDT_BASE.
> >
>
> Hi Anup
>
> It can not achieve dtb delivery at runtime.
>
> Rick
>
> > I think you can copy-over FDT in C code too. You don't need to do
> > in start.S.
> >
> > >
> > > In your board_fdt_blob_setup(), you can safely do:
> > > void **ptr = (void *)CONFIG_RISCV_PRIOR_FDT_BASE;
> > >
> > > Regards,
> > > Anup

[U-Boot] [PATCH v5 4/4] riscv: Remove redundant a2 store on DRAM base in start.S

[Anup Patel]

On Tue, Nov 27, 2018 at 12:14 PM Rick Chen <rickchen36@gmail.com> wrote:
>
> > > > > > When we run U-Boot in S-mode the BBL runs from 0x80000000 so this
> > > > > > two lines corrupts BBL instructions.
>
> Hi Anup
>
> You said
> Your patchset based upon git://git.denx.de/u-boot-riscv.git
>
> Why you announce this problem in [PATCH v5 4/4] riscv: Remove
> redundant a2 store on DRAM base in start.S
> Why you do not find this proble in v1, v2, v3, v4 ?

I had this change locally. I thought some would definitely remove this
lines but did not see that happening so I send patch to remove these
lines myself.

Regards,
Anup

[U-Boot] [PATCH v5 4/4] riscv: Remove redundant a2 store on DRAM base in start.S

[Bin Meng]

Hi Rick,

On Tue, Nov 27, 2018 at 1:20 PM Rick Chen <rickchen36@gmail.com> wrote:
>
> Anup Patel <anup@brainfault.org> 於 2018年11月27日 週二 上午11:28寫道：
> >
> > On Tue, Nov 27, 2018 at 8:50 AM Rick Chen <rickchen36@gmail.com> wrote:
> > >
> > > > > > > Currently, the RISC-V U-Boot is saving a2 register at
> > > > > > > CONFIG_SYS_DRAM_BASE in start.S which does not make sense because
> > > > > > > there is no information passed by previous booting stage in a2
> > > > > > > register.
> > > > > > >
> > > > > > > This patch removes redundant a2 store on DRAM base.
> > > > > > >
> > > > > > > Signed-off-by: Anup Patel <anup@brainfault.org>
> > > > > > > ---
> > > > > > >  arch/riscv/cpu/start.S | 2 --
> > > > > > >  1 file changed, 2 deletions(-)
> > > > > > >
> > > > > > > diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S index
> > > > > > > 704190f946..e4276e8e19 100644
> > > > > > > --- a/arch/riscv/cpu/start.S
> > > > > > > +++ b/arch/riscv/cpu/start.S
> > > > > > > @@ -38,8 +38,6 @@ _start:
> > > > > > >         mv      s0, a0
> > > > > > >         mv      s1, a1
> > > > > > >
> > > > > > > -       li      t0, CONFIG_SYS_SDRAM_BASE
> > > > > > > -       SREG    a2, 0(t0)
> > > > > > >         la      t0, trap_entry
> > > > > > >  #ifdef CONFIG_RISCV_SMODE
> > > > > > >         csrw    stvec, t0
> > > > > > > --
> > > > > >
> > > > > > This is weird. I remember these two lines were already removed by
> > > > > > Lukas's patch series before? Did not have time to dig out the history
> > > > > > though.
> > > > > >
> > >
> > > > > > Regards,
> > > > > > Bin
> > > > >
> > > > > You are correct, however I removed it again, because I did not want to break
> > > > > Rick's board. He did add a commit to the last pull request that removes these
> > > > > two lines and adjusts his board accordingly, but it is not in the current one.
> > > > >
> > >
> > > Hi Likas
> > >
> > > Thanks for your explanation.
> > >
> > > RIck's commit as below
> > > https://www.mail-archive.com/u-boot at lists.denx.de/msg305880.html
> >
> > When we run U-Boot in S-mode the BBL runs from 0x80000000 so this
> > two lines corrupts BBL instructions.
> >
> > If this is important for some board then please have it around #ifdef.
> >
>
> Hi Anup
>
> In the discussion as below :
> https://www.mail-archive.com/u-boot at lists.denx.de/msg305880.html
>
> I try to solve this issue with the aptch
> [PATCH] riscv: ax25-ae350: Pass dtb address to u-boot with a1 register
> diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S
> -       li      t0, CONFIG_SYS_SDRAM_BASE
> -       SREG    a2, 0(t0)
>
> diff --git a/board/AndesTech/ax25-ae350/ax25-ae350.c
> b/board/AndesTech/ax25-ae350/ax25-ae350.c
>  void *board_fdt_blob_setup(void)
>  {
> -       void **ptr = (void *)CONFIG_SYS_SDRAM_BASE;
> +       void **ptr = (void *)&prior_stage_fdt_address;
>
> in the previous pull request.
>
> But Bin do not agree with that I use prior_stage_fdt_address in
> board_fdt_blob_setup( )
> I try to explain why I use it like that way.
> Then Bin have not any reply in the following mail.
> Finally I decide to drop this patch in the next pull request.
>
> Hi Bin
>
> How do you think about I recovery this patch to fix this issue ?
>

Do you mean removing the two lines in start.S? Yes, let's do this.
However for the ax25-ae350 board, in order to support booting from
NOR, we should introduce CONFIG_OF_EMBED or CONFIG_OF_SEPARATE, and
leave prior_stage_fdt_address support only for cases which U-Boot is
loaded by previous stage bootloaders.

Regards,
Bin

[U-Boot] [PATCH v5 4/4] riscv: Remove redundant a2 store on DRAM base in start.S

[Bin Meng]

On Tue, Nov 27, 2018 at 11:28 AM Anup Patel <anup@brainfault.org> wrote:
>
> On Tue, Nov 27, 2018 at 8:50 AM Rick Chen <rickchen36@gmail.com> wrote:
> >
> > > > > > Currently, the RISC-V U-Boot is saving a2 register at
> > > > > > CONFIG_SYS_DRAM_BASE in start.S which does not make sense because
> > > > > > there is no information passed by previous booting stage in a2
> > > > > > register.
> > > > > >
> > > > > > This patch removes redundant a2 store on DRAM base.
> > > > > >
> > > > > > Signed-off-by: Anup Patel <anup@brainfault.org>
> > > > > > ---
> > > > > >  arch/riscv/cpu/start.S | 2 --
> > > > > >  1 file changed, 2 deletions(-)
> > > > > >
> > > > > > diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S index
> > > > > > 704190f946..e4276e8e19 100644
> > > > > > --- a/arch/riscv/cpu/start.S
> > > > > > +++ b/arch/riscv/cpu/start.S
> > > > > > @@ -38,8 +38,6 @@ _start:
> > > > > >         mv      s0, a0
> > > > > >         mv      s1, a1
> > > > > >
> > > > > > -       li      t0, CONFIG_SYS_SDRAM_BASE
> > > > > > -       SREG    a2, 0(t0)
> > > > > >         la      t0, trap_entry
> > > > > >  #ifdef CONFIG_RISCV_SMODE
> > > > > >         csrw    stvec, t0
> > > > > > --
> > > > >
> > > > > This is weird. I remember these two lines were already removed by
> > > > > Lukas's patch series before? Did not have time to dig out the history
> > > > > though.
> > > > >
> >
> > > > > Regards,
> > > > > Bin
> > > >
> > > > You are correct, however I removed it again, because I did not want to break
> > > > Rick's board. He did add a commit to the last pull request that removes these
> > > > two lines and adjusts his board accordingly, but it is not in the current one.
> > > >
> >
> > Hi Likas
> >
> > Thanks for your explanation.
> >
> > RIck's commit as below
> > https://www.mail-archive.com/u-boot at lists.denx.de/msg305880.html
>
> When we run U-Boot in S-mode the BBL runs from 0x80000000 so this
> two lines corrupts BBL instructions.
>
> If this is important for some board then please have it around #ifdef.
>

Please don't do any #ifdef here. That codes should be removed, and we
should figure out a way that does not break the ax25-ae350 board.

> My apologies for the noise.

Regards,
Bin

[U-Boot] [PATCH v5 0/4] RISC-V S-mode support

[Anup Patel]

On Mon, Nov 26, 2018 at 4:13 PM Anup Patel <anup@brainfault.org> wrote:
>
> This patchset allows us runing u-boot in S-mode which is
> useful on platforms where M-mode runtime firmware is an
> independent firmware and u-boot is used as last stage OS
> bootloader.
>
> The patchset based upon git://git.denx.de/u-boot-riscv.git
> and is tested on QEMU in both M-mode and S-mode.
>
> For S-mode testing, we have used u-boot.bin as payload of
> latest BBL (at commit 6ebd0f2a46255d0c76dad3c05b16c1d154795d26)
> applied with following changes:
>
> diff --git a/machine/emulation.c b/machine/emulation.c
> index 132e977..def75e1 100644
> --- a/machine/emulation.c
> +++ b/machine/emulation.c
> @@ -162,6 +162,12 @@ static inline int emulate_read_csr(int num, uintptr_t mstatus, uintptr_t* result
>
>    switch (num)
>    {
> +    case CSR_MISA:
> +      *result = read_csr(misa);
> +      return 0;
> +    case CSR_MHARTID:
> +      *result = read_csr(mhartid);
> +      return 0;
>      case CSR_CYCLE:
>        if (!((counteren >> (CSR_CYCLE - CSR_CYCLE)) & 1))
>          return -1;
>
> Changes since v4:
>  - Rebased series based on commit 52923c6db7f00e0197ec894c8c1bb8a7681974bb
>    of git://git.denx.de/u-boot-riscv.git
>  - Added a patch to remove redundant a2 store on DRAM base. This
>    store was creating problem booting U-Boot in S-mode using BBL.
>
> Changes since v3:
>  - Replaced 'u-boot' with 'U-Boot' in commit message
>  - Dropped 'an' in RISCV_SMODE kconfig option help message
>  - Added appropriate #ifdef in arch/riscv/lib/interrupts.c
>
> Changes since v2:
>  - Dropped 'default n" from RISCV_SMODE kconfig option
>  - Replaced '-smode_' in defconfig names with '_smode_'
>
> Changes since v1:
>  - Rebased upon latest git://git.denx.de/u-boot-riscv.git
>  - Add details in cover letter for running u-boot in S-mode
>    using BBL
>
> Anup Patel (4):
>   riscv: Add kconfig option to run U-Boot in S-mode
>   riscv: qemu: Use different SYS_TEXT_BASE for S-mode
>   riscv: Add S-mode defconfigs for QEMU virt machine
>   riscv: Remove redundant a2 store on DRAM base in start.S
>
>  arch/riscv/Kconfig                     |  5 ++++
>  arch/riscv/cpu/start.S                 | 35 +++++++++++++++++++++++--
>  arch/riscv/include/asm/encoding.h      |  2 ++
>  arch/riscv/lib/interrupts.c            | 36 +++++++++++++++++++-------
>  board/emulation/qemu-riscv/Kconfig     |  3 ++-
>  board/emulation/qemu-riscv/MAINTAINERS |  2 ++
>  configs/qemu-riscv32_smode_defconfig   | 10 +++++++
>  configs/qemu-riscv64_smode_defconfig   | 11 ++++++++
>  8 files changed, 92 insertions(+), 12 deletions(-)
>  create mode 100644 configs/qemu-riscv32_smode_defconfig
>  create mode 100644 configs/qemu-riscv64_smode_defconfig
>
> --
> 2.17.1
>

Hi Rick,

If its fine with you then please take PATCH 1-to-3

The PATCH 4 "riscv: Remove redundant a2 store on DRAM base in start.S"
you can drop and merge a better solution at your end.

Regards,
Anup