Jump to content

Armbian 20.02 (Chiru) Release Thread

lanefu

By lanefu
in Armbian build framework

 Share

Recommended Posts

lanefu

lanefu

Posted
Posted (edited)

Release Candidate Code Freeze Date: 2020-01-25

Release Date: 2020-02-??  (will update thread)

Current Release Candidate Branch Link: v20.02-rc1

Release Changelog: (will update)

Release Coordinator: @lanefu
Testing Tracking Sheet: https://bit.ly/2TGaeZN  (google sheets)

 

The goal of this thread is to discuss testing, bugfixes, and the overall quality of the release.  Once the release is complete, this thread should be locked and unpinned.  Our Hotfix process for completed releases is TBD.

 

First of all I'm sorry I'm kicking this off so late.  I should have started a few weeks ago.  I'll continue to update this post with more information.  I will also update release process documentation as we progress.

 

I am going to go ahead and cut a release branch to learn and further document the process, but the official release branch won't be cut until the Release Candidate Code Freeze Date.

 

Tagging a few devs here from memory.. please tag others....  @Igor @gprovost @martinayotte @chwe @TonyMac32 @count-doku @balbes150 @Tido

 

 

Edited by lanefu
rc branch link, tracking sheet, v20.02-rc1
1
Link to comment
Share on other sites
lanefu

lanefu

Posted
  • Author
Posted (edited)

Incomplete Tasks Targeted For Release

 

AR-42 Merge packaging patches Moved to 20.05

AR-45 Make first login more user friendly Moved to 20.05

AR-50 Optimise armbian-config dependencies Moved to 20.05
AR-128 Adding support for Pinebook PRO  <--  Is there anything in git repo for this.. i know its in a WIP state at least

AR-87 Network manager randomizing wireless adaptor MAC Move out. Not sure if this is bug at all.

AR-151 Integrate @JMCC 's multimedia script .    moved to 20.05

AR-152 Display issues with Bionic Mesa update  critical bug

 

 

 

Edited by lanefu
Adjust, again, mesabug, mesa-workaround, mediascript delayed
Link to comment
Share on other sites
lanefu

lanefu

Posted
  • Author
Posted
2 hours ago, TonyMac32 said:

As I understand it RK3328 needs some love, as does Tinker.  I'll be poking at that tonight to get specifics.

 

Cool.. let me know what you find or link me to something and I'll be glad to key it into Jira

Link to comment
Share on other sites
Heisath

Heisath

Posted
Posted

Looks good, I like the definitive freeze / release dates. 

 

I will do remaining work (mostly testing recent mvebu changes on Helios4) today.

 

Another dev: @aprayoga

 

EDIT:

Not worth the extra post, I completed testing on Helios4 and Clearfog looks good:

mvebu-legacy
    Helios4 lk 4.14.y u-boot 2018.11-armbian
   http://ix.io/27Ou

 

    Clearfog (Pro) lk 4.14.y u-boot 2018.01-armbian
    * SFP working but only up to 1Gbps    
   http://ix.io/27OL

 

mvebu-current
    Helios4 lk 4.19.y u-boot 2019.04-armbian
   http://ix.io/27Ox  

 

    Clearfog (Pro) lk 4.19.y u-boot 2018.01-armbian
    * SFP working but only up to 1Gbps
   http://ix.io/27OM

1
Link to comment
Share on other sites
Igor

Igor

Posted
Posted

My two cents.

 

- once we made a fork from a master branch, version must be adjusted accordingly (also on master)

- master remains the place for new contribution and we merge them into 

- when we are satisfied with the state of the build, RCx -> .1

- hot-fix releases. For now IMO, using master branch and just going up with the number. Unless we have resources which will stay behind and tinkle old releases, send fix to master, merge back, bump version and tell me what to build

 

I do plan to create a Jenkins server for this one day, that you will be able to push things up without me in the loop.

1
Link to comment
Share on other sites
lanefu

lanefu

Posted
  • Author
Posted
3 hours ago, ning said:

I notice the rc brach is created, @Igor@lanefu could you clarify the merge policy?

 

Oh, just above..:D

 

I've added some more detail here on merge policy and release process.  Keep an eye on it. I'll be updating it as we go through this process https://github.com/armbian/documentation/blob/master/docs/Process_Release-Model.md#release-coordinating

 

and to clarify.. I have cut an rc0 branch, but it's just to test the process.   rc1 will be the first official rc branch and will happen on our freeze date.

 

1
Link to comment
Share on other sites
Igor

Igor

Posted
Posted
13 hours ago, lanefu said:

but it's just to test the process.


Almost done. Last images are uploading ... few minutes to go.

 

First problem / question - regarding deleting RC images when new one arrives. Currently they are just being added and we will have them all in the archive and on torrents, each time I re-run the batch.

Link to comment
Share on other sites
TonyMac32

TonyMac32

Posted
Posted

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

 

No sound

No USB3                                                                      Fixed with upstream pending patches

No USB-OTG on Renegade                                           Brought patch from Dev to Current

only 1.3 GHz despite having high opp patch

...Probably not an exhaustive list. 

 

[edit] On apt update/upgrade the desktop fails, I get the wallpaper/mouse but no menu/etc.  Will have to check later.

Link to comment
Share on other sites
Heisath

Heisath

Posted
Posted

Hi,

 

I updated the gdoc sheet from lanefu for mvebu.

 

Regarding the notes:

  • Kernel 4.14 (legacy)
  • Kernel 4.19 (current)
  • Kernel 5.4 (dev) 

all work stable on mvebu (Helios & Clearfog). U-Boot 2019 is still a bit problematic on Clearfog with dev, will try to fix that until 20.05 otherwise just use U-Boot 2018 there aswell.

 

Debian Stretch was not tested, as it is marked as unsupported on the download page ( https://www.armbian.com/clearfog/ ) . Maybe that was a typo and should have been Debian Buster @lanefu?

 

Cheers,

count-doku

 

Link to comment
Share on other sites
Igor

Igor

Posted
Posted
2 hours ago, count-doku said:

Debian Stretch was not tested, as it is marked as unsupported on the download page


We shell focus on Buster / Bionic, the rest as is, user land functions are less important ...

We have to build up the way how to attract/build/promote community supported testings. Its quite time consuming task to test all this without any automated tooling. After we manage to secure some functionality and before we will try to fix bugs which will be found. I am sure people are eager to help, if they would know about.

Link to comment
Share on other sites
TRS-80

TRS-80

Posted
Posted
5 minutes ago, Igor said:

We have to build up the way how to attract/build/promote community supported testings. Its quite time consuming task to test all this without any automated tooling. After we manage to secure some functionality and before we will try to fix bugs which will be found. I am sure people are eager to help, if they would know about.

 

+1

 

I have been aware of the release activity, but I keep asking myself "what can I do to help" or "what does testing entail?" just to give you perspective from more normal end user, not dev like you guys.

 

And I am only aware of this now since I am more involved on forums and IRC. Many others also would be willing I think, but are unaware, as you correctly state.

 

In other words, yes, absolutely spot on with this assessment. :thumbup:

 

How to solve that? I have no idea, as I don't even know what is involved. But I think maybe Igor is starting to see the growing community as a resource maybe instead of a burden? Which IMO is the better way to look at it. Look how quickly for instance the Mod and IRC situations became solved once help was asked for.

 

What would be involved writing some sort of automated testing tooling to be distributed? I suspect long term the effort might be worth it? But again I have no idea what's really involved.

Link to comment
Share on other sites
chwe

chwe

Posted
Posted
On 1/19/2020 at 2:27 AM, lanefu said:

Release Candidate Code Freeze Date: 2020-01-25

let's see if we get the pinebook pro with mainline and the orange pi 4 in a working state til then..  Still struggle with display (some of the available DTs for mainline are wrong regarding to regulators so my display gets likely not powered, sound polutes debug UART and so on)..

 

Maybe we send the display then as a bugfix. :rolleyes::lol: I mean a non working display for a notebook is a bug, a working one isn't a feature right?.. :lol:

Link to comment
Share on other sites
lanefu

lanefu

Posted
  • Author
Posted
13 minutes ago, chwe said:

let's see if we get the pinebook pro with mainline and the orange pi 4 in a working state til then..  Still struggle with display (some of the available DTs for mainline are wrong regarding to regulators so my display gets likely not powered, sound polutes debug UART and so on)..

 

Maybe we send the display then as a bugfix. :rolleyes::lol: I mean a non working display for a notebook is a bug, a working one isn't a feature right?.. :lol:


I'm sure everyone would love to have a brand new headless laptop.

 

Fortunately having a regular release cycle lets us not have to cram things into a release.   People can know its coming for the next release, and use a nightly in the meantime if they really want something
 

Link to comment
Share on other sites
chwe

chwe

Posted
Posted

well I still hope I can sort this mess out till then.. :D:lol: there are a bunch of device trees flying around with a wrong regulater claimed to be on PMIC but in fact triggered by a gpio. The reason this works is likely that u-boot did the lifting before and the kernel couldn't mess it cause it's simply doesn't do something else..

 

 

Link to comment
Share on other sites
Igor

Igor

Posted
Posted
29 minutes ago, chwe said:

let's see if we get the pinebook pro with mainline and the orange pi 4 in a working state til then.. 


I also trying to get somewhere. How far did you get?

Link to comment
Share on other sites
chwe

chwe

Posted
Posted

kernel boots, the charger driver and display settings were added (obviously display doesn't work yet), dmesg looks quite smooth (don't have it anymore - my notebook is on low diskspace the whole time so I've to throw out non fully working images). The DT taken for this was from manjaro. Sound was disabled cause it polutes debug UART for whatever reason. So this guy should boot:

kernel-rockchip64-current (copy).patch

 

but it's not a proper device tree, especially this node here: 

+	vcc3v3_s0: vcc3v3-s0-regulator {
+		compatible = "regulator-fixed";
+		enable-active-high;
+		gpio = <&gpio1 RK_PC6 GPIO_ACTIVE_HIGH>;
+		pinctrl-names = "default";
+		regulator-name = "vcc3v3_s0";
+		regulator-always-on;
+	};

needs some love..  we've the same node with a different name too (this one is present in the manjaro DT the other one was added by myself and taken out of PMIC cause it has nothing to do with REG2 in PMIC, that's not how things are wired according to schematics): 

+	vcc_lcd_en: vcc-lcd-en-regulator {
+		compatible = "regulator-fixed";
+		enable-active-high;
+		gpio = <&gpio1 RK_PC6 GPIO_ACTIVE_HIGH>;
+//		pinctrl-names = "default";
+//		pinctrl-0 = <&vcc_lcd_en_drv>;
+		regulator-name = "vcc_lcd_en";
+		regulator-enable-ramp-delay = <100000>;
+		vin-supply = <&vcc3v3_sys>;
+		regulator-always-on;
+
+		regulator-state-mem {
+			regulator-off-in-suspend;
+		};
+	};

so in PMIC this node was killed: 

+			unused: SWITCH_REG2 {
+				regulator-name = "SWITCH_REG2";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};

maybe just diff the two DT files (ours and the one from manjaro: https://gitlab.manjaro.org/tsys/linux-pinebook-pro/blob/master/arch/arm64/boot/dts/rockchip/rk3399-pinebook-pro.dts) to get a clue.

 

And sound was disabled yet: 

+	es8316-sound {
+		status = "disabled";
+		compatible = "simple-audio-card";
+		simple-audio-card,name = "rockchip,es8316-codec";
+		simple-audio-card,format = "i2s";
+		simple-audio-card,mclk-fs = <256>;
+
+		simple-audio-card,widgets =
+			"Microphone", "Mic Jack",
+			"Headphone", "Headphones",
+			"Speaker", "Speaker";
+		simple-audio-card,routing =
+			"MIC1", "Mic Jack",
+			"Headphones", "HPOL",
+			"Headphones", "HPOR",
+			"Speaker Amplifier INL", "HPOL",
+			"Speaker Amplifier INR", "HPOR",
+			"Speaker", "Speaker Amplifier OUTL",
+			"Speaker", "Speaker Amplifier OUTR";
+
+		simple-audio-card,hp-det-gpio = <&gpio0 RK_PB0 GPIO_ACTIVE_HIGH>;
+		simple-audio-card,aux-devs = <&speaker_amp>;
+
+		simple-audio-card,cpu {
+			sound-dai = <&i2s1>;
+		};
+
+		simple-audio-card,codec {
+			sound-dai = <&es8316>;
+		};
+	};

I simply don't care about sound yet, but working debug UART is a must atm.

Link to comment
Share on other sites
piter75

piter75

Posted
Posted
2 hours ago, Igor said:

all of them are at least booting 20.02-RC images

Did I spot an Orange Pi 4 booting with 20.02-RC in the middle of the pic? ;-)

I did get it to boot with M4V2's current image from SD without issues but did not have enough time to create a proper board definition yet.

Link to comment
Share on other sites
Igor

Igor

Posted
Posted
10 minutes ago, piter75 said:

Did I spot an Orange Pi 4 booting with 20.02-RC in the middle of the pic? ;-)


Yes, but its just Android which is booting off at that time. But its on the table ... :) @chwe I meant Orangepi 4 :) Don't have Pinebook PRO. Yet.

Link to comment
Share on other sites
Guest
This topic is now closed to further replies.
 Share
Go to topic listing
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines

  I accept