boot hartid information passing to UPL

[Dhaval Sharma]

Hi folks, 

I am currently working on Universal Payload (more info) enabling for RISC-V and there is an open question regarding how to pass hartid information from SBI/Platform FW to UPL. We need this info to create CPU HOB (P.S. in UPL we do not get HOBs from the previous layer- only DT).

Due to various constraints (that UPL has to work with multiple archs), it is boiling down to the fact that it would be ideal if we could just pass DT as a standard argument. Which means we pass boot hartid as part of the RV specific DT node. This DT node is going to be an arch specific node.

Alternatively, we continue to get hartid as param inside UPL and use some custom hooks inside to extract it without impacting common boot flows.

Please let me know if there are any comments. 

--

Thanks!

=D

[Heinrich Schuchardt]

On 21.02.24 10:37, Dhaval Sharma wrote:
> Hi folks,
> I am currently working on Universal Payload

> <https://github.com/UniversalPayload/spec/releases/tag/v0.8> (more info
> <https://universalscalablefirmware.github.io/documentation/2_universal_payload.html>) enabling for RISC-V and there is an open question regarding how to pass hartid information from SBI/Platform FW to UPL. We need this info to create CPU HOB (P.S. in UPL we do not get HOBs from the previous layer- only DT).

The Universal Payload specification was written by HOB list fans. Using
device-trees does not fit well into this standard.

I would suggest to define a new HOB structure for passing the missing
information and provide it via the EFI_HOB_HANDOFF_INFO_TABLE.

Best regards

Heinrich

[Dhaval Sharma]

Actually it is indeed going to use DT for passing information from BL to Payload. There is a spec WIP to define required nodes (I can share the document link if you are interested). So there is an option (and in fact we will require) to define an RV specific DT node. 

--

Thanks!

=D

[Sunil V L]

On Wed, Feb 21, 2024 at 04:36:26PM +0530, Dhaval Sharma wrote:
> Actually it is indeed going to use DT for passing information from BL to
> Payload. There is a spec WIP to define required nodes (I can share
> the document link if you are interested). So there is an option (and in
> fact we will require) to define an RV specific DT node.
>

Why not use existing boot-hartid under chosen node?

Thanks,
Sunil

> --
> You received this message because you are subscribed to the Google Groups "RISC-V Firmware Exchange" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to fw-exchange...@riscv.org.
> To view this discussion on the web visit https://groups.google.com/a/riscv.org/d/msgid/fw-exchange/CAAxYnhSy3NCUSEchk_c1RWT0H2TkfPB93wSxVVwbqLD3GgSa2A%40mail.gmail.com.

[Dhaval Sharma]

Chosen node is really a bit loose definition in my opinion. I wanted to have something more arch defined which is scalable (in fact the same applies to other architecture as well). i.e. I expect in future we are going to have to pass ISA string etc as well. So if we define a good RV arch node it can scale well. What do you think?

--

Thanks!

=D

[Sunil V L]

On Wed, Feb 21, 2024 at 04:58:12PM +0530, Dhaval Sharma wrote:
> Chosen node is really a bit loose definition in my opinion. I wanted to
> have something more arch defined which is scalable (in fact the same
> applies to other architecture as well). i.e. I expect in future we are
> going to have to pass ISA string etc as well. So if we define a good RV
> arch node it can scale well. What do you think?
>

I don't understand. Why do we need to have another node in DT when
already there is something defined for boot-hartid and ISA string? IMO,
we should avoid different nodes having same information.

[Dhaval Sharma]

Let me clarify:

As discussed in the meeting we are talking about 2 items.

1. Is there any issue if one stage passes boot hart-id information to another fw stage via DT. It sounds like there is no issue here. We have a /Chosen node for this.
2. Should we have a more specific DT node for RV than a generalized /Chosen node. For this my point is that it is okay to continue this way for now but what I observe is that in UPL if there are multiple architectures wanting to share such information through /Chosen node, it gets a bit crowded. If we have a notion of an arch specific item (maybe within the chosen node) we can organize it a bit better. That is all. I will keep an eye on this and come back with more data on this as. Meanwhile, do we have a spec where we formally document these nodes?

=D

--

Thanks!

=D