rmoriz Posted January 28, 2019 Author Posted January 28, 2019 20 minutes ago, 5kft said: Sure, but it is rather difficult to solve a problem if you don't try to debug it Why not put a little more effort into this, it certainly is an interesting and strange problem...! If you read this thread, you already see that I put some effort into it. Given that there is no documentation about the source of the overlay and u-boot files in Armbian, there is little to debug. It should be easy for you to tell me e.g. which u-boot patches your image uses or at least which git ref you build
martinayotte Posted January 28, 2019 Posted January 28, 2019 10 minutes ago, rmoriz said: you already see that I put some effort into it. Maybe, but you are mixing symptoms and issues and refuse to do what we suggested ... As I said twice, and now a third time, did you do : Quote If you re-run "nand-sata-install", does it provide the option "Install/Update the bootloader on SD/eMMC" ? If Yes, simply give it a try ... If the RootFS on eMMC is Ok, and only refuse to boot directly from eMMC, then it is U-Boot that needs to be recovered ...
5kft Posted January 28, 2019 Posted January 28, 2019 1 minute ago, rmoriz said: If you read this thread, you already see that I put some effort into it. Given that there is no documentation about the source of the overlay and u-boot files in Armbian, there is little to debug. It should be easy for you to tell me e.g. which u-boot patches your image uses or at least which git ref you build Indeed...it's a very odd problem! There's actually a lot you can try to debug, but you'll have to figure some things out. You can start where I started last year: https://docs.armbian.com/Developer-Guide_Build-Preparation/. If you follow the build process (see the "How to start?" section) you'll end up with everything you need locally - all source, all patches, etc. will be present in the "build" tree. This is truly one of the awesome things about Armbian - give it a try, it's very cool!
rmoriz Posted January 28, 2019 Author Posted January 28, 2019 8 minutes ago, martinayotte said: Maybe, but you are mixing symptoms and issues and refuse to do what we suggested ... As I said twice, and now a third time, did you do : If the RootFS on eMMC is Ok, and only refuse to boot directly from eMMC, then it is U-Boot that needs to be recovered ... I did that ~25 times using 4 different Armbian builds without success however the year old OrangePI Ubuntu image does successfully install to eMMC *and* boot after. After checking the eMMC integrity successfully, there are two possibilities left: A. It never worked with Armbian B. It worked in an old Armbian release which is not available anymore. C. something changed in BROM (or whatver this is called with Allwinner) with my late 2018 board. This is very unlikely because the year old OrangePI image works. If A): Ok, I'll accept and stop If B): Tell me which version worked so I can do a bisect manually and debug. Thanks
guidol Posted January 28, 2019 Posted January 28, 2019 5 hours ago, rmoriz said: Has someone of you actually managed to get a full eMMC based installation working with nand-sata-install on the Orange Pi Zero Plus2 H5? as I now recall I had problems with the transfer to eMMC with the latest DEV build, but only because I used a old/slow and maybe defective 16GB SanDIsk Ultra. The problem was that after 53% of transfer the system doenst answered and disconnected the SSH-session. After that I used my 32GB Sandisk Extreme and it worked in the 1st try. Did you try to install/transfer to eMM with another (more speedy) card? The "defective" 16GB Card could formatted without problems and I could write the image with ecther without no problem (incl. verify), but I do see this strange time-leaks while setting up the inital password and adding the first user after root.
martinayotte Posted January 28, 2019 Posted January 28, 2019 23 minutes ago, rmoriz said: I did that ~25 times using 4 different Armbian builds without success however the year old OrangePI Ubuntu image does successfully install to eMMC *and* boot after. I hope you don't use the same method used for installing eMMC using a Non-Armbian image with Armbian one which is "nand-sata-install". As I said earlier, on my OPiZeroPlus2-H5, I've installed Armbian on eMMC successfully several times since years and last time was 2 weeks ago with 4.20.y. Did you have done what I suggested, first : Quote To see more verbosity, edit /boot/armbianEnv.txt, make sure that "verbosity=7" and "console=serial" instead of "console=both". Then, for the fourth time, did you have done : Quote If you re-run "nand-sata-install", does it provide the option "Install/Update the bootloader on SD/eMMC" ? If Yes, simply give it a try ... If really Yes, what was the results ? When rebooting without SDCard inserted, do you see any u-boot activity ? Is it starting booting the kernel ? if Yes, what is the output just before it abort and reboot in loop ? Does it says that it can't find RootFS with proper UUID ? Did you check if UUID are properly set in both /boot/armbianEnv.txt and /etc/fstab of the eMMC (not the one from SDCard) ? 23 minutes ago, rmoriz said: If A): Ok, I'll accept and stop If B): Tell me which version worked so I can do a bisect manually and debug. None of the above, since it works for all of us, and you seems to be the only one to get such failure ...
guidol Posted January 28, 2019 Posted January 28, 2019 To be sure I did compile this evening the actual (of today) DEV-version: Armbian_5.73_Orangepizeroplus2-h5_Debian_stretch_dev_4.20.2.img Flashed it to sdcard via etcher - and after a little bit configuring - I transfered it (using a Samsung EVO 32GB) to the eMMCwithout problems: ARMBIAN 5.73 user-built Debian GNU/Linux 9 (stretch) 4.20.2-sunxi64 Linux opi-zero-plus2-h5 4.20.2-sunxi64 #5.73 SMP Mon Jan 28 20:12:49 +03 2019 aarch64 GNU/Linux Dateisystem 1K-Blöcke Benutzt Verfügbar Verw% Eingehängt auf udev 178024 0 178024 0% /dev tmpfs 49292 2308 46984 5% /run /dev/mmcblk2p1 7370336 1268920 5707308 19% / tmpfs 246448 0 246448 0% /dev/shm tmpfs 5120 4 5116 1% /run/lock tmpfs 246448 0 246448 0% /sys/fs/cgroup tmpfs 246448 4 246444 1% /tmp /dev/zram0 49584 3136 42864 7% /var/log tmpfs 49288 0 49288 0% /run/user/0
rmoriz Posted January 28, 2019 Author Posted January 28, 2019 4 hours ago, martinayotte said: I hope you don't use the same method used for installing eMMC using a Non-Armbian image with Armbian one which is "nand-sata-install". As I said earlier, on my OPiZeroPlus2-H5, I've installed Armbian on eMMC successfully several times since years and last time was 2 weeks ago with 4.20.y. Did you have done what I suggested, first : Then, for the fourth time, did you have done : If really Yes, what was the results ? When rebooting without SDCard inserted, do you see any u-boot activity ? Is it starting booting the kernel ? if Yes, what is the output just before it abort and reboot in loop ? Does it says that it can't find RootFS with proper UUID ? Did you check if UUID are properly set in both /boot/armbianEnv.txt and /etc/fstab of the eMMC (not the one from SDCard) ? None of the above, since it works for all of us, and you seems to be the only one to get such failure ... I know, I posted a lot, so I'll summarize it quickly for you: The remaining issue with Armbian is the "CPU reset" loop after a nand-sata-install immediately after power-up. There is no need to increase kernel verbosity because the kernel gets never loaded. U-Boot is broken.
rmoriz Posted January 28, 2019 Author Posted January 28, 2019 3 hours ago, guidol said: To be sure I did compile this evening the actual (of today) DEV-version: Armbian_5.73_Orangepizeroplus2-h5_Debian_stretch_dev_4.20.2.img Flashed it to sdcard via etcher - and after a little bit configuring - I transfered it (using a Samsung EVO 32GB) to the eMMCwithout problems: ARMBIAN 5.73 user-built Debian GNU/Linux 9 (stretch) 4.20.2-sunxi64 Linux opi-zero-plus2-h5 4.20.2-sunxi64 #5.73 SMP Mon Jan 28 20:12:49 +03 2019 aarch64 GNU/Linux Dateisystem 1K-Blöcke Benutzt Verfügbar Verw% Eingehängt auf udev 178024 0 178024 0% /dev tmpfs 49292 2308 46984 5% /run /dev/mmcblk2p1 7370336 1268920 5707308 19% / tmpfs 246448 0 246448 0% /dev/shm tmpfs 5120 4 5116 1% /run/lock tmpfs 246448 0 246448 0% /sys/fs/cgroup tmpfs 246448 4 246444 1% /tmp /dev/zram0 49584 3136 42864 7% /var/log tmpfs 49288 0 49288 0% /run/user/0 Did you remove the SD card? Does it boot without the SD-Card?
martinayotte Posted January 28, 2019 Posted January 28, 2019 11 minutes ago, rmoriz said: The remaining issue with Armbian is the "CPU reset" loop after a nand-sata-install immediately after power-up. There is no need to increase kernel verbosity because the kernel gets never loaded. U-Boot is broken. What brings you that "U-Boot is broken." ? Many people here are trying to help you, but you're jumping to wrong conclusion ... If you don't want to increase verbosity, which is quite simple task, you don't even know why causing the kernel reboot in loop during this famous 44secs . I bet it is a UUID issue !!! If you don't do what we are asking for, no one will be able to help you !!! Simple is that !!!
martinayotte Posted January 28, 2019 Posted January 28, 2019 13 minutes ago, rmoriz said: Did you remove the SD card? Does it boot without the SD-Card? Of course @guidol will say YES ! (but I will leave him to say it by himself ...)
guidol Posted January 29, 2019 Posted January 29, 2019 9 hours ago, martinayotte said: Of course @guidol will say YES ! (but I will leave him to say it by himself ...) YES after the transfer to eMMC I did "poweroff" and remove the sdcard. At next poweron the Plus2 H5 did boot without problems from eMMC.
rmoriz Posted January 29, 2019 Author Posted January 29, 2019 I've built a custom image using the docker method (result was named Armbian_5.73_Orangepizeroplus2-h5_Ubuntu_bionic_next_4.19.17.img), etched it to SD, booted and installed it to eMMC. Result: U-Boot SPL 2018.11-armbian (Jan 28 2019 - 23:02:45 +0000) DRAM: 512 MiB Trying to boot from MMC2 (hangs, no LED, serial output) compared to the behaviour of the release image (as mentioned in my opening post already) U-Boot SPL 2018.05-armbian (Jan 12 2019 - 18:49:16 +0100) DRAM: 512 MiB Trying to boot from MMC2 (looping) "Synchronous Abort" handler, esr 0x8a000000 elr: 0000000000016895 lr : 0000000000016895 x 0: 0000000000017718 x 1: 0000000000000500 x 2: 0000000000000001 x 3: ffffff80ffffffc8 x 4: 0000000000000001 x 5: 000000000000004a x 6: 000000004fdffba8 x 7: 000000000000000a x 8: 0000000000000044 x 9: 800303d600000000 x10: 9419820400000000 x11: 000000000000000c x12: 4028177e0007fffe x13: 02042420a1fe8820 x14: 1c4401836c41c200 x15: 0012010004200000 x16: 102520254a2c0844 x17: 0c03fc405001bb46 x18: 000000004fdffe80 x19: 0000000000000022 x20: 00000000ffffffc8 x21: 000000004fdff0f0 x22: 000000000001717b x23: 000000000001717b x24: 000000004fdff0b0 x25: 000000004fdff5f1 x26: 000000004fdff0b1 x27: 0000000000000030 x28: 5e0f2289281c052c x29: 000000004fdff410 Resetting CPU ... resetting ... (/looping) PS: Yes, I've set verbosity=7 and console=both as before, by manually mounting the emmc filesystem and chaging /boot/armbianEnv.txt. There is sadly no change in outcome/output.
martinayotte Posted January 29, 2019 Posted January 29, 2019 22 minutes ago, rmoriz said: There is sadly no change in outcome/output Thanks for the effort ! Sorry if I've been rude earlier ... Strange issue ... Could you provide picture of the eMMC ? If it differ from the one on all forum members's boards, like mine, it is maybe a new eMMC chip not supported yet by U-Boot, but still strange since it is working on a already booted kernel. I will search in U-Boot forums, mailing list, and IIRC to see if a U-Boot dev already have a fix, but I doubt since Armbian is already using v2018.11, which is quite recent ...
rmoriz Posted January 29, 2019 Author Posted January 29, 2019 47 minutes ago, martinayotte said: Strange issue ... Could you provide picture of the eMMC ?If it differ from the one on all forum members's boards, like mine, it is maybe a new eMMC chip not supported yet by U-Boot, but still strange since it is working on a already booted kernel. I think this is the eMMC: upper side just for reference (says V 1.0) Thanks!
5kft Posted January 30, 2019 Posted January 30, 2019 Interesting...my Plus2 H5 boards all use Samsung KLM8G1WEPD-B031 parts (eMMC 5.0); @rmoriz's board uses a KLM8G1GETF-B041 (eMMC 5.1). I wonder if there might be an issue with eMMC 5.1 compatibility perhaps?
martinayotte Posted January 30, 2019 Posted January 30, 2019 2 hours ago, rmoriz said: Thanks! Right ! The eMMC is the one on the bottom side ... Yours is KLM8G1GETF, mine is KLM8G1WEPD . Can any other OPiZeroPlus2-H5 can tell what are their eMMC chip number ? I've also a OPiZeroPlus2-H3, and it has also WEPD version ... That must be the culprit ... EDIT : @Igor , if you get in touch with Steven from Xunlong in a near future, can you confirm with him about chip change ? Still, I don't know what need to be tweak in u-boot ... I will try to compare between u-boot and kernel drivers ... EDIT2 : @Igor , can you ask Steven to send me new OPiZeroPlus2-H5 so I can debug this issue ?
5kft Posted January 30, 2019 Posted January 30, 2019 2 minutes ago, martinayotte said: Right ! The eMMC is the one on the bootom side ... Yours is KLM8G1GETF, mine is KLM8G1WEPD . Can any other OPiZeroPlus2-H5 can tell what are their eMMC chip number ? I've also a OPiZeroPlus2-H3, and it has also WEPD version ... That must be the culprit ... Yes, mine use WEPD, and my NEO Core2 boards all have WEPD. However, I have an new/not-yet-used NEO Plus2 that has a GETF part (same as @rmoriz). I'll try flashing it and see how it goes.
martinayotte Posted January 30, 2019 Posted January 30, 2019 4 hours ago, rmoriz said: I've built a custom image @rmoriz are you willing to do another build ? it seems that there are few commit in u-boot mainline since v2018.11 ... In your Armbian build scripts, edit this line https://github.com/armbian/build/blob/master/config/sources/sunxi64_common.inc#L7 and change u-boot tag to v2019.01, it is almost hot from the oven ... Hoping this will fix the issue, but no warranty ...
5kft Posted January 30, 2019 Posted January 30, 2019 @martinayotte, for what it's worth, my NEO Plus2 running from the eMMC flash part KLM8G1GETF-B041 works great...: U-Boot SPL 2018.11-armbian (Jan 28 2019 - 12:38:34 +0100) DRAM: 1024 MiB Trying to boot from MMC2 NOTICE: BL31: v2.0(debug):bc15388 NOTICE: BL31: Built : 12:32:31, Jan 28 2019 NOTICE: BL31: Detected Allwinner H5 SoC (1718) NOTICE: BL31: Found U-Boot DTB at 0x40843b8, model: FriendlyARM NanoPi NEO Plus 2 INFO: ARM GICv2 driver initialized INFO: Configuring SPC Controller NOTICE: BL31: PMIC: Defaulting to PortL GPIO according to H5 reference design. INFO: BL31: Platform setup done INFO: BL31: Initializing runtime services INFO: BL31: cortex_a53: CPU workaround for 855873 was applied INFO: BL31: Preparing for EL3 exit to normal world INFO: Entry point address = 0x4a000000 INFO: SPSR = 0x3c9 U-Boot 2018.11-armbian (Jan 28 2019 - 12:38:34 +0100) Allwinner Technology CPU: Allwinner H5 (SUN50I) Model: FriendlyARM NanoPi NEO Plus 2 DRAM: 1 GiB MMC: SUNXI SD/MMC: 0, SUNXI SD/MMC: 1 Loading Environment from EXT4... MMC: no card present In: serial Out: serial Err: serial Net: No ethernet found. MMC: no card present MMC: no card present starting USB... USB0: USB EHCI 1.00 USB1: USB OHCI 1.0 scanning bus 0 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Autoboot in 1 seconds, press <Space> to stop switch to partitions #0, OK mmc1(part 0) is current device Scanning mmc 1:1... Found U-Boot script /boot/boot.scr 3042 bytes read in 5 ms (593.8 KiB/s) ## Executing script at 4fc00000 U-boot loaded from eMMC or secondary SD Boot script loaded from mmc 194 bytes read in 2 ms (94.7 KiB/s) MMC: no card present 28823 bytes read in 13 ms (2.1 MiB/s) 504 bytes read in 15 ms (32.2 KiB/s) Applying kernel provided DT overlay sun50i-h5-usbhost1.dtbo 504 bytes read in 15 ms (32.2 KiB/s) Applying kernel provided DT overlay sun50i-h5-usbhost2.dtbo 4155 bytes read in 12 ms (337.9 KiB/s) Applying kernel provided DT fixup script (sun50i-h5-fixup.scr) ## Executing script at 44000000 5329311 bytes read in 262 ms (19.4 MiB/s) 14245896 bytes read in 697 ms (19.5 MiB/s) ## Loading init Ramdisk from Legacy Image at 4fe00000 ... Image Name: uInitrd Image Type: AArch64 Linux RAMDisk Image (gzip compressed) Data Size: 5329247 Bytes = 5.1 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 4fa00000 Booting using the fdt blob at 0x4fa00000 EHCI failed to shut down host controller. Loading Ramdisk to 49aea000, end 49fff15f ... OK reserving fdt memory region: addr=4fa00000 size=6d000 Loading Device Tree to 0000000049a7a000, end 0000000049ae9fff ... OK Starting kernel ... Loading, please wait... starting version 232 Begin: Loading essential drivers ... done. Begin: Running /scripts/init-premount ... done. Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done. Begin: Running /scripts/local-premount ... Scanning for Btrfs filesystems done. Begin: Will now check root file system ... fsck from util-linux 2.29.2 [/sbin/fsck.ext4 (1) -- /dev/mmcblk2p1] fsck.ext4 -a -C0 /dev/mmcblk2p1 /dev/mmcblk2p1: clean, 37821/472352 files, 359379/1888624 blocks done. done. Begin: Running /scripts/local-bottom ... done. Begin: Running /scripts/init-bottom ... done. Welcome to Debian GNU/Linux 9 (stretch)! [ OK ] Created slice User and Session Slice. [ OK ] Listening on fsck to fsckd communication Socket. [ OK ] Listening on Journal Socket. [ OK ] Started Dispatch Password Requests to Console Directory Watch. [ OK ] Listening on Journal Socket (/dev/log). [ OK ] Listening on udev Kernel Socket. [ OK ] Reached target Swap. [ OK ] Created slice System Slice. Starting Remount Root and Kernel File Systems... [ OK ] Listening on udev Control Socket. Mounting Debug File System... ... [ OK ] Reached target Network is Online. Starting LSB: Start NTP daemon... Starting /etc/rc.local Compatibility... Starting LSB: Advanced IEEE 802.11 management daemon... [ OK ] Started /etc/rc.local Compatibility. [ OK ] Started LSB: Advanced IEEE 802.11 management daemon. [ OK ] Started Serial Getty on ttyS0. [ OK ] Started Getty on tty1. [ OK ] Started LSB: Start NTP daemon. Debian GNU/Linux 9 nanopineoplus2 ttyS0 nanopineoplus2 login: root Password: Last login: Wed Jan 30 01:59:48 UTC 2019 on ttyS0 _ _ ____ _ _ _ ____ _ ____ | \ | | _ \(_) | \ | | ___ ___ | _ \| |_ _ ___ |___ \ | \| | |_) | | | \| |/ _ \/ _ \ | |_) | | | | / __| __) | | |\ | __/| | | |\ | __/ (_) | | __/| | |_| \__ \ / __/ |_| \_|_| |_| |_| \_|\___|\___/ |_| |_|\__,_|___/ |_____| Welcome to ARMBIAN 5.73 stable Debian GNU/Linux 9 (stretch) 4.19.17-sunxi64 System load: 0.48 0.13 0.04 Up time: 0 min Memory usage: 7 % of 993MB IP: 192.168.1.191 CPU temp: 51�‹C Usage of /: 18% of 7.1G root@nanopineoplus2:~# df -h Filesystem Size Used Avail Use% Mounted on udev 430M 0 430M 0% /dev tmpfs 100M 3.0M 97M 3% /run /dev/mmcblk2p1 7.1G 1.2G 5.5G 18% / tmpfs 497M 0 497M 0% /dev/shm tmpfs 5.0M 4.0K 5.0M 1% /run/lock tmpfs 497M 0 497M 0% /sys/fs/cgroup tmpfs 497M 4.0K 497M 1% /tmp /dev/zram0 49M 1.4M 44M 3% /var/log tmpfs 100M 0 100M 0% /run/user/0 root@nanopineoplus2:~# root@nanopineoplus2:~# hdparm -tT /dev/mmcblk2 /dev/mmcblk2: Timing cached reads: 1004 MB in 2.00 seconds = 501.26 MB/sec Timing buffered disk reads: 132 MB in 3.01 seconds = 43.85 MB/sec root@nanopineoplus2:~# apt-get update Hit:1 http://security.debian.org stretch/updates InRelease Ign:2 http://cdn-fastly.deb.debian.org/debian stretch InRelease Hit:4 http://cdn-fastly.deb.debian.org/debian stretch-updates InRelease Hit:5 http://cdn-fastly.deb.debian.org/debian stretch-backports InRelease Hit:6 http://cdn-fastly.deb.debian.org/debian stretch Release Hit:3 https://apt.armbian.com stretch InRelease Reading package lists... Done root@nanopineoplus2:~# apt-get dist-upgrade Reading package lists... Done Building dependency tree Reading state information... Done Calculating upgrade... Done 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. root@nanopineoplus2:~# Given this, I don't think it's an issue with the flash part version/type... Maybe there a different/subtle H/W change in the new Orange Pi Zero Plus2 H5?
Igor Posted January 30, 2019 Posted January 30, 2019 8 hours ago, rmoriz said: I think this is the eMMC: I talked with Xunlong about this - they are saying to contact them and provide order records. Keep reference on this topics.
Igor Posted January 30, 2019 Posted January 30, 2019 6 hours ago, martinayotte said: if you get in touch with Steven from Xunlong in a near future, can you confirm with him about chip change ? Confirmed. "we have changed the EMMC about one year ago" "KLM8G1WEPD-B031 part: this module is out of the market" "We sell products with KLM8G1GETF-B041 (eMMC 5.1) for almost one year." 6 hours ago, martinayotte said: can you ask Steven to send me new OPiZeroPlus2-H5 so I can debug this issue It's possible, yes. Shell I told him?
guidol Posted January 30, 2019 Posted January 30, 2019 2 hours ago, Igor said: Confirmed. "we have changed the EMMC about one year ago" "KLM8G1WEPD-B031 part: this module is out of the market" "We sell products with KLM8G1GETF-B041 (eMMC 5.1) for almost one year." Wow - and now we got the "first" Plus2 (H5) which has problems installing to a v5.1 eMMc? It seems that there are many v5.0 eMMC boards around...
rmoriz Posted January 30, 2019 Author Posted January 30, 2019 @martinayotte custom built Armbian_5.74_Orangepizeroplus2-h5_Ubuntu_bionic_next_4.19.17.img with U-Boot 2019.01 sadly hangs at the same point as the 2018.11 release: U-Boot SPL 2019.01-armbian (Jan 30 2019 - 13:08:51 +0000) DRAM: 512 MiB Trying to boot from MMC2 @Igor I've contacted "zhao_steven" via mail today at 13:05 UTC providing a screenshot of my AliExpress order and a summary of the thread including a link.
5kft Posted January 30, 2019 Posted January 30, 2019 4 hours ago, guidol said: Wow - and now we got the "first" Plus2 (H5) which has problems installing to a v5.1 eMMc? It seems that there are many v5.0 eMMC boards around... It's definitely odd...I'm wondering if the eMMC part version is a red herring, unless there is a subtle configuration difference between the bootloaders for these boards? This would be worth checking. Both of my NEO Plus2s use the newer v5.1 GETF eMMC part and they work fine. Granted it's a completely different board than the OPi, but the major H/W parts are the same. It'll be interesting to try another OPi Plus2 with this part to see if the problem is reproducible.
martinayotte Posted January 30, 2019 Posted January 30, 2019 7 hours ago, Igor said: It's possible, yes. Shell I told him? Yes ! This will help to figured out the issue ...
Igor Posted January 30, 2019 Posted January 30, 2019 16 minutes ago, martinayotte said: Yes ! This will help to figured out the issue ... OK. There is only one problem left. Chinese holidays starts tomorrow. I sent request, but it might took +two weeks to get there.
martinayotte Posted January 30, 2019 Posted January 30, 2019 2 minutes ago, Igor said: Chinese holidays starts tomorrow. Right !
Igor Posted February 6, 2019 Posted February 6, 2019 This https://lkml.org/lkml/2019/2/3/422 was just included. Perhaps it will solve those problems?
Recommended Posts