[PATCH v2 02/11] RISC-V: make RISCV_SBI and RISCV_M_MODE explicitly mutually exclusive

[Ahmad Fatoum]

Hi,

On 07.05.21 19:52, Antony Pavlov wrote:
> On Fri, 7 May 2021 16:44:24 +0200
> Ahmad Fatoum <a.fatoum at pengutronix.de> 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.

Cheers,
Ahmad

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |