Jump to content

Recommended Posts

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
Posted

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

 

Just to be clear on the freeze date, is it bugfix only after 1-25, or total freeze?

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
Posted
  On 1/19/2020 at 1:31 AM, TonyMac32 said:

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

Expand  

 

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

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

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.

Posted
  On 1/19/2020 at 1:15 PM, ning said:

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

 

Oh, just above..:D

Expand  

 

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.

 

Posted
  On 1/19/2020 at 4:53 PM, lanefu said:

but it's just to test the process.

Expand  


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.

Posted

Bug found. Not all images were made. Possible cause is running out of memory due too too many images building at once.

Posted

Rockchip Current appears to be stable.  TBD is the runtime overlay support, but I think that is secondary *looks over at RK3328*

Posted

Missing images uploaded ... ready for phase II. Testing. Testing. Testing. And trying to fix what we can.

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.

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

 

Posted
  On 1/21/2020 at 7:13 AM, count-doku said:

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

Expand  


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.

Posted
  On 1/21/2020 at 9:42 AM, 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.

Expand  

 

+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.

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

Release Candidate Code Freeze Date: 2020-01-25

Expand  

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:

Posted
  On 1/21/2020 at 6:19 PM, 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:

Expand  


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
 

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

 

 

Posted
  On 1/21/2020 at 6:19 PM, chwe said:

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

Expand  


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

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).patchFetching info...

 

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.

Posted
  On 1/21/2020 at 5:39 PM, Igor said:

all of them are at least booting 20.02-RC images

Expand  

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.

Posted
  On 1/21/2020 at 8:03 PM, piter75 said:

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

Expand  


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.

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines