Post AvfB35D72X3DGC90Fc by mntmn@mastodon.social
(DIR) More posts by mntmn@mastodon.social
(DIR) Post #AvfB3370qEz0khH6Su by mntmn@mastodon.social
2025-06-30T15:57:13Z
0 likes, 0 repeats
i'm working on trying to find out what's preventing proper poweroff (that would call into our reform2_lpc driver to actually shut down the power rails) in our linux 6.15 kernel for rk3588. i'm gonna append to this thread as i try things.the first thing i considered is trying out JTAG/SWD but i haven't done that yet on RK3588, even if the pins look convenient (there are some on UART2 and some on SD card pins). i read that SWD gets disabled by uboot or linux so i'd have to solve that first...
(DIR) Post #AvfB342ROiv7co8xyi by mntmn@mastodon.social
2025-06-30T15:58:39Z
0 likes, 0 repeats
... so not to lose too much time, i'm gonna first try remote kgdb debugging. i'll check if kgdboe (still) works nowadays, and if not, will resort to UART. the first thing is to drop an extlinux.conf with all the kernel parameters, and disabling all CPUs except one (maxcpus=0)
(DIR) Post #AvfB35D72X3DGC90Fc by mntmn@mastodon.social
2025-06-30T16:03:13Z
0 likes, 0 repeats
debian kernel doesn't seem to have KGDB support, so i built a monolithic kernel with all necessary modules compiled in (so i don't need to copy modules around and can iterate faster). i use the extracted debian kernel package source with our patches applied and a special .config that i have for this purpose.
(DIR) Post #AvfB368tZhGu9PB9Jg by mntmn@mastodon.social
2025-06-30T16:07:55Z
0 likes, 0 repeats
boots a lot slower with only 1 cpu core!
(DIR) Post #AvfB36wsZrFoeQZ4E4 by mntmn@mastodon.social
2025-06-30T16:43:18Z
0 likes, 0 repeats
strangely, ethernet doesn't work on the monolithic kernel (no link). using usb ethernet as a workaround
(DIR) Post #AvfB37XOO6SeTfeE8e by mntmn@mastodon.social
2025-06-30T17:03:31Z
0 likes, 0 repeats
machine is prepared insofar that i have stable ssh remote access, and serial console login, and graphical login is turned off. i can build kernel modules on the machine. strangely, reform2_lpc reports a garbage byte at the end of the firmware string now (0xff)
(DIR) Post #AvfB38JFWAk4s62RjU by mntmn@mastodon.social
2025-06-30T17:23:59Z
0 likes, 0 repeats
the 0xff is some artifact of how i'm building and loading the module, fixed this by explicitly clearing the buffer for lpc responses. over serial i can see that lpc_power_off is indeed called when registered properly, _but_ it also crashes when trying to send the actual command! (all output lines are doubled because i use keep_bootcon for the serial output)
(DIR) Post #AvfB38t3N3Nkf8n2XY by mntmn@mastodon.social
2025-06-30T17:38:02Z
1 likes, 0 repeats
i don't need remote gdb to find the problematic line, because gdb can just load the module on the machine and i can enter `l *lpc_command+0x40` (the offset from the Oops) to see the null pointer must be `device* dev` from `dev_get_drvdata()`.
(DIR) Post #AvfB39VL4i0UZshcDQ by mntmn@mastodon.social
2025-06-30T17:38:38Z
1 likes, 0 repeats
indeed i messed something up here, because `poweroff_device` is some leftover thing from the old code before i converted it to a proper sys_off handler.
(DIR) Post #AvfB42mFZXDM0G2Oi8 by grimmware@chaos.social
2025-06-30T16:00:39Z
1 likes, 0 repeats
@mntmn quicker and easier suggestion: