jock

Members
  • Content Count

    175
  • Joined

  • Last visited


Reputation Activity

  1. Like
    jock reacted to Myy in The VPU driver   
    You should like my Wayland example, then :3
     
    Anyway, I see that Ezecquiel Garcia is currently pushing patches to adapt the V4L2 patches from Ayaka, into something that works with V4L2 (and a few modifications) without the MPP layer in-between.
    He pushed support for MPEG-2 decoding support... I'll see if he pushes support for H264 this week.
    If not, I'll try to adapt Ayaka's patches.
  2. Like
    jock reacted to Staars in Proof of concept - Realtek 1295   
    Just a tiny update. Booting from SSD works as expected:
     
    It is not completely free of error messages, but it is quite okay'ish.
     
    I will try to update my first post in order to gather the most recent information there. 
  3. Like
    jock reacted to TonyMac32 in RK3288 Media Script (TinkerBoard)   
    Pssssst:
     

     
    So, this has @Myy's work with the patchset that got dropped on the mailing list for vdec, I've gotten everything building properly (minus a wireless driver and we don't have 1.7 and 1.8 GHz opps)
     
    I ran the media script ans installed everything.
     
    I'm watching a 1080p mp4 at fullscreen, here is my armbianmonitor -m:
     
    Time CPU load %cpu %sys %usr %nice %io %irq CPU C.St. 05:41:25: 1608MHz 1.00 20% 3% 16% 0% 0% 0% 51.7°C 0/11 05:41:30: 1608MHz 0.92 20% 3% 17% 0% 0% 0% 50.4°C 0/11 05:41:35: 1608MHz 0.92 21% 3% 17% 0% 0% 0% 50.4°C 0/11 05:41:40: 1608MHz 0.93 19% 3% 15% 0% 0% 0% 51.2°C 0/11 05:41:45: 1608MHz 0.93 20% 3% 17% 0% 0% 0% 50.4°C 0/11 05:41:50: 1608MHz 0.94 21% 5% 16% 0% 0% 0% 51.7°C 0/11 http://ix.io/1zbd
     
    As for functionality, gstreamer does not seem to want to work, so I would guess the vdec isn't operational yet, or something isn't quite right.  In any case, there is hope, perhaps.  ;-)
  4. Like
    jock got a reaction from TonyHCM15 in Miqi board RK3288   
    I don't have a MiQi, but AFAIK armbian-config should already do what you ask
  5. Like
    jock got a reaction from TonyMac32 in USB Serial Support not working   
    I can confirm that latest armbian with next kernel (4.19) on rk3288 works flawlessy with prolific USB-to-serial adapters:
    15567.072909] usb 2-1: new full-speed USB device number 2 using dwc2 [15567.281604] usb 2-1: New USB device found, idVendor=067b, idProduct=2303, bcdDevice= 3.00 [15567.281616] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [15567.281623] usb 2-1: Product: USB-Serial Controller [15567.281630] usb 2-1: Manufacturer: Prolific Technology Inc. [15567.318362] usbcore: registered new interface driver pl2303 [15567.323408] usbserial: USB Serial support registered for pl2303 [15567.323550] pl2303 2-1:1.0: pl2303 converter detected [15567.327312] usb 2-1: pl2303 converter now attached to ttyUSB0 I use it daily with Arduino IDE to develop and push things to ESP8266 and works without issues.
  6. Like
    jock reacted to Staars in Proof of concept - Realtek 1295   
    Hi,
     
    after reading the very entertaining thread regarding the BPI-W2 and the following opening of the bsp-kernel on github, I became curious and when prices dropped for the Lake-1-TV-Box, I decided to play around with it.
     
    Without very much documentation there was a bunch of trial and error and still many things are not absolutely clear to me, but finally I could boot an armbian build today:
    _ _ _ | | __ _| | _____ / | | | / _` | |/ / _ \ | | | |__| (_| | < __/ | | |_____\__,_|_|\_\___| |_| Welcome to ARMBIAN 5.68 user-built Ubuntu 18.04.1 LTS 4.9.119-rtd1295 System load: 1.49 0.74 0.31 Up time: 3 min Memory usage: 4 % of 1631MB IP: CPU temp: 46°C Usage of /: 11% of 7.2G [ General system configuration (beta): armbian-config ] New to Armbian? Check the documentation first: https://docs.armbian.com Thank you for choosing Armbian! Support: www.armbian.com  
    This is still connected over the serial port and completely untested. I had to use the strange chained double-u-boot and load kernel and dtb manually (from raw sd card sectors), so it is not even close to alpha. But it seems, that this can be improved. 
     
    I plan to make a repeatable build config, but do not expect some really usable stuff anytime soon.  The situation with the lack of mainline support was already discussed in the other thread and the future does not look very bright here.
    This is more or less a personal playground at the moment. But if anyone is interested, you can leave comments or questions here.
     
    Sticky part (updated 20-02-2019):
     
    RTD1295-Devices:
          Tested: Lake 1 Home Cloud TV Box
          Untested: Beelink SEA 1, Zidoo X9s, Zidoo X8, Zidoo X10,  Probox2 AVA, WD My Cloud Home, ...
     
    All development and tests thus far have been done on the Lake-1-TV-Box. It can not be ruled out, that the other boxes have other u-boot-versions/-configurations.
     
    Prerequisites:
    Mandatory:
    Serial connection soldered to the PCB (to reach the u-boot-shell) and a suitable terminal software. Further information here: https://en.opensuse.org/HCL:Lake1 (I can not confirm that „SD rescan“ does not work. Only „fatls“ and „fatload“ never worked for me, that’s why raw sector reads are used.)
     
    Recommended:
    Access to a Windows-PC, a USB-male-to-male-cable and the knowledge to re-flash the device by yourself.
    If you are not comfortable in doing this, DON’T DO IT!!! YOU CAN BRICK YOUR DEVICE FOREVER !!
     
    Current installation process (booting from SD-Card):
    Build a full-OS-image with armbian selecting „lake1“ from this fork: https://github.com/Staars/build. This will create an image with kernel image and dtb written to sectors before the root partition. The u-boot-build of armbian is not used. Write the image (using etcher) to an SD-card. For the moment we will not touch the eMMC of the target device and therefore will work as non-destructive as possible. This might change in the future and it should be no problem to implement a eMMC-only solution, but at the moment there is no solution in sight, that would let you dual-boot Android and Linux. Create a terminal connection to the serial pins of your target device and intercept the boot process immediately after power up to reach the first u-boot-shell. Now we have to edit the BOOTCMD the following way: env edit bootcmd sd read $kernel_loadaddr 800 954a; sd read $fdt_loadaddr a440 5d; env set bootargs earlycon=uart8250,mmio32,0x98007800 console=ttyS0,115200 noinitrd root=/dev/mmcblk0p1 rootfs=ext4  init=/sbin/init; b2ndbc; bootr env save  
               This is a relatively harmless operation and can be reversed with the insertion of 'bootr' in step 2.
               The Android-installation on the eMMC stays untouched.
     
       4. Now at every boot the device will initialize the SD (which can fail!!), load the image and dtb, change the bootargs and call the second u-boot, which then will (hopefully) boot the kernel. 
     
    U-boot:
    At the moment u-boot will be build, but not used. Because of bootloader encryption this will likely stay that way. We can build the fsbl-parts, but without the proper encryption the boot stops, when the first part (hw_setting) is loaded. 
    A separated u-boot-fork at https://github.com/Staars/u-boot-rtd is used for the armbian build, but that does not really matter. We must use the vendor-u-boot and we can not do real scripting (no RUN-command) but only chaining of commands.
     
    Kernel:
    The starting point from Sinovoip was labeled 4.9.119, but this is very likely not the whole story. Some parts are even newer and some are probably older, given the fact that git-cherry-picking showed possible updates when used with the stable linux-4.9-branch below tag:4.9.119.
    The additional phoenix drivers were partly integrated in the kernel-fork on https://github.com/Staars/linux-kernel-rtd/tree/latest_patched as an extra folder to keep them in one place.
    If there should be really an adoption of this platform in the future, it might be a good idea to go the other way around and merge the soc-specific parts into a generic linux-4.9.-fork. This is a bit of work, but it should be possible.
    The fork ist currently patched to 4.9.159.
     
    DTS/DTB:
    This is a minimal changed version for the banana-pi w2. 
     
    Bluecore.audio:
    I do not really know if this (audio firmware?) is useful outside of Android. It is written to the SD-Image (directly behind the DTB), but not loaded.
     
    What works:
    -SATA-port (incl. booting with /root on SSD with bootarg 'root=/dev/sataa1')
    -WLAN (onboard 8821AU), but there are very short freezes every few seconds
    -simple software install (i.e. OMV)
    -reboot/restart works, but can take some time
    -bluetooth
     
    What does NOT work:
    -bluetooth
    -halt/restart
     
    Things to do:
    -waiting for someone, who confirms, that this is repeatable on other setups
    -working on the DTS/DTB
    -test Ethernet, USB
    -HDMI-in/-out or graphics in general (very low priority for me)
    -eMMC-only-install (must check first, where it is safe to write data)
     
  7. Like
    jock got a reaction from lanefu in Is Mali GPU driver available in Mainline for H3?   
    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.
     
     
     
     
  8. Like
    jock got a reaction from chwe in Integrate WireGuard into kernel   
    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.
  9. Like
    jock got a reaction from chwe in Integrate WireGuard into kernel   
    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.
  10. Like
    jock got a reaction from pro777 in CSC Armbian for RK3288 TV Box boards (Q8)   
    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/
  11. Like
    jock got a reaction from pro777 in CSC Armbian for RK3288 TV Box boards (Q8)   
    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/
  12. Like
    jock got a reaction from Igor in CSC support for discontinued rk3288 tv box?   
    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)
  13. Like
    jock reacted to PiotrO in s905w boot process?   
    Guys,
    I think we need to distiguish booting from sd and _unattended_ booting from sd.
    In case of my hw (tx3-mini) I think unattended boot from sd is NOT possible without erasing[modifying] eMMC bootloader.
    I think so as IPL by default is passing control to eMMC.
    So if we want unattended boot from SD - we MUST:
    1\ change eMMC content
    2\ modify IPL
    As IPL is in ROM (I think) -  only option 1\ is choice.
     
    Reasonably written IPL should have fall-back to SD[USB] if SPL from eMMC fails (i.e. for case when flash ageing leading to data rot). In such case IPL should offer recovery by booting from SD and refresh eMMC SPL.
    So I agree with initial @jock answer as IMHO his intention was to describe what needs t be done to have tv-box _unattended_ boot from sd
     
     
  14. Like
    jock got a reaction from chwe in CSC support for discontinued rk3288 tv box?   
    My plan is to reset the kernelconfigs from common base and enable brcmfmac and IR (and ancillary config options) as modules when possible.
    Devfreq support and other things were just test bits that can be left out.
     
    If AP6330 firmware binaries could make into armbian firmware repository I can remove the copy work in rockchip.conf - I can arrange a pull request myself for that.
  15. Like
    jock got a reaction from chwe in CSC support for discontinued rk3288 tv box?   
    My plan is to reset the kernelconfigs from common base and enable brcmfmac and IR (and ancillary config options) as modules when possible.
    Devfreq support and other things were just test bits that can be left out.
     
    If AP6330 firmware binaries could make into armbian firmware repository I can remove the copy work in rockchip.conf - I can arrange a pull request myself for that.
  16. Like
    jock reacted to JMCC in RK3288 Media Script (TinkerBoard)   
    Finally, the version 2.0 for Armbian Bionic is out! Check the OP for documentation and download link.
     
    CHANGELOG:
    Updated all necessary packages to work with Ubuntu Bionic Updated versions of MPV and Kodi Added the GL4ES wrapper, to provide OpenGL support (thanks @jock for the tips). In order to use it, you must launch your app from command line using the wrapper "glrun" RELEASE NOTES:
    I'm not sure whether the Widevine library is still working with newer versions of Chrome, and I don't have access to Netflix anymore to test it. Some feedback on this point is welcome. I'm still including the old cgminer as OpenCL example. If you want to try more recent algorithms and experiment with GPU mining just for fun, I recommend you to have a look to this sgminer for from the ODROID community (it works also with RK3288): https://github.com/hominoids/sgminer-arm As I said, just for learning, curiosity or fun. Trying to get money with a Tinkerboard is a waste of time. Plus, I think the whole crypto-mining idea is absurd, basing the value of a currency on wasting as much electricity as possible  Remember you need a default (4.4.y) kernel for HW video acceleration to work. It is not yet implemented in mainline (4.14.y).  
     
  17. Like
    jock reacted to JMCC in RK3288 Media Script (TinkerBoard)   
    Nope, mali binaries take care of everything.
     
    BTW, Bionic version of the script is done, I'm just brushing up the documentation.
  18. Like
    jock reacted to Igor in Monitoring your system health with HTOP (big.LITTLE)   
    ... and I have build it and pushed to Armbian stable repository (Stretch, Xenial and Bionic; armhf+arm64). First boot scripts also creates CPUfreq config based on CPU count. More can be added if there is an interest ... Package can be installed via apt update and upgrade while auto config feature will work only on self made images.
  19. Like
    jock reacted to @lex in Monitoring your system health with HTOP (big.LITTLE)   
    Just In case anyone is interested I have pushed HTOP 2.2.1 to github, so it is possible to monitor big.LITTLE cores in real-time.
    You can view the big.LITTLE in action, Vcore, Cpu thermal throttling and Cpu frequency for each big or LITTLE core.
     
    HTOP is a nice console graphical tool for system-monitor, process-viewer and process-manager.
    DEB package and source code in case you want to extend or fix things.
    Be aware the process list and task can be very intrusive if you want to monitor many things at once.
    It has been tested on NanoPi M4 (thanks to FriendlyElec for the samples) but should work on any SBC just adjust the Vcore path for different kernel version.
     
    https://github.com/avafinger/htop-2.1.1_enhanced-version
     

  20. Like
    jock reacted to olivluca in kodi on armbian?   
    I never thought you were in bad faith. Pity that my orange pi pc is in active use as my doorbell otherwise I could test it (though by reading the thread it seems there's still a lot of work to be done).
  21. Like
    jock got a reaction from olivluca in kodi on armbian?   
    You're absolutely right, so let's back on the tracks.
     
    A tv box is very handy if you're going to use it like a tvbox or some headless servering, here boxes with S905X are all around and mostly work good.
    If you want an all-purpose device which you can use for development, kodi, interfacing to arduino, with best all-around compatibility and don't want to bother with GPU and VPU issues, take an RPi3 (maybe latest Model B+), but here you have to resign to some "latest and greatest" (hw decoding for H.265 most of all, but also capped gigabit ethernet and the ethically discutible BLOB firmware)
    If you want to try armbian, get GPIO and be on the edge about performance and features, but also unable to use some features because of chipset manufacturers, you can select any board which sports Allwinner, Amlogic or rockchip (OrangePi, Odroid, Libre Computer, ...). This is the most adventurous and can be both satisfactory and frustrating when see you can't reach the goal (the same applies with tvboxes too, somewhat amplified)
     
    Maybe this link can be helpful to clarify current hardware accelerated video status for various chips.
  22. Like
    jock got a reaction from olivluca in kodi on armbian?   
    1. Can you provide a link where I said H3 with Armbian + KODI has full HW support? Those are NOT my words, I said something completely different in the purpose to give the OP an idea of the actual state of the art about the various chips, not trying to sell him something!.
    2. Glad to hear, but developers are saying that's far from being usable, and the same applies for others too. But just stick to the thread "Kodi + Armbian" - not "S905X on LibreELEC" - would you?
    3. The differences between utgard and midgard gpu architectures are totally irrelevant to this thread
     
    That's your opinion, which may be respected but from my point of view is completely wrong. Start from vanilla Armbian and tell me how many steps you need to get GPU and VPU working for your favourite chip.
     
    My rk3288 tvbox was nothing more than a brick a couple of months ago, stuck with Android 4.4, before I poured time and time to bring armbian on it... hardware is nothing without software support, and software support for tvbox is totally absent. Suggesting to buy an unsupported chinese tvbox for a person who asked something completely different is intellectually dishonest.
  23. Like
    jock got a reaction from olivluca in kodi on armbian?   
    No non-sense, the OP asked for hardware acceleration and preferably mainline kernel, so the thing which scores the most this sense is H3, with all the cons I wrote in the post you quoted (plus the fact that I'm not fond of allwinner which is by far the most non-opensource company of the group).
    AmLogic has no committment for mainline kernel and hardware video decoding is missing in mainline (linux-meson.com says "No" "WiP"), so to stay stick to the original question (armbian + kodi) is a step behind the H3. Now you can use it with the legacy kernel and get all the nice things working on a carefully crafted armbian image, but with an ancient kernel.
     
    The summary of all this is that armbian + kodi requires a decent amount of exercise either because armbian target is not multimedia and because the "best" SoC here has still several missing things.
    That's also the reason why many people said buy a RPi3 which has all the USB ports, GPIO, hardware acceleration (with the notable exception of H.265), 64 bits, chips, fries and desserts for the miserable price of €35
  24. Like
    jock got a reaction from olivluca in kodi on armbian?   
    No non-sense, the OP asked for hardware acceleration and preferably mainline kernel, so the thing which scores the most this sense is H3, with all the cons I wrote in the post you quoted (plus the fact that I'm not fond of allwinner which is by far the most non-opensource company of the group).
    AmLogic has no committment for mainline kernel and hardware video decoding is missing in mainline (linux-meson.com says "No" "WiP"), so to stay stick to the original question (armbian + kodi) is a step behind the H3. Now you can use it with the legacy kernel and get all the nice things working on a carefully crafted armbian image, but with an ancient kernel.
     
    The summary of all this is that armbian + kodi requires a decent amount of exercise either because armbian target is not multimedia and because the "best" SoC here has still several missing things.
    That's also the reason why many people said buy a RPi3 which has all the USB ports, GPIO, hardware acceleration (with the notable exception of H.265), 64 bits, chips, fries and desserts for the miserable price of €35
  25. Like
    jock got a reaction from olivluca in kodi on armbian?   
    Maybe all the things you want may be found in an Allwinner H3 box, probably the best choice for armbian is Beelink X2 which is supported out-of-the-box.
    Pros:
    Cheap (below 30$) Have decent support in mainline linux, thanks to the effort of the community GPU drivers can run Bootlin works for reverse engineering the VPU and thus hardware video encoding and decoding Cons:
    The SoC is a bit old nowadays (Cortex A7) The GPU is quite old (Mali 400) The GPU drivers are quite horrible (but if you just run Kodi they should suffice) and have no vsync I don't what is the status of the VPU hardware video decoding now, probably will require some months to mature. Maybe ask on Kodi forums about would turn out to be interesting  
    Otherwise the most decent thing which has everything you ask, but not in mainline but fairly recent kernel, is rockchip family (rk3288/rk3328/rk3399).
    However, except for the Beelink X2 (Allwinner H3) which are supported out of the box by armbian, it's a matter of luck getting a tv box and hoping everything works. I have a discontinued rk3288 tv box which is capable of being a decent media center, but I spent several weekends to reverse engineer lots and lots of details to make it useful (but now I can proudly write this comment from it )
    AMLogic has the oldest kernel of the group, dunno what is the status of mainline kernel but I think they did not release their customized GPU drivers at all