openbmc Digest, Vol 90, Issue 49
Tao Ren
rentao.bupt at gmail.com
Sat Feb 25 13:20:39 AEDT 2023
Hi Erhan,
We are using the jtag master driver implementation from "JTAG driver
introduction" patch series. You may need to resolve merge conflicts
depending on your kernel version.
https://lore.kernel.org/all/20200414091548.GH34613@smile.fi.intel.com/t/
Cheers,
Tao
On Fri, Feb 24, 2023 at 09:01:18AM +0000, Erhan Y. wrote:
> Hi Tao,Where can we find the current source or patches for AST2xxx JTAG master drivers on Linux 6.x?Thanks
>
> Message: 1
> Date: Wed, 22 Feb 2023 23:33:29 -0800
> From: Tao Ren <rentao.bupt at gmail.com>
> To: Joel Stanley <joel at jms.id.au>
> Cc: OpenBMC Maillist <openbmc at lists.ozlabs.org>
> Subject: Re: OpenBMC Linux 6.1
> Message-ID: <Y/cWyUVGkYA2UvBp at fedora>
> Content-Type: text/plain; charset=us-ascii
>
> 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
> On Friday, February 24, 2023 at 03:08:44 AM GMT+3, openbmc-request at lists.ozlabs.org <openbmc-request at lists.ozlabs.org> wrote:
>
> Send openbmc mailing list submissions to
> openbmc at lists.ozlabs.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.ozlabs.org/listinfo/openbmc
> or, via email, send a message with subject or body 'help' to
> openbmc-request at lists.ozlabs.org
>
> You can reach the person managing the list at
> openbmc-owner at lists.ozlabs.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of openbmc digest..."
>
>
> Today's Topics:
>
> 1. Re: OpenBMC Linux 6.1 (Tao Ren)
> 2. RE: [PATCH v5 1/2] dt-bindings: i2c: Add support for ASPEED
> i2Cv2 (Ryan Chen)
> 3. [PATCH v2 0/3] ARM: dts: aspeed: ASRock BMC updates (Zev Weiss)
> 4. [PATCH v2 3/3] ARM: dts: aspeed: asrock: Correct firmware
> flash SPI clocks (Zev Weiss)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 22 Feb 2023 23:33:29 -0800
> From: Tao Ren <rentao.bupt at gmail.com>
> To: Joel Stanley <joel at jms.id.au>
> Cc: OpenBMC Maillist <openbmc at lists.ozlabs.org>
> Subject: Re: OpenBMC Linux 6.1
> Message-ID: <Y/cWyUVGkYA2UvBp at fedora>
> Content-Type: text/plain; charset=us-ascii
>
> 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
>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 23 Feb 2023 10:25:56 +0000
> From: Ryan Chen <ryan_chen at aspeedtech.com>
> To: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>, Rob Herring
> <robh+dt at kernel.org>, Krzysztof Kozlowski
> <krzysztof.kozlowski+dt at linaro.org>, Joel Stanley <joel at jms.id.au>,
> Andrew Jeffery <andrew at aj.id.au>, Philipp Zabel
> <p.zabel at pengutronix.de>, "openbmc at lists.ozlabs.org"
> <openbmc at lists.ozlabs.org>, "linux-arm-kernel at lists.infradead.org"
> <linux-arm-kernel at lists.infradead.org>,
> "linux-aspeed at lists.ozlabs.org" <linux-aspeed at lists.ozlabs.org>,
> "linux-kernel at vger.kernel.org" <linux-kernel at vger.kernel.org>
> Subject: RE: [PATCH v5 1/2] dt-bindings: i2c: Add support for ASPEED
> i2Cv2
> Message-ID:
> <SEZPR06MB52697747528490B1A16AF87FF2AB9 at SEZPR06MB5269.apcprd06.prod.outlook.com>
>
> Content-Type: text/plain; charset="utf-8"
>
> Hello Krzysztof,
>
> > -----Original Message-----
> > From: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
> > Sent: Thursday, February 23, 2023 5:29 PM
> > To: Ryan Chen <ryan_chen at aspeedtech.com>; Rob Herring
> > <robh+dt at kernel.org>; Krzysztof Kozlowski
> > <krzysztof.kozlowski+dt at linaro.org>; Joel Stanley <joel at jms.id.au>; Andrew
> > Jeffery <andrew at aj.id.au>; Philipp Zabel <p.zabel at pengutronix.de>;
> > openbmc at lists.ozlabs.org; linux-arm-kernel at lists.infradead.org;
> > linux-aspeed at lists.ozlabs.org; linux-kernel at vger.kernel.org
> > Subject: Re: [PATCH v5 1/2] dt-bindings: i2c: Add support for ASPEED i2Cv2
> >
> > On 22/02/2023 11:47, Ryan Chen wrote:
> > >>>> connector. That slave will keep state to drive clock stretching.
> > >>>>> So it is specific enable in i2c bus#1. Others is not needed enable
> > timeout.
> > >>>>> Does this draw is more clear in scenario?
> > >>>>
> > >>>> I2C bus #1 works in slave mode? So you always need it for slave work?
> > >>>
> > >>> Yes, it is both slave/master mode. It is always dual role. Slave
> > >>> must always
> > >> work.
> > >>> Due to another board master will send.
> > >>
> > >> I meant that you need this property when it works in slave mode? It
> > >> would be then redundant to have in DT as it is implied by the mode.
> > >
> > > But timeout feature is also apply in master. It for avoid suddenly
> > > slave miss(un-plug) Master can timeout and release the SDA/SCL, return.
> >
> > OK, yet the property should describe the hardware, not the register feature you
> > want to program. You need to properly model it in DT binding to represent
> > hardware setup, not your desired Linux driver behavior.
> >
> > >>>>> The same draw, in this case, i2c bus#1 that is multi-master
> > >>>>> transfer
> > >>>> architecture.
> > >>>>> Both will inactive with trunk data. That cane enable i2c#1 use DMA
> > >>>>> transfer
> > >>>> to reduce CPU utilized.
> > >>>>> Others (bus#2/3) can keep byte/buff mode.
> > >>>>
> > >>>> Isn't then current bus configuration for I2C#1 known to the driver?
> > >>>> Jeremy asked few other questions around here...
> > >>>
> > >>> No, The driver don't know currently board configuration.
> > >>
> > >> It knows whether it is working in multi-master/slave mode.
> > >
> > > But in DT can decide which i2c bus number can use dma or buffer mode
> > transfer.
> > > If in another i2c bus support master only, also can use dma to transfer trunk
> > data to another slave.
> >
> > and none of these were explained in commit msg or device description.
> >
> Thanks your guidance. I will add all those discussion in next patches cover-letter.
> Best regards,
> Ryan Chen.
>
> ------------------------------
>
> Message: 3
> Date: Thu, 23 Feb 2023 16:03:57 -0800
> From: Zev Weiss <zev at bewilderbeest.net>
> To: Andrew Jeffery <andrew at aj.id.au>, Joel Stanley <joel at jms.id.au>
> Cc: Zev Weiss <zev at bewilderbeest.net>, openbmc at lists.ozlabs.org,
> Krzysztof Kozlowski <krzysztof.kozlowski+dt at linaro.org>, Rob Herring
> <robh+dt at kernel.org>, devicetree at vger.kernel.org,
> linux-arm-kernel at lists.infradead.org, linux-aspeed at lists.ozlabs.org,
> linux-kernel at vger.kernel.org
> Subject: [PATCH v2 0/3] ARM: dts: aspeed: ASRock BMC updates
> Message-ID: <20230224000400.12226-1-zev at bewilderbeest.net>
>
> Hello,
>
> This patch series contains a few small device-tree updates for ASRock
> BMCs: an LED polarity fix for romed8hm3, enabling the ast2500 PECI
> device on e3c246d4i, and a SPI flash clock frequency fix for both.
>
> Thanks,
> Zev
>
> Changes since v1 [0]:
> - Added patch 3 correcting SPI flash clocks
>
> [0] https://lore.kernel.org/linux-devicetree/20230203105405.21942-1-zev@bewilderbeest.net/
>
> Zev Weiss (3):
> ARM: dts: aspeed: romed8hm3: Fix GPIO polarity of system-fault LED
> ARM: dts: aspeed: e3c246d4i: Add PECI device
> ARM: dts: aspeed: asrock: Correct firmware flash SPI clocks
>
> arch/arm/boot/dts/aspeed-bmc-asrock-e3c246d4i.dts | 6 +++++-
> arch/arm/boot/dts/aspeed-bmc-asrock-romed8hm3.dts | 4 ++--
> 2 files changed, 7 insertions(+), 3 deletions(-)
>
> --
> 2.39.1.438.gdcb075ea9396.dirty
>
>
>
> ------------------------------
>
> Message: 4
> Date: Thu, 23 Feb 2023 16:04:00 -0800
> From: Zev Weiss <zev at bewilderbeest.net>
> To: Andrew Jeffery <andrew at aj.id.au>, Joel Stanley <joel at jms.id.au>
> Cc: Zev Weiss <zev at bewilderbeest.net>, Krzysztof Kozlowski
> <krzysztof.kozlowski+dt at linaro.org>, Rob Herring <robh+dt at kernel.org>,
> devicetree at vger.kernel.org, linux-arm-kernel at lists.infradead.org,
> linux-aspeed at lists.ozlabs.org, linux-kernel at vger.kernel.org,
> openbmc at lists.ozlabs.org, stable at vger.kernel.org
> Subject: [PATCH v2 3/3] ARM: dts: aspeed: asrock: Correct firmware
> flash SPI clocks
> Message-ID: <20230224000400.12226-4-zev at bewilderbeest.net>
>
> While I'm not aware of any problems that have occurred running these
> at 100 MHz, the official word from ASRock is that 50 MHz is the
> correct speed to use, so let's be safe and use that instead.
>
> Signed-off-by: Zev Weiss <zev at bewilderbeest.net>
> Cc: stable at vger.kernel.org
> Fixes: 2b81613ce417 ("ARM: dts: aspeed: Add ASRock E3C246D4I BMC")
> Fixes: a9a3d60b937a ("ARM: dts: aspeed: Add ASRock ROMED8HM3 BMC")
> ---
> arch/arm/boot/dts/aspeed-bmc-asrock-e3c246d4i.dts | 2 +-
> arch/arm/boot/dts/aspeed-bmc-asrock-romed8hm3.dts | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/boot/dts/aspeed-bmc-asrock-e3c246d4i.dts b/arch/arm/boot/dts/aspeed-bmc-asrock-e3c246d4i.dts
> index 67a75aeafc2b..c4b2efbfdf56 100644
> --- a/arch/arm/boot/dts/aspeed-bmc-asrock-e3c246d4i.dts
> +++ b/arch/arm/boot/dts/aspeed-bmc-asrock-e3c246d4i.dts
> @@ -63,7 +63,7 @@ flash at 0 {
> status = "okay";
> m25p,fast-read;
> label = "bmc";
> - spi-max-frequency = <100000000>; /* 100 MHz */
> + spi-max-frequency = <50000000>; /* 50 MHz */
> #include "openbmc-flash-layout.dtsi"
> };
> };
> diff --git a/arch/arm/boot/dts/aspeed-bmc-asrock-romed8hm3.dts b/arch/arm/boot/dts/aspeed-bmc-asrock-romed8hm3.dts
> index 00efe1a93a69..4554abf0c7cd 100644
> --- a/arch/arm/boot/dts/aspeed-bmc-asrock-romed8hm3.dts
> +++ b/arch/arm/boot/dts/aspeed-bmc-asrock-romed8hm3.dts
> @@ -51,7 +51,7 @@ flash at 0 {
> status = "okay";
> m25p,fast-read;
> label = "bmc";
> - spi-max-frequency = <100000000>; /* 100 MHz */
> + spi-max-frequency = <50000000>; /* 50 MHz */
> #include "openbmc-flash-layout-64.dtsi"
> };
> };
> --
> 2.39.1.438.gdcb075ea9396.dirty
>
>
>
> End of openbmc Digest, Vol 90, Issue 49
> ***************************************
>
More information about the openbmc
mailing list