On Fri, Nov 08, 2024 at 01:46:03AM +0100, Michał Pecio wrote: > Hi, > > It came to my attention that Nvidia provides some degree of mainline > support for old Tegra SoCs, so I wanted to try it on my Acer CB5-311. Exciting! I think I do have one of those devices, though equipped with a Tegra132, so the 64-bit equivalent of Tegra124. > I checked out v6.11.5, applied tegra_defconfig and booted this kernel > with tegra124-nyan-big-fhd.dts from mainline, using CrOS bootloader. > > The kernel came up and userspace got to the login prompt, but then some > issues appeared: Okay, that's pretty good given that we haven't had testers for a few years now. > 1. Most importantly, the EC keyboard doesn't work, I had to use USB to > log in and see what's going on. Turns out, tegra_spi_set_hw_cs_timing() > rejects timings expressed in units other than clock cycles, while slave > drivers like cros_ec apparently prefer to specify us/ns. > > Searching around, I found I'm not the first one to run into this issue, > not only on Nyan, not only on T124. I got around it by disabling this > callback altogether, because SPI core apparently has a workaround. But > maybe it's preferable to fix it properly? I'm not sure what the right way is to fix this. The values in DT are clearly required to be nanoseconds, so either the driver needs to learn about those or the core would need to convert somehow. The core doesn't know about what the driver supports, so it can't do a really good job. Maybe a good compromise would be to have the core expose a helper that can convert to clock cycles (the reverse is already done in spi_delay_to_ns()), which drivers can then use if they only support clock cycles. I think that'd still be preferable over relying on the core's manual delaying. If we can make it work, obviously. > 2. I noticed that tegra_defconfig doesn't include LPAE. Tomorrow I will > see if full 4GB works. Maybe LPAE could be a default on 32 bits? I think LPAE cannot be enabled by default because it would break on Tegra20 and Tegra30 which both don't support LPAE. Tegra114 was the first to feature this (I think), so we'd need an extra LPAE config that's applicable only for newer chips. > 3. Some more warnings about bypassed regulators and missing touchpad > supply (but the touchpad is enabled and works, per evtest at least). Not sure how much can be done about this. Unless you can find the schematics we'd probably have to do this on a best effort basis. > 4. Doesn't come out of suspend. No idea what's wrong, how to debug it? My first step when debugging suspend/resume issues is usually to pass no_console_suspend on the kernel command-line. That's really only useful for debugging consoles and it probably doesn't work well if you've only got the framebuffer console. Other than that it might be possible to try and validate suspend/resume on a more "accessible" device (such as a Jetson TK1), fix any issues that might have and hope that also fixes Nyan. You may also want to play around with different suspend modes. Suspend to memory is usually easier to make work. Anything else might require assistance from the bootloader/firmware side (there's often a warmboot binary that needs to be executed when resuming from lower, or I guess higher depending on how you look at it, suspend modes). > 5. USB is power-cycled on boot, which is a bit annoying as I'm booting > from a USB connected disk. IIRC CrOS kernel 3.10 wasn't doing it. Any > suggestions where to look? Is this really the power going away and coming back up? In that case it might be a regulator that's being temporarily disabled during boot and then brought back up. It could also be a USB reset, which I think is something that's absolutely necessary in order for the kernel to be able to properly enumerate the devices. If it's a regulator it might be possible to mark it as always-on. What exactly are the side-effects of the power-cycle? Does it cause the USB device not to work at all, or does it stall the boot, or perhaps even break it (I assume not since you mentioned you can get to a login prompt). Let me know if you make any progress, or have any questions that I can help with. I have limited options since most of the devices from that era that I used to have access to have stopped working (or accumulated lots of dust at this point), but I'm happy to help if I can. Thierry
Attachment:
signature.asc
Description: PGP signature
