Christos

Hi, Creating a build for OPiPCPlus, mainline/dev/4.11, xenial,desktop. Need to enable the UDA1380 device in my local kernel build, yet I see some ..obstacles.. Tried initially to do a KERNEL_CONFIGURE="yes" in compile.sh but after started the compile and reached the point of menuconfig the UDA1380 option did not got presented (might be because there is no tristate string in mainline sound/soc/codecs/Kconfig..) so I reverted it back to normal. After the first attempt, I tried by modifying the lib/config/kernel/linux-sun8i-dev.config and added "CONFIG_SND_SOC_UDA1380=m", tried the compile again and waited to finish, yet at the end, although the other .o object files (bt, spdif) created correctly in the sources/linux-sun8i-mainline/orange-pi-4.11/sound/soc/codecs folder, the required UDA1380 did not. So, is there something that I miss here or doing it not right? Is there another 'proper' way to enable a mainline kernel device in Armbian? Christos

IMHO FA might go for the S912 now.. They already got M3 (with Samsung CPU) in the past as a 8xCore (and from my experience on it its really fast) but it lacked support, now with Amlogic the foundations are already there to deliver the first decent and trully mainline supported hacker-friendly 8xCore 64-bit A53 SBC.

I bet we will soon see hats from FA, most likely a new version of this -> http://wiki.friendlyarm.com/wiki/index.php/Matrix_-_NanoHat_PCM5102A targeted to the K2, just sayin..

A new 4xA53 Amlogic S905 board from FriendlyArm. -> http://www.friendlyarm.com/index.php?route=product/product&path=69&product_id=186 Really interesting.

Last time I checked the title was reading "OPi Prime board", and my comments are about that board's design. Where do you see the off-topic? BTW: If you feel like it, you are an admin, delete the posts.

Yep, even from the PC2 release had contacted Steven about it in order to catch if possible the replication of the flaw to any new design but as it seems to no avail.. For the Prime, I also contacted him directly as soon as I saw the schematic, he knows this but he mentioned that I should go to the orangepi forum and discuss it because its a ..technical detail..

USB DAC dongles are usually (known to all audiophiiles) crappy/jittery/noisy devices. If I wanted to do that I could do it in every board is out there and has a USB, but as you understand that is not what I said.

Dont know who Steven's board designer is, but has failed hard in that board too as he has failed on the PC2 previously. Again in OrangePi Prime the PCM0 pins are used to turn on ..leds. Crippling both two new A53 boards and not been able to use any DAC from the myriads that are out there, so Xunlong again going away from the audiophile audience.

Tried latest build up to commit c195926 OPi+2E, Ubuntu xenial desktop, default kernel Build failed with this Armbian building script, http://www.armbian.com | Author: Igor Pecovnik ────────────────────────────────────────────────────────────────────────────── ┌────────────────────────────────────────────────────────────────────────┠│ Compiling kernel... │ │────────────────────────────────────────────────────────────────────────│ │ &cec_phy_addr, │ │ ^ │ │ drivers/video/sunxi/disp2/hdmi/aw/hdmi_cec.c:703:9: note: each undecla │ │ scripts/Makefile.build:313: recipe for target 'drivers/video/sunxi/dis │ │ make[4]: *** [drivers/video/sunxi/disp2/hdmi/aw/hdmi_cec.o] Error 1 │ │ scripts/Makefile.build:443: recipe for target 'drivers/video/sunxi/dis │ │ make[3]: *** [drivers/video/sunxi/disp2/hdmi] Error 2 │ │ scripts/Makefile.build:443: recipe for target 'drivers/video/sunxi' fa │ │ make[2]: *** [drivers/video/sunxi] Error 2 │ │ make[2]: *** Waiting for unfinished jobs.... │ │ scripts/Makefile.build:443: recipe for target 'drivers/video' failed │ │ make[1]: *** [drivers/video] Error 2 │ │ Makefile:948: recipe for target 'drivers' failed │ │ make: *** [drivers] Error 2 │ └────────────────────────────────────────────────────────────────────────┘ [ error ] ERROR in function compile_kernel [ common.sh:254 ] [ error ] Kernel was not built [ @host ] [ o.k. ] Process terminated

For what is worth it, IMHO, FA's NanoPi A64 is a pretty decent and in my personal view it fits as a better, cheaper and direct replacement of RPi-3 in almost all aspects. FA is indeed better than others in providing decent BSP and images but they still lack many wanted features and their support is hectic, also in their lately delivered A64 image there are more than enough problems.. Regarding the H5 to A64 comparison, so far only the PC2 (H5) came close to be good enough, but its expansion pinheader faulty design did crippled it. Also, H5 is not yet in the mainline sunxi effort table whereas A64 is already there and in the hands of many sunxi devs, its mainline support is on a good path. So, based on these, I'd be really surprised if Armbian elect not to support this.

Are there plans from Armbian regarding support of this board?

Had this issue too. It is fixed today evening so if you can build now a new image it will be ok.

Performed another H3 OPi+2E build, Ubuntu mainline desktop, up to commit 36ae17d Now the screen/HDMI does work, yet there still is a reported error [ OK ] Mounted Debug File System. [ OK ] Started Create list of required sta...ce nodes for the current kernel. [FAILED] Failed to start Load Kernel Modules. See 'systemctl status systemd-modules-load.service' for details. [ OK ] Started Set console keymap. [ OK ] Started Restore / save the current clock. [ OK ] Started Remount Root and Kernel File Systems. Warning: systemd-modules-load.service changed on disk. Run 'systemctl daemon-reload' to reload units. ◠systemd-modules-load.service - Load Kernel Modules Loaded: loaded (/lib/systemd/system/systemd-modules-load.service; static; vendor preset: enabled) Drop-In: /etc/systemd/system/systemd-modules-load.service.d └─10-timeout.conf Active: failed (Result: exit-code) since Tue 2017-01-31 20:14:29 EET; 5min ago Docs: man:systemd-modules-load.service(8) man:modules-load.d(5) Process: 237 ExecStart=/lib/systemd/systemd-modules-load (code=exited, status=1/FAILURE) Main PID: 237 (code=exited, status=1/FAILURE) Warning: Journal has been rotated since unit was started. Log output is incomplete or unavailable. root@orangepiplus2e:~# Dont know exactly where it comes from so I report the entire dmesg

Did a clean build (deleted all cache & sources), for OPi+2E, Ubuntu development, with desktop. (up to commit 633824d) Build ok and copied on SD, yet after boot no HDMI screen came out boot [ OK ] Started Create list of required sta...ce nodes for the current kernel. [ OK ] Started Set console keymap. [FAILED] Failed to start Load Kernel Modules. See 'systemctl status systemd-modules-load.service' for details. [ OK ] Started Remount Root and Kernel File Systems. [ OK ] Started Nameserver information manager. root@orangepiplus2e:~# systemctl status systemd-modules-load.service Warning: systemd-modules-load.service changed on disk. Run 'systemctl daemon-reload' to reload units. ◠systemd-modules-load.service - Load Kernel Modules Loaded: loaded (/lib/systemd/system/systemd-modules-load.service; static; vendor preset: enabled) Drop-In: /etc/systemd/system/systemd-modules-load.service.d └─10-timeout.conf Active: failed (Result: exit-code) since Tue 2017-01-31 14:18:41 UTC; 10min ago Docs: man:systemd-modules-load.service(8) man:modules-load.d(5) Process: 246 ExecStart=/lib/systemd/systemd-modules-load (code=exited, status=1/FAILURE) Main PID: 246 (code=exited, status=1/FAILURE) Warning: Journal has been rotated since unit was started. Log output is incomplete or unavailable. dmesg [ 3.250482] ------------[ cut here ]------------ [ 3.250502] WARNING: CPU: 2 PID: 1 at arch/arm/mm/ioremap.c:303 __arm_ioremap_pfn_caller+0x5d/0x12c [ 3.250505] Modules linked in: [ 3.250517] CPU: 2 PID: 1 Comm: swapper/0 Not tainted 4.9.4-sun8i #1 [ 3.250520] Hardware name: Allwinner sun8i Family [ 3.250543] [<c010b891>] (unwind_backtrace) from [<c0108ec3>] (show_stack+0xb/0xc) [ 3.250556] [<c0108ec3>] (show_stack) from [<c04266d7>] (dump_stack+0x67/0x74) [ 3.250570] [<c04266d7>] (dump_stack) from [<c0117411>] (__warn+0xa9/0xbc) [ 3.250579] [<c0117411>] (__warn) from [<c011748f>] (warn_slowpath_null+0x13/0x18) [ 3.250589] [<c011748f>] (warn_slowpath_null) from [<c0111dbd>] (__arm_ioremap_pfn_caller+0x5d/0x12c) [ 3.250600] [<c0111dbd>] (__arm_ioremap_pfn_caller) from [<c0111eb9>] (__arm_ioremap_caller+0x2d/0x38) [ 3.250612] [<c0111eb9>] (__arm_ioremap_caller) from [<c046150f>] (simplefb_probe+0x1c3/0x654) [ 3.250625] [<c046150f>] (simplefb_probe) from [<c0497517>] (platform_drv_probe+0x33/0x74) [ 3.250635] [<c0497517>] (platform_drv_probe) from [<c049658b>] (driver_probe_device+0x14f/0x1c8) [ 3.250647] [<c049658b>] (driver_probe_device) from [<c04953ab>] (bus_for_each_drv+0x37/0x54) [ 3.250659] [<c04953ab>] (bus_for_each_drv) from [<c049639b>] (__device_attach+0x6f/0xb8) [ 3.250670] [<c049639b>] (__device_attach) from [<c0495c71>] (bus_probe_device+0x55/0x5c) [ 3.250681] [<c0495c71>] (bus_probe_device) from [<c0494a3d>] (device_add+0x2d9/0x400) [ 3.250695] [<c0494a3d>] (device_add) from [<c05a2ec3>] (of_platform_device_create_pdata+0x5b/0x84) [ 3.250712] [<c05a2ec3>] (of_platform_device_create_pdata) from [<c0a15227>] (simplefb_init+0x43/0x58) [ 3.250725] [<c0a15227>] (simplefb_init) from [<c01016b9>] (do_one_initcall+0x31/0x110) [ 3.250736] [<c01016b9>] (do_one_initcall) from [<c0a00b83>] (kernel_init_freeable+0x17f/0x1e4) [ 3.250749] [<c0a00b83>] (kernel_init_freeable) from [<c069dbd7>] (kernel_init+0x7/0xd4) [ 3.250761] [<c069dbd7>] (kernel_init) from [<c0105f31>] (ret_from_fork+0x11/0x20) [ 3.250771] ---[ end trace d6bff669de280e74 ]--- [ 3.250788] simple-framebuffer: probe of b9f40000.framebuffer failed with error -12 P.S. Trying now again this time for a mainliine Debian/Desktop, but it takes about two hours on my system.. P.S.2 -> same problem in Debian mainline desktop build.

Is there any equivalent information for mainline images? Or even how to test any available mainline WIP regarding I2S?

Ooops.. sorry, yes you are right. I'm always doing that mistake..

Ok, just thought that it would be easy if H5 and H3 share common hdmi code and since PC2 now is really working great. If its too much then obviously we can live with the current situation which is very good. Regarding artifacts, in H3 there is a bit at some point, definitively not the full screen as it was before the fix, just a momentary noise-stripe artifact (it is there in all recent H3 builds), but in PC2 there was nothing at all !!

@zador.blood.stained @jernej The HDMI operation in PC2 looks absolutely brilliant, it is automagically discovering monitor resolution and there are no artifacts shown while booting, trully great. If the H5 and H3 share common HDMI code can you guys put that too in H3? Tried a new (H3) build, up to and including commit "Update H3 HDMI driver in u-boot for a "OPi+2E and these things miss, still some artifacts during boot and no auto resolution discovery, is it possible to put them there too?

Obviously something was wrong before here, so did another build and changed SD card just in case. All are ok now, tested up to latest commit 3d8fce2. BTW, very nice HDMI behaviour! everything works properly automagically!

For you it was already working from the start. If you remember there was the pullup issue for some.. P.S. I'm performing another build, just in case something went wrong before..

Did another build with latest commits. Non-booting problem again. Latest commit that was working ok was commit dc6f9d9, with commits after that it stopped booting properly and go into endless reboots.

@zador.blood.stained It looks that the latest builds (Ubuntu desktop) give a very good result and stable operation as tested with my own DSP application here. Tried a few reboots and had no issues, though I see some strange reporting in the tty console Unmounting /var/log... [FAILED] Failed unmounting /tmp. [ OK ] Unmounted /run/user/1000. [ OK ] Unmounted /var/log.hdd. [FAILED] Failed unmounting /var/log. [ OK ] Reached target Unmount All Filesystems. [ OK ] Stopped target Local File Systems (Pre). [ OK ] Stopped Remount Root and Kernel File Systems. [ OK ] Stopped Create Static Device Nodes in /dev. [ OK ] Started Unattended Upgrades Shutdown. [ OK ] Reached target Shutdown. [ 82.195445] reboot: Power down INFO: PSCI Affinity Map: INFO: AffInst: Level 0, MPID 0x0, State ON INFO: AffInst: Level 0, MPID 0x1, State ON INFO: AffInst: Level 0, MPID 0x2, State ON INFO: AffInst: Level 0, MPID 0x3, State ON ERROR: PSCI system shutdown: still alive ... And this is where it stops but the message is strange to me. Just reporting it FYI. OOOOoooops!! As I was typing this message and left the board at its current setting (turned off supposedly), it sudenly rebooted by its own and reached 132 degrees!! I had the tty already connected and this is the remaining output U-Boot SPL 2017.01-rc1-g5df570f-dirty (Jan 27 2017 - 13:53:59) DRAM: 1024 MiB Trying to boot from MMC1NOTICE: BL3-1: Running on H5 (1718) in SRAM A2 (@0x44000) NOTICE: Configuring SPC Controller NOTICE: BL3-1: v1.0(debug):cd7fa48 NOTICE: BL3-1: Built : 13:53:22, Jan 27 2017 NOTICE: PLL_CPUX: 90001410 INFO: BL3-1: Initializing runtime services INFO: BL3-1: Preparing for EL3 exit to normal world INFO: BL3-1: Next image address: 0x4a000000, SPSR: 0x3c9 U-Boot 2017.01-rc1-g5df570f-dirty (Jan 27 2017 - 13:57:55 +0200) Allwinner Technology CPU: Allwinner H5 (SUN50I) Model: OrangePi PC 2 DRAM: 1 GiB MMC: SUNXI SD/MMC: 0 *** Warning - bad CRC, using default environment HDMI connected: Setting up a 1920x1080 hdmi console (overscan 0x0) hdmi enabled In: serial Out: vga Err: vga Net: phy interface7 eth0: ethernet@1c30000 Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... Found U-Boot script /boot/boot.scr 1768 bytes read in 176 ms (9.8 KiB/s) ## Executing script at 4fc00000 Boot script loaded from mmc 91 bytes read in 148 ms (0 Bytes/s) 24310 bytes read in 263 ms (89.8 KiB/s) 4222403 bytes read in 437 ms (9.2 MiB/s) 11261960 bytes read in 659 ms (16.3 MiB/s) ## Loading init Ramdisk from Legacy Image at 4fe00000 ... Image Name: uInitrd Image Type: AArch64 Linux RAMDisk Image (gzip compressed) Data Size: 4222339 Bytes = 4 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 4fa00000 Booting using the fdt blob at 0x4fa00000 Loading Ramdisk to 49bf9000, end 49fffd83 ... OK Loading Device Tree to 0000000049bf0000, end 0000000049bf8ef5 ... OK Starting kernel ... Loading, please wait... starting version 229 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 [ 2.403476] thermal thermal_zone0: critical temperature reached(132 C),shutting down done. Begin: Will now check root file system ... fsck from util-linux 2.27.1 [/sbin/fsck.ext4 (1) -- /dev/mmcblk0p1] fsck.ext4 -a -C0 /dev/mmcblk0p1 /dev/mmcblk0p1: clean, 184517/954720 files, 1211259/3811232 blocks done. done. Begin: Running /scripts/local-bottom ... done. Begin: Running /scripts/init-bottom ... done. [ 2.751503] thermal thermal_zone0: critical temperature reached(132 C),shutting down [ 2.939899] reboot: Power down INFO: PSCI Affinity Map: INFO: AffInst: Level 0, MPID 0x0, State ON INFO: AffInst: Level 0, MPID 0x1, State ON INFO: AffInst: Level 0, MPID 0x2, State ON INFO: AffInst: Level 0, MPID 0x3, State ON ERROR: PSCI system shutdown: still alive ... At that stage I unplugged the power.. hope this info helps

Got a bit of a weird issue and the search in Armbian site is not helping much due to words with few characters.. Have a Opi+2E running Armbian Ubuntu 16.04.1 xenial desktop and an ethernet connection. (Packet tracking is via wireshark) Whenever an ARP network request comes to it (targeted at its MAC addr) for revealing its IP, it does not reply back. Is there any hint or info on such an issue? Solved. It was just me not rebooting when needed.. Sorry for the noise.

Ok, it boots now.

@zador.blood.stained Although this board is of no use to me, it might be to others so as soon as I see aditional commits on it I'll give it another try, just to give you some feedback. p.s. Added some board photos just in case you need some resistor inspection