Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Does HDMI work on Mango Pi? #25

Open
hgonomeg opened this issue Dec 23, 2022 · 28 comments
Open

Does HDMI work on Mango Pi? #25

hgonomeg opened this issue Dec 23, 2022 · 28 comments

Comments

@hgonomeg
Copy link

I'd like to happily share with you that the default configuration produces an image that is perfectly bootable on Mango Pi (the RISC-V variant: https://mangopi.org/mqpro)

Wi-Fi works, but I can't get HDMI to produce any output.

I'm not sure if I'm actually expected to see anything (maybe I'm missing some kernel argument or there's some lacking configuration?)

Also I'm not sure if USB works.

lsmod shows some platform-related HDMI modules, namely sun8i_drm_hdmi.
Generally, my experience suggests that the default kernel configuration is heavily stripped-down and it seems to lack a lot of kernel modules useful for various purposes [unless I'm doing something wrong].

When it comes to any potentially related dmesg output, I only found this:

musb-sunxi 4100000.usb: Invalid or missing 'dr_mode' property
musb-sunxi: probe of 4100000.usb failed with error -22
sun8i-mixer 5100000.mixer: Couldn't get our reset line
sun8i-mixer 5100000.mixer: Couldn't get our reset line

but I don't know what to make of it.
I'm a bit of a noob when it comes to such low-level stuff so please be understanding.

Once I build up enough understanding, I'd like to contribute to the project!

@sehraf
Copy link
Owner

sehraf commented Dec 24, 2022

Hi!

but I can't get HDMI to produce any output.

HDMI was working some (many) month ago. I did a quick test with a fresh build and now my screen stays black, too 🙄 So yeah it's not just you.

Also I'm not sure if USB works.

USB does work, but there are hardly any USB drivers. (see below)

my experience suggests that the default kernel configuration is heavily stripped-down

Absolutely, this is a "defconfig" (aka the bare minimum to boot) + the bare minimum to get Arch (and (some? most?) USB ethernet adapters working).

I did experiment with the Archlinux RISC-V kernel config in the past but it is missing most (if not all) of Allwinner/sunXi related drivers. Once the D1 stuff is merged upstream, i can create an issue here.

When it comes to any potentially related dmesg output, I only found this:

This is another one.

[ 52.072646] sun4i-drm display-engine: Couldn't bind all pipelines components

@sehraf
Copy link
Owner

sehraf commented Dec 30, 2022

I gave riscv/meta-riscv@e17510e a try without success, though.
EDIT: they depend on ARM

@mattfbacon
Copy link

Any update? Why does hdmi work in the armbian image but not here?

@Nightwulf
Copy link

I'm having the same issue. As far as I could see in the boot logs of armbian, the SUN4I/SUN8I modules are needed directly inside of the kernel itself, not as a loadable module. But even if I add a "patch_config"-line in 1_compile.sh, the config doesn't change at that point.
My Arch on my MangoPi is running, network is working but HDMI remains black....I'll investigate that further and report, if I have any success.

@Nightwulf
Copy link

I added some logging and as you can see here, the options are set to "enabled".
./scripts/config --file ../linux-build/.config --enable DRM_SUN4I ./scripts/config --file ../linux-build/.config --enable DRM_SUN8I_DW_HDMI ./scripts/config --file ../linux-build/.config --enable DRM_SUN8I_MIXER
But if I output the options directly before the build itself starts, .config looks like this:
CONFIG_DRM_SUN4I=m CONFIG_SUN4I_TIMER=y CONFIG_PHY_SUN4I_USB=m
Any hints?

@mattfbacon
Copy link

How do you check that the OS is running? Is there a way to preconfigure the SSID and security so that you can ssh in? Or are you using a serial console?

@mattfbacon
Copy link

BTW, here is the relevant section of Armbian config

# CONFIG_DRM_VGEM is not set
# CONFIG_DRM_VKMS is not set
# CONFIG_DRM_UDL is not set
# CONFIG_DRM_RCAR_DW_HDMI is not set
# CONFIG_DRM_RCAR_USE_LVDS is not set
# CONFIG_DRM_RCAR_MIPI_DSI is not set
CONFIG_DRM_SUN4I=y
# CONFIG_DRM_SUN4I_HDMI is not set
# CONFIG_DRM_SUN4I_BACKEND is not set
CONFIG_DRM_SUN6I_DSI=y
CONFIG_DRM_SUN8I_DW_HDMI=y
CONFIG_DRM_SUN8I_MIXER=y
CONFIG_DRM_SUN8I_TCON_TOP=y
CONFIG_DRM_PANEL=y

@Nightwulf
Copy link

Nightwulf commented Sep 17, 2023

I have a serial console attached to the pi and my PC and configured network and stuff from there. After that was done, I installed SSHD and added a user. Now I'm able to SSH into the pi.
The options you provided are quite helpful since I didn't know, SUN6I_DSI has to be loaded. Thanks!
My main problem is that the changes to the kernel patching stuff are roled back when in 1_compile.sh the following lines are called:

        # default anything new
        make ARCH="${ARCH}" O=../linux-build olddefconfig
        grep SUN4I ../linux-build/.config >> ~/patches.txt

As you can see, the last line is a grep to my log and in this grep, the modules are back to be compiled as a module instead of the "enable" you can see in my patch log.
So why does the make olddefconfig change this back?

@Nightwulf
Copy link

Ok...after reading a bit in the kernel documentation, I guess the problem here is, that some of the modules have dependent options to be set and those dependencies are not met which makes them to fall back to their original behaviour when issuing "make oldconfig" or "make olddefconfig". I'll read and cross-compare everything and report the results here.

@Nightwulf
Copy link

Ok, giving up for today...summary:

  • dependencies are all met and all modules are built and loaded -> still no HDMI
  • compared to armbian again and saw, there all drivers are loaded directly from the kernel, no modules!
  • in current kernels, there is only the option to load them as a module
  • 5.19 stock (the kernel, armbian uses), does not support SUN4i HDMI
    For me, this means the kernel was patched manually to support that configuration

Digging further tomorrow!

@mattfbacon
Copy link

there is only the option to load them as a module

Hmm, I wonder, is this a technical limitation or just an oversight? If the latter, easy to patch.

@Nightwulf
Copy link

Well, there are some arrows in my quiver left.
Next, I'll look, when exactly HDMI comes to life on Armbian and which exact driver it is. Then checking the armbian config again, perhaps the modules have some settings there. And last, I'll check the kernel changelog for any hints.
If all that doesn't help, I'll head over to MangoPi forums. Perhaps anybody there has a hint.
I'll not give up until my MangoPi is working with HDMI on Arch ;-)

@Nightwulf
Copy link

Short update: got several, additional modules to build and load but still no HDMI. One problem is, that the driver names partly changed from 5.19 to 6.4. Even the Ubuntu image holds a 5.19 kernel.
Will continue later this week.

@mattfbacon
Copy link

There are also newer images available here: https://disk.yandex.ru/d/da8qJ8wyE1hhcQ/Nezha_D1/ArmbianTV

I plan to test these soon, hopefully today. It may be helpful to figure out how they get it to work with the 6.x kernel.

@mattfbacon
Copy link

I tested a couple of the images. For HDMI, the latest "current" image works, and all of the edge ones do not.

The relevant section of the kernel config for this current image, 20230630-current, is:

CONFIG_DRM_SUN4I=y
CONFIG_DRM_SUN6I_DSI=y
CONFIG_DRM_SUN8I_DW_HDMI=y
CONFIG_DRM_SUN8I_MIXER=y
CONFIG_DRM_SUN8I_TCON_TOP=y
CONFIG_DRM_PANEL=y

So seems to be the same.

@Nightwulf
Copy link

I have all of those loaded and it does not work. There must be an additional module (or trick).
I'll continue on wednesday.

@Nightwulf
Copy link

Nightwulf commented Sep 20, 2023

Continued today...not very successful tho. I can second, that Armbian 6.1 kernel boots and has HDMI. Downside is, that it is completely differant than the arch kernel setup. Boot is without boot partition and using GRUB, having several command line parameters passed to the kernel and comparing the boot logs shows differences all over the place.
Single positive point I have to report is, that I found out why the drivers didn't build baked into the kernel but only as modules. Reason was, that the DRM driver itself has been selected as a module. Changing that let me build the other stuff in the kernel too.
But in the boot log, there is no sign of the sun4i-drm driver at all.
I compared the dependend modules as stated in the kernel config and from that side, everything looks ok.
I'll drop it for now and let that sink in a bit. But as I promised, I'll not give up ;-)

@mattfbacon
Copy link

Thanks anyway!

@Nightwulf
Copy link

Oh....as I said, I'm not done yet. Next will be, that I'll create a more simple script, based on Sehraf's, using the newest SBI, U-Boot and kernel versions and create a very basic kernel config, so that the system barely runs.
I'll continue from there then.
I bought the Mango-Pi to learn in detail about RISC-V in the first place...guess, that will be very detailed :P

@Nightwulf
Copy link

Ok, driver tries to load now but throws some error about missing components...we're getting closer!

@nekorouter
Copy link
Contributor

Arch's kernel is mainline kernel (looks like), which is not have any display support for D1.
Armbian's 5.19 kernel is from Allwinner's BSP kernel, and 6.1 kernel is from smauel's kernel, both have (at least) HDMI support.

If you can get 6.6+ kernel light up your HDMI monitor, that would be interesting...

@mattfbacon
Copy link

Based on https://linux-sunxi.org/Linux_mainlining_effort#Planned_for_next, HDMI video support is WIP. I have not figured out where the development of this can be tracked, though.

@Nightwulf
Copy link

Those documents are fairly old. Meanwhile I figured out, that the devices HDMI-Connector, HDMI-PHY und HDMI-Controller are in the DTB of the working Armbian/Ubuntu-Distros but not in the vanilla kernel...they are simply missing from the device tree. I'll try to patch them in there and see, whether that helps.

@Nightwulf
Copy link

Ok...I wrote an email to smaeul to figure out, what is happening....so here now the long story short:

  1. important for the boot of the kernel is the device tree in u-boot which gets loaded into memory and passed on to the kernel, not the one included in the kernel itself!
  2. Since the scripts of sehraf are using an older version of u-boot from smaeul's repository, the devices in the DTS (and therefore the compiled DTB) do not fit any longer the drivers in the kernel so that there is no match
  3. As a result of 1+2, important dependencies as e.g. the display clocks cannot be loaded and set

I'll try to change what is needed in the u-boot stuff but as I'm not experienced in that, that at least will take a while if ever I'm successful. Perhaps smaeul can/will help with that.
I'll keep you informed here, what I do and wether it succeeds or not.

@sehraf
Copy link
Owner

sehraf commented Oct 10, 2023

I'll update uboot to v2023.10 and see if it's booting

EDIT: i don't see any config for the D1. @Nightwulf if you have more information on how to get a more recent uboot running, let me know

@Nightwulf
Copy link

At least not an easy one. Since both, the official u-boot repo as well as the fork of smaeul do not include the allwinner stuff in any newer branch than the one, you're using in your scripts, we can not simply use that. As I wrote, the driver structure has changed at many points so the only way I see is to clone the most current u-boot from denx and then adopt the drivers and dts step by step.
This is not my usual playing field but I will give it a try...perhaps smaeul helps a bit...at least I asked him ;-)

@hgonomeg
Copy link
Author

Do you think that it's realistic to expect that @smaeul 's changes get merged to the mainline kernel eventually or is this an abandoned project?

@sehraf
Copy link
Owner

sehraf commented Sep 26, 2024

No idea

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants