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: 268 seconds]
XV8 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
XV8 has joined #armlinux
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #armlinux
amitk has joined #armlinux
apprenticeofbenj has joined #armlinux
cbeznea has quit [Quit: Leaving.]
cbeznea has joined #armlinux
sibis2 has joined #armlinux
apritzel_ has joined #armlinux
bjdooks has quit [*.net *.split]
balrog has quit [*.net *.split]
wolfshappen has quit [*.net *.split]
jwerner has quit [*.net *.split]
hanetzer has quit [*.net *.split]
[florian] has quit [*.net *.split]
HdkR has quit [*.net *.split]
kristinam has quit [*.net *.split]
crummel has quit [*.net *.split]
Esmil has quit [*.net *.split]
rfs613 has quit [*.net *.split]
mal`` has quit [*.net *.split]
marshmallow has quit [*.net *.split]
pg12 has quit [*.net *.split]
tmlind has quit [*.net *.split]
nbd has quit [*.net *.split]
sibis has quit [*.net *.split]
mmind00 has quit [*.net *.split]
kbingham has quit [*.net *.split]
sibis2 is now known as sibis
bjdooks has joined #armlinux
jwerner has joined #armlinux
balrog has joined #armlinux
wolfshappen has joined #armlinux
HdkR has joined #armlinux
[florian] has joined #armlinux
kristinam has joined #armlinux
Esmil has joined #armlinux
crummel has joined #armlinux
pg12 has joined #armlinux
hanetzer has joined #armlinux
rfs613 has joined #armlinux
marshmallow has joined #armlinux
mal`` has joined #armlinux
tmlind has joined #armlinux
nbd has joined #armlinux
kbingham has joined #armlinux
mmind00 has joined #armlinux
balrog has quit [Max SendQ exceeded]
wolfshappen has quit [Max SendQ exceeded]
wolfshappen has joined #armlinux
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #armlinux
frieder has joined #armlinux
balrog has joined #armlinux
apritzel_ has quit [Ping timeout: 264 seconds]
apprenticeofbenj has quit [Remote host closed the connection]
sudeepholla_ has quit [Ping timeout: 272 seconds]
iivanov has joined #armlinux
luispm has quit [Quit: Leaving]
iivanov has quit [Quit: Leaving.]
iivanov has joined #armlinux
nsaenz has joined #armlinux
headless has joined #armlinux
djrscally has joined #armlinux
iivanov has quit [Quit: Leaving.]
Pali has joined #armlinux
alexels has joined #armlinux
matthias_bgg has joined #armlinux
rfried has joined #armlinux
Crassus has joined #armlinux
luispm has joined #armlinux
headless has quit [Quit: Konversation terminated!]
apritzel has joined #armlinux
Crassus has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
matthiasbgg[m] has joined #armlinux
<robmur01>
Xogium: check the stuff under DEBUG_LL and associated bits like DEBUG_UART_*
<robmur01>
if it blows up in printascii() chances are it's poking at the wrong address
<robmur01>
(probably also any earlycon=/earlyprintk= command-line options you're passing; I forget exactly when one started to matter more than the other)
* bjdooks
falls into a deep dark rabbit hole of trying to fix sparse warnings
<Xogium>
robmur01: everything appears to be ok on debug_ll side
<Xogium>
I pass earlyprintk without any other arguments
<Xogium>
friend of mine says that its calling busyuart, that its trying to write 'alsa device list' to the serial but is unable to
monstr has joined #armlinux
* Xogium
scratches head
<Xogium>
oh, if this matters... this system is now freaking finally, running ATF+optee
<Xogium>
after amost a month of trying this and that to get optee to behave properly, I finally discovered that the problem was not in fact optee, but u-boot
<Xogium>
my optee not working was due, all this f***** time to a bad bl33. The ATF doc tells you to use stm32mp15_trusted_defconfig. You should use stm32mp15_defconfig instead, like I said in #barebox yesterday
<Xogium>
but, who'd think its bl33 the problem, if ATF tells you booting bl32 and stops right then and there ?
<Xogium>
of course you'd expect the issue to be bl32
<Xogium>
gonna try to remove uart, set tty1 as console insteas of ttySTM0, then remove earlyprintk. Just to see what it'll do
<Xogium>
*instead
<robmur01>
it may be that 5.15 cares more about earlycon than earlyprintk, so might be picking up something rogue that was ignored before (e.g. stdout-path in the DT)
<Xogium>
hmm serial0 is where it should go
<Xogium>
always went there
<Xogium>
which is uart4
<Xogium>
connected to st-link
<Xogium>
man I love u-boot's mass storage mode
MWelchUK has joined #armlinux
<Xogium>
hmm
<Xogium>
optee managed to print this
<Xogium>
E/TC:1 Panic 'Watchdog' at ?:0
<Xogium>
I'm not exactly what its trying to say, did optee itself panic, did the kernel panic ?
headless has joined #armlinux
<Xogium>
ah yeah. Okay, optee panics because linux froze and its expecting it to ping a watchdog, I think
cbeznea has quit [Ping timeout: 260 seconds]
cbeznea has joined #armlinux
<hanetzer>
quick question (hopefully), is there any particular naming convention for the dt binding yaml files?
<hanetzer>
there exists a file, hisi-crg.txt, which I intend to convert to the yaml format, so is just hisi-crg.yaml fine?
<headless>
hanetzer: hifi,crg.yaml, I think
<headless>
*hisi
<Xogium>
what the heck... if I disable console on ttySTM0 and earlyprintk it freezes but the stack trace shows it froze on hid_input
<Xogium>
like this
<Xogium>
#0 0xc0598ba0 in hidinput_configure_usage (usage=0x5dbf, field=0xc184d4e8, hidinput=0xc2006800) at drivers/hid/hid-input.c:996
<Xogium>
#1 hidinput_configure_usages (report=<optimized out>, hidinput=<optimized out>) at drivers/hid/hid-input.c:1926
<Xogium>
#2 hidinput_connect (hid=0xc0bcf930, force=<optimized out>) at drivers/hid/hid-input.c:1992
<Xogium>
and that's it
<Xogium>
:D
<hanetzer>
headless: well, considering their vendor string is "hisilicon" I'll probably go with that, then.
<hanetzer>
well that's strange.
<Xogium>
hanetzer: my stuff ? Yeah, sure is
<Xogium>
I'm thinking the hid input stuff isn't what freezes it, merely a side effect
<hanetzer>
welcome to embedded :P
<Xogium>
problem is I'm not sure how to debug it further
<hanetzer>
I find that slub debug and kasan helps a bit; I had a fucky clock driver (I was writing it, so my fault) and it showed me that I was clobbering some other thing lmao
<Xogium>
hmm
<Xogium>
does that work with gdb ?
<Xogium>
cause I don't even have working serial..
<hanetzer>
it just shits it out over console if something goes pear shaped
<Xogium>
hanetzer: well that's the issue I don't have a console
<hanetzer>
and if you have gdb working with it, the linux vmlinux-gdb.py script has lx-dmesg which yanks it from the ringbuffer iirc
<hanetzer>
(assuming things aren't too pear-shaped)
<Xogium>
the last thing I get is earlycon bootconsole enabled in quet boot mode
<Xogium>
then a complete freeze, then optee panics/reset the hardware
<Xogium>
in debug instead of quiet I get more info, like thermal sensor probbed successfully, but then kernel tries to write 'alsa device list' to the serial console and suddenly is unable to
<Xogium>
calls busyuart
<Xogium>
and then everything explodes
<Xogium>
fun thing is, it must be coming from my config... Because the buildroot external tree from bootlin for this board works just fine and dandy
<Xogium>
erk, multi v7 defconfig
<Xogium>
I don't like this config
<Xogium>
I mean, I get it. Its a cool defconfig that is pretty generic, it has a whole ton of supported things, but that's also the problem. It's a pain to trim out and you make mistakes in trimming things out of there sometimes, for example you remove something you don't think you needed but it turns out that you in fact needed it
<Xogium>
which is probably what I've done, somehow. Or I'm missing a config option that is now required by 5.15 but previously wasn't for 5.10. Either way my config is weird because it disabled framebuffer support for no reason I could determine
headless has quit [Quit: Konversation terminated!]
torez has joined #armlinux
torez has quit [Client Quit]
torez has joined #armlinux
XV8 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
XV8 has joined #armlinux
Pali has quit [Ping timeout: 272 seconds]
<geertu>
Xogium: See e.g. 8c1768967e2733d5 ("ARM: config: mutli v7: Reenable FB dependency")
<Xogium>
geertu: hmm, iteresting. Could that have impacted my transition with my own defconfig from 5.10 to 5.15 ?
<Xogium>
*interesting
<geertu>
Yes it can. As the symbol was auto-selected before, it didn't end up in a config created by "make savedefconfig"
<Xogium>
oh
<Xogium>
I see
<Xogium>
I'm currently bisecting my full config and the one that the bootlin build produced with my friend, merging it halfway kind of stuff
<Xogium>
until it works
monstr has quit [Remote host closed the connection]
c1728p9 has joined #armlinux
<scosu[m]>
I am currently seeing a "DMA mask not set" warning for a devicetree-matched child of a MFD device which in turn is a child of an I2C adapter and bus. If I understood this correctly, if dma_mask is not set for devicetree probed devices, this warning will be shown. However I am wondering what the value should be starting at the MFD device level?! It is currently 0 for the child, MFD device and i2c adapter. Only the bus has something set.
<robmur01>
scosu[m]: the real problem is that a thing representing an i2c device is a platform device, when we have to assume that platform devices are real DMA-capable SoC blocks thanks to how the OF code works
* broonie
notes that he continually grumbles about people putting the MFD split up of devices into the DT.
* robmur01
thinks about 90% of MFD drivers should probably just be a regmap
<robmur01>
anyway, is that not automatically taken care of by setup_pdev_dma_masks() now? Or is MFD doing something completely weird to create its children?
<broonie>
An awful lot of them *are* just a regmap and instantiation of subfunctions.
<broonie>
Possibly with some core power up/down stuff for chip level power management.
apritzel has quit [Ping timeout: 272 seconds]
<scosu[m]>
hm, at least in my case the mfd child corresponds to a pin being configured in a specific way, namely as a pushbutton. But this configuration is hardware dependent, it could also be vsense for example. I could describe it with a boolean property as well. Not sure that's better?!
<scosu[m]>
robmur01: thanks, I will have a look what the mfd function to add the devices is doing. Thanks for the pointer to the function
matthias_bgg has quit [Quit: Leaving]
djrscally has quit [Ping timeout: 240 seconds]
<robmur01>
broonie: right, and that's where people fall into the trap of thinking they have to have an MFD with completely separate drivers, rather than simply have a driver which exposes multiple functionalities (which may even be sub-modules living in different subsystem directories if that's appropriate)
<robmur01>
e.g. dw_hdmi somehow manages to be a DRM bridge, an audio device, and a CEC device without needing MFD... such witchcraft!
<broonie>
For review we do need to split things up by subsystem (and practically speaking you often want to be able to configure out bits of the chip that aren't being used for space), we're using platform devices because they're simple noop devices - originally people were open coding buses to do this.
<robmur01>
the last time I thought about this properly (back when rejigging that DMA mask stuff), I think I came to the conclusion that one fairly sensible compromise might be for MFD to have its own special bus type
<robmur01>
the platform "bus" is the worst thing for so very many reasons
<broonie>
Greg did try to change his mind and push people to do some new bus which is a copy of platform device with a different name (something beginning with an s, can't immediately see it) but he's doing it entirely through negative review so IIRC it's just the bus and none of the supporting infrastructure is being looked at.
<broonie>
and how to split things up was very unclearly described (again, entirely through negative review which doesn't help).
<broonie>
Devices that physically exist but don't have MMIO being one example (eg, stuff with GPIO controls).
<broonie>
robmur01: auxiliary bus, it got renamed.
<geertu>
broonie: you beat me to it by ;-)
* broonie
can't immediately locate any documentation which says what an auxiliary device is supposed to be. :/
<broonie>
Ah, no there's a bit at the top of the .c file a page or two below the comment which says to look at the mostly empty .rst file.
<geertu>
broonie: It's a mystery device...
<broonie>
robmur01: Also note that some of the MFDs are for memory mapped devices so *should* be using platform_device for their subfunctions (eg, a PCI device with a bunch of IPs in it), MFD would need to have the option to select platform or auxiliary device for the subfunctions.
apritzel_ has joined #armlinux
headless has joined #armlinux
robmur01 has quit [Remote host closed the connection]
robmur01 has joined #armlinux
frieder has quit [Remote host closed the connection]
Pali has joined #armlinux
luispm has quit [Quit: Leaving]
sakman has quit [Quit: Leaving]
alexels has quit [Quit: WeeChat 3.5]
sakman has joined #armlinux
apritzel_ has quit [Ping timeout: 244 seconds]
sudeepholla_ has joined #armlinux
cbeznea has quit [Ping timeout: 240 seconds]
<Xogium>
hanetzer, robmur01, geertu: you lot won't believe this. Migrating to 5.15 from 5.10 was so fscked up because... Kconfig somehow disabled all 3 of these: CONFIG_CLKSRC_STM32_LP, CONFIG_HWSPINLOCK, CONFIG_HWSPINLOCK_STM32
<hanetzer>
oh yeh, that'll prolly fuckya
<Xogium>
hanetzer: yep, a good fsck you
<Xogium>
that was so not nice
<Xogium>
took us hours to figure that out
<hanetzer>
well, I suppose it could be worse :)
<Xogium>
how so ?
<Xogium>
:D
<Xogium>
though wait there's something else too, not entirely solved
sudeepholla_ has quit [Ping timeout: 264 seconds]
sudeepholla_ has joined #armlinux
<hanetzer>
just a config mistake, not some deep-seated code reason / hardware issue
nsaenz has quit [Ping timeout: 272 seconds]
<Xogium>
hanetzer: yeah, good point ^^
<Xogium>
still kind of annoying when that sort of unpredictable behavior happens
<hanetzer>
it *seems like* that kconfig option should be auto-toggled when ARCH_STM32 or whatever is flipped, so I'd perhaps classify it as a bug
<Xogium>
I know right ?
<hanetzer>
assuming that stm32 is a first-class citizen in the arm tree
<Xogium>
it should be
<Xogium>
given that st is actually a vendor that does its damn best to mainline stuff
<Xogium>
still, bugs can happen
* hanetzer
cries in crap vendor
<hanetzer>
I've chosen a stupid hill to die on lmao. but I've been learning quite a lot in the process so I guess that's a win
<Xogium>
heh
<Xogium>
I tend to dislike most vendors these days lol
<Xogium>
except the ones like nxp, st, microchip, who actually bother mainlining
<Xogium>
the only reason why I stick to vendor stuff rn is because I need it for low power modes
<hanetzer>
fair assessment. I'm only running vendor because 1. a full port of u-boot is hella work and 2. to debug/trace/similar their fun bits
<hanetzer>
and something fucky is going on with this board; compiling the vendor sdk u-boot and inserting the existing u-boot's register file into it causes a weird bootloop I haven't gotten around to debugging yet
<marex>
Xogium: ST is actually one of the best vendors with great upstream track record
<Xogium>
argh boot loops suck
<marex>
what's the problem ?
<marex>
I tried to use WILC3000 from Microchip ... oh, oops, forgot to mainline their 100-strong wall of downstream patches
<marex>
NXP, well ... there is room for improvement too
<Xogium>
marex: hmm true, but at least they are attempting
<Xogium>
as for microchip I was more like talking about the sama5
<marex>
wasnt the sama5 actually OKish ?
<Xogium>
yeah
<marex>
the WILC wifi ... urgh ... horrid
<Xogium>
that's what I meant, they mainlined it good, at least as far as I can recall
<hanetzer>
to be fair, wifi in general is fairly cursed.
<Xogium>
horrible as the rx819 xradio chip in some orange pi ? Hah
<Xogium>
the driver is so horrible that even icenowy refused to work on trying to mainline it
<Xogium>
in fact the hardware is also so buggy that the driver can somehow manage to completely lock up your system verry sloooooowly just so you have time to see everything crashing down
<Xogium>
but yep, wifi being cursed is a the truth
<Xogium>
I have wifi based on brcm43430 and another brcm chip, and for some totally weird reason my ubiquiti AP more than dislikes those and they keep disconnecting no matter what settings I attempt to tweak
<marex>
Xogium: how can SPI WiFi chip lock up your system ? :)
<Xogium>
on 4 different devices that use those brcm chips, so its not just an issue with one of them or the firmware it carries
<marex>
Xogium: so the firmware starts radiating evil waves and flips some bits in CPU caches ?
<Xogium>
marex: that... Hum
<Xogium>
let me find the explanation again
<marex>
it's like a portable Death Ray :)
<Xogium>
The firmware running on the xr819 is very crash happy and the driver is a bit stupid. For example the driver can get confused about how many packets of data the xr819 has for it to read and can try to read too many. The firmware on the xr819 responds by triggering an assert and shutting down. The driver gets a packet that tells it that the firmware is dead and shuts down the thread used to push and pull
<Xogium>
data but the rest of the driver and the os has no idea and if the os tries to interact with the driver everything starts to lock up.
<marex>
so buggy downstream kernel driver?
<Xogium>
yup
<Xogium>
and buggy never mainline port that you can try to run on mainline if that amuses you
<Xogium>
which I tried for 5 minutes, which was the amount of time it took to start locking up. It took over 15 minutes for everything to be so frozen that the watchdog reset the board. First thing to go down was uart
<Xogium>
:D
c1728p91 has joined #armlinux
<marex>
Xogium: I was hoping the wifi was radiating some sort of CPU death ray, would've been much cooler tbh
<Xogium>
hehehe
<Xogium>
yeah
<Xogium>
a ray that drills holes into your cpu... Oh wait, there are already holes in that... Lets make more ! Muahaha
c1728p9 has quit [Ping timeout: 264 seconds]
amitk has quit [Ping timeout: 244 seconds]
jlinton has joined #armlinux
apritzel_ has joined #armlinux
jlinton has quit [Quit: Client closed]
jlinton has joined #armlinux
c1728p92 has joined #armlinux
sudeepholla_ has quit [Ping timeout: 240 seconds]
c1728p91 has quit [Ping timeout: 255 seconds]
sudeepholla_ has joined #armlinux
djrscally has joined #armlinux
headless has quit [Quit: Konversation terminated!]