mbox series

[U-Boot,0/4] AE350 support SMP boot from flash

Message ID 20190423054230.10543-1-uboot@andestech.com
Headers show
Series AE350 support SMP boot from flash | expand

Message

Andes April 23, 2019, 5:42 a.m. UTC 
From: Rick Chen <rick@andestech.com>

In current RISC-V SMP flow, AE350 will encounter the the write
failure problem since hart_lottery and available_harts_lock was
not in ram address but in flash address when booing from flash.

This patch can help to fix the failure problem when AE350 was
booting from flash by disable this two features.

Rick Chen (4):
  riscv: hart_lottery and available harts feature can be seletable
  riscv: configs: Support AE350 SMP boot from flash flow
  riscv: prior_stage_fdt_address only be used when OF_PRIOR_STAGE is
    enable
  riscv: configs: AE350 will use OF_PRIOR_STAGE when boot from ram

 arch/riscv/Kconfig                   | 21 ++++++++++++++++++++
 arch/riscv/cpu/cpu.c                 |  4 ++++
 arch/riscv/cpu/start.S               | 11 ++++++++++-
 arch/riscv/include/asm/global_data.h |  2 ++
 arch/riscv/lib/asm-offsets.c         |  2 ++
 arch/riscv/lib/smp.c                 |  2 ++
 configs/ae350_rv32_defconfig         |  2 +-
 configs/ae350_rv32_xip_defconfig     | 37 +++++++++++++++++++++++++++++++++++
 configs/ae350_rv64_defconfig         |  2 +-
 configs/ae350_rv64_xip_defconfig     | 38 ++++++++++++++++++++++++++++++++++++
 10 files changed, 118 insertions(+), 3 deletions(-)
 create mode 100644 configs/ae350_rv32_xip_defconfig
 create mode 100644 configs/ae350_rv64_xip_defconfig

Comments

Lukas Auer April 23, 2019, 7:58 p.m. UTC | #1 
Hi Rick,

On Tue, 2019-04-23 at 13:42 +0800, Andes wrote:
> From: Rick Chen <rick@andestech.com>
> 
> In current RISC-V SMP flow, AE350 will encounter the the write
> failure problem since hart_lottery and available_harts_lock was
> not in ram address but in flash address when booing from flash.
> 
> This patch can help to fix the failure problem when AE350 was
> booting from flash by disable this two features.
> 

Can you describe the issue you are seeing a bit more. The write
failures are both to variables in the .data section, which should be
writable. Perhaps the write failures can be avoided by moving the .data
section or just the variable to RAM?

Thanks,
Lukas
Rick Chen April 24, 2019, 1:35 a.m. UTC | #2 
Hi Lukas

Auer, Lukas <lukas.auer@aisec.fraunhofer.de> 於 2019年4月24日 週三 上午3:58寫道：
>
> Hi Rick,
>
> On Tue, 2019-04-23 at 13:42 +0800, Andes wrote:
> > From: Rick Chen <rick@andestech.com>
> >
> > In current RISC-V SMP flow, AE350 will encounter the the write
> > failure problem since hart_lottery and available_harts_lock was
> > not in ram address but in flash address when booing from flash.
> >
> > This patch can help to fix the failure problem when AE350 was
> > booting from flash by disable this two features.
> >
>
> Can you describe the issue you are seeing a bit more. The write
> failures are both to variables in the .data section, which should be
> writable. Perhaps the write failures can be avoided by moving the .data
> section or just the variable to RAM?
>

When I compile AE350's CONFIG_SYS_TEXT_BASE=0x80000000 which is spi flash base.
And burn u-boot.bin into AE350 spi flash. Power off / on, U-Boot will
run in XIP mode.
At this time prior_stage_fdt_address will be in flash address(0x8004e9e8)
So it is not writable.

80000042:       16021563                bnez    tp,800001ac
<secondary_hart_loop>
80000046:       0004f297                auipc   t0,0x4f
8000004a:       9a22a283                lw      t0,-1630(t0) #
8004e9e8 <prior_stage_fdt_address+0x3f74>
8000004e:       0092a023                sw      s1,0(t0)

Rick

> Thanks,
> Lukas
Lukas Auer April 24, 2019, 9:18 p.m. UTC | #3 
Hi Rick,

On Wed, 2019-04-24 at 09:35 +0800, Rick Chen wrote:
> Hi Lukas
> 
> Auer, Lukas <lukas.auer@aisec.fraunhofer.de> 於 2019年4月24日 週三 上午3:58寫道：
> > Hi Rick,
> > 
> > On Tue, 2019-04-23 at 13:42 +0800, Andes wrote:
> > > From: Rick Chen <rick@andestech.com>
> > > 
> > > In current RISC-V SMP flow, AE350 will encounter the the write
> > > failure problem since hart_lottery and available_harts_lock was
> > > not in ram address but in flash address when booing from flash.
> > > 
> > > This patch can help to fix the failure problem when AE350 was
> > > booting from flash by disable this two features.
> > > 
> > 
> > Can you describe the issue you are seeing a bit more. The write
> > failures are both to variables in the .data section, which should be
> > writable. Perhaps the write failures can be avoided by moving the .data
> > section or just the variable to RAM?
> > 
> 
> When I compile AE350's CONFIG_SYS_TEXT_BASE=0x80000000 which is spi flash base.
> And burn u-boot.bin into AE350 spi flash. Power off / on, U-Boot will
> run in XIP mode.
> At this time prior_stage_fdt_address will be in flash address(0x8004e9e8)
> So it is not writable.
> 
> 80000042:       16021563                bnez    tp,800001ac
> <secondary_hart_loop>
> 80000046:       0004f297                auipc   t0,0x4f
> 8000004a:       9a22a283                lw      t0,-1630(t0) #
> 8004e9e8 <prior_stage_fdt_address+0x3f74>
> 8000004e:       0092a023                sw      s1,0(t0)
> 

Ok, that makes sense.
Another option would be to move the variable to RAM or some other
location, which is write-accessible when U-Boot starts. Would this
work?
I think it would be good to support the hart lottery and the available
harts mask in all configurations.

Thanks,
Lukas
Rick Chen April 25, 2019, 12:55 a.m. UTC | #4 
Hi Lukas

Auer, Lukas <lukas.auer@aisec.fraunhofer.de> 於 2019年4月25日 週四 上午5:18寫道：
>
> Hi Rick,
>
> On Wed, 2019-04-24 at 09:35 +0800, Rick Chen wrote:
> > Hi Lukas
> >
> > Auer, Lukas <lukas.auer@aisec.fraunhofer.de> 於 2019年4月24日 週三 上午3:58寫道：
> > > Hi Rick,
> > >
> > > On Tue, 2019-04-23 at 13:42 +0800, Andes wrote:
> > > > From: Rick Chen <rick@andestech.com>
> > > >
> > > > In current RISC-V SMP flow, AE350 will encounter the the write
> > > > failure problem since hart_lottery and available_harts_lock was
> > > > not in ram address but in flash address when booing from flash.
> > > >
> > > > This patch can help to fix the failure problem when AE350 was
> > > > booting from flash by disable this two features.
> > > >
> > >
> > > Can you describe the issue you are seeing a bit more. The write
> > > failures are both to variables in the .data section, which should be
> > > writable. Perhaps the write failures can be avoided by moving the .data
> > > section or just the variable to RAM?
> > >
> >
> > When I compile AE350's CONFIG_SYS_TEXT_BASE=0x80000000 which is spi flash base.
> > And burn u-boot.bin into AE350 spi flash. Power off / on, U-Boot will
> > run in XIP mode.
> > At this time prior_stage_fdt_address will be in flash address(0x8004e9e8)
> > So it is not writable.
> >
> > 80000042:       16021563                bnez    tp,800001ac
> > <secondary_hart_loop>
> > 80000046:       0004f297                auipc   t0,0x4f
> > 8000004a:       9a22a283                lw      t0,-1630(t0) #
> > 8004e9e8 <prior_stage_fdt_address+0x3f74>
> > 8000004e:       0092a023                sw      s1,0(t0)
> >
>
> Ok, that makes sense.
> Another option would be to move the variable to RAM or some other
> location, which is write-accessible when U-Boot starts. Would this
> work?
> I think it would be good to support the hart lottery and the available
> harts mask in all configurations.
>

Actually I have tried to move them to gd, but it fail.
Because it need some requirements :
hart_lottery need equal to 0 and available_harts_lock equal to 1 at
compile time.
It is hard to achieve this at run time.
That is why I add a CONFIG_XXX to remove this two features simply.

Thanks
Rick

> Thanks,
> Lukas
Lukas Auer April 25, 2019, 8:53 p.m. UTC | #5 
Hi Rick,

On Thu, 2019-04-25 at 08:55 +0800, Rick Chen wrote:
> Hi Lukas
> 
> Auer, Lukas <lukas.auer@aisec.fraunhofer.de> 於 2019年4月25日 週四 上午5:18寫道：
> > Hi Rick,
> > 
> > On Wed, 2019-04-24 at 09:35 +0800, Rick Chen wrote:
> > > Hi Lukas
> > > 
> > > Auer, Lukas <lukas.auer@aisec.fraunhofer.de> 於 2019年4月24日 週三 上午3:58寫道：
> > > > Hi Rick,
> > > > 
> > > > On Tue, 2019-04-23 at 13:42 +0800, Andes wrote:
> > > > > From: Rick Chen <rick@andestech.com>
> > > > > 
> > > > > In current RISC-V SMP flow, AE350 will encounter the the write
> > > > > failure problem since hart_lottery and available_harts_lock was
> > > > > not in ram address but in flash address when booing from flash.
> > > > > 
> > > > > This patch can help to fix the failure problem when AE350 was
> > > > > booting from flash by disable this two features.
> > > > > 
> > > > 
> > > > Can you describe the issue you are seeing a bit more. The write
> > > > failures are both to variables in the .data section, which should be
> > > > writable. Perhaps the write failures can be avoided by moving the .data
> > > > section or just the variable to RAM?
> > > > 
> > > 
> > > When I compile AE350's CONFIG_SYS_TEXT_BASE=0x80000000 which is spi flash base.
> > > And burn u-boot.bin into AE350 spi flash. Power off / on, U-Boot will
> > > run in XIP mode.
> > > At this time prior_stage_fdt_address will be in flash address(0x8004e9e8)
> > > So it is not writable.
> > > 
> > > 80000042:       16021563                bnez    tp,800001ac
> > > <secondary_hart_loop>
> > > 80000046:       0004f297                auipc   t0,0x4f
> > > 8000004a:       9a22a283                lw      t0,-1630(t0) #
> > > 8004e9e8 <prior_stage_fdt_address+0x3f74>
> > > 8000004e:       0092a023                sw      s1,0(t0)
> > > 
> > 
> > Ok, that makes sense.
> > Another option would be to move the variable to RAM or some other
> > location, which is write-accessible when U-Boot starts. Would this
> > work?
> > I think it would be good to support the hart lottery and the available
> > harts mask in all configurations.
> > 
> 
> Actually I have tried to move them to gd, but it fail.
> Because it need some requirements :
> hart_lottery need equal to 0 and available_harts_lock equal to 1 at
> compile time.
> It is hard to achieve this at run time.
> That is why I add a CONFIG_XXX to remove this two features simply.
> 

Ah, you are right. I did not consider that.

Thanks,
Lukas