All Activity
This stream auto-updates
- Past hour
-
Igor, Thanks for your reply. I have done new tests based on image: Armbian_19.11.3_Nanopi-r1_buster_current_5.3.9.7z test 1 : -------- Disconnect power, then reconnect power root@nanopi:~# armbianmonitor -u System diagnosis information will now be uploaded to http://ix.io/22vY Please post the URL in the forum where you've been asked for. test 2: ------- Disconnect power, then reconnect power root@nanopi:~# armbianmonitor -u System diagnosis information will now be uploaded to http://ix.io/22vZ Please post the URL in the forum where you've been asked for. root@nanopi:~# Conclusions: Eth0 (Wan port) is ok, but ... It seems that the MAC address on Ethernet port eth1 changed on each reboot, and on eth0, it is always the same. Could you please confirm this behaviour ? On file : http://ix.io/22vZ ### ip addr: 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet XXX.XXX.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether be:11:34:10:e5:f0 brd ff:ff:ff:ff:ff:ff 3: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 12:81:68:ec:e7:fa brd ff:ff:ff:ff:ff:ff 4: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 66:f4:99:6c:47:19 brd ff:ff:ff:ff:ff:ff 5: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 8c:f7:10:9e:fc:f1 brd ff:ff:ff:ff:ff:ff On file : http://ix.io/22vY ### ip addr: 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet XXX.XXX.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 32:cf:8d:ea:60:bc brd ff:ff:ff:ff:ff:ff 3: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 12:81:68:ec:e7:fa brd ff:ff:ff:ff:ff:ff 4: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether ae:6d:32:73:9b:8f brd ff:ff:ff:ff:ff:ff 5: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 8c:f7:10:9e:fc:f1 brd ff:ff:ff:ff:ff:ff Thanks for your help
- Today
-
Use unchanged stable image from the download section when asking for help. If you don't provide armbianmonitor -u ... you are wasting our precious time.
-
Latest kernel is 5.3.y ... read text on that link. -
SOLVED: How to add an external RTC module to ROCK64 board
rbr replied to turkerali's topic in Development
Hello, this was my way to make RTC DS3231 works on rock64. apt-get install i2c-tools - /etc/rc.local /lib/udev/hwclock-set /dev/rtc1 exit 0 - /lib/udev/hwclock-set if [ -e /run/systemd/system ] ; then # exit 0 /bin/enable_dtoverlay i2c0 i2c@ff150000 okay echo ds1307 0x68 > /sys/class/i2c-adapter/i2c-0/new_device fi #if [ -e /run/udev/hwclock-set ]; then # exit 0 #fi HCTOSYS_DEVICE=rtc1 Copy to /bin/ and make executable https://raw.githubusercontent.com/ayufan-rock64/linux-package/master/root/usr/local/sbin/enable_dtoverlay systemctl stop systemd-timesyncd.service systemctl disable systemd-timesyncd.service systemctl stop fake-hwclock.service systemctl disable fake-hwclock.service sudo apt-get -y remove fake-hwclock apt install chrony -
@piter75 the dev kernel boots correctly: https://pastebin.com/jrghsmPi I have also tried the desktop version which works quite well if panfrost is disabled. Audio doesn't work: strangely it seems that this kernel version doesn't support the Realtek ACL 5651: I tried to manually edit the .config, but with no success Instead, images with the default kernel fail (tested with various sd cards): https://pastebin.com/FSfEs9Kq I guess that the friendlyelec 4.4.y kernel dts isn't compatible with the 2019 uboot branch
-
Using coreelec to share your resources is tantamount to leaving the door open for unhindered theft of all your personal data from your home network.
-
Of course. Did you take any note?
-
Hello, is there a user of orangepiR1 with traces of good operation of the 2 Ethernet interfaces simultaneously? In advance, please provide the boot log of the kernel and the DTB version number
-
Yes, after update to bionic distr. mth@orangepizero:~$ uname -a Linux orangepizero 4.19.62-sunxi #5.92 SMP Wed Jul 31 22:07:23 CEST 2019 armv7l armv7l armv7l GNU/Linux Previous distr (jessie) - working fine.
-
Also after this?
-
We made several manual upgrades which are noted in that document and it seems its alright. If you start with a new image, tools are also installed. Otherwise apt get wg-tools ...
-
Ram chips are 14x8, for me it was easier to cut 14x14 heatsink to size. I am not sure 14x14x10 will be enough for cooling it if you apply any meaningful load. I have a project where Orange Pi Zero runs for years with only a heatsink - but what it does even something like ESP8266 could achieve easily, there's no stress at all. Some of those heatsinks come with adhesive tape already applied, though it's obviously not the best. Unless you plan on deploying many of such heatsinks, it's probably going to be enough. Or you could buy proper thermal adhesive tape that can stand high temperatures over 100C in 15mm or 20mm width. (just an example, research which seller offers best price yourself)
-
Same problem. Some task's cause error info about thermal data and system going to shutdown.
-
Double Sided Adhesive Thermal Conductive Tape You can superglue it, but then you'll not get it off without damaging it
-
you may play around this patch here: https://github.com/armbian/build/blob/nanopi-m4v2-u-boot-v2019.10-ddr-miniloader/patch/kernel/rockchip64-dev/rk3399-sd-drive-level-8ma.patch we've some history with SD cards or rockchip... Jusk ask @TonyMac32
-
Wow, many thanks Igor. So it is safe to uograde my Nanopi Neo2 and Orange Pi Zero boards to Kernel 5.x,and these are the stable versions. On upgrading it should not brake anything, if I'm correct, as I don't have access to one of my devices, only over ssh. And kernel 5.x already has WG integrated, so only wg-tools needs to be installes - and that is really good! Thanks for your hard work!
-
where WG is latest by default anyway ... while DKMS needs some bug fixing.
-
Many thanks! I don't use any expansion board. And I really don't want to use a fan, needs to stay passive. I will look into these heatsinks. I see these don't have adhesive tape, what is the best way to glue/install these on the SoC and the memory chip? Thanks Edit: this 14x14x10 should be ok? HUF 488.72 6%OFF | En-Labs 10pcs Aluminum Heatsink 14*14*10mm Electronic Chip Radiator Cooler w/ 3M Brand 9448A Thermal Double Sided Adhesive Tape https://s.click.aliexpress.com/e/rOdNOldQ And what is the size of the memory chip? I don't have access to the devicw now.
-
Well, at least you got Armbian working (somewhat). If you tried getting Coreelec installed that would be of great help because it is the cheapest S922x box out there, but of course that's up to you. I like fooling around with CE stuff myself- I would have purchased an Odroid N2 at this point but it's still somewhat expensive. Was also looking at the Nvidia Jetson Nano but the drivers are sort of iffy- there might be Kodi support at some time in the future, but who knows. Definitely the most powerful device of its type for <$100.
-
It depends whether you want to add expansion board someday or not. If you do, 14x14x6 heatsink is the better choice, otherwise choose 14x14xsomething according to your desire and budget. I would recommend a fan regardless, those things get hot. You can read about mounting a fan here (SBC is very similar Orange Pi R1, fan mounts the same). Here you can buy the heatsinks, check Aliexpress too maybe they are cheaper there. I also strongly suggest cutting one of the heatsinks to fit on the RAM module, it benefits too.
-
I have a problem now with installing kernel headers: Welcome to Ubuntu Bionic with Armbian Linux 4.19.63-sunxi64 System load: 0.10 0.09 0.08 Up time: 1 day Memory usage: 26 % of 481MB Zram usage: 9 % of 240Mb IP: 192.168.1.125 10.66.66.1 CPU temp: 60°C Usage of /: 3% of 59G [ General system configuration (beta): armbian-config ] Last login: Fri Nov 22 06:43:30 2019 from xxxxx nanopi@nanopineo2:~$ sudo apt install linux-headers-4.19.63-sunxi64 [sudo] password for nanopi: Reading package lists... Done Building dependency tree Reading state information... Done E: Unable to locate package linux-headers-4.19.63-sunxi64 E: Couldn't find any package by glob 'linux-headers-4.19.63-sunxi64' E: Couldn't find any package by regex 'linux-headers-4.19.63-sunxi64' nanopi@nanopineo2:~$ I would like to uograde to the latest Wireguard version, but installing wireguard-dkms fails, can't build the requires modules without the kernel headers, I guess. Simply installing WG from the ppa doesn't update to the newest version on system level. I managed to update last time like this, but if I remember correctly, I was abke to install headers. I tried with armbian-config, installed headers, but still doesn't work. Any ideas? http://ix.io/22v3
-
What happened to the Neo4 Buster minimal 5.3 kernel download?
Werner replied to congitor's topic in Rockchip 3399
Seems like it was successful. It is available now as stated above. -
My adventures with my tv boxes have been limited to running Armbian provided by balbes so I couldnt even begin to tell you whether coreelec runs on it. Since armbian usb hence keyboard not working, using it with stock android. In the middle of Netflix when I got notification that system update was available. Went thru with the update and tv box still up and running. No idea where thaf update came from
-
I made some investigation and found that unstable phase is a consequence of sigma-delta modulation for audio PLL from this commit Sigma-delta modulation make more exact frequency but it leads variable phase of clocks. This means that with the kernel> 4.15 some codecs will not work, as they will not be able to synchronize with the clocks. My PCM5102A may work only with 48k, but not higher
-
Did some more digging and even though its an "old" product, its still produced for OEM customers using it for current products. The HDMI-IN is via a HDMI-to-CSI chip, Toshiba TC358749 HDMI IN -> MIPI CSI -> RK3288 This explains why its implemented as a webcam in android. The CSI variant already has a linux driver in mainline : https://github.com/torvalds/linux/blob/master/drivers/media/i2c/tc358743.c
