warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
ukky has joined #u-boot
sszy has joined #u-boot
Guest68 has quit [Quit: Client closed]
warpme has joined #u-boot
frieder has quit [Ping timeout: 260 seconds]
frieder has joined #u-boot
Guest26 has joined #u-boot
abws has quit [Ping timeout: 252 seconds]
mrkiko has joined #u-boot
<mrkiko>
Hello All! And thank you for your work and patience. I am trying to port an mt7981 board to u-boot. I got most of what I needed working, except for a watchdog connected over gpio. while all other components like gpio leds and other stuff seem working fine, i get a "request failed" error message from the wdt-gpio driver. Any hint?
<mrkiko>
In other terms, when I invoked things like led commands and so on, what happens is that u-boot function uclass_find_device_by_ofnode - found in drivers/core/uclass.c, finds mediatek_gpio, registered by pinctrl mtk common driver. This does not happen in the wdt-gpio case still, and uclass_get_device_by_ofnode fails.
<mrkiko>
Thanks for your patience and help
<marex>
Request for wdt gpio failed: %d ? What is the error code ?
<mrkiko>
oh I forgot - using 2024.10
<mrkiko>
marex: -19
<marex>
run some dm_dump_tree() afterward and see if the gpio controller probed (or what did get probed and what did not)
<marex>
that might give you some suggestions
Guest26 has quit [Quit: Client closed]
<mrkiko>
marex: thanks a lot
<mrkiko>
marex: however, in all other cases I see the device being searched for is named "mediatek_gpio", in that one case dev->name is NULL.
<mrkiko>
Should still pass that dev instance to dm_dump-tree ?
<mrkiko>
or is this alone an indication something is going wrong earlier
<marex>
I think if you pass NULL or dm_root() or somethng, it will travers the whole tree
<mrkiko>
OK
<mrkiko>
thanks
<marex>
see cmd/dm.c , there is an example of it ... it matches "=> dm tree" on U-Boot command line
monstr has joined #u-boot
<mrkiko>
marex: ok, pinctrl not ready tet
<mrkiko>
sorry
<mrkiko>
s/tet/yet/
<marex>
do you maybe need some bootph- flag in DT if this probes early ?
<mrkiko>
marex: eheh, ok - going to read the docs, I don't know bootph stuff at all, even tough I see u-boot searching for them in dt
<mrkiko>
but ok, you helped me shade quite a lot of light on the issue
Guest27 has joined #u-boot
Guest27 has quit [Client Quit]
<mrkiko>
marex: any way I could use dts to define a parent device -> child device relationship ?
<mrkiko>
bootph- doesn't seem "elastic" enough here
<mrkiko>
Ok, I succeeded in obtaining the gpio wdt to start but to do so I needed to move down watchdog init in board_r.c; guess this approach is not acceptable
<mrkiko>
is there a more correct way?
<marex>
mrkiko: probably you need to add these bootph- properties into your -u-boot.dtsi
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<mrkiko>
marex: I trieddoing so, but I can not get the wdt to probe later enough as far as I can tell
<qschulz>
sf probe 0 0 0 followed by the sf update
<mrkiko>
marex: could you please oint me to the rleevant docs for that? I would be very grateful
abws has joined #u-boot
dsimic has quit [Ping timeout: 276 seconds]
dsimic has joined #u-boot
abws has quit [Remote host closed the connection]
flokli has quit [Quit: WeeChat 4.4.2]
flokli has joined #u-boot
<marex>
qschulz: sigh, clearly this got lost in all the other unrelated goo and top-posting
<marex>
mrkiko: doc/develop/driver-model/design.rst:drivers marked with DM_FLAG_PRE_RELOC or the device tree 'bootph-all'
<marex>
mrkiko: that is probably what you are looking for, the PRE_RELOC stuff
<marex>
qschulz: why do they use 0 Hz bus frequency ?!
<qschulz>
marex: don't want to get involved in that discussion, just wanted to say that it seems they have done **almost** what you asked them to (aside from the 0 0 0 for the sf probe command :) )
rber|res has quit [Remote host closed the connection]
<marex>
qschulz: I very much missed it, sigh
<qschulz>
marex: it happens :)
devarsh has quit [Quit: Connection closed for inactivity]
monstr has quit [Remote host closed the connection]
frieder has quit [Remote host closed the connection]
<mrkiko>
marex: thanks for the help
<marex>
mrkiko: did you find anything ?
<marex>
mrkiko: you can always plug some debug printf()s into drivers/core/device.c .... or #define DEBUG at the begining of that file to globally enable debug output
<marex>
then you might see what failed to bind/probe/was somehow missing
vagrantc has joined #u-boot
<mrkiko>
marex: thanks, yeah - I already sprinkled some printf around
<mrkiko>
marex: the problem I am facing is that evenmarking with bootph-all my pinctrl driver, it seems I am not able to get the probe order right and thus the watchdog driver never finds it's gpio
mmu_man has quit [Ping timeout: 252 seconds]
<marex>
mrkiko: is the gpios = <...> property in DT?
<mrkiko>
yes
<marex>
does it refer to a valid gpio controller (and that is probed) ?
<mrkiko>
it does, the problem is the controller is probed later
<marex>
check whether the DT that U-Boot is parsing is really the right one ... => fdt addr $fdtcontroladdr ; fdt print
<mrkiko>
this is mt7981-based system, hence mt7981 pinctrl is used
<marex>
hmmmm
mmu_man has joined #u-boot
<marex>
mrkiko: could it be that something prevents the controller from probing , some dependency ?
<mrkiko>
I anbled dm warning so I can see messages referring to the properties I set ... so i am confident I am parsing the right dt. And moving the call to initr_watchdog later in board_r.c fixes my issue indeed
<mrkiko>
mrkiko: it could be yes...
<marex>
that PRE_RELOC stuff might be involved
<marex>
I'll be back in a bit
<mrkiko>
marex: I marked the pinctrl dt section with bootph-all; but seems not effective atm
Jones42 has quit [Read error: Connection reset by peer]
fatal has quit [Remote host closed the connection]
fatal has joined #u-boot
warpme has joined #u-boot
<haritz>
is there a way to boot a 32 bit linux kernel from a 64 bit uboot build?
<haritz>
when I try to do it it complains about Bad Linux ARM64 Image magic!
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
pgreco has quit [Ping timeout: 244 seconds]
pgreco has joined #u-boot
<marex>
haritz: I think rpi can do something like that
<marex>
haritz: grep -i aarch32
<marex>
that should point out the code of interest
<marex>
I think it was added a while ago by nxp, so maybe LS can also use it ?
warpme has joined #u-boot
<marex>
mrkiko: are you by any chance playing around with the openwrt one ?
<mrkiko>
marex: not, but failry similar device. It's mt7981 - but a notable difference is that no way to disable the external gpio-connected watchdog is known
<mrkiko>
and my device has nor only, and a switch
<marex>
mrkiko: is that why you need to GPIO access so early, to ping the WDT ?
<mrkiko>
marex: well, I wouldn't need the ping so much early - the device gives me approx 30 s to ping the wdt. The problem is that the gpio watchdog fails to request the gpio if mtk pinctrl is not initialized at dm_probe time, and thus will never ping wdt again, leading of course to device resetting
<mrkiko>
marex: so n a sense - yes, that's why :)
<mrkiko>
marex: english isn't my native language, so in case my tone is bad, forgive me
<marex>
sjg1: ^ thoughts ?
<marex>
(on the ordering, why does pinctrl not get probed when gpio-wdt needs it?)
<marex>
mrkiko: I dont see anything obvious in the GPIO WDT driver
<mrkiko>
marex: if interested, I can share my dts with you btw
<mrkiko>
even tough the devie isn't "fully" public
<mrkiko>
so wuld prefer to share it in PM
<mrkiko>
would like to get full permission from manifacturer first, even tough I suppose I'll get it
<marex>
you could share the /watchdog {} node content, that should be enough
<marex>
I assume you have a /watchdog {} node for this ?
<haritz>
marex: thanks
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<mrkiko>
marex: find it in denx inbox
Stat_headcrabbed has quit [Quit: Stat_headcrabbed]
<marex>
mrkiko: is that on u-boot list or my mail (no news there)
<marex>
?
<mrkiko>
marex@denx.de
<marex>
if it is like 5 lines, better use some paste.debian.net so others have access too