These are some pretty awesome developments man!
Thanks a ton for all the work you’ve done to get this working!
Once I actually figure out how to implement these commits, I will be doing so, haha!
These are some pretty awesome developments man!
Thanks a ton for all the work you’ve done to get this working!
Once I actually figure out how to implement these commits, I will be doing so, haha!
One easy way, would be to just clone my repo (the radxa-zero-linux-5.10.y) branch, and build it the same way they recommend to build the vendor kernel in the wiki; I’ve tried to stay as close to the vendor repo as possible, I just rebase on top of the latest 5.10 each time it comes out.
Alternatively, just grab the mentioned commits and apply them to the radxa 5.10 kernel sources (or maybe ask @jack if they could pull them in )
your posts should be restored.
btw, could you make pull-request?
Absolutely, I didn’t even think about that, sorry!
I was working from home the last few days and still working through my backlogs. Gonna review the PR this week.
Thank you for this I am currently compiling the kernel!
It doesn’t work I have a 480 x 1920 screen and no picture sadly.
Can you add “drm.debug=0x02” to your kernel command line, and then after booting, ssh into your machine and run “dmesg | grep drm” and provide the output?
I will try that tomorrow. Also what is a kernel command line I’m new to Linux kernel development.
Ah, well in this case, it should be a matter of just editing or adding “extraargs=drm.debug=0x02
” (without the quotes) in /boot/uEnv.txt
- this just tells the drm subsystem to give us driver debugging outputs. i want to see if it’s actually not seeing things, or if maybe it’s something else. I looked in my code and it definitely should handle 480x1920.
Here is the output:
[ 2.275911] meson-drm ff900000.vpu: Queued 2 outputs on vpu
[ 2.276359] meson-drm ff900000.vpu: CVBS Output connector not available
[ 2.307010] meson-drm ff900000.vpu: bound ff600000.hdmi-tx (ops meson_dw_hdmi_ops)
[ 2.307398] [drm] Initialized meson 1.0.0 20161109 for ff900000.vpu on minor 0
[ 2.360614] meson-drm ff900000.vpu: [drm] Cannot find any crtc or sizes
[ 3.696342] systemd[1]: Starting Load Kernel Module drm…
[ 3.772312] systemd[1]: modprobe@drm.service: Deactivated successfully.
[ 3.773025] systemd[1]: Finished Load Kernel Module drm.
[ 4.771994] [drm] Initialized panfrost 1.1.0 20180908 for ffe40000.gpu on minor 1
Which kernel are you building, and how are you building it? And what does your /boot/uEnv.txt or /boot/extlinux/extlinux.conf file look like? there should be more messages if you have drm.debug=0x02 in the kernel command line.
To be clear, you’re not just trying to use my edid file I linked are you? because that edid file is specifically for the 400x1280 display, not yours which is apparently 400x1920?
I am building your radxa-zero 5.10y kernel and I used the radxa zero kernel building instructions on their website and when I went to edit my /boot/uEnv.txt it created a new file and I haven’t linked any edid file. Also my display is 480x1920.
Can you show me what the contents are in your /boot/uEnv.txt and of the /boot/extlinux/extlinux.conf file please? And also uname -a
please
uEnv.text just has what you said to put in it. extlinux.conf doesn’t exist with the extlinux folder.
uname -a:
Linux radxa-zero 5.10.139-meson64 #22.08.1 SMP PREEMPT Tue Aug 30 07:00:00 UTC 2022 aarch64 aarch64 aarch64 GNU/Linux
Is it because I am using armbian?
That doesn’t seem like it’s my kernel; My kernel should be 5.10.145 based.
I’m not sure how Armbian does it for their radxa zero kernels, but it should be possible to apply my patches to their build system as well
What OS are you using?
On mine I use Kali (but disclaimer that I’m a Kali dev), and we don’t put out an image, you have to build it yourself at the present time. Maybe tonight after work, I’ll look into submitting the patches to armbian, but my todo list in my free time is very long
Ok I will try and install the kernel again and see if it works.
UPDATE:
I think I know what the issue is. I think it is because it was still defaulting to the armbian default kernel even though I had a more up to date kernel installed. I tried to uninstall the old kernel and reboot but now the OS is bricked. Tomorrow I will reflash armbian on the emmc and try it again.