Armbian 20.02 (Chiru) Release Thread

[piter75]

2 hours ago, martinayotte said:

@piter75 , Is your OPi4 boot fine with CURRENT ?

This is my OPi4 booting current: http://ix.io/28fb

Did legacy boot for you?

 

We have different boards (mine is B model) but I hoped we could have a single board definition for both of them.

 

You can find schematic in the "user manual" folder of a specific board on orangepi website: http://www.orangepi.org/downloadresources/

[Igor]

On 1/25/2020 at 3:44 AM, lanefu said:

can you kick off a build for rc1 and let us know when the images are posted?   Once they are available I'll post an announcement to invite the community to test

Images done. Process finished without troubles this time.

[martinayotte]

16 hours ago, piter75 said:

We have different boards (mine is B model) but I hoped we could have a single board definition for both of them.

I think this is the issue : my board hasn't any Rev. letter, it only has written v1.3.

Since I was trying earlier only home made builds, I've now decided to try both Armbian_20.02.0-rc1_Orangepi4_buster_current_5.4.14_desktop.img and Armbian_20.02.0-rc1_Orangepi4_buster_legacy_4.4.210.img from Armbian downloads section. The former is also not reaching login prompt, and the later is producing a git/long crash.

 

I've then downloaded Xunlong's OrangePi_4_debian_stretch_desktop_linux4.4.179_v1.2.img, although facing several crashes, it reached the login prompt, but eMMC produced I/O errors, so unusable.

WiFi is also producing errors, but this maybe because it hasn't the proper AP6256 firmware version ...

 

@Igor, I think we need to figure out with Xunlong's Steven what are the differences between Rev.B and Non-Rev.B, and also asking him to provide us schematics of both boards.

 

Conclusion : For now, my OPi4 Non-Rev will be shelved ...

[stut]

RC1 working very nicely on NanoPi NEO2 boards here. Also running cooler than I remember, hovering between 22-27c idle/light load. Everything I need works including 8811au ac sticks and overlays to enable 1.3ghz and extra usb port on the oled add-on, the oled also works. Wifi seems faster/more responsive. No issues to report so far. Great work!

[TonyMac32]

RC1 working very nicely on NanoPi NEO2 boards here. Also running cooler than I remember, hovering between 22-27c idle/light load. Everything I need works including 8811au ac sticks and overlays to enable 1.3ghz and extra usb port on the oled add-on, the oled also works. Wifi seems faster/more responsive. No issues to report so far. Great work!

Do you have a thermometer to double-check the reported values? I remember these Allwinner parts have some very touchy temp sensors (voltage dependence, etc)

Sent from my Pixel using Tapatalk

[stut]

49 minutes ago, TonyMac32 said:

Do you have a thermometer to double-check the reported values? I remember these Allwinner parts have some very touchy temp sensors (voltage dependence, etc)

Sent from my Pixel using Tapatalk
 

 

I do have one of those gun like ones, thanks for reminding me. I checked some temps and the reported temps are pretty much spot on. It might run cooler without the 1.3ghz overlay cuz I think that increases the voltage, not sure though. Of course I can't measure the chip itself due to the heatsink but I did my best to get a close as possible and find the hottest parts. I do have a temp sensor for a multimeter somewhere that is probably small enough to sit between the heatsink and the dye of the chip but it will reduce the surface so might influence results a bit.

 

Edit: ran sbc-bench without errors: http://ix.io/28pz

[Igor]

2 hours ago, martinayotte said:

I think we need to figure out with Xunlong's Steven what are the differences between Rev.B and Non-Rev.B, and also asking him to provide us schematics of both boards.

 

They are on holidays ... but files are here: https://drive.google.com/open?id=1QMU5n-7fCx28cQPH_lu2L0wrFWeC3G45

[martinayotte]

16 minutes ago, Igor said:

but files are here

Thanks ! I didn't know about this location ...

[balbes150]

On 1/21/2020 at 8:33 AM, TonyMac32 said:

RK3328 Current is all the mess I could have hoped for, and then some.

 

No sound

On which 3328 models do you check the sound ?

[TonyMac32]

Renegade w/5.4, thank you for reminding me to look at that.

Sent from my Pixel using Tapatalk

[balbes150]

2 minutes ago, TonyMac32 said:

Renegade w/5.4, thank you for reminding me to look at that.

Maybe you should try 5.5 ? I have it on TV box rk3328 (DDR4 and DDR3) everything works (sound, WiFi).

[TonyMac32]

I can do that, this topic was covering the current release, where we'll be using 5.4. For next release I agree to look at 5.5 specifically, especially as it is now released.

Sent from my Pixel using Tapatalk

[balbes150]

6 minutes ago, TonyMac32 said:

I can do that, this topic was covering the current release, where we'll be using 5.4. For next release I agree to look at 5.5 specifically, especially as it is now released.

Now I tried the old image with the 5.4 kernel, the sound works.

[balbes150]

1 hour ago, TonyMac32 said:

where we'll be using 5.4.

I checked the official image 20.02 from Renegade to TV box (starting from a USB flash drive, with a small addition of the necessary scripts), with the official kernel image 20.02 and dtb from 5.4 (for MVR9), the sound works. The official core has everything you need for audio on rk3328.

[TonyMac32]

I'm at my day job, so let me make sure I'm clear, I made the observation that it didn't work when I started cleaning up the mainline kernel switch. I never went back to mess with it, so it's entirely possible it just works with very minor adjustment, or even was fixed in the meantime.

I'd entirely forgotten it. ;-)

Sent from my Pixel using Tapatalk

[balbes150]

10 minutes ago, TonyMac32 said:

I'm at my day job, so let me make sure I'm clear, I made the observation that it didn't work when I started cleaning up the mainline kernel switch. I never went back to mess with it, so it's entirely possible it just works with very minor adjustment, or even was fixed in the meantime.

I'd entirely forgotten it. ;-)

With the correct DTB, the sound works in the official images for rk3328 (I tried the official images for Renegade and Rock64). All it took was adding the correct DTB (with audio support). If use a DTB from roc-cc, there is no sound.

 

You can see how the sound was added to DTS here.

 

https://github.com/150balbes/Amlogic_s905-kernel/blob/5.4/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts

 

https://github.com/150balbes/Amlogic_s905-kernel/blob/5.5/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts

[Chris Rupnik]

Posted in the spreadsheet - but also wanted to list there. On the OrangePiPC2 - usb (rtl8192cu) WIFI adapters no longer are able to connect. This same hardware works correctly with the previous release without issue. 

 

It fails whether i use armbian-config via command line or using the network manager gui to set the wifi configuration.

 

output.rtf

[Igor]

1 hour ago, Chris Rupnik said:

usb (rtl8192cu) WIFI adapters no longer are able to connect

 

Thank you for informing us, will be noted. I am not sure we will be able to fix this in a time frame we have for a next release. In a mean time you can use a kernel 4.19.y images which should work without issues.

 

Those drivers are mainly maintained upstream. https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/MAINTAINERS?h=v5.4.15 or by 3rd party.

[Chris Rupnik]

As mentioned - previous kernel works correctly on orangepiPC2.

 

Note that on the orangepilite - the rtl8189fs works correctly with this release 5.4.14

[Igor]

24 minutes ago, Chris Rupnik said:

As mentioned - previous kernel works correctly on orangepiPC2.

Note that on the orangepilite - the rtl8189fs works correctly with this release 5.4.14

 

Thank you, but answer is still the same. This problem is outside our power to fix. Armbian has zero employees which can't cover work of 1000+ people that works on the Linux kernel. They created this problem and they will fix it.

[martinayotte]

For my OPi4 Non-Rev issue :

 

 

[TonyMac32]

On 1/28/2020 at 1:01 PM, balbes150 said:

You can see how the sound was added to DTS here.

 

 

This looks very much like what I did, I'll have to dig a bit deeper since it didn't work for me.  I applied the dtsi and dts patches as proposed for the sound pipeline on mainline, I'll just have to dig around and see what else is different. 

 

@balbes150 I forgot to enable i2s0 and 1...    Works now, but PulseAudio isn't piping audio until I change outputs back and forth a few times... (Bionic)

[balbes150]

12 hours ago, TonyMac32 said:

This looks very much like what I did, I'll have to dig a bit deeper since it didn't work for me.  I applied the dtsi and dts patches as proposed for the sound pipeline on mainline, I'll just have to dig around and see what else is different. 

 

@balbes150 I forgot to enable i2s0 and 1...    Works now, but PulseAudio isn't piping audio until I change outputs back and forth a few times... (Bionic)

Just for checking, to try to understand the reason, you can try the image from the TV boxes on your rk3328 ?

[jcaron]

  ___  ____  _   _____ 
 / _ \|  _ \(_) |___ / 
| | | | |_) | |   |_ \ 
| |_| |  __/| |  ___) |
 \___/|_|   |_| |____/ 
                       
Welcome to Armbian buster with Linux 5.5.0-sunxi64

Thanks all for the great job!

 

Still having issues with Panfrost/T720 though, I'll post in the Orange Pi 3 thread about that.

[stut]

I was having issues connecting to certain APs, the password was always wrong even though I knew for sure they were right. In the end it was due to network-manager's random mac address trickery. After disabling it I could connect just fine. Maybe the random mac should be turned off by default as it can interfere with certain APs?

 

A quick fix, create /etc/NetworkManager/conf.d/99-disable-wifi-random-mac.conf and add the following;

[connection]
wifi.mac-address-randomization=1

[device]
wifi.scan-rand-mac-address=no

 

[lanefu]

6 hours ago, stut said:

I was having issues connecting to certain APs, the password was always wrong even though I knew for sure they were right. In the end it was due to network-manager's random mac address trickery. After disabling it I could connect just fine. Maybe the random mac should be turned off by default as it can interfere with certain APs?

 

Was that with debian buster or ubuntu bionic? 

[Igor]

BTW. I tried to build two Buster images with 5.4.17 today - Orangepiwin and Orangepiplus2-h3 and both are without wireless  

 

It seems some troubles with the driver ... will try to debug in the evening.

[stut]

14 hours ago, lanefu said:

 

Was that with debian buster or ubuntu bionic? 

Sorry, it was buster yes. Not sure since when it’s been like this. Only happens with certain APs. I think they don’t like the client mac charging after a probe or something. Happened on an OpenWrt router and an Apple Airport router. Running standard firmware, nothing exotic or anything. There’s some other report about network-monitor doing this that messes up connecting to APs. He argues it may mess up the card not the AP. 

 

But I would like to argue that is not wanted behaviour under any circumstance unless you connect to a public wifi. Network-manager connects with a different mac address every time. It will also mess any mac filtering you may have setup or you may get. new ip every single time you reboot/reconnect. Apparently this function has been added somewhere in 2017 and from time time pops back up. Guess Ubuntu has this disabled and Debian enabled?

[Igor]

9 hours ago, Igor said:

BTW. I tried to build two Buster images with 5.4.17 today - Orangepiwin and Orangepiplus2-h3 and both are without wireless  

 

It seems some troubles with the driver ... will try to debug in the evening.

False alarm. Everything is alright.

[karabek]

3 hours ago, stut said:

Guess Ubuntu has this disabled and Debian enabled?

Correct.

Compare ...

/etc/NetworkManager/NetworkManager.conf

... in debian and ubutu.