Gentoo for Amlogic S9xx (TV box S905\S905X\S912)

[mDup]

Are you using the original dtb?

The original as in the dtb.img file in the original 8.2.3.1 image from kszaq? No, I'm using... gxbb_p200_2G_1Gbit.dtb.

I have a S905 too which for which Armbian eth works using meson-gxbb-p200.dtb 4.19.x and 2015 u-boot, but not (yet) using 2018 u-boot.
I do patch meson-gxbb-p200 however as follows:

Code: Select all

-               eth_phy0: ethernet-phy@3 {
-                       /* Micrel KSZ9031 (0x00221620) */
-                       reg = <3>;
+               eth_phy0: ethernet-phy@0 {
+                       reg = <0>;
+                       eee-broken-1000t;

This is not needed to make eth work but to make it work reliably.
I guess you could perhaps use SD card or USB stick with 2015 u-boot to start with.
Good luck.

[erm67]

Are you using the original dtb?

The original as in the dtb.img file in the original 8.2.3.1 image from kszaq? No, I'm using... gxbb_p200_2G_1Gbit.dtb.

Well you linux on arm System On Chip like your TV box is different from linux onx86 computers, there is no plug&pray, hardware is not automatically detected & initialized; instead the kernel relies on a file that describes exactly the HW of the board and is referenced by the drivers, this file is the dtb.
You said that some of the hardware in your board is not recognized, well the bad news is that it will never be recognized unless you use the right dtb, there aren't so many 905 boards out there, just try all dtbs until one works.
You posted a pic of a box called M9+ previously, well it doesn't have a gbit eth but a 100Mbit one, so you are probably using the wrong dtb since gxbb_p200_2G_1Gbit.dtb is a dtb for a box with a gbit ethernet; that is probably the reason why the ethernet interface is not recognized, IIRC the original dtb burned by the manufacturer is in /dev/dtb with the original firmware & LE.
The original dtb that comes with the board might or might not work with LibreELEC or balbes 3.14 kernels because they used updated drivers that also need updated dtb, however it describes correctly the hardware in your box. You can convert the binary dtb back to the source using the dtc utility like this:

Code: Select all

~/gits/linux-xlnx/scripts/dtc/dtc -I dtb -O dts -o devicetree.dts devicetree.dtb

The dts is a text file (the source) and can be read by humans with a text editor ...

So if you manage to find the original (as provided by your HW vendor) dtb you can decompile it, open it in vi and find out exactly what kind of hardware is in your board, at this point you will be able to select the correct dtb for the kernel you are using.
Alternatively open the box and visually identify the chips soldered on the board I use a small usb microscope for that, the prints are very small ....

The dtb is also used by uboot, the bootloader to initialize the hardware before the kernel is loaded, in this kind of boxed the uboot bootloader uses the dtb burned in the firmware (/dev/dtb) while the kernel might use a different one (loaded by balbes scripts for example), this creates problems some times, expecially if the 2 dtb differs.

[The_Pope]

Ok, the box is this one. It says plain and clear "Kekilo M9 Plus TV Box is a smart Android TV Box that supports 100/1000M Internet/Gigabit Lan."

Okay? Next time please assume that I know how to read and what hardware I'm using. I even have the original cardboard box, it says gigabit everywhere. They can't say gigabit and have 100 Mbps in reality, they would get sued or their product taken off Amazon. There should be some guy on some website complaining about something like that.

This box came with Android on it. Not Libreelec. The Android is gone because the owner (not me) sees these boxes as pure Libreelec boxes and thus installed it to the internal memory. The only purpose of a non-spaceship computer is to play movies, it appears. He gave this to me because he doesn't have time to google around if a hw-accelerated Linux can be installed on this. So if I can do it, then fine. If I can't do it, eh, we tried. Would have been cool to have an ARM-based desktop.

He prefers Gentoo and I get why. But he said any Linux that works would be fine. Turns out this Amlogic crap has sketchy-at-best support, but hey, it was cheap. The only Linuxes that work on it are Libreelec and Armbian. Libreelec is useless for desktop computing as it was never meant to do that. Armbian... not a chance. Oh, sure, if you use it without X, as some sort of server, then yeah, it works. Even if you have X it can sort of work, for example as a display in a mall, looping various ads, messages, whatever. Just don't try to play a high bitrate video.

Since this is Gentoo, I thought things can be forced to work as they should. Seems it can't even be forced to boot.

So thanks but no thanks, I'm returning this to the owner to use with their precious Libreelec. I might try with an older box, based on armv7 / s812 - https://www.amazon.ca/NinkBox-Android-A ... B01G1Q7GSA

[erm67]

Ok, the box is this one. It says plain and clear "Kekilo M9 Plus TV Box is a smart Android TV Box that supports 100/1000M Internet/Gigabit Lan."

Okay? Next time please assume that I know how to read and what hardware I'm using. I even have the original cardboard box, it says gigabit everywhere. They can't say gigabit and have 100 Mbps in reality, they would get sued or their product taken off Amazon. There should be some guy on some website complaining about something like that.

This box came with Android on it. Not Libreelec. The Android is gone because the owner (not me) sees these boxes as pure Libreelec boxes and thus installed it to the internal memory. The only purpose of a non-spaceship computer is to play movies, it appears. He gave this to me because he doesn't have time to google around if a hw-accelerated Linux can be installed on this. So if I can do it, then fine. If I can't do it, eh, we tried. Would have been cool to have an ARM-based desktop.

He prefers Gentoo and I get why. But he said any Linux that works would be fine. Turns out this Amlogic crap has sketchy-at-best support, but hey, it was cheap. The only Linuxes that work on it are Libreelec and Armbian. Libreelec is useless for desktop computing as it was never meant to do that. Armbian... not a chance. Oh, sure, if you use it without X, as some sort of server, then yeah, it works. Even if you have X it can sort of work, for example as a display in a mall, looping various ads, messages, whatever. Just don't try to play a high bitrate video.

Since this is Gentoo, I thought things can be forced to work as they should. Seems it can't even be forced to boot.

So thanks but no thanks, I'm returning this to the owner to use with their precious Libreelec. I might try with an older box, based on armv7 / s812 - https://www.amazon.ca/NinkBox-Android-A ... B01G1Q7GSA

Return it is a great idea, but you have no idea of how many devices are sold on ebay/amazon with fake components inside, the ones that complain get a refund the other don't even notice. For Amazon/Ebay is ok as long as the seller refunds those that complains. With cheap china boxes like that the best solution is open it and visually inspect the chipsets inside.

If it doesn't boot or has boot related problem the dtb is wrong nothing that can be fixed by an Operating System in the ARM world at least.
Oh I forgot, the kernel and dtb used by LibreELEC and Armbian 3.14.x are ripped from Android so they are just the same.

try the odroid H2
http://linuxgizmos.com/odroid-h2-is-wor ... ker-board/
It is inbtel based so no more dtb problems

[The_Pope]

try the odroid H2
http://linuxgizmos.com/odroid-h2-is-wor ... ker-board/
It is inbtel based so no more dtb problems

Nah, on any single x86 machine I'm good, I generally don't need help. Plenty of documentation and hardware support.

[mDup]

[...]Armbian... not a chance. Oh, sure, if you use it without X, as some sort of server, then yeah, it works. Even if you have X it can sort of work, for example as a display in a mall, looping various ads, messages, whatever. Just don't try to play a high bitrate video.[...]

I have not tried myself recently but balbes150 s905 Armbian with amlogic libmali is said to have graphics acceleration in X for some HW.
See Armbian and Khadas VIM forums.

[erm67]

I used an S905 box (a good one from beelink) with utgard and opengl but it was rather disappointing, after all the GPU only has few pixel shaders (3?) and runs at low speed (500mhz?) I read in the odroid forum that there is also a bottleneck somewhere that makes it even slower. libmali is a hack to use android drivers in linux and is even slower since everything must be copied and converted to libmali format.

That said I used the box with libreelec to play high bitrate full-HD h264-h265 content (torrents and DVB-S2 from my sat->ip dish) without problems, I never tried 4k but it should work. VP9 did not work well, all that of course using HW decoding (not all Amlogic boards have it) and 3.14.x kernel. Now that I remember there was an HW bug decoding some h265 high bitrate, Mad Max: Fury Road crashed for me, but h264 was fine at every bitrate.

https://discourse.coreelec.org/t/amlogi ... -soon/1320

HW h264 decoding should come also for mainline kernel soon.

It is a TV box you know, all it is supposed to do is decode MPEG videos ...

[The_Pope]

It is a TV box you know, all it is supposed to do is decode MPEG videos ...

Absolutely. It's just the closest thing to a desktop machine that I could find, anywhere. That's actually my problem, I'd like a desktop ARM machine. Couldn't find anything that has been released, just about 3(?) announcements about such future products.

[NeddySeagoon]

The_Pope,

How much do you want to spend and do you need everything to work?
Most of the present arm64 'desktops' are servers in a desktop case. Some have missing hardware drivers too.

[The_Pope]

Well, if something is guaranteed to have complete Linux support, I'd spend some nice money on it. Among the reasons is the famous "I'm only doing this once."

I'm seriously looking at Raspberry Pi now. At least some of them have a GPU that is supported with a VIDEO_CARDS variable in Gentoo.

[NeddySeagoon]

The_Pope,

I have 64 bit KDE on my Pi3B+ but its not ready for prime time yet.
All The Pis have the same GPU. Its essentially a mobile phone chipset with an ARM CPU of some sort added on.

There is the Avantek
Other I know the Cavium Thunder X works well with Gentoo, I don't know any of the details.
There are one or two others.

[The_Pope]

Fantastic, thank you very much! The price tag isn't that enormous. It is expensive, but still, it could be worse.

[erm67]

Get a chromebook, it is a desktop, ARM64 and runs gentoo (well sort of at least

There aren't soo many ARM GPU with linux drivers out there......

C'mon did you really thought that installing gentoo on a 20$ chinese TV box you got off EBAY/Amazon it would become a full fledged desktop?

Maybe using the right dtb it could be barely usable, I bet you didn't even edit uEnv.ini to make it point to the correct dtb ..... Maybe rip the Libreelec kernel and kernel modules using uboot tools requires too much man pages reading and sorry LE no longer ships systemd-switch-root, too bad.

[The_Pope]

C'mon did you really thought that installing gentoo on a 20$ chinese TV box you got off EBAY/Amazon it would become a full fledged desktop?

...I bet you didn't even edit uEnv.ini to make it point to the correct dtb .....

No, I tried, because someone asked me to. Now I have a suggestion to make to him, thanks to NeddySeagoon. Apparently only the ASUS Chromebook is based on ARM, the others have ordinary Intel processors. The point of this is to have an ARM desktop, not an x86_64 desktop that's difficult to install. And the ASUS, ARM-based Chromebook has the Mali GPU. No thanks, I already have two TV boxes with those.

Also, I told you to please stop assuming things about me. Of course I edited the uEnv.ini from Armbian. I haven't even tried to boot it without editing that. The problem is that it didn't recognize any network interface and had to use a USB one.

I'm also kind of amazed that I can't take a dtb file that works almost perfectly, from Libreelec, and use it with Armbian. It has to be compiled linked to the image to be booted or something like that.

[NeddySeagoon]

The_Pope,

arm64 is not a well trodden path, like amd64. It will break on you, lots of things are not keyworded, and support from Gentoo is a little thin on the ground.

Its my opinion that arm64 has a long way to go before its desktop ready.
My investment is limited to a couple of Raspberry Pis and my time.

arm64 boxes with lots of cores look really good until you realise that calculating the dependency graph is single threaded and ./configure is single threaded so getting all those cores busy at the same time is a real challenge. I've tried on a 96 Core Cavium Thunder. Feel free to borrow from my binhost.

[erm67]

Also, I told you to please stop assuming things about me. Of course I edited the uEnv.ini from Armbian. I haven't even tried to boot it without editing that. The problem is that it didn't recognize any network interface and had to use a USB one.

I'm also kind of amazed that I can't take a dtb file that works almost perfectly, from Libreelec, and use it with Armbian. It has to be compiled linked to the image to be booted or something like that.

I assume that you still have not well understood the relationship between dtb and drivers, it is not amazement ....

[NeddySeagoon]

The_Pope,

The device tree compiler (dtc) works both ways.
You normally feed in a *.dts and it produces the *.dtb.
You can also feed it the *.dtb and get a *.dts out.

However, like all code, dts files are usually written with symbolic names. This are not preserved by dtc.
Its syntactically correct, so you can can edit it and put it back through dtc again.

[The_Pope]

I assume that you still have not well understood the relationship between dtb and drivers, it is not amazement ....

I somewhat get it, a dtb sort of indicates what drivers to expect and maybe even where to load them from? Because there's no plug n play? Even so, why in the world is the dtb system not standard? Copy some dtb file and the modules directory. Well, no, because there is a different script system! Great.

[NeddySeagoon]

The_Pope,

The dtb describes the hardware to the kernel.
e.g. address, dma, irq and more. Rather like passing module parameters to kernel drivers before Plug and Pray was a thing on ISA cards.
You had to fit jumpers to avoid resource clashes, then describe the jumpers to the kernel module.

[erm67]

Can you post the dtb from libreelec somewhere and the corrisponding one from balbes/mDup kernel? I can decompile and diff them just to see what changed.
Just a tip:

Code: Select all

[    0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034]
[    0.000000] Linux version 4.19.6-gentoo (root@erm67) (gcc version 8.2.0 (Gentoo 8.2.0-r5 p1.6)) #1 SMP PREEMPT Tue Dec 4 20:45:14 CET 2018
[    0.000000] Machine model: Amlogic Meson GXM (S912) Q200 Development Board

The first lines in dmesg will show the DTB that is being used since the 'Machine model' is defined in the dtb itself.

[The_Pope]

Ok, this is the dtb file from Armbian 5.64 while the dtb file from Libreelec (version 8 ) is here.

[erm67]

Definition of the ethernet interface in the Amlogic proprietary dtb:

Code: Select all

       ethernet@0xc9410000 {
                compatible = "amlogic, gxbb-rgmii-dwmac";
                reg = < 0x00 0xc9410000 0x00 0x10000 0x00 0xc8834540 0x00 0x08 >;
                interrupts = < 0x00 0x08 0x01 >;
                phy-mode = "rgmii";
                pinctrl-names = "eth_pins";
                pinctrl-0 = < 0x2e >;
                rst_pin-gpios = < 0x2f 0x0e 0x00 >;
                mc_val = < 0x1621 >;
                resets = < 0x08 0x23 >;
                reset-names = "ethpower";
                interrupt-names = "macirq";
                clocks = < 0x08 0x0a >;
                clock-names = "ethclk81";
        };

Definition of the ethernet interface in the mainline dtb:

Code: Select all

            ethernet@c9410000 {
                        compatible = "amlogic,meson-gx-dwmac\0amlogic,meson-gxbb-dwmac\0snps,dwmac";
                        reg = < 0x00 0xc9410000 0x00 0x10000 0x00 0xc8834540 0x00 0x04 >;
                        interrupts = < 0x00 0x08 0x01 >;
                        interrupt-names = "macirq";
                        status = "okay";
                        clocks = < 0x0b 0x24 0x0b 0x04 0x0b 0x0f >;
                        clock-names = "stmmaceth\0clkin0\0clkin1";
                        pinctrl-0 = < 0x1b >;
                        pinctrl-names = "default";
                        phy-handle = < 0x1c >;
                        phy-mode = "rgmii";
                        amlogic,tx-delay-ns = < 0x02 >;
                        snps,reset-gpio = < 0x1d 0x0e 0x00 >;
                        snps,reset-delays-us = < 0x00 0x2710 0xf4240 >;
                        snps,reset-active-low;

                        mdio {
                                compatible = "snps,dwmac-mdio";
                                #address-cells = < 0x01 >;
                                #size-cells = < 0x00 >;

                                ethernet-phy@3 {
                                        reg = < 0x03 >;
                                        interrupt-parent = < 0x1e >;
                                        interrupts = < 0x1d 0x08 >;
                                        phandle = < 0x1c >;
                                };
                        };
                };

Apparently it is the same, phy-mode = "rgmii"; means it there is an external physical interface (a Gbit interface since the internal one is 100Mbit), I was wrong and indeed the board has a gbit interface (you say the eth is working with libreelec), also the memory addresses used look the same, bothe are ethernet@c9410000 where c9410000 is a memory address :

Code: Select all

reg = < 0x00 0xc9410000 0x00 0x10000 0x00 0xc8834540 0x00 0x04 >;
vs
reg = < 0x00 0xc9410000 0x00 0x10000 0x00 0xc8834540 0x00 0x08 >;

The compatible line:

Code: Select all

 compatible = "amlogic,meson-gx-dwmac\0amlogic,meson-gxbb-dwmac\0snps,dwmac";

Indicates what linux driver should be used and this is the documentation of the meson-dwmac driver from the open source dts:

https://www.kernel.org/doc/Documentatio ... -dwmac.txt

I don't see anything obvious atm, but it's late here and I go to bed now
Post a dmesg of a freshly booted kernel maybe

Code: Select all

                                wifi@1 {
                                        reg = < 0x01 >;
                                        compatible = "brcm,bcm4329-fmac";
                                };

Wifi uses the brcmfmac driver that is the same for all broadcom chipsets but needs proper firmware installed, it's a bitch to configure and armbian images most of the time lack most of the drivers while libreelec guys (kszaq) did a great job collecting all possible driver combination for this class of boards. It is a bit more complicated make it work on armbian. Do you have experience with brcmfmac driver and firmware?

[The_Pope]

Wait, wait... Amlogic proprietary dtb ? You mean the one in Libreelec? This one?
Libreelec recognizes both network interfaces, but the wired one just gets a weird IP. Hm, come to think of it, I don't recall trying to see if it does the same even if I don't plug in a network cable. But the result is the same, it doesn't work.

And by mainline you mean the one in Armbian, the one I uploaded? That one recognizes both interfaces yet neither work.

It could still be a 100Mbit ethernet device! I've never seen it actually working!

Now, dmesg. I have heard of this. I'll google how to get to the respective log.

However, small disclaimer, it will take me a while. Since the outlook on the S905 machine was very bleak, I took an S812 and tried the same thing, but with an ancient Libreelec build (by balbes150!) - version 7.0.x, from 2016. Used the same pair of USB sticks to boot libreelec and chroot on a second libreelec stick's root partition and unpacked the arm7va hardfloat stage3 there. Waaaaaay more stable, despite the stage3 file being ancient.
Also, I have encountered one package so far (and I'm pretty close to pulling in Xfce4!) that was marked green on packages.gentoo.org (so stable?) yet it failed to compile. The next version, which was also the latest, was marked yellow, yet it did compile! I went to package.accept_keywords and put that ~arm flag there and it pulled the last version, which compiled. Super weird. The package was sys-fs/udev.

I'll have to unplug the S812 machine, replace it with the S905 and get to the dmesg bit. Also, dmesg under which Linux distribution - Libreelec, Armbian, or Gentoo?

EDIT: Also, no, I'm not experienced in brcmfmac. I installed Gentoo on a Pentium III laptop with PCMCIA slots and I had a Netgear wi-fi card for it, with a Broadcom chipset. I don't recall managing to make it work, despite checking a lot of wi-fi modules in genkernel and installing the linux-firmware package.

[erm67]

As I was writing yesterday the ethernet entry in the dtb describes the interface that should be used to talk with the physical interface, (think of it like a PCI bus), for Amlogic devices the type can be internal and in this case the kernel uses the amlogic driver or use the rgmii protocol to talk with an external chipset. This external chipset is identified without the need of an entry in the dtb and most of the times is a realtek chip in amlogic boards, you should look in dmesg or lsmod to see what ethernet driver is being used/loaded by LE, or open the board and visully determine what cheap eth chipset has been soldered on the board by chinese workers. The cheaper the board the cheaper the eth chipset used.
Also balbes/mDup kernel have very few drivers compiled compared to the Fedora aarch64 kernel, that is why it compiles quickly, maybe the driver for the physical eth is missing.

The same goes for the wifi, Amlogic boards have 3 SDIO busses, where devices used the protocol used by SD cards to communicate, one of the SDIO busses is used by the SD card (and it doesn't need to pretend to be an SD card), the second is used by the EMMC drive (if present) and the third is used by the wifi card, that pretends to be an SD card .... The entry in the dtb say that there is a wifi card handled by the brcmfmac driver on a specific SDIO bus so the linux kernel just loads the brcmfmac and tell it to find a card on SDIO 3. Again there is no way to know what cheap wifi chipset was soldered on that SDIO bus the board, since most broadcom chipset are handled by the brcmfmac driver, again even you have the original or a working firmware or the only way to determine what cheap wifi chipset has been soldered on the board is open the box and look inside. There are tables on freaktab that list the wifi chipset used on the various amlogic boards but I was never able to use the wifi on my board until I opened it and discovered there was and older&slower 4335 chipset insted of the AP6335 that should have been there.

With LibreElec it worked since I had submitted the firmware from my board to kszaq like everybody on LE forum

I'll have to unplug the S812 machine, replace it with the S905 and get to the dmesg bit. Also, dmesg under which Linux distribution - Libreelec, Armbian, or Gentoo?

Ideally a dmesg from a system where the periferals work well and one from gentoo/Armbian the kernel is more or less the same but Armbian has more firmware installed.

The S812 should work well now with mainline kernel, if you manage to configure all devices and find the right dtb

[NeddySeagoon]

Some Broadcom SDIO wifi needs a text file as well as the firmware. e.g. Raspberry Pi.
The firmware may be in linux-firmware but the text file is not.