lopper: assists: gen_domain_dts: Ensure correct serial is used #667
Conversation
|
CC @onkarharsh @kedareswararao |
If non-default serial is the only present, ensur that chosen properties are adjusted to reflect it. Signed-off-by: Ben Levinsky <ben.levinsky@amd.com>
bentheredonethat
force-pushed
the
gen-domain-zeph-chosen-serial
branch
from
2387856 to
abd0454
Compare
| sdt.tree['/aliases'] + LopperProp(name="ufs0", value = ufs_node.abs_path) | ||
|
|
||
| # Ensure correct serial node is used | ||
| chosen_node = sdt.tree['/'].subnodes(children_only=True,name="chosen$") |
There was a problem hiding this comment.
@zeddii : the requirement here is to have a different serial for Zephyr and Linux should it be derived from domain yaml?
There was a problem hiding this comment.
Maybe a better phrasing is: should the serial device be specified in the domain (whether it is in yaml or not isn't the important part) ?
It could be in the access_list, and if so, we could then make sure that the domain_access assist pruned out unreferenced serial devices. Which may not be the key question here, since from the patch description, it more sounds like the chosen node needs to be updated to match the serial. If so, that is something that could be done in the more generic assists.
But I need more information on the complete flow, as just looking at this change to the assist, isn't giving me enough context to say whether or not we can do something generically for this (which is the preference).
There was a problem hiding this comment.
Hi @zeddii i think we agree
I want to (a) declare the serial in the access list and (b) then have whichever plugin setups zephyr DT (in this case gen domain plugin) then read the existing serial node and set u the chosen:zephyr properties correctly.
I checked and @sstabellini was OK with the domain access approach. Note that even if we do that, this logic or something similar is needed to ensure the chosen node gets in correctly.
Thanks
CC @kedareswararao
There was a problem hiding this comment.
@bentheredonethat may i know the end to end case that you are trying to fix here. Do you have domain.yaml in this flow?
For example you have 2 uarts present in the SDT and chosen node in SDT has uart0. Now, in the domains yaml, if one uart(i.e uart0) is assigned to Linux domain and uart1 is assigned to Zephyr domain, are you trying to update chosen node with uart1 in zephyr dt? is my understanding correct?
There was a problem hiding this comment.
@sivadur : what's your take on this? could you please provide your inputs here
There was a problem hiding this comment.
ok. so thinking on this more. Do the other serial devices carry through to the domain DTS ? i.e. is there one active one and others in the final ?
The reason I ask, is that passing special flags or making special key-value pairs in the domains.yaml ends up making things inflexible over time.
Similar to other things that we've done, if there was only one serial device that went through, we could just prune out all unreferenced serial devices (consistent with other processing), and then the OS specific assist would know that the serial left in the device tree (or domain, since we maintain that in the SDT) needs to be promoted / made available to the OS .. so for linux that would be putting it into the chosen node, and other OSs would do os-specirfic things.
If that doesn't work, the next question is: if we know the serial we want to the point where we can put it into the domains.yaml, what is the relationship to the SDT ? i.e. can we find the node in the SDT and just update the chosen node directly ?
Barring that, something more generic in the assist like simply a "chosen;" property being found (so just an empty chosen key value pair in the domains.yaml or just chosen; in dts) means that whatever node this is, should be copied into the chosen node. But that binds us to linux and chosen, which is less than ideal.
lops can also easily handle this and be more flexible, remember lops should be considered and not just drive everything into assists.
Going back to the "chosen" property I mentioned, something more generic like "copy_to: chosen" would allow us to generically tag a node/property and copy it to somewhere else (in this case chosen), but again, lops can also do that quite easily.
Sorry for the slow reply, I wasn't sure if you were waiting on me to answer or not!
There was a problem hiding this comment.
@bentheredonethat may i know the end to end case that you are trying to fix here. Do you have domain.yaml in this flow?
For example you have 2 uarts present in the SDT and chosen node in SDT has uart0. Now, in the domains yaml, if one uart(i.e uart0) is assigned to Linux domain and uart1 is assigned to Zephyr domain, are you trying to update chosen node with uart1 in zephyr dt? is my understanding correct?
@sivadur yes exactly
there are 2 UARTs for a given domain so we need way to define the chosen node properly
There was a problem hiding this comment.
@sivadur the thing is - even if we use domain-access as is - there are default chosen node values coming through - for linux from the SDT
We need someway to have the domain-configured chosen values for the zephr domain DT now
4 participants
If non-default serial is the only present, ensur that chosen properties are adjusted to reflect it.