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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <451abe2a-7568-43c7-8483-242a9919684d@ti.com>
Date: Fri, 30 Aug 2024 20:38:39 +0530
From: Beleswar Prasad Padhi <b-padhi@...com>
To: Nishanth Menon <nm@...com>
CC: <vigneshr@...com>, <kristo@...nel.org>, <robh@...nel.org>,
        <krzk+dt@...nel.org>, <conor+dt@...nel.org>, <u-kumar1@...com>,
        <p-mantena@...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 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.

>
>> 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
>>