jock

Members
  • Content Count

    146
  • Joined

  • Last visited


Reputation Activity

  1. 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
     
     
  2. 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.
  3. 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.
  4. Like
    jock reacted to JMCC in RK3288 Media Script (TinkerBoard, MiQi)   
    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).  
     
  5. Like
    jock reacted to JMCC in RK3288 Media Script (TinkerBoard, MiQi)   
    Nope, mali binaries take care of everything.
     
    BTW, Bionic version of the script is done, I'm just brushing up the documentation.
  6. 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.
  7. 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
     

  8. 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).
  9. 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.
  10. 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.
  11. 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
  12. 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
  13. 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
  14. Like
    jock got a reaction from olivluca in kodi on armbian?   
    Yes, indeed RPi3 is a good choice. The only drawback is that h.265 being software decoded because the VPU/GPU part has not been updated since their debut, on the other side you get plenty of support by community and foundation, and also an opensource GPU OpenGL driver which works pretty well, as opposite of the crappy blobs for ARM Mali GPUs
  15. Like
    jock got a reaction from olivluca in kodi on armbian?   
    Well, you should at least specify the hardware you want to run armbian and kodi on.
    If your intent is to just run armbian + kodi, usually you get most hardware acceleration (GPU + video decoding) if you use the kernel provided by the hardware manufacturer, but don't expect a warm soup ready for lunch.
    Each SoC is a different story: GPU drivers are not always available (mostly due to ARM Mali license, the most common GPU in SoCs), and sometimes they are misbehaving. It's kind of puzzle-game where not always all the pieces are there to be fit togheter.
     
    At the moment, I don't know any board which works out-of-the box with vanilla armbian.
    Some work has been done by the community for rockchip rk3288 (see here). Rockchip are the most promising because the manufacturer provides documentation and source code and also GPU drivers works.
    Allwinner provides GPU drivers for their old Mali400/450 GPUs. Bootlin reverse engineered the VPU on older SoCs (H3 and going back) to provide hardware acceleration for videos on mainline kernel and apparently some support is appearing in ffmpeg, although I don't know if it is ready to be used.
    AmLogic is unknown to me, I think you should stick to their white-beard old kernel if you want GPU and VPU acceleration
     
  16. Like
    jock got a reaction from chwe in RK3288 Media Script (TinkerBoard, MiQi)   
    @JMCC yes of course, I will do a small tutorial as soon as I have some spare time!
    The compilation process is quite easy to accomplish, although documenting important environment variables is essential
  17. Like
    jock reacted to Myy in HDMI frequencies in the DTS file   
    I've adapted a set of patches from Urja Rannikko, which move the HDMI frequencies definition into the DTS file, with some preconfigured rates if none are defined in the DTS.
     
    The original patches set is here : https://www.spinics.net/lists/arm-kernel/msg673156.html
    The big patch I used as a basis is here : https://github.com/urjaman/arch-c201/blob/master/linux-c201/0020-RK3288-HDMI-clock-hacks-combined.patch
    I included these patches by splitting them again : https://github.com/Miouyouyou/RockMyy/commit/57ff073fffb5678e75959e566704376f6f52ac17
     
    These patches were suggested to me here : https://github.com/Miouyouyou/RockMyy/issues/3
     
    Anyway, after some quick tests, these patches remove the dreaded bar of purple pixels at the left of my HDMI screen, when plugged to Tinkerboard systems and MiQi systems. Note that these bars only appear on my screen when using "good" (enough) USB power supply.
    Still, with these patches, they are gone. However... I only tested these patches on my 60Hz 1080p screen, which is pretty much the de-facto standard screen.
    I'd like to see people test these patches on other HDMI configurations which are known to have some issues with Tinkerboard, MiQi and others RK3288 systems.
     
    So, yeah, if you'd like to test some kernel patches and are not afraid to see your screen go black after a reboot, have a try.
     
    Note : This is completely unrelated with the CEC issue.
  18. Like
    jock got a reaction from Myy in RK3288 Media Script (TinkerBoard, MiQi)   
    Oldies but goodies: a made a quick demo with my smartphone (sorry for the bad quality) of Quake2 running on rk3288 using GL4ES. The game works really well, it is totally playable and there are no issues of any sort 
     
     
  19. Like
    jock got a reaction from guidol in Armbian for RK3288 TV Box boards (Q8)   
    This is an unofficial Armbian variant for XT-Q8L-V10 boards, also known as Chiptrip Q8, Vsmart Q8, ENY 3288 Q8, etc...
     

     
    All source code is available on github as an armbian fork: https://github.com/paolosabatino/build
    To compile armbian images, just follow the official instructions and select "xt-q8l-v10" board.
     
    Prebuilt images:
    Armbian Ubuntu Xenial 5.41 Desktop - Kernel 4.4.126 (legacy)
    Armbian Ubuntu Xenial 5.41 Desktop - Kernel 4.14.39 (mainline)
    Armian Debian Stretch 5.41 Server - Kernel 4.4.126 (legacy)
    Armian Debian Stretch 5.41 Server - Kernel 4.14.39 (next)
    Armbian Ubuntu Xenial 5.59 Desktop - Kernel 4.14.68 (mainline) (eMMC friendly)
    Armbian Ubuntu Xenial 5.59 Desktop - Kernel 4.18.6 (mainline-dev) (eMMC friendly)
     
     
    Instructions:
    First of all, tv boxes comes with an obsolete u-boot. To be able to fully boot from sdcard, the fastest way is to zero-fill the internal eMMC: you won't brick your box, instead it will be forced to boot in Maskrom Mode which, by default, boots from the external sdcard. rkdeveloptool may come really handy for such job. Follow the guide just below or learn some more reference: https://github.com/nolange/rk3288-guide/blob/master/bootloader.md Flash the image on the sdcard, plug it in and push the power button for 1 second (or until it turns blue) Wait some seconds, the led should start blinking soon (HDMI output during boot is not available yet, so just wait for the login prompt, it should be there in less than 30 seconds) As usual, armbian default credentials are user: root password: 1234 If you want to install an image into the embedded eMMC, just prefer an image with the "eMMC friendly" tag above  
    Boot priority:
    Newer images (those with mainline kernel >= 4.14.50) now support booting from multiple devices.
    Priority is fixed and boot devices are probed in this order:
     
    External SD card External USB storage device (Any USB Stick/Hard drive attached to USB host ports; USB OTG port still does not work for booting) Internal eMMC  
    This way even if you install armbian to internal eMMC, you can still easily test different images booting from external devices.
    Experts notes: when armbian is installed into eMMC you get U-boot installed too in eMMC. This is important to know because the box won't boot in Maskrom Mode, but instead will always boot the embedded U-boot, no matter if you put an sdcard/usb stick. In practice the embedded U-boot is totally responsible for the boot priority. If you want to restore the Maskrom Mode, just erase U-boot from eMMC using this command:
    dd if=/dev/zero of=/dev/mmcblk2 seek=64 count=8128 conv=sync,fsync  
    Current status:
    Wireless: works. pretty fast and stable, signal is strong on my box; Bluetooth: works. I was able to transfer files and stream audio without problems USB ports: works, with autosuspend too. A quick benchmark show that transfer rate is quite good (topped at 34 MB/s) USB OTG: works in host mode, no quirks apparently. Transfer rate is very good (> 40 MB/s) MMC: works and is perfectly accessible as storage device. The images above with "eMMC friendly" have been tested and work when installed in eMMC using the standard armbian-config eMMC installer SDCard: works. legacy kernel is limited to high speed, while mainline works fine in UHS mode too. A quick benchmark with a Samsung EVO card shows the promised 48Mb/s read speed. Gigabit Ethernet: works, fast and reliably HDMI: works but may have some minor quirks. Sometime happens that you get a purple vertical line at the very left side of the display or the audio via HDMI does not work. Usually turning off and on the monitor solves both the problems. Serial: works Audio: HDMI audio works, SPDIF connector is enabled and should work too, but I had no chance to test it because I have no DAC at the moment IR remote: works on legacy and mainline kernels Reboot/Suspend process: rebooting the device is a working in progress, at the moment sometimes it works and sometimes it doesn't. Suspend is still not available. Hardware acceleration: everything which works for rk3288 boards applies here too. This guide or maybe the Media Testing Script will help you gain an hardware accelerated X11 and Chromium (using GL4ES I enjoyed Quake 2 from the start till the end, but also Quake and Quake III Arena work flawlessy, here a quick how-to to compile and install GL4ES)  
  20. Like
    jock got a reaction from pro777 in Armbian for RK3288 TV Box boards (Q8)   
    Bump up due to some news:
    New Xenial image with mainline 4.14.68 kernel New Xenial image with latest and greatest 4.18.6 dev kernel (which seems pretty stable to me) Both new images now fully support the IR Remote out of the box, in native mode via kernel keymappings and drivers. Kernel keymap table can be customized using ir-keytable tool. Kernel 4.18.6 also exposes the native lirc interface, so in theory any remote controller can be trained to work with the box Both new images enables the SPDIF connector (it is untested though due to lack of a Optical DAC at home) Added devfreq support for the GPU: at the moment the base frequency is 100 Mhz and maximum frequency is 600 Mhz. The GPU may be too lazy to switch frequency, so you can force a minimum frequency issuing (as root) echo 300000000 > /sys/class/devfreq/devfreq0/min_freq to force the pre-devfreq default operating frequency. You may also force 600000000 (600 Mhz) as minimum to run the GPU always at full speed. Beware the thermals anyway, when the core reaches 70°C it starts throttling and your performance may not be as you expect if you don't cool enough the SoC Every other thing which has been put into Armbian lately is also in the images Enjoy!
     
     
  21. Like
    jock got a reaction from pro777 in Armbian for RK3288 TV Box boards (Q8)   
    Bump up due to some news:
    New Xenial image with mainline 4.14.68 kernel New Xenial image with latest and greatest 4.18.6 dev kernel (which seems pretty stable to me) Both new images now fully support the IR Remote out of the box, in native mode via kernel keymappings and drivers. Kernel keymap table can be customized using ir-keytable tool. Kernel 4.18.6 also exposes the native lirc interface, so in theory any remote controller can be trained to work with the box Both new images enables the SPDIF connector (it is untested though due to lack of a Optical DAC at home) Added devfreq support for the GPU: at the moment the base frequency is 100 Mhz and maximum frequency is 600 Mhz. The GPU may be too lazy to switch frequency, so you can force a minimum frequency issuing (as root) echo 300000000 > /sys/class/devfreq/devfreq0/min_freq to force the pre-devfreq default operating frequency. You may also force 600000000 (600 Mhz) as minimum to run the GPU always at full speed. Beware the thermals anyway, when the core reaches 70°C it starts throttling and your performance may not be as you expect if you don't cool enough the SoC Every other thing which has been put into Armbian lately is also in the images Enjoy!
     
     
  22. Like
    jock got a reaction from Myy in RK3288 Media Script (TinkerBoard, MiQi)   
    Oldies but goodies: a made a quick demo with my smartphone (sorry for the bad quality) of Quake2 running on rk3288 using GL4ES. The game works really well, it is totally playable and there are no issues of any sort 
     
     
  23. Like
    jock reacted to Myy in RK3288 Media Script (TinkerBoard, MiQi)   
    The Mali driver can use devfreq, and has various ways to be told how to vary the frequency of the GPU.
    Now, I've been informed recently that a patch is necessary on mainline kernels to avoid some Mali Devfreq related warnings and panics.
    A modified version of the patch is available here : https://github.com/Miouyouyou/RockMyy/blob/master/patches/Midgard/r19p0-01rel0/0010-GPU-Mali-Midgard-remove-rcu_read_lock-references.patch
    The original is here : https://github.com/mihailescu2m/linux/commit/bbe73c3c1143e5991bdcaee3afaecf5c31af0647
     
    That said, if you want to push the Mali GPU to higher limits, you can do something like this :
    cd /sys/class/misc/mali0/device/devfreq/devfreq0/ echo `cat max_freq` > min_freq echo 10 > polling_interval This will force the GPU to be at its highest clock rate constantly (supposedly, I have no way to actually verify that).
     
    Now, let's be clear, if you launch a GPU intensive task with these settings, while not having a beefy stable power supply, the board might just shut down or not provide any performance gain. Now that's mostly the case for USB power supplied board.
     
    Still, these settings provide good performances gain on some benchmarks, very little on others. Frequency alone won't help you overcome bad optimizations. Also sometimes performances issues become CPU bound as the GPU gets faster.
     
  24. Like
    jock reacted to TonyMac32 in U-boot v2018.05 and RK3288 not working?   
    U-Boot 2018.05-armbian (Jul 02 2018 - 00:54:54 -0400) Model: Tinker-RK3288 DRAM: 2 GiB PC event = 0x20 usb connected to SDP, force enter ums mode rk3288_maskrom_ctrl: enable_emmc = 1 usb_current_limit_ctrl: unlock_current = 1 MMC: dwmmc@ff0c0000: 1, dwmmc@ff0f0000: 0 Loading Environment from EXT4... ** Unable to use mmc 0:auto for loading the env ** Failed (-5) In: serial Out: serial Err: serial Model: Tinker-RK3288 Net: failed to enable clock 0 No ethernet found. UMS: LUN 0, dev 0, hwpart 0, sector 0x0, count 0x1d5a000 \wait for usb get descriptor cmd timeout rk3288_maskrom_ctrl: enable_emmc = 0 usb_current_limit_ctrl: unlock_current = 0 Hit any key to stop autoboot: 0 Card did not respond to voltage select! switch to partitions #0, OK mmc1 is current device Scanning mmc 1:1... Found U-Boot script /boot/boot.scr 1498 bytes read in 17 ms (85.9 KiB/s) ## Executing script at 00000000 U-boot loaded from eMMC 178 bytes read in 14 ms (11.7 KiB/s) 41042 bytes read in 35 ms (1.1 MiB/s) 4908082 bytes read in 238 ms (19.7 MiB/s) 9272512 bytes read in 433 ms (20.4 MiB/s) ## Loading init Ramdisk from Legacy Image at 21000000 ... Image Name: uInitrd Image Type: ARM Linux RAMDisk Image (gzip compressed) Data Size: 4908018 Bytes = 4.7 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 01f00000 Booting using the fdt blob at 0x1f00000 Loading Ramdisk to 0fb51000, end 0ffff3f2 ... OK Loading Device Tree to 0fb43000, end 0fb50051 ... OK gets right to starting kernel.  The delay is the dev kernel I was building.
  25. Like
    jock reacted to TonyMac32 in U-boot v2018.05 and RK3288 not working?   
    I tried it last night without any UART connection, it took it about 5 minutes to boot.  So I'm not certain what's going on, I have some other stuff to work on first in any case.