Seasalt Posted February 18, 2019 Posted February 18, 2019 3 hours ago, AndrewDB said: An identical hardware problem on three separate Km8-P TV boxes that allows them to boot and function perfectly with kernel 3.14 but freezes them with kernels 4.xx? I don't see how this could be a hardware problem, but I confess I am scratching my head over this one. Coreelec images are based on kernel 3.14, so they'll boot and work fine. Again: these Km8-P boxes boot and work fine with any image that uses kernel 3.14.29. They freeze when any kernel 4.xx is booted. Btw they come from the factory with Android 7.1 and a 3.14 Android Linux kernel I am away from my KM8 at the moment but i am having no problem with Armbian_5.67_Aml-s9xxx_Ubuntu_bionic_default_4.19.2_desktop_20181203 on 3 KM8 Mecools. It appears to have dissapeared. My internet is so slow I cannot send it too you.
balbes150 Posted February 18, 2019 Author Posted February 18, 2019 6 hours ago, AndrewDB said: An identical hardware problem on three separate Km8-P TV boxes that allows them to boot and function perfectly with kernel 3.14 but freezes them with kernels 4.xx? I don't see how this could be a hardware problem, but I confess I am scratching my head over this one. Coreelec images are based on kernel 3.14, so they'll boot and work fine. Again: these Km8-P boxes boot and work fine with any image that uses kernel 3.14.29. They freeze when any kernel 4.xx is booted. Btw they come from the factory with Android 7.1 and a 3.14 Android Linux kernel On the box where the UART is. Try to completely wipe eMMC (start the system with kernel 3.14 from SD card and run "dd if=/dev/zero of=/dev/you_name_EMMC bs=64M"). And then try to run the latest Armbian image with 4.20 kernel from SD card (there is a new u-boot-2015 in the image). Probably the reason in u-boot which to be in eMMC. If the system does not start at all, you can restore it via the DDBR utility (from a previously created copy) or via a USB cable. I had a similar situation on VIM1 when I tried to run a new kernel on an old u-boot. After u-boot was updated to the new version, the kernel started to run.
AndrewDB Posted February 18, 2019 Posted February 18, 2019 2 hours ago, balbes150 said: On the box where the UART is. Try to completely wipe eMMC (start the system with kernel 3.14 from SD card and run "dd if=/dev/zero of=/dev/you_name_EMMC bs=64M"). And then try to run the latest Armbian image with 4.20 kernel from SD card (there is a new u-boot-2015 in the image). Probably the reason in u-boot which to be in eMMC. If the system does not start at all, you can restore it via the DDBR utility (from a previously created copy) or via a USB cable. I had a similar situation on VIM1 when I tried to run a new kernel on an old u-boot. After u-boot was updated to the new version, the kernel started to run. I think that was an excellent idea, as I agree it is logical that the problem is with the u-boot in the eMMC. Here is what I did: 1. On the Km8-P box with the UART cable, rebooted Armbian 5.44 with 3.14.29 kernel. 2. Checked internal emmc device. Run ddbr (as root): root@aml:~# ddbr DO YOU WANT TO BACKUP OR RESTORE ? BACKUP=(b) RESTORE=(r) b AVAILABLE DEVICES: mmcblk0 mmcblk1 YOU ARE RUNNING bionic FROM mmcblk1 INTERNAL EMMC IS: mmcblk0 SIZE: 7634944 ROOT (mmcblk1) FREE SPACE IS: 13700900 DO YOU WANT COMPRESSION ? YES=(y) NO=(n) y SAVING AND COMPRESSING mmcblk0 TO /ddbr/Amlogic-emmc.img.gz... 15269888+0 records inMiB/s] [================================> ] 99% ETA 0:00:02 15269888+0 records out 7.28GiB 0:10:01 [12.4MiB/s] [================================>] 100% 7818182656 bytes (7.8 GB, 7.3 GiB) copied, 601.091 s, 13.0 MB/s JOB FINISHED! 3. Zero first 256MB of internal eMMC (as root): dd if=/dev/zero of=/dev/mmcblk0 bs=1M count=256 256+0 records in 256+0 records out 268435456 bytes (268 MB, 256 MiB) copied, 7.82563 s, 34.3 MB/s 4. Flush buffers just in case: sync 5. Shutdown TV box with kernel 3.14.29. 6. On Linux laptop, prepare SD card with Armbian with kernel 4.20 on it, but first zero partition table info on SD card: dd if=/dev/zero of=/dev/mmcblk0 bs=1M count=32 32+0 records in 32+0 records out 33554432 bytes (34 MB, 32 MiB) copied, 2,69802 s, 12,4 MB/s dd if=./Armbian_5.75_Aml-s912_Ubuntu_bionic_default_4.20.5_20190211.img of=/dev/mmcblk0 bs=1M 1276+0 records in 1276+0 records out 1337982976 bytes (1,3 GB, 1,2 GiB) copied, 183,001 s, 7,3 MB/s 7. Edit uEnv.ini on newly created SD card to point dtb to meson-gxm-q201.dtb 8. Reboot TV box with Armbian 5.75 with kernel 4.20 and dtb meson-gxm-q201.dtb Unfortunately, I now have a boot loop, probably the u-boot on the SD card is not managing to properly initialize the DRAM, as it says "DDR init failed...": GXM:BL1:dc8b51:76f1a5;FEAT:ADFC318C:80;POC:3;RCY:0;EMMC:0;READ:0;CHK:AA;SD:0;READ:0;0.0;CHK:0; no sdio debug board detected TE: 191120 BL2 Built : 14:59:36, Aug 9 2017. gxl ge8c6a83 - xiaobo.gu@droid12 set vdd cpu_a to 1120 mv set vdd cpu_b to 1050 mv set vddee to 1000 mv Board ID = 6 CPU clk: 1200MHz DQS-corr enabled DDR scramble enabled DDR3 chl: Rank0+1 @ 912MHz - FAIL DDR4 chl: Rank0+1 @ 1008MHz - FAIL DDR init failed... Reset... I noticed there is a uboot-S912 file on the Armbian image, should I try to use that? Or a 2018 u-boot? BTW the RAM used on these Km8-P boxes is Samsung DDR3-1600 (one can see the Samsung chip used in a photo I posted earlier)
balbes150 Posted February 18, 2019 Author Posted February 18, 2019 33 minutes ago, AndrewDB said: dd if=./Armbian_5.75_Aml-s912_Ubuntu_bionic_default_4.20.5_20190211.img of=/dev/mmcblk0 bs=1M Do not use the DD utility to write the image. This often creates problems with the image (there have been many messages from different users about this problem). You need to use special programs to record the image. 35 minutes ago, AndrewDB said: 8. Reboot TV box with Armbian 5.75 with kernel 4.20 and dtb meson-gxm-q201.dtb Unfortunately, I now have a boot loop, probably the u-boot on the SD card is not managing to properly initialize the DRAM, as it says "DDR init failed...": That's interesting. Try to overwrite the u-boot on the SD card to the new version of uboot-2018 (the file with this version is included in the image). If that doesn't help, I'll build more other u-boot options. dd if=2018-u-boot.bin of=/dev/mmcblkX conv=fsync bs=1 count=442 dd if=2018-u-boot.bin of=/dev/mmcblkX conv=fsync bs=512 skip=1 seek=1
lev2k Posted February 18, 2019 Posted February 18, 2019 15 minutes ago, balbes150 said: Do not use the DD utility to write the image. This often creates problems with the image (there have been many messages from different users about this problem). You need to use special programs to record the image. What software do you suggest instead of "dd", to write an image back to emmc?
AndrewDB Posted February 18, 2019 Posted February 18, 2019 37 minutes ago, lev2k said: What software do you suggest instead of "dd", to write an image back to emmc? I believe Etcher https://www.balena.io/etcher/ is the recommended software for writing Armbian images on SD cards. On the internal eMMC Oleg probably agrees that dd is the best tool (as long as you are on Linux, of course).
AndrewDB Posted February 18, 2019 Posted February 18, 2019 1 hour ago, balbes150 said: Do not use the DD utility to write the image. This often creates problems with the image (there have been many messages from different users about this problem). You need to use special programs to record the image. That's interesting. Try to overwrite the u-boot on the SD card to the new version of uboot-2018 (the file with this version is included in the image). If that doesn't help, I'll build more other u-boot options. dd if=2018-u-boot.bin of=/dev/mmcblkX conv=fsync bs=1 count=442 dd if=2018-u-boot.bin of=/dev/mmcblkX conv=fsync bs=512 skip=1 seek=1 I am trying that as I write this. Let's see... sudo dd if=./s912-uboot.img of=/dev/mmcblk0 conv=fsync bs=1 count=442 and sudo dd if=./s912-uboot.img of=/dev/mmcblk0 conv=fsync bs=512 skip=1 seek=1 I assume that is the correct file, that was on the Armbian image? Still bootloops: GXM:BL1:dc8b51:76f1a5;FEAT:ADFC318C:80;POC:3;RCY:0;EMMC:0;READ:0;CHK:AA;SD:0;READ:0;0.0;CHK:0; no sdio debug board detected TE: 182150 BL2 Built : 14:59:36, Aug 9 2017. gxl ge8c6a83 - xiaobo.gu@droid12 set vdd cpu_a to 1120 mv set vdd cpu_b to 1050 mv set vddee to 1000 mv Board ID = 6 CPU clk: 1200MHz DQS-corr enabled DDR scramble enabled DDR3 chl: Rank0+1 @ 912MHz - FAIL DDR4 chl: Rank0+1 @ 1008MHz - FAIL DDR init failed... Reset... The messages are identical, except for the TE: value
balbes150 Posted February 18, 2019 Author Posted February 18, 2019 41 minutes ago, lev2k said: What software do you suggest instead of "dd", to write an image back to emmc? Do not confuse writing an image to external media (which is usually done on a PC) and creating and restoring a backup. These are completely different tasks.
lev2k Posted February 18, 2019 Posted February 18, 2019 37 minutes ago, balbes150 said: Do not confuse writing an image to external media (which is usually done on a PC) and creating and restoring a backup. These are completely different tasks. I'm not confused about that.. ;-) I'm talking about to write back/restore an emmc backup, formerly created with "DD". I personally, had never issues with "dd" restoring a backup, even if I backup only a part of /dev/mmcblk1. (I usually don't include "unallocated space" in my backup). Another question: why is there 700MB unallocated space at the beginning of /dev/mmcblk1. Is that somehow necessary?
balbes150 Posted February 18, 2019 Author Posted February 18, 2019 39 minutes ago, lev2k said: I'm not confused about that.. ;-) I'm talking about to write back/restore an emmc backup, formerly created with "DD". I personally, had never issues with "dd" restoring a backup, even if I backup only a part of /dev/mmcblk1. (I usually don't include "unallocated space" in my backup). Another question: why is there 700MB unallocated space at the beginning of /dev/mmcblk1. Is that somehow necessary? And in vain, that not include. What you think is empty is actually a critical piece of data for the operation of the system. I have already explained this many times, where do these "empty" 700 MB.
mitico Posted February 18, 2019 Posted February 18, 2019 Hi guys, i installed in my MicroSD armbian, i installed firefox and VLC player. I have a problem because when stream on firefox a video on youtube it lag a lot, i notice that with top command a process called web component uses more than 100% of CPU. the same is for VLC when streaming a video Could please someone help me? I have a Mini M8S Pro TV Box 3GB DDR4 + 32GB eMMC CPU: S912 8 core ARM Cortex-A53 (2GHz) GPU: Mali-T820MP3 750 MHz (DVFS) thank you a lot
AndrewDB Posted February 18, 2019 Posted February 18, 2019 5 hours ago, lev2k said: I'm not confused about that.. ;-) I'm talking about to write back/restore an emmc backup, formerly created with "DD". I personally, had never issues with "dd" restoring a backup, even if I backup only a part of /dev/mmcblk1. (I usually don't include "unallocated space" in my backup). Another question: why is there 700MB unallocated space at the beginning of /dev/mmcblk1. Is that somehow necessary? If I am not wrong, that's the android recovery and boot partitions and some other things that are best left untouched. If you ever want to restore your TV box to its original firmware it's better to leave these 700MB or so untouched, I think, and since there are another 14~15GB of eMMC remaining, they don't matter that much. Plus if you need more storage space you can always add an SD card or an external USB SSD/HDD. I was recently surprised to learn that an excellent A1 SanDisk 32GB microSD card was just 5 euros - with shipping, 64GB for 9 euros and 128GB for 15 euros or so!
lev2k Posted February 18, 2019 Posted February 18, 2019 4 hours ago, AndrewDB said: I think, and since there are another 14~15GB of eMMC remaining, they don't matter that much. I don't care about the space, I was just curious for what such a large "empty partition" is needed... Found this somewhere else from balbes150 (what is a "service part"?): Quote Primary 700Mb is the service part when using the regular u-boot-2015. If you use u-boot-2018, it will be possible to exploit the full capacity of eMMC for the system (minus the 4MB service in the beginning to u-boot-2018)
Carlos.latour Posted February 18, 2019 Posted February 18, 2019 11 hours ago, AndrewDB said: I am trying that as I write this. Let's see... sudo dd if=./s912-uboot.img of=/dev/mmcblk0 conv=fsync bs=1 count=442 and sudo dd if=./s912-uboot.img of=/dev/mmcblk0 conv=fsync bs=512 skip=1 seek=1 I assume that is the correct file, that was on the Armbian image? Still bootloops: GXM:BL1:dc8b51:76f1a5;FEAT:ADFC318C:80;POC:3;RCY:0;EMMC:0;READ:0;CHK:AA;SD:0;READ:0;0.0;CHK:0; no sdio debug board detected TE: 182150 BL2 Built : 14:59:36, Aug 9 2017. gxl ge8c6a83 - xiaobo.gu@droid12 set vdd cpu_a to 1120 mv set vdd cpu_b to 1050 mv set vddee to 1000 mv Board ID = 6 CPU clk: 1200MHz DQS-corr enabled DDR scramble enabled DDR3 chl: Rank0+1 @ 912MHz - FAIL DDR4 chl: Rank0+1 @ 1008MHz - FAIL DDR init failed... Reset... The messages are identical, except for the TE: value In my system, the memory speed messages that work are: 792Mhz (slower thant the 1008 Mhz) ... any way to pass a command to test it at 792mhz instead of 1008? Thanks! .... DDR scramble enabled DDR3 chl: Rank0+1 @ 912MHz - FAIL DDR4 chl: Rank0+1 @ 792MHz - PASS Rank0: 2048MB(auto)-2T-18 Rank1: 1024MB(auto)-2T-18 DataBus test pass! AddrBus test pass!
Carlos.latour Posted February 19, 2019 Posted February 19, 2019 3 hours ago, Carlos.latour said: In my system, the memory speed messages that work are: 792Mhz (slower thant the 1008 Mhz) ... any way to pass a command to test it at 792mhz instead of 1008? Thanks! .... DDR scramble enabled DDR3 chl: Rank0+1 @ 912MHz - FAIL DDR4 chl: Rank0+1 @ 792MHz - PASS Rank0: 2048MB(auto)-2T-18 Rank1: 1024MB(auto)-2T-18 DataBus test pass! AddrBus test pass! Odd, After clearing the u-boot in the hardware (as explained above) and using an SD card, I manage to get it booting on an 4.x kernel !! Sound/video work, BUT Still have to get it to recognize eth/wifi, (amlogic/dhd modules not in the 5.75 image? or did the modules change name?) Thnx pre-boot messages: GXM:BL1:dc8b51:76f1a5;FEAT:ADFC318C:0;POC:3;RCY:0;EMMC:0;READ:0;0.0;CHK:0; TE: 95046 BL2 Built : 14:59:36, Aug 9 2017. gxl ge8c6a83 - xiaobo.gu@droid12 set vdd cpu_a to 1120 mv set vdd cpu_b to 1050 mv set vddee to 1000 mv Board ID = 10 CPU clk: 1200MHz DQS-corr enabled DDR scramble enabled DDR3 chl: Rank0+1 @ 912MHz - FAIL DDR4 chl: Rank0+1 @ 1008MHz - PASS Rank0: 2048MB(auto)-2T-18 Rank1: 1024MB(auto)-2T-18 DataBus test pass! AddrBus test pass!
Seasalt Posted February 19, 2019 Posted February 19, 2019 On 2/18/2019 at 7:03 AM, AndrewDB said: An identical hardware problem on three separate Km8-P TV boxes Your Km8 Mecools may not be identical. I am not certain my three KM8 Mecools s912 1GB/ 8GB are the same. For a while I tried to boot from the internal 8gb flash. It appeared to me there were slight differences. In the end I just updated all three mecool KM8's internal flash to Android 7 and gave up trying to boot Armbian from the internal flash. Open your units up and have a look at the boards.
Seasalt Posted February 19, 2019 Posted February 19, 2019 14 hours ago, mitico said: i installed firefox and VLC player. I have a problem because when stream on firefox a video on youtube it lag a lot Are you running HTOP system info? It should show you your s912 8 cores CPU loads. Normally when I run x265 Video using I think "mplayer" it is about 90% cpu on all 8 cores. Remember the first 4 cores are 1.5ghz and the second four are I think limited to 1GHz. Firefox in Armbian s912 is a memory hog. VLC does not work well in Armbian s912. You can ssh in to the s912 box and remotely run armbianmonitor -m to keep an eye on temperature. Without a fan my s912 Mecool gets to like 85 degree Celsius. But with a Fan it sits under 90% load playing a video at about 50 degrees Celsius. Its possible the laginess could be the s912 "HEAT THROTTLEing"
Seasalt Posted February 19, 2019 Posted February 19, 2019 1 hour ago, Carlos.latour said: BUT Still have to get it to recognize eth/wifi, I think I gave up on the internal WiFi being configured under Armbian S912 build 67 Ubuntu 18.04 and just plugged a series generic USB wifi dongles in until one was recognized. On my Mecool KM8 s912 Armbian 67 build Ethernet is working fine.
Carlos.latour Posted February 19, 2019 Posted February 19, 2019 38 minutes ago, Seasalt said: I think I gave up on the internal WiFi being configured under Armbian S912 build 67 Ubuntu 18.04 and just plugged a series generic USB wifi dongles in until one was recognized. On my Mecool KM8 s912 Armbian 67 build Ethernet is working fine. Ok for the wifi, guess i'll try to recompile and port the proper drivers.... (still working on my kernel compiling setup, but I'm getting there !) Would you happen to know what ethernet driver's you box is using ? (my box is an M8S Pro, 3g/s912) thx
Seasalt Posted February 19, 2019 Posted February 19, 2019 6 minutes ago, Carlos.latour said: Would you happen to know what ethernet driver's you box is using ? (my box is an M8S Pro, 3g/s912) Give me a terminal command to run on my Mecool km8 and I will cut and paste the output here.
Carlos.latour Posted February 19, 2019 Posted February 19, 2019 2 minutes ago, Seasalt said: Give me a terminal command to run on my Mecool km8 and I will cut and paste the output here. 1 ) to get running modules .. lsmod 2) I do get an error on my setup for this one (I *think* is the phy. eth0, with different hardware) dmesg |grep ath thx! Carlos.
Seasalt Posted February 19, 2019 Posted February 19, 2019 12 minutes ago, Carlos.latour said: 1 ) to get running modules .. lsmod 2) I do get an error on my setup for this one (I *think* is the phy. eth0, with different hardware) dmesg |grep ath thx! Carlos. ~$ lsmod Module Size Used by fuse 102400 3 zstd 16384 8 zram 24576 5 zsmalloc 24576 1 zram meson_rng 16384 0 rng_core 16384 1 meson_rng meson_ir 16384 0 ao_cec 16384 0 scpi_hwmon 16384 0 rc_core 49152 2 meson_ir meson_gxbb_wdt 16384 0 pwm_meson 16384 1 george@aml:~$ dmesg |grep ath [ 8.697551] systemd[1]: Started ntp-systemd-netif.path.
Carlos.latour Posted February 19, 2019 Posted February 19, 2019 2 minutes ago, Seasalt said: ~$ lsmod Module Size Used by fuse 102400 3 zstd 16384 8 zram 24576 5 zsmalloc 24576 1 zram meson_rng 16384 0 rng_core 16384 1 meson_rng meson_ir 16384 0 ao_cec 16384 0 scpi_hwmon 16384 0 rc_core 49152 2 meson_ir meson_gxbb_wdt 16384 0 pwm_meson 16384 1 george@aml:~$ dmesg |grep ath [ 8.697551] systemd[1]: Started ntp-systemd-netif.path. mind doing an 'uname -a' ? (it would appear that ,either I'm way off, or the driver for the eth is compiled in the kernel and not as a module.) thx
Seasalt Posted February 19, 2019 Posted February 19, 2019 4 minutes ago, Carlos.latour said: mind doing an 'uname -a' ? (it would appear that ,either I'm way off, or the driver for the eth is compiled in the kernel and not as a module.) thx hand typing from other screen Linux aml 4.19.2-aml-s9xxx #12 SMP PREEMPT MON DEC 14...MSK 2018 aarch64 aarch64 GNU/Linux
balbes150 Posted February 19, 2019 Author Posted February 19, 2019 With the correct DTB, the wired network works on all models.
Carlos.latour Posted February 19, 2019 Posted February 19, 2019 32 minutes ago, balbes150 said: With the correct DTB, the wired network works on all models. Thanks Balbes, I admit I'm stumped.! I'm using meson-gxm-q201.dtb, (it's the same name as the one on 3.14) did try the q200.dtb with no success. (i'll test the gxl series, just in case.)
Seasalt Posted February 19, 2019 Posted February 19, 2019 46 minutes ago, Carlos.latour said: try the q200.dtb try q201
AndrewDB Posted February 19, 2019 Posted February 19, 2019 3 hours ago, Seasalt said: I think I gave up on the internal WiFi being configured under Armbian S912 build 67 Ubuntu 18.04 and just plugged a series generic USB wifi dongles in until one was recognized. On my Mecool KM8 s912 Armbian 67 build Ethernet is working fine. Yes, the WiFi module in the Km8-P uses a S9082 chip for which there is no source code for any Linux kernel, we just have the .ko module built for the Amlogic 3.14.29 kernel as distributed by hardware vendors that use this module, this is why some xxxxelec images are shipped with this module and provide WiFi, but any Linux image with a kernel other than the original Amlogic 3.14.29 won't - including of course any Armbian image.
AndrewDB Posted February 19, 2019 Posted February 19, 2019 @Carlos.latour Since your box is a M8S Pro, 3g/s912, it uses a different WiFi chip from the Km8-P and possibly also the ethernet is wired differently, so there is a possibility that you might be able to use it. You could open the case, take a close-up picture of the PCB (both sides), and post it here, that would provide a good amount of information to help get you going. You should really try all the DTB files for meson-gxm-*
Carlos.latour Posted February 19, 2019 Posted February 19, 2019 1 minute ago, AndrewDB said: @Carlos.latour Since your box is a M8S Pro, 3g/s912, it uses a different WiFi chip from the Km8-P and possibly also the ethernet is wired differently, so there is a possibility that you might be able to use it. You could open the case, take a close-up picture of the PCB (both sides), and post it here, that would provide a good amount of information to help get you going. You should really try all the DTB files for meson-gxm-* did try all the gxm-xxxx and some of the gxl, still no joy there, I'll reopen the box and identify the actual chips. (I am however thinking that I may have blown the hardware, as the u-boot 2018 doesn't recognize and interface there ...)
Recommended Posts