> Date: Tue, 13 Aug 2019 01:01:37 +0000
> From: ioh <m...@sdf.org>
>
> On Mon, Aug 12, Mark Kettenis wrote:
> > > Date: Sun, 11 Aug 2019 23:49:10 +0000
> > > From: ioh <m...@sdf.org>
> > >
> > > I have been able to successfully install OpenBSD Current Aug 06
> > > 2019 on the Olimex Teres laptop. It has very similar hardware to
> > > the PineBook, arm64 allwinner, etc. I used u-boot-sunxi-with-spl.bin
> > > from u-boot v2019.07 (teres_i_defconfig) and Arm Trusted Firmware
> > > v2.1. The dtb (sun50i-a64-teres-i.dtb) is from the OpenBSD 6.5-release
> > > ports tree.
> > >
> > > To complete kernel initialization from either the install bsd.rd
> > > or bsd from an install, the ohci driver must be disabled. I have
> > > included the serial console output and dmesg of first a boot without
> > > the ohci driver disabled, and then the boot log of my successful
> > > install with ohci disabled. According to linux dmesg or the
> > > sun50i-a64-teres-i.dts, ohci is available so the driver is probed
> > > correctly - but even after several minutes the initialization process
> > > will not continue past the line "ohci0 at simplebus0".
> >
> > The hang at that point suggests that accessing the OHCI registers
> > hangs the machine. That happened in the past when the relevant clock
> > wasn't running or when the OHCI logic block wasn't brought out of
> > reset. But those issues got fixed and ohci(4) works fine on other
> > boards that use the Allwinner A64 SoC. What seems to be different is
> > that the Teres-i only has the 2nd USB controller enabled.
> >
> > Adding printfs is probably the way to go here. Start with
> > ohci_fdt_attach() in sys/dev/fdt/ohci_fdt.c and try to pinpoint at
> > which point it hangs.
>
> This is the printf's I added, followed by the dmesg output. The
> point at which init hangs is at bus_space_read_4() in ohci_fdt_attach().
> Do you need further digging in bus_space_read_4, ie adding printf's
> to that function too to find the exact line further, or is that
> enough information?
Thanks, yes, at least for now.
This confirms my suspicion and does point towards an issue with a
clock that isn't running and/or a reset that isn't deasserted. You
could see what happens if you enable the other USB controller (both
ehci0 and ohci0) in the device tree if you know how to do that. On my
end I'll try to do the opposite (disable ehci0 and ohci0) and see if I
can reproduce the issue. It seems the Linux image you're using has
both controllers enabled.
Cheers,
Mark
> Index: dev/fdt/ohci_fdt.c
> ===================================================================
> RCS file: /cvs/src/sys/dev/fdt/ohci_fdt.c,v
> retrieving revision 1.2
> diff -u -p -u -p -r1.2 ohci_fdt.c
> --- dev/fdt/ohci_fdt.c 7 Jan 2019 03:41:06 -0000 1.2
> +++ dev/fdt/ohci_fdt.c 13 Aug 2019 00:53:06 -0000
> @@ -71,6 +71,8 @@ ohci_fdt_match(struct device *parent, vo
> void
> ohci_fdt_attach(struct device *parent, struct device *self, void *aux)
> {
> +printf("\nDEBUG: entering ohci_fdt_attach\n");
> +
> struct ohci_fdt_softc *sc = (struct ohci_fdt_softc *)self;
> struct fdt_attach_args *faa = aux;
> char *devname = sc->sc.sc_bus.bdev.dv_xname;
> @@ -96,9 +98,13 @@ ohci_fdt_attach(struct device *parent, s
> clock_enable_all(sc->sc_node);
> reset_deassert_all(sc->sc_node);
>
> +printf("DEBUG: Make it to here\n");
> +
> /* Record what interrupts were enabled by SMM/BIOS. */
> sc->sc.sc_intre = bus_space_read_4(sc->sc.iot, sc->sc.ioh,
> OHCI_INTERRUPT_ENABLE);
> +
> +printf("DEBUG: Do not make it here\n");
>
> /* Disable interrupts, so we don't get any spurious ones. */
> bus_space_write_4(sc->sc.iot, sc->sc.ioh, OHCI_INTERRUPT_DISABLE,
>
>
> OpenBSD 6.5-current (CUSTOM) #2: Mon Aug 12 17:45:21 PDT 2019
> r...@hedges.my.domain:/sys/arch/arm64/compile/CUSTOM
> real mem = 2018398208 (1924MB)
> avail mem = 1928859648 (1839MB)
> mainbus0 at root: Olimex A64 Teres-I
> 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: 512KB 64b/line 16-way L2 cache
> efi0 at mainbus0: UEFI 2.7
> efi0: Das U-Boot rev 0x20190700
> apm0 at mainbus0
> psci0 at mainbus0: PSCI 1.1, SMCCC 1.1
> "osc24M_clk" at mainbus0 not configured
> "osc32k_clk" at mainbus0 not configured
> "internal-osc-clk" at mainbus0 not configured
> "sound_spdif" at mainbus0 not configured
> "spdif-out" at mainbus0 not configured
> agtimer0 at mainbus0: tick rate 24000 KHz
> simplebus0 at mainbus0: "soc"
> sxiccmu0 at simplebus0
> sxipio0 at simplebus0: 103 pins
> ampintc0 at simplebus0 nirq 224, ncpu 4: "interrupt-controller"
> sxiccmu1 at simplebus0
> sxipio1 at simplebus0: 13 pins
> sxirsb0 at simplebus0
> axppmic0 at sxirsb0 addr 0x3a3: AXP803
> "de2" at simplebus0 not configured
> "syscon" at simplebus0 not configured
> "dma-controller" at simplebus0 not configured
> "lcd-controller" at simplebus0 not configured
> "lcd-controller" at simplebus0 not configured
> sximmc0 at simplebus0
> sdmmc0 at sximmc0: 4-bit, sd high-speed, mmc high-speed, dma
> sximmc1 at simplebus0
> sdmmc1 at sximmc1: 4-bit, sd high-speed, mmc high-speed, dma
> sximmc2 at simplebus0
> sdmmc2 at sximmc2: 8-bit, sd high-speed, mmc high-speed, dma
> "eeprom" at simplebus0 not configured
> "phy" at simplebus0 not configured
> ehci0 at simplebus0
> usb0 at ehci0: USB revision 2.0
> uhub0 at usb0 configuration 1 interface 0 "Generic EHCI root hub" rev
> 2.00/1.00 addr 1
> ohci0 at simplebus0
> DEBUG: entering ohci_fdt_attach
> DEBUG: Make it to here
>
> --
> ioh
>
