Hi, On Tue, Dec 20, 2011 at 4:27 PM, Tom Warren <twarren.nvi...@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 <twar...@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:ane...@ti.com] >>> Sent: Thursday, December 08, 2011 11:18 PM >>> To: Tom Warren >>> Cc: Mike Frysinger; u-boot@lists.denx.de; tr...@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:ane...@ti.com] >>> >> Sent: Wednesday, December 07, 2011 10:51 PM >>> >> To: Mike Frysinger >>> >> Cc: u-boot@lists.denx.de; tr...@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@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot