Am Thu, Dec 30, 2021 at 02:30:24PM +0100 schrieb Patrick Wildt: > 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. >
Preorders for the Pro Explorer Edition will come up later today: https://www.pine64.org/2022/01/11/pinephone-pro-explorer-edition-pre-orders-open-january-11/ I'll order one. Patrick > > > > So you might want to find out why sxirsb(4) isn't working well. > > > > I'll have a look at the code today. > >
