All Activity

This stream auto-updates     

  1. Past hour
  2. have you tried swapping SD+PSU+cable to rule out any hardware issues?
  3. You can query all supported resolution on the device using xrandr. I think the command is 'xrandr -q'. But you may want to check the manual for xrandr. -R
  4. I have used this dtb file 'sun50i-h6-tanix-tx6.dtb' which I believe should be the one to be used for this device. I think I will try one of the other H6 boxes available in the market. Will probably need the right dtb for that too! You sure know the topic in depth. Thank you for these insightful information, -R
  5. Today
  6. @Rajesh - if you really reach > 130 c celsius then i think either the thermal sensor is not properly calibrated and/or the cpu-throttle-cooling-device is not/not properly defined in the dtb - usually the cpu clock is reduced when the cpu gets too hot to cool down ... on the h6 without proper cpu voltage handling (like in tv boxes) this down clocking might not be aggressive enough ... not sure if something like this: is in @balbes150 tree already and if it is it might still be not aggressive enough for h6 tv boxes as they have to be clocked down massively to really get the temperature down a bit as the voltage stays by cheap design the same all the time ...
  7. I tried to force the 1366x768.bin that is present at my /usr/lib/firmware/edid by adding this line to uEnv.txt extraargs=drm_kms_helper.edid_firmware=HDMI-A-1:edid/1366x768.bin video=HDMI-A-1:1366X768@60 but the only resolution that I get is 1360x768@60
  8. Hi! my nextcloud instance on an odroid hc2 running armbian has been running stable and smoothly for several months now. Thanks Igor and the whole armbian team! I have one question though: Task: I convert videos with ffmpeg to reduce file size and optimize them for streaming observed behaviour: the CPU is getting very hot! In the evening up to 100 °C (see below), but at noon I have seen temperatures of up to 115 °C! I read somewhere that 110 °C is the critical temperature for the board and the stock hardkernel image has an emergency shutdown implemented. But my board running armbian seems to be negligent of this. On a side note, the CPU frequency reported in armbianmonitor -m is 1800/1300, in htop all 8 cores show 1300 ( .LITTLE)? expected behaviour: shouldn't the CPU be throttled automatically? excerpts from armbianmonitor -m: Stop monitoring using [ctrl]-[c] Time big.LITTLE load %cpu %sys %usr %nice %io %irq CPU C.St. 17:56:51: 1800/1300MHz 2.20 2% 0% 0% 1% 0% 0% 84.0°C 2/13 17:56:57: 1800/1300MHz 2.99 93% 0% 17% 75% 0% 0% 87.0°C 2/13 17:57:02: 1800/1300MHz 3.79 93% 0% 18% 74% 0% 0% 89.0°C 2/13 17:57:07: 1800/1300MHz 3.89 82% 0% 13% 68% 0% 0% 84.0°C 2/13 17:57:12: 1800/1300MHz 3.74 80% 0% 18% 60% 0% 0% 85.0°C 2/13 ... 17:59:19: 1800/1300MHz 9.83 90% 0% 16% 73% 0% 0% 98.0°C 2/13 17:59:25: 1800/1300MHz 10.38 95% 0% 15% 79% 0% 0% 99.0°C 2/13 Time big.LITTLE load %cpu %sys %usr %nice %io %irq CPU C.St. 17:59:30: 1800/1300MHz 10.27 94% 1% 22% 70% 0% 0% 100.0°C 2/13 17:59:36: 1800/1300MHz 9.85 90% 0% 16% 72% 0% 0% 99.0°C 2/13 17:59:42: 1800/1300MHz 10.10 95% 0% 17% 77% 0% 0% 100.0°C 2/13 17:59:48: 1800/1300MHz 10.33 98% 0% 18% 79% 0% 0% 102.0°C 2/13 17:59:54: 1800/1300MHz 10.38 95% 0% 22% 71% 0% 0% 101.0°C 2/13 18:00:00: 1800/1300MHz 10.79 97% 1% 20% 75% 0% 0% 100.0°C 2/13
  9. Hi, Panfrost is now working without crashes on gnome. We can steel see some blurred components of the gnome panels, but now we don have crashes. We can use firefox but we have to set in /etc/environment MOZ_ENABLE_WAYLAND=1 firefox. MPV we have to set on mpv.conf gpu-context=wayland. It works without screen tearing. Thanks Alyssa Rosenzweig for your great work.
  10. Sorry, I cant help you with that - because Iam not a android-developer
  11. Hi , dos anyone knows if is possible to set screen resolution 1366X768@60 (my tv resolution). I always get 1360x768@60. xrand is not a option because I'm in wayland. Thanks
  12. cheers @lanefu but this is how I spin up my builds usually, therefore alas no go ( summary from first page below ) I will give it another shot Tuesday earliest I guess ( hoping also for rc5 )
  13. Thanks very much. Sorry for the slow response - I'm only allowed one post per 24 hours. I seem to have a solution. As mentioned above, I took the image from https://www.armbian.com/odroid-hc1/ To be more specific, I used the one with the large image at the right hand side of the page, just below the picture of an HC1. Looking more carefully, it uses kernel 4.14.y. Not being knowledgeable about kernel versions, I assumed that the highlighted image was the best to use. However, I later looked down the page, and tried using the download link https://dl.armbian.com/odroidxu4/Buster_current_minimal which uses kernel 5.4. Why would people prefer an old kernel? Anyway, everything seems to work as I would expect with no need for selecting legacy elements or anything unusual. With the other image, I was not able to find a package called iptables-legacy, only one called iptables. Reinstalling it and rebooting didn't make a difference. In case they are still of interest, the answers to your questions are: root@backup:~# find /lib/modules/|fgrep -i tables /lib/modules/4.14.187-odroidxu4/kernel/net/ipv6/netfilter/nf_tables_ipv6.ko /lib/modules/4.14.187-odroidxu4/kernel/net/ipv6/netfilter/ip6_tables.ko /lib/modules/4.14.187-odroidxu4/kernel/net/ipv4/netfilter/nf_tables_ipv4.ko /lib/modules/4.14.187-odroidxu4/kernel/net/ipv4/netfilter/ip_tables.ko /lib/modules/4.14.187-odroidxu4/kernel/net/ipv4/netfilter/arp_tables.ko /lib/modules/4.14.187-odroidxu4/kernel/net/ipv4/netfilter/nf_tables_arp.ko /lib/modules/4.14.187-odroidxu4/kernel/net/netfilter/nf_tables_netdev.ko /lib/modules/4.14.187-odroidxu4/kernel/net/netfilter/nf_tables.ko /lib/modules/4.14.187-odroidxu4/kernel/net/netfilter/nf_tables_inet.ko /lib/modules/4.14.187-odroidxu4/kernel/net/bridge/netfilter/ebtables.ko /lib/modules/4.14.187-odroidxu4/kernel/net/bridge/netfilter/nf_tables_bridge.ko root@backup:~# armbianmonitor -u System diagnosis information will now be uploaded to http://ix.io/2rqQ
  14. But, sir, I want to compile stockfish 11 for Android so that I can change some source code and test the engine in droidfish. I'm trying to do this since last week but I can't. I messaged you in Facebook Messenger, if possible reply me there, sir. I'm waiting for your reply.
  15. @balbes150 I have tested this with open box and with heat sink and radiator, and the temperature hovers around 80 degrees I have been testing it for just few minutes. I think it is still at the higher side so I think fan is the only option. I am wary of adding moving parts in the box. Sooner or later it will need replacement. BTW it is interesting in the closed box scenario the temp reaches up to 139 degrees C within 20-25 minutes of running a movie. As per your earlier quote in this forum you have mentioned you plan to focus on Allwinner and RockChip SOCs only going forward however Amlogic SOCs are quite stable and have decent performance. I have tried your images on Tanix TX3 Mini (S905W), MeCool M8S Pro (S912), Tanix TX5 Mini (S905X), T95U Pro and T95Z Pro both S912. They work great on all these boxes. I am sure you may have solid reasons for having limited support for Amlogic going forward. If you can share some of your thoughts, it will help with choosing for future. I have used Allwinner Orange Pi Plus 2e also. It is a good device but Plymouth does not work well on this (ARMv7 32-bit). Plymouth has issues with 32-bit images I think, based on my experience. As always thank you great job with these images. -R
  16. @dolphs see if it builds when adding EXTRAWIFI=no
  17. Hello, eMMC is 8GB, GB here stands for gigabytes. RAM memories are advestised to the general public in gigabytes also, but the technical datasheets of the chips reports the chip sizes in gigabits, so 8 gigabits = 1 gigabyte. Clock frequencies are "unrestricted", in the sense you can set the device tree to report the SoC is capable of any reasonable frequency. A restriction, as @hexdump said, is applied to the voltage you set for a specific OPP: the SoC frequency is linked to the voltage regulator which has to be programmed on the fly to provide higher or lower voltages depending on the operating frequency. The regulator also has an operating voltage range (also described in the device tree) and the kernel will cut out those OPPs that are requesting voltages outside this range. dmesg will tell you if an OPP has been cut away. Overclocking these chips should be quite easy, but don't expect great performance advancements, they are low power chips and the architecture is quite old nowadays. Lately instead I was trying to undervolt them to see if I can let them consume less current and produce less heat too and I think there is great room for improvement here.
  18. Added u-boot-2020.07 files for rk3399-rock-pi-4b
  19. run `armbianmonitor -u` to provide debugging info.
  20. This is odd.. as whenlooking at the kernel config used iptables modules are there. Debian buster does use nftables, so there most be some underlying issues. maybee reinstall iptables-legacy package and reboot before setting alternative? what does this command return? find /lib/modules/|fgrep -i tables also please run and share link for sudo armbianmonitor -u
  21. I was wondering if the Armbian distribution had a fix for this yet. I downloaded the current sources and built Armbian_20.08.0-trunk_Pine64so_buster_current_5.4.51.img It does boot nicely in the baseboard but it does not appear to have any fix for the clustereboard networking problem. I am able to use the Armbian_5.41_Pine64so_Ubuntu_xenial_next_4.14.20.img.xz that I downloaded off the forum. It does have the fix, but if I do the "apt update; apt upgrade" to bring in updates, I lose the fix and the next boot fails to operate in the clusterboard. Here is my Pine64 archive for community use. see http://cloud.goodall.com/Pine64 The image I am using that has the fix (but cannot be updated) is http://cloud.goodall.com/Pine64/ClusterBoard/Armbian_5.41_Pine64so_Ubuntu_xenial_next_4.14.20.img.xz I will post updates in my archive as I have them so they will be available for use.
  22. I might switch to rpi4(1Gbps + usb 3.0 ethernet adapter) or NanoPi R2S(1Gbp x2 RK3328) or NanoPi NEO3 (1Gbps x1 + Usb3.0 RK3328), or just hEX once I get bored of SBC DIY stuff. Both APUx or Clearfogpro are way above my budget.
  23. Running into this exact issue when bringing up new nodes to add to my existing cluster. Any idea what the last version of Armbian compatible might be? My existing cluster is running kernel 4.14.70-s5p6818 and on Dietpi v6.15 and I could clone that -- but I was hoping to use Armbian for the new additions.. tso is fixed in the latest version and by default appears to be off.. root@armbian-nanopi3-ClusterTest:~# ethtool -k eth0 | grep tcp tcp-segmentation-offload: off tx-tcp-segmentation: off [fixed] tx-tcp-ecn-segmentation: off [fixed] tx-tcp-mangleid-segmentation: off [fixed] tx-tcp6-segmentation: off [fixed] Thanks!
  24. Yesterday
  25. @Yeoj Henrie Sayadi - it might be due to the restriction of the voltage range of the voltage provider for the cpu in case you also increased the voltage for the higher opp points ...
  26. Before it is working, after cannot connect to serial U-Boot SPL 2020.04-armbian (Jul 11 2020 - 16:51:48 +0300) DRAM: 512 MiB Trying to boot from MMC1 U-Boot 2020.04-armbian (Jul 11 2020 - 16:51:48 +0300) Allwinner Technology CPU: Allwinner H3 (SUN8I 1680) Model: FriendlyARM NanoPi DUO 2 DRAM: 512 MiB MMC: mmc@1c0f000: 0 Loading Environment from FAT... Unable to use mmc 0:1... In: serial Out: serial Err: serial Net: No ethernet found. starting USB... No working controllers found Autoboot in 1 seconds, press <Space> to stop switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... Found U-Boot script /boot/boot.scr 3789 bytes read in 3 ms (1.2 MiB/s) ## Executing script at 43100000 U-boot loaded from SD Boot script loaded from mmc 190 bytes read in 3 ms (61.5 KiB/s) 13628911 bytes read in 1035 ms (12.6 MiB/s) 6118624 bytes read in 467 ms (12.5 MiB/s) Found mainline kernel configuration 29102 bytes read in 9 ms (3.1 MiB/s) 504 bytes read in 9 ms (54.7 KiB/s) Applying kernel provided DT overlay sun8i-h3-usbhost0.dtbo 504 bytes read in 9 ms (54.7 KiB/s) Applying kernel provided DT overlay sun8i-h3-usbhost2.dtbo 504 bytes read in 9 ms (54.7 KiB/s) Applying kernel provided DT overlay sun8i-h3-usbhost3.dtbo 4185 bytes read in 9 ms (454.1 KiB/s) Applying kernel provided DT fixup script (sun8i-h3-fixup.scr) ## Executing script at 44000000 ## Loading init Ramdisk from Legacy Image at 43300000 ... Image Name: uInitrd Image Type: ARM Linux RAMDisk Image (gzip compressed) Data Size: 13628847 Bytes = 13 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 43000000 Booting using the fdt blob at 0x43000000 Loading Ramdisk to 49300000, end 49fff5af ... OK Loading Device Tree to 49290000, end 492fffff ... OK Starting kernel ... Uncompressing Linux... done, booting the kernel. and it just stop after booting the kernel Thanks man
  27. Hello, I have just installed Armbian_20.05.4_Odroidc4_focal_current_5.6.18.img on my Odroid-C4, and encounter the same issue. The board doesn't come back up after rebooting. The ethernet controller is blinking in an interesting way. The right orange NIC LED blink about 5 times, then green and orange LED blink once together. This continues this way. The screen is not enabled after the reboot. Unpowering the board helps to reboot. The last thing you read from the screen before it turns black was: Reached target Reboot. I am using a micro SD card, Samsung Pro 32G. Let me know what information you might want to have posted here. I do not have the same issue with Odroid's default image, but I prefer your tidy distro dmesg.log kern.log 20200711_160117.mp4
  28. i think so. I tested your pattern sample on A64 and both pattern looked fine (exactly the same) ffmpeg -input_format yuyv422 -s 1920x1080 -i /dev/video0 /tmp/output_yuyv422.mjpg ffmpeg -input_format yuv420p -s 1920x1080 -i /dev/video0 /tmp/output_yuyv420.mjpg which i think should fail for the yuyv422 on fmt:YUYV8_2X8/1920x1080 Image quality is similar to what you got with your test_0. I would advise to move on to latest ov5640 driver or if you find the ov5640 driver (PinePhone) with additional fix , let us know the diff. Maybe @rreignier can have different results. Hope this information will be helpful. Good luck.
  1. Load more activity