Help

[张健]

From: openbmc-request at lists.ozlabs.org
Date: 2月25日 (周五) 05:00
Subject: [External] openbmc Digest, Vol 78, Issue 123
To: <openbmc at lists.ozlabs.org>
Send openbmc mailing list submissions toopenbmc at lists.ozlabs.orgTo
subscribe or unsubscribe via the World Wide Web, visit
https://lists.ozlabs.org/listinfo/openbmcor, via email, send a message with
subject or body 'help' toopenbmc-request at lists.ozlabs.orgYou can reach the
person managing the list atopenbmc-owner at lists.ozlabs.orgWhen replying,
please edit your Subject line so it is more specificthan "Re: Contents of
openbmc digest..."Today's Topics: 1. [u-boot, v2019.04-aspeed-openbmc 1/1]
fix compiling warnings for AST2600 A1 SPL (Jamin Lin) 2. [u-boot,
v2019.04-aspeed-openbmc 0/1] fix compiling warnings for AST2600 A1 SPL
(Jamin Lin) 3. Re: I3C Binding DSP0233 (Matt Johnston) 4. Re: New
u-boot-aspeed-sdk runs slow and cause wdt2 timeout on ast2500 (Joel
Stanley) 5. Re: [u-boot,v2019.04-aspeed-openbmc 1/1] fix compiling warnings
for AST2600 A1 SPL (Joel Stanley) 6. Re: Checking for network online
(Patrick Williams) 7. Re: [PATCH 1/2] pinctrl: aspeed: Enable pass-through
on GPIOE1 and GPIOE3 free (Bills, Jason
M)----------------------------------------------------------------------Message:
1Date: Thu, 24 Feb 2022 16:11:21 +0800From: Jamin Lin To: , , Cc: ,
Subject: [u-boot, v2019.04-aspeed-openbmc 1/1] fix compiling warningsfor
AST2600 A1 SPLMessage-ID:
<20220224081121.10389-2-jamin_lin at aspeedtech.com>Content-Type:
text/plainremove duplicated defineSigned-off-by: Jamin Lin ---
include/configs/evb_ast2600a1_spl.h | 7 ------- 1 file changed, 7
deletions(-)diff --git a/include/configs/evb_ast2600a1_spl.h
b/include/configs/evb_ast2600a1_spl.hindex 655896b237..006cc4345b 100644---
a/include/configs/evb_ast2600a1_spl.h+++
b/include/configs/evb_ast2600a1_spl.h@@ -42,13 +42,6 @@ #endif #endif -/*
SPL */-#define CONFIG_SPL_TEXT_BASE0x00000000-#define
CONFIG_SPL_MAX_SIZE0x0000E800-#define CONFIG_SPL_STACK0x10010000-#define
CONFIG_SPL_BSS_START_ADDR0x90000000-#define
CONFIG_SPL_BSS_MAX_SIZE0x00100000- #define CONFIG_SUPPORT_EMMC_BOOT
#endif/* __CONFIG_H */-- 2.17.1------------------------------Message:
2Date: Thu, 24 Feb 2022 16:11:20 +0800From: Jamin Lin To: , , Cc: ,
Subject: [u-boot, v2019.04-aspeed-openbmc 0/1] fix compiling warningsfor
AST2600 A1 SPLMessage-ID:
<20220224081121.10389-1-jamin_lin at aspeedtech.com>Content-Type:
text/plainremove duplicated defineJamin Lin (1): fix compiling warnings for
AST2600 A1 SPL include/configs/evb_ast2600a1_spl.h | 7 ------- 1 file
changed, 7 deletions(-)-- 2.17.1------------------------------Message:
3Date: Thu, 24 Feb 2022 11:06:39 +0800From: Matt Johnston To: Rahul Kapoor
,"openbmc at lists.ozlabs.org" Subject: Re: I3C Binding DSP0233Message-ID:<
73c46f0b8b609edddad0e314ead38c9b9d72517e.camel at codeconstruct.com.au>Content-Type:
text/plain; charset="UTF-8"On Wed, 2022-02-23 at 16:45 +0000, Rahul Kapoor
wrote:> Hi,> ?> I would like to understand if OpenBMC project currently
supports MCTP over> I3C>
https://www.dmtf.org/sites/default/files/standards/documents/DSP0233_1.0.0.pdf>
? If not, are there plans to support it going forward? We are currently>
using Intel-BMC/libmctp for SMBus binding and plan to transition to in->
kernel MCTP in future.Hi Rahul,I'm not aware of any current work on
MCTP-over-I3C for OpenBMC or in-kernel.It could be added as another
in-kernel MCTP transport alongside the currentI2C net driver.I'm not sure
what the current status is for I3C drivers on BMC hardware.Kernel I3C will
only support Linux as an I3C Controller not Target, thoughthat would suit
many setups.Cheers,Matt------------------------------Message: 4Date: Thu,
24 Feb 2022 03:45:48 +0000From: Joel Stanley To: Lei Yu Cc: ChiaWei Wang ,
Troy Lee, Ryan Chen ,openbmc , tangyiwei.2022 at bytedance.comSubject: Re: New
u-boot-aspeed-sdk runs slow and cause wdt2 timeout
onast2500Message-ID:Content-Type: text/plain; charset="UTF-8"On Wed, 23 Feb
2022 at 10:02, Lei Yu wrote:>> > > > > Could you share us the boot log with
timestamps?> > > > > It would be nice to know the time elapsed at each
stage.> > > >> > > > Pasted to https://pastebin.com/emseqW6c> > > > It
contains two logs, the first one is good, and the second has the issue.> >>
> Working:> > [2022-02-23 02:47:03] U-Boot 2019.04 (Jan 24 2022 - 10:18:18
+0000)> > [2022-02-23 02:47:06] ## Loading kernel from FIT Image at
20100000 ...> > [2022-02-23 02:47:12] Starting kernel ...> >> > 3 + 6
seconds.> >> > broken:> > [2022-02-23 02:58:07] U-Boot 2019.04 (Feb 15 2022
- 07:22:14 +0000)> > [2022-02-23 02:58:12] ## Loading kernel from FIT Image
at 20100000 ...> > [2022-02-23 02:58:22] Starting kernel ...> >> > 5 + 10
seconds.> >> > Interesting that the pre-hashing part is also slower.> >> >
The old branch was based on v00.04.03. The new branch is based on
v00.04.09.> >> > I wonder if this is the cause:> >> > $ git diff
v00.04.03..v00.04.09 -- configs/evb-ast2500_defconfig> > diff --git
a/configs/evb-ast2500_defconfig b/configs/evb-ast2500_defconfig> > index
9fcf55b05ebb..000ed3f90bdd 100644> > --- a/configs/evb-ast2500_defconfig> >
+++ b/configs/evb-ast2500_defconfig> > @@ -1,4 +1,5 @@> > CONFIG_ARM=y> >
+CONFIG_SYS_DCACHE_OFF=y> > CONFIG_ARCH_ASPEED=y> >
CONFIG_SYS_TEXT_BASE=0x0> > CONFIG_SYS_MALLOC_F_LEN=0x2000> >> > Lei, can
you re-test with CONFIG_SYS_DCACHE_OFF=n ?> >>> Yiwei helped to test with
CONFIG_SYS_DCACHE_OFF=n, and it works fine now.> So it seems we get the
root cause!I'm glad this worked. The bill is in the mail :)I would suggest
this is not the root cause. This is a workaround thatspeeds up booting
enough that you make it to linux, but if your kernelimage got a bit larger
(for example), it would take longer and theissue would show up again.To
properly fix the issue, we need to ensure the watchdog is serviced,as I
mentioned in my previous
email.Cheers,Joel------------------------------Message: 5Date: Thu, 24 Feb
2022 11:43:32 +0000From: Joel Stanley To: Jamin Lin Cc: OpenBMC Maillist ,
Andrew Jeffery, Troy Lee , Steven LeeSubject: Re:
[u-boot,v2019.04-aspeed-openbmc 1/1] fix compilingwarnings for AST2600 A1
SPLMessage-ID:Content-Type: text/plain; charset="UTF-8"On Thu, 24 Feb 2022
at 08:11, Jamin Lin wrote:>> remove duplicated define>> Signed-off-by:
Jamin Lin > ---> include/configs/evb_ast2600a1_spl.h | 7 -------> 1 file
changed, 7 deletions(-)>> diff --git a/include/configs/evb_ast2600a1_spl.h
b/include/configs/evb_ast2600a1_spl.h> index 655896b237..006cc4345b 100644>
--- a/include/configs/evb_ast2600a1_spl.h> +++
b/include/configs/evb_ast2600a1_spl.h> @@ -42,13 +42,6 @@> #endif> #endif>>
-/* SPL */> -#define CONFIG_SPL_TEXT_BASE 0x00000000> -#define
CONFIG_SPL_MAX_SIZE 0x0000E800> -#define CONFIG_SPL_STACK 0x10010000>
-#define CONFIG_SPL_BSS_START_ADDR 0x90000000> -#define
CONFIG_SPL_BSS_MAX_SIZE 0x00100000A good cleanup. While we're here, can we
clean up the various ast2600config headers?There is a large diff between
the a0 and the a1 spl header. I know theA0 has a smaller SRAM. Are there
any other differences required?> -> #define CONFIG_SUPPORT_EMMC_BOOT>>
#endif /* __CONFIG_H */> --> 2.17.1>------------------------------Message:
6Date: Thu, 24 Feb 2022 14:09:11 -0600From: Patrick Williams To: Johnathan
Mantey Cc: Jiaqing Zhao , Lei Yu, Jeremy Kerr ,OpenBMC Maillist Subject:
Re: Checking for network onlineMessage-ID: Content-Type: text/plain;
charset="us-ascii"On Wed, Feb 23, 2022 at 12:04:12PM -0800, Johnathan
Mantey wrote:> On 2/23/22 09:44, Jiaqing Zhao wrote:> > On 2022-02-23
21:48, Patrick Williams wrote:> >> On Wed, Feb 23, 2022 at 10:09:19AM
+0800, Jiaqing Zhao wrote:> There may be openbmc powered servers that do
use the distributed logging > provided by rsyslogd. If there are then
globally removing network-online > from the rsyslog service file is
undesirable. I consider the same to be > true of assigning a default
RequiredForOnline=false.> > Based on the above, it's my opinion this is a
vendor based decision for > how to configure
rsyslog/systemd-networkd-wait-online.I agree we shouldn't enable this
globally, but that doesn't mean we can't adda simple PKGCONFIG that allows
it to be enabled/disabled as needed. That waywe only have the single
`PKGCONFIG:append` line in vendor layers and vendorsthat have a problem
with it can leave it same as upstream.-- Patrick Williams--------------
next part --------------A non-text attachment was scrubbed...Name:
signature.ascType: application/pgp-signatureSize: 833 bytesDesc: not
availableURL: ------------------------------Message: 7Date: Thu, 24 Feb
2022 14:03:48 -0700From: "Bills, Jason M" To: Joel Stanley , Andrew Jeffery
Cc: "openbmc at lists.ozlabs.org" Subject: Re: [PATCH 1/2] pinctrl: aspeed:
Enable pass-through onGPIOE1 and GPIOE3 freeMessage-ID: <
7d792cb4-9eaf-cbdc-d39c-72217d5ebcf8 at linux.intel.com>Content-Type:
text/plain; charset=UTF-8; format=flowedOn 2/6/2022 11:45 PM, Joel Stanley
wrote:> On Wed, 2 Feb 2022 at 22:49, Andrew Jeffery wrote:>>>>>>>> On Thu,
3 Feb 2022, at 06:29, Bills, Jason M wrote:>>> This change adds a
gpio_disable_free() implementation that checks>>> if the GPIO being freed
is GPIOE1 (33) or GPIOE3 (35) and will>>> re-enable the pass-through
mux.>>>> Okay. So trying to pull back from the implementation for a
moment:>>>> Perhaps we can view pass-through as a property on a pair of
GPIOs, rather than a mux state? I think it would be better if we could, for
instance, annotate this in the devicetree?>>>> If we did that I don't think
we're require this awkward and pin-specific implementation of the free
callback for GPIOs.>>>> If pass-through is enabled it puts constraints on
how the pins are used if they're requested as GPIOs, but we can add those
dynamic checks in the GPIO driver.>>>> Let me think about it some more.>>>>
Thanks for surfacing the patch.> > This is for the kernel, I assume.> >
Jason, you should send the patch to the upstream lists (use>
get_maintainers.pl) for review.Sorry for the delay. I found the right lists
with get_maintainers.pl. Should I send these patches to the upstream lists
as they are, or do they need to be tweaked?Thanks!-Jason> > Cheers,> >
JoelEnd of openbmc Digest, Vol 78, Issue
123****************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20220224/bd3cf433/attachment-0001.htm>