FW: OpenBMC support for SAM9X75 - follow up

[Marco.Cardellini at microchip.com]

Hi Patrick,

Many thanks for your feed back
I will discuss now with our Linux

Regards
Marco

Marco Cardellini
Manager-Applications Engineering
Tel: (+33) (0) 6 72 86 84 83
marco.cardellini at microchip.com 

Microchip Technology Rousset
57 Avenue Victoire, 13790 Rousset, France
Fax: (+33) (0) 4 42 53 60 01
www.microchip.com



-----Original Message-----
From: Patrick Williams <patrick at stwcx.xyz> 
Sent: Tuesday, November 7, 2023 12:07 AM
To: Marco Cardellini - M43165 <Marco.Cardellini at microchip.com>
Cc: geissonator at gmail.com; openbmc at lists.ozlabs.org; Hakim Cherif - M69710 <Hakim.Cherif at microchip.com>
Subject: Re: FW: OpenBMC support for SAM9X75 - follow up

On Fri, Nov 03, 2023 at 08:37:55AM +0000, Marco.Cardellini at microchip.com wrote:
> Hi Patrick, Andrew
> 
> Many thanks for your feed back but we are not sure to understand your answer.
> .
> Does it mean openBMC team will keep updating their code based on any yocto release?

OpenBMC only does development against the Yocto master branch.

If you look at our Kirkstone branch you will see it is 3592 commits behind master and was last touched in April 2022.  That means it is missing 1.5 years worth of BMC code development.

https://github.com/openbmc/openbmc/tree/kirkstone/meta-phosphor

> 
> Checked the wiki, kirkstone is the latest LTS version of yocto. 
> https://wiki.yoctoproject.org/wiki/Releases

LTS releases mean very little for OpenBMC.  Most OpenBMC uses take a "live at HEAD" approach (or something very near to it).  We do not maintain past releases and we certainly do not add new code to them.

> 
> Did openBMC team mean if we want to put our meta (meta-atmel) to openBMC github, we have to follow every version from yocto release?

There are two approaches:

1. You add the bare minimum of meta-atmel recipes to support your SOC into our tree (this was Andrew G.'s suggestion).  We need to understand what these recipes are.  You will probably end up with a similar set as what is currently in meta-nuvoton.

2. You ensure your own meta-atmel is a well-maintained Yocto meta layer (by ensuring it always works against Yocto's master release as well) and then we can add it into our subtree import tool.  This is how we keep meta-arm, meta-raspberrypi, meta-openembedded, etc. updated.

> Is there any quick way if we integrate our meta to kirkstone branch?

No.  And even if we did, it would provide no value since our Kirkstone branch is using relatively ancient code.

--
Patrick Williams