ChanServ changed the topic of #armlinux to: ARM kernel talk [Upstream kernel, find your vendor forums for questions about their kernels] | https://libera.irclog.whitequark.org/armlinux
nsaenz has quit [Remote host closed the connection]
nsaenz has joined #armlinux
HerbY_NL has joined #armlinux
psydroid3 has joined #armlinux
ninelore has quit [Ping timeout: 256 seconds]
HerbY_NL has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
arj has joined #armlinux
graham__ has quit [Ping timeout: 256 seconds]
psydroid3 has quit [Ping timeout: 244 seconds]
HerbY_NL has joined #armlinux
psydroid3 has joined #armlinux
HerbY_NL has quit [Remote host closed the connection]
HerbY_NL has joined #armlinux
derjanni has quit [Ping timeout: 244 seconds]
derjanni has joined #armlinux
arj has quit [Read error: Connection reset by peer]
siak has joined #armlinux
psydroid3 has quit [Ping timeout: 256 seconds]
siak_ has joined #armlinux
siak has quit [Ping timeout: 272 seconds]
apritzel has joined #armlinux
siak_ has quit [Quit: No Ping reply in 180 seconds.]
siak has joined #armlinux
biju has joined #armlinux
HerbY_NL has quit [Ping timeout: 245 seconds]
siak_ has joined #armlinux
siak has quit [Ping timeout: 244 seconds]
prabhakalad has quit [Ping timeout: 255 seconds]
prabhakalad has joined #armlinux
tlwoerner_ has joined #armlinux
tlwoerner has quit [Ping timeout: 260 seconds]
nsaenz has quit [Remote host closed the connection]
nsaenz has joined #armlinux
sally- has joined #armlinux
sally_ has quit [Ping timeout: 252 seconds]
HerbY_NL has joined #armlinux
HerbY_NL has quit [Quit: Leaving]
HerbY_NL has joined #armlinux
ninelore has joined #armlinux
rgallaispou has joined #armlinux
HerbY_NL has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
vigneshr has joined #armlinux
rgallaispou has quit [Quit: WeeChat 4.7.0]
monstr has joined #armlinux
dmart has joined #armlinux
HerbY_NL has joined #armlinux
arj has joined #armlinux
HerbY_NL has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
psydroid3 has joined #armlinux
<robmur01>
rrq: point is that it should not be trying to execute U-Boot code in SVC/HYP such that a fault is taken to *Linux's* vectors
<robmur01>
that happening would tend to imply that the SMC handler is returning back *from* monitor mode to the wrong address and/or the wrong mode/security state.
<rrq>
I'm trying to trace it but so far it looks like not entering the smc handler, which to me looks like the access gets aborted by the memory setup; and that abort is handled by linux code
<rrq>
certainly a plain read of the mvbar vector address result in memory access failure
<rrq>
but printout slightly different from the smc execution attempt