From mboxrd@z Thu Jan 1 00:00:00 1970 From: Albert ARIBAUD Date: Sun, 1 Mar 2015 16:30:37 +0100 Subject: [U-Boot] U-Boot stuck after relocation attempt on MX51 board In-Reply-To: References: <1424830787325-206738.post@n7.nabble.com> <1424899387250-206846.post@n7.nabble.com> Message-ID: <20150301163037.395731a6@lilith> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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 > > 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, -- Albert.