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

[Simon Glass]

Hi,

On Tue, Dec 20, 2011 at 4:27 PM, Tom Warren <twarren.nvidia at gmail.com> wrote:
> 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

Yes please! Tegra is broken in mainline without this patch.

Regards,
Simon

>
> 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.
>>> > ----------------------------------------------------------------------
>>> > -------------
>>
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot