mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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,

      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®