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
Nact has quit [Quit: Konversation terminated!]
apritzel has quit [Ping timeout: 252 seconds]
pjw has quit [Ping timeout: 245 seconds]
narmstrong has quit [Ping timeout: 245 seconds]
sboyd has quit [Ping timeout: 245 seconds]
nohit has quit [Ping timeout: 245 seconds]
pjw has joined #armlinux
zx2c4 has quit [Ping timeout: 260 seconds]
nohit has joined #armlinux
zx2c4 has joined #armlinux
khilman has quit [Read error: Connection reset by peer]
roxell has quit [Read error: Connection reset by peer]
dtor has quit [Read error: Connection reset by peer]
zx2c4 has quit [Ping timeout: 245 seconds]
nathanchance has quit [Read error: Connection reset by peer]
nohit has quit [Read error: Connection reset by peer]
sboyd has joined #armlinux
zx2c4 has joined #armlinux
nohit has joined #armlinux
khilman has joined #armlinux
nathanchance has joined #armlinux
dtor has joined #armlinux
roxell has joined #armlinux
narmstrong has joined #armlinux
<HdkR>
robclark: I finally got around to testing what happens when when a partially faulted write occurs. Returns EFAULT as expected.
<HdkR>
Fun thing though, Since I've upgraded to 5.15, partial faulting reads now work on AArch64
macromorgan has quit [Killed (molybdenum.libera.chat (Nickname regained by services))]
macromorgan has joined #armlinux
tudorel has joined #armlinux
russ has quit [Ping timeout: 252 seconds]
russ has joined #armlinux
guillaume_g has joined #armlinux
macromorgan has quit [Killed (silver.libera.chat (Nickname regained by services))]
iivanov has quit [Read error: Connection reset by peer]
iivanov has joined #armlinux
abelvesa_ has quit [Remote host closed the connection]
abelvesa has joined #armlinux
scosu has quit [Quit: No Ping reply in 180 seconds.]
scosu has joined #armlinux
headless has joined #armlinux
russ has quit [Ping timeout: 265 seconds]
matthias_bgg has joined #armlinux
frieder has quit [Remote host closed the connection]
russ has joined #armlinux
Pali has joined #armlinux
monstr has quit [Remote host closed the connection]
torez has quit [Ping timeout: 252 seconds]
cdaudt has joined #armlinux
matthias_bgg has quit [Quit: Leaving]
torez has joined #armlinux
guillaume_g has quit [Quit: Konversation terminated!]
<gpiccoli>
Does anybody know a trick to reboot/restart an ARM64 processor with a single (or few) assembly instructions?
<gpiccoli>
I'm taking a look in machine_restart(), but seems in arm64 it relies on efi_reboot()
ardb has quit [Read error: Connection reset by peer]
<maz>
gpiccoli: rebooting is a system-wide thing. we usually rely on firmware for that.
<gpiccoli>
thanks maz, let me give you context - I hope there's a way to do what I want heheh
<gpiccoli>
I have a bug that is really early in kernel, so I'm not sure even if kernel is booted, or if bootloader fails to jump into kernel code
<gpiccoli>
So, my hacky idea is to insert some code in early kernel entry point to reboot!
<gpiccoli>
So, if the FW jumps into kernel, it'll reboot, and I know the problem is at kernel code level
<milkylainen_>
debugger?
<gpiccoli>
Conversely, if it's stuck, I'd know that bootloader is stuck
<maz>
if you're firmware supports PSCI, you can issue a PSCI reset SMC.
<gpiccoli>
milkylainen_ which one?
<gpiccoli>
yes, it supports maz!
<gpiccoli>
I'll check that then, thanks a lot! do you know if we have a code example in kernel for that maz ?
cdaudt has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<maz>
gpiccoli: the kernel has multiple layers of acstraction to get to that. but that's only loading the PSCI_RESET constant into x0, followed by SMC #0.
<gpiccoli>
that's very very helpful maz, thanks a lot!
Misotauros has quit [Ping timeout: 260 seconds]
<maz>
gpiccoli: "ldr x0, =0x84000009 " + "SMC #0" is what you need.
<gpiccoli>
wow maz, much appreciated! Thanks a bunch
<gpiccoli>
will try that and let you know how it goes heheh
ardb has joined #armlinux
<bencoh>
gpiccoli: you do have earlycon enabled already, by the way?
<bencoh>
I can speedup early kernel debugging
<gpiccoli>
sure bencoh , I do have it enabled and no output at all
<gpiccoli>
and no odd messages from bootloader as well, so it's hard to know what's going on
apritzel has quit [Quit: Leaving]
<milkylainen_>
gpiccoli: what kind of image and what mechanism are you booting through?
<gpiccoli>
I'm booting a zImage though "lk", a qcom board milkylainen_ - I'm not really sure it's a pure lk, but at least it does print lk messages
<gpiccoli>
the board is based on db820c
<milkylainen_>
zImage?
<gpiccoli>
the bootloader is booting a zImage, I create a blob with mkbootimage and use fastboot to transfer that to ufs storage in the board
<gpiccoli>
I guess bootloader isolate the zImage and the initrd based on the adresses, and jumps to the kernel start adrr
<milkylainen_>
umm. arm64 are usually Image, not zImage
<gpiccoli>
I'm not experienced in arm64, so please let me know if I'm talking bullshit heheh
<gpiccoli>
yes, it's Image
<gpiccoli>
my bad
<gpiccoli>
i'm use to talk in x86/ppc world
<gpiccoli>
arch/arm64/boot/Image is the kernel image file
<milkylainen_>
ok. :)
<gpiccoli>
so, I'm not sure how to plug a debugger there unless it's something HW related
<milkylainen_>
db820c. snapdragon 820 eg? Don't they have their own snapdragon debuggers?
<gpiccoli>
milkylainen_, it's an Inforce board, based on snapdragon - but I'm not sure about the debuggers. Might have, but for now I don't have access to anything like that, would need to buy it heheh
<arnd>
this looks like an incompatible binding change, is that intentional?
<mmind00>
arnd: I think you might want Matthias Brugger (+Rob) for Mediatek stuff instead ;-) ... though I don't see him on irc right now
<arnd>
sorry mmind00, you are right, I confused your irc nick
<arnd>
I'll reply by email then
headless has quit [Quit: Konversation terminated!]
ardb has joined #armlinux
<robher>
arnd: Mediatek PCI is a mess. IIRC, they didn't care about compatibility and the change looks like a significant improvement.
<robher>
Though there is also the mt7621 PCI driver in staging that looks to be similar, but different enough to be 'hard'.
<arnd>
robher: indeed, there is a good chance it's exactly the same hardware and the differences are all about the way MIPS does PCI differently from ARM, like the I/O space thing that should now be worked out
iivanov has quit [Remote host closed the connection]
djrscally has joined #armlinux
<Pali>
arnd: about that mentioned patch... I think it is the right change but not backward compatible because old definition was wrong
<Pali>
very similar issue is with pci mvebu driver
<Pali>
in both cases (mediatek and mvebu) DT nodes seems to be defined that there is one pcie controller with multiple pcie root ports
<Pali>
but in reality HW is something like multi-root-complex controller where each root complex has single pcie root port
ardb has quit [Ping timeout: 252 seconds]
<Pali>
I think the main issue here is missing some "guide" how to correctly write DTS files for PCIe controllers