Bug 226014 - Allwinner H3: Orange Pi fails to boot with the Audio Codec enabled in fdt
Summary: Allwinner H3: Orange Pi fails to boot with the Audio Codec enabled in fdt
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: arm (show other bugs)
Version: CURRENT
Hardware: arm Any
: --- Affects Only Me
Assignee: freebsd-arm mailing list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-02-18 21:52 UTC by Greg V
Modified: 2020-01-11 17:24 UTC (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Greg V 2018-02-18 21:52:32 UTC
This has been reported on the mailing list, but got no replies:

https://lists.freebsd.org/pipermail/freebsd-arm/2017-November/017104.html

I can reproduce this on my Orange Pi PC (similar to Plus 2E but a different board still.)

Booting with NanoPi NEO's device tree works (apparently since it does not detect 'pcm0: <Allwinner Audio Codec>' with that one), booting with the Orange dtb fails with the exact same error as linked above.

The patch that adds 'h3_codec0: <Allwinner H3 Audio Codec (analog part)>' (http://arrowd.name/h3audio.patch) does not help.
Comment 1 Greg V 2018-02-18 22:14:53 UTC
Better workaround than using NanoPi's device tree: changing

status = "okay";

to

status = "disabled";

in the &codec section in sys/gnu/dts/arm/sun8i-h3-orangepi-pc.dts, recompiling it (in that folder: /usr/src/sys/tools/fdt/make_dtb.sh /usr/src/sys sun8i-h3-orangepi-pc.dts ~), copying to the sd card and booting.
Comment 2 Mark Linimon freebsd_committer freebsd_triage 2018-02-19 00:21:39 UTC
You might try the hack in 224070.
Comment 3 Greg V 2018-02-19 11:51:23 UTC
(In reply to Mark Linimon from comment #2)
I already applied the hack that is disabling it in the dts :) I just want these boards to be supported in -CURRENT without modifications.

By the way, Ethernet works when I plug the cable in before boot.
Comment 4 Mark Millard 2018-10-12 03:00:34 UTC
(In reply to Greg V from comment #0)

I just tried head -r339076 and 2018.09 u-boot and such for
an OPi+2E. The audio-support related kernel crash still
exists.

I set the status to disabled in the .dts and produced a
new .dtb and substituted it. That allowed booting (but
disabled audio, not that I'd be using audio if it was
working).

With Ethernet plugged in up before being powered on,
Ethernet worked. A basic test of each of the USB ports
showed them to be working.

HDMI seemed to work in the early powerup but then the
display image was trashed. (I'm not planning on using
the display for now anyway.)

powerpd was working. The fastest listed clock rate was
slightly over 1GHz.

I do not have hint sinks or a fan for it yet so I only
planned on this basic test for now. It seems basically
operational when audio is disabled in the dtb.
Comment 5 Emmanuel Vadot freebsd_committer 2020-01-11 17:24:21 UTC
It is still the case ? I think I've fixed that with some review or other bug report.