From mboxrd@z Thu Jan 1 00:00:00 1970 From: Albert ARIBAUD Date: Fri, 28 Oct 2011 07:07:37 +0200 Subject: [U-Boot] [PATCH 3/9] arm: Move CP15 init out of cpu_init_crit() In-Reply-To: References: <1318539963-3329-1-git-send-email-sjg@chromium.org> <4EA1E797.1070600@aribaud.net> <4EA1F12A.5090108@aribaud.net> <4EA27738.4060102@aribaud.net> <4EA5C4C7.9060106@aribaud.net> <4EA5D6BE.8060206@aribaud.net> <4EA65A17.3000609@aribaud.net> <4EA9B992.909@aribaud.net> <4EA9DD91.5000806@aribaud.net> Message-ID: <4EAA3899.2090408@aribaud.net> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Simon, Le 28/10/2011 00:46, Simon Glass a ?crit : > Hi Albert, >>>>>> Yes I'm tempted to go with this even if the ARM ARM is silent on the >>>>>> matter. I will try it out today. >>>>> >>>>> Silly me of course it doesn't work - since if the CP15 doesn't have >>>>> those features then you get undef instruction exception. Please see >>>>> ^^^ above! >>>> >>>> Are you stating a reasoning here or the results of an actual test? What >>>> causes an undefined instruction exception is the absence of a coprocessor >>>> to >>>> handle the instruction, not the presence of a coprocessor which >>>> incidentally >>>> cannot perform all of what"s being asked. >>> >>> Yes I did test it - it hangs. Would you like me to spend some time to >>> debug exactly why? I suspect it is an undef instruction, since >>> executing cache instructions on an ARM7TDMI is dodgy, but I could >>> check if it would help. But let's assume for now we can't do that! >> >> What was the test exactly? Depending on which register of CP15 you try to >> access, things could be different. Can you test MRC p15,0,,c0,c0,0 ? >> That's the MIDR and it should be always accessible, plus it should have a >> unique value for each type of core, so it could be used to not write cp15 >> for caches etc from the AVP. > > I'm sure that is fine. So do you want me to add a check that the ID > shows architecture ARMv7, and then skip the cache code if not? > It should be safe enough since it is a clear signal that something is not > right. It would also handle the case where an Cortex-A7 (with a cache) > is attached. That's the general idea of what I am asking for: test for actual conditions when needed rather than assume conditions at build time. However I don't want to test for ARMv7 architecture, because there is no reason for *all* ARMv7 cores to fail handling current cp15 init. What I want here is to test for NVidia Tegra2 AVP (using the Implementer, Variant, Primary part number and possibly even Revision fields of MIDR), since you have demonstrated it to not handle the current cp15 init. Plus, run-time testing on MIDR could later on allow us to reduce ARM init code path to a single, common start.S for generic/common ARM init code, and specific code would be 'switched' into, based on MIDR -- that could allow for multiple board support in a single binary. > Regards, > Simon Amicalement, -- Albert.