Proceed with caution. I’m feeling somewhat fatigued after having to figure out how to turn everything on, but I have figured out (at this point) how to boot with new packages and a new kernel.
The Kernel (the beast):
First, ouch. I have been doing a lot of trial and error up to this point to get everything up and running. Instead of getting y’all to run weird fat-fingered scripts and all of that, I just modified the upstream kernel from RaspberryPi in a github repo. This has taken days of trial and error. This DSI display in the device is quite wacky.
sudo apt install git bc bison flex libssl-dev make
git clone https://github.com/labrat97/uconsole-linux.git ; cd uconsole-linux
ls /lib/modules to see the new kernel version tag.
sudo cp .config /boot/config-[said kernel version tag]
sudo update-initramfs -c -k [said kernel version tag]
sudo reboot Do this ASAP.
Second, packages:
sudo apt update; sudo apt install screen
Edit all occurrences of bullseye in /etc/apt/sources.list to bookworm. Do this also for /etc/apt/sources.list.d/raspi.list. The clockwork repo does not need this.
Next, sudo apt update; screen sudo apt full-upgrade. The only thing that must be changed in terms of config during the install are things relating to LXDE if using the default image. The new maintainer versions change from mutter to openbox-lxde and you won’t have window decorations or window management if this is kept the same.
sudo reboot
sudo apt install socat raspinfo as these are removed randomly, but still cool.
sudo apt autoremove
Edit: fixed the issue that broke the system below with update-initramfs
The screen is actually making me want to scream. I have the power manager working but it looks like SPI is having a hard time getting DMA up, and the DSI display can’t perform a VBLANK properly. I’m assuming (judging by the random sleeps in the driver code for panel-cwu50), that by upgrading the kernel one of those sleeps is invalidly tuned now. Everything else seems to be working.
The weirdest thing is that it actually booted fine, then i backed it up using fsarchiver. That might be causing something. We shall see.
You’re not the only one who has had problems changing the Kernal. There are some limitations in the patch provided by ClockworkPi that breaks compatibility with different Kernal versions. This link will probably be helpful to you and will explain the issues much better than I can.
That would have been helpful like three days ago. It’s crazy that I have done the exact same thing they have. The only difference is I am using the rpi-6.1.y branch of the raspberry pi linux git and I’m merging all of the applied config options from both rpi-6.1.y and the 0001-...patch. The thing that broke new kernels was two function signatures that could be trivially changed in panel-cwu05 and panel-cwc686 (I think that’s the right name for the 686 one).
So check the repo in the previous comment. I figured it out and it is now working with the new kernel version. If you ever want to use waydroid, do this.
I’ll definitely check it out. I don’t have my uConsole yet, but I’m happy to see any Kernal development or changes for the device while I’m waiting on mine to ship.
Well when you get yours (it’s very cool). Make sure to check out the repo. If you have access to a 3D printer, I have added my shoulder strap mount STLs as this thing is barely pocketable in some clothing.
So the screen isn’t working AGAIN, it’s really odd. It seems like there is some configuration missing from being sent to the panel when it boots after the kernel upgrade. If it reboots after the upgrade (the panel never has its power cut) the screen still works, after a complete shutdown it stops. The git repo is now ongoing.
Maybe my patches here will help you with your screen problem. I’ve tested them with a CM3 module. There is still an issue that kernel complains screen failed to enter sleep mode then resets the screen, which doesn’t affect normal use.
Edit: in very rare cases, the screen will stay black at boot and a force reboot is required. The patches should be applied to latest 6.1.y branch, or the stable one.
My suspicion is it is in the power-up sequence defined at 7.1.2 from the JD9365D.pdf, and is very picky. I don’t know how long tINIT_SLAVE and tINTERNAL_DELAY are.
First we agree that my assumption of the screen controller model is correct. Yes, chip model JD9365 originates from my assumption.
I think tINIT_SLAVE and tINTERNAL_DELAY are just general terms about overall timing. They basically tell that the host controller should initialize itself before screen controller, and become active after screen initialized, and an additional delay.
Maybe chapter 9.5(Power on/off sequence) is more useful.
That is way more useful. Thank you. I’m looking at this between things today. I don’t know if that is the correct screen controller for sure, but it is the best I have to go with at the moment. I’ve emailed Alex for some hopeful support.
I’ve been getting pretty frustrated trying to get it to work right for the past few days and I’ve been thinking of maybe just implementing a properly written cwu50 module for use in DKMS so that newer raspberry pi OS’s can just have a package or something to install it during runtime. I also can’t quite figure out why any of these hacks are needed at all. Looking at whatever documentation I could find on implementing a MIPI-DSI module in linux, it seems the main thing could just be improper structure of the driver itself. I don’t think the driver is effectively handling drm_bridge things, as the driver used in the 5.10 branch controls the screen totally fine. The VC4* modules had a lot of changes between then and now, and one of the biggest changes I saw looking through was based around setting up drm bridges for the kernel.
The wheel doesn’t have to be completely reinvented for any of this, but I feel as though the really janky ULPS repeat send thing and various function signature changes have caused the need for a bit of a restructuring.
I’d need to look through it again, but it looks like the MIPI-DSI implementation has a thing for short and long transfers to the display and the display might be sensitive to those during that long init sequence. There might need to be a new set of operation decoders or something?
Also, that extra pull-up on the HW Reset line looks fishy.
Hi. I’m also trying to build custom kernel and your thread feels unfinished.
I’m tinkering with the whole armbian build and trying to boot up 6.6.
Also I’ve found patchset for 6.1 but haven’t tried it yet. Maybe it will help you.
I Did this on accident the other day by touching raspi-config and enabling 4k output… it wiped all the overlay entrys from config.txt you need those for it not to ignore the built in screen…
disable_overscan=1
dtparam=audio=on
[pi4]
max_framebuffers=2
over_voltage=6
arm_freq=2000
gpu_freq=750
[all]
ignore_lcd=1 #these below are for the “panel”
dtoverlay=dwc2,dr_mode=host
dtoverlay=vc4-kms-v3d-pi4,cma-384
dtoverlay=devterm-pmu
dtoverlay=devterm-panel-uc #these are for… the fan? EDIT… not fan… i guess the audio pins for some reason?
dtoverlay=devterm-misc
dtoverlay=audremap,pins_12_13
dtparam=spi=on
gpio=10=ip,np
dtparam=ant2
gpu_mem=256
Thank you all for your work on this. I am ordering my UConsole in a couple of days and I am very much hoping that bookworm will work on it (well) by the time I get it. (I am somewhat of a newbie so I try to follow what you do but it will be a while before I can contribute - if at all). So Thank you!
