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

[Adriana Kobylak]

> On May 17, 2017, at 10:43 AM, Adriana Kobylak <anoo at linux.vnet.ibm.com> wrote:
> 
>> 
>> On May 16, 2017, at 8:48 PM, Lei YU <mine260309 at gmail.com <mailto: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> <mailto: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> <mailto: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> <mailto: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?

Maybe Andrew can comment? It’s my understanding that the mbox daemon v2 would support any erase size, but if there’s an issue with alignment when using something other than 4k, maybe the daemon would need to abstract the chip erase size and set to 4k as the v1 does.

> 
> 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/20170519/5f21582f/attachment.html>