On Tue, Nov 27, 2018 at 12:00 PM Rick Chen <rickche...@gmail.com> wrote:
>
> Anup Patel <a...@brainfault.org> 於 2018年11月27日 週二 下午2:14寫道:
> >
> >
> >
> > On Tue, 27 Nov, 2018, 11:38 AM Rick Chen <rickche...@gmail.com wrote:
> >>
> >> Anup Patel <a...@brainfault.org> 於 2018年11月27日 週二 下午1:47寫道:
> >> >
> >> > On Tue, Nov 27, 2018 at 11:14 AM Anup Patel <a...@brainfault.org> wrote:
> >> > >
> >> > > On Tue, Nov 27, 2018 at 10:50 AM Rick Chen <rickche...@gmail.com> 
> >> > > wrote:
> >> > > >
> >> > > > Anup Patel <a...@brainfault.org> 於 2018年11月27日 週二 上午11:28寫道:
> >> > > > >
> >> > > > > On Tue, Nov 27, 2018 at 8:50 AM Rick Chen <rickche...@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 <a...@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@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@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 mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Reply via email to