[U-Boot] IMX6 NAND boot regression

[U-Boot] IMX6 NAND boot regression

[Tim Harvey]

Stefan,

I'm trying to track down an IMX6 SPL NAND boot regression that started
in v2018.07 with your patch series to mxs_nand.

I bisected it back to '5346c31e305a37d39f535cc0d5ae87d8b7e81230 mtd:
nand: mxs_nand: use self init'. With this particular patch nand bbt
scanning would crash the board because of nand_chip.scan_btt not being
assigned. This was later fixed in
'96d0be07e7498e7174daa6f3b56fc807b9feb71d MTD: nand: mxs_nand_spl: Fix
empty function pointer for BBT' but cherry-picking that on top of
5346c31 fixes the immediate crash while scanning but then I find that
mxs_read_page_ecc() hangs on the 4th page of reading u-boot.img from
the NAND. This gets worse 2 patches later where in
'28897e8d21f8e197e259a91c693de09cd81f2d5a: mtd: nand: mxs_nand: use
structure for BCH geometry' I find that the first byte of every page
read is wrong because mxs_nand_swap_block_mark() is getting called on
the page which swaps the first bytes with oob.

There are several IMX6 boards out there using both NAND and SPL I
believe that I would assume were broken by this series. Any ideas on
the proper resolution?

Regards,

Tim

[U-Boot] IMX6 NAND boot regression

[Stefan Agner]

Hi Tim,

On 02.02.19 03:32, Tim Harvey wrote:
> Stefan,
> 
> I'm trying to track down an IMX6 SPL NAND boot regression that started
> in v2018.07 with your patch series to mxs_nand.

I am sorry about that. Unfortunately I did not had a design at hand where I was able to test the NAND driver in SPL...

> 
> I bisected it back to '5346c31e305a37d39f535cc0d5ae87d8b7e81230 mtd:
> nand: mxs_nand: use self init'. With this particular patch nand bbt
> scanning would crash the board because of nand_chip.scan_btt not being
> assigned. This was later fixed in
> '96d0be07e7498e7174daa6f3b56fc807b9feb71d MTD: nand: mxs_nand_spl: Fix
> empty function pointer for BBT' but cherry-picking that on top of
> 5346c31 fixes the immediate crash while scanning but then I find that
> mxs_read_page_ecc() hangs on the 4th page of reading u-boot.img from
> the NAND. This gets worse 2 patches later where in
> '28897e8d21f8e197e259a91c693de09cd81f2d5a: mtd: nand: mxs_nand: use
> structure for BCH geometry' I find that the first byte of every page
> read is wrong because mxs_nand_swap_block_mark() is getting called on
> the page which swaps the first bytes with oob.
> 
> There are several IMX6 boards out there using both NAND and SPL I
> believe that I would assume were broken by this series. Any ideas on
> the proper resolution?

Adam Ford sent another patch just recently with the title: "MTD: nand: mxs_nand: Allow driver to auto setup ECC in SPL". Maybe this helps?

--
Stefan

> 
> Regards,
> 
> Tim
> 

[U-Boot] IMX6 NAND boot regression

[Jagan Teki]

+Adam, Shyam

On Sat, 2 Feb, 2019, 8:49 AM Stefan Agner <stefan.agner@toradex.com wrote:

> Hi Tim,
>
> On 02.02.19 03:32, Tim Harvey wrote:
> > Stefan,
> >
> > I'm trying to track down an IMX6 SPL NAND boot regression that started
> > in v2018.07 with your patch series to mxs_nand.
>
> I am sorry about that. Unfortunately I did not had a design at hand where
> I was able to test the NAND driver in SPL...
>
> >
> > I bisected it back to '5346c31e305a37d39f535cc0d5ae87d8b7e81230 mtd:
> > nand: mxs_nand: use self init'. With this particular patch nand bbt
> > scanning would crash the board because of nand_chip.scan_btt not being
> > assigned. This was later fixed in
> > '96d0be07e7498e7174daa6f3b56fc807b9feb71d MTD: nand: mxs_nand_spl: Fix
> > empty function pointer for BBT' but cherry-picking that on top of
> > 5346c31 fixes the immediate crash while scanning but then I find that
> > mxs_read_page_ecc() hangs on the 4th page of reading u-boot.img from
> > the NAND. This gets worse 2 patches later where in
> > '28897e8d21f8e197e259a91c693de09cd81f2d5a: mtd: nand: mxs_nand: use
> > structure for BCH geometry' I find that the first byte of every page
> > read is wrong because mxs_nand_swap_block_mark() is getting called on
> > the page which swaps the first bytes with oob.
> >
> > There are several IMX6 boards out there using both NAND and SPL I
> > believe that I would assume were broken by this series. Any ideas on
> > the proper resolution?
>

Look like 2017.03 can be stable boot from nand as for as my test is concern.

We are also trying hard using git bisect, but seems like multiple breakings.

Will keep posted if something move further.

[U-Boot] IMX6 NAND boot regression

[Adam Ford]

On Sat, Feb 2, 2019 at 12:29 AM Jagan Teki <jagan@amarulasolutions.com> wrote:
>
> +Adam, Shyam
>
> On Sat, 2 Feb, 2019, 8:49 AM Stefan Agner <stefan.agner@toradex.com wrote:
>
> > Hi Tim,
> >
> > On 02.02.19 03:32, Tim Harvey wrote:
> > > Stefan,
> > >
> > > I'm trying to track down an IMX6 SPL NAND boot regression that started
> > > in v2018.07 with your patch series to mxs_nand.
> >
> > I am sorry about that. Unfortunately I did not had a design at hand where
> > I was able to test the NAND driver in SPL...
> >
> > >
> > > I bisected it back to '5346c31e305a37d39f535cc0d5ae87d8b7e81230 mtd:
> > > nand: mxs_nand: use self init'. With this particular patch nand bbt
> > > scanning would crash the board because of nand_chip.scan_btt not being
> > > assigned. This was later fixed in
> > > '96d0be07e7498e7174daa6f3b56fc807b9feb71d MTD: nand: mxs_nand_spl: Fix
> > > empty function pointer for BBT' but cherry-picking that on top of
> > > 5346c31 fixes the immediate crash while scanning but then I find that
> > > mxs_read_page_ecc() hangs on the 4th page of reading u-boot.img from
> > > the NAND. This gets worse 2 patches later where in
> > > '28897e8d21f8e197e259a91c693de09cd81f2d5a: mtd: nand: mxs_nand: use
> > > structure for BCH geometry' I find that the first byte of every page
> > > read is wrong because mxs_nand_swap_block_mark() is getting called on
> > > the page which swaps the first bytes with oob.
> > >
> > > There are several IMX6 boards out there using both NAND and SPL I
> > > believe that I would assume were broken by this series. Any ideas on
> > > the proper resolution?
> >
>
> Look like 2017.03 can be stable boot from nand as for as my test is concern.
>
> We are also trying hard using git bisect, but seems like multiple breakings.
>
> Will keep posted if something move further.


From a different thread, someone was able to test these patches and
found they fixed their booting issues:

 There was a broken function pointer here that was fixed and applied
 the imx-master, but pending merge with master
 http://patchwork.ozlabs.org/patch/1019440/

 Configure ECC from SPL here:
 http://patchwork.ozlabs.org/patch/1020160/

 Remove hard-coded ECC parameters since the patch above can autoset them.
 http://patchwork.ozlabs.org/patch/1026638/

Maybe those can help.

adam


> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> https://lists.denx.de/listinfo/u-boot

[U-Boot] IMX6 NAND boot regression

[Jörg Krause]

Hi,

On Sat, 2019-02-02 at 05:30 -0800, Adam Ford wrote:
> On Sat, Feb 2, 2019 at 12:29 AM Jagan Teki <jagan@amarulasolutions.com> wrote:
> > +Adam, Shyam
> > 
> > On Sat, 2 Feb, 2019, 8:49 AM Stefan Agner <stefan.agner@toradex.com wrote:
> > 
> > > Hi Tim,
> > > 
> > > On 02.02.19 03:32, Tim Harvey wrote:
> > > > Stefan,
> > > > 
> > > > I'm trying to track down an IMX6 SPL NAND boot regression that started
> > > > in v2018.07 with your patch series to mxs_nand.
> > > 
> > > I am sorry about that. Unfortunately I did not had a design at hand where
> > > I was able to test the NAND driver in SPL...
> > > 
> > > > I bisected it back to '5346c31e305a37d39f535cc0d5ae87d8b7e81230 mtd:
> > > > nand: mxs_nand: use self init'. With this particular patch nand bbt
> > > > scanning would crash the board because of nand_chip.scan_btt not being
> > > > assigned. This was later fixed in
> > > > '96d0be07e7498e7174daa6f3b56fc807b9feb71d MTD: nand: mxs_nand_spl: Fix
> > > > empty function pointer for BBT' but cherry-picking that on top of
> > > > 5346c31 fixes the immediate crash while scanning but then I find that
> > > > mxs_read_page_ecc() hangs on the 4th page of reading u-boot.img from
> > > > the NAND. This gets worse 2 patches later where in
> > > > '28897e8d21f8e197e259a91c693de09cd81f2d5a: mtd: nand: mxs_nand: use
> > > > structure for BCH geometry' I find that the first byte of every page
> > > > read is wrong because mxs_nand_swap_block_mark() is getting called on
> > > > the page which swaps the first bytes with oob.
> > > > 
> > > > There are several IMX6 boards out there using both NAND and SPL I
> > > > believe that I would assume were broken by this series. Any ideas on
> > > > the proper resolution?
> > 
> > Look like 2017.03 can be stable boot from nand as for as my test is concern.
> > 
> > We are also trying hard using git bisect, but seems like multiple breakings.
> > 
> > Will keep posted if something move further.
> 
> From a different thread, someone was able to test these patches and
> found they fixed their booting issues:
> 
>  There was a broken function pointer here that was fixed and applied
>  the imx-master, but pending merge with master
>  http://patchwork.ozlabs.org/patch/1019440/
> 
>  Configure ECC from SPL here:
>  http://patchwork.ozlabs.org/patch/1020160/
> 
>  Remove hard-coded ECC parameters since the patch above can autoset them.
>  http://patchwork.ozlabs.org/patch/1026638/
> 
> Maybe those can help.

I can confirm that that the commit
5346c31e305a37d39f535cc0d5ae87d8b7e81230 broke booting from NAND for my
i.MX6ULL board, so I sticked with version 2018.05.

Now, I've tested U-Boot 2019.01 with the three patches Adam suggested
and the SPL loader is able to boot from NAND again.

Jörg

[U-Boot] IMX6 NAND boot regression

[Tim Harvey]

On Sat, Feb 2, 2019 at 5:30 AM Adam Ford <aford173@gmail.com> wrote:
>
> On Sat, Feb 2, 2019 at 12:29 AM Jagan Teki <jagan@amarulasolutions.com> wrote:
> >
> > +Adam, Shyam
> >
> > On Sat, 2 Feb, 2019, 8:49 AM Stefan Agner <stefan.agner@toradex.com wrote:
> >
> > > Hi Tim,
> > >
> > > On 02.02.19 03:32, Tim Harvey wrote:
> > > > Stefan,
> > > >
> > > > I'm trying to track down an IMX6 SPL NAND boot regression that started
> > > > in v2018.07 with your patch series to mxs_nand.
> > >
> > > I am sorry about that. Unfortunately I did not had a design at hand where
> > > I was able to test the NAND driver in SPL...
> > >
> > > >
> > > > I bisected it back to '5346c31e305a37d39f535cc0d5ae87d8b7e81230 mtd:
> > > > nand: mxs_nand: use self init'. With this particular patch nand bbt
> > > > scanning would crash the board because of nand_chip.scan_btt not being
> > > > assigned. This was later fixed in
> > > > '96d0be07e7498e7174daa6f3b56fc807b9feb71d MTD: nand: mxs_nand_spl: Fix
> > > > empty function pointer for BBT' but cherry-picking that on top of
> > > > 5346c31 fixes the immediate crash while scanning but then I find that
> > > > mxs_read_page_ecc() hangs on the 4th page of reading u-boot.img from
> > > > the NAND. This gets worse 2 patches later where in
> > > > '28897e8d21f8e197e259a91c693de09cd81f2d5a: mtd: nand: mxs_nand: use
> > > > structure for BCH geometry' I find that the first byte of every page
> > > > read is wrong because mxs_nand_swap_block_mark() is getting called on
> > > > the page which swaps the first bytes with oob.
> > > >
> > > > There are several IMX6 boards out there using both NAND and SPL I
> > > > believe that I would assume were broken by this series. Any ideas on
> > > > the proper resolution?
> > >
> >
> > Look like 2017.03 can be stable boot from nand as for as my test is concern.
> >
> > We are also trying hard using git bisect, but seems like multiple breakings.
> >
> > Will keep posted if something move further.
>
>
> From a different thread, someone was able to test these patches and
> found they fixed their booting issues:
>
>  There was a broken function pointer here that was fixed and applied
>  the imx-master, but pending merge with master
>  http://patchwork.ozlabs.org/patch/1019440/

right, this one was the 96d0be07 merged upstream already. I'm not
clear how any NAND SPL would have worked after Sefan's series back in
June without this one.

>
>  Configure ECC from SPL here:
>  http://patchwork.ozlabs.org/patch/1020160/

For my boards with Micron  MT29F2G08AB 2Gbit NAND (oob=64) this was
enough but with Micron MT29F16G08AD 16Gbit (oob=224) and Cypress
S34ML16G202BH 16GBit (oob=128) NAND flash your other patch is needed.

>
>  Remove hard-coded ECC parameters since the patch above can autoset them.
>  http://patchwork.ozlabs.org/patch/1026638/
>

Thanks Adam, this one resolved the boot issue with Micron MT29F16G08AD
16Gbit (oob=224) and Cypress S34ML16G202BH 16Gbit (oob=128) NAND.

I will ack those last 2 patches that are still pending and take note
to avoid anything between v2018.07 and the next release v2019.03 for
IMX NAND SPL.

It kind of sucks that patches that affected IMX NAND SPL were accepted
with no testing on a NAND SPL board or cc's sent to maintainers of
boards using IMX NAND SPL but I understand the difficulty in even
identifying those maintainers and realize it is everyones
responsibility to test RC's on their own boards so I accept
responsibility for that. I'll make a note to remember that U-Boot is
broken for IMX NAND SPL between 2017.07 and 2019.03.

Thanks,

Tim

[U-Boot] IMX6 NAND boot regression

[Michael Nazzareno Trimarchi]

HI all

On Mon, Feb 4, 2019 at 7:14 PM Tim Harvey <tharvey@gateworks.com> wrote:
>
> On Sat, Feb 2, 2019 at 5:30 AM Adam Ford <aford173@gmail.com> wrote:
> >
> > On Sat, Feb 2, 2019 at 12:29 AM Jagan Teki <jagan@amarulasolutions.com> wrote:
> > >
> > > +Adam, Shyam
> > >
> > > On Sat, 2 Feb, 2019, 8:49 AM Stefan Agner <stefan.agner@toradex.com wrote:
> > >
> > > > Hi Tim,
> > > >
> > > > On 02.02.19 03:32, Tim Harvey wrote:
> > > > > Stefan,
> > > > >
> > > > > I'm trying to track down an IMX6 SPL NAND boot regression that started
> > > > > in v2018.07 with your patch series to mxs_nand.
> > > >
> > > > I am sorry about that. Unfortunately I did not had a design at hand where
> > > > I was able to test the NAND driver in SPL...
> > > >
> > > > >
> > > > > I bisected it back to '5346c31e305a37d39f535cc0d5ae87d8b7e81230 mtd:
> > > > > nand: mxs_nand: use self init'. With this particular patch nand bbt
> > > > > scanning would crash the board because of nand_chip.scan_btt not being
> > > > > assigned. This was later fixed in
> > > > > '96d0be07e7498e7174daa6f3b56fc807b9feb71d MTD: nand: mxs_nand_spl: Fix
> > > > > empty function pointer for BBT' but cherry-picking that on top of
> > > > > 5346c31 fixes the immediate crash while scanning but then I find that
> > > > > mxs_read_page_ecc() hangs on the 4th page of reading u-boot.img from
> > > > > the NAND. This gets worse 2 patches later where in
> > > > > '28897e8d21f8e197e259a91c693de09cd81f2d5a: mtd: nand: mxs_nand: use
> > > > > structure for BCH geometry' I find that the first byte of every page
> > > > > read is wrong because mxs_nand_swap_block_mark() is getting called on
> > > > > the page which swaps the first bytes with oob.
> > > > >
> > > > > There are several IMX6 boards out there using both NAND and SPL I
> > > > > believe that I would assume were broken by this series. Any ideas on
> > > > > the proper resolution?
> > > >
> > >
> > > Look like 2017.03 can be stable boot from nand as for as my test is concern.
> > >
> > > We are also trying hard using git bisect, but seems like multiple breakings.
> > >
> > > Will keep posted if something move further.
> >
> >
> > From a different thread, someone was able to test these patches and
> > found they fixed their booting issues:
> >
> >  There was a broken function pointer here that was fixed and applied
> >  the imx-master, but pending merge with master
> >  http://patchwork.ozlabs.org/patch/1019440/
>
> right, this one was the 96d0be07 merged upstream already. I'm not
> clear how any NAND SPL would have worked after Sefan's series back in
> June without this one.
>

>>SPL: board_init_r()
spl_init
Trying to boot from NAND
spl: nand - using hw ecc
0x2c:0xdc erasesize=262144 (>>18)
writesize=4096 (>>12)
oobsize=224
chipsize=536870912
nand_spl_load_image offset:0x00200000 len:64 page:512
SPL: payload image: U-Boot 2019.04-rc3-dirty for imx� load addr:
0x177fffc0 size: 635435
nand_spl_load_image offset:0x00200000 len:635435 page:512
is_badblock offs=0x00240000 block:9 page:576
is_badblock offs=0x00280000 block:10 page:640
Jumping to U-Boot
loaded - jumping to U-Boot...
image entry point: 0x17800000

I'm stuck here. Booting from mmc is fine

Michael
> >
> >  Configure ECC from SPL here:
> >  http://patchwork.ozlabs.org/patch/1020160/
>
> For my boards with Micron  MT29F2G08AB 2Gbit NAND (oob=64) this was
> enough but with Micron MT29F16G08AD 16Gbit (oob=224) and Cypress
> S34ML16G202BH 16GBit (oob=128) NAND flash your other patch is needed.
>
> >
> >  Remove hard-coded ECC parameters since the patch above can autoset them.
> >  http://patchwork.ozlabs.org/patch/1026638/
> >
>
> Thanks Adam, this one resolved the boot issue with Micron MT29F16G08AD
> 16Gbit (oob=224) and Cypress S34ML16G202BH 16Gbit (oob=128) NAND.
>
> I will ack those last 2 patches that are still pending and take note
> to avoid anything between v2018.07 and the next release v2019.03 for
> IMX NAND SPL.
>
> It kind of sucks that patches that affected IMX NAND SPL were accepted
> with no testing on a NAND SPL board or cc's sent to maintainers of
> boards using IMX NAND SPL but I understand the difficulty in even
> identifying those maintainers and realize it is everyones
> responsibility to test RC's on their own boards so I accept
> responsibility for that. I'll make a note to remember that U-Boot is
> broken for IMX NAND SPL between 2017.07 and 2019.03.
>
> Thanks,
>
> Tim
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> https://lists.denx.de/listinfo/u-boot



-- 
| Michael Nazzareno Trimarchi                     Amarula Solutions BV |
| COO  -  Founder                                      Cruquiuskade 47 |
| +31(0)851119172                                 Amsterdam 1018 AM NL |
|                  [`as] http://www.amarulasolutions.com               |

[U-Boot] IMX6 NAND boot regression

[Tim Harvey]

On Tue, Mar 5, 2019 at 8:41 AM Michael Nazzareno Trimarchi
<michael@amarulasolutions.com> wrote:
>
> HI all
>
> On Mon, Feb 4, 2019 at 7:14 PM Tim Harvey <tharvey@gateworks.com> wrote:
> >
> > On Sat, Feb 2, 2019 at 5:30 AM Adam Ford <aford173@gmail.com> wrote:
> > >
> > > On Sat, Feb 2, 2019 at 12:29 AM Jagan Teki <jagan@amarulasolutions.com> wrote:
> > > >
> > > > +Adam, Shyam
> > > >
> > > > On Sat, 2 Feb, 2019, 8:49 AM Stefan Agner <stefan.agner@toradex.com wrote:
> > > >
> > > > > Hi Tim,
> > > > >
> > > > > On 02.02.19 03:32, Tim Harvey wrote:
> > > > > > Stefan,
> > > > > >
> > > > > > I'm trying to track down an IMX6 SPL NAND boot regression that started
> > > > > > in v2018.07 with your patch series to mxs_nand.
> > > > >
> > > > > I am sorry about that. Unfortunately I did not had a design at hand where
> > > > > I was able to test the NAND driver in SPL...
> > > > >
> > > > > >
> > > > > > I bisected it back to '5346c31e305a37d39f535cc0d5ae87d8b7e81230 mtd:
> > > > > > nand: mxs_nand: use self init'. With this particular patch nand bbt
> > > > > > scanning would crash the board because of nand_chip.scan_btt not being
> > > > > > assigned. This was later fixed in
> > > > > > '96d0be07e7498e7174daa6f3b56fc807b9feb71d MTD: nand: mxs_nand_spl: Fix
> > > > > > empty function pointer for BBT' but cherry-picking that on top of
> > > > > > 5346c31 fixes the immediate crash while scanning but then I find that
> > > > > > mxs_read_page_ecc() hangs on the 4th page of reading u-boot.img from
> > > > > > the NAND. This gets worse 2 patches later where in
> > > > > > '28897e8d21f8e197e259a91c693de09cd81f2d5a: mtd: nand: mxs_nand: use
> > > > > > structure for BCH geometry' I find that the first byte of every page
> > > > > > read is wrong because mxs_nand_swap_block_mark() is getting called on
> > > > > > the page which swaps the first bytes with oob.
> > > > > >
> > > > > > There are several IMX6 boards out there using both NAND and SPL I
> > > > > > believe that I would assume were broken by this series. Any ideas on
> > > > > > the proper resolution?
> > > > >
> > > >
> > > > Look like 2017.03 can be stable boot from nand as for as my test is concern.
> > > >
> > > > We are also trying hard using git bisect, but seems like multiple breakings.
> > > >
> > > > Will keep posted if something move further.
> > >
> > >
> > > From a different thread, someone was able to test these patches and
> > > found they fixed their booting issues:
> > >
> > >  There was a broken function pointer here that was fixed and applied
> > >  the imx-master, but pending merge with master
> > >  http://patchwork.ozlabs.org/patch/1019440/
> >
> > right, this one was the 96d0be07 merged upstream already. I'm not
> > clear how any NAND SPL would have worked after Sefan's series back in
> > June without this one.
> >
>
> >>SPL: board_init_r()
> spl_init
> Trying to boot from NAND
> spl: nand - using hw ecc
> 0x2c:0xdc erasesize=262144 (>>18)
> writesize=4096 (>>12)
> oobsize=224
> chipsize=536870912
> nand_spl_load_image offset:0x00200000 len:64 page:512
> SPL: payload image: U-Boot 2019.04-rc3-dirty for imx� load addr:
> 0x177fffc0 size: 635435
> nand_spl_load_image offset:0x00200000 len:635435 page:512
> is_badblock offs=0x00240000 block:9 page:576
> is_badblock offs=0x00280000 block:10 page:640
> Jumping to U-Boot
> loaded - jumping to U-Boot...
> image entry point: 0x17800000
>
> I'm stuck here. Booting from mmc is fine
>
> Michael

Michael,

What code are you running (git sha) and what board?

Make sure you have 04568bd0b6 MTD: nand: mxs_nand: Allow driver to
auto setup ECC in SPL

Tim

[U-Boot] IMX6 NAND boot regression

[Michael Nazzareno Trimarchi]

Hi Tim

On Tue, Mar 5, 2019 at 5:54 PM Tim Harvey <tharvey@gateworks.com> wrote:
>
> On Tue, Mar 5, 2019 at 8:41 AM Michael Nazzareno Trimarchi
> <michael@amarulasolutions.com> wrote:
> >
> > HI all
> >
> > On Mon, Feb 4, 2019 at 7:14 PM Tim Harvey <tharvey@gateworks.com> wrote:
> > >
> > > On Sat, Feb 2, 2019 at 5:30 AM Adam Ford <aford173@gmail.com> wrote:
> > > >
> > > > On Sat, Feb 2, 2019 at 12:29 AM Jagan Teki <jagan@amarulasolutions.com> wrote:
> > > > >
> > > > > +Adam, Shyam
> > > > >
> > > > > On Sat, 2 Feb, 2019, 8:49 AM Stefan Agner <stefan.agner@toradex.com wrote:
> > > > >
> > > > > > Hi Tim,
> > > > > >
> > > > > > On 02.02.19 03:32, Tim Harvey wrote:
> > > > > > > Stefan,
> > > > > > >
> > > > > > > I'm trying to track down an IMX6 SPL NAND boot regression that started
> > > > > > > in v2018.07 with your patch series to mxs_nand.
> > > > > >
> > > > > > I am sorry about that. Unfortunately I did not had a design at hand where
> > > > > > I was able to test the NAND driver in SPL...
> > > > > >
> > > > > > >
> > > > > > > I bisected it back to '5346c31e305a37d39f535cc0d5ae87d8b7e81230 mtd:
> > > > > > > nand: mxs_nand: use self init'. With this particular patch nand bbt
> > > > > > > scanning would crash the board because of nand_chip.scan_btt not being
> > > > > > > assigned. This was later fixed in
> > > > > > > '96d0be07e7498e7174daa6f3b56fc807b9feb71d MTD: nand: mxs_nand_spl: Fix
> > > > > > > empty function pointer for BBT' but cherry-picking that on top of
> > > > > > > 5346c31 fixes the immediate crash while scanning but then I find that
> > > > > > > mxs_read_page_ecc() hangs on the 4th page of reading u-boot.img from
> > > > > > > the NAND. This gets worse 2 patches later where in
> > > > > > > '28897e8d21f8e197e259a91c693de09cd81f2d5a: mtd: nand: mxs_nand: use
> > > > > > > structure for BCH geometry' I find that the first byte of every page
> > > > > > > read is wrong because mxs_nand_swap_block_mark() is getting called on
> > > > > > > the page which swaps the first bytes with oob.
> > > > > > >
> > > > > > > There are several IMX6 boards out there using both NAND and SPL I
> > > > > > > believe that I would assume were broken by this series. Any ideas on
> > > > > > > the proper resolution?
> > > > > >
> > > > >
> > > > > Look like 2017.03 can be stable boot from nand as for as my test is concern.
> > > > >
> > > > > We are also trying hard using git bisect, but seems like multiple breakings.
> > > > >
> > > > > Will keep posted if something move further.
> > > >
> > > >
> > > > From a different thread, someone was able to test these patches and
> > > > found they fixed their booting issues:
> > > >
> > > >  There was a broken function pointer here that was fixed and applied
> > > >  the imx-master, but pending merge with master
> > > >  http://patchwork.ozlabs.org/patch/1019440/
> > >
> > > right, this one was the 96d0be07 merged upstream already. I'm not
> > > clear how any NAND SPL would have worked after Sefan's series back in
> > > June without this one.
> > >
> >
> > >>SPL: board_init_r()
> > spl_init
> > Trying to boot from NAND
> > spl: nand - using hw ecc
> > 0x2c:0xdc erasesize=262144 (>>18)
> > writesize=4096 (>>12)
> > oobsize=224
> > chipsize=536870912
> > nand_spl_load_image offset:0x00200000 len:64 page:512
> > SPL: payload image: U-Boot 2019.04-rc3-dirty for imx� load addr:
> > 0x177fffc0 size: 635435
> > nand_spl_load_image offset:0x00200000 len:635435 page:512
> > is_badblock offs=0x00240000 block:9 page:576
> > is_badblock offs=0x00280000 block:10 page:640
> > Jumping to U-Boot
> > loaded - jumping to U-Boot...
> > image entry point: 0x17800000
> >
> > I'm stuck here. Booting from mmc is fine
> >
> > Michael
>
> Michael,
>
> What code are you running (git sha) and what board?
>
> Make sure you have 04568bd0b6 MTD: nand: mxs_nand: Allow driver to
> auto setup ECC in SPL
>

Top of master and I have that commit included. Can I know one imx6 board now
that can boot from Nand?

Michael

> Tim



-- 
| Michael Nazzareno Trimarchi                     Amarula Solutions BV |
| COO  -  Founder                                      Cruquiuskade 47 |
| +31(0)851119172                                 Amsterdam 1018 AM NL |
|                  [`as] http://www.amarulasolutions.com               |

[U-Boot] IMX6 NAND boot regression

[Michael Nazzareno Trimarchi]

Hi Tim

On Tue, Mar 5, 2019 at 5:59 PM Michael Nazzareno Trimarchi
<michael@amarulasolutions.com> wrote:
>
> Hi Tim
>
> On Tue, Mar 5, 2019 at 5:54 PM Tim Harvey <tharvey@gateworks.com> wrote:
> >
> > On Tue, Mar 5, 2019 at 8:41 AM Michael Nazzareno Trimarchi
> > <michael@amarulasolutions.com> wrote:
> > >
> > > HI all
> > >
> > > On Mon, Feb 4, 2019 at 7:14 PM Tim Harvey <tharvey@gateworks.com> wrote:
> > > >
> > > > On Sat, Feb 2, 2019 at 5:30 AM Adam Ford <aford173@gmail.com> wrote:
> > > > >
> > > > > On Sat, Feb 2, 2019 at 12:29 AM Jagan Teki <jagan@amarulasolutions.com> wrote:
> > > > > >
> > > > > > +Adam, Shyam
> > > > > >
> > > > > > On Sat, 2 Feb, 2019, 8:49 AM Stefan Agner <stefan.agner@toradex.com wrote:
> > > > > >
> > > > > > > Hi Tim,
> > > > > > >
> > > > > > > On 02.02.19 03:32, Tim Harvey wrote:
> > > > > > > > Stefan,
> > > > > > > >
> > > > > > > > I'm trying to track down an IMX6 SPL NAND boot regression that started
> > > > > > > > in v2018.07 with your patch series to mxs_nand.
> > > > > > >
> > > > > > > I am sorry about that. Unfortunately I did not had a design at hand where
> > > > > > > I was able to test the NAND driver in SPL...
> > > > > > >
> > > > > > > >
> > > > > > > > I bisected it back to '5346c31e305a37d39f535cc0d5ae87d8b7e81230 mtd:
> > > > > > > > nand: mxs_nand: use self init'. With this particular patch nand bbt
> > > > > > > > scanning would crash the board because of nand_chip.scan_btt not being
> > > > > > > > assigned. This was later fixed in
> > > > > > > > '96d0be07e7498e7174daa6f3b56fc807b9feb71d MTD: nand: mxs_nand_spl: Fix
> > > > > > > > empty function pointer for BBT' but cherry-picking that on top of
> > > > > > > > 5346c31 fixes the immediate crash while scanning but then I find that
> > > > > > > > mxs_read_page_ecc() hangs on the 4th page of reading u-boot.img from
> > > > > > > > the NAND. This gets worse 2 patches later where in
> > > > > > > > '28897e8d21f8e197e259a91c693de09cd81f2d5a: mtd: nand: mxs_nand: use
> > > > > > > > structure for BCH geometry' I find that the first byte of every page
> > > > > > > > read is wrong because mxs_nand_swap_block_mark() is getting called on
> > > > > > > > the page which swaps the first bytes with oob.
> > > > > > > >
> > > > > > > > There are several IMX6 boards out there using both NAND and SPL I
> > > > > > > > believe that I would assume were broken by this series. Any ideas on
> > > > > > > > the proper resolution?
> > > > > > >
> > > > > >
> > > > > > Look like 2017.03 can be stable boot from nand as for as my test is concern.
> > > > > >
> > > > > > We are also trying hard using git bisect, but seems like multiple breakings.
> > > > > >
> > > > > > Will keep posted if something move further.
> > > > >
> > > > >
> > > > > From a different thread, someone was able to test these patches and
> > > > > found they fixed their booting issues:
> > > > >
> > > > >  There was a broken function pointer here that was fixed and applied
> > > > >  the imx-master, but pending merge with master
> > > > >  http://patchwork.ozlabs.org/patch/1019440/
> > > >
> > > > right, this one was the 96d0be07 merged upstream already. I'm not
> > > > clear how any NAND SPL would have worked after Sefan's series back in
> > > > June without this one.
> > > >
> > >
> > > >>SPL: board_init_r()
> > > spl_init
> > > Trying to boot from NAND
> > > spl: nand - using hw ecc
> > > 0x2c:0xdc erasesize=262144 (>>18)
> > > writesize=4096 (>>12)
> > > oobsize=224
> > > chipsize=536870912
> > > nand_spl_load_image offset:0x00200000 len:64 page:512
> > > SPL: payload image: U-Boot 2019.04-rc3-dirty for imx� load addr:
> > > 0x177fffc0 size: 635435
> > > nand_spl_load_image offset:0x00200000 len:635435 page:512
> > > is_badblock offs=0x00240000 block:9 page:576
> > > is_badblock offs=0x00280000 block:10 page:640
> > > Jumping to U-Boot
> > > loaded - jumping to U-Boot...
> > > image entry point: 0x17800000
> > >
> > > I'm stuck here. Booting from mmc is fine
> > >
> > > Michael
> >
> > Michael,
> >
> > What code are you running (git sha) and what board?
> >
> > Make sure you have 04568bd0b6 MTD: nand: mxs_nand: Allow driver to
> > auto setup ECC in SPL
> >
>
> Top of master and I have that commit included. Can I know one imx6 board now
> that can boot from Nand?
One valid is here

U-Boot SPL 2017.03 (Mar 05 2019 - 18:15:17)
Trying to boot from NAND
: 512 MiB


U-Boot 2017.03 (Mar 05 2019 - 18:15:17 +0100)

CPU:   Freescale i.MX6SOLO rev1.3 996 MHz (running at 792 MHz)
CPU:   Extended Commercial temperature grade (-20C to 105C) at 54C
Reset cause: WDOG
Model: Engicam i.CoreM6 DualLite/Solo Starter Kit
DRAM:  256 MiB
NAND:  512 MiB
MMC:   FSL_SDHC: 0
*** Warning - bad CRC, using default environment

No panel detected: default to Amp-WD
Display: Amp-WD (800x480)
In:    serial
Out:   serial
Err:   serial
Net:
Error: ethernet at 02188000 address not set.


>
> Michael
>
> > Tim
>
>
>
> --
> | Michael Nazzareno Trimarchi                     Amarula Solutions BV |
> | COO  -  Founder                                      Cruquiuskade 47 |
> | +31(0)851119172                                 Amsterdam 1018 AM NL |
> |                  [`as] http://www.amarulasolutions.com               |



-- 
| Michael Nazzareno Trimarchi                     Amarula Solutions BV |
| COO  -  Founder                                      Cruquiuskade 47 |
| +31(0)851119172                                 Amsterdam 1018 AM NL |
|                  [`as] http://www.amarulasolutions.com               |

[U-Boot] IMX6 NAND boot regression

[Tim Harvey]

On Tue, Mar 5, 2019 at 9:00 AM Michael Nazzareno Trimarchi
<michael@amarulasolutions.com> wrote:
>
> Hi Tim
>
> On Tue, Mar 5, 2019 at 5:54 PM Tim Harvey <tharvey@gateworks.com> wrote:
> >
> > On Tue, Mar 5, 2019 at 8:41 AM Michael Nazzareno Trimarchi
> > <michael@amarulasolutions.com> wrote:
> > >
> > > HI all
> > >
> > > On Mon, Feb 4, 2019 at 7:14 PM Tim Harvey <tharvey@gateworks.com> wrote:
> > > >
> > > > On Sat, Feb 2, 2019 at 5:30 AM Adam Ford <aford173@gmail.com> wrote:
> > > > >
> > > > > On Sat, Feb 2, 2019 at 12:29 AM Jagan Teki <jagan@amarulasolutions.com> wrote:
> > > > > >
> > > > > > +Adam, Shyam
> > > > > >
> > > > > > On Sat, 2 Feb, 2019, 8:49 AM Stefan Agner <stefan.agner@toradex.com wrote:
> > > > > >
> > > > > > > Hi Tim,
> > > > > > >
> > > > > > > On 02.02.19 03:32, Tim Harvey wrote:
> > > > > > > > Stefan,
> > > > > > > >
> > > > > > > > I'm trying to track down an IMX6 SPL NAND boot regression that started
> > > > > > > > in v2018.07 with your patch series to mxs_nand.
> > > > > > >
> > > > > > > I am sorry about that. Unfortunately I did not had a design at hand where
> > > > > > > I was able to test the NAND driver in SPL...
> > > > > > >
> > > > > > > >
> > > > > > > > I bisected it back to '5346c31e305a37d39f535cc0d5ae87d8b7e81230 mtd:
> > > > > > > > nand: mxs_nand: use self init'. With this particular patch nand bbt
> > > > > > > > scanning would crash the board because of nand_chip.scan_btt not being
> > > > > > > > assigned. This was later fixed in
> > > > > > > > '96d0be07e7498e7174daa6f3b56fc807b9feb71d MTD: nand: mxs_nand_spl: Fix
> > > > > > > > empty function pointer for BBT' but cherry-picking that on top of
> > > > > > > > 5346c31 fixes the immediate crash while scanning but then I find that
> > > > > > > > mxs_read_page_ecc() hangs on the 4th page of reading u-boot.img from
> > > > > > > > the NAND. This gets worse 2 patches later where in
> > > > > > > > '28897e8d21f8e197e259a91c693de09cd81f2d5a: mtd: nand: mxs_nand: use
> > > > > > > > structure for BCH geometry' I find that the first byte of every page
> > > > > > > > read is wrong because mxs_nand_swap_block_mark() is getting called on
> > > > > > > > the page which swaps the first bytes with oob.
> > > > > > > >
> > > > > > > > There are several IMX6 boards out there using both NAND and SPL I
> > > > > > > > believe that I would assume were broken by this series. Any ideas on
> > > > > > > > the proper resolution?
> > > > > > >
> > > > > >
> > > > > > Look like 2017.03 can be stable boot from nand as for as my test is concern.
> > > > > >
> > > > > > We are also trying hard using git bisect, but seems like multiple breakings.
> > > > > >
> > > > > > Will keep posted if something move further.
> > > > >
> > > > >
> > > > > From a different thread, someone was able to test these patches and
> > > > > found they fixed their booting issues:
> > > > >
> > > > >  There was a broken function pointer here that was fixed and applied
> > > > >  the imx-master, but pending merge with master
> > > > >  http://patchwork.ozlabs.org/patch/1019440/
> > > >
> > > > right, this one was the 96d0be07 merged upstream already. I'm not
> > > > clear how any NAND SPL would have worked after Sefan's series back in
> > > > June without this one.
> > > >
> > >
> > > >>SPL: board_init_r()
> > > spl_init
> > > Trying to boot from NAND
> > > spl: nand - using hw ecc
> > > 0x2c:0xdc erasesize=262144 (>>18)
> > > writesize=4096 (>>12)
> > > oobsize=224
> > > chipsize=536870912
> > > nand_spl_load_image offset:0x00200000 len:64 page:512
> > > SPL: payload image: U-Boot 2019.04-rc3-dirty for imx� load addr:
> > > 0x177fffc0 size: 635435
> > > nand_spl_load_image offset:0x00200000 len:635435 page:512
> > > is_badblock offs=0x00240000 block:9 page:576
> > > is_badblock offs=0x00280000 block:10 page:640
> > > Jumping to U-Boot
> > > loaded - jumping to U-Boot...
> > > image entry point: 0x17800000
> > >
> > > I'm stuck here. Booting from mmc is fine
> > >
> > > Michael
> >
> > Michael,
> >
> > What code are you running (git sha) and what board?
> >
> > Make sure you have 04568bd0b6 MTD: nand: mxs_nand: Allow driver to
> > auto setup ECC in SPL
> >
>
> Top of master and I have that commit included. Can I know one imx6 board now
> that can boot from Nand?
>

Michael,

I just built v2019.04-rc3 for gwventana_nand_defconfig and booted it
fine on a board with a 2GiB Cypress NAND flash. This uses NAND and SPL
(and would not boot before the mentioned patch).

Tim

[U-Boot] IMX6 NAND boot regression

[Michael Nazzareno Trimarchi]

Hi

On Tue, Mar 5, 2019 at 6:20 PM Tim Harvey <tharvey@gateworks.com> wrote:
>
> On Tue, Mar 5, 2019 at 9:00 AM Michael Nazzareno Trimarchi
> <michael@amarulasolutions.com> wrote:
> >
> > Hi Tim
> >
> > On Tue, Mar 5, 2019 at 5:54 PM Tim Harvey <tharvey@gateworks.com> wrote:
> > >
> > > On Tue, Mar 5, 2019 at 8:41 AM Michael Nazzareno Trimarchi
> > > <michael@amarulasolutions.com> wrote:
> > > >
> > > > HI all
> > > >
> > > > On Mon, Feb 4, 2019 at 7:14 PM Tim Harvey <tharvey@gateworks.com> wrote:
> > > > >
> > > > > On Sat, Feb 2, 2019 at 5:30 AM Adam Ford <aford173@gmail.com> wrote:
> > > > > >
> > > > > > On Sat, Feb 2, 2019 at 12:29 AM Jagan Teki <jagan@amarulasolutions.com> wrote:
> > > > > > >
> > > > > > > +Adam, Shyam
> > > > > > >
> > > > > > > On Sat, 2 Feb, 2019, 8:49 AM Stefan Agner <stefan.agner@toradex.com wrote:
> > > > > > >
> > > > > > > > Hi Tim,
> > > > > > > >
> > > > > > > > On 02.02.19 03:32, Tim Harvey wrote:
> > > > > > > > > Stefan,
> > > > > > > > >
> > > > > > > > > I'm trying to track down an IMX6 SPL NAND boot regression that started
> > > > > > > > > in v2018.07 with your patch series to mxs_nand.
> > > > > > > >
> > > > > > > > I am sorry about that. Unfortunately I did not had a design at hand where
> > > > > > > > I was able to test the NAND driver in SPL...
> > > > > > > >
> > > > > > > > >
> > > > > > > > > I bisected it back to '5346c31e305a37d39f535cc0d5ae87d8b7e81230 mtd:
> > > > > > > > > nand: mxs_nand: use self init'. With this particular patch nand bbt
> > > > > > > > > scanning would crash the board because of nand_chip.scan_btt not being
> > > > > > > > > assigned. This was later fixed in
> > > > > > > > > '96d0be07e7498e7174daa6f3b56fc807b9feb71d MTD: nand: mxs_nand_spl: Fix
> > > > > > > > > empty function pointer for BBT' but cherry-picking that on top of
> > > > > > > > > 5346c31 fixes the immediate crash while scanning but then I find that
> > > > > > > > > mxs_read_page_ecc() hangs on the 4th page of reading u-boot.img from
> > > > > > > > > the NAND. This gets worse 2 patches later where in
> > > > > > > > > '28897e8d21f8e197e259a91c693de09cd81f2d5a: mtd: nand: mxs_nand: use
> > > > > > > > > structure for BCH geometry' I find that the first byte of every page
> > > > > > > > > read is wrong because mxs_nand_swap_block_mark() is getting called on
> > > > > > > > > the page which swaps the first bytes with oob.
> > > > > > > > >
> > > > > > > > > There are several IMX6 boards out there using both NAND and SPL I
> > > > > > > > > believe that I would assume were broken by this series. Any ideas on
> > > > > > > > > the proper resolution?
> > > > > > > >
> > > > > > >
> > > > > > > Look like 2017.03 can be stable boot from nand as for as my test is concern.
> > > > > > >
> > > > > > > We are also trying hard using git bisect, but seems like multiple breakings.
> > > > > > >
> > > > > > > Will keep posted if something move further.
> > > > > >
> > > > > >
> > > > > > From a different thread, someone was able to test these patches and
> > > > > > found they fixed their booting issues:
> > > > > >
> > > > > >  There was a broken function pointer here that was fixed and applied
> > > > > >  the imx-master, but pending merge with master
> > > > > >  http://patchwork.ozlabs.org/patch/1019440/
> > > > >
> > > > > right, this one was the 96d0be07 merged upstream already. I'm not
> > > > > clear how any NAND SPL would have worked after Sefan's series back in
> > > > > June without this one.
> > > > >
> > > >
> > > > >>SPL: board_init_r()
> > > > spl_init
> > > > Trying to boot from NAND
> > > > spl: nand - using hw ecc
> > > > 0x2c:0xdc erasesize=262144 (>>18)
> > > > writesize=4096 (>>12)
> > > > oobsize=224
> > > > chipsize=536870912
> > > > nand_spl_load_image offset:0x00200000 len:64 page:512
> > > > SPL: payload image: U-Boot 2019.04-rc3-dirty for imx� load addr:
> > > > 0x177fffc0 size: 635435
> > > > nand_spl_load_image offset:0x00200000 len:635435 page:512
> > > > is_badblock offs=0x00240000 block:9 page:576
> > > > is_badblock offs=0x00280000 block:10 page:640
> > > > Jumping to U-Boot
> > > > loaded - jumping to U-Boot...
> > > > image entry point: 0x17800000
> > > >
> > > > I'm stuck here. Booting from mmc is fine
> > > >
> > > > Michael
> > >
> > > Michael,
> > >
> > > What code are you running (git sha) and what board?
> > >
> > > Make sure you have 04568bd0b6 MTD: nand: mxs_nand: Allow driver to
> > > auto setup ECC in SPL
> > >
> >
> > Top of master and I have that commit included. Can I know one imx6 board now
> > that can boot from Nand?
> >
>
> Michael,
>
> I just built v2019.04-rc3 for gwventana_nand_defconfig and booted it
> fine on a board with a 2GiB Cypress NAND flash. This uses NAND and SPL
> (and would not boot before the mentioned patch).
>

diff --git a/configs/imx6dl_icore_nand_defconfig
b/configs/imx6dl_icore_nand_defconfig
index c34c515080..69c45b948b 100644
--- a/configs/imx6dl_icore_nand_defconfig
+++ b/configs/imx6dl_icore_nand_defconfig
@@ -4,6 +4,7 @@ CONFIG_SYS_TEXT_BASE=0x17800000
 CONFIG_SPL_GPIO_SUPPORT=y
 CONFIG_SPL_LIBCOMMON_SUPPORT=y
 CONFIG_SPL_LIBGENERIC_SUPPORT=y
+CONFIG_SYS_MALLOC_F_LEN=0x2000
 CONFIG_TARGET_MX6Q_ENGICAM=y
 CONFIG_SPL_SERIAL_SUPPORT=y
 CONFIG_SPL=y

I'm checking but seems to boot now

Michael
> Tim



-- 
| Michael Nazzareno Trimarchi                     Amarula Solutions BV |
| COO  -  Founder                                      Cruquiuskade 47 |
| +31(0)851119172                                 Amsterdam 1018 AM NL |
|                  [`as] http://www.amarulasolutions.com               |