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.
> 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.
> 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
