Armbian running on Pine64 (and other A64/H5 devices)

[tkaiser]

@TKaiser, 5 cents is pretty low estimate, I would rather say 20 cents, even 30 cents if we wish 128Mbits

Well, @ssvb spotted those modules on Aliexpress for 4 Cents and all that's needed are 16 Mb. We want a boot loader with HDMI, USB and network support that can either help the clueless get their board up an running since help texts can be displayed or that simply allows to boot from everywhere.

 

This is already possible with u-boot for older Allwinner SoCs, the only annoying step is that you always have to burn an SD card first. With such a basic boot loader on board (be it SPI flash or inside eMMC boot partition on more expensive boards) by default the problem is solved.

 

This will help first time users as well as professional users since this also eases deployment a lot: attach power and network cable and you're up and running (PXE boot and rootfs on NFS). Or attach power cable and USB stick with your universal Armbian installation and continue to work on an entirety different device. Or as a professional user let the SPI flash be overwritten at first boot with your very own code you need on the device.

 

And @nz1 is absolutely right. First time users insert the exFAT formatted SD card in their PC, then copy the compressed OS image they downloaded on it and will fail to boot (check pine64 forums, a few of those users even manage to find the forum and complain, the majority sends their SBC to the bin or asks for a refund since DOA). To get the idea:

 

- http://linux-sunxi.org/Bootable_SPI_flash

- http://linux-sunxi.org/Bootable_eMMC (it's not about writing a crappy Android to eMMC, it's about using the eMMC boot partitions in the same way as SPI NOR flash)

[tkaiser]

To get the idea of how easy it is to be distracted from the very few that make a lot of noise and forget the many thousands that are happy and quiet..

For you to get the idea why you won't receive any more comments from me: I'll remain quiet from now on since it's a waste of time.

 

We're talking here not about the hobbyists point of view but professional use cases. If I want to roll out a few hundred OPi Zero a pre-populated SPI NOR flash with u-boot able to boot from network makes a huge difference regarding TCO!

 

Is it really that hard to understand why a device specific boot loader that's

 

a) already there

can boot from everywhere (SD card, USB stick, USB disk, SATA on A10/A20/R40 devices, network)

c) can boot device agnostic (universal!) OS images

d) while assisting the inexperienced

 

is simply a great idea? As long as the vendor's increase in costs is marginal and doesn't hurt.

[pfeerick]

That's yet another thing that's nice about the Orange Pi PC 2... they've managed to bring out a ~US $20 board and still managed to spring for a 16MB SPI FLASH. I can see the downsides of having SPI on board though... I mean, I just know that if tkaiser had his way and it had been on the pine64, instead of booting it would say 'You sucker... you went and bought a pine64 didn't you! Well, you deserve what you get... nothing!' and refuse to boot ;-P

 

Seriously though, to have the bootloader and a basic diagnostic system on board with every new board made would be the best thing for all, as tkaiser was pointing out. That was the same handy thing Dell did with all their machines - not only do you have the pretty blinking lights that via hardware give you POST diagnostics, but you could enter the on-board diagnostics and test all the hardware. It would be great if when you bought a new board you could plug it in, and without loading a SD card / flashing the eMMC, power the board up, hit ESC to skip the auto-boot sequence, type in 'diagnostics' or whatever, press enter, and then some basic diagnostics would be run - i.e. cpu stress test (hence also power supply test) memory, sd read / present, display test, etc. Then you'd know that everything was good to go. But that might be pushing the 16MB storage a bit, since you also want the boot-loader stuff? :-P I'll stop pipe-dreaming now... 

 

oh, btw, @Christos... I'm one of the (occasionally) noisy ones who has moved pass most of the problems I had and still makes noise... so you might want to rethink that theory!  

[Seasalt]

Is there a early beta available for Orange Pi PC2?

[tkaiser]

Strange. While Armbian provides extensive documentation and a beta image where everything should work out of the box since weeks... meanwhile in Pine64 land people waste time and struggle with our build system and other people even provide 'customized' Armbian images bundled with wrong instructions: http://forum.pine64.org/showthread.php?tid=1183&pid=22923#pid22923

 

Seems the out of control moderator (Marcus H...) did a really great job constantly deleting every post mentioning Armbian

 

@pfeerick: wouldn't it be a good idea to make users over there aware of https://docs.armbian.com/board_details/pine64/ ?

[pfeerick]

And why? Do really think I should break the excellent example set forward by our illustrious leader Lord Marcus? Who is an expert at everything (even when he isn't?)... 

 

And I had to shudder at the mention of Win32DiskImager... really great choice there! 

 

Well, the documentation is getting better... the software released page now actually mentions the existence of Armbian... but I am now fighting the battle of direct links to images, rather than the appropriate project/download pages. 

[tkaiser]

I am now fighting the battle of direct links to images, rather than the appropriate project/download pages.

http://wiki.pine64.org/index.php/Pine_A64_Software_Release#Armbian_Linux_Image

 

How moronic is that? A wiki linking to static OS images instead of our download/info page? So every time we update the OS image (and that's EVERY NIGHT at the moment) it's ensured that Pine64 users only get access to more outdated stuff. Those guys responsible for this wiki still try very hard to provide most shitty user experience ever for Pain64 users. Unbelievable.

[tkaiser]

Small update on Pine64 running with mainline kernel: https://github.com/igorpecovnik/lib/issues/546#issuecomment-264862192

 

@apritzel was so kind to provide a nice tool to poke memory values on some Allwinner boards (so anyone with an OPi PC 2 in his hands could start to determine perfect tx-delay/rx-delay values to max out Gigabit Ethernet on this board). My results with 2/0 and 3/0 combination on Pine64 were rather good given that I only slightly overclock A64 with 864 MHz (with mainline kernel we still have no PMIC support and therefore also no cpufreq and dvfs scaling so by default A64 will be clocked with just 480 MHz -- when using Armbian's build system we clock A64 with 816 MHz since this is a sane value given that VDD_CPUX without active PMIC support is set to 1.1V).

 

In other words: Looks promising to already do server tasks with mainline kernel. With Armbian CPU cores clock at the upper maximum already, USB2 throughput is impressive high with UASP capable disk enclosures and Gigabit Ethernet performance is also almost perfect (900/940 Mbits/sec). 

[Velociraptor]

Hi!

so any news on the pine front? I would like to use it as an surf/email desktop but my problem is the display ... 1080p and i have na 1680*1050 -> 16:10 aspection... any idea how I could work around this ?

[zador.blood.stained]

so any news on the pine front? I would like to use it as an surf/email desktop but my problem is the display ... 1080p and i have na 1680*1050 -> 16:10 aspection... any idea how I could work around this ?

Nobody works on the legacy kernel, so only predefined resolutions are supported there (and don't think anything will change there), and there is no display support in mainline yet (in addition to other critical bits missing).

[arne]

How about other A64 boards? I own a BPI-M64 (and only found out later about the terrible support of SinoVoip...). What are the steps needed for a noob like me to get the Pine64 Armbian image running on an M64? Never mind about hdmi, emmc, wifi or whatever, just the bare basics would be great already. Just something that utilizes the capabilities of the chipset a bit more than the official images. Thanks for the amazing work you all are doing!

[tkaiser]

What are the steps needed for a noob like me to get the Pine64 Armbian image running on an M64?

 

Simply burn the Armbian image of choice with Etcher to an SD card and boot BPi M64 with it. Then hardware like Wi-Fi or eMMC still won't work (with none of the SinoVoip images either since those morons simply used Pine64+ device tree) but at least you have an ARMv8 user land (the morons only provide rootfs for ARMv7 or even ARMv6 to ensure BPi M64 is the slowest A64 device around).

 

To get eMMC working I would assume some DT bits are missing. Same for WiFi (according to Jon Smirl they did not follow Allwinner's reference design here) and there you would need an appropriate Ampak driver (brcmfmac -- no idea whether this driver is already contained in Pine64 legacy kernel sources).

[@lex]

Here is my take on the eMMC, unfortunately with partial success if not a complete fail.

 

I have managed to boot with rootfs on SD card and able to see the eMMC , but if i try to format it i get errors. I can DD to the eMMC.

If the DT is correct there is a bit more than that.

 

Anyway if someone want to take over this or fix what is wrong, here is the changes to DTS:

        sdmmc@01C11000 {
            compatible = "allwinner,sun50i-sdmmc2";
            device_type = "sdc2";
            reg = <0x00000000 0x01c11000 0x00000000 0x00001000>;
            interrupts = <0x00000000 0x0000003e 0x00000104>;
            clocks = <0x00000006 0x0000005a 0x0000005b 0x0000005c 0x0000005d>;
            clock-names = "osc24m", "pll_periph", "mmc", "ahb", "rst";
            pinctrl-names = "default", "sleep";
            pinctrl-1 = <0x0000005f>;
            bus-width = <0x00000008>;
            max-frequency = <0x05f5e100>;
            sdc_tm4_sm0_freq0 = <0x00000000>;
            sdc_tm4_sm0_freq1 = <0x00000000>;
            sdc_tm4_sm1_freq0 = <0x00000000>;
            sdc_tm4_sm1_freq1 = <0x00000000>;
            sdc_tm4_sm2_freq0 = <0x00000000>;
            sdc_tm4_sm2_freq1 = <0x00000000>;
            sdc_tm4_sm3_freq0 = <0x05000000>;
            sdc_tm4_sm3_freq1 = <0x00000405>;
            sdc_tm4_sm4_freq0 = <0x00050000>;
            sdc_tm4_sm4_freq1 = <0x00000408>;
            /* status = "disabled";  */
            status = "okay";
            non-removable;
            pinctrl-0 = <0x000000b4>;
            cd-gpios;
            sunxi-power-save-mode;
            sunxi-dis-signal-vol-sw;
            mmc-ddr-1_8v;
            mmc-hs200-1_8v;
            mmc-hs400-1_8v;
            vmmc = "vcc-emmc";
            /* vqmmc = "vcc-emmcvq18"; */
            vqmmc = "vcc-emmcvq33";
            vdmmc = "none";
        };

ls -la /dev/mmcblk*

brw-rw---- 1 root disk 179,  0 Feb 11  2016 /dev/mmcblk0
brw-rw---- 1 root disk 179,  8 Dec 28 21:03 /dev/mmcblk0boot0
brw-rw---- 1 root disk 179, 16 Dec 28 21:03 /dev/mmcblk0boot1
brw-rw---- 1 root disk 179, 24 Feb 11  2016 /dev/mmcblk1
brw-rw---- 1 root disk 179, 25 Dec 28 21:03 /dev/mmcblk1p1
brw-rw---- 1 root disk 179, 26 Dec 28 21:03 /dev/mmcblk1p2

If i try to format the eMMC i get this errors:

[  102.401046] sunxi-mmc 1c11000.sdmmc: smc 0 p2 err, cmd 18, RD SBE !!
[  102.408065] sunxi-mmc 1c11000.sdmmc: data error, sending stop command
[  102.415252] mmcblk0: timed out sending r/w cmd command, card status 0x900
[  102.422933] mmcblk0: not retrying timeout
[  102.427385] blk_update_request: 11 callbacks suppressed
[  102.427391] end_request: I/O error, dev mmcblk0, sector 0
[  102.433454] Buffer I/O error on device mmcblk0, logical block 0
[  102.440960] sunxi-mmc 1c11000.sdmmc: smc 0 p2 err, cmd 18, RD SBE !!
[  102.448266] sunxi-mmc 1c11000.sdmmc: data error, sending stop command
[  102.458122] mmcblk0: timed out sending r/w cmd command, card status 0x900
[  102.468248] mmcblk0: not retrying timeout
[  102.475457] end_request: I/O error, dev mmcblk0, sector 0
[  102.482418] Buffer I/O error on device mmcblk0, logical block 0

[tkaiser]

Here is my take on the eMMC, unfortunately with partial success if not a complete fail.

 

Did you take this into account: https://github.com/apritzel/linux/commit/a8c3e0bef036c3a758e978064b49efaeab6a1de1 (see also commit before).

[Xalius]

Hello, just had to create an account here to say thank you Armbian :-)

 

I was absent for a couple month from most things Pine64 and came back to do some more work on my hardware projects. I then was looking at the state of the different Linux support options and was excited to see that Armbian has official support for the Pine. I am running now two of my boards on Xenial images, one with BSP the other with an updated sunxi kernel. Works like a charm, thank you very much.

 

That being said, it seems that Armbian is kind of underrepresented over at Pine64 which I think is a shame. I would like to create a new subforum in the Linux section or at least a thread to steer some more users this way, if there are no objections?

[tkaiser]

That being said, it seems that Armbian is kind of underrepresented over at Pine64 which I think is a shame. I would like to create a new subforum in the Linux section or at least a thread to steer some more users this way, if there are no objections?

 

Well, from a distro baker's point of view Pine64 is still an absolute support nightmare

 

Also the average Pine64 backer was mislead by the kickstarter campaign so the high expectations meet a few hardware flaws and people get frustrated since they don't get it that they need quality SD cards or that their crappy phone charger isn't able to reliably power these devices (especially with connected peripherals).

 

From my point of view it should suffice if Armbian is represented on Pine Inc's download pages (which seems to be the case now) and if the stubborn old man who constantly deleted/censored Armbian related information over there gets his moderator status removed since he mis-used it so many times.

[umiddelb]

1st of all I'd like to thank you very much for bringing together all the bits and pieces.

 

I've tried the mainline / Ubuntu edition for the Pine64 yesterday and I was happy to see a mainline kernel booting up which supports at least the lower USB port. Unfortunately some Docker related requirements are still missing so I tried to build the mainline kernel with a more extensive configuration. I've taken the kernel sources form Icenowy, according to the configuration settings, checked out the sunxi64-next-20170125 branch and applied the Armbian related kernel patches. Unfortunately the kernel built this way starts up with a warning and doesn't have USB support at all. What did I miss? Do you refer to a specific commit inside the branch? Are there additional patches to be applied?

 

Cheers

Uli

--

[    1.324812] ------------[ cut here ]------------
[    1.329469] WARNING: CPU: 1 PID: 89 at drivers/base/dd.c:349 driver_probe_device+0x260/0x2c8
[    1.337916] Modules linked in:

[    1.342480] CPU: 1 PID: 89 Comm: kworker/1:1 Not tainted 4.10.0-rc5-next-20170125-p64-g0caa26e-dirty #1
[    1.351880] Hardware name: Pine64+ (DT)
[    1.355725] Workqueue: events deferred_probe_work_func
[    1.360869] task: ffff80007c63cb00 task.stack: ffff80007c670000
[    1.366793] PC is at driver_probe_device+0x260/0x2c8
[    1.371762] LR is at driver_probe_device+0x60/0x2c8
[    1.376644] pc : [<ffff000008546108>] lr : [<ffff000008545f08>] pstate: 20000045
[    1.384048] sp : ffff80007c673c60
[    1.387367] x29: ffff80007c673c60 x28: 0000000000000000
[    1.392686] x27: ffff80007c4d7d20 x26: ffff80007c5ae1b8
[    1.398005] x25: ffff000008e28483 x24: 0000000000000001
[    1.403323] x23: ffff000008e542d0 x22: 0000000000000000
[    1.408642] x21: 0000000000000000 x20: ffff000008f30000
[    1.413960] x19: ffff80007c6a9810 x18: ffff80007c45bcf0
[    1.419279] x17: 00000000a3f21038 x16: 000000007c44e9fa
[    1.424597] x15: 0000000026778477 x14: 000000003f487d8b
[    1.429916] x13: 0000000000000002 x12: 0000000000000000
[    1.435234] x11: 0000000000000020 x10: 0101010101010101
[    1.440552] x9 : fffffffffffffffe x8 : 7f7f7f7f7f7f7f7f
[    1.445871] x7 : 0000000000000020 x6 : 0000000000000008
[    1.451189] x5 : ffff80007c6a99a0 x4 : 0000000000000000
[    1.456507] x3 : ffff80007c63cb00 x2 : ffff000008f300f8
[    1.461825] x1 : ffff80007c6a9a98 x0 : ffff80007a866280

[    1.468639] ---[ end trace 62bd292a1e0f16ee ]---
[    1.473260] Call trace:
[    1.475714] Exception stack(0xffff80007c673a90 to 0xffff80007c673bc0)
[    1.482159] 3a80:                                   ffff80007c6a9810 0001000000000000
[    1.490001] 3aa0: ffff80007c673c60 ffff000008546108 0000000000000001 fffffffffffffff8
[    1.497842] 3ac0: 00000000000004f9 00000000000004f9 00000000000004f9 00000000000004f9
[    1.505683] 3ae0: 0000000000000400 0000000000000400 0000000000000001 0000000000000001
[    1.513524] 3b00: 0000000000000000 ffff80007c420280 ffff80007c420400 000000000000091e
[    1.521366] 3b20: 0000000000001000 0000000000000247 ffff80007a866280 ffff80007c6a9a98
[    1.529207] 3b40: ffff000008f300f8 ffff80007c63cb00 0000000000000000 ffff80007c6a99a0
[    1.537048] 3b60: 0000000000000008 0000000000000020 7f7f7f7f7f7f7f7f fffffffffffffffe
[    1.544889] 3b80: 0101010101010101 0000000000000020 0000000000000000 0000000000000002
[    1.552730] 3ba0: 000000003f487d8b 0000000026778477 000000007c44e9fa 00000000a3f21038
[    1.560571] [<ffff000008546108>] driver_probe_device+0x260/0x2c8
[    1.566583] [<ffff0000085462bc>] __device_attach_driver+0x9c/0xf8
[    1.572684] [<ffff0000085442d0>] bus_for_each_drv+0x58/0x98
[    1.578262] [<ffff000008545d84>] __device_attach+0xc4/0x138
[    1.583839] [<ffff000008546368>] device_initial_probe+0x10/0x18
[    1.589763] [<ffff0000085452ec>] bus_probe_device+0x94/0xa0
[    1.595340] [<ffff000008545774>] deferred_probe_work_func+0x74/0xa8
[    1.601616] [<ffff0000080d5b48>] process_one_work+0x120/0x368
[    1.607367] [<ffff0000080d5fd4>] worker_thread+0x244/0x488
[    1.612859] [<ffff0000080dbbe8>] kthread+0xf0/0x120
[    1.617744] [<ffff000008082ec0>] ret_from_fork+0x10/0x50

[martinayotte]

That is strange !

 

With the build I did yesterday morning with sunxi64-next-20170125 branch, I was able to mount /dev/sda1 external drive and update its rootfs, and reboot with it as USB-Boot.

What kind of USB drive are you using ?

 

BTW be aware that some USB dongle such as "058f:6387 Alcor Micro Corp. Flash Drive" are failing in 64 bits SPL-USB-U-Boot, while some MicroSD reader such "14cd:121c Super Top microSD card reader" are working fine.

[umiddelb]

I'm booting the Pine64 without any device attached to the USB port. lsusb doesn't show the root hubs.

 

I've used the maintainer's defconfig as a base, since I'm unsure which one to take here. Do you still have the kernel sources you've checked out yesterday?

[tkaiser]

Why not utilizing the build system: https://docs.armbian.com/Developer-Guide_Build-Options/ (KERNEL_ONLY and KERNEL_CONFIGURE both set to yes and you end up with stuff for 'dpkg -i' in output/debs/ directory)

[umiddelb]

Obviously, I just cannot build the kernel on the Pine64 directly ...

root@p65:~/armbian# bash ./compile.sh
[ o.k. ] This script will try to update
Already up-to-date.
Already on 'master'
Your branch is up-to-date with 'origin/master'.
[ o.k. ] Preparing [ host ]
[ .... ] Please read documentation to set up proper compilation environment
[ .... ] http://www.armbian.com/using-armbian-tools/
[ error ] ERROR in function prepare_host [ general.sh:458 ]
[ error ] Running this tool on board itself is not supported
[ o.k. ] Process terminated

[martinayotte]

[ error ] Running this tool on board itself is not supported

You need to cross-compile on a PC equipped with Ubuntu-16.04, or inside a VirtualBox with the same Ubuntu.

[zador.blood.stained]

And BTW in latest nightlies all Docker related options should be enabled already - I used check-config script to update sun8i-dev and sun50i-dev kernel configs.

 

 

root@orangepipc2:~# wget https://raw.githubusercontent.com/docker/docker/master/contrib/check-config.sh
--2017-01-31 17:40:45--  https://raw.githubusercontent.com/docker/docker/master/contrib/check-config.sh
Resolving raw.githubusercontent.com (raw.githubusercontent.com)... 151.101.36.133
Connecting to raw.githubusercontent.com (raw.githubusercontent.com)|151.101.36.133|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 10257 (10K) [text/plain]
Saving to: ‘check-config.sh’

check-config.sh     100%[===================>]  10.02K  --.-KB/s    in 0.004s

2017-01-31 17:40:45 (2.54 MB/s) - ‘check-config.sh’ saved [10257/10257]

root@orangepipc2:~# bash check-config.sh
info: reading kernel config from /proc/config.gz ...

Generally Necessary:
- cgroup hierarchy: properly mounted [/sys/fs/cgroup]
- CONFIG_NAMESPACES: enabled
- CONFIG_NET_NS: enabled
- CONFIG_PID_NS: enabled
- CONFIG_IPC_NS: enabled
- CONFIG_UTS_NS: enabled
- CONFIG_CGROUPS: enabled
- CONFIG_CGROUP_CPUACCT: enabled
- CONFIG_CGROUP_DEVICE: enabled
- CONFIG_CGROUP_FREEZER: enabled
- CONFIG_CGROUP_SCHED: enabled
- CONFIG_CPUSETS: enabled
- CONFIG_MEMCG: enabled
- CONFIG_KEYS: enabled
- CONFIG_VETH: enabled (as module)
- CONFIG_BRIDGE: enabled (as module)
- CONFIG_BRIDGE_NETFILTER: enabled (as module)
- CONFIG_NF_NAT_IPV4: enabled (as module)
- CONFIG_IP_NF_FILTER: enabled (as module)
- CONFIG_IP_NF_TARGET_MASQUERADE: enabled (as module)
- CONFIG_NETFILTER_XT_MATCH_ADDRTYPE: enabled (as module)
- CONFIG_NETFILTER_XT_MATCH_CONNTRACK: enabled (as module)
- CONFIG_NETFILTER_XT_MATCH_IPVS: enabled (as module)
- CONFIG_IP_NF_NAT: enabled (as module)
- CONFIG_NF_NAT: enabled (as module)
- CONFIG_NF_NAT_NEEDED: enabled
- CONFIG_POSIX_MQUEUE: enabled

Optional Features:
- CONFIG_USER_NS: enabled
- CONFIG_SECCOMP: enabled
- CONFIG_CGROUP_PIDS: enabled
- CONFIG_MEMCG_SWAP: enabled
- CONFIG_MEMCG_SWAP_ENABLED: missing
    (cgroup swap accounting is currently not enabled, you can enable it by setting boot option "swapaccount=1")
- CONFIG_BLK_CGROUP: enabled
- CONFIG_BLK_DEV_THROTTLING: enabled
- CONFIG_IOSCHED_CFQ: enabled
- CONFIG_CFQ_GROUP_IOSCHED: enabled
- CONFIG_CGROUP_PERF: enabled
- CONFIG_CGROUP_HUGETLB: enabled
- CONFIG_NET_CLS_CGROUP: enabled (as module)
- CONFIG_CGROUP_NET_PRIO: enabled
- CONFIG_CFS_BANDWIDTH: enabled
- CONFIG_FAIR_GROUP_SCHED: enabled
- CONFIG_RT_GROUP_SCHED: enabled
- CONFIG_IP_VS: enabled (as module)
- CONFIG_IP_VS_NFCT: enabled
- CONFIG_IP_VS_RR: enabled (as module)
- CONFIG_EXT4_FS: enabled
- CONFIG_EXT4_FS_POSIX_ACL: enabled
- CONFIG_EXT4_FS_SECURITY: enabled
- Network Drivers:
  - "overlay":
    - CONFIG_VXLAN: enabled (as module)
      Optional (for encrypted networks):
      - CONFIG_CRYPTO: enabled
      - CONFIG_CRYPTO_AEAD: enabled
      - CONFIG_CRYPTO_GCM: enabled (as module)
      - CONFIG_CRYPTO_SEQIV: enabled
      - CONFIG_CRYPTO_GHASH: enabled (as module)
      - CONFIG_XFRM: enabled
      - CONFIG_XFRM_USER: enabled (as module)
      - CONFIG_XFRM_ALGO: enabled (as module)
      - CONFIG_INET_ESP: enabled (as module)
      - CONFIG_INET_XFRM_MODE_TRANSPORT: enabled (as module)
  - "ipvlan":
    - CONFIG_IPVLAN: enabled (as module)
  - "macvlan":
    - CONFIG_MACVLAN: enabled (as module)
    - CONFIG_DUMMY: enabled (as module)
  - "ftp,tftp client in container":
    - CONFIG_NF_NAT_FTP: enabled (as module)
    - CONFIG_NF_CONNTRACK_FTP: enabled (as module)
    - CONFIG_NF_NAT_TFTP: enabled (as module)
    - CONFIG_NF_CONNTRACK_TFTP: enabled (as module)
- Storage Drivers:
  - "aufs":
    - CONFIG_AUFS_FS: missing
  - "btrfs":
    - CONFIG_BTRFS_FS: enabled
    - CONFIG_BTRFS_FS_POSIX_ACL: enabled
  - "devicemapper":
    - CONFIG_BLK_DEV_DM: enabled (as module)
    - CONFIG_DM_THIN_PROVISIONING: enabled (as module)
  - "overlay":
    - CONFIG_OVERLAY_FS: enabled
  - "zfs":
    - /dev/zfs: missing
    - zfs command: missing
    - zpool command: missing

Limits:
- /proc/sys/kernel/keys/root_maxkeys: 1000000

root@orangepipc2:~#

 

 

[umiddelb]

@zador.blood.stained
 Thank you! Which defconfig did you take for the Orange Pie PC 2? IMHO the Pine64 kernel build still refers to the maintainers (Icenowy) defconfig.

B.t.w. what is the best way in incept a diverging kernel configuration into the build process automatically?

[zador.blood.stained]

Hm. Got SoPine64 with a baseboard. Both legacy boot0 and mainline SPL can't init the DRAM

 

 

U-Boot SPL 2017.01-rc1-g5df570f-dirty (Feb 02 2017 - 19:03:16)
DRAM: 0 MiB
### ERROR ### Please RESET the board ### 

 

 

 

 

HELLO! BOOT0 is starting!
boot0 commit : 045061a8bb2580cb3fa02e301f52a015040c158f

boot0 version : 4.0.0
set pll start
set pll end
rtc[0] value = 0x00000000
rtc[1] value = 0x00000000
rtc[2] value = 0x00000000
rtc[3] value = 0x00000000
rtc[4] value = 0x00000000
rtc[5] value = 0x00000000
DRAM driver version: V1.1
rsb_send_initseq: rsb clk 400Khz -> 3Mhz
PMU: AXP81X
ddr voltage = 1500 mv
DRAM Type = 3 (2:DDR2,3:DDR3,6:LPDDR2,7:LPDDR3)
DRAM clk = 672 MHz
DRAM zq value: 003b3bbb
DRAM error status 0
DRAM init error!
initializing SDRAM Fail. 

 

 

[zador.blood.stained]

Thank you! Which defconfig did you take for the Orange Pie PC 2? IMHO the Pine64 kernel build still refers to the maintainers (Icenowy) defconfig.

We had a config from Pine64-dev from somewhere, so it was used as a base.

 

B.t.w. what is the best way in incept a diverging kernel configuration into the build process automatically?

https://docs.armbian.com/Developer-Guide_User-Configurations/#user-provided-kernel-config

[tkaiser]

Hm. Got SoPine64 with a baseboard. Both legacy boot0 and mainline SPL can't init the DRAM

 

Did you try out boot0 for Pinebook (also using LPDDR3)?

[zador.blood.stained]

Did you try out boot0 for Pinebook (also using LPDDR3)?

 

 

HELLO! BOOT0 is starting!
boot0 commit : 0d2d693517354dd7caddf843073674a2643b3630

boot0 version : 4.0.0
set pll start
set pll end
rtc[0] value = 0x00000000
rtc[1] value = 0x00000000
rtc[2] value = 0x00000000
rtc[3] value = 0x00000000
rtc[4] value = 0x00000000
rtc[5] value = 0x00000000
DRAM driver version: V1.1
rsb_send_initseq: rsb clk 400Khz -> 3Mhz
PMU: AXP81X
ddr voltage = 1500 mv
DRAM Type = 3 (2:DDR2,3:DDR3,6:LPDDR2,7:LPDDR3)
DRAM clk = 552 MHz
DRAM zq value: 003b3bbb
DRAM DQS gate training error
DRAM init error!
initializing SDRAM Fail.

 

 

Google is silent about SKhynix H4CCNNNBLTAL it's H9CCNNNBLTAL

[tkaiser]

DRAM Type = 3 (2:DDR2,3:DDR3,6:LPDDR2,7:LPDDR3)

 

Shouldn't this be 7 instead?

[zador.blood.stained]

Shouldn't this be 7 instead?

No idea, boot0 is a blob anyway, and I'm not sure open-source SPL can be easily changed without having something that already works to dump the DRAM controller registers