initial porting of IPIPE x86_64 patches onto Linux stable 5.4.52

initial porting of IPIPE x86_64 patches onto Linux stable 5.4.52

[Meng, Fino]

Dear all, 

We ported IPIPE patch from 4.19.89-x86-9 to Linux stable 5.4.52,  temporarily uploaded to github for review: 

https://github.com/intel/linux-stable-xenomai/tree/review/5.4.52/stable/ipipe/xenomai-3.1

pls help to review and check mistakes.  I didn't build it yet, due to I am not confidence on make a perfect kernel config

plan of this week:
  Make a good kernel config, build, fix bugs and patch format.
  Check and pick some CIP branch' patches.

@Jan,  I didn't fully catch about the ARCH/NON ARCH separation discussed on last meeting,
What I should do about it? 

BR / Fino (孟祥夫)
Intel – IOTG Developer Enabling

Re: initial porting of IPIPE x86_64 patches onto Linux stable 5.4.52

[Jan Kiszka]

On 24.08.20 02:48, Meng, Fino wrote:
> Dear all, 
> 
> We ported IPIPE patch from 4.19.89-x86-9 to Linux stable 5.4.52,  temporarily uploaded to github for review: 
> 
> https://github.com/intel/linux-stable-xenomai/tree/review/5.4.52/stable/ipipe/xenomai-3.1
> 
> pls help to review and check mistakes.  I didn't build it yet, due to I am not confidence on make a perfect kernel config
> 
> plan of this week:
>   Make a good kernel config, build, fix bugs and patch format.
>   Check and pick some CIP branch' patches.
> 

Thanks a lot for your effort already!

> @Jan,  I didn't fully catch about the ARCH/NON ARCH separation discussed on last meeting,
> What I should do about it? 

All non-x86 I-pipe commit should be at the beginning of the queue so
that I can split them off into ipipe-noarch. On first glance, this
already seems to be the case.

Greg, with this baseline available, porting ARM/ARM64 to 5.4 should
become possible. Thought I would wait until we have basic confidence on
x86 into the generic pieces. Steven, same for powerpc.

For 5.<next-lts> (5.10 likely), the plan remains going for dovetail.
However, that may requires a xenomai-3.2, thus this can give us some
time for the existing 3.1 series, and also for converting to 64-bit time_t.

Thanks,
Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

Re: initial porting of IPIPE x86_64 patches onto Linux stable 5.4.52

[Greg Gallagher]

On Mon, Aug 24, 2020 at 2:09 AM Jan Kiszka <jan.kiszka@siemens.com> wrote:
>
> On 24.08.20 02:48, Meng, Fino wrote:
> > Dear all,
> >
> > We ported IPIPE patch from 4.19.89-x86-9 to Linux stable 5.4.52,  temporarily uploaded to github for review:
> >
> > https://github.com/intel/linux-stable-xenomai/tree/review/5.4.52/stable/ipipe/xenomai-3.1
> >
> > pls help to review and check mistakes.  I didn't build it yet, due to I am not confidence on make a perfect kernel config
> >
> > plan of this week:
> >   Make a good kernel config, build, fix bugs and patch format.
> >   Check and pick some CIP branch' patches.
> >
>
> Thanks a lot for your effort already!
>
> > @Jan,  I didn't fully catch about the ARCH/NON ARCH separation discussed on last meeting,
> > What I should do about it?
>
> All non-x86 I-pipe commit should be at the beginning of the queue so
> that I can split them off into ipipe-noarch. On first glance, this
> already seems to be the case.
>
> Greg, with this baseline available, porting ARM/ARM64 to 5.4 should
> become possible. Thought I would wait until we have basic confidence on
> x86 into the generic pieces. Steven, same for powerpc.
>

Sounds good, I have a new 4.19 patch ready for arm and arm64 that I'll
have out this week depending on my schedule.


> For 5.<next-lts> (5.10 likely), the plan remains going for dovetail.
> However, that may requires a xenomai-3.2, thus this can give us some
> time for the existing 3.1 series, and also for converting to 64-bit time_t.
>
> Thanks,
> Jan
>
> --
> Siemens AG, Corporate Technology, CT RDA IOT SES-DE
> Corporate Competence Center Embedded Linux

-Greg

Re: initial porting of IPIPE x86_64 patches onto Linux stable 5.4.52

[Steven Seeger]

> On Mon, Aug 24, 2020 at 2:09 AM Jan Kiszka <jan.kiszka@siemens.com> wrote:
> > Greg, with this baseline available, porting ARM/ARM64 to 5.4 should
> > become possible. Thought I would wait until we have basic confidence on
> > x86 into the generic pieces. Steven, same for powerpc.

I'm definitely interested in doing this for PPC e500 32-bit. I now have my hands on a 64-bit 
e500 based board (PPC 5020) but it's a loaner COTS board from an industry partner. I 
probably won't be able to do Xenomai on that without a funding source, because of my 
other obligations. But I am reasonably sure that moving to 5.4 for e500 32-bit is something 
my partners would support. I get emails occasionally for more modern kernels.

If this follows the old noarch pattern for the baseline stuff, then that should make it ideal 
for bringing the rest of it up to date.

Steven

Re: initial porting of IPIPE x86_64 patches onto Linux stable 5.4.52

[Lennart Sorensen]

On Mon, Aug 24, 2020 at 11:05:55AM -0400, Steven Seeger via Xenomai wrote:
> I'm definitely interested in doing this for PPC e500 32-bit. I now have my hands on a 64-bit 
> e500 based board (PPC 5020) but it's a loaner COTS board from an industry partner. I 
> probably won't be able to do Xenomai on that without a funding source, because of my 
> other obligations. But I am reasonably sure that moving to 5.4 for e500 32-bit is something 
> my partners would support. I get emails occasionally for more modern kernels.

A 5020 is an e5500, which is nothing like an e500.  The e500 is PowerpC
SPE, while the e5500 (and the e300, e500mc and e6500) are "real" PowerPC
instead with a somewhat different instruction set.

GCC 9 even dropped support for the PPC SPE, while PPC is fully supported.

The e500's existence offends me since it fragments the powerpc
architecture.  Yuck. :)

> If this follows the old noarch pattern for the baseline stuff, then that should make it ideal 
> for bringing the rest of it up to date.

-- 
Len Sorensen

Re: initial porting of IPIPE x86_64 patches onto Linux stable 5.4.52

[Steven Seeger]

On Tuesday, August 25, 2020 9:25:00 AM EDT Lennart Sorensen wrote:
> A 5020 is an e5500, which is nothing like an e500.  The e500 is PowerpC
> SPE, while the e5500 (and the e300, e500mc and e6500) are "real" PowerPC
> instead with a somewhat different instruction set.

Sorry e500 was a typo in that case.

> GCC 9 even dropped support for the PPC SPE, while PPC is fully supported.
> 

Yeah there are e500 boards being made for military, aerospace, and LEO (low earth orbit) 
uses. There is concern that gcc 9 dropped SPE support, but it's up to vendors to support 
maintenance of it.

> 
> The e500's existence offends me since it fragments the powerpc
> architecture.  Yuck. :)

Well I won't say anything good or bad about it, but it's the one I know the most since it's 
what I work with all the time. ;)

The worst thing I ever had to deal with was making changes to a 603 instruction set 
simulator to make it be a 601. The subtle differences between POWER and PowerPC ISAs 
were quite a pain to find at the time. This was years ago.

But yeah all my work (and tested support with xenomai) have been on a e500v2. (8548)

Steven