Hi Stefan,
On Fri, Jan 30, 2015 at 5:20 PM, Stefan Wahren <[email protected]> wrote:
> According to i.MX23 and i.MX28 reference manual [1],[2] the fractional
> clock control register is 32-bit wide, but is separated in 4 parts.
> So write instructions must not apply to more than 1 part at once.
>
> The clk init for the i.MX28 violates this restriction and all the other
> accesses on that register suggest that there isn't such a restriction.
>
> This patch restricts the access to this register to byte instructions and
> extends the comment in the init functions.
>
> Btw the imx23 init now uses a R-M-W sequence just like imx28 init
> to avoid any clock glitches.
>
> The changes has been tested with a i.MX23 and a i.MX28 board.
>
> [1] - http://cache.freescale.com/files/dsp/doc/ref_manual/IMX23RM.pdf
> [2] - http://cache.freescale.com/files/dsp/doc/ref_manual/MCIMX28RM.pdf
>
> Signed-off-by: Stefan Wahren <[email protected]>
> Reviewed-by: Marek Vasut <[email protected]>
> ---
>
> Changes in V2:
> - use relaxed access operations in clk-ref
With this patch applied mx28evk cannot probe SPI NOR flash:
m25p80 spi1.0: unrecognized JEDEC id bytes: bf, 24, 40
Reverting it from linux-next, then the SPI NOR probe correctly.
m25p80 spi1.0: sst25vf016b (2048 Kbytes)
Any ideas?
Thanks for the suggestion, Marek!
Regards,
Fabio Estevam
Hi Fabio,
Am 10.02.2015 um 13:52 schrieb Fabio Estevam:
> Hi Stefan,
>
> On Fri, Jan 30, 2015 at 5:20 PM, Stefan Wahren <[email protected]> wrote:
>> According to i.MX23 and i.MX28 reference manual [1],[2] the fractional
>> clock control register is 32-bit wide, but is separated in 4 parts.
>> So write instructions must not apply to more than 1 part at once.
>>
>> The clk init for the i.MX28 violates this restriction and all the other
>> accesses on that register suggest that there isn't such a restriction.
>>
>> This patch restricts the access to this register to byte instructions and
>> extends the comment in the init functions.
>>
>> Btw the imx23 init now uses a R-M-W sequence just like imx28 init
>> to avoid any clock glitches.
>>
>> The changes has been tested with a i.MX23 and a i.MX28 board.
>>
>> [1] - http://cache.freescale.com/files/dsp/doc/ref_manual/IMX23RM.pdf
>> [2] - http://cache.freescale.com/files/dsp/doc/ref_manual/MCIMX28RM.pdf
>>
>> Signed-off-by: Stefan Wahren <[email protected]>
>> Reviewed-by: Marek Vasut <[email protected]>
>> ---
>>
>> Changes in V2:
>> - use relaxed access operations in clk-ref
> With this patch applied mx28evk cannot probe SPI NOR flash:
>
> m25p80 spi1.0: unrecognized JEDEC id bytes: bf, 24, 40
>
> Reverting it from linux-next, then the SPI NOR probe correctly.
>
> m25p80 spi1.0: sst25vf016b (2048 Kbytes)
>
> Any ideas?
sorry no. But i will try to get a mx28evk to reproduce the problem and
narrow down which part of the patch causes this problem.
Did you see any problem with the clock control register settings?
Stefan
>
> Thanks for the suggestion, Marek!
>
> Regards,
>
> Fabio Estevam
Hi Stefan,
On Tue, Feb 10, 2015 at 11:05 AM, Stefan Wahren <[email protected]> wrote:
> sorry no. But i will try to get a mx28evk to reproduce the problem and
Just a comment: mx28evk comes without SPI NOR flash from the factory.
I have populated one in my mx28evk (slot U49).
> narrow down which part of the patch causes this problem.
>
> Did you see any problem with the clock control register settings?
I haven't inspected the clock control registers yet.
Regards,
Fabio Estevam
Hi Fabio,
Am 10.02.2015 um 14:09 schrieb Fabio Estevam:
> Hi Stefan,
>
> On Tue, Feb 10, 2015 at 11:05 AM, Stefan Wahren <[email protected]> wrote:
>
>> sorry no. But i will try to get a mx28evk to reproduce the problem and
> Just a comment: mx28evk comes without SPI NOR flash from the factory.
> I have populated one in my mx28evk (slot U49).
i tought it would be easy because of this nice flash socket, but it's
for NAND :-(
Could you apply only the clk-imx28.c part of my patch and see what happens?
Stefan
>
>> narrow down which part of the patch causes this problem.
>>
>> Did you see any problem with the clock control register settings?
> I haven't inspected the clock control registers yet.
>
> Regards,
>
> Fabio Estevam
Hi Stefan,
On Tue, Feb 10, 2015 at 11:55 AM, Stefan Wahren <[email protected]> wrote:
> Could you apply only the clk-imx28.c part of my patch and see what happens?
If I apply only the clk-imx28.c part of your patch I can successfully
probe the SPI NOR.
Thanks
Hi Fabio,
> Fabio Estevam <[email protected]> hat am 10. Februar 2015 um 16:06
> geschrieben:
>
>
> Hi Stefan,
>
> On Tue, Feb 10, 2015 at 11:55 AM, Stefan Wahren <[email protected]>
> wrote:
>
> > Could you apply only the clk-imx28.c part of my patch and see what happens?
>
> If I apply only the clk-imx28.c part of your patch I can successfully
> probe the SPI NOR.
thanks this is very helpful. I built the linux-next for my Duckbill and add the
SSP2 section from imx28-evk.dts into imx28-duckbill.dts.
Without my patch i get the following for HW_CLKCTRL_FRAC0:
./memwatch -a 0x800401B0
0x800401b0: 0x5e5b5513
With my patch i get:
./memwatch -a 0x800401B0
0x800401b0: 0x5e1b5513
So it looks like a problem in my patch.
I orded such a flash chip, but it will take some time until i can use it with my
hardware.
Stefan
>
> Thanks
>
> _______________________________________________
> linux-arm-kernel mailing list
> [email protected]
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Hi Stefan,
On Tue, Feb 10, 2015 at 7:24 PM, Stefan Wahren <[email protected]> wrote:
> thanks this is very helpful. I built the linux-next for my Duckbill and add the
> SSP2 section from imx28-evk.dts into imx28-duckbill.dts.
>
> Without my patch i get the following for HW_CLKCTRL_FRAC0:
>
> ./memwatch -a 0x800401B0
>
> 0x800401b0: 0x5e5b5513
>
> With my patch i get:
>
> ./memwatch -a 0x800401B0
>
> 0x800401b0: 0x5e1b5513
>
> So it looks like a problem in my patch.
Yes, let's try to get the same value HW_CLKCTRL_FRAC0.
> I orded such a flash chip, but it will take some time until i can use it with my
> hardware.
Thanks for doing this.
Maybe if you find out a way to fix the calculation of
HW_CLKCTRL_FRAC0, then I can test it on my board.
Regards,
Fabio Estevam
On Tuesday, February 10, 2015 at 10:54:52 PM, Fabio Estevam wrote:
> Hi Stefan,
>
> On Tue, Feb 10, 2015 at 7:24 PM, Stefan Wahren <[email protected]> wrote:
> > thanks this is very helpful. I built the linux-next for my Duckbill and
> > add the SSP2 section from imx28-evk.dts into imx28-duckbill.dts.
> >
> > Without my patch i get the following for HW_CLKCTRL_FRAC0:
> >
> > ./memwatch -a 0x800401B0
> >
> > 0x800401b0: 0x5e5b5513
> >
> > With my patch i get:
> >
> > ./memwatch -a 0x800401B0
> >
> > 0x800401b0: 0x5e1b5513
> >
> > So it looks like a problem in my patch.
>
> Yes, let's try to get the same value HW_CLKCTRL_FRAC0.
>
> > I orded such a flash chip, but it will take some time until i can use it
> > with my hardware.
>
> Thanks for doing this.
>
> Maybe if you find out a way to fix the calculation of
> HW_CLKCTRL_FRAC0, then I can test it on my board.
Hi,
the difference is this 0x40 bit, right ? That's _STABLE bit, so it means
the clock are not stable, right ? Why would that happen in the first place?
Best regards,
Marek Vasut
Quoting Marek Vasut (2015-02-10 14:07:51)
> On Tuesday, February 10, 2015 at 10:54:52 PM, Fabio Estevam wrote:
> > Hi Stefan,
> >
> > On Tue, Feb 10, 2015 at 7:24 PM, Stefan Wahren <[email protected]> wrote:
> > > thanks this is very helpful. I built the linux-next for my Duckbill and
> > > add the SSP2 section from imx28-evk.dts into imx28-duckbill.dts.
> > >
> > > Without my patch i get the following for HW_CLKCTRL_FRAC0:
> > >
> > > ./memwatch -a 0x800401B0
> > >
> > > 0x800401b0: 0x5e5b5513
> > >
> > > With my patch i get:
> > >
> > > ./memwatch -a 0x800401B0
> > >
> > > 0x800401b0: 0x5e1b5513
> > >
> > > So it looks like a problem in my patch.
> >
> > Yes, let's try to get the same value HW_CLKCTRL_FRAC0.
> >
> > > I orded such a flash chip, but it will take some time until i can use it
> > > with my hardware.
> >
> > Thanks for doing this.
> >
> > Maybe if you find out a way to fix the calculation of
> > HW_CLKCTRL_FRAC0, then I can test it on my board.
>
> Hi,
>
> the difference is this 0x40 bit, right ? That's _STABLE bit, so it means
> the clock are not stable, right ? Why would that happen in the first place?
Can you dump all the registers related to all of the clocks provided by
your clock driver, both with and without your patch? Then just diff
them. Might be more deltas than just this one register.
Regards,
Mike
>
> Best regards,
> Marek Vasut
Hi Stefan,
On Tue, Feb 10, 2015 at 7:24 PM, Stefan Wahren <[email protected]> wrote:
> Hi Fabio,
>
>> Fabio Estevam <[email protected]> hat am 10. Februar 2015 um 16:06
>> geschrieben:
>>
>>
>> Hi Stefan,
>>
>> On Tue, Feb 10, 2015 at 11:55 AM, Stefan Wahren <[email protected]>
>> wrote:
>>
>> > Could you apply only the clk-imx28.c part of my patch and see what happens?
>>
>> If I apply only the clk-imx28.c part of your patch I can successfully
>> probe the SPI NOR.
>
> thanks this is very helpful. I built the linux-next for my Duckbill and add the
> SSP2 section from imx28-evk.dts into imx28-duckbill.dts.
>
> Without my patch i get the following for HW_CLKCTRL_FRAC0:
>
> ./memwatch -a 0x800401B0
>
> 0x800401b0: 0x5e5b5513
>
> With my patch i get:
>
> ./memwatch -a 0x800401B0
>
> 0x800401b0: 0x5e1b5513
I always get 0x5e5b5513 with or without your patch.
Hi Fabio,
> Fabio Estevam <[email protected]> hat am 11. Februar 2015 um 17:58
> geschrieben:
>
>
> Hi Stefan,
>
> On Tue, Feb 10, 2015 at 7:24 PM, Stefan Wahren <[email protected]> wrote:
> > Hi Fabio,
> >
> >> Fabio Estevam <[email protected]> hat am 10. Februar 2015 um 16:06
> >> geschrieben:
> >>
> >>
> >> Hi Stefan,
> >>
> >> On Tue, Feb 10, 2015 at 11:55 AM, Stefan Wahren <[email protected]>
> >> wrote:
> >>
> >> > Could you apply only the clk-imx28.c part of my patch and see what
> >> > happens?
> >>
> >> If I apply only the clk-imx28.c part of your patch I can successfully
> >> probe the SPI NOR.
> >
> > thanks this is very helpful. I built the linux-next for my Duckbill and add
> > the
> > SSP2 section from imx28-evk.dts into imx28-duckbill.dts.
> >
> > Without my patch i get the following for HW_CLKCTRL_FRAC0:
> >
> > ./memwatch -a 0x800401B0
> >
> > 0x800401b0: 0x5e5b5513
> >
> > With my patch i get:
> >
> > ./memwatch -a 0x800401B0
> >
> > 0x800401b0: 0x5e1b5513
>
> I always get 0x5e5b5513 with or without your patch.
very strange. Do you have any idea why IO1_STABLE is permanent low?
Here are the register dumps as requested by Mike.
Without this patch after boot
0x80040000: 0x00060000
0x80040010: 0x800004b1
0x80040050: 0x00011001
0x80040080: 0x64000001
0x80040090: 0x00000001
0x800400a0: 0x80000001
0x800400b0: 0x00000002
0x800400c0: 0xa0000001
0x800401b0: 0x5e5b5513
0x800401c0: 0x00929292
0x800401d0: 0x00004104
With this patch after boot
0x80040000: 0x00060000
0x80040010: 0x800004b1
0x80040050: 0x00011001
0x80040080: 0x64000001
0x80040090: 0x00000001
0x800400a0: 0x80000001
0x800400b0: 0x00000002
0x800400c0: 0xa0000001
0x800401b0: 0x5e1b5513
0x800401c0: 0x00929292
0x800401d0: 0x00004104
So only IO1_STABLE (0x800401b0) is different.
If i restore clk_ref_set_rate() from clk-ref.c after the complete patch is
applied, the issue with the IO1_STABLE bit disappears.
Can you confirm the behavior according to your flash issue?
I think it would be the best to revert my patch. Sorry for the trouble.
Stefan
>
> _______________________________________________
> linux-arm-kernel mailing list
> [email protected]
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On Wed, Feb 11, 2015 at 6:31 PM, Stefan Wahren <[email protected]> wrote:
>> I always get 0x5e5b5513 with or without your patch.
>
> very strange. Do you have any idea why IO1_STABLE is permanent low?
On my case it is always 1.
> Can you confirm the behavior according to your flash issue?
In my tests IO1_STABLE stays the same.
> I think it would be the best to revert my patch. Sorry for the trouble.
To be on the safe side, I agree.
Could you please send a revert patch?
Thanks
Hi Fabio,
> Fabio Estevam <[email protected]> hat am 11. Februar 2015 um 22:10
> geschrieben:
>
>
> On Wed, Feb 11, 2015 at 6:31 PM, Stefan Wahren <[email protected]> wrote:
>
> >> I always get 0x5e5b5513 with or without your patch.
> >
> > very strange. Do you have any idea why IO1_STABLE is permanent low?
>
> On my case it is always 1.
i expected the same behavior on my hardware.
Do you use u-boot as bootloader?
>
> > Can you confirm the behavior according to your flash issue?
>
> In my tests IO1_STABLE stays the same.
This wasn't the intension of my second question. I wanted to know about the
state of the SPI NOR flash detection process.
Does it sucessed if you apply the patch, but revert the changes in
clk_ref_set_rate() from clk-ref.c?
>
> > I think it would be the best to revert my patch. Sorry for the trouble.
>
> To be on the safe side, I agree.
>
> Could you please send a revert patch?
Sure.
>
> Thanks
>
Stefan
Hi Stefan,
On Thu, Feb 12, 2015 at 4:59 PM, Stefan Wahren <[email protected]> wrote:
> Hi Fabio,
>
>> Fabio Estevam <[email protected]> hat am 11. Februar 2015 um 22:10
>> geschrieben:
>>
>>
>> On Wed, Feb 11, 2015 at 6:31 PM, Stefan Wahren <[email protected]> wrote:
>>
>> >> I always get 0x5e5b5513 with or without your patch.
>> >
>> > very strange. Do you have any idea why IO1_STABLE is permanent low?
>>
>> On my case it is always 1.
>
> i expected the same behavior on my hardware.
>
> Do you use u-boot as bootloader?
Yes, I do.
>>
>> > Can you confirm the behavior according to your flash issue?
>>
>> In my tests IO1_STABLE stays the same.
>
> This wasn't the intension of my second question. I wanted to know about the
> state of the SPI NOR flash detection process.
>
> Does it sucessed if you apply the patch, but revert the changes in
> clk_ref_set_rate() from clk-ref.c?
I don't have my mx28evk setup available at the moment, but when I
applied your patch and reverted all the changes in clk-ref.c, then the
SPI flash detection works.
I haven't tested to only reverting the changes inside
clk_ref_set_rate(), but I can do it tomorrow.
Regards,
Fabio Estevam
Hi Fabio,
> Fabio Estevam <[email protected]> hat am 12. Februar 2015 um 20:08
> geschrieben:
>
>
> Hi Stefan,
>
> On Thu, Feb 12, 2015 at 4:59 PM, Stefan Wahren <[email protected]> wrote:
> > Hi Fabio,
> >
> >> Fabio Estevam <[email protected]> hat am 11. Februar 2015 um 22:10
> >> geschrieben:
> >>
> >>
> >> On Wed, Feb 11, 2015 at 6:31 PM, Stefan Wahren <[email protected]>
> >> wrote:
> >>
> >> >> I always get 0x5e5b5513 with or without your patch.
> >> >
> >> > very strange. Do you have any idea why IO1_STABLE is permanent low?
> >>
> >> On my case it is always 1.
> >
> > i expected the same behavior on my hardware.
> >
> > Do you use u-boot as bootloader?
>
> Yes, I do.
i will try to test it with u-boot.
>
> >>
> >> > Can you confirm the behavior according to your flash issue?
> >>
> >> In my tests IO1_STABLE stays the same.
> >
> > This wasn't the intension of my second question. I wanted to know about the
> > state of the SPI NOR flash detection process.
> >
> > Does it sucessed if you apply the patch, but revert the changes in
> > clk_ref_set_rate() from clk-ref.c?
>
> I don't have my mx28evk setup available at the moment, but when I
> applied your patch and reverted all the changes in clk-ref.c, then the
> SPI flash detection works.
>
> I haven't tested to only reverting the changes inside
> clk_ref_set_rate(), but I can do it tomorrow.
I think the reason for the problem in the flash detection is caused by the
misaligned access on the frac register.
Maybe you want to try the following after the second patch is reverted.
Stefan
------------>8----------------------------------------------------------
diff --git a/drivers/clk/mxs/clk-imx23.c b/drivers/clk/mxs/clk-imx23.c
index 9fc9359..87969e3 100644
--- a/drivers/clk/mxs/clk-imx23.c
+++ b/drivers/clk/mxs/clk-imx23.c
@@ -73,8 +73,10 @@ static void __init clk_misc_init(void)
* 480 MHz seems too high to be ssp clock source directly,
* so set frac to get a 288 MHz ref_io.
*/
- writel_relaxed(0x3f << BP_FRAC_IOFRAC, FRAC + CLR);
- writel_relaxed(30 << BP_FRAC_IOFRAC, FRAC + SET);
+ val = readl_relaxed(FRAC);
+ val &= ~(0x3f << BP_FRAC_IOFRAC);
+ val |= 30 << BP_FRAC_IOFRAC;
+ writel_relaxed(val, FRAC);
}
static const char *sel_pll[] __initconst = { "pll", "ref_xtal", };
diff --git a/drivers/clk/mxs/clk-imx28.c b/drivers/clk/mxs/clk-imx28.c
index a6c3501..e47ad69 100644
--- a/drivers/clk/mxs/clk-imx28.c
+++ b/drivers/clk/mxs/clk-imx28.c
@@ -118,10 +118,15 @@ static void __init clk_misc_init(void)
/*
* 480 MHz seems too high to be ssp clock source directly,
* so set frac0 to get a 288 MHz ref_io0 and ref_io1.
+ * According to reference manual we must modify frac bytewise.
*/
val = readl_relaxed(FRAC0);
- val &= ~((0x3f << BP_FRAC0_IO0FRAC) | (0x3f << BP_FRAC0_IO1FRAC));
- val |= (30 << BP_FRAC0_IO0FRAC) | (30 << BP_FRAC0_IO1FRAC);
+ val &= ~(0x3f << BP_FRAC0_IO0FRAC);
+ val |= 30 << BP_FRAC0_IO0FRAC;
+ writel_relaxed(val, FRAC0);
+ val = readl_relaxed(FRAC0);
+ val &= ~(0x3f << BP_FRAC0_IO1FRAC);
+ val |= 30 << BP_FRAC0_IO1FRAC;
writel_relaxed(val, FRAC0);
}
On Monday, February 16, 2015 at 09:24:51 PM, Stefan Wahren wrote:
> Hi Fabio,
>
> > Fabio Estevam <[email protected]> hat am 12. Februar 2015 um 20:08
> > geschrieben:
> >
> >
> > Hi Stefan,
> >
> > On Thu, Feb 12, 2015 at 4:59 PM, Stefan Wahren <[email protected]>
wrote:
> > > Hi Fabio,
> > >
> > >> Fabio Estevam <[email protected]> hat am 11. Februar 2015 um 22:10
> > >> geschrieben:
> > >>
> > >>
> > >> On Wed, Feb 11, 2015 at 6:31 PM, Stefan Wahren
> > >> <[email protected]>
> > >>
> > >> wrote:
> > >> >> I always get 0x5e5b5513 with or without your patch.
> > >> >
> > >> > very strange. Do you have any idea why IO1_STABLE is permanent low?
> > >>
> > >> On my case it is always 1.
> > >
> > > i expected the same behavior on my hardware.
> > >
> > > Do you use u-boot as bootloader?
> >
> > Yes, I do.
>
> i will try to test it with u-boot.
>
> > >> > Can you confirm the behavior according to your flash issue?
> > >>
> > >> In my tests IO1_STABLE stays the same.
> > >
> > > This wasn't the intension of my second question. I wanted to know about
> > > the state of the SPI NOR flash detection process.
> > >
> > > Does it sucessed if you apply the patch, but revert the changes in
> > > clk_ref_set_rate() from clk-ref.c?
> >
> > I don't have my mx28evk setup available at the moment, but when I
> > applied your patch and reverted all the changes in clk-ref.c, then the
> > SPI flash detection works.
> >
> > I haven't tested to only reverting the changes inside
> > clk_ref_set_rate(), but I can do it tomorrow.
>
> I think the reason for the problem in the flash detection is caused by the
> misaligned access on the frac register.
Misaligned ? In which way ? Can you please elaborate on this ?
Hi Fabio,
> Stefan Wahren <[email protected]> hat am 11. Februar 2015 um 21:31
> geschrieben:
>
>
> Hi Fabio,
>
> > Fabio Estevam <[email protected]> hat am 11. Februar 2015 um 17:58
> > geschrieben:
> >
> >
> > Hi Stefan,
> >
> > On Tue, Feb 10, 2015 at 7:24 PM, Stefan Wahren <[email protected]>
> > wrote:
> > > Hi Fabio,
> > >
> > >> Fabio Estevam <[email protected]> hat am 10. Februar 2015 um 16:06
> > >> geschrieben:
> > >>
> > >>
> > >> Hi Stefan,
> > >>
> > >> On Tue, Feb 10, 2015 at 11:55 AM, Stefan Wahren <[email protected]>
> > >> wrote:
> > >>
> > >> > Could you apply only the clk-imx28.c part of my patch and see what
> > >> > happens?
> > >>
> > >> If I apply only the clk-imx28.c part of your patch I can successfully
> > >> probe the SPI NOR.
> > >
> > > thanks this is very helpful. I built the linux-next for my Duckbill and
> > > add
> > > the
> > > SSP2 section from imx28-evk.dts into imx28-duckbill.dts.
> > >
> > > Without my patch i get the following for HW_CLKCTRL_FRAC0:
> > >
> > > ./memwatch -a 0x800401B0
> > >
> > > 0x800401b0: 0x5e5b5513
> > >
> > > With my patch i get:
> > >
> > > ./memwatch -a 0x800401B0
> > >
> > > 0x800401b0: 0x5e1b5513
> >
> > I always get 0x5e5b5513 with or without your patch.
>
> very strange. Do you have any idea why IO1_STABLE is permanent low?
>
> Here are the register dumps as requested by Mike.
>
> Without this patch after boot
>
> 0x80040000: 0x00060000
> 0x80040010: 0x800004b1
> 0x80040050: 0x00011001
> 0x80040080: 0x64000001
> 0x80040090: 0x00000001
> 0x800400a0: 0x80000001
> 0x800400b0: 0x00000002
> 0x800400c0: 0xa0000001
> 0x800401b0: 0x5e5b5513
> 0x800401c0: 0x00929292
> 0x800401d0: 0x00004104
>
> With this patch after boot
>
> 0x80040000: 0x00060000
> 0x80040010: 0x800004b1
> 0x80040050: 0x00011001
> 0x80040080: 0x64000001
> 0x80040090: 0x00000001
> 0x800400a0: 0x80000001
> 0x800400b0: 0x00000002
> 0x800400c0: 0xa0000001
> 0x800401b0: 0x5e1b5513
> 0x800401c0: 0x00929292
> 0x800401d0: 0x00004104
just for the records here is the register dump for the case "patch V2 on
Duckbill with U-Boot instead of imx-bootlets":
0x80040000: 0x00060000
0x80040010: 0x800004b1
0x80040050: 0x00011001
0x80040080: 0x64000001
0x80040090: 0x00000005
0x800400a0: 0x80000001
0x800400b0: 0x00000002
0x800400c0: 0xa0000001
0x800401b0: 0x5e5b5513
0x800401c0: 0x00929292
0x800401d0: 0x00004104
So the issue with IO1_STABLE seems to come from the bootloader.
Do you have any idea which i.MX28 registers additionally could be relevant?
Stefan