Date: Tue, 25 Jun 2019 08:32:49 +0200 From: Emmanuel Vadot <manu@bidouilliste.com> To: Milan Obuch <freebsd-arm@dino.sk> Cc: freebsd-arm@freebsd.org Subject: Re: Pine64+ HDMI output note Message-ID: <20190625083249.8802d2fb4723a8c7c79bf953@bidouilliste.com> In-Reply-To: <20190616093439.5bcbe869@zeta.dino.sk> References: <20190616093439.5bcbe869@zeta.dino.sk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 16 Jun 2019 09:34:39 +0200 Milan Obuch <freebsd-arm@dino.sk> wrote: > Hi, > > as I am trying to use my Pine64+ for something usefull, I decided to > look on video output. As I built new system natively on Pine, using > what was available there in original image, I mean u-boot and related > things, video output does not work. In original image, I believe it was > built from r345863 sources at April 4th, there were even no /dev/ttyvN > entries. In my new r348999 based system, they were present, but HDMI > output was not active. > > Observing boot process for some time I noticed HDMI output is working > up to some time in the middle of kernel device probing sequence. I > examined a bit dtb blob used, dmesg messages, some source file etc. in > order to understand what's going on, and tried following > > # dmesg | grep hdmi > Clock: hdmi, parent: pll_video0(0), freq: 297000000 > Clock: bus-hdmi, parent: ahb1(0), freq: 300000000 > Clock: hdmi-ddc, parent: osc24M(0), freq: 24000000 > simplebus0: <hdmi@1ee0000> mem 0x1ee0000-0x1eeffff irq 51 compat allwinner,sun50i-a64-dw-hdmi (no driver attached) > simplebus0: <hdmi-phy@1ef0000> mem 0x1ef0000-0x1efffff compat allwinner,sun50i-a64-hdmi-phy (no driver attached) > ofwbus0: <hdmi-connector> compat hdmi-connector (no driver attached) > regulator: shutting down vcc-hdmi > axp8xx_pmu0: Disable vcc-hdmi (dldo1) > > which makes me think, together with presence of getty processes > attached to /dev/ttyvN devices, that all what's missing is just > physical video output signal, and this is most probably caused by > output buffer being shut down. So I googled a bit and found a hint, > tried it - I put line > > hw.regulator.disable_unused=0 > > into /boot/loader.conf file and it works. I think it just uses HDMI > output engine configured by u-boot instead of configuring it itself, as > we have no driver for hdmi and hdmi-phy devices on A64 SoCs. With this you are using efifb. The reason for the tunable is that since there is no node in the dtb related to efifb the kernel will shutdown every regulator that isn't referenced, this is 1) to save power 2) to do the same thing as the Linux kernel as at one point I commited some bad DTS into Linux where almost every regulator got shutdown after a while. > Maybe this is just as simple as adding appropriate compatible string > into arm/allwinner/a10_hdmi.c file, but I do not know if A20 and A64 > cores are compatible in this area... and workaround found is just OK > for me. No, A64 uses the version 2 of the Allwinner display engine, I have a DRM driver working for it (but still have some work to do on it). https://github.com/evadot/freebsd/tree/drm_aw_de2 > Next step would be to try X on Pine64+... Any hint on this? I am going > to try scfb video driver for this, as noted on FreeBSD/arm/Allwinner > wiki page. As for this wiki page - maybe it could be updated in > 'supported devices' table, in column A64 - I think framebuffer works > and HDMI video too, kind of, leaving it in pre-initialised state with > above mentioned workaround. SCFB driver will work correctly with efifb. > Regards, > Milan > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" -- Emmanuel Vadot <manu@bidouilliste.com> <manu@freebsd.org>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20190625083249.8802d2fb4723a8c7c79bf953>