On Thu, Dec 30, 2021 at 08:51:24AM -0300, Crystal Kolipe wrote: > Hi, > > Thanks for your comments! > > On Sun, Dec 26, 2021 at 07:00:31PM +0100, Patrick Wildt wrote: > > On Sun, Dec 26, 2021 at 08:19:49AM -0300, Crystal Kolipe wrote: > > > * Although the USB root hubs are detected, external USB devices don't > > > seem to be detected when connected. > > > > That can have multiple reasons. If you have a device that lights up > > upon power supply only, use that to find out if the USB device is > > powered at all. Maybe it just doesn't supply power to the device. > > There definitely seems to be a USB power supply issue. > > I connected a USB analyser to the Pinephone and got the following results: > > Booted into MP kernel after crash, with just the analyser connected: > No voltage or current draw detected. > > Booted into MP kernel after crash, with the analyser and dock connected: > No voltage or current draw detected. > > Booted into SP kernel, with just the analyser connected: > 3.56 volts, 0.06 amps. > > Booted into SP kernel, with the analyser and dock connected: > 3.54 volts, 0.10 amps. > > Booted into Linux kernel, with just the analyser connected: > No voltage or current draw detected. > > Booted into Linux kernel, with the analyser and dock connected: > 5.15 volts, 0.05 amps.
I'm not sure if all of the device tree bits they use have been upstreamed, so I might be looking at outdated device trees. Also the schematics are a bit hard to read... There are two bits that are relevant: How to provide power, and how data works. Power: If the dock is supposed to work without another USB-C connected, then we would need to provide 5V to the USB port. What I can see is that the AXP803 supports being connected to a USB power supply, and using this to charge the battery. There's also a pin that tells it when *not* to use VBUS. I think if the phone provides 5V on the USB, it will probably set the N_VBUSEN to tell AXP803 to disregard the VBUS, otherwise it would probably charge itself... N_VBUSEN is controlled by USB-DRVVBUS, which is connected to DRVVBUS (which controls a USB Power Loading Switch), and there's also PL9-DRVVBUS (a GPIO on the A64) and VBUS_CTRL. This last one is connected to ANX7688S, which seems to handle USB-C Power Delivery to find out how much one can charge, and if we should switch data/power roles. There's some more info here: https://xnux.eu/devices/feature/anx7688.html I really can't find where... oh. Now I see. USB-5V is connected to the battery and over the USB Power Loading Switch to DCIN. So I guess if there's no 5V on input, it will output? Can you attach a simple stupid boring Type-C to Type-A adapter and see if there's 5V on it? Because if so, then the Dock is probably powered as well, but the ports on the dock don't provide power? Data: According to the current device tree, two eHCI controllers are enabled and the OTG controller is set to 'peripheral'. The USB-C is probably on the OTG controller. According to the link above, a driver for the ANX7688S should trigger the OTG change. But since it's hardcoded to peripheral, it will (with that device tree) never change to host. Hence no devices will show up. > I've also noticed that when booted into the OpenBSD kernel: > > * The phone works on AC power. > * The phone works on battery power. > > But: > > * The battery does NOT charge. We need a driver for x-powers,axp813-usb-power-supply which sets the RS (Run/Stop) bit in the BC Module Global register. This starts the battery charging module. > My first wild guess is that the USB controller might be being configured in > 'peripheral' mode, rather than 'host' mode. > > > You can try 'usb start' in U-Boot to see if that changes things. > > Unfortunately U-boot just reports 'No working controllers found'. > > > > * The backlight for the display illuminates during boot, around the point > > > of "lcd-controller" at simplebus0 not configured. > > > > Yeah, we have code for the backlight, but we don't have *any* other code > > for graphics output on Allwinner-based systems. If U-Boot sets up a > > framebuffer, we can use it. > > Do we even have any documentation for the display hardware in the A64 SoC? > > I don't mean the Mali GPU, I just mean enough to get un-accelerated plotting > working. > > It might be worth noting that the recently announced Pinephone Pro uses a > Rockchip SoC based on the RK3399. I've just tested the HDMI output on a > Rock-PI 4a, (which uses an RK3399), running OpenBSD, and it works quite well, > (although the console is very slow when scrolling). > > Since a phone is obviously not going to be much use without the on-board > graphics hardware working, (unlike an SBC, which might be accessed > exclusively over the network), I'm wondering if it might be worth waiting to > see if the Pinephone Pro would be a much easier target for such a portable > OpenBSD machine, rather than investing a lot of time on the current Pinephone > model? > > On the other hand, I suspect that many current users of the Allwinner-based > Pinephone will be tempted to replace it with a Pinephone Pro, given that the > performance of the various Linux distributions available for it is not > exactly stella. This could easily lead to a glut of the original model being > available at low cost on the used market. > > OpenBSD could potentially run quite well on that hardware, even if we only > had un-accelerated framebuffer console. Bear in mind that a physical > keyboard is, (or will be soon), available for it, so we wouldn't even need > touchscreen support in order to get a pocketable OpenBSD PDA. I agree, the Pinephone Pro with the RK3399 would be a much better target. The only thing we probably need to write a driver for is the MIPI-DSI controller on the RK3399. But apart from that the rest of the display subsystem should work fine. So, I do have hopes for that. I'd love to have a Pinephone Pro to give it a go. Patrick > > So you might want to find out why sxirsb(4) isn't working well. > > I'll have a look at the code today. >
