<jernej>
it seems that when building for H5, there is some H3 stuff that breaks build
<jernej>
namely CONFIG_ARMV7_SECURE_BASE
<MoeIcenowy>
BTW when will crust be mainline ready?
<MoeIcenowy>
and, as V853 is out, is there a proper way to split HW resource between two processors?
<jernej>
MoeIcenowy: I think that Crust already works with mainline U-Boot and TF-A
<jernej>
for 64-bit SoCs
<jernej>
only H3 needs U-Boot patches
<jernej>
and only few Linux patches are needed
<MoeIcenowy>
well I mean the Linux ones
<MoeIcenowy>
I know TF-A is ready for crust for a long time
<MoeIcenowy>
(BTW TF-A R329 support is upstreamed for a long time, but I didn't push Linux/U-Boot a lot yet
<jernej>
Currently I have 12 Crust related patches in 5.18
<jernej>
I believe one was mainlined in 5.19
<jernej>
already much better situation than before, but not just there yet
<jernej>
well, you have to ask smaeul about further plans
<jernej>
btw, what kind of HW resources you have in mind?
<gamiee>
It would be cool to have Crust ported to V853's RISC-V core
<MoeIcenowy>
jernej: well I think peripherals on V853 are quite equal to both cores
<MoeIcenowy>
by default I think Allwinner BSP allocates a chunk of DRAM and UART3 to RV
<jernej>
ok, I'm out of the loop regarding V853
<jernej>
is there any manual for it?
<jernej>
or at least datasheet
<MoeIcenowy>
there should be none
<MoeIcenowy>
but I have some leaked thing
<jernej>
well, resource allocation is usually HW dependent, so it's impossible to say if there is no available documentation or BSP code
<MoeIcenowy>
BSP code gots available 3 hrs ago
<gamiee>
BSP is open now? On open allwinnertech?
<apritzel>
MoeIcenowy: what would be the problem with the hardware allocation to either core? Sounds like the DT is a good fit for that:
<apritzel>
the DT starts with everything available, then firmware (either TF-A, U-Boot, or crust) grab exclusive possession of a device, and disable it in the DT passed down
<MoeIcenowy>
gamiee: yes
<MoeIcenowy>
apritzel: well it's even a problem on H616, right?
<apritzel>
MoeIcenowy: only if you do the wrong thing: explicitly loading a DTB from disk ;-)
<apritzel>
looks like we don't want to really support this anymore
<MoeIcenowy>
but is it really wrong?
<MoeIcenowy>
we do not update U-Boot DT frequently.
* jernej
grabs popcorn :)
<MoeIcenowy>
and Linux is now the de facto central DT hub
<apritzel>
jernej: lol (and sigh)
<apritzel>
MoeIcenowy: for multiple reasons, the main blocker being incompatible changes
<MoeIcenowy>
I remember Fedora manually syncs DT to U-Boot in order to prevent explicit DT load
<MoeIcenowy>
In addition, if you want to add something that has no stable binding
<apritzel>
we broke this with syncing the 5.18 DTs in a forward compatible way now, so can more frequently update
<MoeIcenowy>
use a manually loaded DT instead of bootloader shipped DT is a good idea
<apritzel>
I plan on syncing the 5.20-rc1 DTs
<apritzel>
MoeIcenowy: if it's for something experimental or for development: sure, but then you know what you do, and live with the consequences
<apritzel>
or you are clever and use overlays
<MoeIcenowy>
apritzel: overlays are not easy to use now
<MoeIcenowy>
loading an overlay is in fact much more complex than loading a full DT
<MoeIcenowy>
and I don't think we build U-Boot DT in a overlay-friendly way