[U-Boot] U-Boot stuck after relocation attempt on MX51 board

[U-Boot] U-Boot stuck after relocation attempt on MX51 board

[DaveKucharczyk]

I'm porting U-Boot for an MX51 based board. 

This is the boot sequence with debug on...

U-Boot 2014.07-svn10 (Feb 24 2015 - 15:49:39)

initcall: 9ff85820
U-Boot code: 9FF80000 -> 9FFA6824  BSS: -> 9FFD944C
initcall: 9ff8118c
CPU:   Freescale i.MX51 rev3.0 at 800 MHz
initcall: 9ff858ac
I2C:   ready
initcall: 9ff85894
DRAM:  initcall: 9ff81ff4
initcall: 9ff85a04
Monitor len: 0005944C
Ram size: 10000000
Ram top: A0000000
initcall: 9ff855b0
initcall: 9ff857c8
TLB table from 9fff0000 to 9fff4000
initcall: 9ff855c8
initcall: 9ff8577c
Reserving 357k for U-Boot at: 9ff96000
initcall: 9ff85750
Reserving 1280k for malloc() at: 9fe56000
initcall: 9ff85850
Reserving 88 Bytes for Board Info at: 9fe55fa8
initcall: 9ff855d0
initcall: 9ff8571c
Reserving 216 Bytes for Global Data at: 9fe55ed0
initcall: 9ff856b8
initcall: 9ff855e4
initcall: 9ff859ec
initcall: 9ff85948

RAM Configuration:
Bank #0: 90000000 256 MiB
 
DRAM:  256 MiB
initcall: 9ff8569c
New Stack Pointer is: 9fe55eb0
initcall: 9ff85618
initcall: 9ff85648
Relocation Offset is: 00016000
Relocating to 9ff96000, new gd at 9fe55ed0, sp at 9fe55eb0

And that's where it hangs and resets in a continuous loop. 

I confirmed that the entire init_sequence completed in board_f.c, but never
makes it to board_r.c

So...according to ./arch/arm/lib/crt0.S ...

/* assembly code */

board_init_f          <--we make it out of here

/* assembly code */   <-- stuck somewhere in here

relocate_code           <-- stuck somewhere in here

/* assembly code */   <-- stuck somewhere in here

board_init_r          <--we never make it here

I can't sprinkle any debug statements where it's stuck because it's all
assembly. Before I break out the BDI tomorrow does anyone have any ideas? 

BTW it works on our 512MB board, but not the 256MB board. Thanks.



--
View this message in context: http://u-boot.10912.n7.nabble.com/U-Boot-stuck-after-relocation-attempt-on-MX51-board-tp206738.html
Sent from the U-Boot mailing list archive@Nabble.com.

[U-Boot] U-Boot stuck after relocation attempt on MX51 board

[DaveKucharczyk]

So I can't debug with the BDI3000 because the target keeps on resetting...

This happens over and over...

- TARGET: processing power-up delay
- TARGET: processing reset request
- TARGET: BDI executes scan chain init string
- TARGET: Bypass check 0x00000001 => 0x00000004
- TARGET: JTAG exists check passed
- Core#0: ID code is 0x1BA00477
- Core#0: DP-CSW  is 0xF0000000
- Core#0: DBG-AP  at 0xC0008000
- Core#0: DIDR    is 0x00000000
- TARGET: Reset sequence passed
- TARGET: resetting target passed
- TARGET: processing target startup ....
- TARGET: processing target startup passed
# TARGET: reset detected, restarting target

How can I prevent the reset?



--
View this message in context: http://u-boot.10912.n7.nabble.com/U-Boot-stuck-after-relocation-attempt-on-MX51-board-tp206738p206808.html
Sent from the U-Boot mailing list archive at Nabble.com.

[U-Boot] U-Boot stuck after relocation attempt on MX51 board

[Benoît Thébaudeau]

Dear Dave Kucharczyk,

On Wed, Feb 25, 2015 at 3:19 AM, DaveKucharczyk
<david.kucharczyk@gmail.com> wrote:
> I'm porting U-Boot for an MX51 based board.
>
> This is the boot sequence with debug on...
>
> U-Boot 2014.07-svn10 (Feb 24 2015 - 15:49:39)
>
> initcall: 9ff85820
> U-Boot code: 9FF80000 -> 9FFA6824  BSS: -> 9FFD944C
> initcall: 9ff8118c
> CPU:   Freescale i.MX51 rev3.0 at 800 MHz
> initcall: 9ff858ac
> I2C:   ready
> initcall: 9ff85894
> DRAM:  initcall: 9ff81ff4
> initcall: 9ff85a04
> Monitor len: 0005944C
> Ram size: 10000000
> Ram top: A0000000
> initcall: 9ff855b0
> initcall: 9ff857c8
> TLB table from 9fff0000 to 9fff4000
> initcall: 9ff855c8
> initcall: 9ff8577c
> Reserving 357k for U-Boot at: 9ff96000
> initcall: 9ff85750
> Reserving 1280k for malloc() at: 9fe56000
> initcall: 9ff85850
> Reserving 88 Bytes for Board Info at: 9fe55fa8
> initcall: 9ff855d0
> initcall: 9ff8571c
> Reserving 216 Bytes for Global Data at: 9fe55ed0
> initcall: 9ff856b8
> initcall: 9ff855e4
> initcall: 9ff859ec
> initcall: 9ff85948
>
> RAM Configuration:
> Bank #0: 90000000 256 MiB
>
> DRAM:  256 MiB
> initcall: 9ff8569c
> New Stack Pointer is: 9fe55eb0
> initcall: 9ff85618
> initcall: 9ff85648
> Relocation Offset is: 00016000
> Relocating to 9ff96000, new gd at 9fe55ed0, sp at 9fe55eb0
>
> And that's where it hangs and resets in a continuous loop.
>
> I confirmed that the entire init_sequence completed in board_f.c, but never
> makes it to board_r.c
>
> So...according to ./arch/arm/lib/crt0.S ...
>
> /* assembly code */
>
> board_init_f          <--we make it out of here
>
> /* assembly code */   <-- stuck somewhere in here
>
> relocate_code           <-- stuck somewhere in here
>
> /* assembly code */   <-- stuck somewhere in here
>
> board_init_r          <--we never make it here
>
> I can't sprinkle any debug statements where it's stuck because it's all
> assembly. Before I break out the BDI tomorrow does anyone have any ideas?
>
> BTW it works on our 512MB board, but not the 256MB board. Thanks.

The following needs to be added for i.MX51 and i.MX53 too:
http://lists.denx.de/pipermail/u-boot/2015-February/205849.html

This should fix your issue.

Best regards,
Beno?t

[U-Boot] U-Boot stuck after relocation attempt on MX51 board

[DaveKucharczyk]

I applied the patch, but it still hangs.

The directory tree is different for mx5x vs. MX35

I added relocate.S to...arch/arm/cpu/armv7/mx5/relocate.S

and modified Makefile here...arch/arm/cpu/armv7/mx5/Makefile

Does that seem right?



--
View this message in context: http://u-boot.10912.n7.nabble.com/U-Boot-stuck-after-relocation-attempt-on-MX51-board-tp206738p206846.html
Sent from the U-Boot mailing list archive at Nabble.com.

[U-Boot] U-Boot stuck after relocation attempt on MX51 board

[Fabio Estevam]

Hi Dave,

On Wed, Feb 25, 2015 at 6:23 PM, DaveKucharczyk
<david.kucharczyk@gmail.com> wrote:
> I applied the patch, but it still hangs.
>
> The directory tree is different for mx5x vs. MX35
>
> I added relocate.S to...arch/arm/cpu/armv7/mx5/relocate.S
>
> and modified Makefile here...arch/arm/cpu/armv7/mx5/Makefile
>
> Does that seem right?

I have just tested top of tree U-boot and my mx53loco board boots fine.

It seems your issue is a different one. You are using 2014.07, can you
try it with 2015.01 instead?

Also, you said that your 512MB board version works fine, but the 256MB fails.

I suppose you are using two different binaries for each board, right?
You can't have a single binary for the two boards, unless you use the
SPL approach.

Regards.

Fabio Estevam

[U-Boot] U-Boot stuck after relocation attempt on MX51 board

[DaveKucharczyk]

Fabio Estevam-2 wrote
> Also, you said that your 512MB board version works fine, but the 256MB
> fails.
> 
> I suppose you are using two different binaries for each board, right?
> You can't have a single binary for the two boards, unless you use the
> SPL approach.

Fabio, we use one binary. It has runtime memory discovery via gpio's
(resistor reads). DRAM size is reported correctly from both boards. It just
hangs on the 256MB board. 

We do not have SPL setup.  




--
View this message in context: http://u-boot.10912.n7.nabble.com/U-Boot-stuck-after-relocation-attempt-on-MX51-board-tp206738p206862.html
Sent from the U-Boot mailing list archive at Nabble.com.

[U-Boot] U-Boot stuck after relocation attempt on MX51 board

[Benoît Thébaudeau]

Dear Dave Kucharczyk,

On Wed, Feb 25, 2015 at 11:08 PM, DaveKucharczyk
<david.kucharczyk@gmail.com> wrote:
> Fabio Estevam-2 wrote
>> Also, you said that your 512MB board version works fine, but the 256MB
>> fails.
>>
>> I suppose you are using two different binaries for each board, right?
>> You can't have a single binary for the two boards, unless you use the
>> SPL approach.
>
> Fabio, we use one binary. It has runtime memory discovery via gpio's
> (resistor reads). DRAM size is reported correctly from both boards. It just
> hangs on the 256MB board.
>
> We do not have SPL setup.

You should try with 2015.01 as Fabio suggested.

Also, check the CONFIG_SYS_TEXT_BASE of your board. From your log, I'm
wondering if it's not set too high, resulting in an overlap of the
pre- and post-relocation addresses occupied by your binary in the
256-MiB case.

Best regards,
Beno?t

[U-Boot] U-Boot stuck after relocation attempt on MX51 board

[Albert ARIBAUD]

Hello Beno?t,

On Thu, 26 Feb 2015 00:56:00 +0100, Beno?t Th?baudeau
<benoit.thebaudeau.dev@gmail.com> wrote:
> Dear Dave Kucharczyk,
> 
> On Wed, Feb 25, 2015 at 11:08 PM, DaveKucharczyk
> <david.kucharczyk@gmail.com> wrote:
> > Fabio Estevam-2 wrote
> >> Also, you said that your 512MB board version works fine, but the 256MB
> >> fails.
> >>
> >> I suppose you are using two different binaries for each board, right?
> >> You can't have a single binary for the two boards, unless you use the
> >> SPL approach.
> >
> > Fabio, we use one binary. It has runtime memory discovery via gpio's
> > (resistor reads). DRAM size is reported correctly from both boards. It just
> > hangs on the 256MB board.
> >
> > We do not have SPL setup.
> 
> You should try with 2015.01 as Fabio suggested.
> 
> Also, check the CONFIG_SYS_TEXT_BASE of your board. From your log, I'm
> wondering if it's not set too high, resulting in an overlap of the
> pre- and post-relocation addresses occupied by your binary in the
> 256-MiB case.

/me wonders whether we should not add a test for this situation, with
a conspicuous error message on the console stating that relocation will
probably fail due to overlap.

> Best regards,
> Beno?t

Amicalement,
-- 
Albert.

[U-Boot] U-Boot stuck after relocation attempt on MX51 board

[DaveKucharczyk]

Beno?t Th?baudeau-2 wrote
> Also, check the CONFIG_SYS_TEXT_BASE of your board. From your log, I'm
> wondering if it's not set too high, resulting in an overlap of the
> pre- and post-relocation addresses occupied by your binary in the
> 256-MiB case.

BINGO!!! Good catch Beno?t, thank you. I changed it from 9FF80000 to
9F000000 and now it boots. 

Looking at the original log...it relocated 90KB above text base. Not quite
enough room...
--------
U-Boot code: 9FF80000 -> 9FFA6840  BSS: -> 9FFD944C
.
Relocating to 9ff96000, new gd at 9fe55ed0, sp at 9fe55eb0
------

On a side note, how involved would it be to convert to 2015.01? I've already
ported 3 boards for 2014.07. Will everything I've done work perfectly fine
with 2015.01?







--
View this message in context: http://u-boot.10912.n7.nabble.com/U-Boot-stuck-after-relocation-attempt-on-MX51-board-tp206738p206924.html
Sent from the U-Boot mailing list archive at Nabble.com.

[U-Boot] U-Boot stuck after relocation attempt on MX51 board

[Benoît Thébaudeau]

.Hi Fabio,

On Wed, Feb 25, 2015 at 11:05 PM, Fabio Estevam <festevam@gmail.com> wrote:
> I have just tested top of tree U-boot and my mx53loco board boots fine.

That's because CONFIG_HAS_VBAR is set for ARMv7. There may be an
issue, though: according to Freescale, the TrustZone security
extensions are present on i.MX514/515/516/53x, but not on i.MX512/513.
According to ARM, the security extensions seem to always be
implemented on Cortex-A8, so it's not clear what Freescale means for
i.MX512/513, and if the non-secure VBAR is still available on these.
If not, 0x00000000 is the boot ROM, and 0xFFFF0000 is reserved, just
like on i.MX25/27/31/35, so disabling CONFIG_HAS_VBAR for i.MX512/513
would not help, and your vector relocation patch would be required
here too. It would be nice if someone could test the latest U-Boot on
i.MX512/513.

Best regards,
Beno?t

[U-Boot] U-Boot stuck after relocation attempt on MX51 board

[Benoît Thébaudeau]

Hi Albert,

On Thu, Feb 26, 2015 at 11:38 AM, Albert ARIBAUD
<albert.u.boot@aribaud.net> wrote:
> Hello Beno?t,
>
> On Thu, 26 Feb 2015 00:56:00 +0100, Beno?t Th?baudeau
> <benoit.thebaudeau.dev@gmail.com> wrote:
>> Dear Dave Kucharczyk,
>>
>> On Wed, Feb 25, 2015 at 11:08 PM, DaveKucharczyk
>> <david.kucharczyk@gmail.com> wrote:
>> > Fabio Estevam-2 wrote
>> >> Also, you said that your 512MB board version works fine, but the 256MB
>> >> fails.
>> >>
>> >> I suppose you are using two different binaries for each board, right?
>> >> You can't have a single binary for the two boards, unless you use the
>> >> SPL approach.
>> >
>> > Fabio, we use one binary. It has runtime memory discovery via gpio's
>> > (resistor reads). DRAM size is reported correctly from both boards. It just
>> > hangs on the 256MB board.
>> >
>> > We do not have SPL setup.
>>
>> You should try with 2015.01 as Fabio suggested.
>>
>> Also, check the CONFIG_SYS_TEXT_BASE of your board. From your log, I'm
>> wondering if it's not set too high, resulting in an overlap of the
>> pre- and post-relocation addresses occupied by your binary in the
>> 256-MiB case.
>
> /me wonders whether we should not add a test for this situation, with
> a conspicuous error message on the console stating that relocation will
> probably fail due to overlap.

Yes, that would be very helpful in such a case, which must occur very
often for new boards being ported to U-Boot. Besides that, it would be
great if CONFIG_SYS_TEXT_BASE could be automatically set to a sensible
value for most boards, from the configured internal/external RAM base
addresses.

Best regards,
Beno?t

[U-Boot] U-Boot stuck after relocation attempt on MX51 board

[Benoît Thébaudeau]

Hi Dave,

On Thu, Feb 26, 2015 at 3:19 PM, DaveKucharczyk
<david.kucharczyk@gmail.com> wrote:
> Beno?t Th?baudeau-2 wrote
>> Also, check the CONFIG_SYS_TEXT_BASE of your board. From your log, I'm
>> wondering if it's not set too high, resulting in an overlap of the
>> pre- and post-relocation addresses occupied by your binary in the
>> 256-MiB case.
>
> BINGO!!! Good catch Beno?t, thank you. I changed it from 9FF80000 to
> 9F000000 and now it boots.
>
> Looking at the original log...it relocated 90KB above text base. Not quite
> enough room...
> --------
> U-Boot code: 9FF80000 -> 9FFA6840  BSS: -> 9FFD944C
> .
> Relocating to 9ff96000, new gd at 9fe55ed0, sp at 9fe55eb0
> ------

You're welcome.

> On a side note, how involved would it be to convert to 2015.01? I've already
> ported 3 boards for 2014.07. Will everything I've done work perfectly fine
> with 2015.01?

You will probably have to make a few adjustments, but that should not
be too heavy. There have been many changes in the infrastructure of
U-Boot lately, mainly revolving around the integration of Kconfig,
Kbuild and the driver model. At worst, you should have to upgrade your
config / make / maintainers files, and maybe adjust your code for a
few changes in the driver APIs. To have an idea:
http://git.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=history;f=board/freescale/mx51evk;hpb=refs/tags/v2014.07;hb=refs/tags/v2015.01

Best regards,
Beno?t

[U-Boot] U-Boot stuck after relocation attempt on MX51 board

[Fabio Estevam]

Hi Beno?t,

On Thu, Feb 26, 2015 at 6:10 PM, Beno?t Th?baudeau
<benoit.thebaudeau.dev@gmail.com> wrote:

> That's because CONFIG_HAS_VBAR is set for ARMv7. There may be an
> issue, though: according to Freescale, the TrustZone security
> extensions are present on i.MX514/515/516/53x, but not on i.MX512/513.
> According to ARM, the security extensions seem to always be
> implemented on Cortex-A8, so it's not clear what Freescale means for
> i.MX512/513, and if the non-secure VBAR is still available on these.
> If not, 0x00000000 is the boot ROM, and 0xFFFF0000 is reserved, just
> like on i.MX25/27/31/35, so disabling CONFIG_HAS_VBAR for i.MX512/513
> would not help, and your vector relocation patch would be required
> here too. It would be nice if someone could test the latest U-Boot on
> i.MX512/513.

That's a good point. I don't have access to the mx512/mx513 variants though.

Regards,

Fabio Estevam

[U-Boot] U-Boot stuck after relocation attempt on MX51 board

[Fabio Estevam]

Hi Dave,

On Thu, Feb 26, 2015 at 7:01 PM, Beno?t Th?baudeau
<benoit.thebaudeau.dev@gmail.com> wrote:

> You will probably have to make a few adjustments, but that should not
> be too heavy. There have been many changes in the infrastructure of
> U-Boot lately, mainly revolving around the integration of Kconfig,
> Kbuild and the driver model. At worst, you should have to upgrade your
> config / make / maintainers files, and maybe adjust your code for a
> few changes in the driver APIs. To have an idea:
> http://git.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=history;f=board/freescale/mx51evk;hpb=refs/tags/v2014.07;hb=refs/tags/v2015.01

In addition to what Beno?t said, you could consider upstreaming your
board support, so that you don't have to worry about upgrading U-boot
in the future.
As I understand you have started with 2009.08, then moved to 2014.07
and plan to move to 2015.01. Also please keep in mind that we are in
the process of moving to 2015.04 :-)

[U-Boot] U-Boot stuck after relocation attempt on MX51 board

[Albert ARIBAUD]

Hello Fabio,

On Sat, 28 Feb 2015 12:56:25 -0300, Fabio Estevam <festevam@gmail.com>
wrote:
> Hi Beno?t,
> 
> On Thu, Feb 26, 2015 at 6:10 PM, Beno?t Th?baudeau
> <benoit.thebaudeau.dev@gmail.com> wrote:
> 
> > That's because CONFIG_HAS_VBAR is set for ARMv7. There may be an
> > issue, though: according to Freescale, the TrustZone security
> > extensions are present on i.MX514/515/516/53x, but not on i.MX512/513.
> > According to ARM, the security extensions seem to always be
> > implemented on Cortex-A8, so it's not clear what Freescale means for
> > i.MX512/513, and if the non-secure VBAR is still available on these.
> > If not, 0x00000000 is the boot ROM, and 0xFFFF0000 is reserved, just
> > like on i.MX25/27/31/35, so disabling CONFIG_HAS_VBAR for i.MX512/513
> > would not help, and your vector relocation patch would be required
> > here too. It would be nice if someone could test the latest U-Boot on
> > i.MX512/513.
> 
> That's a good point. I don't have access to the mx512/mx513 variants though.

Another point is that just skipping vectors relocation is akin to
papering over the issue. If there is any change done in U-Boot, I would
like it to actually ensure that exception handlers are actually called,
as I did with commit db544b96.

> Regards,
> 
> Fabio Estevam

Amicalement,
-- 
Albert.

[U-Boot] U-Boot stuck after relocation attempt on MX51 board

[Fabio Estevam]

Hi Albert,

On Sun, Mar 1, 2015 at 12:30 PM, Albert ARIBAUD
<albert.u.boot@aribaud.net> wrote:

> Another point is that just skipping vectors relocation is akin to
> papering over the issue. If there is any change done in U-Boot, I would
> like it to actually ensure that exception handlers are actually called,
> as I did with commit db544b96.

Sure, feel free to submit a patch then.

Thanks,

Fabio Estevam