I thought arch for arm was dead ended, but it was just the goofy board company version. There's a generic arm64 that still gets lots of updates. I'm glad I checked before going thru with the above. That would have been a long process.
This time I think I did things a little more properly. I learned a few things about u-boot:
u-boot looks for a boot.cmd script in /boot that sets up alot of env vars and the kernel and init files. The kernel is easy, u-boot knows how to load them, but the init stuff is tricksier.
There's a mkimage utility that both compiles the boot.cmd into a boot.scr and wraps an initramfs into a u-boot friendly ram thing. Right now I'm just going to have to manually remember to run those when my kernel updates, but I think there might be a way to make it happen automagically. I'll figure it out later.
This new Arch arm install has the same problem with my = key that armbian did, so I'm hoping I can make it to having barrier running before I need an = key
The cold hit oklahoma. I live in a shitty old house, and my office is in a really badly made addon room that leaks air. The north wall is barely there and icy north winds blow through it.
When it hits each year I usually bail and set up my main pc in another room with a nice warm furnace. This time It looked like the weather would get better in a few days so I just took my tater and my small 1080 monitor.
That gave me a couple days to work on it, and I got it in really nice shape. I ended up spending alot of time reading the kernel docs and various forum posts and whatnot. Single board computers have a dtb file associated with them that describes the hardware to the kernel.
My boot.cmd was left over from armbian. I started with that and kind of blasted over most of it with arch. But I found the right spot and just set my tater dtb directly along with the usual names of the kernel and initramfs that arch spews out after an update (and my aforementioned scripts are run).
One other change needed is the rw put after rootwait. Without that you get this big ascii box warning that the early disk check can't happen without it.
With that the GPU sort of begins to kind of work. For the tater it is a mali 450. The kernel drivers try to use an older open source driver called lima. If you google for lima though, there is some garbage apple thing that has the results totally polluted. I could never find much information on it.
Many hours of assgoblinry later, I discovered that one of the driver pathways is called "modesetting". Yea, great name for a driver. I could see that the lima stuff was creating the proper goodies in /dev/ and /proc and I could see spew in dmesg about it.
I found a few people doing stuff with xorg.conf and started poking with that and none of the stuff I saw online worked, but it gave me ideas to try stuff. I kept seeing d00c0000.gpu in the dmesg and I stuffed that into MatchDriver and bam x launched!
openGL even works! From everything I had read, the mali wouldn't work and only supported gles or something, but GL gears fired right up, and my openGL terminal works fine.
You can see a regulator error in the boot spew:
I think that means the gpu just runs fully volted at all times and might cook itself eventually
Here's what it looks like running with bsp window manager:
Bottom left is a discord client that runs in the terminal. I'm trying to get everything like that as it saves bigtime on ram and works better with the tiling.
Ram is definitely a problem though. There really aren't any lightweight browsers. I've got floorp on there and it eats around a gig when open. I tried using a full discord client to watch anime with a friend and it leaked like crazy and eventually started swapping like mad. The audio couldn't keep up and everyone sounded like robots.
It seems like any single board computer that has had a few years to ripen a bit will have hackers adding in support to the kernel.
Also the whole reason I started on this journey, audio, just worked, at least HDMI audio.
