On Fri, 7 May 2021 20:08:48 +0200
Ahmad Fatoum <a.fatoum@xxxxxxxxxxxxxx> wrote:
Hi Ahmad!
> On 07.05.21 19:52, Antony Pavlov wrote:
> > On Fri, 7 May 2021 16:44:24 +0200
> > Ahmad Fatoum <a.fatoum@xxxxxxxxxxxxxx> wrote:
> >
> > Hi Ahmad !
> >
> >> Hello Antony,
> >>
> >> On 07.05.21 16:25, Antony Pavlov wrote:
> >>>> I would really like to have a riscv{32,64}_defconfig that can just build all boards
> >>>> at once. Do you know if this could be dynamically determined?
> >>>
> >>> At the moment I have not answer.
> >>> I'll try to investigate dynamic mode determination, it's very attractive idea.
> >>>
> >>> On the other hand compile time mode selection is not the show stopper for
> >>> "one defconfig to build them all": we have to make STACK_SIZE and MALLOC_SIZE
> >>> per-board parameters not per-defconfig parameters like now.
> >>>
> >>> If we could make STACK_SIZE and MALLOC_SIZE per-board compile-time parameters then
> >>> we can make RISC-V mode per-board compile-time parameter too. Is this solution
> >>> acceptable?
> >>
> >> MALLOC_SIZE can be set as 0 and barebox will determine it based on
> >> membase + memsize that are set by PBL.
> >>
> >> STACK_SIZE must be set per Kconfig, but I think even a generous default stack
> >> size should accommodate all targets.
> >>
> >> If we do the same for RISC-V mode that would probably mean having
> >> two functions barebox_riscv_machine_entry() and barebox_riscv_supervisor_entry()
> >> in PBL that take care to pass the correct info to barebox proper.
> >>
> >> Apparently, you can determine mode if you catch exceptions:
> >> https://forums.sifive.com/t/how-to-determine-the-current-execution-privilege-mode/2823
> >
> > Hmm, answer is mostly negative:
> >
> > <<
> > RISC-V deliberately doesn’t make it easy for code to discover
> > what mode it is running it because this is a virtualisation hole.
> > As a general principle, code should be designed for and implicitly
> > know what mode it will run in.
> >>>
> >
> >> We don't yet install exception handlers in barebox, but I am fine with using
> >> different PBL common code entry functions.
> >>
> >> What do you think?
> >
> > I think that adding exception handling to barebox would be very handy.
> > At the moment barebox sometimes hangs during my experiments without any error message.
> > Even with a simple exception handler that just prints out epc, status and cause registers
> > I have much more information on hang reason.
>
> Exception handling would be useful, no doubt. Rouven is looking
> into adding that.
>
> I was asking about what you think about adding barebox_riscv_machine_entry()
> and barebox_riscv_supervisor_entry(), so PBL entry points can decide for
> themselves what mode the rest of barebox should get when riscv_mode() is
> called. I'll CC you on the series.
Can we just add one more 'int mode' argument to barebox_riscv_entry()?
--
Best regards,
Antony Pavlov
_______________________________________________
barebox mailing list
barebox@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/barebox
