[PATCH v2] misc: fs_loader: Add QSPI RAW partition loading support

[Ravulapalli, Naresh Kumar]

Hi Marek

On 21-Aug-25 2:31 PM, Marek Vasut wrote:
> 
> On 8/21/25 8:26 AM, Ravulapalli, Naresh Kumar wrote:
>>
>> Hi Marek
>>
>> On 21-Aug-25 1:49 AM, Marek Vasut wrote:
>>>
>>> On 8/20/25 1:35 PM, Ravulapalli, Naresh Kumar wrote:
>>>> Hi Marek
>>>>
>>>> On 20-Aug-25 4:56 PM, Marek Vasut wrote:
>>>>>
>>>>> On 8/20/25 1:20 PM, Ravulapalli, Naresh Kumar wrote:
>>>>>> Hi Marek
>>>>>>
>>>>>> On 20-Aug-25 2:27 PM, Marek Vasut wrote:
>>>>>>>
>>>>>>> On 8/20/25 9:53 AM, Naresh Kumar Ravulapalli wrote:
>>>>>>>> Enhanced the generic firmware loader to support QSPI RAW partition
>>>>>>>> loading. This would enable FPGA configuration bitstream loading
>>>>>>>> from QSPI RAW partition to program FPGA.
>>>>>>>>
>>>>>>>> Signed-off-by: Tien Fong Chee <tien.fong.chee at altera.com>
>>>>>>>> Signed-off-by: Naresh Kumar Ravulapalli
>>>>>>>> <nareshkumar.ravulapalli at altera.com>
>>>>>>>
>>>>>>> Why not load from UBI on SPI NOR ?
>>>>>>
>>>>>> It is to avoid the storage overhead for metadata and management
>>>>>> for devices with flash constraints.
>>>>>
>>>>> What about data integrity , iirc UBI gives you built-in checksums.
>>>>>
>>>>
>>>> Agree, UBI supports bad block management and other advantages. But
>>>> the objective here is to support RAW partition for flash constraint
>>>> devices.
>>> How is integrity of the data in flash handled in this case ?
>>
>> RAW partition support and required data integrity handling is user
>> specific. In our case, we are storing CRC32 checksum in flash and
>> computing the checksum on raw data during run time and cross-checking
>> the values.
> 
> How big is the file ? crc32 is weak . Why not use e.g. fitImage for this ?
> 
> If this raw loading should be available to users, it should come with a
> BIG WARNING about data integrity.

User can use CRC32 and if they require SHA256/512, they can use that as 
well or any other algorithm as desired.

RAW partition support is helpful for flash constraint devices especially 
in a use case where we need to store data as RAW during run-time and if 
data integrity is required, user has the flexibility to choose 
respective algorithms like CRC/SHA etc. The whole objective of this 
patch is to provide that flexibility to the user.

I don't think we need the BIG WARNING, as RAW data by definition will 
not have any built-in integrity features and users should exercise 
caution if data integrity is required. It is mentioned in the enum 
definition that choosing "DATA_RAW" flag will store data as RAW.

Kind Regards
Naresh