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.

Hi!

Fresh build with commit b084385fefa3e166dc4a007d5128e715cc9d2e2f stopping wlan interface. After manual actions like:

cp /lib/firmware/brcm/brcmfmac43430-sdio.bin /lib/firmware/brcm/brcmfmac43430-sdio.bin.bak
cp /lib/firmware/ap6212/fw_bcm43438a1.bin /lib/firmware/brcm/brcmfmac43430-sdio.bin
rmmod brcmfmac
modprobe brcmfmac

wifi works again.

Hi all

What is the kernel branch used for "dev" branch in sun50i targets?

3 minutes ago, Menion said:

What is the kernel branch used for "dev" branch in sun50i targets?

Icenowy's linux-4.13.y

For H5 targets using the "next" branch is recommended instead.

 

dwmac-sun8i is not present in either the branch?

Just now, Menion said:

dwmac-sun8i is not present in either the branch?

It is present and should be working on several H5 boards: NanoPi Neo2, OrangePi PC2 and OrangePi Prime. Other H5 boards most likely are missing relevant DT entries for the driver.

 

Also in next (that I understand it is mainline)?

Because, AFAIK, this has been removed due to unstable DT bindings for all the board

Just now, Menion said:

Also in next (that I understand it is mainline)?

Yes

 

Just now, Menion said:

Because, AFAIK, this has been removed due to unstable DT bindings for all the board

But we (and Icenowy in her branch) reverted that removal.

"Unstable bindings" doesn't mean that something isn't working or is unstable, it just means that DT maintainers are not happy with the way DT represents the hardware.

Today the 7th iteration of the attempt to resolve this was posted: https://groups.google.com/forum/#!topic/linux-sunxi/jxF_AIJP0VA

Ahhhh ok, son on mainline we have armbian enable patch

Thanks, yes I followed the thread, it was clear to me that the problem was more to let the maintainer agree on the DT bindings structure

Hi!

On orange pi zero plus 2 h5 armbianmonitor show that cpu temperature is over 35C, but radiator is too hot, i cant touch it more 5 second. I think that real temperature is over 70C and calculation need to correct.

1 minute ago, rusatch said:

On orange pi zero plus 2 h5 armbianmonitor show that cpu temperature is over 35C, but radiator is too hot, i cant touch it more 5 second. I think that real temperature is over 70C and calculation need to correct.

Which kernel version and branch?

1 hour ago, zador.blood.stained said:

Which kernel version and branch?

 cat /etc/armbian-release
# PLEASE DO NOT EDIT THIS FILE
BOARD=orangepizeroplus2-h5
BOARD_NAME="Orange Pi Zero Plus 2"
VERSION=5.33
LINUXFAMILY=sunxi64
BRANCH=next
ARCH=arm64
IMAGE_TYPE=user-built
BOARD_TYPE=conf
INITRD_ARCH=arm64
KERNEL_IMAGE_TYPE=Image
 

uname -r
4.13.8-sunxi64
 

Guys, thanks for update of image.

Verium miner

Before update:113 h/m

After update:141 h/m (not sure of exact number, but hash rate is raise is about  25%)

 

Throttle is working -  temp keeps about 66-68 degrees.

Output of armbianmonitor can be found here : http://znoxx.me/2017/10/20/na-frontie-orange-pi/

 

And yet another point. If one is using I2P on OpiPC2, probably, it will fail to run native big integer library, since it is not included in distribution.

I've build one - you can grab one here: https://static-bins.herokuapp.com/files/aarch64/libjbigi/libjbigi-linux-armv8-a.so.gz

 

Unpack the archive and copy .so file with name libjbigi.so to your I2P installation directory. After this restart I2P. Log should show, that Native Big Integer library is loaded from file.

I've build it as static for OrangePi PC2 , but it also should work on other H5 boards. However, I didn't have a chance to test it on other machines, even ones different from one where it was build. So if someone interested, welcome to try it.

Hello. On OPZ2-H5 with latest build of armbian (both next and dev branches)  lsusb return error -99. Dmesg show no errors. Do i need somehow manually enable USB or use overlay?

1 hour ago, Jarik65535 said:

Hello. On OPZ2-H5 with latest build of armbian (both next and dev branches)  lsusb return error -99. Dmesg show no errors. Do i need somehow manually enable USB or use overlay?

With overlay usb on OPZ2-H5 working fine.

On 3/27/2017 at 8:20 PM, zador.blood.stained said:

I wonder how many times the wheel can be reinvented... 

root@orangepiplus2e:~# fdtget /boot/dtb/sun8i-h3-orangepi-one.dtb /cpus/cpu@0 operating-points
1008000 1300000 816000 1100000 624000 1100000 480000 1100000 312000 1100000 240000 1100000 120000 1100000
root@orangepiplus2e:~# fdtput /boot/dtb/sun8i-h3-orangepi-one.dtb /cpus/cpu@0 operating-points 1008000 1300000 816000 1300000 624000 1100000 480000 1100000 312000 1100000 240000 1100000 120000 1100000
root@orangepiplus2e:~# fdtget /boot/dtb/sun8i-h3-orangepi-one.dtb /cpus/cpu@0 operating-points
1008000 1300000 816000 1300000 624000 1100000 480000 1100000 312000 1100000 240000 1100000 120000 1100000
root@orangepiplus2e:~#

 

 

im trying to add 1.3GHz operating point to the newest PC2 image using these commands but im getting this error 

 

root@orangepipc2:/boot/dtb/allwinner# fdtget /boot/dtb/allwinner/sun50i-h5-orangepi-pc2.dtb /cpus/cpu@0 operating-points
Error at 'operating-points': FDT_ERR_NOTFOUND

 

New DT uses a different format (operating-points-v2) that can't be easily edited with fdtget/fdtput, you need to use dtc to decompile, edit and recompile it.

Yeah, i figured as much. Well, maybe old entries could be used from previous builds, these seem to work on most boards back then.

Is it possible to change on the fly the MUSB from OTG<->HOST without having to do so in the dts?

1 hour ago, Menion said:

Is it possible to change on the fly the MUSB from OTG<->HOST without having to do so in the dts?

If it is in OTG mode (dr_mode = "otg") (and you loaded at least one gadget module) it will already switch from device to host mode on the fly by reading the OTG  ID pin. Alternatively it may be possible to load overlays via configfs to change the dr_mode property, but it wasn't tested so I'm not sure that the driver will respect those changes.

With original dtb, dr_mode='otg' I plugged an USB key but it doesn't get recognized. I changed the dr_mode='host', rebooted with the new dtb and then it worked fine. USB key is connected with a micro USB to USB A female cable, also named OTG cable, can this be the problem? 

2 minutes ago, Menion said:

With original dtb, dr_mode='otg' I plugged an USB key but it doesn't get recognized.

Did you load any gadget modules (i.e. g_serial)?

Mmmm I am afraid I don't know what this gadget module are. But I did nothing, so I guess no

But the usb gadgets, aren't ment to be used for having the SBC acting like a serial, mass storage, etc...?

My goal is just to use the OTG port in host mode

Switching between host and peripheral mode is done by the MUSB stack, and it won't be activated until you load a gadget module (even if you want to use OTG only in host mode). This applies at least to all Allwinner devices running the mainline kernel - A10, A20, A64, H3, H5, ...

Ahhhhh ok  Next time I will recompile the kernel I will enable one then

Just now, Menion said:

Ahhhhh ok  Next time I will recompile the kernel I will enable one then

They are already enabled in our kernel config.

Alternatively you could add a DT overlay to change dr_mode to "host" - then it should work without loading extra modules but without a possibility to switch to the peripheral mode on the fly.

Hello,

 

I noticed that there isnt any support for the Orange Pi Zero Plus (H5) and would ask if there is a reason for it. They are more of an original Orange Pi Zero with an H5 from an hardware perspective and dont come with onboard flash.

 

Have a good Day

 

Matthias

Edited November 6, 20178 yr by Nowak Matthias

Any prevision to have a stable release for Orange Pi Prime?

I'm actually waiting for a debian based armbian image instead of Ubuntu.

 

Someone who tried this unstable version on a pi prime can share the faced issues?

1 hour ago, _vn said:

Someone who tried this unstable version on a pi prime can share the faced issues?

Basic hardware features are operational - but all mainline kernels for H3/H5/A64 boards remain labeled testing (also after next major release) since things are not well tested, not fine-tuned (thermal protection) and there is nothing we can do to speed up. In the testing period we don't make all possible images, so you have to make your own (Debian Stretch) image or wait ...