jock

Looking for No currently active connector found on google tells that it is probably a message coming from kernel DRM. Maybe the 7" LCD screen is not advertising itself correctly to the HDMI interface, or there's a bug in the DRM kernel code which prevents it working correctly. I had to deal with a couple of Full-HD industrial panels (via DVI) and they usually refuse to display anything when they are not configured exactly with the resolution and refresh rate they expect. I think this is a remote possibility, but supplying EDID manually may interfere somehow. You can read back EDID from the display using get-edit tool (see this for an example), at least you can understand if the display is advertising its modes correctly: get-edid -b 5 | parse-edid

Pretty interesting device! I see from the Internet it has an embedded SATA slot, RTC, 802.11ac wifi, HDMI IN and it has Mali-T860 GPU on a 4-core A53 design, where all other chinese propose outdated GPUs Also the "legacy" kernel looks recent enough, which is nice to start with. Congratulations and keep it up edit: bringing u-boot to boot is one of the most difficult tasks, I faced it when I had to deal with it and Chiptrip Q8 RK3288 (xt-q8l-v10) tv box because I had to use the vendor bootloader and chaining it to u-boot SPL which, in turn, boot the real u-boot.

The answer is yes, it can be done, but you need a bit of knowledge about compiling kernel modules. I made it on an Orange PI PC (Allwinner H3) to test my armsoc drivers and it worked, although Mali-400 MP2 embedded into H3 was quite slow. You should be able to take everything you need (both the kernel driver and the userland EGL+OpenGL ES drivers) from https://github.com/mripard/sunxi-mali Kernel and userland libraries should match their versions to be sure that they work correctly together: if you use r6p2 kernel driver, use r6p2 for userland too. Instructions are easy but here are some hints: You need the kernel headers package installed, you won't get far without this; you should be able to use apt-get to install the appropriate package for your armbian version You can compile the kernel driver on your very same board (I strongly suggest this), so you don't need to export the CROSS_COMPILE environment variable export the KDIR env variable to point to your kernel headers. Typically: export KDIR=/lib/modules/$(uname -r)/build export INSTALL_MOD_PATH env variable to point to your kernel modules:. Typically: export INSTALL_MOD_PATH=/lib/modules/$(uname -r)/kernel follow the instructions as described, but expect some patch won't work or compile fail. Just don't be scared to get your hands dirty, it is common that you may need to do some little manual adjustments (a missing kernel file here, a missing header there...) Once the driver is compiled and installed, you should be already able to modprobe it. Follow the instructions to install the userland EGL and OpenGL ES libraries too. If you are using the X server, you need the x11_dma_buf flavour and you also need to compile this armsoc driver too (maybe you can try the already compiled version I published on this post, it should work for your SoC too. Ignore the media script part which is for rockchip socs). If you don't use X you can use the fbdev flavour, in this case add extraargs=drm_kms_helper.drm_fbdev_overalloc=200 to /boot/armbianEnv.txt as per-instructions.

AFAIK, the problem usually is not related to the hardware itself. Some people reports that often these tvboxes are equipped with defective RAM or flash memories, which should be downclocked to work right, but it is common that they just work. The boards follow more-or-less the chipmaker reference design, but it is very common to see some different chips to deal with Wifi, bluetooth, ethernet, PMU, RTC, etc... As long as your box has a S905 SoC, you must use gxbb p200 device tree, otherwise the box won't boot at all! Unfortunately, as I previously said, the peripheral chips are not always the same, so it is very common that the device boots but you don't get all the goodies from it (in your case, the gigabit ethernet), just because the ethernet/wifi/bluetooth/audio/whatever chip is not described in the device tree you used. Probably there isn't an already cooked device tree for your particular board, so you have to deal by yourself, but editing device trees requires deep hardware knowledge and is not at the reach of an average user. I don't know if there is some armbian or community effort here, but device tree overlays are perfect for such job: you have the basic description of the SoC hardware in the main device tree, then every user manually add overlays for each piece of peripheral hardware of it's own board.

you can export LIBGL_ES=2 environment variable and retry launching the binary. Normally GL4ES supports a variety of OpenGL 2 functions, but some are missing. The documentation on official github page covers them in detail

Ahhh, mixing modesetting and armsoc is not a wise idea, actually I don't know what is going to be chosen by X11 server. I have my own rule for xorg.conf files: the less configuration you write the best it performs. Nowadays X.org is doing good job at autoconfiguring itself, and the configuration files are there for "little" adjustments. Normally, for example, modelines and resolutions are autodetected by the driver and you should not specify them manually (you can also take a look to the detected modelines in /var/log/Xorg.0.log file if you want). Normally to enable armsoc you just need: Section "Device" Identifier "Mali FBDEV" Driver "armsoc" EndSection in 10-armsoc.conf, leave also the "default" armbian configuration file (which should be already in xorg.conf.d directory) and remove everything else. Most of the all the other settings are bogus things you can find in various forum threads. People added them without knowing anything of the driver or mixing configuration options from other drivers, in fact there are no references to such options in the source code. About the missing armsoc_dri.so file, this is expected but should not be harmful for OpenGL ES applications. The slow performance of glmark2 can be related to the very old packaged version shipped with ubuntu/debian. Usually it is always suggested to compile the latest stable source code from sources (which I think can be downloaded from github) for reliable and up-to-date performance. @JMCC is working on a script which install all the drivers and some goodies for RK3399 devices. He already did such script for RK3288 and it is the reference for all the multimedia things for that platform.

If you are using mainline kernel, maybe my armsoc X11 driver fork may work for you configuration. It has been developed on RK3288, but it seems it works good for RK3399 too. It does not require any special X server, just compile it against stock one. It should work well with 2D and give 3D for mali blobs. Some references are here

Why? I'm always using it while doing tests (and also at work, actually) burning SD cards and I encountered no problems so far. I have to admit although I'm using some particular flags to avoid cache (oflag=direct) and large block size (bs=512k). The bad thing that is corrupting very often my burns is an already mounted partition which gets overwritten; I have to remember to unmount all partitions of the SD card before operating on it.

This happened to me when I forgot to unmount the partitions of the SD Card before writing the armbian image on it using dd. About the issue with the bad resolution, you may also try to run your personal dhcp server on your PC, connect the ethernet cable from your PC to the tv box and get a shell using ssh. The following command uses dnsmasq to listen for DHCP packets on eth0 and assign an IP in the range 192.168.2.10 -> 192.168.2.20 when asked by the tvbox: sudo dnsmasq -d --dhcp-range=192.168.2.10,192.168.2.20 -p 0 -i eth0 --except-interface=lo --bind-interfaces

Yeah you can integrate wireguard into the kernel, but you can also use DKMS framework to let it being recompiled each time a new kernel is installed. Wireguard already comes with a small configuration file for DKMS, just follow a tutorial on how to install and setup DKMS on your machine (which is quite easy, just few steps) and register wireguard module and you're done.

Is audio via HDMI working? I'm having issues on my non-tinkerboard rk3288 box, kernel 4.19.6, and I can't figure it out. Also bluetooth is not working (it was on 4.18, broadcom chip attached to /dev/ttyS0). Apparently the DMA Controller (dmac_bus_s) is somehow complaining

The remote keycodes are already fixed ages ago, and it was just a cosmetic issue (I used scancodes instead of human-readable constants, nothing to really worry about) The i2s problem turned out to be a pro777's box issue. The soundcard name in the device tree filters into ALSA device name but is not collected by pulseaudio, but I'm working on it. As a workaround you can add these two lines at the bottom of /etc/pulse/default.pa file: update-sink-proplist alsa_output.platform-soundcard-hdmi.stereo-fallback device.description="HDMI Digital Output" update-sink-proplist alsa_output.platform-soundcard-spdif.stereo-fallback device.description="SPDIF Digital Output"

That's X11 nomenclature which I did not dealt with. It may be Buffer Object or whatever, my main purpose for creating another fork of Armsoc driver was to leverage mainline kernel DRM interface and add hardware mouse cursor for Rockchip. Eventually it turned out that the same driver was "tidied up" to run on amlogic and allwinner devices too and made VSynced page flipping somewhat working. armbian next and dev kernels are both mainline kernels, instead default (or also legacy) is the kernel branch developed by Rockchip. You can use the Armsoc driver in the archive I pointed you both with next or dev armbian kernels (which are mainline), but it won't work with default (or legacy) kernels For my personal experience, it works much better with 2D desktop graphics than modesetting + glamor and allows 3D acceleration too. It is far from being perfect, but it is another choice which works and may better fit some needs. Still working on that pulseaudio issue, trying to find the least intrusive way to define the soundcard description names. Instead I'm not aware about IR remote control codes issues, can you point it out to me?

If you mean issues about the Media Script, no it won't because the issues are of the Media Script (and related things) and not the Armbian image itself. By the way, I'm having discrete satisfaction using armsoc xf86 driver instead of modesetting: it has good 2D performance and 3D works. Videos are still decoded in software, but Kodi and mpv seems to run fine. I'm using the TV Box as desktop replacement (mostly browsing with Firefox) and it works pretty well! If you want to give it a try, I suggest you to start from a fresh image with mainline or dev kernel. Decompress this archive (armsoc compiled driver against X.Org 1.19.6, works only on mainline kernels) into /usr/lib/xorg/modules/drivers and create /etc/X11/xorg.conf.d/10-armsoc.conf with this content: Section "Device" Identifier "Mali FBDEV" Driver "armsoc" EndSection Then decompress also the Media Script and install the Mali drivers with: $ sudo dpkg -i packages/libs/libmali-rk-midgard-t76x-r14p0-r0p0_1.6-1-0armbian1_armhf.deb it should be sufficient to run Kodi and mpv

Hello guys, I'm proud to say that the Q8 boards are now in mainline Armbian as CSC supported boards! https://www.armbian.com/xt-q8l-v10/

Did you take a look into /etc/NetworkManager/dispatcher.d directory to see how the other scripts do? For example, I see that you miss the shebang at the very first lines of your script. edit: also check the double equal (==) in the if statement. If I remember well, there should be a single equal there.

Well, another solution is to patch brcmfmac kernel module to add ap6330 chip and revision. It's a very small patch, just adding another item to the list: diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c index a907d7b06..ec71996c7 100644 --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c @@ -619,13 +619,17 @@ BRCMF_FW_DEF(4354, "brcmfmac4354-sdio"); BRCMF_FW_DEF(4356, "brcmfmac4356-sdio"); BRCMF_FW_DEF(4373, "brcmfmac4373-sdio"); +/* AMPAK */ +BRCMF_FW_DEF(AP6330, "brcmfmac-ap6330-sdio"); + static const struct brcmf_firmware_mapping brcmf_sdio_fwnames[] = { BRCMF_FW_ENTRY(BRCM_CC_43143_CHIP_ID, 0xFFFFFFFF, 43143), BRCMF_FW_ENTRY(BRCM_CC_43241_CHIP_ID, 0x0000001F, 43241B0), BRCMF_FW_ENTRY(BRCM_CC_43241_CHIP_ID, 0x00000020, 43241B4), BRCMF_FW_ENTRY(BRCM_CC_43241_CHIP_ID, 0xFFFFFFC0, 43241B5), BRCMF_FW_ENTRY(BRCM_CC_4329_CHIP_ID, 0xFFFFFFFF, 4329), - BRCMF_FW_ENTRY(BRCM_CC_4330_CHIP_ID, 0xFFFFFFFF, 4330), + BRCMF_FW_ENTRY(BRCM_CC_4330_CHIP_ID, 0xFFFFFFEF, 4330), + BRCMF_FW_ENTRY(BRCM_CC_4330_CHIP_ID, 0x10, AP6330), BRCMF_FW_ENTRY(BRCM_CC_4334_CHIP_ID, 0xFFFFFFFF, 4334), BRCMF_FW_ENTRY(BRCM_CC_43340_CHIP_ID, 0xFFFFFFFF, 43340), BRCMF_FW_ENTRY(BRCM_CC_43341_CHIP_ID, 0xFFFFFFFF, 43340), This will let brcmfmac look for brcmfmac-ap6330-sdio.bin and brcmfmac-ap6330-sdio.txt firmware files, so there is no need for alternative paths. As long as brcmfmac only discriminates among Chip ID and Chip Revision, there is the drawback case where all those devices which have ID:0x4330 and REV:0x4 will be considered as AP6330. After googling around for "BCM4330/4" (a string the driver produces in dmesg), all the sensible results always bind it to AP6330. Although this looks tidier, my preference goes to the former solution because it seems "safer" (no id/revision clashing)

It seems that the eMMC driver has some issues dealing with it. Are you compiling your own kernel or using an already compiled one? AFAIK the eMMC driver is work in progress and in my latest tests (long ago) on 4.18 it was not working at all (or not present, didn't dig through)

I delved into brcmfmac sources but eventually ended up with this: https://github.com/paolosabatino/firmware/tree/master/ap6330 I'm a bit concerned about the brcm symbolic link to self directory, but it is needed for brcmfmac driver compatibility It does not mess up with the existing directory structure and, if needed, bcmdhd driver can use it with proper module parameters. Still requires alternative_fw_path=ap6330, but I think it is could be reasonable to put it into a .conf file in /etc/modules.d

I made some changes to my fork, in particular I reverted back kernel configs to current mainline and just enabled brcmfmac and remote GPIO IR drivers, both as modules. I'm a bit puzzled by brcmfmac firmware handling, in particular the place the driver looks into for the firmware and nvram. Currently I add extraargs=brcmfmac.alternative_fw_path=ap6330 in armbianEnv.txt and firmware files are put in /lib/firmware/ap6330/brcm path. I'm still studying a way to be consistent with armbian-firmware ampak drivers approach, so any suggestion in this sense is appreciated.

You exactly got the point!

Your choice. Doing "experiments" is for people who has the proper skills to do that. As long as you asked, I answered. Never said you or anyone else must do it for any reason. just to be clear, because it looks like I'm bringing people into mysterious and self-destroying practices: perhaps you intend "you have to" as instructions or obligation to follow a suggestion; NOPE. It is intended as "in the case you want to do this, the fullfil your goal the operation to do is ...". So, again, I'm not suggesting anyone to erase their's eMMC, just explaining how the boot thing works (it still looks like the thread title is "s905w boot process?", isn't it?)

Well my box is pretty "standard" (mxq-s905-v20 says the signature on the PCB), and the above procedure works. It's not for the faint of heart, I agree. Anyway, in your setup the binary amlogic blobs and u-boot are on eMMC and then the kernel is took from the SDCard. For the full stack (binary amlogic blobs, u-boot, kernel) to boot from the SDCard you have to remove the bootloader from the eMMC. There is another trick which works with Rockchip SoCs: short the CLOCK pin to ground of the eMMC. Not sure if it works on amlogic SoCs too, but I guess they all follow the same pattern. You may say: "why bothering with erasing eMMC and doing more work for the same...". Well, it's like treating the tv box as the same SBC boards out there rather than a "black box": removing as most blobs as possible to really make the hardware yours.

I truly don't understand what you mean: that's a merge from master I made yesterday to update the project to latest armbian mainline bits. Keeping the repo aligned with mainline armbian, what's wrong with that? About the usage instructions, just compile the armbian the normal way (there will be a new mxq-s905-v20 board to choose) and burn the output image onto an sdcard. Again: to let the tvbox boot from the sdcard, eMMC must be erased.

What do you mean "with error"?