<apritzel>
in particular we miss the PSCI version call, so just return -1 there, and the kernel translates this accordingly
<jkm>
CONFIG_SUN20I_D1_CCU=y
<jkm>
apritzel: I see
kuba2k3 has joined #linux-sunxi
<apritzel>
but don't worry, the PSCI version is mostly cosmetic at this point
<apritzel>
(I guess we need to update our PSCI implementation at some point, but it's not a showstopper)
<apritzel>
jkm: and I guess you have CONFIG_PINCTRL_SUN20I_D1 as well?
<jkm>
yep
Net147 has quit [Quit: Quit]
<apritzel>
(just asking, because you said SUN8I options, but we borrow quite a lot from the D1 code)
<jkm>
yes, I am aware that we CCU is mostly borrowed from D1
Net147 has joined #linux-sunxi
Net147 has quit [Remote host closed the connection]
<apritzel>
you could try adding initcall_debug, to see if that gives you a clue
<jkm>
I wonder why on 6.6.3 cma reserves 64 MiB from 0x43800000
Net147 has joined #linux-sunxi
<jkm>
and on 6.1.54 from 0x44000000
<jkm>
I will add memory node in dt
<apritzel>
no, that's wrong
<apritzel>
U-Boot does that, and U-Boot knows best
<apritzel>
you should drop the cma=64M from the kernel command line
<apritzel>
or you boot with some initrd which gives you a shell prompt, and then check out /sys/kernel/debug/devices_deferred
<jkm>
ack
<jkm>
will test
kuba2k2 has quit [Ping timeout: 480 seconds]
<apritzel>
my hunch is that it's one driver missing in your .config. My favourite example is CONFIG_REGULATOR_FIXED_VOLTAGE, which is absolutely essential, but sometimes missed in custom configs
kuba2k3 has quit [Ping timeout: 480 seconds]
<jkm>
CONFIG_REGULATOR_FIXED_VOLTAGE=y
<apritzel>
jkm: what is your DT, exactly? the one from mainline kernel or U-Boot? Did you use $fdtcontroladdr? That should give you the right one automatically
<jkm>
apritzel: I use ${fdtfile} which is sun8i-t113s-mangopi-mq-r-t113.dtb from Linux
<jkm>
anyway, I could stick to 6.1.54, but I *would like* to use 6.6.y :D
<jkm>
oh, I can see that I have "memory { reg = <0x40000000 0x8000000>; };" in sunxi-6.1.y.patch
<jkm>
and that is missing on 6.6.y I guess...
JohnDoe_71Rus has quit []
gsz has quit [Quit: leaving]
<jkm>
apritzel: "cma: Reserved 64 MiB at 0x43800000 on node -1" <= what is node -1? :P
norton has joined #linux-sunxi
Net147 has quit [Read error: Connection reset by peer]
Net147 has joined #linux-sunxi
Daanct12 has quit [Quit: WeeChat 4.1.1]
warpme has quit []
warpme has joined #linux-sunxi
<apritzel>
jkm: the memory node doesn't belong into the .dts *file*, because it's added dynamically by the bootloader, U-Boot in this case
<apritzel>
jkm: and please don't give up and use the 6.1 kernel, this won't solve your problem
<apritzel>
regarding $fdtfile: you don't need to load anything, because U-Boot carries the same DT already, in memory, and this is what $fdtcontroladdr points to
<jkm>
apritzel: oh, I didn't know that, that's preatty neat
<apritzel>
so instead of loading something to $fdt_addr_r, you just give $fdtcontroladdr on the bootz (or bootm) commandline
<jkm>
range 0x42000000..0x420fffff is used by dsp0 AFAIK
<jkm>
but not sure...
<jkm>
at least now I can see bootlog until usbcore, so there is *some* progress :D
Advancel has joined #linux-sunxi
kuba2k2 has joined #linux-sunxi
<jkm>
apritzel: please let me know if you are able to boot 6.6.y on T113-S3
<apritzel>
I think I see the same problem
<jkm>
you got any clue?
<apritzel>
it somewhat works with 6.1.64 (although init crashes, but I count this as success), but doesn't with 6.5 or 6.6
<apritzel>
all same mainline U-Boot and using the same DT (from U-Boot)
<jkm>
yes, same here
<jkm>
6.1.y works, 6.6.y does NOT
<apritzel>
there was CONFIG_SUN20I_PPU missing from sunxi_defconfig, but that's not it
<jkm>
I have it disabled in 6.6.y .config too
<apritzel>
I think it's not used (yet) in the DT ...
<jkm>
But if you're saying that's not it I'm not even rebuiling
<apritzel>
I see it now hanging exactly after a timestamp, which smells like something is turned off: a regulator or a clock
<apritzel>
let me try clk_ignore_unused ...
junari has joined #linux-sunxi
vagrantc has joined #linux-sunxi
warpme has quit []
warpme has joined #linux-sunxi
jkm has quit [Quit: leaving]
jkm has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
warpme has quit []
warpme has joined #linux-sunxi
kuba2k2 has quit [Ping timeout: 480 seconds]
warpme has quit []
mripard has quit [Quit: mripard]
warpme has joined #linux-sunxi
warpme has quit []
<apritzel>
jkm: so I tried quite some things, nothing is really a clue yet: initcall_debug showed some driver stuck in EPROBE_DEFER, but disabling them didn't change anything
junari has quit [Ping timeout: 480 seconds]
vagrantc has quit [Quit: leaving]
<apritzel>
I guess the system just stops at some point, and they don't get a chance to probe again before
<jkm>
apritzel: I see, thanks anyway
<apritzel>
removing the watchdogs for the DT didn't help as well
<apritzel>
I tried different kernel versions: 6.2 did still work, 6.3 didn't
<apritzel>
so we might just bisect between those two revisions, but I can't do this before Monday (need a proper machine for that)
<jkm>
sure, I'll try a few things over the weekend
<apritzel>
I also tried disabling PSCI, or removing the 2nd core, but that didn't help as well
norton has quit [Quit: WeeChat 4.1.1]
<Jookia>
oh no, upstream bug bisect time?
<jkm>
seems that way
<apritzel>
well, there are probably smarter methods, but at least bisecting is mostly a matter of diligence, so it's quite powerful
<Jookia>
the smartest method of all is probably JTAG or kdb i guess
evgeny_boger1 has quit [Read error: No route to host]
evgeny_boger has joined #linux-sunxi
<apritzel>
it's look like more of a highlevel kernel issue, so not so sure those things help easily
<apritzel>
so yeah, 6.3-rc1 is "bad", 6.2 is "good", with sunxi_defconfig and mainline U-Boot, using $fdtcontroladdr: be my guest ;-)
<apritzel>
mmh, we got the ARM clocks only in v6.3, so this "works <= 6.2" part might be wishful thinking (I saw it actually crashing in /init, assuming it would be my initrd at fault)
apritzel has quit [Ping timeout: 480 seconds]
<jernej>
jkm: apritzel: note that specifying cma as kernel argument has a drawback - it skips location limit posed by DT. This was the issue found ndufresne when testing cedrus on A20 (cedrus can access only certain memory locations there)
Advancel has quit []
<jernej>
but I guess T113 doesn't have such limitations
vagrantc has joined #linux-sunxi
machinehum1 has joined #linux-sunxi
machinehum has quit [Ping timeout: 480 seconds]
warpme has quit []
warpme has joined #linux-sunxi
machinehum1 has quit []
warpme has quit []
evgeny_boger has joined #linux-sunxi
evgeny_boger has quit [Ping timeout: 480 seconds]
JohnDoe_71Rus has quit []
warpme has joined #linux-sunxi
warpme has quit []
evgeny_boger has joined #linux-sunxi
norton has joined #linux-sunxi
kuba2k2 has joined #linux-sunxi
<jkm>
apritzel: apparently I can't bring up secondary CPU on 6.6.3...
ftg has joined #linux-sunxi
kuba2k2 has quit []
<jkm>
I guess this is PSCI related...
<jkm>
fex firmware | enable-method = "psci" | linux-6.6.3 => 1 CPU up in SVC mode
fraolt has joined #linux-sunxi
obbardc has joined #linux-sunxi
<jkm>
after fighting with this issue for several hours more, I came to the conclusion that importing *anything* from RISC-V DT to ARM DT is a *really* terrible idea...
<jkm>
there should be an arch agnostic place for peripherals-related DT nodes (maybe there is one already?)