-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
openSUSE 15.5 turns off on boot of RK3399-PC #2
Comments
I've just tried with the distro device tree and it also fails. This looks more like an openSUSE bug. |
Ok, I take that back. Same symptoms with Ubuntu 23.04. |
Ok, so the culprit is my dynamic voltage capable USB-C power supply. Something apparently wants to talk to it, reconfigure it, and while it does so, we lose power. |
Hey Alex, I have some patches that are not in right now. I'm currently working on RK3328 today and RK3399 tomorrow. I'll get back to you shortly on this. |
@agraf I reworked everything to use the latest stuff. I didn't enable any of the funny bits with FUSB302 (long history in upstream). Let me know if it works for you. https://github.com/libre-computer-project/libretech-u-boot/commits/v2023.04/roc-rk3399-pc
I will play with PD in the next few days to see what patches are needed upstream in Linux. Meanwhile, you can build roc-rk3399-pc-spiflash or grab it here: https://boot.libre.computer/ci/roc-rk3399-pc-spiflash |
@agraf I've tested a lot of distribution ISOs and the only one I got to work is Fedora. |
Hi Alex, I've isolated all of the issues with FUSB302 driver a few months ago and here are the patches necessary: After powering on the FUSB302 IC, you need to wait at least 200us for the STATUS0 register to reflect the actual hardware state. I've tried 100us and 150us and they were not long enough. Due to mid state transition from messages received from wait_capabilities, some capabilities were registered but the state machine goes to hard_reset without clearing these capabilities first, causing an error the next time they try to register. We detect the previous state of wait_cap and remove any half registered capabilities on hard_reset. set_pd_rx will flush queued PD messages when it is called by wait_capabilities. However, there is some time between request_caps and wait_capabilities state transition in tcpm so the messages are flushed by wait_capabilities as the power supply microcontroller sends the messages almost immediately. To compensate for this, flush only when we are turning RX off rather than every time we call set_pd_rx. TCPM assumes that the power supply was plugged in after Linux starts. The power supply send the PD messages upon plug detect. However as u-boot does not handle PD, it could be up to 30s or more before Linux starts causing the power supply to time out per spec. Linux jumps into wait_cap without ever requesting the power supply capabilities. We add a new TCPM state called request_caps where if wait_cap times out, we sent out a PD capabilities request so that the power supply can re-provide the information. Note, some power supplies will send a hard_reset if they timeout during negotiation anyway. You can successfully boot around 3/4 times on many Amazon power supplies I've tested. |
When I build roc-rk3399-pc-spiflash, the resulting U-Boot is able to load the kernel successfully. However, its device tree seems incompatible with the openSUSE 15.5 kernel. When I boot the installer iso, it prints messages up to this point:
After that, it powers off. Pressing the power button makes it boot up again:
Is this a device tree incompatibility? If so, should we update the device tree and/or the U-Boot branch to a more recent one?
The text was updated successfully, but these errors were encountered: