Build: Latest debian stretch&xenial images are unbootable on TinkerBoard

[Ntemis]

Compiled a fresh image twice with same outcome

[Tonymac32]

I compiled one 7 hours ago to verify the gpu concern and booted just fine. So, the question becomes did either
https://github.com/armbian/build/commit/f3fcea23582c8397a3257fc91fc5c1bd0154ed32

or something custom in your environment cause it? I will look into the commit.

[Tonymac32]

Do you have UART console output to see where it goes wrong?

[Ntemis]

LOL i think i found out whats the issue
Even though a user selects tinkerboard as target he always get in boot.cmd
setenv fdt_file "rk3288-miqi.dtb"
armbianEnv.txt has the correct dtb
fdt_file=rk3288-miniarm.dtb

[Ntemis]

Will provide uart output tomorrow

[Tonymac32]

well, right, the bootscript loads armbianEnv.txt which overrides the miqi dtb selection. Unless something else changed it's been that way for a year now

[Tonymac32]

Just built and booted 4.4.133, Armbian 5.46, booted with no issues.

[Ntemis]

Yes i found out that this is the commit that leaves me unbootable
https://github.com/armbian/build/pull/981 :(
While it shouldn't i"ll change android version to 0x08000000 and try again.
DO NOT MERGE atm

[dmschwartzii]

@Tonymac32 anyway I can get a download of what you built?

[igorpecovnik]

@Ntemis

https://forum.armbian.com/topic/7346-cant-boot-tinker-board-s-from-emmc/?do=findComment&comment=55356

[Ntemis]

I booted up @igorpecovnik :)

[igorpecovnik]

With midgard for Android?

[Ntemis]

Yeap uploading atm for the group to start building TinkerPie

[Ntemis]

Used http://dpaste.com/1VPK8VX with https://github.com/armbian/build/pull/981

[Ntemis]

I think will close now

[igorpecovnik]

MALI is working now?

[Tonymac32]

Does the touchscreen still work with the change to the way the Mipi_dsi?

[Ntemis]

I dont have any to tell but you can test
https://androidfilehost.com/?fid=890278863836288820

[chwe17]

Does JMCC know about this issue here? @ntemis did you test how much this affects his 'RK3288 MEDIA TESTING SCRIPT'? You have the board, you can test it... ;)
IMO it would be really annoying when we break his whole work with switching to 'android_mali' only cause 'linux_mali' is currently broken. For me, his 'UN-official, UN-supported, UN-necessary, UN-popular, UN-precedented...' multimedia script multimedia script is of more importance than making 'default Armbian' suitable for 'retropie images' (as you're suggest with https://github.com/armbian/build/pull/981). In case both is possible, perfect. But in case this means that his whole script gets obsolete and he needs to start from plain, then I favor that we wait/look for a fix of the linux mali driver.

[Tonymac32]

Well, the issue here is actually Rockchip updating the DDK and somehow breaking the compile. The switch was then made to the Linux driver, but it is an older version yet, so it doesn't function for users. I want to get rockchip stable and see if I either have to clone their repo or pick a "moment in time via a tag/commit number so we don't get surprises. As of today I would assume the media script is not working either with a new build.

https://github.com/rockchip-linux/kernel/commit/91842c9d8b4f21a431643d97269d142d9524cd9a#diff-60ad033154c5f79f2acf5a2d6576198e

[dmschwartzii]

@all in my testing using midgard for android breaks emulationstation which kind of defeats the purpose

[chwe17]

As of today I would assume the media script is not working either with a new build.

not my main argument.. ;)

then I favor that we wait/look for a fix of the linux mali driver.

he spend a huge amount of time, bringing this features to armbian, not (yet) officially but with support and fixing the script for currently available armbian images. If this work gets obsolete just by:

+CONFIG_MALI_MIDGARD_FOR_ANDROID=y
+# CONFIG_MALI_MIDGARD_FOR_LINUX is not set

and:

that gcc-wrapper script also adds to the kernel compile time, so pretty nice to get rid of :)

than it's IMO not worth to break his work fully for future armbian images (I know it's currently broken) only to make 'new builds' suitable for RetroPi. Armbians buildscript allows them to build their own kernel/images with minor efforts and to avoid breaking their builds they can freeze the kernel by default and/or usecustomize-image.sh for whatever they want to do with a 'RetroPi image based on Armbian' similar as @ThomasKaiser does it for the OMV images he/OMV provides.

[igorpecovnik]

it's IMO not worth to break

Ofc not. Possible choices:

• go back in time as Tony proposed and we have a working build again
• wait that Rockhip engineers fix what they recently broke
• do nothing :)

[chwe17]

IMO not worth to break his work fully for future armbian images

I don't know how much 'android mali' differs from 'linux mali'. But if this has noticeable side-effects (means it breaks stuff like JMCCs multimedia work), than I would prefer to not send any kernelupgrade to the current users (and also not bring them a default buildoption which doesn't reflect armbians mali behavior as soon as 'linux mali' works) cause support will be a nightmare (e.g. why does it not work anymore? it worked just before I did upgrade! I don't do any upgrades anymore cause you break things). If there aren't any noticeable side-effects than we can switch between both sorts of mali driver whenever RK messes one of them up... :P

[igorpecovnik]

The problem is that "Linux mali" never worked properly while "Android mali" was broken recently. It was broken to the state that building fails. Experimenting caused switching to "Linux mali" ... but that one is not compatible with current mali libs ... bottom up. Goto my previous post :)

We will not provide any kernel upgrade until this is solved.

[Ntemis]

I would suggest one thing.
Follow&Use yocto rocko kernel update tag
Example given
https://github.com/rockchip-linux/meta-rockchip/blob/master/recipes-kernel/linux/linux-rockchip_4.4.bb#L12
This is what i do in Lakka and this is what i recommended Recalbox&Batocera team to do so to avoid any nightmares like this

[igorpecovnik]

I would suggest one thing.

We thought to implement this as a source feature but so far things were eventually fixed upstream. I would not panic and wait 1-2 weeks and then proceed with alternative options.

[Ntemis]

@chwe17 @Tonymac32 @igorpecovnik basically is very easy to add support for mali hw acceleration i will explain the steps here and maybe someone with more knowledge of armbian building system surely can automate the steps.

1. Kernel headers -> linux-headers-rockchip
2. we need libmali-rk-dev_1.6-1_armhf.deb and depending on the board:
   
   
   
   • Use libmali-rk-midgard-t76x-r14p0-r0p0_1.6-1_armhf.deb for Asus Tinkerboard
   
   
   • Use libmali-rk-midgard-t76x-r14p0-r1p0_1.6-1_armhf.deb for MQmaker MiQi
   
   
   • Use libmali-rk-utgard-450-r7p0_1.6-1_armhf.deb for Pine64 ROCK64
   
   
   • Adapt for other socs at will
     
     from https://github.com/rockchip-linux/rk-rootfs-build/tree/master/packages/armhf/libmali
   
   
3. Libdrm from https://github.com/rockchip-linux/libdrm-rockchip.git
4. something like
   ./autogen.sh --disable-intel --enable-rockchip-experimental-api
   $ make && sudo make install
   will do the work :)
   4.Libmali Library
   https://github.com/rockchip-linux/libmali
   Builds with:
   $ cmake CMakeLists.txt
   $ make && sudo make install
   5 https://github.com/rockchip-linux/mpp.git
   Builds with:
   $cmake -DRKPLATFORM=ON -DHAVE_DRM=ON
   $make && sudo make install
   6.And last wayland
   from git://anongit.freedesktop.org/wayland/wayland
   Build with:
   ./autogen.sh --disable-documentation
   $ make && sudo make install

[teacupx]

Hi. JMCC here.

IMO, I think it is convenient to distinguish here three different aspects of the problem:

1. Mali DDK being updated to r18p0 for linux libmali:The commit referenced above was done six months ago, and they are still offering r14p0 in their libmali repo. So, if the Android driver is now the only one compatible with r14p0, I understand they expect us to stay using it for linux too, until a r18p0 library is uploaded.

This issue will come up with every update of the kernel driver or the userspace lib, and will necessarily cause GPU accel to be broken from time to time in the dev images. As a solution, it only requires that the kernel and lib maintainers at Armbian coordinate both ends before pushing a release.

1. The mali driver being broken now. I think the wisest is to freeze the kernel to a working commit, and unfreeze it when the Rockchip engineers fix it, if it is not too much trouble. Or, otherwise, as Igor says, do nothing and wait.

2. The issue with the game emulator: @Ntemis I don't know if you are aware that some developers and community members have been working in a full 3D & video implementation for the Armbian desktop in RK3288 boards , that is currently working quite well. I invite you to check it out in this thread. All your contributions and suggestions are very welcome, so we can join efforts instead of spreading and duplicating our work.

[teacupx]

@Ntemis : In a second read, it looks like you are developing an emulator-oriented distro based on Debian, correct? Well, in that case, it is very likely that the best solution for an X accelerated desktop will not be the same as for a game-only distro. For example, our solution differs substantially from the one LibreELEC currently uses.
One of the good things about Armbian is that it provides a very easy to use kernel config tool. I had no experience in kernel development, and I was able to work with it just in a couple hours. I suggest that you can use it to make a kernel that best tailors your needs, because probably some of the features that are included in the standard Armbian will be an unnecesary burden for your distro, and some features you need will be missing because they conflict with others that Armbian is using (that can be the case for the mali driver). Igor put a lot of work into that masterpiece that is the Armbian build script, let us take advantage of it ;)

[Tonymac32]

@Miouyouyou does MiQi and Tinker require different libmali packages?

As far as the commit reference, @teacupx, yes, that's why we aren't using it, there were some bugfixes that actually mattered that came in after that, I've been waiting on the next tagged release to freeze it.

[teacupx]

does MiQi and Tinker require different libmali packages?

According to this, the r1p0 lib is for RK3288w (a different revision of the SoC).
AFAIK, MiQi uses RK3288 as TinkerBoard. Several people reported in the Armbian thread that the same lib for the Tinker worked in the MiQi. Plus, according to this, the two SoC's are not software compatible, and they would require changes in the kernel.

But please correct me if I am wrong.

[Miouyouyou]

I remember hearing something like this but I never knew the basis. With DRM/KMS/EGL, I never saw any difference, but I never tested with X11 back then (since you need the special snowflake Rockchip X11 server).

[Miouyouyou]

Just tested by switching the libMali.so back and forth and, indeed, the r14p0-r1p0 is throwing a tantrum on my MiQi. The r0p0 works fine though.

ERROR: The DDK is not compatible with any of the Mali GPUs on the system.
The DDK was built for 0x750 r1p0 status range [0..15], but none of the GPUs matched:
/dev/mali0 detected as 0x750 r0p0 status 1
Error: eglInitialize() failed with error: 0x3001

[Ntemis]

@Miouyouyou then you might have a developers edition MiQi because mine is incompatible with r14p0-r0p0 i would suggest to request a production board from them. I remember telling you that in MQmaker forums i posted but i didn't get a response back.

[Miouyouyou]

There's indeed multiple versions of MiQi devices, which don't make testing easier.
One with 2GB of RAM and one with 1GB of RAM.

I got the one with the 2GB and the green LED.

I also had one with a blue LED but it fried up :disappointed:

[Ntemis]

Ah mine is the blue led now i see :)
What a mess they made amazing and unbelievable with no reference anywhere about this.
I have 2GB Blue led btw

[Tonymac32]

hmmm, mine is blue, let me see.

[Miouyouyou]

Well, I found that the Mali driver exports the GPU informations through sysfs :

cat /sys/devices/platform/ffa30000.gpu/misc/mali0/device/gpuinfo

root@miqi:/sys/devices/platform/ffa30000.gpu/misc/mali0# cat device/gpuinfo 
Mali-T76x 4 cores r0p0 0x0750

So there might a way to check this information easily :smiley_cat:

[Tonymac32]

indeed, I just yanked it through the dmesg output, but yeah, r1p0. That's it, EOL-ing the MiQi. (J/K, but ffs)

[Miouyouyou]

So Blue LED = RK3288W then ?

[Ntemis]

@Tonymac32 why? all released miqis are blue led 2gb and r1p0
Could be that r0p0 is just a few old batches
@Miouyouyou yes MiQi has RK3288W i even loaded google os on it once(Chrome OS)

[Tonymac32]

If so there's no mark on it. The Tinker is an RK3288C, clearly marked.

https://www.armbian.com/wp-content/uploads/2018/03/miqi-1.png is mine, it's an angled shot, but no discerning marks.

@Ntemis it was a joke. @teacupx can do a quick check in the script if he is so inclined to handle the difference.

[Miouyouyou]

Since the mali driver depends on only one file : libMali.so . It might be possible to store in /usr/lib/... libMali-r0p0.so and libMali-r1p0.so then create a libMali.so symlink to the most appropriate one depending on the sysfs check.

[Ntemis]

Yeap that would do just fine good call

[Miouyouyou]

Or just trigger the right Rockchip libmali package installation on first boot. That way, it won't break the wonderful Rockchip libmali packages.

[Ntemis]

what ever rocks your world, then ship it!

[Miouyouyou]

:shipit:

[Ntemis]

btw r18p0 has no KMS/DRM support only X11

[Miouyouyou]

No gbm symbol at all ? That shucks. Does it have any vk symbol ?

readelf -a libMali-of-the-r18p0.so | grep -i vk

Also, where did you get a r18p0 user-space driver ? I don't see it on libmali Rockchip repo and don't see it ARM website either.

[teacupx]

@Tonymac32 Check here. It says that if the long alphanumeric row at the bottom left ends in "W", then it is the W version. That seems to be the case for the picture you sent.

Plus, in the same link, it states that they require different software, but the latest SDKs from Rockchip support both. However, we must take that into account just in case in the future some random MiQi's start to show problems and others don't: we'll have to add to the release notes "check the LED color" :)

I can figure out some way of supporting both revisions in the scripts, but to be honest, I don't feel much like doing it if I don't have a MiQi myself. It is a pain to have others test before releasing. And I'm not going to buy one, so the only chance is that the board makers feel interested and send me a sample.

[Ntemis]

ah sorry bud i did a mistake cause was some days ago and forgot the number and got curried away with all the r18 reference :)
Was talking about r22p0 actually not r18p0 and got them from here
https://chromium.googlesource.com/chromiumos/overlays/board-overlays.git/+/ef521b7f640511430e104ae2e46c148e34ebb868
and vulkan support is a wishful thinking keep dreaming like me

[Miouyouyou]

Well, the fbdev version of the Firefly drivers provided by ARM have Vulkan symbols.

So far I was able to list Vulkan "devices" and the queues properties, using these drivers. But I didn't try the display initialization yet. I'll have to focus on that part... when I got a free week-end or something.

The tutorial I'm following : https://software.intel.com/en-us/articles/api-without-secrets-introduction-to-vulkan-part-2
And some bits of code ... That might compile or not : https://github.com/Miouyouyou/Vulkan_Steps/tree/master
The driver you want to test it with : https://developer.arm.com/products/software/mali-drivers/user-space -> Firefly -> r12p0 with fbdev support.

[Tonymac32]

I see some familiar actors in that conversation. Interesting, and seemingly completely unnecessary, probably added cost.

[Ntemis]

fbdev & missing r1p0 support does it for me.
am more looking forward for mainline and gbm support tbh, maybe this time next year we will be there who knows :)

[Miouyouyou]

Indeed ! Meanwhile, for the MiQi Red/Green issue, the fastest way to deal with this would be to check the rXpX version from sysfs and install the right package on first boot, IMHO.

The thing is, the rXpX issue might also be present with some Chromebooks too.

[teacupx]

People reported that the solution we are using in the Armbian script works in mainline MiQi. I guess it was the plain RK3288 version, though.

[Ntemis]

yes patched mainline kernel from rockchip has r14p0 support build-in e.g. https://github.com/rockchip-linux/linux/commit/d3e6d001c15f4cd54e3b5eead1e11f2c8bc2b5aa

[dmschwartzii]

@Ntemis yeah but is Bluetooth and sound stable?

[Tonymac32]

My patches are @Miouyouyou 's patches for mainline.
@dmschwartzii Bluetooth was recently resolved, Armbian has it rolled out, I've been playing music on a bluetooth speaker all day, actually. HDMI sound quit on all three builds, that needs understood, if I roll back the scripts making the onboard USB codec work then there is no audio jack sound in desktop. The DAI cells and codec include issues in 4.14 have been patched upstream.

[dmschwartzii]

@Tonymac32 so Bluetooth works? HDMI sound does not?

[Tonymac32]

Ja/Si/Oui/Da/Yes, I will be working on HDMI sound tonight, I've had enough Amlogic GXB bootloader witchcraft for a bit (how to magic the blobs into a working image with the mainline U-boot)

[dmschwartzii]

@Tonymac32 keep me posted id like to test if you get it working

[Tonymac32]

Another big round of commits hit 16 hours ago, let's take a look. On the bright side, an improved Wifi driver is included. I was waiting for it to hit Rockchip, it was an almost 20 MB patch

[Tonymac32]

The touchscreen is broken with the rockchip update anyway, reviewing. This is a larger mess than anticipated. Hold, please.

[igorpecovnik]

Holly crap, different MiQi's. Mine has green color PCB with bright green light :) The mark on the chip is only RK3288 and PCB is labeled as MiQi V1.0 It has 2G/16G eMMC.

[Tonymac32]

Mine is also V1.0 but has blue. You have the "Limited edition" 🤣 In any case, graphics driver aside, I'm sure the kernel drivers are all aware and look for whatever identification exists in the hardware.

[Ntemis]

Yes kernel wise nothing to worry about only diff is the blob used

[Ntemis]

@Tonymac32 @igorpecovnik @teacupx @chwe17
r18p0 should have support for user space r14p0, anything after r18p0 kernel driver drops support for pre-r18p0 userspace, so my line of action to restore r14p0 support proves to be correct

[Tonymac32]

@Ntemis @dmschwartzii try out branch "rockchip-default" and put any PR's against it while we sort this out. Taking the opportunity to do some housecleaning as well