Hi Albert,
On Sun, Mar 1, 2015 at 12:30 PM, Albert ARIBAUD
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 wit
Hello Fabio,
On Sat, 28 Feb 2015 12:56:25 -0300, Fabio Estevam
wrote:
> Hi Benoît,
>
> On Thu, Feb 26, 2015 at 6:10 PM, Benoît Thébaudeau
> wrote:
>
> > That's because CONFIG_HAS_VBAR is set for ARMv7. There may be an
> > issue, though: according to Freescale, the TrustZone security
> > extens
Hi Dave,
On Thu, Feb 26, 2015 at 7:01 PM, Benoît Thébaudeau
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 d
Hi Benoît,
On Thu, Feb 26, 2015 at 6:10 PM, Benoît Thébaudeau
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
Hi Dave,
On Thu, Feb 26, 2015 at 3:19 PM, DaveKucharczyk
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
Hi Albert,
On Thu, Feb 26, 2015 at 11:38 AM, Albert ARIBAUD
wrote:
> Hello Benoît,
>
> On Thu, 26 Feb 2015 00:56:00 +0100, Benoît Thébaudeau
> wrote:
>> Dear Dave Kucharczyk,
>>
>> On Wed, Feb 25, 2015 at 11:08 PM, DaveKucharczyk
>> wrote:
>> > Fabio Estevam-2 wrote
>> >> Also, you said that yo
.Hi Fabio,
On Wed, Feb 25, 2015 at 11:05 PM, Fabio Estevam 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.M
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 chang
Hello Benoît,
On Thu, 26 Feb 2015 00:56:00 +0100, Benoît Thébaudeau
wrote:
> Dear Dave Kucharczyk,
>
> On Wed, Feb 25, 2015 at 11:08 PM, DaveKucharczyk
> wrote:
> > Fabio Estevam-2 wrote
> >> Also, you said that your 512MB board version works fine, but the 256MB
> >> fails.
> >>
> >> I suppose
Dear Dave Kucharczyk,
On Wed, Feb 25, 2015 at 11:08 PM, DaveKucharczyk
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 f
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 ha
Hi Dave,
On Wed, Feb 25, 2015 at 6:23 PM, DaveKucharczyk
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
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.nab
Dear Dave Kucharczyk,
On Wed, Feb 25, 2015 at 3:19 AM, DaveKucharczyk
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: 9FF8 -> 9FFA6824 BSS: -> 9FFD944C
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 0x0001 => 0x0004
- TARGET: JTAG exists check
15 matches
Mail list logo
