[U-Boot] U-Boot stuck after relocation attempt on MX51 board
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-M... Sent from the U-Boot mailing list archive at Nabble.com.
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-M... Sent from the U-Boot mailing list archive at Nabble.com.
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
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-M... Sent from the U-Boot mailing list archive at Nabble.com.
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
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-M... Sent from the U-Boot mailing list archive at Nabble.com.
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
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,
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
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-M... Sent from the U-Boot mailing list archive at Nabble.com.
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/freesca...
Best regards, Benoît
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/freesca...
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 :-)
.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
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
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,
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
participants (4)
-
Albert ARIBAUD -
Benoît Thébaudeau -
DaveKucharczyk -
Fabio Estevam