| Message ID | 1493913487-7482-1-git-send-email-anoo@linux.vnet.ibm.com |
|---|---|
| State | Not Applicable, archived |
| Headers | show |
On Thu, May 11, 2017 at 7:31 AM, Adriana Kobylak <anoo@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. Cedric, can you remind me what the issues are with the 4K kconfig option? Cheers, Joel > > Thanks! > > > Begin forwarded message: > > From: Adriana Kobylak <anoo@linux.vnet.ibm.com> > Subject: [PATCH linux dev-4.7] arm: configs: aspeed: Disable > CONFIG_MTD_SPI_NOR_USE_4K_SECTORS > Date: May 4, 2017 at 10:58:07 AM CDT > To: openbmc@lists.ozlabs.org > Cc: Adriana Kobylak <anoo@linux.vnet.ibm.com> > > Disable the 4KB erase block size from the spi nor to be able to > use UBIFS, since UBIFS requires the erase size to be at least 15KB. > > Signed-off-by: Adriana Kobylak <anoo@linux.vnet.ibm.com> > --- > arch/arm/configs/aspeed_g4_defconfig | 1 + > arch/arm/configs/aspeed_g5_defconfig | 1 + > 2 files changed, 2 insertions(+) > > diff --git a/arch/arm/configs/aspeed_g4_defconfig > b/arch/arm/configs/aspeed_g4_defconfig > index 4350f67..6538993 100644 > --- a/arch/arm/configs/aspeed_g4_defconfig > +++ b/arch/arm/configs/aspeed_g4_defconfig > @@ -69,6 +69,7 @@ CONFIG_MTD=y > CONFIG_MTD_BLOCK=y > CONFIG_MTD_PARTITIONED_MASTER=y > CONFIG_MTD_SPI_NOR=y > +# CONFIG_MTD_SPI_NOR_USE_4K_SECTORS is not set > CONFIG_ASPEED_FLASH_SPI=y > CONFIG_MTD_UBI=y > CONFIG_MTD_UBI_FASTMAP=y > diff --git a/arch/arm/configs/aspeed_g5_defconfig > b/arch/arm/configs/aspeed_g5_defconfig > index b6b3ca0..7063949 100644 > --- a/arch/arm/configs/aspeed_g5_defconfig > +++ b/arch/arm/configs/aspeed_g5_defconfig > @@ -68,6 +68,7 @@ CONFIG_MTD=y > CONFIG_MTD_BLOCK=y > CONFIG_MTD_PARTITIONED_MASTER=y > CONFIG_MTD_SPI_NOR=y > +# CONFIG_MTD_SPI_NOR_USE_4K_SECTORS is not set > CONFIG_ASPEED_FLASH_SPI=y > CONFIG_MTD_UBI=y > CONFIG_MTD_UBI_FASTMAP=y > -- > 1.8.2.2 > >
On 05/11/2017 02:12 PM, Joel Stanley wrote: > On Thu, May 11, 2017 at 7:31 AM, Adriana Kobylak > <anoo@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. Cheers, C.
> On May 13, 2017, at 3:49 PM, Cédric Le Goater <clg@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@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. > 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? > Cheers, > > C. >
On 05/15/2017 02:41 AM, Adriana Kobylak wrote: > >> On May 13, 2017, at 3:49 PM, Cédric Le Goater <clg@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@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. >> > 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 ? C.
> On May 16, 2017, at 1:01 AM, Cédric Le Goater <clg@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@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@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. >>> >> 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. Ex witherspoon: root@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@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.
On 05/16/2017 03:30 PM, Adriana Kobylak wrote: > >> On May 16, 2017, at 1:01 AM, Cédric Le Goater <clg@kaod.org <mailto:clg@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@kaod.org <mailto:clg@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@linux.vnet.ibm.com <mailto:anoo@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. >>>> >>> 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@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@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. >
On Tue, May 16, 2017 at 9:59 PM, Cédric Le Goater <clg@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@kaod.org <mailto:clg@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@kaod.org <mailto:clg@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@linux.vnet.ibm.com <mailto:anoo@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 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@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@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. >> >
> On May 16, 2017, at 8:48 PM, Lei YU <mine260309@gmail.com> wrote: > > On Tue, May 16, 2017 at 9:59 PM, Cédric Le Goater <clg@kaod.org <mailto:clg@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@kaod.org <mailto:clg@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@kaod.org <mailto:clg@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@linux.vnet.ibm.com <mailto:anoo@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@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@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.
> On May 17, 2017, at 10:43 AM, Adriana Kobylak <anoo@linux.vnet.ibm.com> wrote: > >> >> On May 16, 2017, at 8:48 PM, Lei YU <mine260309@gmail.com <mailto:mine260309@gmail.com>> wrote: >> >> On Tue, May 16, 2017 at 9:59 PM, Cédric Le Goater <clg@kaod.org <mailto:clg@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@kaod.org <mailto:clg@kaod.org> <mailto:clg@kaod.org <mailto:clg@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@kaod.org <mailto:clg@kaod.org> <mailto:clg@kaod.org <mailto:clg@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@linux.vnet.ibm.com <mailto:anoo@linux.vnet.ibm.com> <mailto:anoo@linux.vnet.ibm.com <mailto:anoo@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@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@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.
diff --git a/arch/arm/configs/aspeed_g4_defconfig b/arch/arm/configs/aspeed_g4_defconfig index 4350f67..6538993 100644 --- a/arch/arm/configs/aspeed_g4_defconfig +++ b/arch/arm/configs/aspeed_g4_defconfig @@ -69,6 +69,7 @@ CONFIG_MTD=y CONFIG_MTD_BLOCK=y CONFIG_MTD_PARTITIONED_MASTER=y CONFIG_MTD_SPI_NOR=y +# CONFIG_MTD_SPI_NOR_USE_4K_SECTORS is not set CONFIG_ASPEED_FLASH_SPI=y CONFIG_MTD_UBI=y CONFIG_MTD_UBI_FASTMAP=y diff --git a/arch/arm/configs/aspeed_g5_defconfig b/arch/arm/configs/aspeed_g5_defconfig index b6b3ca0..7063949 100644 --- a/arch/arm/configs/aspeed_g5_defconfig +++ b/arch/arm/configs/aspeed_g5_defconfig @@ -68,6 +68,7 @@ CONFIG_MTD=y CONFIG_MTD_BLOCK=y CONFIG_MTD_PARTITIONED_MASTER=y CONFIG_MTD_SPI_NOR=y +# CONFIG_MTD_SPI_NOR_USE_4K_SECTORS is not set CONFIG_ASPEED_FLASH_SPI=y CONFIG_MTD_UBI=y CONFIG_MTD_UBI_FASTMAP=y
Disable the 4KB erase block size from the spi nor to be able to use UBIFS, since UBIFS requires the erase size to be at least 15KB. Signed-off-by: Adriana Kobylak <anoo@linux.vnet.ibm.com> --- arch/arm/configs/aspeed_g4_defconfig | 1 + arch/arm/configs/aspeed_g5_defconfig | 1 + 2 files changed, 2 insertions(+)