OpenBMC Linux 6.1

[Tao Ren]

On Wed, Feb 22, 2023 at 06:25:13AM +0000, Joel Stanley wrote:
> On Wed, 22 Feb 2023 at 06:11, Tao Ren <rentao.bupt at gmail.com> wrote:
> >
> > Hi Joel,
> >
> > Thanks for the update. Let me move some Meta/Facebook AST2500 and
> > AST2600 Network OpenBMCs to v6.1, and will share my findings later.
> 
> Thanks Tao, I appreciate it.

Just heads up I sanity tested dev-6.1 branch on 3 aspeed generations,
and everything looks normal. The 3 openbmc platforms are:
  - wedge100 (AST2400)
  - cmm (AST2500)
  - fbdarwin (AST2600, dts to be upstreamed)

> 
> > Besides, could you please share your long term kernel upgrade plan? For
> > example, are you planning to align with LTS kernel in the future? Or the
> > ultimate goal is to upgrade openbmc kernel whenever newer kernel is
> > released?
> 
> Somewhere in between those two.
> 
> If we were to wait 5 or so years between updates, then we remove the
> motivation for developers to upstream their code, and I imagine it
> would be a headache to hunt down regressions when making that big
> jump.
> 
> On the other hand, management has been trained to target the stable
> releases and somehow consider them to be better than others. I argue
> this isn't true, because the code is only as stable as the test and
> development resources that are put into it! That said, it's less work
> to merge in the stable tree every week or two and test that than it is
> to do a new rebase every three months.
> 
> The ultimate goal is to have all of our code upstream, and just use
> whatever kernel yocto has. We're pretty close for aspeed machines; at
> IBM we have some downstream hacks for misbehaving i2c devices, and
> some device trees for pre-production hardware that have minor
> differences to the production version. If we were to upstream the
> hacks for i2c devices (or stop using them) then we could ship upstream
> kernels.
> 
> Ultimately it would be best for the project if we used the latest
> kernel on master, and had a LTS kernel that was used by product
> branches. This would require the project to fund someone to do this
> work long term, to ensure the stable updates haven't caused
> regressions, to cherry pick patches that fix code that was not present
> in the upstream release, and in their remaining time help get more
> code in mainline.
> 
> Cheers,
> 
> Joel

Thanks for sharing the details, and in short, I'm moving torward the
similar direction:)

My current plan is to upgrade openbmc kernel at least once a year
(skipping ~4 kernel releases) for facebook network openbmc platforms,
and I'm facing the similar challenges: upstreaming kernel patches and
test enhancement. I don't have plan to force more frequent kernel
upgrade in 2023, because if I had bandwidth, I'd rather spend the time
upstreaming patches: I believe kernel upgrade would be much easier if
all the patches are upstreamed.

I quickly went through the local kernel patches in my repo, and they
fall in 3 major categories: 1) JTAG master drivers 2) hwmon drivers 3)
enabling dsa in a few dts files. I'm not sure if anyone is actively
looking into the jtag patch series, but I will try my best to clean up
some patches in #2 and #3 this year.

BTW, I will create the recipe to fetch dev-6.1 into meta/facebook
openbmc tree soon. Thanks again for maintaining the tree.


Cheers,

Tao