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

[Auer, Lukas]

Hi Rick,

On Thu, 2019-04-25 at 08:55 +0800, Rick Chen wrote:
> Hi Lukas
> 
> Auer, Lukas <lukas.auer at 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 at 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 at 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