add support for Teres I DIY laptop kit

[jonassmedegaard]

Type of issue

Feature Request

Description

Would be great to have Crust include a defconfig file for the Teres I DIY laptop.

I own such laptop and can help test, but am not skilled enough to figure out on my own how the schematics of the laptop mainboard corresponds to Crust configuration.

I can compile both Crust and u-boot (I am the package maintainer of Crust in Debian). I have so far tried use the Crust build for Pinebook but I fail to wakeup the system after it has fallen asleep.

[smaeul]

The TERES-I has the same PMIC and voltage regulator allocation as practically every other A64 board, so the only configuration needed is selecting CONFIG_MFD_AXP20X. For reference, I'm comparing the schematic to the constants in regulator_list.c.

This is the same hardware configuration as the Pinebook, so the Pinebook firmware should work as-is. The Pinebook defconfig disables the serial console for additional power saving, but that is not necessary for basic functionality. In fact, enabling CONFIG_SERIAL and CONFIG_DEBUG_LOG would probably be helpful for the moment. Crust will share UART0 with Linux.

The most likely issue is with your kernel. What version of Linux are your running, and have you applied any patches? Try booting with the clk_ignore_unused kernel command line option, and see if that fixes things. If it does, great! You can:

• keep using that option,
• apply the first and fifth patches from the crust-minimal branch here, or
• change the 0 in the apb0-twd clock description to a CLK_IGNORE_UNUSED.

If that doesn't fix your resume issues, please paste the serial console output from a suspend/resume attempt, ideally with debug logging enabled.

[jonassmedegaard]

My TERES-I survives a wakeup with kernel option clk_ignore_unused. Thanks!

I run Debian testing on the TERES-I, which means the kernel used is currently 5.14.6, Debian revision 2 with [these] patches applied.

Would it still be helpful that I try get a serial port working on my TERES-I (a bit tricky but I think I succeeded with that before), or is my current succes enough of an indication of what the failure before was caused by?

Is your kernel patchset in the process of getting merged into mainline? I am asking because ideal for me (and others as well) would be to get this working out of the box in Debian, and I know that the kernel team in Debian would much prefer to keep the pile of custom patches to a minimum.

[smaeul]

No, a serial port is not needed, since you got resume working.

I have tried sending the patches upstream a couple of times, but each time was asked to re-implement the functionality in a different way. The most recent attempt, at the branch I linked above, was rejected with the only explanation being "because it looks wrong at first glance" (and that feedback was a month later and not even sent to me). So this issue has been a low priority for me.

The way to get the smallest out-of-tree patch would be my third suggestion (change the 0 in the apb0-twd clock description to a CLK_IGNORE_UNUSED). I should push that instead of the current series, since it is a better short-term solution. I have also considered adding a workaround inside crust, but it would be rather ugly, and Linux is the one doing the wrong thing here.

[jonassmedegaard]

Thanks for clarifying that I need not fumble with serial port.

I recognize the frustration of getting patches approved - I've experienced it with a TERES-I USB keyboard fix for u-boot which took "forever" to get approved and required several rounds of rewrite (not pointing fingers, though: I am sure my limited skills was ultimately the cause - just saying I recognize the frustration of slow processing).

Perhaps sending a gently email to Stephen Boyd encouraging him to share his concerns for your patch series at the appropriate thread might help progress?

If a smaller patch is possible short term then that might be sensible - but since I don't understand the technical details here and don't know the reason the larger generic patchset hasn't been accepted I am obviously only guessing blindly here.

If not too much work to provide a workaround in Crust itself, then I would appreciate that, to be able to use Crust with mainline kernels, without needing to add custom patches. Perhaps provide it behind a KConfig option default disabled, and its explanation pointing to the issue with the kernel, so as to raising the likelihood of your users getting informed about the underlying issue if they enable that workaround?