openbmc Digest, Vol 90, Issue 49
Erhan Y.
erhan14 at yahoo.com
Fri Feb 24 20:01:18 AEDT 2023
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
***************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20230224/e954dd5f/attachment-0001.htm>
More information about the openbmc
mailing list