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
Turringen has quit [Ping timeout: 276 seconds]
apritzel_ has quit [Ping timeout: 276 seconds]
jlinton has joined #armlinux
jlinton has quit [Client Quit]
amitk has joined #armlinux
apritzel_ has joined #armlinux
apritzel_ has quit [Ping timeout: 240 seconds]
suzukikp has quit [*.net *.split]
lag has quit [*.net *.split]
robmur01 has quit [*.net *.split]
rfried has quit [*.net *.split]
palmer has quit [*.net *.split]
abelvesa has quit [*.net *.split]
tagr has quit [*.net *.split]
gpiccoli has quit [*.net *.split]
gclement_ has quit [*.net *.split]
javierm has quit [*.net *.split]
palmer has joined #armlinux
javierm has joined #armlinux
abelvesa has joined #armlinux
tagr has joined #armlinux
gclement has joined #armlinux
gpiccoli has joined #armlinux
suzukikp has joined #armlinux
gpiccoli has joined #armlinux
gpiccoli has quit [Changing host]
robmur01 has joined #armlinux
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #armlinux
lag has joined #armlinux
ajb-linaro has quit [*.net *.split]
nohit has quit [*.net *.split]
marcan has quit [*.net *.split]
ccaione has quit [*.net *.split]
jkridner has quit [*.net *.split]
jtf has quit [*.net *.split]
Fridtjof has quit [*.net *.split]
NishanthMenon has quit [*.net *.split]
ccaione has joined #armlinux
jkridner has joined #armlinux
nohit has joined #armlinux
NishanthMenon has joined #armlinux
ajb-linaro has joined #armlinux
marcan has joined #armlinux
jtf has joined #armlinux
Fridtjof has joined #armlinux
monstr has joined #armlinux
mwalle has joined #armlinux
frieder has joined #armlinux
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #armlinux
biju has joined #armlinux
mcoquelin has quit [Remote host closed the connection]
guillaume_g has joined #armlinux
mcoquelin has joined #armlinux
headless has joined #armlinux
guillaume has joined #armlinux
rvalue- has joined #armlinux
rvalue has quit [Ping timeout: 240 seconds]
rvalue- has quit [Remote host closed the connection]
guillaume_g has quit [Ping timeout: 244 seconds]
rvalue has joined #armlinux
luispm has quit [Quit: Leaving]
nsaenz has joined #armlinux
luispm has joined #armlinux
headless has quit [Quit: Konversation terminated!]
alexels has joined #armlinux
apritzel has joined #armlinux
guillaume_g has joined #armlinux
guillaume has quit [Ping timeout: 255 seconds]
<scosu[m]>
What is the difference between irq_of_parse_and_map() and of_irq_get() apart from irq domain check in of_irq_get() which can lead to EPROBE_DEFER?
torez has joined #armlinux
guillaume has joined #armlinux
guillaume_g has quit [Ping timeout: 272 seconds]
sszy has joined #armlinux
guillaume has quit [Quit: Konversation terminated!]
jlinton has joined #armlinux
guillaume_g has joined #armlinux
guillaume has joined #armlinux
guillaume_g has quit [Ping timeout: 260 seconds]
guillaume is now known as guillaume_g
guillaume has joined #armlinux
guillaume_g has quit [Ping timeout: 240 seconds]
guillaume is now known as guillaume_g
headless has joined #armlinux
jlinton has quit [Quit: Client closed]
<arnd>
scosu[m]: irq_of_parse_and_map() is the old interface from powerpc before the of_device was folded into platform_device. Most drivers should just use platform_get_irq()
balrog has quit [Ping timeout: 256 seconds]
balrog has joined #armlinux
<scosu[m]>
arnd: thank you
<mrutland->
ardb: looking at arm64 for-next/core, it looks like KASAN_INLINE got broken by commit a004393f45d9a55e ("arm64: idreg-override: use early FDT mapping in ID map")
mrutland- is now known as mrutland
<mrutland>
... because the idmap alias of the FDT doesn't have a legitimate shadow addr, and so the inline shadow accesses blow up
<mrutland>
It looks like marking the idreg-override file as KASAN_SANITIZE=n isn't sufficient, because there are calls to instrumented functions (e.g. mem*(), str*())
<mrutland>
thought maybe I'm being thick, since we make a copy, and should be able to safely avoid instrumentation there
balrog has quit [Ping timeout: 272 seconds]
frieder has quit [Remote host closed the connection]
<hanetzer>
a userspace question. is there any 'proper' or 'recommended' way of doing mmio from userspace? it seems that most kernel drivers use {read,write}{,b,l,etc} or some wrapper around them; does such a construction/helper exist in userspace?
monstr has quit [Remote host closed the connection]
<robmur01>
really the best rule is don't do MMIO from userspace, but failing that it runs the gamut from carefully-abstracted accessors using inline asm and/or volatile to hide them from optimisation as Linux does, to just dereferencing pointers directly and hoping
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #armlinux
<robmur01>
unless of course you were using some language other than C which had a first-class notion of MMIO vs. memory rather than a very abstract execution environment
c1728p9 has joined #armlinux
luispm has quit [Quit: Leaving]
<ajb-linaro>
what is lib/Kconfig.debug for - file seems to think it's a binary file
<j`ey>
ajb-linaro: shows as an ASCII text file to me
<ajb-linaro>
hmm odd - I guess my old ssd was sicker than I thought... surprised that git didn't complain about it though
alexels has quit [Quit: WeeChat 3.5]
<Xogium>
stupid question, does it really matters if you compile something that is meant to be running on bare metal with a non bare metal toolchain ? I.e: linux-gnueabihf instead of noneabi
<biju>
if you are compiling TF-A, mostly won't boot
<Xogium>
really ?
<Xogium>
why ?
<robmur01>
if the project is fully set up to not rely on toolchain libraries or default values for compiler options, no. I'm not sure if I've ever built an arm64 kernel with anything *other* than an aarch64-linux-gnu toolchain :)
<robmur01>
if on the other hand you compile a random .c file with an arm-linux-gnueabihf toolchain which assumes a Cortex-A9 with NEON and expect it to run fine on a Cortex-M0, you'll probably have a bad time.
<Xogium>
I see
<Xogium>
asking cause this is ATF, so
<Xogium>
NOTICE: BL2: Booting BL32... and nothing else
<Xogium>
I'm going mad with optee
<robmur01>
yeah, I could well imagine that TF-A assumes a sensibly-configured bare-metal toolchain and doesn't override every compiler option which might do something problematic
<Xogium>
I guess it wasn't the none-eabi then, erk
<Xogium>
it just doesn't want to launch optee
<robmur01>
(e.g. most modern armhf toolchains default to -mthumb, but bare-metal v7-A code would typically would to be built for ARM state)
<biju>
you can disable BL32, and try BL33
* robmur01
wonders how editing between "want" and "need" ended up as "would" there :/
<ajb-linaro>
j`ey: heh - rm lib/Kconfig.debug and git reset --hard HEAD fixed it... *shrug*
<Xogium>
biju: well that's the thing... Buildroot somehow is able to build a working ATF+optee with a specific external tree while I can't manage it on my own
<Xogium>
doing what they did on my side makes it not work, building the config works
<Pali>
If you are compiling with -ffreestanding -nostdlib -nostartfiles and -mcpu= options then it does not matter what kind of toolchain are you using.
<Xogium>
I have to have at least sp_min as bl32, this one works, but vendor switched to optee
apritzel has quit [Ping timeout: 272 seconds]
<Pali>
and these flags are commonly used for compiling bare metal code
<robmur01>
Pali: unless it's also a hard-float Thumb toolchain which will still happily turn your freestanding code into instructions which won't actually run ;)
<Pali>
Ok :) But you can control this via compile flags too.
<robmur01>
at least the aarch64 target has -mgeneral-regs-only
<Pali>
-marm -msoft-float or what are those flags
<Xogium>
from the looks of thing its ATF that broke
<robmur01>
admittedly my TF-A tree is old, but grepping for either of those options brings up nothing, that's my point ;)
<Xogium>
flashing a working fip with the ATF I just built totally fails
<Xogium>
if I flash a working ATF from buildroot everything's back to normal
<Xogium>
the thing is... I don't know why it breaks
* broonie
has never been able to figure out how to make optee build outside of it's own distro type stuff :(
<Xogium>
huh, wait
<Xogium>
no, my bad
<Xogium>
I flashed a broken fip with a working ATF, not the other way around
<Xogium>
ok
<Xogium>
so
<Xogium>
the fip is broken, somehow
<Xogium>
the last thing I see on ATF side is setting up a trust zone
<Xogium>
but ATF loads the fip images one after another... It loas image id 4, then proceeds to load image id 21 exactly on top of id 4 ?
<Xogium>
same address range and everything. At least same start address
<Xogium>
is it like... even supposed to do that ?
<Xogium>
I thought ATF itself regulated where in memory fip images were loaded
<Xogium>
but could it be the fip image itself telling it that ?
c1728p91 has joined #armlinux
c1728p9 has quit [Ping timeout: 260 seconds]
c1728p91 has quit [Quit: Leaving]
c1728p9 has joined #armlinux
<hanetzer>
robmur01: working thru some binary kmod/userspace libs (where one ends and the other begins varies per 'device'; the jpeg decoder seems to handle just about *all* the mmio in the userspace lib, which is 'standard' jpeg6b+hw functions and the kmod seems to only handle irqs and clock stuff) and part of my process is some LD_PRELOAD hackery
<hanetzer>
it seems its encoder analog does more in the kmod tho
<robmur01>
yeah, BSPs :(
<hanetzer>
yee. at least *this one* uses a relatively recent (4.9.37) kernel and devicetree. still old af u-boot tho (2010.06)
macromorgan has joined #armlinux
biju has quit [Quit: Client closed]
jwerner has quit [Quit: leaving]
nsaenz has quit [Quit: Leaving]
<Xogium>
hrm. I grabbed the components buildroot grabbed for optee and built the fip manually with them. They work fine. So at least its not the fip generation that's going insane...
<Xogium>
so like the tee binaries are what's not being built correctly
<Xogium>
this is crazy. I have exactly the same build flags passed in my build of optee, yet manual compilation or compilation using my own buildroot defconfig doesn't produce a working optee
<Xogium>
using the very same toolchain also
<Xogium>
if anyone's got any idea...
<Xogium>
because honestly by now I don't have any more ideas to try finding why this happens
<Xogium>
if it was up to me I'd stick to sp_min but I don't have much choice since vendor is giving up on trying to maintain sp_min for arm32
<Xogium>
and optee at the sime time
<Xogium>
*same
amitk has quit [Ping timeout: 240 seconds]
apritzel_ has joined #armlinux
jwerner has joined #armlinux
headless has quit [Quit: Konversation terminated!]
djrscally has joined #armlinux
djrscally has quit [Ping timeout: 244 seconds]
Pali has quit [Ping timeout: 276 seconds]
torez has quit [Remote host closed the connection]