Hi Bin > > Hi Rick, > > On Wed, Oct 30, 2019 at 10:50 AM Rick Chen <rickche...@gmail.com> wrote: > > > > Hi Bin > > > > > > > > Hi Rick, > > > > > > On Fri, Oct 25, 2019 at 2:18 PM Andes <ub...@andestech.com> wrote: > > > > > > > > From: Rick Chen <r...@andestech.com> > > > > > > > > It will work fine due to hart 0 always will be main > > > > hart coincidentally. When develop SPL flow, I try to > > > > force other harts to be main hart. And it will go > > > > wrong in sending IPI flow. So fix it. > > > > > > Fix what? Does this commit contain 2 fixes, or just 1 fix? > > > > Yes, it include two fixs. But they will cause one negative result > > that only hart 0 can send ipi to other harts. > > > > > > > > > > > > > Having this fix, any hart can be main hart in U-Boot SPL > > > > theoretically, but it still fail somewhere. After dig in > > > > and found there is an assumption that hart 0 shall be > > > > main hart in OpenSbi. > > > > > > So does this mean there is a bug in OpenSBI too? > > > > I am not sure if it is a bug. Maybe it is a compatible issue. > > There is a limitation that only hart 0 can be main hart in OpenSBI. > > I don't think OpenSBI has such limitation.
OK. But there is a hint in OpenSBI indeed. Maybe it is just different interpretation each other. /* * Jump to warm-boot if this is not the first core booting, * that is, for mhartid != 0 */ > > > But any hart can be main hart in U-Boot. > > > > In general case, hart 0 will be main and it is fine when U-Boot jump ot > > OpenSBI. > > But if we force hart 1 to be main hart, when hart 0 jump to OPenSBI from > > U-Boot, > > It will do relocation flow in OpenSBI which willcorrupt U-Boot SPL, > > but hart 0 still in U-Boot SPL. > > > > > > > > > > > > > After some work-arounds, it can pass the verifications > > > > that any hart can be main hart and boots U-Boot SPL -> > > > > OpenSbi -> U-Boot proper -> Linux Kernel successfully. > > > > > > > > > > It's a bit hard for me to understand what was described here in the > > > commit message. Maybe you need rewrite something. > > > > OK. I will rewrite this commit message. > > > > > > > > > Signed-off-by: Rick Chen <r...@andestech.com> > > > > Cc: KC Lin <kc...@andestech.com> > > > > Cc: Alan Kao <alan...@andestech.com> > > > > --- > > > > arch/riscv/lib/andes_plic.c | 11 +++++++---- > > > > 1 file changed, 7 insertions(+), 4 deletions(-) > > > > > > > > diff --git a/arch/riscv/lib/andes_plic.c b/arch/riscv/lib/andes_plic.c > > > > index 28568e4..42394b9 100644 > > > > --- a/arch/riscv/lib/andes_plic.c > > > > +++ b/arch/riscv/lib/andes_plic.c > > > > @@ -19,7 +19,7 @@ > > > > #include <cpu.h> > > > > > > > > /* pending register */ > > > > -#define PENDING_REG(base, hart) ((ulong)(base) + 0x1000 + > > > > (hart) * 8) > > > > +#define PENDING_REG(base, hart) ((ulong)(base) + 0x1000 + > > > > ((hart) / 4) * 4) > > > > /* enable register */ > > > > #define ENABLE_REG(base, hart) ((ulong)(base) + 0x2000 + (hart) * 0x80) > > > > /* claim register */ > > > > @@ -46,7 +46,7 @@ static int init_plic(void); > > > > > > > > static int enable_ipi(int hart) > > > > { > > > > - int en; > > > > + unsigned int en; > > > > > > Is this for some compiler warning fix? > > > > No, it is not a warning fix. It is a bug fix. > > I hope en can be 0x0000000080808080 instead of 0xffffffff80808080, > > But it is int, which is only 32-bit. The example you gave was a 64-bit number. The verification runs on RV64, so it is a 64-bit number example. Thanks Rick > > > or it will cause IPI sending errors. > > > > Regards, > Bin _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot