Armbian for OrangePi PC2, AllWinner H5
32 32

433 posts in this topic

Recommended Posts

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)

 

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

32 32

  • Support the project

    We need your help to stay focused on the project.

    Choose the amount and currency you would like to donate in below.