RTEMS | bsps/shared/dev/nor: Add SFDP and CFI parsers (!823)

Aaron Nyholm (@eagleirony) gitlab at rtems.org
Mon Nov 3 23:06:35 UTC 2025




Aaron Nyholm commented on a discussion on bsps/shared/dev/nor/config-parser.c: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/823#note_135631

 > +      return RTEMS_INVALID_ADDRESS;
 > +    }
 > +
 > +    if (data->SectorSize < (sector_base * 256UL)) {
 > +      data->NumSectors = num_sectors_sub + 1;
 > +      data->SectorSize = sector_base * 256UL;
 > +    }
 >    }
 > -  data->SectorSize = sector_base * 256UL;
 >  
 > -  data->DeviceSize = data->NumSectors * data->SectorSize;
 > +  if (num_regions == 1) {
 > +    /* Device size for at least s25fl512s is off by 1, calculate with sectors */
 > +    data->DeviceSize = data->NumSectors * data->SectorSize;
 > +  } else {
 > +    data->NumSectors = data->DeviceSize / data->SectorSize;

This is due to handling multiple regions. My change results in returning the largest sector size on the device. That is the size that the block erase command erases allowing drivers to use a uniform sector size. However this means that the sector count is not always correct for `num_regions > 1` as there may be a region with smaller sectors. For example the `S25FL128P_64K` chip I tested on has the following CFI table/regions
```
Total flash size: 0x1000000
Size    | Count
0x1000  | 32
0x10000 | 254
```
The sector count is wrong as we are treating the first region as part of the second. This works because the block erase command will erase 0x10000 bytes even in the smaller region. This code line brings the sector count inline with the size of the device. It allows for basic support of flash chips with multiple regions.

-- 
View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/823#note_135631
You're receiving this email because of your account on gitlab.rtems.org.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/bugs/attachments/20251103/aba115d6/attachment-0001.htm>


More information about the bugs mailing list