Jump to content
  • 0

Armbian for OrangePi PC2, AllWinner H5


Christos
 Share

Question

Hi,

 

Are there any news on if Armbian will be on the new H5 64bit board?

Orange released an Android SDK and an Android image but I guess everyone is waiting for a decent 64bit Debian.

 

Since took the plunge and got into the H5 wagon ordering one, I looked at the released info and obviously there was nothing I could use myself..

So the question goes to the Armbian gurus, guys do you think that there could be an Armbian release for H5 this year?

 

Christos

 

Link to comment
Share on other sites

Recommended Posts

When discussing a problem make sure to provide full logs!

  • 0
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.

Link to comment
Share on other sites

  • 0
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

Link to comment
Share on other sites

  • 0

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.

Link to comment
Share on other sites

  • 0

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

Link to comment
Share on other sites

  • 0
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

Link to comment
Share on other sites

  • 0
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.

Link to comment
Share on other sites

  • 0
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

Link to comment
Share on other sites

  • 0
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

Link to comment
Share on other sites

  • 0

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.

Link to comment
Share on other sites

  • 0
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. 

Link to comment
Share on other sites

  • 0

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.

 

Link to comment
Share on other sites

  • 0

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.

 

Link to comment
Share on other sites

  • 0
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.

Link to comment
Share on other sites

  • 0
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?

 

Link to comment
Share on other sites

  • 0
8 minutes ago, hojnikb said:

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

As soon as anyone tests (on multiple devices, using cpuburn and xhpl) and publishes a new DVFS table I may add it to kernel sources. Until that you could write a DT overlay or patch the DT manually. I just copy-pasted a DVFS table from somewhere and I don't want to waste time tweaking it without a good reason.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Answer this question...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

×
×
  • Create New...