8 8
lanefu

Armbian 20.02 (Chiru) Release Thread

Recommended Posts

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/

Share this post


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

Share this post


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

Share this post


Link to post
Share on other sites

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!

Share this post


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

Share this post


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

Share this post


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

Share this post


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

Share this post


Link to post
Share on other sites

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

Share this post


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

Share this post


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

Share this post


Link to post
Share on other sites

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

Share this post


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

Share this post


Link to post
Share on other sites

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

Share this post


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

Share this post


Link to post
Share on other sites

As mentioned - previous kernel works correctly on orangepiPC2.

 

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

Share this post


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

Share this post


Link to post
Share on other sites
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...  :ph34r::lol:  Works now, but PulseAudio isn't piping audio until I change outputs back and forth a few times... (Bionic)

Share this post


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

Share this post


Link to post
Share on other sites
  ___  ____  _   _____ 
 / _ \|  _ \(_) |___ / 
| | | | |_) | |   |_ \ 
| |_| |  __/| |  ___) |
 \___/|_|   |_| |____/ 
                       
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.

Share this post


Link to post
Share on other sites

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

 

Share this post


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

Share this post


Link to post
Share on other sites

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.

Share this post


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

Share this post


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

Share this post


Link to post
Share on other sites
3 hours ago, stut said:

Guess Ubuntu has this disabled and Debian enabled?

Correct.

Compare ...

/etc/NetworkManager/NetworkManager.conf

... in debian and ubutu.

Share this post


Link to post
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
Reply to this topic...

×   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...
8 8