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
tlwoerner has quit [*.net *.split]
snalty_ has quit [*.net *.split]
luispm has quit [*.net *.split]
TheCoffeMaker has quit [*.net *.split]
mcfrdy has quit [*.net *.split]
cambrian_invader has quit [*.net *.split]
ex-parrot has quit [*.net *.split]
mupuf has quit [*.net *.split]
dormito has quit [*.net *.split]
luispm has joined #armlinux
tlwoerner has joined #armlinux
snalty has joined #armlinux
cambrian_invader has joined #armlinux
mcfrdy has joined #armlinux
TheCoffeMaker has joined #armlinux
dormito has joined #armlinux
ex-parrot has joined #armlinux
mupuf has joined #armlinux
smoothdev has joined #armlinux
elastic_dog has quit [Ping timeout: 240 seconds]
elastic_dog has joined #armlinux
heat_ has joined #armlinux
heat has quit [Read error: Connection reset by peer]
heat_ has quit [Read error: Connection reset by peer]
heat has joined #armlinux
jclsn has quit [Ping timeout: 255 seconds]
jclsn has joined #armlinux
elastic_dog has quit [Ping timeout: 264 seconds]
elastic_dog has joined #armlinux
monstr has joined #armlinux
heat has quit [Ping timeout: 240 seconds]
Norkle has quit [Server closed connection]
Norkle has joined #armlinux
sukrutb has joined #armlinux
xvmt has quit [Remote host closed the connection]
xvmt has joined #armlinux
<javierm>
arnd: that "depends on IPV6 >= WIREGUARD" that Masahiro-san shared made my head to explode, didn't ever think about using tristate Kconfig symbols like that
<javierm>
but also I believe that relying in the implementation details of Kconfig may be fragile
hanetzer has quit [Ping timeout: 246 seconds]
hanetzer has joined #armlinux
<arnd>
I think it was nico's idea to add the > and < operators to Kconfig, I never liked them at all. Not really any worse than the ternary ! operators, but that one at least does the intuitive thing most of the time
<javierm>
arnd: yes, I wasn't aware that those operators were supported
monstr has quit [Ping timeout: 240 seconds]
monstr has joined #armlinux
smoothdev has quit [Quit: smoothdev]
smoothdev has joined #armlinux
headless has joined #armlinux
monstr has quit [Ping timeout: 264 seconds]
luispm has quit [Ping timeout: 246 seconds]
prabhakarlad has joined #armlinux
hanetzer has quit [Ping timeout: 240 seconds]
hanetzer has joined #armlinux
nsaenz_ has joined #armlinux
nsaenz_ has quit [Remote host closed the connection]
nsaenz_ has joined #armlinux
prabhakarlad has quit [Quit: Client closed]
vup has quit [Ping timeout: 258 seconds]
vup has joined #armlinux
headless has quit [Quit: Konversation terminated!]
sszy has joined #armlinux
smoothdev has quit [Quit: smoothdev]
smoothdev has joined #armlinux
hanetzer has quit [Ping timeout: 264 seconds]
smoothdev has quit [Client Quit]
luispm has joined #armlinux
smoothdev has joined #armlinux
sukrutb has quit [Quit: Leaving]
sakman_ has joined #armlinux
sakman has quit [Ping timeout: 245 seconds]
hanetzer has joined #armlinux
heat has joined #armlinux
prabhakarlad has joined #armlinux
sakman_ is now known as sakman
hanetzer has quit [Ping timeout: 244 seconds]
mwalle has quit [Ping timeout: 245 seconds]
hanetzer has joined #armlinux
prabhakarlad has quit [Quit: Client closed]
nsaenz_ has quit [Remote host closed the connection]
hanetzer has quit [Ping timeout: 264 seconds]
Amit_T has joined #armlinux
hanetzer has joined #armlinux
prabhakarlad has joined #armlinux
hanetzer has quit [Ping timeout: 244 seconds]
nsaenz has joined #armlinux
nsaenz has quit [Remote host closed the connection]
prabhakarlad has quit [Quit: Client closed]
<Xogium>
hmm how does one figure out what is prevening boot up in the case of, huh... Linux doing something like this
<Xogium>
basically lots and lots of defered probing and then watchdog just kicks in and the board gets reset
<Xogium>
fwiw I'm trying to port a board to the vendor kernel... Or more like the vendor above that vendor. Seeed studio made a board and their code's basically huh I'll remain polite and stick to the word crappy. So I'm trying to port the hardware to st's latest kernel
prabhakarlad has joined #armlinux
prabhakarlad has quit [Client Quit]
hanetzer has joined #armlinux
hanetzer has quit [Ping timeout: 240 seconds]
jeeeun82 has joined #armlinux
jeeeun8 has quit [Ping timeout: 255 seconds]
jeeeun82 is now known as jeeeun8
nsaenz has joined #armlinux
<arnd>
Xogium: most likely you're missing the clk or irqchip driver, or it failed to probe for some reason
<Xogium>
mmmh
<Xogium>
arnd: if I share with you the dt I've currently gotten, do you think you could give a hand with this ? This is stm32mp13 based so all compoentns should definitely be there...
<arnd>
Xogium: maybe try to raise the console debug level to get a little more output first, usually there is an error message if the base driver fails to load
<Xogium>
oh I've set to debug already and added earlycon
<Xogium>
but I'm not sure which clock I should be checkng for, or irq
<Xogium>
*checking
<arnd>
I think it has to be drivers/clk/stm32/clk-stm32mp13.c -- if it was the irqchip driver, you'd not even get this far
<robmur01>
turning on the dev_dbg print in dev_err_probe() might be informative
<arnd>
ah, and the driver is enabled unconditionally when MACH_STM32MP13, so it can't be a missing driver either
nsaenz has quit [Remote host closed the connection]
<Xogium>
robmur01: how do I do this, is this a menuconfig setting ?
<robmur01>
if you have CONFIG_DYNAMIC_DEBUG enabled you can use the "dyndbg=..." command-line runes
<Xogium>
fwiw I'm actually quite glad I've got uart output. This board has no jtag. Or rather, it has only solder pads for jtag
<robmur01>
otherwise I'd just smash a "#define DEBUG 1" right at the top of drivers/base/core.c :)
<arnd>
Xogium: I'd also add a printk() at the start and end of stm32mp1_rcc_clocks_probe() to see if it gets called, and what it returns
<Xogium>
I don't have that config enabled, but I could enable it
<Xogium>
or do that define trick
<Xogium>
I'm not surprised it's a bit rocky to port it... Seeed did an awful job with this board on the software side. Like, say, enabling pka and saes because they literally copied the dt of the stm32mp135f-dk from st and tweaked it to suit their board. There's just one problem: stm32mp135d doesn't support secure boot nor has it a hw crypto engine
<Xogium>
so I've had to do a massive cleanup
<Xogium>
I'm gonna go with some printk and that #define, see what that says
<Xogium>
thanks for the suggestion, will let you know what is going on and hopefully be able to fix it
<Xogium>
btw I assume just in case, to not make a dumb mistake, that for nfs rootfs and ip=dhcp one needs the ethernet driver built-in, correct ?
nsaenz has joined #armlinux
<Xogium>
that's how I've got them currently, but
<robmur01>
IMO built-in is always easier than faffing with initramfs anyway :)
<Xogium>
oh yes I always build everything critical as not a module
<Xogium>
anything being a module isn't critical. Like usb ;)
nsaenz has quit [Remote host closed the connection]
<robher>
ardb: I've been on some of that, but haven't really been paying attention...
<Xogium>
arnd: the good news is that it does get probed. I might have badly done the printk however because it returne something that doesn't make sense to me
<Xogium>
arnd: I came up with this, but I probably used the wrong type for printk
<geertu>
IIRC, marex had some "grewat" experiences with that...
<geertu>
marex: ^
<Xogium>
btw if it's relevant, my boot chain is this
<Xogium>
tf-a -> optee -> u-boot -> kernel
<geertu>
Xogium: In that case your kernel image might just miss the arm_scmi driver?
<Xogium>
could be
<Xogium>
I'm using the multi_v7_defconfig
<geertu>
And let's hope your firmware has the correct scmi code version...
<Xogium>
it should have, given I'm using the correct version of all components
<geertu>
CONFIG_ARM_SCMI_PROTOCOL=y?
<Xogium>
let me check
<Xogium>
yeah I have that
<robmur01>
and also the relevant drivers for the actual services, e.g. CONFIG_COMMON_CLOCK_SCMI, of course
<Xogium>
checking all of this, slow progress
<robmur01>
if in doubt, just enable everything with "SCMI" in the name, that's my approach :)
<Xogium>
:D
heat has quit [Remote host closed the connection]
heat has joined #armlinux
nsaenz has joined #armlinux
<Xogium>
I can't find anything wrong with arm_scmi nor with common_clk_scmi
<Xogium>
as in they are all enabled
<Xogium>
I'd think a multi_v7_defconfig should be plenty generic so that it runs on all platforms by default ?
<Xogium>
though here's something that might, just might be relevant. When updating from 3.16 to 3.19 optee, st removed all reference to sram including scmi_sram from the dt. I wasn't able to figure out what replaced that, and simply removed the sram dt nodes
<Xogium>
so for all I know I messed up something on the optee side
<Xogium>
kinda wish st had an irc channel :/
<robmur01>
ah, indeed, in that case I'd look for signs of the transport layer being unhappy (which might entail some more printk()s)
<Xogium>
damn, porting hardware is difficult :p I'm lucky no custom drivers were involved at all
<milkylainen>
Xogium: remember all the swearwords I used when I was dealing with this? :)
<Xogium>
seeed just made a 3.16 optee release but it's all wrong, like, they didn't even add their board as a flavor for stm32mp13 platform, and they once again copied the stm32mp135f to use it while not even taking care to remove irrelevant or problematic things like saes and pka
<Xogium>
milkylainen: I remember some ;p
<Xogium>
so I'm porting that over and on top of it all bumping to a newer release
<Xogium>
which means trouble
<milkylainen>
yeah. outside the treaded path means instant catastrophy. It's not just minor issues. It always breaks in the most strange ways.
<milkylainen>
I'm glad I don't have to force a stm32mp1x sideways anymore. :P
nsaenz has quit [Read error: Connection reset by peer]
nsaenz has joined #armlinux
<Xogium>
well, what started this is, it turns out the board has no saes obviously as its mp135d. So I removed that dt node alone with pka. Optee blew up because it still tried to use the key manager and now had no way to use it at all. It was blowing up before but... Turns out it's a bug which has gotten fix since. So I went like, hey let's move to 3.19...
<Xogium>
I don't mind st but I sure as hell mind seeed
<Xogium>
fun fact: st at least has doc. Seeed has no doc at all, and not one single reference image to try out your hardware on to even know if it works when you receive it
<milkylainen>
Agreed there. ST is pretty good at online docs.
<Xogium>
it's actually thanks to their doc I've gotten this far
luispm has joined #armlinux
<Xogium>
I was thinking seeed might have doc in chinese relating to that board. Not one word. There's one single forum thread about the odyssey mp135d which was asking where the device tree source was located
<Xogium>
they claim buildroot and OE support, and there's nothing
<Xogium>
I think they spent all their money on making the hardware actually nice and a cool schematics ;)
<milkylainen>
:)
hanetzer has joined #armlinux
nsaenz has quit [Remote host closed the connection]
cbeznea_ has quit [Ping timeout: 245 seconds]
cbeznea has joined #armlinux
headless has joined #armlinux
nsaenz has joined #armlinux
nsaenz has quit [Read error: Connection reset by peer]
<Xogium>
robmur01, milkylainen, arnd: I found part of my issue. It turns out I must have done a wrong thing when I enabled optee support in kernel and tee was enabled but optee ended up not being enabled. I just hadn't noticed. I'm getting really close
<Xogium>
not sure why it defers the mmc and eth2 and such just yet, and also not sure why it's basically annoyed at the nfs thing and somehow not finding rootfs ? Hmm
<Xogium>
maybe I forgot something but I don't think I did... First time I try nfs rootfs
<milkylainen>
do you have to specify the nfs version?
<milkylainen>
I never use nfs. :P
<Xogium>
I'm not sure
<Xogium>
possibly ?
<milkylainen>
I don't know what nfs uses as default nowdays and what's the default supported version in various distros.
<Xogium>
I use nfsv3
<Xogium>
that much I know
<milkylainen>
I think you can explicitly set version on the cmdline.
rockosov has quit [Quit: WeeChat 3.4-dev]
<geertu>
modern nfs servers (e.g. Ubuntu) need ",tcp,v3" appended
<Xogium>
hmm you mean in the cmdline ? Where do I append it to, exactly ?
<Xogium>
is it normal you think that it defers devices so late during boot ? It kind of bothers me
* headless
also remembers troubles w/nfs
<Xogium>
headless: haha yes
<headless>
not sure about tcp but v3 helped
<headless>
it's all vague now...
<Xogium>
holy damn it works ! ... sort of. I still have defered devices
Amit_T has quit [Quit: Leaving]
cbeznea has quit [Ping timeout: 244 seconds]
<milkylainen>
Xogium: glad version numbers worked.
<Xogium>
aye... Now another spot of trouble, because the trouble never finishes around here
<milkylainen>
It's kinda stupid if you ask me.
<milkylainen>
(setting protocol versions like that)
<Xogium>
creating directories or files over nfs returns permission denied. Running the rootfs in systemd-nspawn, as in chrooting into it and manually running seedrng which was what failed worked just fine
<Xogium>
well it's not just the version. actually the issue was tcp
<Xogium>
but I enabled udp so u-boot would be happy
heat has quit [Ping timeout: 246 seconds]
heat has joined #armlinux
<Xogium>
yeah m'kay I still have these to fix. I'm guessing clock or regulator issue
<Xogium>
but I figured out my nfs issue, I had missing stuff in the exports
smoothdev has quit [Quit: smoothdev]
* marex
reads backlog ... I wish I could un-read that
<marex>
Xogium: ah, stm32mp13 ? I had the singular worst experience with that platform due to that scmi crud they forced onto everyone for no good reason
<marex>
that platform, in my opinion, if it doesn't make that scmi baggage optional, is an Edsel