From: Andrew Jeffery <andrew@codeconstruct.com.au>
To: Cooper Huang <cooper_huang@aspeedtech.com>,
Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Joel Stanley <joel@jms.id.au>,
Ryan Chen <ryan_chen@aspeedtech.com>,
Billy Tsai <billy_tsai@aspeedtech.com>
Cc: devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-aspeed@lists.ozlabs.org, linux-kernel@vger.kernel.org,
Chin-Ting Kuo <chin-ting_kuo@aspeedtech.com>
Subject: Re: [PATCH] arm64: dts: aspeed: Enlarge AST2700 EVB kernel partition to 12 MiB
Date: Tue, 03 Nov 2026 14:48:06 +1030 [thread overview]
Message-ID: <bc6e605a8c5bee59ad9bcbce5f4fe775c9c3324e.camel@codeconstruct.com.au> (raw)
In-Reply-To: <20261029-ast2700-evb-kernel-part-v1-1-e6f52742c575@aspeedtech.com>
Hi Cooper,
On Thu, 2026-10-29 at 15:25 +0800, Cooper Huang wrote:
> From: Chin-Ting Kuo <chin-ting_kuo@aspeedtech.com>
>
> The 128 MiB flash layout of the AST2700 EVB reserves 9 MiB for the
> kernel FIT image. A FIT image containing an LZMA-compressed kernel,
> the DTB and an initramfs is already close to that size, leaving little
> room for the kernel to grow.
>
> Grow the kernel partition to 12 MiB and take the 3 MiB from rofs,
Why 12MiB? Why only take 3MiB?
> which now starts at 0x1020000 and shrinks from 82.875 MiB to
> 79.875 MiB. rofs still ends at 0x6000000, so the u-boot, u-boot-env
> and rwfs partitions are unchanged.
>
> This is the same layout used by the OpenBMC images ASPEED provides
> for the EVB [1],
>
Why was what was sent upstream different to what you were doing
elsewhere in the software stack? It seems oddly incoherent.
> so the rofs partition described by the device tree
> also matches where those images place the filesystem.
>
> Link: https://github.com/AspeedTech-BMC/openbmc/blob/438e761ed38644b77ba704c984cb607649bf2724/meta-aspeed-sdk/meta-ast2700-sdk/conf/machine/ast2700-default.conf [1]
> Signed-off-by: Chin-Ting Kuo <chin-ting_kuo@aspeedtech.com>
> Signed-off-by: Cooper Huang <cooper_huang@aspeedtech.com>
> ---
> Notes:
> - "Already close to that size": with mainline at c339f4010dea
> (v7.3-17997), ASPEED's aspeed_g7_defconfig [2] and GCC 13.2, a FIT
A bit of a tangent, but GCC 13.2 is over 3 years old at this point.
Debian stable ships 14.2. Why such an old compiler?
> image with the LZMA-compressed kernel, ast2700-evb.dtb and the
> OpenBMC phosphor initramfs is about 8.99 MiB, less than 20 KiB
What are your measured sizes for the kernel vs the initramfs?
Is the initramfs content reasonable?
Andrew
> below 9 MiB (the exact size varies by a few KiB between builds).
> - Upstream OpenBMC's AST2700 machines use the static-norootfs layout
> (no rofs) and are unaffected; the rwfs offset does not change.
>
> [2] https://github.com/AspeedTech-BMC/linux/blob/76457d3afe2bd4022ca82dd9eb8fc48b84f0e9ab/arch/arm64/configs/aspeed_g7_defconfig
> ---
> arch/arm64/boot/dts/aspeed/aspeed-evb-flash-layout-128.dtsi | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/aspeed/aspeed-evb-flash-layout-128.dtsi b/arch/arm64/boot/dts/aspeed/aspeed-evb-flash-layout-128.dtsi
> index b54915f06efd..f54d53077538 100644
> --- a/arch/arm64/boot/dts/aspeed/aspeed-evb-flash-layout-128.dtsi
> +++ b/arch/arm64/boot/dts/aspeed/aspeed-evb-flash-layout-128.dtsi
> @@ -16,12 +16,12 @@ u-boot-env@400000 {
> };
>
> kernel@420000 {
> - reg = <0x420000 0x900000>; // 9MB
> + reg = <0x420000 0xc00000>; // 12MB
> label = "kernel";
> };
>
> - rofs@d20000 {
> - reg = <0xd20000 0x52E0000>; // 82.875MB
> + rofs@1020000 {
> + reg = <0x1020000 0x4fe0000>; // 79.875MB
> label = "rofs";
> };
>
>
> ---
> base-commit: cee9395acd8043be0644b25c34bfa86623f2b935
> change-id: 20261029-ast2700-evb-kernel-part-63b3c998ea6e
>
> Best regards,
prev parent reply other threads:[~2026-11-03 4:18 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-29 7:25 Cooper Huang
2026-11-03 4:18 ` Andrew Jeffery [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bc6e605a8c5bee59ad9bcbce5f4fe775c9c3324e.camel@codeconstruct.com.au \
--to=andrew@codeconstruct.com.au \
--cc=billy_tsai@aspeedtech.com \
--cc=chin-ting_kuo@aspeedtech.com \
--cc=conor+dt@kernel.org \
--cc=cooper_huang@aspeedtech.com \
--cc=devicetree@vger.kernel.org \
--cc=joel@jms.id.au \
--cc=krzk+dt@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-aspeed@lists.ozlabs.org \
--cc=linux-kernel@vger.kernel.org \
--cc=robh@kernel.org \
--cc=ryan_chen@aspeedtech.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®