TonyMac32

if you are on the broken desktop, <ctrl><alt><F1> to get the terminal.

I knew I would get the right people into this conversation.

You can, but the conversation around Lima/Mesa maturity was quite clear, that the performance will be terrible/buggy without using a much newer Mesa library (19.3.x minimum) Sent from my Pixel using Tapatalk

https://gitlab.freedesktop.org/lima/mesa/issues/85 So looks like no solution. Older than 1.20 xserver could be configured, but the mesa 19.1 lima support is no good for xfce. Lima more or less needs shut off on Bionic, I haven't gotten too far on looking at Buster. [edit] Buster uses ca 2018 mesa (18.x), so no worry about that.

On my builds the initial boot is fine until I update those packages, then *boom* no menus and a lot of laggyness.

I saw this on my RK3328 boards, but it's now been reported on Allwinner as well, the recent libdrm updates are killing our display manager. As soon as I update my image the menus and things are no longer displaying properly, things are missing, invisible, etc. lima related perhaps?

I have seen the same on my RK3328 builds after apt upgrade of those libraries. @Igor I'm not sure who knows the DRM magic best.

...is the legacy kernel not working with display right now? My last build did... Sent from my Pixel using Tapatalk

I think with the next LTS mainline kernel this will be possible. Right now there are still a few odds and ends, RK3399 is not as well supported as RK3288, for example. It's far better off than RK3328 though. We have some fragmentation of the RK3399 boards due to bootloader difficulties with RAM, Rockchip has been extraordinarily slow to improve LPDDR4 support Sent from my Pixel using Tapatalk

No complaints from me, once I get kernel hell straightened out on renegade and friends I want to circle around and u-boot 2020 the tinker as well, and I might see if the MiQi will survive it, it seemed to dislike 2018+ last time ... Sent from my Pixel using Tapatalk

RK3328 Current is all the mess I could have hoped for, and then some. No sound No USB3 Fixed with upstream pending patches No USB-OTG on Renegade Brought patch from Dev to Current only 1.3 GHz despite having high opp patch ...Probably not an exhaustive list. [edit] On apt update/upgrade the desktop fails, I get the wallpaper/mouse but no menu/etc. Will have to check later.

Rockchip Current appears to be stable. TBD is the runtime overlay support, but I think that is secondary *looks over at RK3328*

This could have been like this for a while (since the restructure), a patch I had in the system disappeared it looks like, I reapplied for current kernel, added the MiQi turbo mode patch to the RK3288.dtsi so it can be used with any board where the user wishes (and cleans up our patch directory).

Hi @adafruit! It's been 11 months, and @chwe never committed to providing said PR, he provided a critique. I would say it's a safe guess a PR isn't coming. For my part I still really like the concept, but yes, the need to put board detection logic in every sub-function library was a bit rough. I myself haven't looked at this code in quite some time, I spent the summer helping my wife with her recovery from a spinal tumor removal, I'm only now catching up on other things. Somewhat related, I should be getting a Giant Board whenever UPS decides it isn't too snowy to provide service. I'm interested in how that performs, I know it is running Blinka, it should give me something to compare to if I pursue it. (I'm still catching up on BSP issues at the moment for our next release window) An interesting benchmark would be Blinka on Linux SBC vs these new NXP iMXRT boards.

I just pushed a fix for the desktop in legacy. It boots to desktop now.

As I understand it RK3328 needs some love, as does Tinker. I'll be poking at that tonight to get specifics. Just to be clear on the freeze date, is it bugfix only after 1-25, or total freeze?

@guidol should we have an I2S overlay for the H3 boards? I don't see why not... Also, for the K1 Plus, the Pimoroni PHAT DAC should work if you just need the DAC.

@martinayotte, @sgjava Would this be a potential feature to have out of the box? Say, an overlay to enable the button in the first place?

Excellent! I have moved the convo from the ArmbianIO thread to the Userspace IO thread so as to not confuse anyone.

@chewitt the C2 has a special blob because of some legal issues with their advertisement of clock speeds, it tests for a hardware tell to make sure it's on the right board, everyone else is required to use the other closed source blob. It's as close to RPi as you can get without actually descending into the abyss that is Broadcom. ;-) Sent from my Pixel using Tapatalk

I see you were busy today, I had no intention of giving you work to do.

This whole thing is still making my head hurt, I can't see any reason uboot.bin flashed at the right location wouldn't be working. right, the *.sd.bin is different than the *.bin. Describe the partition scheme you want to use? It is. I found a module for my K1 Plus, perhaps it will work to experiment with the K2, since this seems to be festering.

Mainline. I will look at the patch set later today and hopefully rectify the issue in our build system. Sent from my Pixel using Tapatalk

@Larry Bank, @sgjava I'll be taking another look at this codebase again, things have slowed down a bit on my side and I want to start getting some of these RPi Hat's running with Armbian boards.