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
apritzel_ has quit [Ping timeout: 246 seconds]
heat has quit [Ping timeout: 240 seconds]
jclsn has quit [Ping timeout: 246 seconds]
jclsn has joined #armlinux
amitk has joined #armlinux
amitk has quit [Ping timeout: 240 seconds]
amitk has joined #armlinux
iivanov has joined #armlinux
monstr has joined #armlinux
Patater has quit [Quit: Explodes into a thousand pieces]
DrPatater has joined #armlinux
DrPatater has quit [Client Quit]
DrPatater has joined #armlinux
ezulian has joined #armlinux
apritzel_ has joined #armlinux
apritzel_ has quit [Ping timeout: 255 seconds]
headless has joined #armlinux
sszy has joined #armlinux
frieder has joined #armlinux
headless has quit [Quit: Konversation terminated!]
prabhakarlad has quit [Quit: Client closed]
apritzel has joined #armlinux
mvaittin has joined #armlinux
luispm has quit [Ping timeout: 255 seconds]
frieder has quit [Ping timeout: 240 seconds]
prabhakarlad has joined #armlinux
frieder has joined #armlinux
shawnguo has joined #armlinux
monstr has quit [Ping timeout: 255 seconds]
luispm has joined #armlinux
heat has joined #armlinux
monstr has joined #armlinux
<bjdooks>
grr, anyone had issues with clang (iirc clang16) with generating ldr qX. [] code and not aligning the structs to 16 bytes to allow it to actually work
_sfo has joined #armlinux
_sfo has quit [Client Quit]
<heat>
bjdooks, is that userspace? (i hope??)
<bjdooks>
this is building trusted-firmware
<heat>
my first idea when I find one of those problems is that the stack is misaligned
<bjdooks>
just wondered if anyoen else has seen something like it, i'm assuming optimisation issue
<bjdooks>
it seems to be trying to load an 12 byte struct in one go :/
<bjdooks>
which works for the first one, then the second one in the loop fails as that's not aligned :/
<heat>
the ABI for most platforms requires 16 byte stack alignment at function entry in one way or another
<heat>
oh
mripard has joined #armlinux
frieder has quit [Ping timeout: 272 seconds]
mripard has quit [Read error: Connection reset by peer]
mripard has joined #armlinux
<ardb>
bjdooks: why would ldr qX need alignment?
<ardb>
is your MMU off?
<bjdooks>
so qemu is aborting on it, mmu should be on iirc
<ardb>
ah hold on
<ardb>
it's the stack right?
<ardb>
so stack access are permitted to be misaligned as long as SP itself is always 16 byte aligned
<ardb>
unless you are running with the MMU off, accessing device memory or have some sysreg control set to a non-default value
frieder has joined #armlinux
<bjdooks>
yeah, so clang is loading an 12 byte struct into q0 and storing it to the stack...
<bjdooks>
ldr q0, [x8] ; str q0, [ sp ] ; bl code
<bjdooks>
hmm, looks like tfa is setting the A bit to trap unaligned accesses
<bjdooks>
it doesn't help the original coder doesn#'t seem to trust struct *, and therefore these are getting passed on the stack :/
<ardb>
if SCTLR.A is set you need to pass -mstrict-align to clang
<ardb>
bjdooks: ^^^
<Xogium>
maz: did you end up returning the rpi 5 ?
heat_ has joined #armlinux
<bjdooks>
ardb: ah, yes, that seems to have fixed it
heat has quit [Ping timeout: 245 seconds]
<maz>
Xogium: not yet, but been advised to.
<Xogium>
maz: yeah makes sense... Seems like there are faulty rpi 5 going around
headless has joined #armlinux
<maz>
Xogium: is there? I've read a bunch of horror stories about RPi4 dying, but not much about RPi5.
<Xogium>
I've seen one or two other folks with the same issue as you
ezulian has quit [Quit: ezulian]
<maz>
Xogium: do you have a pointer to it? my google-foo didn't lead to anything useful.
<Xogium>
maz: no it is someone I know in real life
frieder has quit [Remote host closed the connection]
<arnd>
palmer: It's not a big deal, but yes, you need to coordinate with conchuod about who should send these patches my way to avoid duplicate patches, it looks like you both picked it up around the same days
<conchuod>
That's my fault
<palmer>
arnd: OK, that makes more sense. So it's just still called the arm-soc tree for the whole soc tree in linux-next?
<conchuod>
I was supposed to take it for the previous window, I asked him to pick it up, but then forgot I hadn't dropped it
<conchuod>
I don't think the duplicate patch thing is a big deal when they're identical though
<arnd>
palmer: I think sfr just calls it the arm-soc tree in his list in linux-next.git/Next/Trees, I call it the soc tree
<palmer>
ya, makes sense
<palmer>
I think that's just how I got confused, I'd assumed it was just in the Arm bits
<palmer>
conchuod: they have different hashes, though, so IMO it's a problem. I can probably just drop it from my tree if you want?
<palmer>
unless there's some dependency? I forgot why it ended up in my tree in the first place
<conchuod>
The contents are identical is what I meant
<palmer>
ya, but I think it's still something to avoid
<palmer>
at least, it's something I try to avoid
<palmer>
(also not Arm stuff, so maybe we jump over to #riscv to avoid the noise?)
justache is now known as justHaunted
monstr has quit [Remote host closed the connection]