From mboxrd@z Thu Jan 1 00:00:00 1970 From: Albert ARIBAUD Date: Mon, 24 Oct 2011 23:21:02 +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> <1318539963-3329-4-git-send-email-sjg@chromium.org> <4EA1DD04.3010808@aribaud.net> <4EA1E797.1070600@aribaud.net> <4EA1F12A.5090108@aribaud.net> <4EA27738.4060102@aribaud.net> <4EA5C4C7.9060106@aribaud.net> Message-ID: <4EA5D6BE.8060206@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 Le 24/10/2011 22:14, Simon Glass a ?crit : >>> So how about I create a patch to move the cp15_init() code into >>> arch/arm/cpu/armv7/lib/lowlevel.S or similar so I can call it later? >> >> I don't mind moving it to armv7/lib. I do mind the "later". > > OK, but the AVP cannot execute this code, whereas the A9 needs to > execute it on start-up. Yes, and that's the real problem: if you did not have that AVP running the same code path as the A9, you wouldn't even have though of moving cp15 init elsewhere. > We define CONFIG_SKIP_LOWLEVEL_INIT on Tegra, and the mere fact that > this option exists suggests that platforms are permitted to do it. We > don't need to do any memory init, and the CP15 init can be called in > arch_cpu_init() once we establish that we are an A9 and not an AVP. > Does that sound ok? Yes, CONFIG_SKIP_LOWLEVEL_INIT exists for a reason, but that reason is not "I'm running this code on two CPUs", it is "those inits have already been done". CONFIG_SKIP_LOWLEVEL_INITS is meant for U-Boot being loaded by SPL, so SPL has done the inits already. And I also agree that we should do the cp15 init as soon as we have checked that we're the A9, not the AVP. But this check has to be done during low level init, based on some immediate identification, not based on where in the code we are. > The only problem I can see with this is if the data cache is on. This > could happen if you load U-Boot with (say) tftp and jump to it. Well > 'don't do that!'. We also hope that the D-cache has at least been > flushed or there is nothing we can do. One fix for this (prior to the > refactor you are planning and mentioned in your earlier email) is > perhaps to implement a run-time check for the existence of CP15. Is > that better or worse? According to ARM, coprocessors 14 and 15 should always be supported from ARMv6 up. Are you sure the AVP does not have it? If there is a Tegra specification available, I'd like to have a look at it. > Regards, > Simon Amicalement, -- Albert.