<sjg1>
Tartarus: PHASE_ is used to individually control (via Kconfig) which phases get a certain feature. XPL_ is used when *all* xPL phases should behave the same (either get the feature or not)
naoki has joined #u-boot
warpme has joined #u-boot
warpme has quit [Ping timeout: 245 seconds]
sakman has quit [Remote host closed the connection]
sakman has joined #u-boot
warpme has joined #u-boot
warpme has quit [Ping timeout: 252 seconds]
goliath has quit [Quit: SIGSEGV]
ikarso has quit [Quit: Connection closed for inactivity]
monstr has quit [Remote host closed the connection]
mmu_man has joined #u-boot
<Jones42>
Has anyone already managed to get to run op-tee on a i.mx7?
<marex>
Jones42: not me, why ?
<marex>
Jones42: start u-boot in EL3 or equal on arm32, pack up optee into fitImage alongside Linux, set correct load address and entry point for OpTee , make sure optee exits into the Linux load address, boot ?
<marex>
something like that , give or take
sakman_ is now known as sakman
<Jones42>
marex: thanks for the pointers.
<Jones42>
marex: we have a student who's trying to make it work for his thesis. Not sure why they didn't go for a imx8mp. that looked like it would be easier.
<Jones42>
marex: the colleagues chose a toradex board and it's all very "work in progress"-y
<Jones42>
marex: thanks. I was just hoping someone would point me to a working example or something in that direction. It's a student's project and I'm not his supervisor, so I'll just pass that information on to them :-)
warpme has joined #u-boot
warpme has quit [Client Quit]
<marex>
calebccff: nice
<marex>
calebccff: I think U-Boot should be the first thing running in EL3, and load all the other non-free blobs and then Linux as well
<marex>
calebccff: U-Boot is, after all, the debug tool
<marex>
calebccff: it should have the option of having unrestricted hardware access so it can act like one, hence it should run in EL3
<calebccff>
marex: i like it... :P
<calebccff>
marex: is it possible to emulate MMIO access from el3? or only el2?
<calebccff>
i've been wanting a platform-agnostic m1n1 equivalent for a while
warpme has joined #u-boot
<marex>
calebccff: emulate ?
<marex>
mini is the apple loader ?
<calebccff>
marex: trap accesses for logging, or for example to mux the UART
<calebccff>
m1n1 is also a debug hypervisor, it can boot linux/macos in el1, it takes control of a USB port and lets you interactively debug
<calebccff>
xen can apparently kinda do this too but it's gdbstub is x86 specific i think
warpme has quit [Client Quit]
<calebccff>
would be suuuuper awesome if we could turn U-Boot into a small VMM that just let you gdb the kernel
<marex>
calebccff: oh, huh
<marex>
calebccff: U-Boot can become PSCI provider, even on ARM64, the PSCI part runs in EL3, but the whole __secure thing is awful
* calebccff
tried before but was too dumb to figure out how to set up a vector table in el2 and drop to el1, might try again at some point though
<marex>
calebccff: I think that would have to be spun into some dedicated stage , which would have to be started from U-Boot ... and act as the hypervisor
<marex>
calebccff: I did a bit of that for iMX8MP for the PSCI implementation ; I have to revisit that at some point
<calebccff>
marex: i was thinking we'd have u-boot start in el2 and drop to el1 during relocation (setting up the vectors in the process). it could emulate the UART and implement a gdbstub on top
<calebccff>
eventually emulate whatever mmio you want i guess, but baby steps...
<marex>
calebccff: I would want U-Boot in EL3, because then I have full access to EVERYTHING
<marex>
calebccff: it makes debugging hardware so much easier
<marex>
but yes, there is no safety net
<marex>
if something goes wrong, it goes ... boom
<calebccff>
how does that help debugging?
<calebccff>
ooi
<marex>
calebccff: I can e.g. read memory which is otherwise not accessible because some TFA/TEE thinks it knows better
<Tartarus>
calebccff: Can you post a boot log from a UFS-having device please, when you have a minute?