[U-Boot] [PATCH] arm: Tegra: fix undefined instruction hang immediately after reset

Tom Warren twarren.nvidia at gmail.com
Wed Dec 21 00:27:06 CET 2011


This is needed for v2011.12-rc2. I'm using my Google email because I
seem to be getting blocked by base64 MIME crap w/Outlook.

Tom

On Wed, Dec 14, 2011 at 1:40 PM, Tom Warren <TWarren at nvidia.com> wrote:
> [Resending due to Outlook Base64 MIME issues. Sorry if you get spammed w/multiple copies]
>
> Wolfgang/Albert,
>
> This needs to be added to v2011.12-rc1 or Tegra2 builds/boards will be DOA.
>
> Thanks,
>
> Tom
>
>> -----Original Message-----
>> From: Aneesh V [mailto:aneesh at ti.com]
>> Sent: Thursday, December 08, 2011 11:18 PM
>> To: Tom Warren
>> Cc: Mike Frysinger; u-boot at lists.denx.de; trini at ti.com; Tom Warren; Albert
>> Aribaud
>> Subject: Re: [U-Boot] [PATCH] arm: Tegra: fix undefined instruction hang
>> immediately after reset
>>
>> Tom,
>>
>> On Thursday 08 December 2011 09:07 PM, Tom Warren wrote:
>> > Aneesh&  Mike,
>> >
>> >> -----Original Message-----
>> >> From: Aneesh V [mailto:aneesh at ti.com]
>> >> Sent: Wednesday, December 07, 2011 10:51 PM
>> >> To: Mike Frysinger
>> >> Cc: u-boot at lists.denx.de; trini at ti.com; Tom Warren; Tom Warren
>> >> Subject: Re: [U-Boot] [PATCH] arm: Tegra: fix undefined instruction
>> >> hang immediately after reset
>> >>
>> >> Mike,
>> >>
>> >> On Thursday 08 December 2011 05:44 AM, Mike Frysinger wrote:
>> >>> On Tuesday 06 December 2011 18:00:19 Tom Warren wrote:
>> >>>> commit 0d479b53 (Aneesh V) added code for OMAP4 that doesn't
>> >>>> execute on Tegra, due to the AVP (ARM7TDI) not having a CP15.
>> >>>> Result was an undefined instruction hang just after reset.
>> >>>>
>> >>>> --- a/arch/arm/cpu/armv7/start.S
>> >>>> +++ b/arch/arm/cpu/armv7/start.S
>> >>>>
>> >>>> +#if !defined(CONFIG_TEGRA2)
>> >>>>    /*
>> >>>>     * Setup vector:
>> >>>>     * (OMAP4 spl TEXT_BASE is not 32 byte aligned.
>> >>>> @@ -159,6 +160,7 @@ reset:
>> >>>>          ldr     r0, =_start
>> >>>>          mcr     p15, 0, r0, c12, c0, 0  @Set VBAR
>> >>>>    #endif
>> >>>> +#endif  /* !Tegra2 */
>> >>>
>> >>> forgive my ignorance, but would it be better to invert the logic ?
>> >>> have ARM cores that do have a CP15 define CONFIG_ARM_CP15 (or
>> >>> whatever) and then put all this logic behind that rather than grow a
>> >>> list
>> >> of SoC's that lack it ?
>> >>> -mike
>> >>
>> >> As far as I understand CP15 is typically available(if not mandatory)
>> >> on all
>> >> armv7 processors. Here, IIUC, NVidia has a peculiar architecture that
>> >> necessitates an armv4 processor supported by armv7 code. IMHO, this
>> >> is the exceptional case.
>> >
>> > Tegra has (at least) 2 ARM processors - the AVP, which is ARM7TDMI-based
>> and hence has no CP15, and the CPU complex, which as 2 or more A9 CPUs.
>> Since the AVP is the boot processor, it runs the initial U-Boot code
>> (start.S) and will eventually setup and kick off the CPU(s) to run the bulk
>> of U-Boot.
>> >
>> > Perhaps we should be in our own arch/arm/cpu/arm7tdmi subdir, but that's a
>> major change from the current structure. Is it possible for this code
>> ("Setup vector") to only be defined for OMAP processor builds? The code it
>> replaces was ifdef'd for OMAP3, and had no affect on Tegra builds.
>>
>> I think setting up vector is useful for all platforms and I think this is
>> the right place to do it. Just that we didn't have it till now ecept for
>> OMAP3 and OMAP3 was doing it in a round-about way.
>>
>> >
>> > Unless some other SoC decides to use an ARM7TDMI-S boot proc, though, the
>> CONFIG_TEGRA2 fencing should be the only one necessary.
>>
>> I agree. I don't think there will be many more exceptions like this. We can
>> live with that #ifdef. Not sure what Albert thinks though.
>>
>> >
>> > Tom
>> >>
>> >> br,
>> >> Aneesh
>> > ----------------------------------------------------------------------
>> > ------------- This email message is for the sole use of the intended
>> > recipient(s) and may contain confidential information.  Any
>> > unauthorized review, use, disclosure or distribution is prohibited.
>> > If you are not the intended recipient, please contact the sender by
>> > reply email and destroy all copies of the original message.
>> > ----------------------------------------------------------------------
>> > -------------
>


More information about the U-Boot mailing list