linux-kernel - Re: [PATCH] arm64: dts: ti: k3-am69-sk: Update OSPI partitions offsets

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20240902060120.n2qj2zkbd6vakoha@uda0496754>
Date: Mon, 2 Sep 2024 11:31:20 +0530
From: Prasanth Mantena <p-mantena@...com>
To: Beleswar Prasad Padhi <b-padhi@...com>
CC: Nishanth Menon <nm@...com>, <vigneshr@...com>, <kristo@...nel.org>,
        <robh@...nel.org>, <krzk+dt@...nel.org>, <conor+dt@...nel.org>,
        <u-kumar1@...com>, <devicetree@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH] arm64: dts: ti: k3-am69-sk: Update OSPI partitions
 offsets

On 20:38-20240830, Beleswar Prasad Padhi wrote:
> 
> On 30-08-2024 14:52, Nishanth Menon wrote:
> > On 14:37-20240830, Beleswar Padhi wrote:
> > > OSPI NOR flash was partitioned with a size of 1 MB for the initial
> > > bootloader ("ospi.tiboot3"). On the AM69-SK board, boot failures were
> > > sometimes observed when the initial bootloader size exceeded 512 KB. To
> > Why does the boot fail when > 512MB?
> 
> 
> It is a limitation by BOOT ROM where it can not bring up the initial
> bootloader when its size exceeds 512 KB in the DFU boot mode.
> 
> > 
> > > address this, the initial bootloader image has been optimized to be
> > > smaller than 512 KB.
> > > 
> > > Therefore, limit the first OSPI partition size to 512 KB and adjust the
> > > remaining size across the subsequent partitions.
> > I am NOT a fan of redoing flash partition organization of platforms that
> > are already in production - all kinds of ecosystem messes happen as a
> > result. Alternatively - give the 512K to u-boot tispl partition and
> > leave all others as is - this will at least allow people's current env
> > to be retained.
> 
> 
> This sounds good to me. I will let Prasanth comment over this.
> 

We can align things in u-boot level rather than changing anything here.
This patch can be dropped Beleswar.

> > 
> > > Signed-off-by: Beleswar Padhi <b-padhi@...com>
> > > ---
> > >   arch/arm64/boot/dts/ti/k3-am69-sk.dts | 18 +++++++++---------
> > >   1 file changed, 9 insertions(+), 9 deletions(-)
> > > 
> > > diff --git a/arch/arm64/boot/dts/ti/k3-am69-sk.dts b/arch/arm64/boot/dts/ti/k3-am69-sk.dts
> > > index 1e36965a1403..641236918379 100644
> > > --- a/arch/arm64/boot/dts/ti/k3-am69-sk.dts
> > > +++ b/arch/arm64/boot/dts/ti/k3-am69-sk.dts
> > > @@ -1241,27 +1241,27 @@ partitions {
> > >   			partition@0 {
> > >   				label = "ospi.tiboot3";
> > > -				reg = <0x0 0x100000>;
> > > +				reg = <0x0 0x80000>;
> > >   			};
> > > -			partition@...000 {
> > > +			partition@...00 {
> > >   				label = "ospi.tispl";
> > > -				reg = <0x100000 0x200000>;
> > > +				reg = <0x80000 0x200000>;
> > >   			};
> > > -			partition@...000 {
> > > +			partition@...000 {
> > >   				label = "ospi.u-boot";
> > > -				reg = <0x300000 0x400000>;
> > > +				reg = <0x280000 0x400000>;
> > >   			};
> > > -			partition@...000 {
> > > +			partition@...000 {
> > >   				label = "ospi.env";
> > > -				reg = <0x700000 0x40000>;
> > > +				reg = <0x680000 0x40000>;
> > >   			};
> > > -			partition@...000 {
> > > +			partition@...000 {
> > >   				label = "ospi.env.backup";
> > > -				reg = <0x740000 0x40000>;
> > > +				reg = <0x6c0000 0x40000>;
> > >   			};
> > >   			partition@...000 {
> > > -- 
> > > 2.34.1
> > >