That quote is just copied from megi’s page linked in the other topic. Pinephone has identical output (except the username) and i did not want to type it out manually on the pc i’m using to post this.
I’m trying to get something working, not suggesting how to fix it as i don’t know. The only thing i came up with was thinking if the order of the build flags mattered like they do in some commands, probably not, but philm already made some other changes that also rearranged that identical to the example working build command.
The linked uboot version makes the touch screen stop working after reboot. The phone boots normally to login screen but swiping up to unlock does not work. Tested both on an updated unstable install, and on fresh beta28 install.
edit: here is something maybe related from journal:
tammi 17 14:24:33 manjaro-arm kernel: lima 1c40000.gpu: error -ENODEV: _opp_set_regulators: no regulator (mali) found
tammi 17 14:24:33 manjaro-arm kernel: sun50i-a64-r-pinctrl 1f02c00.pinctrl: supply vcc-pl not found, using dummy regulator
tammi 17 14:24:33 manjaro-arm kernel: axp20x-rsb sunxi-rsb-3a3: mask_invert=true is deprecated; please switch to unmask_base
tammi 17 14:24:33 manjaro-arm kernel: axp20x-adc axp813-adc: DMA mask not set
tammi 17 14:24:33 manjaro-arm kernel: axp20x-battery-power-supply axp20x-battery-power-supply: DMA mask not set
tammi 17 14:24:33 manjaro-arm kernel: axp20x-usb-power-supply axp20x-usb-power-supply: DMA mask not set
tammi 17 14:24:33 manjaro-arm kernel: i2c i2c-0: mv64xxx: I2C bus locked, block: 1, time_left: 0
tammi 17 14:24:33 manjaro-arm kernel: Goodix-TS 0-005d: Error reading 1 bytes from 0x8140: -110
tammi 17 14:24:33 manjaro-arm kernel: i2c i2c-0: mv64xxx: I2C bus locked, block: 1, time_left: 0
tammi 17 14:24:33 manjaro-arm kernel: Goodix-TS 0-005d: Error reading 1 bytes from 0x8140: -110
tammi 17 14:24:33 manjaro-arm kernel: Goodix-TS 0-005d: I2C communication failure: -110
tammi 17 14:24:33 manjaro-arm kernel: Goodix-TS: probe of 0-005d failed with error -110
Do you have access to your phone’s serial console, meaning that you can capture the messages produced on the serial console when the phone is turned on and booted?
No, the cable would become insanely expensive to buy due to shipping costs, as it is not possible to purchase it in same package as the phone (i tried).
Should these logs not be available after boot from disk?
I’m rather fine now, thankfully, and I’ll start testing various boot loader builds tomorrow. I already went through the relevant TF-A source code, so I know what’s the expected behavior with the CPU idle states and Crust, and what may actually go wrong. What’s left is detailed testing.
Gah, I’ve started coughing quite badly, having a runny nose, and feeling rather bad in general, which all basically have put me out of commission. I was already sick for about a couple of weeks back in December, hoping to be done with the common cold, seasonal flu or whatever it was, but what do you know, it’s probably just that time of the year.
I’m hoping I’ll be better tomorrow or the day after, so I can perform the testing. I’m looking forward to getting to the bottom of the CPU idle issue.
@Strit Could you, please, run the following command and post the resulting pinephone.dts file in the GitLab issue? Just to make sure that the device tree is amended correctly in the TF-A.
The correct additions to the device tree are pretty much already confirmed by the TF-A output from the serial console that’s visible below, as an excerpt from the logs you provided, but let’s double check that to be sure, please.
INFO: PSCI: Suspend is available via SCPI
By the way, what are you getting in the following sysfs file?
@philm As a note, I’ve just checked the kernel configuration in the linux-pinephone package, and it looks right because it contains the following lines: