[PATCH linux dev-4.7] arm: configs: aspeed: Disable CONFIG_MTD_SPI_NOR_USE_4K_SECTORS

[Adriana Kobylak]

> On May 16, 2017, at 8:48 PM, Lei YU <mine260309 at gmail.com> wrote:
> 
> On Tue, May 16, 2017 at 9:59 PM, Cédric Le Goater <clg at kaod.org <mailto:clg at kaod.org>> wrote:
>> On 05/16/2017 03:30 PM, Adriana Kobylak wrote:
>>> 
>>>> On May 16, 2017, at 1:01 AM, Cédric Le Goater <clg at kaod.org <mailto:clg at kaod.org>> wrote:
>>>> 
>>>> On 05/15/2017 02:41 AM, Adriana Kobylak wrote:
>>>>> 
>>>>>> On May 13, 2017, at 3:49 PM, Cédric Le Goater <clg at kaod.org <mailto:clg at kaod.org>> wrote:
>>>>>> 
>>>>>> On 05/11/2017 02:12 PM, Joel Stanley wrote:
>>>>>>> On Thu, May 11, 2017 at 7:31 AM, Adriana Kobylak
>>>>>>> <anoo at linux.vnet.ibm.com <mailto:anoo at linux.vnet.ibm.com>> wrote:
>>>>>>>> Milton stopped by and mentioned that you had tried to modify the 4K erase
>>>>>>>> sector previously for a perhaps bmc chip and saw some flash corruption when
>>>>>>>> moving to an image that changed it?
>>>>>>>> 
>>>>>>>> Just wanted to add that this change only changes the pnor setting and I
>>>>>>>> didn’t see any issues powering on a system after updating the BMC with an
>>>>>>>> image with this change. Then I updated the pnor with an image that had the
>>>>>>>> mbox enabled. Also checked with AndrewJ and the hostboot team and there’s no
>>>>>>>> hard-coded assumptions in their side about the erase size.
>>>>>>>> 
>>>>>>>> With all this info let me know if you have any thoughts or concerns.
>>>>>>> 
>>>>>>> I recall issues relating to this option. I didn't record what they were
>>>>>>> though.
>>>>>> 
>>>>>> We tried to activate 4K erase on some chips, which supported it,
>>>>>> and that the OpenPOWER systems use. That was because the PNOR
>>>>>> sections were not aligned with the erase size and that caused
>>>>>> some issues in pflash. But it breaks the compatibility with
>>>>>> previously created jffs2 filesystems. jffs2 stores the erase
>>>>>> size. So we stepped back.
>>>>>> 
>>>>>>> Cedric, can you remind me what the issues are with the 4K kconfig option?
>>>>>> 
>>>>>> CONFIG_MTD_SPI_NOR_USE_4K_SECTORS enables the 4K erase commands,
>>>>>> and without it, the driver will use the sector erase command, most
>>>>>> likely 64K. I suppose we could have the same problem as described
>>>>>> above, as it can change the default erase size of a chip. to be
>>>>>> checked.
> 
> The same question as Cedric, PNOR has sections that are not 64K
> aligned but 4K aligned,
> e.g. HBEL, GARD:
> ID=02            HBEL 000a0000..000c4000 (actual=00024000) [ECC]
> ID=03           GUARD 000d0000..000d5000 (actual=00005000) [ECC]
> 
> When using gard tool to clear GARD partition, it will fail if erasing
> size is 64K.
> 
> Do we have a plan to support this case?

Thanks Lei for providing this info. For the proposed openbmc implementation, it’d work since the pnor sections (or partitions) would be files located in a ubi volume, and their data loaded into memory (virtual pnor) for the host to access, so erasing GUARD for example would underneath the covers modify the GUARD.bin file and not a specific offset in the physical pnor chip.

But that raises the question about openpower systems that are not running openbmc. Should disabling 4k be an openbmc only patch?

> 
>>>>>> 
>>>>> Thanks Cedric for the info. It appears there are no issues when
>>>>> disabling the 4K sectors for the pnor chip (yes, the erase size
>>>>> is then 64K), probably because the pnor is not formatted with
>>>>> a jffs2 filesystem. We might need to clear the pnor chip anyways
>>>>> to be able to format it as a UBI volume. So would you say we’re
>>>>> ok with this patch?
>>>> 
>>>> Well, what if the BMC is using a flash module with a 4K erase size ?
>>> 
>>> All the mtd devices except PNOR in the P8 and P9 systems running openbmc
>>> have already an erase size of 64K.
>> 
>> So everything is fine for these.
>> 
>> Cheers,
>> 
>> C.
>> 
>> 
>>> Ex witherspoon:
>>> root at witherspoon:~# cat /proc/mtd
>>> dev:    size   erasesize  name
>>> mtd0: 02000000 00010000 "bmc"
>>> mtd1: 00060000 00010000 "u-boot"
>>> mtd2: 00020000 00010000 "u-boot-env"
>>> mtd3: 00440000 00010000 "kernel"
>>> mtd4: 01740000 00010000 "rofs"
>>> mtd5: 00400000 00010000 "rwfs"
>>> mtd6: 02000000 00010000 "alt"
>>> mtd7: 08000000 00001000 “pnor”
>>> 
>>> Ex barreleye:
>>> root at barreleye:~# cat /proc/mtd
>>> dev:    size   erasesize  name
>>> mtd0: 02000000 00010000 "bmc"
>>> mtd1: 00060000 00010000 "u-boot"
>>> mtd2: 00020000 00010000 "u-boot-env"
>>> mtd3: 00440000 00010000 "kernel"
>>> mtd4: 01740000 00010000 "rofs"
>>> mtd5: 00400000 00010000 "rwfs"
>>> mtd6: 04000000 00001000 "pnor"
>>> 
>>>> 
>>>> C.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20170517/edb93935/attachment-0001.html>