On Thu, 4 May 2023 at 11:31, Ilias Apalodimas ilias.apalodimas@linaro.org wrote:
Replying to both Jassi and Tom here since it makes more sense,
On Thu, 4 May 2023 at 19:19, Tom Rini trini@konsulko.com wrote:
On Thu, May 04, 2023 at 10:39:06AM -0500, Jassi Brar wrote:
On Thu, 4 May 2023 at 10:19, Rob Herring robh+dt@kernel.org wrote:
On Thu, May 4, 2023 at 9:01 AM Jassi Brar jaswinder.singh@linaro.org wrote:
I may be wrong, but I see having fwu properties contained within the fwu node is cleaner than having them embedded into existing bindings (potentially different classes in future). So I moved to the current design.
Having all the information related to a device/node in one place is cleaner IMO.
As I said, if u-boot wants private interfaces between the DT and itself, then fine, but that should remain private and be stripped by u-boot. A separate node would certainly be easier for doing that.
Seems we are on the same page(?). Current implementation does exactly that -- we have a separate fwu node containing all the properties it needs.
I think Rob is saying the exact opposite. The way I see it we either
- Keep the bindings as an internal u-boot ABI, in which case the
current format is fine, but we need to strip it from the DT before handing it over to the OS.
I interpreted "Having all the information related to a device/node in one place is cleaner IMO." to suggest this approach. Though the stripping part remains tbd. Where should that be done in u-boot?
- Alternatively, if we want to submit it upstream, we need to change
where that data lives and ideally have them under existing partition bindings.
Here we may have to add to bindings of various subsystems (as support widens) and still have to strip the property before handover to the kernel. right?
Both would work, with the latter offering a bit more standardization if another bootloader tries to implement something similar.
Well, isn't part of why we're here is that this isn't strictly a U-Boot only thing? My question is can, and then is, this also being used in other projects yet?
I am not aware of any other projects currently using it.
Maybe I am overlooking something, but the kernel should not have anything to do with it. EDK2 may use the node as such and BL1/2 would have the meta-data location info hardcoded into them (?)
thanks.