Re: [U-Boot] [PATCH v1 0/2] mtd: nand: omap: booting from NAND using u-boot
Hi Pekon, On Tue, Jan 28, 2014 at 07:42:09AM +, Pekon Gupta wrote: > >From: Brian Norris > > > >On Fri, Dec 13, 2013 at 02:42:56PM +0530, Pekon Gupta wrote: > >> As there were parallel set of patches running between u-boot and kernel. > > > >I don't know what patches you're talking about. > > > Following patch-sets touched ecc.layout while cleaning up OMAP NAND driver. > u-boot: http://lists.denx.de/pipermail/u-boot/2013-November/167551.html > kernel: > http://lists.infradead.org/pipermail/linux-mtd/2013-October/049414.html > > >> hence, some patch-sets caused regression for OMAP3x platforms when booting > > > >"Hence" is not the right word. The previous sentence doesn't imply that > >there were regressions. > > > >> using u-boot specifically for ecc-schemes (like BCH4_SW). > > > >Huh? What does "specifically for ecc-schemes" mean? You mean that only > >some schemes had regressions? Can you be more specific? What are these > >regressions? > > > It was reported by Enric Balletbo Serra [2] that > when using 'OMAP_ECC_BCH8_CODE_HW_DETECTION_SW' ecc-scheme > there was a mismatch in ECC layout between mainline u-boot and kernel. > This caused boot failure when kernel tried to mount UBIFS with image > flashed from u-boot. > > This was missed while testing earlier patch-sets because only OMAP3 boards > use above ecc-scheme as OMAP3 SoC do not have ELM hardware engine. > All the later platforms use 'OMAP_ECC_BCH8_CODE_HW' ecc-scheme. > Both ecc-scheme are based on same algorithm of BCH8 ECC code except that: > (1) 'OMAP_ECC_BCH8_CODE_HW_DETECTION_SW' uses /lib/bch.c software > library for ecc-correction. > (2) 'OMAP_ECC_BCH8_CODE_HW' uses ELM hardware engine for ecc-correction. > > This regression affects following ecc-schemes, as ecc.layout logic is just > copy-paste of each-other. > - 'OMAP_ECC_BCH4_CODE_HW_DETECTION_SW' and > - 'OMAP_ECC_BCH8_CODE_HW_DETECTION_SW' OK > >The rest of this cover letter (and most of the patch descriptions) > >describes the configurations and testing (which is all very good, don't > >get me wrong), with a lot of focus on things I don't follow (namely, > >U-Boot), but you omit many of the important details, like > > > > * What is the regression? I honestly don't see a description of the > > actual regression. (I can read the code to intuit that, but what's > > the point of your pages of description if it doesn't mention this?) > > Please give some logical description of the problem > > > [Patch 1/2] of this series actually simplification of > 'ecclayout->oobfree->offset' > It does not fix the regression, but it's important to clean it, before any new > feature additions. By my reading, it is actually wrong, and therefore not just a clean up. Can you address my comment there about your indexing into the eccpos[] array? Did you actually check (e.g., print out) the resulting ecclayout before and after your cleanup to make sure it's exactly the same? I'm looking at the oobfree[] values, which looked wrong to me. > [Patch 2/2] Actually fixes the regression for affected ecc-schemes. But > "this patch also touches other ecc-schemes as the fix required > refactoring common code, into ecc-scheme specific code." > > > > * What are the effects of the regression? ECC bytes in the wrong place, > > so you see correction failures/corruption? JFFS2 failures? (The > > "oobfree" changes, for instance, should only affect something like > > JFFS2.) > > > As mentioned above [PATCH 1/2] which touches 'ecclayout->oobfree->offset' > is a clean-up not affecting regression, but it should be taken in before > any further feature or ecc-scheme changes. That's fine; a fixup patch can come just before a bugfix, if that helps simplify the bufix. > Now, what is your preference? > (a) Take [PATCH 1/2] ecc.layout clean-up separately. > (b) Take ecc.layout as part of this series, but may be with different patch > title. I think we'll keep these patches together, but they both need to have better descriptions to tell what's actually going on. > > * What Linux commit caused the regression? > > * Should this patch set be marked for -stable? And for what kernel > > release? (the previous question would help answer this) > > > This regression was caused in > commit b491da7233d5dc1a24d46ca1ad0209900329c5d0 >mtd: nand: omap: clean-up ecc layout for BCH ecc schemes > So, this should be applicable from 3.13.x+ > > > >> Hence this patch series fixes those regressions, and tests complete > >[...] snip > > > >I'm preparing a 3.14 pull request soon, and since you seem committed to > >fixing and properly testing a known regression here, I'd like to see > >this go in. But given the late timing and the unanswered questions, I > >think it's unlikely to go in -rc1. Perhaps I can send a later pull > >request if we can get it together properly. > > > Yes, if the above details are sufficient, then I'll: > (1) re-word [PATCH 1/2] commit log & title to mention that it's a clean-up > (2
Re: [U-Boot] [PATCH v1 0/2] mtd: nand: omap: booting from NAND using u-boot
Hi Brian, >From: Gupta, Pekon >>I'm preparing a 3.14 pull request soon, and since you seem committed to >>fixing and properly testing a known regression here, I'd like to see >>this go in. But given the late timing and the unanswered questions, I >>think it's unlikely to go in -rc1. Perhaps I can send a later pull >>request if we can get it together properly. >> >Yes, if the above details are sufficient, then I'll: >(1) re-word [PATCH 1/2] commit log & title to mention that it's a clean-up >(2) Add above description and details of regression into commit log of [PATCH >2/2] >(3) Include your other comments on individual patches. > > >>So I'd like to first of all get a few answers to my questions, and then >>I think we might want to refresh this patch series with a little better >>commit messages and perhaps a separate documentation file (not >>necessarily in the same patch series, as the fix is more urgent). >> Do my previous responses look complete to you for re-submission ? with regards, pekon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v1 0/2] mtd: nand: omap: booting from NAND using u-boot
Hi Brian, >From: Brian Norris > >Hi Pekon, > >Sorry, I'm revisiting your patch series a bit late. There are a few >factors that contributed to this, though. > >1. This patch series talks extensively about U-Boot. U-Boot is not my > interest, nor should it be the focus of kernel (driver) development. > Any work done here should be framed in the kernel driver context. [1] > >2. You have previously CC'd me on U-Boot patches. Or at least, I think > so. More about this in the next point... > >3. The U-Boot source code structure is rather similar to pieces of Linux > subsystems. So without additional effort, it is hard to discern > whether a patch is intended for Linux MTD or U-Boot MTD. > >4. You cross-posted to both the U-Boot and Linux-MTD mailing lists. > >So the sum of all this is that I ignored these patches at first, as they >weren't clearly intended for me. > >On Fri, Dec 13, 2013 at 02:42:56PM +0530, Pekon Gupta wrote: >> As there were parallel set of patches running between u-boot and kernel. > >I don't know what patches you're talking about. > Following patch-sets touched ecc.layout while cleaning up OMAP NAND driver. u-boot: http://lists.denx.de/pipermail/u-boot/2013-November/167551.html kernel: http://lists.infradead.org/pipermail/linux-mtd/2013-October/049414.html >> hence, some patch-sets caused regression for OMAP3x platforms when booting > >"Hence" is not the right word. The previous sentence doesn't imply that >there were regressions. > >> using u-boot specifically for ecc-schemes (like BCH4_SW). > >Huh? What does "specifically for ecc-schemes" mean? You mean that only >some schemes had regressions? Can you be more specific? What are these >regressions? > It was reported by Enric Balletbo Serra [2] that when using 'OMAP_ECC_BCH8_CODE_HW_DETECTION_SW' ecc-scheme there was a mismatch in ECC layout between mainline u-boot and kernel. This caused boot failure when kernel tried to mount UBIFS with image flashed from u-boot. This was missed while testing earlier patch-sets because only OMAP3 boards use above ecc-scheme as OMAP3 SoC do not have ELM hardware engine. All the later platforms use 'OMAP_ECC_BCH8_CODE_HW' ecc-scheme. Both ecc-scheme are based on same algorithm of BCH8 ECC code except that: (1) 'OMAP_ECC_BCH8_CODE_HW_DETECTION_SW' uses /lib/bch.c software library for ecc-correction. (2) 'OMAP_ECC_BCH8_CODE_HW' uses ELM hardware engine for ecc-correction. This regression affects following ecc-schemes, as ecc.layout logic is just copy-paste of each-other. - 'OMAP_ECC_BCH4_CODE_HW_DETECTION_SW' and - 'OMAP_ECC_BCH8_CODE_HW_DETECTION_SW' >The rest of this cover letter (and most of the patch descriptions) >describes the configurations and testing (which is all very good, don't >get me wrong), with a lot of focus on things I don't follow (namely, >U-Boot), but you omit many of the important details, like > > * What is the regression? I honestly don't see a description of the > actual regression. (I can read the code to intuit that, but what's > the point of your pages of description if it doesn't mention this?) > Please give some logical description of the problem > [Patch 1/2] of this series actually simplification of 'ecclayout->oobfree->offset' It does not fix the regression, but it's important to clean it, before any new feature additions. [Patch 2/2] Actually fixes the regression for affected ecc-schemes. But "this patch also touches other ecc-schemes as the fix required refactoring common code, into ecc-scheme specific code." > * What are the effects of the regression? ECC bytes in the wrong place, > so you see correction failures/corruption? JFFS2 failures? (The > "oobfree" changes, for instance, should only affect something like > JFFS2.) > As mentioned above [PATCH 1/2] which touches 'ecclayout->oobfree->offset' is a clean-up not affecting regression, but it should be taken in before any further feature or ecc-scheme changes. Now, what is your preference? (a) Take [PATCH 1/2] ecc.layout clean-up separately. (b) Take ecc.layout as part of this series, but may be with different patch title. > * What Linux commit caused the regression? > * Should this patch set be marked for -stable? And for what kernel > release? (the previous question would help answer this) > This regression was caused in commit b491da7233d5dc1a24d46ca1ad0209900329c5d0 mtd: nand: omap: clean-up ecc layout for BCH ecc schemes So, this should be applicable from 3.13.x+ >> Hence this patch series fixes those regressions, and tests complete >[...] snip > >I'm preparing a 3.14 pull request soon, and since you seem committed to >fixing and properly testing a known regression here, I'd like to see >this go in. But given the late timing and the unanswered questions, I >think it's unlikely to go in -rc1. Perhaps I can send a later pull >request if we can get it together properly. > Yes, if the above details are sufficient, then I'll: (1) re-word [PATCH 1/2] commit log & t
Re: [U-Boot] [PATCH v1 0/2] mtd: nand: omap: booting from NAND using u-boot
Hi Brian, >From: Brian Norris > >1. This patch series talks extensively about U-Boot. U-Boot is not my > interest, nor should it be the focus of kernel (driver) development. > Any work done here should be framed in the kernel driver context. [1] > Apologies for cross-posting, I understand that you are already flooded by emails from linux-mtd list. But my intention was to keep all users of OMAP3 informed, as this regression was Reported-by: Enric Balletbo Serra while testing mainline u-boot & kernel on OMAP3 platform. Thanks for you feedbacks. I'll fix the commit messages with proper description of the regression, And incorporate other comments when I re-send it. Also, I'll cut-down the CC list, as u-boot mailman blocks emails with long CC list. with regards, pekon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v1 0/2] mtd: nand: omap: booting from NAND using u-boot
On Mon, Jan 27, 2014 at 9:46 AM, Gupta, Pekon wrote:
>>From: Brian Norris
>>
>>1. This patch series talks extensively about U-Boot. U-Boot is not my
>> interest, nor should it be the focus of kernel (driver) development.
>> Any work done here should be framed in the kernel driver context. [1]
>>
> Apologies for cross-posting, I understand that you are already flooded by
> emails
> from linux-mtd list. But my intention was to keep all users of OMAP3 informed,
> as this regression was Reported-by: Enric Balletbo Serra
>
> while testing mainline u-boot & kernel on OMAP3 platform.
This last line ("while testing mainline u-boot & kernel on OMAP3
platform") is part of what worries me and requires more explanation.
An upgrade to *either* U-Boot or kernel should not cause regressions
for already-supported platforms (if this is new platform support, then
that's different, and it's not exactly a "regression" in that case;
but I know some of the kernel features are new platform support).
> Thanks for you feedbacks.
> I'll fix the commit messages with proper description of the regression,
> And incorporate other comments when I re-send it.
Can you please respond to a few of the concerns before sending a new
patch set? I'd like to have the proper explanation and discussion up
front here, rather than burying it in your long patch descriptions
with test results. Then the end result can go into a proper commit
message, once we're all happy.
> Also, I'll cut-down the
> CC list, as u-boot mailman blocks emails with long CC list.
Yeah, I noticed that after I sent my replies... IMO, you can drop the
u-boot list if that helps.
Brian
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v1 0/2] mtd: nand: omap: booting from NAND using u-boot
Hi Pekon, Sorry, I'm revisiting your patch series a bit late. There are a few factors that contributed to this, though. 1. This patch series talks extensively about U-Boot. U-Boot is not my interest, nor should it be the focus of kernel (driver) development. Any work done here should be framed in the kernel driver context. [1] 2. You have previously CC'd me on U-Boot patches. Or at least, I think so. More about this in the next point... 3. The U-Boot source code structure is rather similar to pieces of Linux subsystems. So without additional effort, it is hard to discern whether a patch is intended for Linux MTD or U-Boot MTD. 4. You cross-posted to both the U-Boot and Linux-MTD mailing lists. So the sum of all this is that I ignored these patches at first, as they weren't clearly intended for me. On Fri, Dec 13, 2013 at 02:42:56PM +0530, Pekon Gupta wrote: > As there were parallel set of patches running between u-boot and kernel. I don't know what patches you're talking about. > hence, some patch-sets caused regression for OMAP3x platforms when booting "Hence" is not the right word. The previous sentence doesn't imply that there were regressions. > using u-boot specifically for ecc-schemes (like BCH4_SW). Huh? What does "specifically for ecc-schemes" mean? You mean that only some schemes had regressions? Can you be more specific? What are these regressions? The rest of this cover letter (and most of the patch descriptions) describes the configurations and testing (which is all very good, don't get me wrong), with a lot of focus on things I don't follow (namely, U-Boot), but you omit many of the important details, like * What is the regression? I honestly don't see a description of the actual regression. (I can read the code to intuit that, but what's the point of your pages of description if it doesn't mention this?) Please give some logical description of the problem * What are the effects of the regression? ECC bytes in the wrong place, so you see correction failures/corruption? JFFS2 failures? (The "oobfree" changes, for instance, should only affect something like JFFS2.) * What Linux commit caused the regression? * Should this patch set be marked for -stable? And for what kernel release? (the previous question would help answer this) > Hence this patch series fixes those regressions, and tests complete [...] snip I'm preparing a 3.14 pull request soon, and since you seem committed to fixing and properly testing a known regression here, I'd like to see this go in. But given the late timing and the unanswered questions, I think it's unlikely to go in -rc1. Perhaps I can send a later pull request if we can get it together properly. So I'd like to first of all get a few answers to my questions, and then I think we might want to refresh this patch series with a little better commit messages and perhaps a separate documentation file (not necessarily in the same patch series, as the fix is more urgent). Brian [1] For instance, rather than saying "the ECC layout doesn't match U-Boot", you should probably describe what the intended ECC layout should look like and show that Linux does not match it. Perhaps it's time for some better documentation, like Ezequiel stashed under Documentation/mtd/nand/ for pxa3xx. You could also take some cues from Huang's comments on ECC layouts, etc., in gpmi-nand.c. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v1 0/2] mtd: nand: omap: booting from NAND using u-boot
Hi Brian,
>From: Enric Balletbo Serra [mailto:eballe...@gmail.com]
>>2014/1/6 Stefan Roese :
...
As there were parallel set of patches running between u-boot and kernel.
hence, some patch-sets caused regression for OMAP3x platforms when booting
using u-boot specifically for ecc-schemes (like BCH4_SW).
Hence this patch series fixes those regressions, and tests complete
NAND boot sequence for multiple ecc-schemes on AM335x-EVM board.
(following configurations are required for building u-boot driver which is
compatible to kernel ecclayout for selected ecc-scheme)
(BCH8_HW) (HAM1_HW) (HAM1_HW) (HAM1_HW) (UBIFS)
ROM -> SPL -> U-Boot -> Kernel ->
File-System
(BCH8_HW) (BCH8_SW) (BCH8_SW) (BCH8_SW) (UBIFS)
ROM -> SPL -> U-Boot -> Kernel ->
File-System
(BCH8_HW) (BCH8_HW) (BCH8_HW) (BCH8_HW) (UBIFS)
ROM -> SPL -> U-Boot -> Kernel ->
File-System
*Configurations used to build u-boot and kernel for end-to-end NAND boot*
+++--+
| ecc-scheme | u-boot/SPL configs| kernel DTS
|
+++--+
|||
|
| HAM1_HW| #define CONFIG_NAND_OMAP_ECCSCHEME \
|ti,nand-ecc-opts= |
|| OMAP_ECC_HAM1_CODE_HW |"ham1"
|
| (1-bit | #define CONFIG_SYS_NAND_ECCBYTES 3 |
|
| Hamming| #define CONFIG_SYS_NAND_ECCPOS \ |
|
| using h/w) | { 1, 2, 3, 4, 5, 6, 7, 8, 9, \|
|
||10, 11, 12 }|
|
|| (for NAND page-size=2048) |
|
|||
|
+++--+
|||
|
| BCH8_SW| #define CONFIG_NAND_OMAP_ECCSCHEME\
|ti,nand-ecc-opts= |
|| OMAP_ECC_BCH8_CODE_HW_DETECTION_SW |"bch8"
|
|(8-bit BCH | #define CONFIG_SYS_NAND_ECCBYTES 13 |(without ELM
node)|
| using s/w | #define CONFIG_BCH |
|
|library for | #undef CONFIG_SPL_NAND_AM33XX_BCH |
|
|for ECC | #define CONFIG_SPL_NAND_SIMPLE |
|
| error | #define CONFIG_SYS_NAND_ECCPOS \ |
|
|correction) | {2, 3, 4, 5, 6, 7, 8, 9, 10, \ |
|
|| 11, 12, 13, 14, \ |
|
|| 16, 17, 18, 19, 20, 21, 22, 23, 24, \ |
|
|| 25, 26, 27, 28, \ |
|
|| 30, 31, 32, 33, 34, 35, 36, 37, 38, \ |
|
|| 39, 40, 41, 42, \ |
|
|| 44, 45, 46, 47, 48, 49, 50, 51, 52, \ |
|
|| 53, 54, 55, 56, } |
|
|| (for NAND page-size=2048) |
|
|| #define CONFIG_SYS_NAND_ECCSIZE 512 |
|
|||
|
+++--+
|||
|
| BCH8_HW| #define CONFIG_NAND_OMAP_ECCSCHEME\
|ti,nand-ecc-opts= |
|| OMAP_ECC_BCH8_CODE_HW |"bch8"
|
|(8-bit BCH | #define CONFIG_SYS_NAND_ECCBYTES 14 |
|
| using ELM | #define CONFIG_SPL_NAND_AM33XX_BCH |(with ELM node)
|
| h/w engine | #define CONFIG_SYS_NAND_ECCPOS \
|ti,elm-id=<&elm> |
|for ECC | {2, 3, 4, 5, 6, 7, 8, 9, \|
|
| error | 10, 11, 12, 13, 14, 15, 16, 17, \|
|
|correction) | 18, 19, 20, 21, 22, 23, 24, 25, \|
|
|| 26,
Re: [U-Boot] [PATCH v1 0/2] mtd: nand: omap: booting from NAND using u-boot
Hi Pekon,
On 06.01.2014 08:40, Gupta, Pekon wrote:
> Hello Enric, Nikita, and other OMAP3 users,
>
>>
>> As there were parallel set of patches running between u-boot and kernel.
>> hence, some patch-sets caused regression for OMAP3x platforms when booting
>> using u-boot specifically for ecc-schemes (like BCH4_SW).
>>
>> Hence this patch series fixes those regressions, and tests complete
>> NAND boot sequence for multiple ecc-schemes on AM335x-EVM board.
>> (following configurations are required for building u-boot driver which is
>> compatible to kernel ecclayout for selected ecc-scheme)
>>
>>
>>(BCH8_HW) (HAM1_HW) (HAM1_HW) (HAM1_HW) (UBIFS)
>> ROM -> SPL -> U-Boot -> Kernel -> File-System
>>
>>(BCH8_HW) (BCH8_SW) (BCH8_SW) (BCH8_SW) (UBIFS)
>> ROM -> SPL -> U-Boot -> Kernel -> File-System
>>
>>(BCH8_HW) (BCH8_HW) (BCH8_HW) (BCH8_HW) (UBIFS)
>> ROM -> SPL -> U-Boot -> Kernel -> File-System
>>
>> *Configurations used to build u-boot and kernel for end-to-end NAND boot*
>> +++--+
>> | ecc-scheme | u-boot/SPL configs| kernel DTS
>> |
>> +++--+
>> |||
>> |
>> | HAM1_HW| #define CONFIG_NAND_OMAP_ECCSCHEME \ |ti,nand-ecc-opts=
>> |
>> || OMAP_ECC_HAM1_CODE_HW |"ham1"
>> |
>> | (1-bit | #define CONFIG_SYS_NAND_ECCBYTES 3 |
>> |
>> | Hamming| #define CONFIG_SYS_NAND_ECCPOS \ |
>> |
>> | using h/w) | { 1, 2, 3, 4, 5, 6, 7, 8, 9, \|
>> |
>> ||10, 11, 12 }|
>> |
>> || (for NAND page-size=2048) |
>> |
>> |||
>> |
>> +++--+
>> |||
>> |
>> | BCH8_SW| #define CONFIG_NAND_OMAP_ECCSCHEME\|ti,nand-ecc-opts=
>> |
>> || OMAP_ECC_BCH8_CODE_HW_DETECTION_SW |"bch8"
>> |
>> |(8-bit BCH | #define CONFIG_SYS_NAND_ECCBYTES 13 |(without ELM
>> node)|
>> | using s/w | #define CONFIG_BCH |
>> |
>> |library for | #undef CONFIG_SPL_NAND_AM33XX_BCH |
>> |
>> |for ECC | #define CONFIG_SPL_NAND_SIMPLE |
>> |
>> | error | #define CONFIG_SYS_NAND_ECCPOS \ |
>> |
>> |correction) | {2, 3, 4, 5, 6, 7, 8, 9, 10, \ |
>> |
>> || 11, 12, 13, 14, \ |
>> |
>> || 16, 17, 18, 19, 20, 21, 22, 23, 24, \ |
>> |
>> || 25, 26, 27, 28, \ |
>> |
>> || 30, 31, 32, 33, 34, 35, 36, 37, 38, \ |
>> |
>> || 39, 40, 41, 42, \ |
>> |
>> || 44, 45, 46, 47, 48, 49, 50, 51, 52, \ |
>> |
>> || 53, 54, 55, 56, } |
>> |
>> || (for NAND page-size=2048) |
>> |
>> || #define CONFIG_SYS_NAND_ECCSIZE 512 |
>> |
>> |||
>> |
>> +++--+
>> |||
>> |
>> | BCH8_HW| #define CONFIG_NAND_OMAP_ECCSCHEME\|ti,nand-ecc-opts=
>> |
>> || OMAP_ECC_BCH8_CODE_HW |"bch8"
>> |
>> |(8-bit BCH | #define CONFIG_SYS_NAND_ECCBYTES 14 |
>> |
>> | using ELM | #define CONFIG_SPL_NAND_AM33XX_BCH |(with ELM node)
>> |
>> | h/w engine | #define CONFIG_SYS_NAND_ECCPOS \ |ti,elm-id=<&elm>
>> |
>> |for ECC | {2, 3, 4, 5, 6, 7, 8, 9, \|
>> |
>> | error | 10, 11, 12, 13, 14, 15, 16, 17, \|
>> |
>> |correction) | 18, 19, 20, 21, 22, 23, 24, 25, \|
>> |
>> || 26, 27, 28, 29, 30, 31, 32, 33, \|
>> |
>> || 34, 35, 36, 37, 38, 39, 40, 41, \|
>> |
>> || 42, 43, 44, 45, 46, 47, 48, 49, \|
Re: [U-Boot] [PATCH v1 0/2] mtd: nand: omap: booting from NAND using u-boot
Hello Enric, Nikita, and other OMAP3 users,
>
>As there were parallel set of patches running between u-boot and kernel.
>hence, some patch-sets caused regression for OMAP3x platforms when booting
>using u-boot specifically for ecc-schemes (like BCH4_SW).
>
>Hence this patch series fixes those regressions, and tests complete
>NAND boot sequence for multiple ecc-schemes on AM335x-EVM board.
>(following configurations are required for building u-boot driver which is
> compatible to kernel ecclayout for selected ecc-scheme)
>
>
>(BCH8_HW) (HAM1_HW) (HAM1_HW) (HAM1_HW) (UBIFS)
>ROM -> SPL -> U-Boot -> Kernel -> File-System
>
>(BCH8_HW) (BCH8_SW) (BCH8_SW) (BCH8_SW) (UBIFS)
>ROM -> SPL -> U-Boot -> Kernel -> File-System
>
>(BCH8_HW) (BCH8_HW) (BCH8_HW) (BCH8_HW) (UBIFS)
>ROM -> SPL -> U-Boot -> Kernel -> File-System
>
>*Configurations used to build u-boot and kernel for end-to-end NAND boot*
>+++--+
>| ecc-scheme | u-boot/SPL configs| kernel DTS |
>+++--+
>||| |
>| HAM1_HW| #define CONFIG_NAND_OMAP_ECCSCHEME \ |ti,nand-ecc-opts= |
>|| OMAP_ECC_HAM1_CODE_HW |"ham1"|
>| (1-bit | #define CONFIG_SYS_NAND_ECCBYTES 3 | |
>| Hamming| #define CONFIG_SYS_NAND_ECCPOS \ | |
>| using h/w) | { 1, 2, 3, 4, 5, 6, 7, 8, 9, \| |
>||10, 11, 12 }| |
>|| (for NAND page-size=2048) | |
>||| |
>+++--+
>||| |
>| BCH8_SW| #define CONFIG_NAND_OMAP_ECCSCHEME\|ti,nand-ecc-opts= |
>|| OMAP_ECC_BCH8_CODE_HW_DETECTION_SW |"bch8"|
>|(8-bit BCH | #define CONFIG_SYS_NAND_ECCBYTES 13 |(without ELM node)|
>| using s/w | #define CONFIG_BCH | |
>|library for | #undef CONFIG_SPL_NAND_AM33XX_BCH | |
>|for ECC | #define CONFIG_SPL_NAND_SIMPLE | |
>| error | #define CONFIG_SYS_NAND_ECCPOS \ | |
>|correction) | {2, 3, 4, 5, 6, 7, 8, 9, 10, \ | |
>|| 11, 12, 13, 14, \ | |
>|| 16, 17, 18, 19, 20, 21, 22, 23, 24, \ | |
>|| 25, 26, 27, 28, \ | |
>|| 30, 31, 32, 33, 34, 35, 36, 37, 38, \ | |
>|| 39, 40, 41, 42, \ | |
>|| 44, 45, 46, 47, 48, 49, 50, 51, 52, \ | |
>|| 53, 54, 55, 56, } | |
>|| (for NAND page-size=2048) | |
>|| #define CONFIG_SYS_NAND_ECCSIZE 512 | |
>||| |
>+++--+
>||| |
>| BCH8_HW| #define CONFIG_NAND_OMAP_ECCSCHEME\|ti,nand-ecc-opts= |
>|| OMAP_ECC_BCH8_CODE_HW |"bch8"|
>|(8-bit BCH | #define CONFIG_SYS_NAND_ECCBYTES 14 | |
>| using ELM | #define CONFIG_SPL_NAND_AM33XX_BCH |(with ELM node) |
>| h/w engine | #define CONFIG_SYS_NAND_ECCPOS \ |ti,elm-id=<&elm> |
>|for ECC | {2, 3, 4, 5, 6, 7, 8, 9, \| |
>| error | 10, 11, 12, 13, 14, 15, 16, 17, \| |
>|correction) | 18, 19, 20, 21, 22, 23, 24, 25, \| |
>|| 26, 27, 28, 29, 30, 31, 32, 33, \| |
>|| 34, 35, 36, 37, 38, 39, 40, 41, \| |
>|| 42, 43, 44, 45, 46, 47, 48, 49, \| |
>|| 50, 51, 52, 53, 54, 55, 56, 57, }| |
>|| (for NAND page-size=2048) | |
>|| #define CONFIG_SYS_NAND_ECCSIZE 512 | |
>||| |
>+---
