[U-Boot] [PATCH v2 5/5] cgtqmx6eval: Protect the manufacturing information in SPI NOR

Jagan Teki jteki at openedev.com
Wed Sep 23 10:15:34 CEST 2015


On 23 September 2015 at 01:27, Otavio Salvador
<otavio.salvador at ossystems.com.br> wrote:
> On Tue, Sep 22, 2015 at 4:11 PM, Jagan Teki <jteki at openedev.com> wrote:
>> On 12 September 2015 at 19:27, Otavio Salvador <otavio at ossystems.com.br> wrote:
>>> +static void spinor_protect(void)
>>> +{
>>> +       struct spi_flash *spi;
>>> +
>>> +       spi = spi_flash_probe(CONFIG_ENV_SPI_BUS, CONFIG_ENV_SPI_CS,
>>> +                             CONFIG_ENV_SPI_MAX_HZ, CONFIG_ENV_SPI_MODE);
>>> +       /*
>>> +        * Set BP2 BP1 BP0 to 001, so that the last 64 sectors
>>> +        * can be protected (0x3f0000 to 0x3fffff).
>>
>> The last sector (64*1024) area is being protected here, why? does this
>> specific to your board?
>> And also your taking an example of  (0x3f0000 to 0x3fffff) that means
>> the flash your using is 4MB is it? then this again becomes your board
>> specific? is it?
>
> Yes, the protected range is board specific. Congatec put some data in
> this area which are valuable and should not be erased. So we need to
> protect it.

Sorry, I didn't understand why protection range or bits are specific
to board, is it different in Congetc because the flash area being
protected by means of sector range which is obviously the flash
offset.

m25p32

BP2/BP1/BP0=protected sectors
000 = sector (none)
001 = sector (63)
010 = sector (63, 62)
....
111 = sector (all)

I understand your concept of protecting sectors once you find the BP2,
BP1 and BP0 bits on board and then you locked the particular sectors,
is it? it's totally reverse way that you're trying to do is it?

thanks!
-- 
Jagan | openedev.


More information about the U-Boot mailing list