update:
I’m manage to setup the mac address by mac=xxxx, but the ethernet is still not work well…
The 169.254.x.x address is called the “link-local” address, and it’s what happens when you have DHCP enabled on the interface but the system is unable to successfully negotiate an IP address. For example, if there is packet loss (like in our case) or if there is no DHCP server online.
1 Like
Hello @microdude,
Can you try this image to check the ethernet issue?
I checked on my side, it works. And I can make Armbian work, too.
/ # ifconfig
eth0 Link encap:Ethernet HWaddr 16:AB:6D:E8:52:D0
inet addr:192.168.1.116 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:378 errors:0 dropped:0 overruns:0 frame:0
TX packets:359 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:319435 (311.9 KiB) TX bytes:49762 (48.5 KiB)
Interrupt:24
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
wlan0 Link encap:Ethernet HWaddr 28:ED:E0:E6:99:F8
inet6 addr: fe80::2aed:e0ff:fee6:99f8/64 Scope:Link
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:47 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:14438 (14.0 KiB)
/ #
/ # ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1): 56 data bytes
64 bytes from 192.168.1.1: seq=0 ttl=64 time=1.064 ms
64 bytes from 192.168.1.1: seq=1 ttl=64 time=0.783 ms
64 bytes from 192.168.1.1: seq=2 ttl=64 time=0.871 ms
64 bytes from 192.168.1.1: seq=3 ttl=64 time=0.816 ms
64 bytes from 192.168.1.1: seq=4 ttl=64 time=0.772 ms
64 bytes from 192.168.1.1: seq=5 ttl=64 time=0.703 ms
^C
--- 192.168.1.1 ping statistics ---
6 packets transmitted, 6 packets received, 0% packet loss
round-trip min/avg/max = 0.703/0.834/1.064 ms
/ #
1 Like
Can you check out the latest “default” and “dev” 5.89_20190627 images Armbian, how does the wired network work on your EDGE-V ?
2 Likes
Awesome. This fixed the Ethernet!
However, I’m back to missing the m.2 
The m.2 is just a DTB fix though. I wonder if I can steal it from the Edge image from before…
1 Like
Oops, this image is built from the LibreELEC mainline, so the M.2 patch is missing.
As you said you can obtain it from Edge image.
And I will try to send the patches to LibreELEC upstream.
Yep, that fixed it. But now I’m stuck with some 4K h265 HDR media that won’t play. And the ones that do eventually cause the system to lock up and get very hot. Not sure what’s going on or how to debug. I enabled debug logging in Kodi, but when it locks up I’m unable to get the logs.
On the media that won’t play at all (but will play via VLC on my Mac, S905X devices, and an nVidia Shield TV) I see a lot of these errors:
2019-06-27 15:04:59.230 T:3600802688 ERROR: ffmpeg[D69FE380]: [hevc_rkmpp] Received a errinfo frame.
2019-06-27 15:04:59.230 T:3600802688 ERROR: CDVDVideoCodecDRMPRIME::AddData - send packet failed, ret:-1313558101
2019-06-27 15:04:59.263 T:3600802688 ERROR: ffmpeg[D69FE380]: [hevc_rkmpp] Received a errinfo frame.
2019-06-27 15:04:59.263 T:3600802688 ERROR: CDVDVideoCodecDRMPRIME::AddData - send packet failed, ret:-1313558101
2019-06-27 15:04:59.296 T:3600802688 ERROR: ffmpeg[D69FE380]: [hevc_rkmpp] Received a errinfo frame.
2019-06-27 15:04:59.296 T:3600802688 ERROR: CDVDVideoCodecDRMPRIME::AddData - send packet failed, ret:-1313558101
Here is the Media Info reported in the debug log:
2019-06-27 15:04:53.619 T:3609195392 INFO: ffmpeg[D71FF380]: Stream #0:0: Video: hevc (Main 10), yuv420p10le(tv, bt2020nc/bt2020/smpte2084), 3840x1600, SAR 1:1 DAR 12:5, 23.98 fps, 23.98 tbr, 1k tbn, 23.98 tbc (default)
2019-06-27 15:04:53.619 T:3609195392 INFO: ffmpeg[D71FF380]: Metadata:
2019-06-27 15:04:53.619 T:3609195392 INFO: ffmpeg[D71FF380]: BPS : 21256548
2019-06-27 15:04:53.619 T:3609195392 INFO: ffmpeg[D71FF380]: BPS-eng : 21256548
2019-06-27 15:04:53.619 T:3609195392 INFO: ffmpeg[D71FF380]: DURATION : 01:41:11.733000000
2019-06-27 15:04:53.619 T:3609195392 INFO: ffmpeg[D71FF380]: DURATION-eng : 01:41:11.733000000
2019-06-27 15:04:53.619 T:3609195392 INFO: ffmpeg[D71FF380]: NUMBER_OF_FRAMES: 145576
2019-06-27 15:04:53.619 T:3609195392 INFO: ffmpeg[D71FF380]: NUMBER_OF_FRAMES-eng: 145576
2019-06-27 15:04:53.619 T:3609195392 INFO: ffmpeg[D71FF380]: NUMBER_OF_BYTES : 16133011066
2019-06-27 15:04:53.619 T:3609195392 INFO: ffmpeg[D71FF380]: NUMBER_OF_BYTES-eng: 16133011066
2019-06-27 15:04:53.619 T:3609195392 INFO: ffmpeg[D71FF380]: _STATISTICS_WRITING_APP: mkvmerge v12.0.0 ('Trust / Lust') 64bit
2019-06-27 15:04:53.619 T:3609195392 INFO: ffmpeg[D71FF380]: _STATISTICS_WRITING_APP-eng: mkvmerge v12.0.0 ('Trust / Lust') 64bit
2019-06-27 15:04:53.619 T:3609195392 INFO: ffmpeg[D71FF380]: _STATISTICS_WRITING_DATE_UTC: 2017-11-08 11:07:18
2019-06-27 15:04:53.619 T:3609195392 INFO: ffmpeg[D71FF380]: _STATISTICS_WRITING_DATE_UTC-eng: 2017-11-08 11:07:18
2019-06-27 15:04:53.619 T:3609195392 INFO: ffmpeg[D71FF380]: _STATISTICS_TAGS: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES
2019-06-27 15:04:53.619 T:3609195392 INFO: ffmpeg[D71FF380]: _STATISTICS_TAGS-eng: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES
And just grepping out the streams on a working one vs a broken one:
2019-06-27 15:49:51.218 T:3833652096 INFO: ffmpeg[E480E380]: Input #0, matroska,webm, from '/var/media/nvme/works.mkv':
2019-06-27 15:49:51.225 T:3833652096 INFO: ffmpeg[E480E380]: Stream #0:0: Video: hevc (Main 10), yuv420p10le(tv, bt2020nc/bt2020/smpte2084), 3840x1600, SAR 1:1 DAR 12:5, 23.98 fps, 23.98 tbr, 1k tbn, 23.98 tbc (default)
2019-06-27 15:49:51.226 T:3833652096 INFO: ffmpeg[E480E380]: Stream #0:1(eng): Audio: aac (LC), 48000 Hz, 7.1, fltp (default)
2019-06-27 15:49:51.227 T:3833652096 INFO: ffmpeg[E480E380]: Stream #0:2(eng): Audio: aac (HE-AAC), 48000 Hz, stereo, fltp
2019-06-27 15:49:51.228 T:3833652096 INFO: ffmpeg[E480E380]: Stream #0:3(eng): Audio: aac (HE-AAC), 48000 Hz, stereo, fltp
2019-06-27 15:49:51.229 T:3833652096 INFO: ffmpeg[E480E380]: Stream #0:4(eng): Audio: aac (HE-AAC), 48000 Hz, stereo, fltp
2019-06-27 15:49:51.230 T:3833652096 INFO: ffmpeg[E480E380]: Stream #0:5(eng): Audio: aac (LC), 48000 Hz, stereo, fltp
2019-06-27 15:49:51.231 T:3833652096 INFO: ffmpeg[E480E380]: Stream #0:6(eng): Subtitle: dvd_subtitle, 1920x1080
2019-06-27 15:49:51.232 T:3833652096 INFO: ffmpeg[E480E380]: Stream #0:7(ara): Subtitle: dvd_subtitle, 1920x1080
2019-06-27 15:49:51.233 T:3833652096 INFO: ffmpeg[E480E380]: Stream #0:8(chi): Subtitle: dvd_subtitle, 1920x1080
2019-06-27 15:49:51.234 T:3833652096 INFO: ffmpeg[E480E380]: Stream #0:9(hrv): Subtitle: dvd_subtitle, 1920x1080
2019-06-27 15:49:51.235 T:3833652096 INFO: ffmpeg[E480E380]: Stream #0:10(cze): Subtitle: dvd_subtitle, 1920x1080
2019-06-27 15:49:51.236 T:3833652096 INFO: ffmpeg[E480E380]: Stream #0:11(dan): Subtitle: dvd_subtitle, 1920x1080
2019-06-27 15:49:51.237 T:3833652096 INFO: ffmpeg[E480E380]: Stream #0:12(fin): Subtitle: dvd_subtitle, 1920x1080
2019-06-27 15:49:51.238 T:3833652096 INFO: ffmpeg[E480E380]: Stream #0:13(ger): Subtitle: dvd_subtitle, 1920x1080
2019-06-27 15:49:51.239 T:3833652096 INFO: ffmpeg[E480E380]: Stream #0:14(gre): Subtitle: dvd_subtitle, 1920x1080
2019-06-27 15:49:51.240 T:3833652096 INFO: ffmpeg[E480E380]: Stream #0:15(hun): Subtitle: dvd_subtitle, 1920x1080
2019-06-27 15:49:51.241 T:3833652096 INFO: ffmpeg[E480E380]: Stream #0:16(ita): Subtitle: dvd_subtitle, 1920x1080
2019-06-27 15:49:51.242 T:3833652096 INFO: ffmpeg[E480E380]: Stream #0:17(kor): Subtitle: dvd_subtitle, 1920x1080
2019-06-27 15:49:51.243 T:3833652096 INFO: ffmpeg[E480E380]: Stream #0:18(nob): Subtitle: dvd_subtitle, 1920x1080
2019-06-27 15:49:51.244 T:3833652096 INFO: ffmpeg[E480E380]: Stream #0:19(pol): Subtitle: dvd_subtitle, 1920x1080
2019-06-27 15:49:51.245 T:3833652096 INFO: ffmpeg[E480E380]: Stream #0:20(por): Subtitle: dvd_subtitle, 1920x1080
2019-06-27 15:49:51.246 T:3833652096 INFO: ffmpeg[E480E380]: Stream #0:21(rum): Subtitle: dvd_subtitle, 1920x1080
2019-06-27 15:49:51.247 T:3833652096 INFO: ffmpeg[E480E380]: Stream #0:22(rus): Subtitle: dvd_subtitle, 1920x1080
2019-06-27 15:49:51.248 T:3833652096 INFO: ffmpeg[E480E380]: Stream #0:23(spa): Subtitle: dvd_subtitle, 1920x1080
2019-06-27 15:49:51.249 T:3833652096 INFO: ffmpeg[E480E380]: Stream #0:24(swe): Subtitle: dvd_subtitle, 1920x1080
2019-06-27 15:49:51.250 T:3833652096 INFO: ffmpeg[E480E380]: Stream #0:25(tha): Subtitle: dvd_subtitle, 1920x1080
2019-06-27 15:49:51.251 T:3833652096 INFO: ffmpeg[E480E380]: Stream #0:26(tur): Subtitle: dvd_subtitle, 1920x1080
2019-06-27 15:50:08.463 T:3929895808 INFO: ffmpeg[EA3D7380]: Input #0, matroska,webm, from '/var/media/nvme/broken.mkv':
2019-06-27 15:50:08.466 T:3929895808 INFO: ffmpeg[EA3D7380]: Stream #0:0: Video: hevc (Main 10), yuv420p10le(tv, bt2020nc/bt2020/smpte2084), 3840x1600, SAR 1:1 DAR 12:5, 23.98 fps, 23.98 tbr, 1k tbn, 23.98 tbc (default)
2019-06-27 15:50:08.467 T:3929895808 INFO: ffmpeg[EA3D7380]: Stream #0:1(eng): Audio: truehd, 48000 Hz, 7.1, s32 (24 bit) (default)
2019-06-27 15:50:08.469 T:3929895808 INFO: ffmpeg[EA3D7380]: Stream #0:2(eng): Audio: ac3, 48000 Hz, 5.1(side), fltp, 640 kb/s
2019-06-27 15:50:08.470 T:3929895808 INFO: ffmpeg[EA3D7380]: Stream #0:3(eng): Audio: ac3, 48000 Hz, stereo, fltp, 224 kb/s
2019-06-27 15:50:08.471 T:3929895808 INFO: ffmpeg[EA3D7380]: Stream #0:4(eng): Subtitle: hdmv_pgs_subtitle
2019-06-27 15:50:08.472 T:3929895808 INFO: ffmpeg[EA3D7380]: Stream #0:5(eng): Subtitle: hdmv_pgs_subtitle
2019-06-27 15:50:08.473 T:3929895808 INFO: ffmpeg[EA3D7380]: Stream #0:6(spa): Subtitle: hdmv_pgs_subtitle
Any tips on what I could do to debug? I’m not sure why it works everywhere else but not on the RK device (Edge-V, v13, etc.)
Mainline LibreELEC doesn’t support HDR yet.
Work was started last month by Intel that is doing the majority of the work.
On some other devices, using proprietary kernels, not mainline, HDR can work with a lot of patches but the LibreELEC developers decided it’s better to go the mainline route so that they can support a lot more devices and provide much better functionality with long term support. Kwiboo is the main developer doing HDR work - https://github.com/Kwiboo/linux-rockchip/commits/rockchip-5.1-libreelec-hdr-v5.1.5
You will have to wait until they merge all his mainline work into official LibreELEC, which should be soon.
Then they will post new test builds in the LibreELEC forum users can try to troubleshoot all the remaining bugs.
https://forum.libreelec.tv/board/43-rockchip/
3 Likes
Thank you for the quick and thorough answer! Very much appreciated. They were both HDR files so that’s probably why they crashed. I’ll have to give it a go watching a full (non-HDR) movie. Looking forward to the development. Thanks everyone for the help thus far, particularly @balbes150 @Frank @numbqq and @mo123 – sorry if I forgot anyone, it’s been too many posts
@microdude You can also use the previous LE provided by @balbes150, after burn it to the SD card, you just need to update the u-boot to fix the ethernet issue.
You can download the u-boot here: https://dl.khadas.com/Firmware/test/Edge_uboot/
Download the u-boot to somewhere, and dd them to the SD card:
sudo dd if=idbloader.img of=/dev/sdX seek=64 conv=notrunc
sudo dd if=uboot.img of=/dev/sdX seek=16384 conv=notrunc
sudo dd if=trust.img of=/dev/sdX seek=24576 conv=notrunc
Note: Replace sdX to the correct one.
Oh cool, thank you. Do his versions have the beta support for HDR? (I’m guessing not, but just want to make sure).
@balbes150 I’ve been a little behind, but I hope to test your Armbian images today.
I tested these images and both worked great:
Armbian_5.89_Rk3399-tv_Ubuntu_bionic_default_4.4.154_20190627.img
Armbian_5.89_Rk3399-tv_Ubuntu_bionic_dev_4.4.167_20190627.imgNew image Libreelec for EDGE 20190628.
Add new u-boot patch for EDGE-V
M2 not add
1 Like
What is the difference between this image and the one posted by @numbqq? Both seem to work well for me (I used the other .dtb on yours so that m2 would work). Neither have HDR yet, as far as I can tell.
The image I provided is built from LibreELEC mainline with the u-boot fix.
The images provided by @balbes150 is built from his own repo.
Hi balbes150,
I can’t find the aarch64 Images in Libreelec for EDGE 20190628.
Can you help me?
BTW, why not installing the LibreELEC directly to the eMMC storage of the Edge? Less practical, no advantage or not possible for some actual reason?
You can install LE to EMMC with Balbes’s LE images.
But LE is still work in progress and if you install it to EMMC, there is no easy way to get Android back on it. The only way is to make a backup of Android through LE and restore it from there if ran from a micro-sd card.
1 Like
The new version 20190629. Added separate DTB for all edge models. Added support for NVMe. Added scripts and a GUI to create a full backup of the entire eMMC and the possibility of installing to eMMC LE through the GUI (LibreelecSettings->eMMC).
@numbqq When running on EDGE+Captain has the option to output sound through the AV output, but the sound’s not working. Perhaps need patches for the kernel or configuration ?
2 Likes