Re: arm/arm-64 ipipe release

[Greg Gallagher <greg@embeddedgreg.com>]

On Mon, Mar 6, 2023 at 12:18 AM Greg Gallagher <greg@embeddedgreg.com> wrote:
>
> On Fri, Mar 3, 2023 at 12:50 PM Florian Bezdeka
> <florian.bezdeka@siemens.com> wrote:
> >
> > On Wed, 2023-03-01 at 13:08 +0100, Jan Kiszka wrote:
> > > On 01.03.23 12:19, Florian Bezdeka wrote:
> > > > On Tue, 2023-02-28 at 09:12 +0100, Jan Kiszka wrote:
> > > > > On 28.02.23 08:49, Florian Bezdeka wrote:
> > > > > > On Tue, 2023-02-28 at 06:48 +0100, Jan Kiszka wrote:
> > > > > > > On 28.02.23 06:18, Greg Gallagher wrote:
> > > > > > > > On Mon, Feb 20, 2023 at 1:42 AM Jan Kiszka <jan.kiszka@siemens.com> wrote:
> > > > > > > > >
> > > > > > > > > On 20.02.23 06:27, Greg Gallagher wrote:
> > > > > > > > > > On Sat, Feb 18, 2023 at 12:33 AM Greg Gallagher <greg@embeddedgreg.com> wrote:
> > > > > > > > > > >
> > > > > > > > > > > On Tue, Feb 14, 2023 at 11:56 AM Florian Bezdeka
> > > > > > > > > > > <florian.bezdeka@siemens.com> wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > Hi Greg!
> > > > > > > > > > > >
> > > > > > > > > > > > On Mon, 2023-02-13 at 23:01 -0500, Greg Gallagher wrote:
> > > > > > > > > > > > > Hi,
> > > > > > > > > > > > >    I'm almost ready to release the next arm and arm64 ipipe patch. I'm
> > > > > > > > > > > > > working on stable release 231 since it contains the patch that
> > > > > > > > > > > > > hopefully fixes the UART irq issue seen in CI.  If there's a problem
> > > > > > > > > > > > > with using 231 let me know.  Finishing my local test this week.
> > > > > > > > > > > >
> > > > > > > > > > > > Thanks for letting us know. If there is a chance that you publish a
> > > > > > > > > > > > public available -rc somewhere, it would be possible to tweak our CI a
> > > > > > > > > > > > bit and trigger a full test run in our lab.
> > > > > > > > > > > >
> > > > > > > > > > > > That should help us to identify any leftovers upfront.
> > > > > > > > > > > >
> > > > > > > > > > > > Best regards,
> > > > > > > > > > > > Florian
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > Thanks
> > > > > > > > > > > > >
> > > > > > > > > > > > > Greg
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > I'll get -rc releases out this weekend.  I'll post back once they are
> > > > > > > > > > > done and the -rc tags are pushed up.
> > > > > > > > > > >
> > > > > > > > > > > Thanks
> > > > > > > > > > >
> > > > > > > > > > > Greg
> > > > > > > > > >
> > > > > > > > > > Hi Florian,
> > > > > > > > > >    I have the rc releases ready to go.  I'm going to push them up to
> > > > > > > > > > the ipipe tree with the kernel update (5.4.231).  Does the CI system
> > > > > > > > > > pull the current ipipe release based on the tag?  Would pushing up the
> > > > > > > > > > new point release (5.4.231) break the current CI?
> > > > > > > > >
> > > > > > > > > We are pulling from the head of ipipe/4.19.y-cip and ipipe/5.4.y for
> > > > > > > > > ipipe-arm[64], see [1]. It just takes manual triggers so far as there
> > > > > > > > > are no ci files in our kernel trees (unlike the xenomai repo itself).
> > > > > > > > >
> > > > > > > > > Jan
> > > > > > > > >
> > > > > > > > > [1]
> > > > > > > > > https://source.denx.de/Xenomai/xenomai-images/-/blob/master/recipes-kernel/linux/linux-xenomai_latest.bb
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > Siemens AG, Technology
> > > > > > > > > Competence Center Embedded Linux
> > > > > > > > >
> > > > > > > >
> > > > > > > > I put the beta releases here:
> > > > > > > >
> > > > > > > > https://github.com/ggallagher31/ipipe-arm
> > > > > > > > https://github.com/ggallagher31/ipipe-arm64
> > > > > > > >
> > > > > > > > Branch names are the same as gitlab, once CI tests out the branches
> > > > > > > > where are the results located? I'll look to see what debugging is
> > > > > > > > needed.
> > > > > > >
> > > > > > > Anything speaking against pushing to the regular branches directly? No
> > > > > > > need to tag/bump revision yet, you can do that after CI passed. That's
> > > > > > > how I maintain the other repos/branches.
> > > > > >
> > > > > > I can tweek the CI a bit and trigger an internal run. The test runs
> > > > > > will be visible at [1] once build stage is complete and we enter the
> > > > > > test stage.
> > > > > >
> > > > > > Pushing to the regular branches - and a failing CI afterwards - means
> > > > > > that we already "released" or at least deployed something that is not
> > > > > > working. No?
> > > > >
> > > > > Released is what was tagged. I do local build tests for my branches
> > > > > before I push, but CI is doing the rest of the qualification. Then I
> > > > > bump the revision, add a tag, and push all that as release.
> > > > >
> > > > > Jan
> > > >
> > > > Update:
> > > >
> > > > I triggered our CI infrastructure to perform two different builds. One
> > > > with Debian 11 (gcc 10) and one with Debian 12 (gcc 12).
> > > >
> > > > The result of both runs is the same: We have one failing test job on
> > > > the Hikey board. 5.4 [2] does not show any UART output, 4.19 [3] is
> > > > fine.
> > >
> > > Do we have any early printk on? And does it only show that issue with
> > > I-pipe enabled? QEMU arm64 is fine, right?
> >
> > Nope, no early printk enabled. The qemu job is OK, so it seems board/hw
> > specific.
> >
> > >
> > > Jan
> > >
> >
> Let me see if I have a board here that has the same uart as the Hikey
> board, I'll see if I can reproduce locally.
>
> -Greg

Quick update, still debugging the ARM64 build, the arm side looks
okay.  I'll release the ARM stuff by the weekend and continue to look
into ARM64.

-Greg