openSUSE 15.5 turns off on boot of RK3399-PC

[agraf]

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:

>>> openSUSE Leap 15.5 Beta installation program v7.0.32.4 (c) 1996-2020 SUSE LLC  <<<
Starting udev... [   21.449884][  T213] SCSI subsystem initialized
[   21.458219][  T213] alua: device handler registered
[   21.477317][  T216] emc: device handler registered
[   21.497038][  T217] rdac: device handler registered
[   23.870575][  T233] dw_wdt ff848000.watchdog: No valid TOPs array specified
[   23.888145][  T230] usbcore: registered new interface driver usbfs
[   23.888815][  T230] usbcore: registered new interface driver hub
[   23.889445][  T230] usbcore: registered new device driver usb
[   23.981326][  T248] Synopsys Designware Multimedia Card Interface Driver
[   23.995111][  T249] sdhci: Secure Digital Host Controller Interface driver
[   23.995736][  T249] sdhci: Copyright(c) Pierre Ossman
[   23.997522][  T230] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[   24.000340][  T238] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[   24.001065][  T238] Warning! ehci_hcd should always be loaded before uhci_hcd and ohci_hcd, not after
[   24.043727][  T238] ehci-platform: EHCI generic platform driver
[   24.068121][  T249] sdhci-pltfm: SDHCI platform and OF driver helper
[   24.161763][  T244] ohci-platform: OHCI generic platform driver
[   24.170035][  T251] vcc3v3_pcie: supplied by sys_12v
[   24.171035][  T227] input: gpio-keys as /devices/platform/gpio-keys/input/input0
[   24.174500][  T251] vcc3v3_sys: supplied by sys_12v
[   24.175830][  T251] vcc3v3_ngff: supplied by sys_12v
[   24.176946][  T251] vcc_sys: supplied by sys_12v
[   24.197627][    T7] vcc3v0_sd: supplied by vcc3v3_sys
[   24.201466][    T7] vcca_0v9: supplied by vcc3v3_sys
[   24.204471][    T7] vcc5v0_host: supplied by vcc_sys
[   24.207253][    T7] vcc_vbus_typec1: supplied by vcc_sys
[   24.210383][    T7] vcc_hub_en: supplied by vcc_sys
[   24.464554][  T234] cryptd: max_cpu_qlen set to 1000
[   24.719058][  T255] rockchip-vop ff8f0000.vop: Adding to iommu group 2
[   24.719715][  T255] iommu: Failed to allocate default IOMMU domain of type 4 for group (null) - Falling back to IOMMU_DOMAIN_DMA
[   24.721137][  T255] rockchip-vop ff900000.vop: Adding to iommu group 3
[   24.722801][  T255] iommu: Failed to allocate default IOMMU domain of type 4 for group (null) - Falling back to IOMMU_DOMAIN_DMA
[   24.742138][  T255] Console: switching to colour dummy device 80x25
[   24.749998][  T255] rockchip-drm display-subsystem: bound ff8f0000.vop (ops vop_component_ops [rockchipdrm])
[   24.751240][  T255] [drm] unsupported AFBC format[3231564e]
[   24.755935][  T255] rockchip-drm display-subsystem: bound ff900000.vop (ops vop_component_ops [rockchipdrm])
[   24.757106][  T255] dwhdmi-rockchip ff940000.hdmi: supply avdd-0v9 not found, using dummy regulator
[   24.758260][  T255] dwhdmi-rockchip ff940000.hdmi: supply avdd-1v8 not found, using dummy regulator
[   24.759496][  T255] dwhdmi-rockchip ff940000.hdmi: Detected HDMI TX controller v2.11a with HDCP (DWC HDMI 2.0 TX PHY)
[   24.764788][  T255] rockchip-drm display-subsystem: bound ff940000.hdmi (ops dw_hdmi_rockchip_ops [rockchipdrm])
[   24.769037][  T255] [drm] Initialized rockchip 1.0.0 20140818 for display-subsystem on minor 0
[   24.931234][  T255] Console: switching to colour frame buffer device 240x67
[   24.936099][  T228] dc_12v: supplied by regulator-dummy
[   24.983659][  T252] rk808 0-001b: chip id: 0x0
[   24.984978][  T255] rockchip-drm display-subsystem: [drm] fb0: rockchipdrmfb frame buffer device
[   24.994704][  T230] fan53555-regulator 0-0040: FAN53555 Option[8] Rev[1] Detected!
[   25.003274][  T230] vdd_cpu_b: supplied by vcc3v3_sys
[   25.003316][  T229] OF: graph: no port node found in /i2c@ff160000/usb-typec@22
[   25.027755][  T230] fan53555-regulator 0-0041: FAN53555 Option[8] Rev[1] Detected!
[   25.031033][  T230] vdd_gpu: supplied by vcc3v3_sys
[   25.035098][  T430] rockchip-pcie f8000000.pcie: host bridge /pcie@f8000000 ranges:
[   25.035827][  T430] rockchip-pcie f8000000.pcie:      MEM 0x00fa000000..0x00fbdfffff -> 0x00fa000000
[   25.036647][  T430] rockchip-pcie f8000000.pcie:       IO 0x00fbe00000..0x00fbefffff -> 0x00fbe00000
[   25.038191][  T430] rockchip-pcie f8000000.pcie: no vpcie12v regulator found
[   25.062797][  T229] OF: graph: no port node found in /i2c@ff3d0000/usb-typec@22
[   25.108910][  T430] ehci-platform fe380000.usb: EHCI Host Controller
[   25.109554][  T430] ehci-platform fe380000.usb: new USB bus registered, assigned bus number 1
[   25.110579][  T430] ehci-platform fe380000.usb: irq 35, io mem 0xfe380000
[   25.131464][  T227] Registered IR keymap rc-cec
[   25.132176][  T227] rc rc0: dw_hdmi as /devices/platform/ff940000.hdmi/rc/rc0
[   25.133126][  T227] input: dw_hdmi as /devices/platform/ff940000.hdmi/rc/rc0/input1
[   25.140681][  T430] ehci-platform fe380000.usb: USB 2.0 started, EHCI 1.00
[   25.141799][  T430] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 5.14
[   25.142611][  T430] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[   25.143321][  T430] usb usb1: Product: EHCI Host Controller
[   25.143831][  T430] usb usb1: Manufacturer: Linux 5.14.21-150500.49-default ehci_hcd
[   25.144529][  T430] usb usb1: SerialNumber: fe380000.usb
[   25.145739][  T246] rk808-regulator rk808-regulator: there is no dvs0 gpio
[   25.146041][  T430] hub 1-0:1.0: USB hub found
[   25.146444][  T246] rk808-regulator rk808-regulator: there is no dvs1 gpio
[   25.149684][  T430] hub 1-0:1.0: 1 port detected
[   25.155153][  T430] ehci-platform fe3c0000.usb: EHCI Host Controller
[   25.155789][  T430] ehci-platform fe3c0000.usb: new USB bus registered, assigned bus number 2
[   25.156758][  T430] ehci-platform fe3c0000.usb: irq 37, io mem 0xfe3c0000
[   25.180677][  T430] ehci-platform fe3c0000.usb: USB 2.0 started, EHCI 1.00
[   25.184510][  T430] usb usb2: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 5.14
[   25.185339][  T430] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[   25.186050][  T430] usb usb2: Product: EHCI Host Controller
[   25.186552][  T430] usb usb2: Manufacturer: Linux 5.14.21-150500.49-default ehci_hcd
[   25.187246][  T430] usb usb2: SerialNumber: fe3c0000.usb
[   25.191762][  T246] vdd_center: supplied by vcc3v3_sys
[   25.193903][  T246] vdd_cpu_l: supplied by vcc3v3_sys
[   25.194827][  T430] hub 2-0:1.0: USB hub found
[   25.195435][  T430] hub 2-0:1.0: 1 port detected
[   25.217580][  T246] vcc_ddr: supplied by vcc3v3_sys
[   25.219249][  T246] vcc_1v8: supplied by vcc3v3_sys
[   25.219897][  T430] dwmmc_rockchip fe320000.mmc: IDMAC supports 32-bit address mode.
[   25.220725][  T430] dwmmc_rockchip fe320000.mmc: Using internal DMA controller.
[   25.221404][  T430] dwmmc_rockchip fe320000.mmc: Version ID is 270a
[   25.222113][  T430] dwmmc_rockchip fe320000.mmc: DW MMC controller at irq 33,32 bit host data width,256 deep fifo
[   25.222319][  T230] rk808-rtc rk808-rtc: registered as rtc0
[   25.223836][  T246] vcca1v8_codec: supplied by vcc3v3_sys
[   25.225299][  T230] rk808-rtc rk808-rtc: setting system clock to 2013-01-18T08:51:20 UTC (1358499080)
[   25.229266][  T246] vcc1v8_hdmi: supplied by vcc3v3_sys
[   25.231476][  T246] vcc1v8_pmu: supplied by vcc3v3_sys
[   25.234494][  T246] vcc_sdio: supplied by vcc3v3_sys
[   25.236737][  T246] vcca3v0_codec: supplied by vcc3v3_sys
[   25.238742][  T246] vcc_1v5: supplied by vcc3v3_sys
[   25.242235][  T246] vcca0v9_hdmi: supplied by vcc3v3_sys
[   25.244670][  T246] vcc_3v0: supplied by vcc3v3_sys
[   25.246205][  T246] vcc3v3_s3: supplied by vcc3v3_sys
[   25.246985][  T246] vcc3v3_s0: supplied by vcc3v3_sys

After that, it powers off. Pressing the power button makes it boot up again:

U-Boot TPL 2022.10-rc5+ (Apr 26 2023 - 23:11:04)
[...]

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?

[agraf]

I've just tried with the distro device tree and it also fails. This looks more like an openSUSE bug.

[agraf]

Ok, I take that back. Same symptoms with Ubuntu 23.04.

[agraf]

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.

[dsx724]

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.

[dsx724]

@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

1. Dumb supply: 5V 3A OK
2. Semi-smart supply: 5V 3A OK
3. Spec-smart supply: 5V 3A without resistors/negotiation not OK at high current.

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

[dsx724]

@agraf I've tested a lot of distribution ISOs and the only one I got to work is Fedora.
OpenSUSE 15.5 was stuck on lack of USB drivers. Debian and Ubuntu stopped at GRUB.

[dsx724]

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.
libre-computer-project/libretech-linux@509bfc8

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.
libre-computer-project/libretech-linux@6291269

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.
libre-computer-project/libretech-linux@5141755

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.
Note 2, some power supplies send a non-sense header after they time out and we filter these non-sense by ignoring them if (pd_header_type_le(msg->header) != 0)
libre-computer-project/libretech-linux@ef5abaa