support for non-uniform SPI NOR flash memories

support for non-uniform SPI NOR flash memories

[Tudor Ambarus]

Hi, Marek, all,

I'm studying Cyrille's patch for non-uniform SPI NOR flash memories:
https://lkml.org/lkml/2017/4/15/70.

It's not clear to me whether interleaved regions are possible or not. I
read the JEDEC Standard No. 216B and it looks like each region is well
delimited, there is no such thing as interleaved regions (see section
6.5):

"When there is more than one sector size in a device, each contiguous
group of sectors, that are of the same size, and support the same erase
types, is called a region."

If interleaved regions are not possible, the code can be simplified. Do
I miss something, is there anything else that I should read in this
regard?

Apart of how we represent the regions, there is some improvement that we
can do. When in a region, I see that is preferred the biggest possible
erase type that meets all the conditions. If so, we can iterate from the
biggest erase type to the smallest, and when find one that meets all the
conditions, break the loop.

Thanks,
ta

Re: support for non-uniform SPI NOR flash memories

[Marek Vasut]

On 05/07/2018 07:11 PM, Tudor Ambarus wrote:
> Hi, Marek, all,
> 
> I'm studying Cyrille's patch for non-uniform SPI NOR flash memories:
> https://lkml.org/lkml/2017/4/15/70.
> 
> It's not clear to me whether interleaved regions are possible or not. I
> read the JEDEC Standard No. 216B and it looks like each region is well
> delimited, there is no such thing as interleaved regions (see section
> 6.5):
> 
> "When there is more than one sector size in a device, each contiguous
> group of sectors, that are of the same size, and support the same erase
> types, is called a region."
> 
> If interleaved regions are not possible, the code can be simplified. Do
> I miss something, is there anything else that I should read in this
> regard?
> 
> Apart of how we represent the regions, there is some improvement that we
> can do. When in a region, I see that is preferred the biggest possible
> erase type that meets all the conditions. If so, we can iterate from the
> biggest erase type to the smallest, and when find one that meets all the
> conditions, break the loop.

There are flashes which have larger erase blocks at the beginning/end
and then there are flashes with multiple dies, which support die-wide
erase and chip-wide erase . Not all flashes support everything though.

But indeed there are -- to my knowledge -- no flashes with interleaved
erase blocks. And yes, there could be improvement in erasing exactly the
required chunk of flash with a fitting opcode :)

-- 
Best regards,
Marek Vasut

Re: support for non-uniform SPI NOR flash memories

[Tudor Ambarus]

On 05/07/2018 08:14 PM, Marek Vasut wrote:
> But indeed there are -- to my knowledge -- no flashes with interleaved
> erase blocks. And yes, there could be improvement in erasing exactly the
> required chunk of flash with a fitting opcode:)

Thanks Marek.

Other improvement would be to minimize the amount of erase() calls by
using the best sequence of erase type commands depending on alignment.
But this will increase the number of queries.

I've read again the Sector Map section of the JEDECB standard and it
looks like "overlaid" regions are possible. Here's an example that I
found there:

Bottom: 8x 4KB sectors at bottom (only 4KB erase supported),
         1x overlaid 64KB sector at bottom (only 64KB erase supported),
         511 uniform 64KB sectors (only 64KB erase supported)

That's interesting, when one wants to erase the overlaid 64KB sector, I
guess that the 8x 4KB sectors will be erased too.

I'm still studying this, I'll try to come with a proposal in the next
few days.

Cheers,
ta

Re: support for non-uniform SPI NOR flash memories

[Marek Vasut]

On 05/09/2018 06:40 PM, Tudor Ambarus wrote:
> 
> On 05/07/2018 08:14 PM, Marek Vasut wrote:
>> But indeed there are -- to my knowledge -- no flashes with interleaved
>> erase blocks. And yes, there could be improvement in erasing exactly the
>> required chunk of flash with a fitting opcode:)
> 
> Thanks Marek.
> 
> Other improvement would be to minimize the amount of erase() calls by
> using the best sequence of erase type commands depending on alignment.
> But this will increase the number of queries.
> 
> I've read again the Sector Map section of the JEDECB standard and it
> looks like "overlaid" regions are possible. Here's an example that I
> found there:
> 
> Bottom: 8x 4KB sectors at bottom (only 4KB erase supported),
>         1x overlaid 64KB sector at bottom (only 64KB erase supported),
>         511 uniform 64KB sectors (only 64KB erase supported)
> 
> That's interesting, when one wants to erase the overlaid 64KB sector, I
> guess that the 8x 4KB sectors will be erased too.

Ah yes, some old flashes had these few 64 kiB erase blocks at the
beginning/end, which could either be erased as one 64 kiB block or as
smaller 8k/4k blocks .

> I'm still studying this, I'll try to come with a proposal in the next
> few days.

Cool!

-- 
Best regards,
Marek Vasut