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
