arm/arm-64 ipipe release

arm/arm-64 ipipe release

[Greg Gallagher]

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

Greg

Re: arm/arm-64 ipipe release

[Florian Bezdeka]

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
> 

Re: arm/arm-64 ipipe release

[Greg Gallagher]

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

Re: arm/arm-64 ipipe release

[Greg Gallagher]

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?

thanks

Greg

Re: arm/arm-64 ipipe release

[Jan Kiszka]

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

Re: arm/arm-64 ipipe release

[Greg Gallagher]

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.

Thanks

Greg

Re: arm/arm-64 ipipe release

[Jan Kiszka]

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.

Jan

-- 
Siemens AG, Technology
Competence Center Embedded Linux

Re: arm/arm-64 ipipe release

[Florian Bezdeka]

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?

I will let you know when the test results are visible.

[1] https://lava.xenomai.org/scheduler/alljobs

Best regards,
Florian

> 
> Jan
> 

Re: arm/arm-64 ipipe release

[Jan Kiszka]

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

> 
> I will let you know when the test results are visible.
> 
> [1] https://lava.xenomai.org/scheduler/alljobs
> 
> Best regards,
> Florian
> 
>>
>> Jan
>>
> 

-- 
Siemens AG, Technology
Competence Center Embedded Linux

Re: arm/arm-64 ipipe release

[Florian Bezdeka]

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. 

Greg, do you have such a board at hand?

Best regards,
Florian

[2] https://lava.xenomai.org/scheduler/job/8381
[3] https://lava.xenomai.org/scheduler/job/8376

> 
> > 
> > I will let you know when the test results are visible.
> > 
> > [1] https://lava.xenomai.org/scheduler/alljobs
> > 
> > Best regards,
> > Florian
> > 
> > > 
> > > Jan
> > > 
> > 
> 

Re: arm/arm-64 ipipe release

[Jan Kiszka]

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?

Jan

-- 
Siemens AG, Technology
Competence Center Embedded Linux

Re: arm/arm-64 ipipe release

[Florian Bezdeka]

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
> 

Re: arm/arm-64 ipipe release

[Greg Gallagher]

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

Re: arm/arm-64 ipipe release

[Greg Gallagher]

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

Re: arm/arm-64 ipipe release

[Florian Bezdeka]

On Thu, 2023-03-16 at 16:11 -0400, Greg Gallagher wrote:
> 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.

Thanks for the update! Our CI confirmed the same thing, arm OK, arm64
boot failure.

Still debugging means that you can reproduce? That would actually be
perfect because I don't have the board at hand and would need to
remote-debug it...

Florian
> 
> -Greg

Re: arm/arm-64 ipipe release

[Greg Gallagher]

On Thu, Mar 16, 2023 at 4:52 PM Florian Bezdeka
<florian.bezdeka@siemens.com> wrote:
>
> On Thu, 2023-03-16 at 16:11 -0400, Greg Gallagher wrote:
> > 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.
>
> Thanks for the update! Our CI confirmed the same thing, arm OK, arm64
> boot failure.
>
> Still debugging means that you can reproduce? That would actually be
> perfect because I don't have the board at hand and would need to
> remote-debug it...
>
> Florian
> >
> > -Greg
>

Hi Florian,
   Can you confirm what hikey board it is.  I think the uart driver is
the arm,pl011.  I do have a board here with it, I'm trying to
reproduce tonight and over the weekend.

-Greg

Re: arm/arm-64 ipipe release

[Florian Bezdeka]

On 16.03.23 21:56, Greg Gallagher wrote:
> On Thu, Mar 16, 2023 at 4:52 PM Florian Bezdeka
> <florian.bezdeka@siemens.com> wrote:
>>
>> On Thu, 2023-03-16 at 16:11 -0400, Greg Gallagher wrote:
>>> 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.
>>
>> Thanks for the update! Our CI confirmed the same thing, arm OK, arm64
>> boot failure.
>>
>> Still debugging means that you can reproduce? That would actually be
>> perfect because I don't have the board at hand and would need to
>> remote-debug it...
>>
>> Florian
>>>
>>> -Greg
>>
> 
> Hi Florian,
>    Can you confirm what hikey board it is.  I think the uart driver is
> the arm,pl011.  I do have a board here with it, I'm trying to
> reproduce tonight and over the weekend.

According to our machine config / used device tree[1] we have a 
Hikey 6220 in our lab.

[1] https://source.denx.de/Xenomai/xenomai-images/-/blob/master/conf/machine/hikey.conf#L20

> 
> -Greg