Armbian for OrangePi PC2, AllWinner H5

[zador.blood.stained]

17 minutes ago, rusatch said:

Build for last 2 hours with mainline kernel(thanks for add this option).

It's not ready yet and it won't be any better than the dev branch for a while.

[martinayotte]

3 hours ago, rusatch said:

** File not found /boot/Image **

In the mean time, you can copy cache/sources/linux-sun50i-dev/linux-4.13.y/arch/arm64/boot/Image into /boot/ of your SD (or inside the image itself)

 

[rusatch]

4 minutes ago, martinayotte said:

In the mean time, you can copy cache/sources/linux-sun50i-dev/linux-4.13.y/arch/arm64/boot/Image into /boot/ of your SD (or inside the image itself)

There is zImage file available. I think there is some scenario that must boot compresed image, but this scenario doesn't work.

[zador.blood.stained]

25 minutes ago, rusatch said:

There is zImage file available. I think there is some scenario that must boot compresed image, but this scenario doesn't work.

It's just a wrong file name defined in the packaging patch. zImage (symlink) can be renamed to Image.

[martinayotte]

12 minutes ago, zador.blood.stained said:

zImage (symlink) can be renamed to Image

But 64bits U-boot want the uncompressed version, so that why I used the Image from build tree.

 

[zador.blood.stained]

7 minutes ago, martinayotte said:

But 64bits U-boot want the uncompressed version, so that why I used the Image from build tree.

There is no zImage anyway, and vmlinux-... file should be uncompressed

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/tree/arch/arm64/boot/Makefile

https://github.com/armbian/build/blob/master/patch/kernel/sun50i-dev/set-default-target-to-Image.patch

[martinayotte]

But our packaging script is still taking the Image.gz and copy it as /boot/vmlinuz-4.13.2-sun50iw2 instead of /boot/Image-4.13.2-sun50iw2

[zador.blood.stained]

10 minutes ago, martinayotte said:

But our packaging script is still taking the Image.gz and copy it as /boot/vmlinuz-4.13.2-sun50iw2 instead of /boot/Image-4.13.2-sun50iw2

I'll try to fiddle with/fix this soon, maybe tomorrow.

[martinayotte]

Not worries, since I'm using the workaround ...

[rusatch]

Just for testing I build 2 images: with dev kernel and with next kernel.

Both images booted without crashes, but system with dev kernel booted without wifi, only lo interface, next kernel get wlan0 interface but without 802.11n, only abg.

Is there some hack to get 802.11n?

Thanks a lot.

[John Brooks]

I built the mainline 'next' branch today (not dev) using the compile.sh UI option and targeting the OPIZP2-H5 board.

 

It built and booted up fine using serial tty, though there were 2-3 boot log errors. The CPU was running at 768MHz and did not seem to scale with CPU load or thermals. With a heat sink attached to the H5, I was able to change the clock speed to 1200MHz via CCU reg 0 and it appeared to stick (ie, not altered by linux). Performance was about 33% faster at 1200MHZ compared to 768MHZ.

 

FWIW, all 4 cores share one clock, so no per-core speed control on the H5.

 

Wifi is working now on the Zero-H5. The missing items I noticed today compared to 4.11 were no HDMI console, and no /dev/sda* for mounting USB flash drives.

 

It looks like the HDMI console is handled differently in the new uboot & kernel 4.13 (ie, no framebuffer@x device, but rather an HDMI device).

 

Thanks for the rapid improvements on kernel 4.13. Impressive work.

 

-JB

@JBrooksBSI

[John Brooks]

On 9/13/2017 at 9:36 AM, jernej said:

There is none. I started to write something about it here: http://linux-sunxi.org/DE2_Register_Guide Not much, but it is a start. Most informations can be found here: https://github.com/jernejsk/linux/blob/master/drivers/video/sunxi/disp2/disp/de/lowlevel_sun8iw7/de_rtmx_type.h

U-Boot has already DE2 & HDMI driver, while Linux has DE2 driver for V3s only. Basic DE2 driver & full HDMI driver for A64/H3/H5 are already prepared and a matter of mainlining.

 

Thanks for the links jernej. Looking at the lowlevel BSP src files, the DE system sure has a lot of registers and functionality. With a footprint of 4 megs, it consumes more address space than any other H5 subsystem.

 

It looks like the H5 support for 4.11 expects a simple framebuffer passed in from uboot, but it looks like the new uboot is passing an HDMI device entry to 4.13 instead of a framebuffer? It makes sense to have Linux create it's own framebuffer when HDMI is detected/activated instead of being a one-time event at boot.

 

-JB

@JBrookSBSI

[jernej]

On 19. 9. 2017 at 6:47 AM, John Brooks said:

but it looks like the new uboot is passing an HDMI device entry to 4.13 instead of a framebuffer?

I'm not sure what you mean. Can you give me a link? If you mean HDMI DT nodes, which are not present in mainline kernel, just Armbian, then it is probably from experimental H3 HDMI Linux driver, which needs some fixes to work on H5. At some it will be fixed, if it is not already.

 

On 19. 9. 2017 at 6:47 AM, John Brooks said:

It makes sense to have Linux create it's own framebuffer when HDMI is detected/activated instead of being a one-time event at boot.

SimpleFB could only be one time event, by design. For dinamic behaviour you need proper DRM driver.

[mousavy_mh]

I am trying to compile& install some driver on this image, but it seems that's impossible to install the kernel headers. 
How do I install kernel header files?
Thanks in advance

[martinayotte]

When doing your own build, the build process will generate something like output/debs/linux-headers-next-sunxi64_5.33_arm64.deb.

Copy that file on the target board and install it using "dpkg -i output/debs/linux-headers-next-sunxi64_5.33_arm64.deb".

 

[Igor]

9 hours ago, mousavy_mh said:

I am trying to compile& install some driver on this image, but it seems that's impossible to install the kernel headers. 
How do I install kernel header files?

If you ran the latest beta: armbian-config -> software -> install headers

https://github.com/armbian/documentation/blob/master/docs/images/armbian-config-6.png

[OrangePiPc2]

Hello,

 

I would like to build a Debian stretch image for this board, which is required for freedombone.

 

I suppose it isn't as easy as editing "xenial" to "stretch" in this file

So I would like to have some advice on how to go about doing this.

 

Thank you and appreciate all the work!

 

       

 

 

 

[Igor]

5 hours ago, OrangePiPc2 said:

So I would like to have some advice on how to go about doing this.

Stretch is possible, but kernel for this board is not quite ready. We are working round the clock to finish this in planned due in 1-2 months.

 

Current status: 

HDMI DRM driver, CEC, HDMI audio, I2S (requires overlays)

Missing features: DVFS, THS U-boot is most likely broken

[pec]

Yesterday I built latest next version for opc2 from source (git rev 1674eb7), kernel version 4.13.5.

It boots fine and in general it seems to work, but when I tried to compile latest tvheadend from source, then gcc fails with internal error:

[ 20%] Building CXX object encoder/CMakeFiles/encoder.dir/entropy.cpp.o
/root/build/tvh/tvheadend/build.linux/ffmpeg/x265_2.4/source/encoder/entropy.cpp: In function ‘void x265::Entropy::codeCoeffNxN(const x265::CUData&, const coeff_t*, uint32_t, uint32_t, x265::TextType)’:
/root/build/tvh/tvheadend/build.linux/ffmpeg/x265_2.4/source/encoder/entropy.cpp:2186:1: internal compiler error: Segmentation fault
 }
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See <file:///usr/share/doc/gcc-5/README.Bugs> for instructions.
The bug is not reproducible, so it is likely a hardware or OS problem.
encoder/CMakeFiles/encoder.dir/build.make:326: recipe for target 'encoder/CMakeFiles/encoder.dir/entropy.cpp.o' failed

When I a disable compiling x265 encoder then there will be next codec that fails with internal compiler error  and so on.

 

But OTOH when building tvheadend on older armbian build (4.11.6-sun50iw2 #5 SMP Sat Jun 24 14:34:21 EEST), then I don't have such problems.

 

gcc version was 5.4.1 in both cases, also I tried gcc 7.2 and 4.9.4, same issue with latest armbian version.

[Yuan]

6 hours ago, pec said:

Yesterday I built latest next version for opc2 from source (git rev 1674eb7), kernel version 4.13.5.

It boots fine and in general it seems to work, but when I tried to compile latest tvheadend from source, then gcc fails with internal error:

[ 20%] Building CXX object encoder/CMakeFiles/encoder.dir/entropy.cpp.o
/root/build/tvh/tvheadend/build.linux/ffmpeg/x265_2.4/source/encoder/entropy.cpp: In function ‘void x265::Entropy::codeCoeffNxN(const x265::CUData&, const coeff_t*, uint32_t, uint32_t, x265::TextType)’:
/root/build/tvh/tvheadend/build.linux/ffmpeg/x265_2.4/source/encoder/entropy.cpp:2186:1: internal compiler error: Segmentation fault
 }
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See <file:///usr/share/doc/gcc-5/README.Bugs> for instructions.
The bug is not reproducible, so it is likely a hardware or OS problem.
encoder/CMakeFiles/encoder.dir/build.make:326: recipe for target 'encoder/CMakeFiles/encoder.dir/entropy.cpp.o' failed

When I a disable compiling x265 encoder then there will be next codec that fails with internal compiler error  and so on.

 

But OTOH when building tvheadend on older armbian build (4.11.6-sun50iw2 #5 SMP Sat Jun 24 14:34:21 EEST), then I don't have such problems.

 

gcc version was 5.4.1 in both cases, also I tried gcc 7.2 and 4.9.4, same issue with latest armbian version.

Starting from kernel version 4.12 I got compiler errors like yours too. You may try a 4.11 build. 

[Menion]

Do you have any swap file active? Compiling optimized cpp files requires a lot of memory and you can easily run out of memory in aarch64 even with 1Gb of memory.

With the swap file you may avoid the segmentation fault, but it is not a solution because the system will slow down till being unusable, if you use USB storage.

 

[pec]

I had 400MB+ for swap. 

[Menion]

Ok

As workaround you may try to compile in chroot+qemu environment using the same distribution image you are running on target (after having extended the file system of course) or with a clone of your currently working SD image

[pec]

My main concern is that maybe this issue affects something else beside compilation, at the moment I decided to stick to 4.11 as it works without issues.

[Larry Bank]

Has anyone tried the latest nightly for the OPZ+2 H5? It works fine when connected via TTY, but HDMI turns off right after the "loading kernel" message. It also doesn't enable any of the USB ports, but Wifi works fine

 

The OrangePi PC 2 version runs better on the OPZ+2 H5. It has video out, usb works, but the wifi is not working.

 

[zador.blood.stained]

1 hour ago, Larry Bank said:

HDMI turns off right after the "loading kernel" message

Video driver wasn't activated on all boards yet

 

1 hour ago, Larry Bank said:

It also doesn't enable any of the USB ports

All ports that are not soldered by default will be disabled by default, can be enabled with DT overlays

 

1 hour ago, Larry Bank said:

but the wifi is not working.

PC2 doesn't have any onboard wireless, so logs (i.e. armbianmonitor -u) are necessary to see if driver or firmware are missing.

[martinayotte]

59 minutes ago, zador.blood.stained said:

PC2 doesn't have any onboard wireless

... therefore, some entries in DT that are present in OPZ+2 H5 are not present in OPiPC2 ...

 

[Larry Bank]

1 hour ago, zador.blood.stained said:

Video driver wasn't activated on all boards yet

 

All ports that are not soldered by default will be disabled by default, can be enabled with DT overlays

 

PC2 doesn't have any onboard wireless, so logs (i.e. armbianmonitor -u) are necessary to see if driver or firmware are missing.

I tried activating USB with DT overlays - still didn't work.

When I run the OP PC2 build  on the OPZ+2H5, USB and video works, so why the difference between the 2 builds?

How do I activate the video driver?

 

[Igor]

1 hour ago, Larry Bank said:

How do I activate the video driver?

https://github.com/armbian/build/blob/master/patch/kernel/sunxi-next/17-1-enable-hdmi-video-on-several-boards.patch

[hojnikb]

Any chance frequency tables get bumped to 1.3Ghz, as it was before ? Mine only goes to 1.15G