jock

Members
  • Content Count

    244
  • Joined

  • Last visited

 Content Type 

Forums

Member Map

Store

Crowdfunding

Raffles

Applications

Everything posted by jock

  1. jock

    s905w boot process?

    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.
  2. jock

    s905w boot process?

    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.
  3. jock

    s905w boot process?

    What do you mean "with error"?
  4. jock

    s905w boot process?

    Not according to this: http://openlinux.amlogic.com:8000/download/doc/linux-3.14-buildroot-pkg-201512-release-v1.0.pdf Chapter #4, paragraph #3, bullet #5
  5. jock

    s905w boot process?

    1. Never said the user has to erase the regular u-boot on TV box. Just said that the best way (the only way, AFAIK) to boot u-boot (the "bootloader") from sdcard is to erase the first sectors of the eMMC. If you have another method, please post it because I'm very interested. 2. Read better. You can: https://github.com/paolosabatino/armbian-build/tree/mxq-s905-v20
  6. 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.
  7. jock

    s905w boot process?

    As far as I know, you're running a customized armbian which does the boot in a different way due to the fact that tvbox have u-boot in their eMMC: the SoC first checks the eMMC and, if it finds a valid boot loader, starts from there. The best way to force the SoC to boot from an sdcard is to zero-fill the first sectors of the eMMC: the SoC is not able to find a valid bootloader on eMMC and will then try to boot from sdcard. I don't know the usage of the scripts you mentioned at point 2 because they are not part of armbian. The boot process on amlogic boards begins loading a binary beginning at the second sector of the eMMC/sdcard. The binary is an assembling of amlogic blobs (clock and ram initialization) and u-boot. In your actual condition, u-boot scripts on eMMC have been modified (via u-boot environment variables) to first check the SDcard for a valid kernel + initramfs + device tree combination. In summary what happens on your tv box is this: You turn on the board The SoC checks for a bootloader on eMMC, finds it and boots from eMMC Amlogic binary blobs are read from eMMC. They initialize the clock, ram and other low level things. The legacy amlogic u-boot is started from eMMC U-boot initializes its own things (USB, SDcard, etc...) and reads the "environment" variables from a sector of the eMMC. The boot scripts are part of the environment variables: once they are altered in the right way, they first check the SDcard for a boot descriptor U-boot finds the descriptor on the ext4 partition of the sdcard (it looks for uEnv.ini or extlinux.conf somewhere in /boot directory of the first partition) U-boot loads the kernel + initramfs + device tree pointed by the descriptor in RAM and transfer control to the kernel If you zero-fill your eMMC, the process changes from step 2 onwards: after a failed attempt to start a bootloader from the eMMC, the SoC queries the sdcard and boots from there. The boot process of amlogic is a bit involved due to the binary blobs which, as far as I know, must be built using the amlogic legacy u-boot source code and tuned for your specific hardware (ddr frequency and size, mostly) and debugging without a serial attached to the board can be really hard. Once you get the binary blobs, you can use them to build a pure vanilla armbian which boots mainline u-boot from sdcard
  8. Hello, before even thinking about arranging a CSC board bring up pull request to armbian, I would be pleased to know if it sensible to do that for a TV Box which is not sold anymore but still quite powerful because of its rk3288 SoC. I made my own fork of armbian (see here). I tried to do things the most tidy way, following the best practices learnt from the documentation. The box has very good support now, but requires some initial setup to clean the eMMC. Also I made some customizations to kernel configs which, I guess, should be moved away (mali driver compiled by default, devfreq support, brcmfmac driver for AP6330 wifi, maybe other things...) Any opinion is welcome!
  9. Try to run fdisk /dev/mmcblk0 and then issue the command p to take a look to the real partitions on the device
  10. Thanks for reporting back all these infos! At the moment I'm looking into pulseaudio "Build-in Audio Stereo" issue for both SPDIF and HDMI. A little trick to know who is who is to click on the speaker on the upper right corner, then go to "Default Sink" and then hover the mouse cursor on a label: there should appear a large overlay with many details about the sink, including the hardware name. I'm also experimenting with xf86-video-armsoc driver, which provides a very smooth desktop experience. Some drawbacks are the lack of vsync (can be annoying watching videos), and some strange issues with fullscreen: kodi and glmark2 don't update their content, but quake/quake2 works really well. By the way, I still did not experience any lockup or freeze using it.
  11. Just built this new Armbian Bionic 5.65 - dev kernel 4.18.16, which seems to work quite well with the updated Media Script by @JMCC for Bionic, but still no hw acceleration for video decoding. This build raises a kernel error about an "Unbalanced IRQ", but the system is stable and the functionality does not seem to be hindered. I also built a default rockchip kernel image. but does not boot. I'm thinking to build the rockchip kernel without armbian patches to see if it is definitely in a bad state or there is some misconfiguration or patch triggering issues. For this you have to wait some time :/ edit: I see from the armbian commits that rockchip kernel has been forked by Armbian people, maybe there's a good chance to get something stable soon...
  12. You're doing it the hard way. Just add extraargs=isolcpus=2 in /boot/armbianEnv.txt and you're done
  13. GPU acceleration works perfectly on latest dev kernel (4.18.16), desktop with experimental xserver also is quite usable. Thanks!!
  14. HDMI has still some minor issues: it may happen that a purple vertical line appears on left edge of the screen, or audio does not work. Normally it is sufficient to turn the monitor off and on and purple line disappears and audio comes back. Pulseaudio also has some issues with labels, but I2S should be in reality HDMI (on my setup both SPDIF and HDMI appears as "Analog audio" ) Some trick you may try: 1) Disable compositing from Menu -> Settings -> Window Manager Tricks - this is pretty essential for decent desktop speed 2) The image you are using probably has devfreq compiled in. Devfreq handles the GPU frequency dynamically, but at the moment it is not so "dynamic" and keeps the GPU at lowest frequency (100 Mhz). Anyway the good thing is that you can change the frequency of the GPU at manually invoking echo 300000000 > /sys/class/devfreq/devfreq0/min_freq as root to force the GPU to run at least at 300 Mhz (which is the default frequency without devfreq). 3) Be sure that OpenGL ES setup is in place (use es2_info for that) and be sure that MPV uses OpenGL ES rendering. This is important because otherwise screen blitting happens on slow software paths I also installed packaged Kodi (Isengard), which was pleasantly working. I planned to raise a bit the throttling temperature, maybe at least 75°C. It should be relatively far from the critical threshold (apparently 90°C). Also it would be interesting to see what happens turning down the voltage at highest speeds, just to see what is the limit for the SoC. This can be done via device tree, but providing additional device trees can be problematic.. At the moment I compiled a couple of new images (default and dev kernels), but the recent bump of u-boot to v2018.09 broke something and they don't boot. I hope to sort things out this weekend
  15. Mmmh, I'm sorry the default kernel images don't work, but I'm not surprised. Those were some test images I did to poke around and see if the mainline kernel was in a working state or not. Anyway, the overheating problem is actually real on default images, which as far as I remember, don't have an overheating temperature control, so probably you guessed right. You may limit the speed of the cores using cpufreq-set and install a heatsink, which is a must have for rk3288 Mainline images instead have the thermal driver working and start throttling when the CPU or GPU reaches 70°C. armbianmonitor -m command may be useful to monitor the temperatures in realtime. By the way I prefer to use mainline images for my own general usage even though there is no video acceleration for the moment, latest 4.18 kernel also proved to be quite stable in my experience. I will try to make a new default image soon to see if it is working, I will let you know. edit: about the phase shift of the pixel clock, it's something I noticed on my fullhd monitor also and only on default kernels. Rockchip people removed some clock entries from the device tree which made HDMI and serial work really bad. I opened an issue about that, but noone did care about. I restored the missing entries in my branch and HDMI was working again, but still I have some artifacts in the form of horizontal flashing colored lines, which is clearly related to bad clocks
  16. Oops! Thanks for pointing me the dead link. Legacy kernel is developed by rockchip itself, in the last months they made some breaking changes which produced unstable or crashing images. I actually removed the image with kernel 4.4.132, but you may try these test images: Armbian Xenial 5.59 4.4.159 Armbian Xenial 5.59 4.4.153 Armbian Xenial 5.59 4.4.152 Armbian Xenial 5.52 4.4.139 Be aware there's a good chance they crash at boot without anything on screen. if you report any of them which works decently for you and does not crash I will put it in the first post. Otherwise I'm pretty sure the 4.4.126 image was working fine. About the media script, it is quite straightforward and should work flawlessy. I'm eagerly waiting for JMCC to publish its latest updated work for Ubuntu Bionic, when it will be available I will publish some Bionic images too
  17. Hi! The images are vanilla armbian, so they don't have video drivers installed; though in the first post of this thread you can find a link to the media script thread for RK3288 provided by @JMCC which downloads and installs all the necessary bits for GPU drivers and VPU libraries for hardware video decoding. Hardware video decoding works only on legacy 4.4 kernel, GPU acceleration instead works fine up to latest 4.18 kernel. To check if GPU drivers are correctly installed you can install mesa-utils-extra package and run es2_info utility, which should report ARM Mali T76x as OpenGL ES renderer (if it reports LLVM, then you are using software rendering)
  18. I agree, doing a backup of the boot partition is highly advisable before doing kernel update (even apt-get upgrade), expecially if you are running a non-official armbian. Normally the upgrade scripts do a copy of the old kernel/initrd themselves, but very often I lost some files in the process. It is quite time consuming and annoying try to restore the old kernel from working images
  19. Yes, of course. the kernel completely resides in memory once the system is booted, so you can update it safely.
  20. There's also a bigger model (c400). This is exactly what I was talking about "no support from manufacturer" when dealing with tv boxes; you're on your own. edit: BTW I see that c300 is a s905d devices, but your link points to some documentation about a s912 device, maybe they are not the same device PS: for the chronicles, this could be interesting just to say I was in good faith when I was talking about H3
  21. there also was something by another manufacturer (magicsee) with the same s905d, maybe you are luckier with that
  22. 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.
  23. I tried it, but only on a Raspberry Pi 1 Model B. At work we use OpenVPN but are planning to switch to wireguard as soon as possible. I did some cheap benchmark to see if it worths and turned out that it worths! Wireguard on such old machine (ARMv6, without NEON) was 3x faster than OpenVPN against a simple download of a file (900 kb/s vs 3.2mb/s) and latency was actually a bit better. I didn't test more powerful ARMv7 and ARMv8 machines, but I expect the gap to be even bigger. On the opposite side, you lose some ancillary nice things OpenVPN has like pushing the routes on connections, automatic IP assignment, etc... Also running a DHCP service on the server is impossible because Wireguard lays on top of IP protocol
  24. 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.
  25. I changed my device tree to add HDMI frequencies and other things exactly as described in rk3288-veyron-chromebook.dtsi. The result is that the device boots and HDMI seems fine. Again changing resolutions via xrandr works and all resolutions I tried worked (1920x1080, 1280x720, 800x600, 1680x1050) but sometimes the purple line is still there. Also it seems that the purple line appears much often when I physically turn the monitor off and on than when I change resolution via xrandr. Also when the purple line is there, HDMI audio does not work. The fact that HDMI audio goes away and gets back once in a couple times makes me think about a flag that does not reset or so...