[V0,1/1] bootconfig: Increase max size of bootconfig from 32 KB to 256 KB for DCC support
Message ID | 654357bcbfd3974072a558c494a51edafaa73e1a.1673261071.git.quic_schowdhu@quicinc.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:4e01:0:0:0:0:0 with SMTP id p1csp2189817wrt; Mon, 9 Jan 2023 06:34:53 -0800 (PST) X-Google-Smtp-Source: AMrXdXv4pLt0T234EMKeyIFu0uY/p4Oe+0baj4XpHR6JHAGz7sMplL6BCd8J+kPsP3mR1Nh/CZgf X-Received: by 2002:a17:906:b1c5:b0:84d:14c8:b669 with SMTP id bv5-20020a170906b1c500b0084d14c8b669mr11590557ejb.77.1673274893612; Mon, 09 Jan 2023 06:34:53 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1673274893; cv=none; d=google.com; s=arc-20160816; b=kWkRH5a7iOV+NEd0kqxVuYYFE4StIwjgtEJ79RJM1UR6wULevy7O/6Z2qqXt89zjhc TX6a30Jki92Wh6YzOzr4z5HDZDqP4QXg6tZIcHeEnE/CXKkUJXVokerl4Ns5uio9SZ7+ i3kOD/Y3tMcio7euuYgMvui1Q+723jJ9dBRe6DuEe7lwFxHq05oM7Xpk0TzuMszTqJdA 3EkxpqBcfKB7BCWwfVK99+MkFfP/oeP4c3mCe1hobo1WJb/fFxD3xKWVVF6Z4JmymMeM wNyG2Hpgo8Cts6k/3ogo6bIFKBb2Rez0X0cLY0gwncttKAALozFAR+bKky4g0N+j0KwS 6hCw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:references:in-reply-to:message-id :date:subject:cc:to:from:dkim-signature; bh=To2M7m8ifpIWIdwpFICEz3ryGg079W9y4tN8/QOGdV4=; b=WKsfptmr0mXxKYVNxk39aFOZqrgyX0akZiWy2kzYT64Ldco/aLSzkTH+81CGD/q5ma CMNj/Mguyeksr49n5OfOvEnI80YKltgr7HWMzPjWhHIk5GTav1OU0NkZfVYncwgBZxJb z08Da/Rmc5fbIn60D/WbYewlNKyQB/bknFr+0nuuu89MtBwmUaBbL/EE3zZbNUmU4sKA k/YpzjHq/aicoocX1zBUT5X1G6+rKyN5dJiU/x0xLZUREjdziBFLyCYGISK+Wvwu9U1w ELjk27wf86HBsDGXMlNYanoL+TG2Plp5PEK2MJedu9dcS97Jc0Z+zRRQH4SWquBZwnEI aCgw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@quicinc.com header.s=qcppdkim1 header.b=C8hhFRcN; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=quicinc.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id go44-20020a1709070dac00b0084d45631a5dsi3708511ejc.587.2023.01.09.06.34.29; Mon, 09 Jan 2023 06:34:53 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@quicinc.com header.s=qcppdkim1 header.b=C8hhFRcN; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=quicinc.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233120AbjAIObx (ORCPT <rfc822;274620705z@gmail.com> + 99 others); Mon, 9 Jan 2023 09:31:53 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56768 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233232AbjAIObn (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 9 Jan 2023 09:31:43 -0500 Received: from mx0a-0031df01.pphosted.com (mx0a-0031df01.pphosted.com [205.220.168.131]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 23414F46; Mon, 9 Jan 2023 06:31:42 -0800 (PST) Received: from pps.filterd (m0279863.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 309CY0h6015630; Mon, 9 Jan 2023 14:31:35 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quicinc.com; h=from : to : cc : subject : date : message-id : in-reply-to : references : mime-version : content-type; s=qcppdkim1; bh=To2M7m8ifpIWIdwpFICEz3ryGg079W9y4tN8/QOGdV4=; b=C8hhFRcNZoSAPYaBcWSIn41fhcMKbBRPq0+XpDXrxiYoeFElBGJe7WXV2Wgrgv7ETwW1 tFlpzy2g4immZDqO4v0U6sifj/Lb7pa7KJ0z6fozAR8C55omc+8jIW/E0FZ02eq79K4E eFOjxy07sm04gP2Br904yWKwUXgpOTTeh1CfEotCihmDtY+L9hwXu289h3fBJwoeAgw5 jEfDT3H3VCyaBr3WFwkvOrPcyLO4FSwPwHGxR3cuM1hGJbURpG0P0q2O5OM5t34xl+DB OC7kmV+sZ1L82lhQ81kR0XX4xpG9GUvOJrKaz67rZpGqnRhIM5JXpXIE/Sk8fpd/1bZC nw== Received: from nalasppmta01.qualcomm.com (Global_NAT1.qualcomm.com [129.46.96.20]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 3my0yab96p-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 09 Jan 2023 14:31:34 +0000 Received: from nalasex01a.na.qualcomm.com (nalasex01a.na.qualcomm.com [10.47.209.196]) by NALASPPMTA01.qualcomm.com (8.17.1.5/8.17.1.5) with ESMTPS id 309EVYIk008829 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 9 Jan 2023 14:31:34 GMT Received: from blr-ubuntu-525.qualcomm.com (10.80.80.8) by nalasex01a.na.qualcomm.com (10.47.209.196) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.36; Mon, 9 Jan 2023 06:31:31 -0800 From: Souradeep Chowdhury <quic_schowdhu@quicinc.com> To: Masami Hiramatsu <mhiramat@kernel.org>, <linux-kernel@vger.kernel.org>, Bjorn Andersson <andersson@kernel.org> CC: <linux-arm-kernel@lists.infradead.org>, <linux-arm-msm@vger.kernel.org>, Sai Prakash Ranjan <quic_saipraka@quicinc.com>, Sibi Sankar <quic_sibis@quicinc.com>, Rajendra Nayak <quic_rjendra@quicinc.com>, Souradeep Chowdhury <quic_schowdhu@quicinc.com> Subject: [PATCH V0 1/1] bootconfig: Increase max size of bootconfig from 32 KB to 256 KB for DCC support Date: Mon, 9 Jan 2023 20:01:05 +0530 Message-ID: <654357bcbfd3974072a558c494a51edafaa73e1a.1673261071.git.quic_schowdhu@quicinc.com> X-Mailer: git-send-email 2.7.4 In-Reply-To: <cover.1673261071.git.quic_schowdhu@quicinc.com> References: <cover.1673261071.git.quic_schowdhu@quicinc.com> MIME-Version: 1.0 Content-Type: text/plain X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: nasanex01a.na.qualcomm.com (10.52.223.231) To nalasex01a.na.qualcomm.com (10.47.209.196) X-QCInternal: smtphost X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=5800 signatures=585085 X-Proofpoint-GUID: NsW1RMkj6V-w0IFwYdL-EqcGWixwojvg X-Proofpoint-ORIG-GUID: NsW1RMkj6V-w0IFwYdL-EqcGWixwojvg X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.923,Hydra:6.0.545,FMLib:17.11.122.1 definitions=2023-01-09_08,2023-01-09_01,2022-06-22_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxlogscore=988 adultscore=0 malwarescore=0 clxscore=1015 phishscore=0 bulkscore=0 priorityscore=1501 mlxscore=0 impostorscore=0 spamscore=0 suspectscore=0 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2212070000 definitions=main-2301090104 X-Spam-Status: No, score=0.5 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW, RCVD_IN_SBL_CSS,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1754555894942296475?= X-GMAIL-MSGID: =?utf-8?q?1754555894942296475?= |
Series |
bootconfig: Increase size and node limit of bootconfig for DCC support
|
|
Commit Message
Souradeep Chowdhury
Jan. 9, 2023, 2:31 p.m. UTC
Increasing the memory size of bootconfig to be able to handle a max number of
8192 nodes to be fitted in memory size of 256KB.
Signed-off-by: Souradeep Chowdhury <quic_schowdhu@quicinc.com>
---
include/linux/bootconfig.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
Comments
On Mon, Jan 09, 2023 at 08:01:05PM +0530, Souradeep Chowdhury wrote: > Increasing the memory size of bootconfig to be able to handle a max number of > 8192 nodes to be fitted in memory size of 256KB. > This states what the patch does, but not why. The description you put in the cover letter does capture the why, but the cover-letter won't be part of the git history (and if it was, there's no reason to keep the motivation separate from the change). So please move the motivation into the commit message. Also, there's generally no reason to have a cover-letter for a single patch "series". So please skip the --cover-letter. Regards, Bjorn > Signed-off-by: Souradeep Chowdhury <quic_schowdhu@quicinc.com> > --- > include/linux/bootconfig.h | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/include/linux/bootconfig.h b/include/linux/bootconfig.h > index 1611f9d..64d233b 100644 > --- a/include/linux/bootconfig.h > +++ b/include/linux/bootconfig.h > @@ -55,11 +55,11 @@ struct xbc_node { > } __attribute__ ((__packed__)); > > #define XBC_KEY 0 > -#define XBC_VALUE (1 << 15) > -/* Maximum size of boot config is 32KB - 1 */ > +#define XBC_VALUE (1 << 18) > +/* Maximum size of boot config is 256KB - 1 */ > #define XBC_DATA_MAX (XBC_VALUE - 1) > > -#define XBC_NODE_MAX 1024 > +#define XBC_NODE_MAX 8192 > #define XBC_KEYLEN_MAX 256 > #define XBC_DEPTH_MAX 16 > > -- > 2.7.4 >
On Mon, 9 Jan 2023 20:01:05 +0530 Souradeep Chowdhury <quic_schowdhu@quicinc.com> wrote: > Increasing the memory size of bootconfig to be able to handle a max number of > 8192 nodes to be fitted in memory size of 256KB. Sorry, but you missed the 'xbc_node::data' stores the index of the data and that is uint16_t. So the XBC_DATA_MAX is fixed limitation. The number of nodes (XBC_NODE_MAX) can be expanded because I just decided it to keep the pre-compiled array size ~8KB. Maybe expanding it to 64KB just increase the size of kernel on init memory (and freed after boot). Could you tell me why you need such a big data for your DCC? Thank you, > > Signed-off-by: Souradeep Chowdhury <quic_schowdhu@quicinc.com> > --- > include/linux/bootconfig.h | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/include/linux/bootconfig.h b/include/linux/bootconfig.h > index 1611f9d..64d233b 100644 > --- a/include/linux/bootconfig.h > +++ b/include/linux/bootconfig.h > @@ -55,11 +55,11 @@ struct xbc_node { > } __attribute__ ((__packed__)); > > #define XBC_KEY 0 > -#define XBC_VALUE (1 << 15) > -/* Maximum size of boot config is 32KB - 1 */ > +#define XBC_VALUE (1 << 18) > +/* Maximum size of boot config is 256KB - 1 */ > #define XBC_DATA_MAX (XBC_VALUE - 1) > > -#define XBC_NODE_MAX 1024 > +#define XBC_NODE_MAX 8192 > #define XBC_KEYLEN_MAX 256 > #define XBC_DEPTH_MAX 16 > > -- > 2.7.4 >
On 1/9/2023 8:39 PM, Bjorn Andersson wrote: > On Mon, Jan 09, 2023 at 08:01:05PM +0530, Souradeep Chowdhury wrote: >> Increasing the memory size of bootconfig to be able to handle a max number of >> 8192 nodes to be fitted in memory size of 256KB. >> > > This states what the patch does, but not why. > > The description you put in the cover letter does capture the why, but > the cover-letter won't be part of the git history (and if it was, > there's no reason to keep the motivation separate from the change). So > please move the motivation into the commit message. > > Also, there's generally no reason to have a cover-letter for a > single patch "series". So please skip the --cover-letter. > > Regards, > Bjorn Ack > >> Signed-off-by: Souradeep Chowdhury <quic_schowdhu@quicinc.com> >> --- >> include/linux/bootconfig.h | 6 +++--- >> 1 file changed, 3 insertions(+), 3 deletions(-) >> >> diff --git a/include/linux/bootconfig.h b/include/linux/bootconfig.h >> index 1611f9d..64d233b 100644 >> --- a/include/linux/bootconfig.h >> +++ b/include/linux/bootconfig.h >> @@ -55,11 +55,11 @@ struct xbc_node { >> } __attribute__ ((__packed__)); >> >> #define XBC_KEY 0 >> -#define XBC_VALUE (1 << 15) >> -/* Maximum size of boot config is 32KB - 1 */ >> +#define XBC_VALUE (1 << 18) >> +/* Maximum size of boot config is 256KB - 1 */ >> #define XBC_DATA_MAX (XBC_VALUE - 1) >> >> -#define XBC_NODE_MAX 1024 >> +#define XBC_NODE_MAX 8192 >> #define XBC_KEYLEN_MAX 256 >> #define XBC_DEPTH_MAX 16 >> >> -- >> 2.7.4 >>
On 1/9/2023 8:48 PM, Masami Hiramatsu (Google) wrote: > On Mon, 9 Jan 2023 20:01:05 +0530 > Souradeep Chowdhury <quic_schowdhu@quicinc.com> wrote: > >> Increasing the memory size of bootconfig to be able to handle a max number of >> 8192 nodes to be fitted in memory size of 256KB. > > Sorry, but you missed the 'xbc_node::data' stores the index of the data and > that is uint16_t. So the XBC_DATA_MAX is fixed limitation. > > The number of nodes (XBC_NODE_MAX) can be expanded because I just decided it > to keep the pre-compiled array size ~8KB. Maybe expanding it to 64KB just > increase the size of kernel on init memory (and freed after boot). > > Could you tell me why you need such a big data for your DCC? > > Thank you, DCC is a debugging tool used in qcom which is needed to debug crashes that can happen at boot-time. For debugging purposes a large number of registers need to be configured in DCC driver which is to be fed via the bootconfig file. For that we need to expand the nodes as well as memory for using bootconfig. Can you let us know the changes that you suggest for doing the same? Is it fine to just increase the XBC_NODE_MAX, do we also need to change the uint16_t to u32 for proper storing of index values? > >> >> Signed-off-by: Souradeep Chowdhury <quic_schowdhu@quicinc.com> >> --- >> include/linux/bootconfig.h | 6 +++--- >> 1 file changed, 3 insertions(+), 3 deletions(-) >> >> diff --git a/include/linux/bootconfig.h b/include/linux/bootconfig.h >> index 1611f9d..64d233b 100644 >> --- a/include/linux/bootconfig.h >> +++ b/include/linux/bootconfig.h >> @@ -55,11 +55,11 @@ struct xbc_node { >> } __attribute__ ((__packed__)); >> >> #define XBC_KEY 0 >> -#define XBC_VALUE (1 << 15) >> -/* Maximum size of boot config is 32KB - 1 */ >> +#define XBC_VALUE (1 << 18) >> +/* Maximum size of boot config is 256KB - 1 */ >> #define XBC_DATA_MAX (XBC_VALUE - 1) >> >> -#define XBC_NODE_MAX 1024 >> +#define XBC_NODE_MAX 8192 >> #define XBC_KEYLEN_MAX 256 >> #define XBC_DEPTH_MAX 16 >> >> -- >> 2.7.4 >> > >
On Tue, 10 Jan 2023 17:26:07 +0530 Souradeep Chowdhury <quic_schowdhu@quicinc.com> wrote: > > > On 1/9/2023 8:48 PM, Masami Hiramatsu (Google) wrote: > > On Mon, 9 Jan 2023 20:01:05 +0530 > > Souradeep Chowdhury <quic_schowdhu@quicinc.com> wrote: > > > >> Increasing the memory size of bootconfig to be able to handle a max number of > >> 8192 nodes to be fitted in memory size of 256KB. > > > > Sorry, but you missed the 'xbc_node::data' stores the index of the data and > > that is uint16_t. So the XBC_DATA_MAX is fixed limitation. > > > > The number of nodes (XBC_NODE_MAX) can be expanded because I just decided it > > to keep the pre-compiled array size ~8KB. Maybe expanding it to 64KB just > > increase the size of kernel on init memory (and freed after boot). > > > > Could you tell me why you need such a big data for your DCC? > > > > Thank you, > > DCC is a debugging tool used in qcom which is needed to debug crashes > that can happen at boot-time. For debugging purposes a large number of > registers need to be configured in DCC driver which is to be fed via the > bootconfig file. For that we need to expand the nodes as well as memory > for using bootconfig. Hmm, how many registers does DCC usually use? And how big the bootconfig file is usually? I have no idea about that. > Can you let us know the changes that you suggest for doing the same? Is > it fine to just increase the XBC_NODE_MAX, do we also need to > change the uint16_t to u32 for proper storing of index values? Expanding the number of max nodes is easy, just increase the XBC_NODE_MAX (must be less than 64k). That will also increase the memory consumption during the boot time even if the bootconfig is small. Anyway, it will be freed after boot, so it maybe OK. But expanding the size of max bootconfig needs to change the type of the 'data' field to uint32_t (since that will be used for building bootconfig tool) and you also must confirm that `tools/bootconfig/bootconfig` can be built and pass the test-bootconfig.sh. Hmm, comparing with expanding the max number of XBC node, changing the 'data' type to uint32_t may not have much impact on memory consumption point of view, because it may increase only 20% of memory, but expanding the MAX_XBC_NODE always increases more than double. Thus, if we can accept increasing the number of node, it should be OK to change the 'data' type. BTW, I think now we don't need the ' __attribute__ ((__packed__))' for struct xbc_node. It was packed for reducing the size of array and able to pass 'compiled' bootconfig, but now it is just passed as a text data for safety. Thank you, > > > > > >> > >> Signed-off-by: Souradeep Chowdhury <quic_schowdhu@quicinc.com> > >> --- > >> include/linux/bootconfig.h | 6 +++--- > >> 1 file changed, 3 insertions(+), 3 deletions(-) > >> > >> diff --git a/include/linux/bootconfig.h b/include/linux/bootconfig.h > >> index 1611f9d..64d233b 100644 > >> --- a/include/linux/bootconfig.h > >> +++ b/include/linux/bootconfig.h > >> @@ -55,11 +55,11 @@ struct xbc_node { > >> } __attribute__ ((__packed__)); > >> > >> #define XBC_KEY 0 > >> -#define XBC_VALUE (1 << 15) > >> -/* Maximum size of boot config is 32KB - 1 */ > >> +#define XBC_VALUE (1 << 18) > >> +/* Maximum size of boot config is 256KB - 1 */ > >> #define XBC_DATA_MAX (XBC_VALUE - 1) > >> > >> -#define XBC_NODE_MAX 1024 > >> +#define XBC_NODE_MAX 8192 > >> #define XBC_KEYLEN_MAX 256 > >> #define XBC_DEPTH_MAX 16 > >> > >> -- > >> 2.7.4 > >> > > > >
On 1/10/2023 8:16 PM, Masami Hiramatsu (Google) wrote: > On Tue, 10 Jan 2023 17:26:07 +0530 > Souradeep Chowdhury <quic_schowdhu@quicinc.com> wrote: > >> >> >> On 1/9/2023 8:48 PM, Masami Hiramatsu (Google) wrote: >>> On Mon, 9 Jan 2023 20:01:05 +0530 >>> Souradeep Chowdhury <quic_schowdhu@quicinc.com> wrote: >>> >>>> Increasing the memory size of bootconfig to be able to handle a max number of >>>> 8192 nodes to be fitted in memory size of 256KB. >>> >>> Sorry, but you missed the 'xbc_node::data' stores the index of the data and >>> that is uint16_t. So the XBC_DATA_MAX is fixed limitation. >>> >>> The number of nodes (XBC_NODE_MAX) can be expanded because I just decided it >>> to keep the pre-compiled array size ~8KB. Maybe expanding it to 64KB just >>> increase the size of kernel on init memory (and freed after boot). >>> >>> Could you tell me why you need such a big data for your DCC? >>> >>> Thank you, >> >> DCC is a debugging tool used in qcom which is needed to debug crashes >> that can happen at boot-time. For debugging purposes a large number of >> registers need to be configured in DCC driver which is to be fed via the >> bootconfig file. For that we need to expand the nodes as well as memory >> for using bootconfig. > > Hmm, how many registers does DCC usually use? And how big the bootconfig > file is usually? I have no idea about that. So a typical bootconfig file for consumption of DCC looks like as follows dcc_config { link_list_0 { qcom-curr-link-list = 6 qcom-link-list = R_0x1781005c_1_apb, R_0x1782005c_1_apb } link_list_1 { qcom-curr-link-list = 5 qcom-link-list = R_0x1784005c_1_apb } } The "qcom-link-list" field can have 1000s of register , based on that max nodes is increased to 8192. > >> Can you let us know the changes that you suggest for doing the same? Is >> it fine to just increase the XBC_NODE_MAX, do we also need to >> change the uint16_t to u32 for proper storing of index values? > > Expanding the number of max nodes is easy, just increase the XBC_NODE_MAX > (must be less than 64k). That will also increase the memory consumption > during the boot time even if the bootconfig is small. Anyway, it will be > freed after boot, so it maybe OK. So since the limit is 64K, 8192 is a valid value for max nodes. > > But expanding the size of max bootconfig needs to change the type of > the 'data' field to uint32_t (since that will be used for building > bootconfig tool) and you also must confirm that `tools/bootconfig/bootconfig` > can be built and pass the test-bootconfig.sh. > Hmm, comparing with expanding the max number of XBC node, changing the > 'data' type to uint32_t may not have much impact on memory consumption point > of view, because it may increase only 20% of memory, but expanding the > MAX_XBC_NODE always increases more than double. > > Thus, if we can accept increasing the number of node, it should be OK to > change the 'data' type. That means from DCC point of view only increasing the max nodes is enough as increasing the data size is unrelated to increasing the max nodes? > > BTW, I think now we don't need the ' __attribute__ ((__packed__))' for > struct xbc_node. It was packed for reducing the size of array and able to > pass 'compiled' bootconfig, but now it is just passed as a text data for > safety. > > Thank you, > >> >> >>> >>>> >>>> Signed-off-by: Souradeep Chowdhury <quic_schowdhu@quicinc.com> >>>> --- >>>> include/linux/bootconfig.h | 6 +++--- >>>> 1 file changed, 3 insertions(+), 3 deletions(-) >>>> >>>> diff --git a/include/linux/bootconfig.h b/include/linux/bootconfig.h >>>> index 1611f9d..64d233b 100644 >>>> --- a/include/linux/bootconfig.h >>>> +++ b/include/linux/bootconfig.h >>>> @@ -55,11 +55,11 @@ struct xbc_node { >>>> } __attribute__ ((__packed__)); >>>> >>>> #define XBC_KEY 0 >>>> -#define XBC_VALUE (1 << 15) >>>> -/* Maximum size of boot config is 32KB - 1 */ >>>> +#define XBC_VALUE (1 << 18) >>>> +/* Maximum size of boot config is 256KB - 1 */ >>>> #define XBC_DATA_MAX (XBC_VALUE - 1) >>>> >>>> -#define XBC_NODE_MAX 1024 >>>> +#define XBC_NODE_MAX 8192 >>>> #define XBC_KEYLEN_MAX 256 >>>> #define XBC_DEPTH_MAX 16 >>>> >>>> -- >>>> 2.7.4 >>>> >>> >>> > >
On Tue, 10 Jan 2023 20:38:54 +0530 Souradeep Chowdhury <quic_schowdhu@quicinc.com> wrote: > > > On 1/10/2023 8:16 PM, Masami Hiramatsu (Google) wrote: > > On Tue, 10 Jan 2023 17:26:07 +0530 > > Souradeep Chowdhury <quic_schowdhu@quicinc.com> wrote: > > > >> > >> > >> On 1/9/2023 8:48 PM, Masami Hiramatsu (Google) wrote: > >>> On Mon, 9 Jan 2023 20:01:05 +0530 > >>> Souradeep Chowdhury <quic_schowdhu@quicinc.com> wrote: > >>> > >>>> Increasing the memory size of bootconfig to be able to handle a max number of > >>>> 8192 nodes to be fitted in memory size of 256KB. > >>> > >>> Sorry, but you missed the 'xbc_node::data' stores the index of the data and > >>> that is uint16_t. So the XBC_DATA_MAX is fixed limitation. > >>> > >>> The number of nodes (XBC_NODE_MAX) can be expanded because I just decided it > >>> to keep the pre-compiled array size ~8KB. Maybe expanding it to 64KB just > >>> increase the size of kernel on init memory (and freed after boot). > >>> > >>> Could you tell me why you need such a big data for your DCC? > >>> > >>> Thank you, > >> > >> DCC is a debugging tool used in qcom which is needed to debug crashes > >> that can happen at boot-time. For debugging purposes a large number of > >> registers need to be configured in DCC driver which is to be fed via the > >> bootconfig file. For that we need to expand the nodes as well as memory > >> for using bootconfig. > > > > Hmm, how many registers does DCC usually use? And how big the bootconfig > > file is usually? I have no idea about that. > > So a typical bootconfig file for consumption of DCC looks like as follows > > dcc_config { > link_list_0 { > qcom-curr-link-list = 6 > qcom-link-list = R_0x1781005c_1_apb, > R_0x1782005c_1_apb > } > link_list_1 { > qcom-curr-link-list = 5 > qcom-link-list = R_0x1784005c_1_apb > } > } > > The "qcom-link-list" field can have 1000s of register , based on that > max nodes is increased to 8192. OK, then the number of fields can be larger than 1000. I got it. > > > > >> Can you let us know the changes that you suggest for doing the same? Is > >> it fine to just increase the XBC_NODE_MAX, do we also need to > >> change the uint16_t to u32 for proper storing of index values? > > > > Expanding the number of max nodes is easy, just increase the XBC_NODE_MAX > > (must be less than 64k). That will also increase the memory consumption > > during the boot time even if the bootconfig is small. Anyway, it will be > > freed after boot, so it maybe OK. > > So since the limit is 64K, 8192 is a valid value for max nodes. Yes. Expanding the number of node is OK to me. > > > > > But expanding the size of max bootconfig needs to change the type of > > the 'data' field to uint32_t (since that will be used for building > > bootconfig tool) and you also must confirm that `tools/bootconfig/bootconfig` > > can be built and pass the test-bootconfig.sh. > > Hmm, comparing with expanding the max number of XBC node, changing the > > 'data' type to uint32_t may not have much impact on memory consumption point > > of view, because it may increase only 20% of memory, but expanding the > > MAX_XBC_NODE always increases more than double. > > > > Thus, if we can accept increasing the number of node, it should be OK to > > change the 'data' type. > > That means from DCC point of view only increasing the max nodes is > enough as increasing the data size is unrelated to increasing the max nodes? Yes, if it is less than 32KB, you just need to increase the XBC_NODE_MAX. But if you think the size of bootconfig, we have to change the type of xbc_node::data field. Can you check the DCC also need to expand the size of bootconfig limitation? Thank you! > > > > > BTW, I think now we don't need the ' __attribute__ ((__packed__))' for > > struct xbc_node. It was packed for reducing the size of array and able to > > pass 'compiled' bootconfig, but now it is just passed as a text data for > > safety. > > > > > Thank you, > > > >> > >> > >>> > >>>> > >>>> Signed-off-by: Souradeep Chowdhury <quic_schowdhu@quicinc.com> > >>>> --- > >>>> include/linux/bootconfig.h | 6 +++--- > >>>> 1 file changed, 3 insertions(+), 3 deletions(-) > >>>> > >>>> diff --git a/include/linux/bootconfig.h b/include/linux/bootconfig.h > >>>> index 1611f9d..64d233b 100644 > >>>> --- a/include/linux/bootconfig.h > >>>> +++ b/include/linux/bootconfig.h > >>>> @@ -55,11 +55,11 @@ struct xbc_node { > >>>> } __attribute__ ((__packed__)); > >>>> > >>>> #define XBC_KEY 0 > >>>> -#define XBC_VALUE (1 << 15) > >>>> -/* Maximum size of boot config is 32KB - 1 */ > >>>> +#define XBC_VALUE (1 << 18) > >>>> +/* Maximum size of boot config is 256KB - 1 */ > >>>> #define XBC_DATA_MAX (XBC_VALUE - 1) > >>>> > >>>> -#define XBC_NODE_MAX 1024 > >>>> +#define XBC_NODE_MAX 8192 > >>>> #define XBC_KEYLEN_MAX 256 > >>>> #define XBC_DEPTH_MAX 16 > >>>> > >>>> -- > >>>> 2.7.4 > >>>> > >>> > >>> > > > >
On 1/12/2023 12:31 PM, Masami Hiramatsu (Google) wrote: > On Tue, 10 Jan 2023 20:38:54 +0530 > Souradeep Chowdhury <quic_schowdhu@quicinc.com> wrote: > >> >> >> On 1/10/2023 8:16 PM, Masami Hiramatsu (Google) wrote: >>> On Tue, 10 Jan 2023 17:26:07 +0530 >>> Souradeep Chowdhury <quic_schowdhu@quicinc.com> wrote: >>> >>>> >>>> >>>> On 1/9/2023 8:48 PM, Masami Hiramatsu (Google) wrote: >>>>> On Mon, 9 Jan 2023 20:01:05 +0530 >>>>> Souradeep Chowdhury <quic_schowdhu@quicinc.com> wrote: >>>>> >>>>>> Increasing the memory size of bootconfig to be able to handle a max number of >>>>>> 8192 nodes to be fitted in memory size of 256KB. >>>>> >>>>> Sorry, but you missed the 'xbc_node::data' stores the index of the data and >>>>> that is uint16_t. So the XBC_DATA_MAX is fixed limitation. >>>>> >>>>> The number of nodes (XBC_NODE_MAX) can be expanded because I just decided it >>>>> to keep the pre-compiled array size ~8KB. Maybe expanding it to 64KB just >>>>> increase the size of kernel on init memory (and freed after boot). >>>>> >>>>> Could you tell me why you need such a big data for your DCC? >>>>> >>>>> Thank you, >>>> >>>> DCC is a debugging tool used in qcom which is needed to debug crashes >>>> that can happen at boot-time. For debugging purposes a large number of >>>> registers need to be configured in DCC driver which is to be fed via the >>>> bootconfig file. For that we need to expand the nodes as well as memory >>>> for using bootconfig. >>> >>> Hmm, how many registers does DCC usually use? And how big the bootconfig >>> file is usually? I have no idea about that. >> >> So a typical bootconfig file for consumption of DCC looks like as follows >> >> dcc_config { >> link_list_0 { >> qcom-curr-link-list = 6 >> qcom-link-list = R_0x1781005c_1_apb, >> R_0x1782005c_1_apb >> } >> link_list_1 { >> qcom-curr-link-list = 5 >> qcom-link-list = R_0x1784005c_1_apb >> } >> } >> >> The "qcom-link-list" field can have 1000s of register , based on that >> max nodes is increased to 8192. > > OK, then the number of fields can be larger than 1000. I got it. > >> >>> >>>> Can you let us know the changes that you suggest for doing the same? Is >>>> it fine to just increase the XBC_NODE_MAX, do we also need to >>>> change the uint16_t to u32 for proper storing of index values? >>> >>> Expanding the number of max nodes is easy, just increase the XBC_NODE_MAX >>> (must be less than 64k). That will also increase the memory consumption >>> during the boot time even if the bootconfig is small. Anyway, it will be >>> freed after boot, so it maybe OK. >> >> So since the limit is 64K, 8192 is a valid value for max nodes. > > Yes. Expanding the number of node is OK to me. > >> >>> >>> But expanding the size of max bootconfig needs to change the type of >>> the 'data' field to uint32_t (since that will be used for building >>> bootconfig tool) and you also must confirm that `tools/bootconfig/bootconfig` >>> can be built and pass the test-bootconfig.sh. >>> Hmm, comparing with expanding the max number of XBC node, changing the >>> 'data' type to uint32_t may not have much impact on memory consumption point >>> of view, because it may increase only 20% of memory, but expanding the >>> MAX_XBC_NODE always increases more than double. >>> >>> Thus, if we can accept increasing the number of node, it should be OK to >>> change the 'data' type. >> >> That means from DCC point of view only increasing the max nodes is >> enough as increasing the data size is unrelated to increasing the max nodes? > > Yes, if it is less than 32KB, you just need to increase the XBC_NODE_MAX. > But if you think the size of bootconfig, we have to change the type of > xbc_node::data field. > > Can you check the DCC also need to expand the size of bootconfig limitation? > > Thank you! Yes, I don't think the index needs to be increased from u16 to u32 for dcc. Will be sending out the next version accordingly. Thanks > >> >>> >>> BTW, I think now we don't need the ' __attribute__ ((__packed__))' for >>> struct xbc_node. It was packed for reducing the size of array and able to >>> pass 'compiled' bootconfig, but now it is just passed as a text data for >>> safety. >> >>> >>> Thank you, >>> >>>> >>>> >>>>> >>>>>> >>>>>> Signed-off-by: Souradeep Chowdhury <quic_schowdhu@quicinc.com> >>>>>> --- >>>>>> include/linux/bootconfig.h | 6 +++--- >>>>>> 1 file changed, 3 insertions(+), 3 deletions(-) >>>>>> >>>>>> diff --git a/include/linux/bootconfig.h b/include/linux/bootconfig.h >>>>>> index 1611f9d..64d233b 100644 >>>>>> --- a/include/linux/bootconfig.h >>>>>> +++ b/include/linux/bootconfig.h >>>>>> @@ -55,11 +55,11 @@ struct xbc_node { >>>>>> } __attribute__ ((__packed__)); >>>>>> >>>>>> #define XBC_KEY 0 >>>>>> -#define XBC_VALUE (1 << 15) >>>>>> -/* Maximum size of boot config is 32KB - 1 */ >>>>>> +#define XBC_VALUE (1 << 18) >>>>>> +/* Maximum size of boot config is 256KB - 1 */ >>>>>> #define XBC_DATA_MAX (XBC_VALUE - 1) >>>>>> >>>>>> -#define XBC_NODE_MAX 1024 >>>>>> +#define XBC_NODE_MAX 8192 >>>>>> #define XBC_KEYLEN_MAX 256 >>>>>> #define XBC_DEPTH_MAX 16 >>>>>> >>>>>> -- >>>>>> 2.7.4 >>>>>> >>>>> >>>>> >>> >>> > >
On Thu, 19 Jan 2023 22:21:27 +0530 Souradeep Chowdhury <quic_schowdhu@quicinc.com> wrote: > > > On 1/12/2023 12:31 PM, Masami Hiramatsu (Google) wrote: > > On Tue, 10 Jan 2023 20:38:54 +0530 > > Souradeep Chowdhury <quic_schowdhu@quicinc.com> wrote: > > > >> > >> > >> On 1/10/2023 8:16 PM, Masami Hiramatsu (Google) wrote: > >>> On Tue, 10 Jan 2023 17:26:07 +0530 > >>> Souradeep Chowdhury <quic_schowdhu@quicinc.com> wrote: > >>> > >>>> > >>>> > >>>> On 1/9/2023 8:48 PM, Masami Hiramatsu (Google) wrote: > >>>>> On Mon, 9 Jan 2023 20:01:05 +0530 > >>>>> Souradeep Chowdhury <quic_schowdhu@quicinc.com> wrote: > >>>>> > >>>>>> Increasing the memory size of bootconfig to be able to handle a max number of > >>>>>> 8192 nodes to be fitted in memory size of 256KB. > >>>>> > >>>>> Sorry, but you missed the 'xbc_node::data' stores the index of the data and > >>>>> that is uint16_t. So the XBC_DATA_MAX is fixed limitation. > >>>>> > >>>>> The number of nodes (XBC_NODE_MAX) can be expanded because I just decided it > >>>>> to keep the pre-compiled array size ~8KB. Maybe expanding it to 64KB just > >>>>> increase the size of kernel on init memory (and freed after boot). > >>>>> > >>>>> Could you tell me why you need such a big data for your DCC? > >>>>> > >>>>> Thank you, > >>>> > >>>> DCC is a debugging tool used in qcom which is needed to debug crashes > >>>> that can happen at boot-time. For debugging purposes a large number of > >>>> registers need to be configured in DCC driver which is to be fed via the > >>>> bootconfig file. For that we need to expand the nodes as well as memory > >>>> for using bootconfig. > >>> > >>> Hmm, how many registers does DCC usually use? And how big the bootconfig > >>> file is usually? I have no idea about that. > >> > >> So a typical bootconfig file for consumption of DCC looks like as follows > >> > >> dcc_config { > >> link_list_0 { > >> qcom-curr-link-list = 6 > >> qcom-link-list = R_0x1781005c_1_apb, > >> R_0x1782005c_1_apb > >> } > >> link_list_1 { > >> qcom-curr-link-list = 5 > >> qcom-link-list = R_0x1784005c_1_apb > >> } > >> } > >> > >> The "qcom-link-list" field can have 1000s of register , based on that > >> max nodes is increased to 8192. > > > > OK, then the number of fields can be larger than 1000. I got it. > > > >> > >>> > >>>> Can you let us know the changes that you suggest for doing the same? Is > >>>> it fine to just increase the XBC_NODE_MAX, do we also need to > >>>> change the uint16_t to u32 for proper storing of index values? > >>> > >>> Expanding the number of max nodes is easy, just increase the XBC_NODE_MAX > >>> (must be less than 64k). That will also increase the memory consumption > >>> during the boot time even if the bootconfig is small. Anyway, it will be > >>> freed after boot, so it maybe OK. > >> > >> So since the limit is 64K, 8192 is a valid value for max nodes. > > > > Yes. Expanding the number of node is OK to me. > > > >> > >>> > >>> But expanding the size of max bootconfig needs to change the type of > >>> the 'data' field to uint32_t (since that will be used for building > >>> bootconfig tool) and you also must confirm that `tools/bootconfig/bootconfig` > >>> can be built and pass the test-bootconfig.sh. > >>> Hmm, comparing with expanding the max number of XBC node, changing the > >>> 'data' type to uint32_t may not have much impact on memory consumption point > >>> of view, because it may increase only 20% of memory, but expanding the > >>> MAX_XBC_NODE always increases more than double. > >>> > >>> Thus, if we can accept increasing the number of node, it should be OK to > >>> change the 'data' type. > >> > >> That means from DCC point of view only increasing the max nodes is > >> enough as increasing the data size is unrelated to increasing the max nodes? > > > > Yes, if it is less than 32KB, you just need to increase the XBC_NODE_MAX. > > But if you think the size of bootconfig, we have to change the type of > > xbc_node::data field. > > > > Can you check the DCC also need to expand the size of bootconfig limitation? > > > > Thank you! > > Yes, I don't think the index needs to be increased from u16 to u32 for > dcc. Will be sending out the next version accordingly. OK, thanks for the confirmation!
diff --git a/include/linux/bootconfig.h b/include/linux/bootconfig.h index 1611f9d..64d233b 100644 --- a/include/linux/bootconfig.h +++ b/include/linux/bootconfig.h @@ -55,11 +55,11 @@ struct xbc_node { } __attribute__ ((__packed__)); #define XBC_KEY 0 -#define XBC_VALUE (1 << 15) -/* Maximum size of boot config is 32KB - 1 */ +#define XBC_VALUE (1 << 18) +/* Maximum size of boot config is 256KB - 1 */ #define XBC_DATA_MAX (XBC_VALUE - 1) -#define XBC_NODE_MAX 1024 +#define XBC_NODE_MAX 8192 #define XBC_KEYLEN_MAX 256 #define XBC_DEPTH_MAX 16