On 2022-07-11 11:28, Anton Lindqvist wrote:
On Mon, Jul 11, 2022 at 12:13:38PM +0200, Mark Kettenis wrote:
> Date: Wed, 06 Jul 2022 15:45:05 -0500
> From: j...@entropicblur.com
>
> Hi all,
>
> I had an unused Le Potato SBC lying around, so I took a crack at
> installing OpenBSD/arm64 on it. The board is similar to the supported
> ODROID-C4 and can boot the install kernel successfully, but there are
> many unconfigured devices. I was not able to complete an install because
> neither USB nor microSD storage was available. The dwge network
> interface is detected but nonfunctional because the PHY is not
> configured.
>
> I understand that this is an unsupported board and I had no expectation
> of success or support, but I'm passing this info along in case there is
> any developer interest.
>
> For reference, this is the board:
>
> https://libre.computer/products/s905x/
>
> I used the meson-gxl-s905x-libretech-cc.dtb file from OpenBSD's dtb
> package and the u-boot-2020-07-r1.sd.bin from here:
>
>
http://share.loverpi.com/board/libre-computer-project/libre-computer-board/aml-s905x-cc/firmware/
>
> I used the latest snap miniroot71.img, dated July 06.
>
> Dmesg from the install kernel:
>
> Copyright (c) 1982, 1986, 1989, 1991, 1993
> The Regents of the University of California. All rights
> reserved.
> Copyright (c) 1995-2022 OpenBSD. All rights reserved.
> https://www.OpenBSD.org
>
> OpenBSD 7.1-current (RAMDISK) #1616: Tue Jul 5 10:44:45 MDT 2022
> dera...@arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/RAMDISK
> real mem = 2039029760 (1944MB)
> avail mem = 1939697664 (1849MB)
> random: good seed from bootblocks
> mainbus0 at root: Libre Computer AML-S905X-CC
> psci0 at mainbus0: PSCI 0.2
> cpu0 at mainbus0 mpidr 0: ARM Cortex-A53 r0p4
> cpu0: 32KB 64b/line 2-way L1 VIPT I-cache, 32KB 64b/line 4-way L1
> D-cache
> cpu0: 256KB 64b/line 16-way L2 cache
> cpu0: CRC32,SHA2,SHA1,AES+PMULL,ASID16
> efi0 at mainbus0: UEFI 2.8
> efi0: Das U-Boot rev 0x20200700
> "arm-pmu" at mainbus0 not configured
> agtimer0 at mainbus0: 24000 kHz
> "xtal-clk" at mainbus0 not configured
> "firmware" at mainbus0 not configured
> "efuse" at mainbus0 not configured
> "scpi" at mainbus0 not configured
> simplebus0 at mainbus0: "soc"
> ampintc0 at simplebus0 nirq 256, ncpu 4: "interrupt-controller"
> simplebus1 at simplebus0: "bus"
> "interrupt-controller" at simplebus1 not configured
> "reset-controller" at simplebus1 not configured
> "adc" at simplebus1 not configured
> "clock-measure" at simplebus1 not configured
> "spi" at simplebus1 not configured
> "watchdog" at simplebus1 not configured
> "sram" at simplebus0 not configured
> simplebus2 at simplebus0: "bus"
> syscon0 at simplebus2: "sys-ctrl"
> "power-controller-vpu" at syscon0 not configured
> "clock-controller" at syscon0 not configured
> syscon1 at simplebus2: "ao-secure"
> "cec" at simplebus2 not configured
> amluart0 at simplebus2: console
> "ir" at simplebus2 not configured
> "pinctrl" at simplebus2 not configured
> "video-codec" at simplebus0 not configured
> simplebus3 at simplebus0: "bus"
> amlrng0 at simplebus3
> "pinctrl" at simplebus3 not configured
> "eth-phy-mux" at simplebus3 not configured
> simplebus4 at simplebus0: "bus"
> "video-lut" at simplebus4 not configured
> simplebus5 at simplebus0: "bus"
> syscon2 at simplebus5: "system-controller"
> "clock-controller" at syscon2 not configured
> "mailbox" at simplebus5 not configured
> dwge0 at simplebus0: rev 0x37, address ea:b1:7f:b1:44:67
> dwge0: no PHY found!
> simplebus6 at simplebus0: "apb"
> "mmc" at simplebus6 not configured
> "mmc" at simplebus6 not configured
> "phy" at simplebus6 not configured
> "phy" at simplebus6 not configured
> "phy" at simplebus6 not configured
> "gpu" at simplebus6 not configured
> "vpu" at simplebus0 not configured
> "hdmi-tx" at simplebus0 not configured
> "usb" at simplebus0 not configured
> "crypto" at simplebus0 not configured
> "cvbs-connector" at mainbus0 not configured
> "emmc-pwrseq" at mainbus0 not configured
> "hdmi-connector" at mainbus0 not configured
> "leds" at mainbus0 not configured
> "regulator-hdmi-5v" at mainbus0 not configured
> "regulator-vcc_3v3" at mainbus0 not configured
> "regulator-vcc-card" at mainbus0 not configured
> "regulator-vddio_ao18" at mainbus0 not configured
> "regulator-vddio_boot" at mainbus0 not configured
> simplefb0 at mainbus0: 720x576, 32bpp
> wsdisplay0 at simplefb0
> wsdisplay0: screen 0 added (std, vt100 emulation)
> softraid0 at root
> scsibus0 at softraid0: 256 targets
> root on rd0a swap on rd0b dump on rd0b
> WARNING: CHECK AND RESET THE DATE!
>
> If there is any developer interest, I'm happy to do what I can to help.
Hi Joe,
This board is based on a different SoC than the ODROID-C4. We'll need
to add support for this SoC to the amlclock(4), amlreset(4),
amplpinctrl(4) and amldwusb(4) drivers. Shouldn't be too difficult
but it is a bit of work. If you're willing to test diffs with a
relatively quick tunraround I can give it a go. Otherwise somebody
would need to send me a board with that SoC.
I also took a look a this and decided to order a device. One thing I
did
notice is that we lack a driver for the phy supply referenced from the
node that hopefully can attach as amlusbphy(4):
phy@78000 {
compatible = "amlogic,meson-gxl-usb2-phy";
#phy-cells = <0x00>;
reg = <0x00 0x78000 0x00 0x20>;
clocks = <0x03 0x37>;
clock-names = "phy";
resets = <0x11 0x22>;
reset-names = "phy";
status = "okay";
phy-supply = <0x2b>;
phandle = <0x33>;
};
...
regulator-hdmi-5v {
compatible = "regulator-fixed";
regulator-name = "HDMI_5V";
regulator-min-microvolt = <0x4c4b40>;
regulator-max-microvolt = <0x4c4b40>;
gpio = <0x23 0x13 0x00>;
enable-active-high;
regulator-always-on;
phandle = <0x2b>;
};
Being able to enable this regulator looks crucial based on this commit
from Linux:
https://github.com/torvalds/linux/commit/b83687f359d9b4128073f06ab7a06489eb04aa7c
I wrote a quick driver that attaches to all regulator-fixed nodes,
making all of them available through the regulator(9) API. This should
make the regulator_enable() call in amlusbphy(4) work. I'm wondering if
this approach makes sense or if a driver with more "restrictive" match
semantics is desirable?
Hi Anton and Mark,
Thank you for your interest. I would be happy to help test if you can
provide a compiled kernel or miniroot image; unfortunately I have a
bootstrapping problem because this is the only arm64 board I have on
hand, and it obviously isn't usable as a build environment yet. But this
problem is probably moot if Anton has hardware on the way!
One thing I do want to mention is that this board seems to have the
usual chaos and confusion surrounding U-Boot and DTB versions; as best I
can tell, there is an old vendor U-Boot with some binary blobs baked in,
and at least one or two newer, community-maintained U-Boot versions. I
am not terribly confident that I picked the "right" versions of U-Boot
and DTB for my installation attempt.
Thanks,
Joe
