From mboxrd@z Thu Jan  1 00:00:00 1970
From: Albert ARIBAUD <albert.u.boot@aribaud.net>
Date: Sat, 05 Nov 2011 09:09:45 +0100
Subject: [U-Boot] [PATCH 3/9] arm: Move CP15 init out of cpu_init_crit()
In-Reply-To: <CAPnjgZ0x5D3SNx-veiBVTBQ-MM8r-yPd5CzizVFZ-CqxH-ohjQ@mail.gmail.com>
References: <1318539963-3329-1-git-send-email-sjg@chromium.org>
	<4EA5D6BE.8060206@aribaud.net>
	<CAPnjgZ371QhtMCGkGUVy5xZ_bkito1-pigr8jmzaUkHGXb07iQ@mail.gmail.com>
	<4EA65A17.3000609@aribaud.net>
	<CAPnjgZ1n0m1nm+EGAOJ-8pq7kkJ-9_FO3bHAqF-B0phj=hwZ1g@mail.gmail.com>
	<CAPnjgZ06BVaDDvaMiuaa59hTBL=d-ido1aBH7v=q7XMakcEfcg@mail.gmail.com>
	<4EA9B992.909@aribaud.net>
	<CAPnjgZ15aGEMdugcpYuBJ4Onmp-LdFHtEugkEwi7RDFPrNwH1A@mail.gmail.com>
	<4EA9DD91.5000806@aribaud.net>
	<CAPnjgZ160Unujwwaj0XdyZ0GBHd4JxdSS5NH4tWkayUzfPUiGw@mail.gmail.com>
	<CAPnjgZ1PExaBHp96pwfKXLjtJzfdYvJjT_NdMApQZQ=4-5XYAg@mail.gmail.com>
	<4EAA391A.6000309@aribaud.net>
	<CAPnjgZ2p-TKtXC9PGHZAQwHTTUMfsZpq3kcsvxXPhJFHV+_J3Q@mail.gmail.com>
	<4EAD23E9.3090605@aribaud.net>
	<CAPnjgZ1JVw=wMUoFc9Hyf_Q4cUJd5QXUwXtzshhW3QPq7uOGBA@mail.gmail.com>
	<7E91C59574E9954FA075F8D8CCDF78DB38FDD3E963@HQMAIL04.nvidia.com>
	<CAPnjgZ0x5D3SNx-veiBVTBQ-MM8r-yPd5CzizVFZ-CqxH-ohjQ@mail.gmail.com>
Message-ID: <4EB4EF49.2050402@aribaud.net>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

Hi Simon et al.,

Thanks to you and others for their patience. Let me summarize the thread:

- ARM7TDMI definitely lacks a cp15, as AN99 explicitely states;

- ARM provides no other, reliable, way to identify an ARM7TDMI reliably;

- Identification through a manufacturer-specific method just defeats the 
goal.

This makes it impossible to support ARM7TDMI (as well as others listed 
in AM99)  with a start.S code that contains cp15 instructions.

OTOH, I've gone through a number of ARM TRMs for cores that have 
caches/MMU and they all state that these are disabled on reset. I will 
also assume that when U-Boot starts indirectly through SPL or any other 
mechanism, and if this mechanism uses caches/MMU, then it will disable 
them properly before passing control to U-Boot, just like U-Boot 
disables caches etc before passing control to e.g. Linux.

I understand that this initialization is done so that the the cache/MMU 
is in a correct state, and this must still be ensured, but I now think 
that ensuring this is the burden of whatever passed control to the start 
label (this includes true resets, branching from SPL or any other IPL, 
and --ugh-- branching to start from inside U-Boot).

Based on this, I revise my opinion that the caches and MMU cleaning code 
in start.S should be kept there, and actually I now consider that they 
should be removed entirely.

However, removing cp15 inits would mean a *third* revision of your 
patchset, plus it could cause unexpected issues which I don't want to 
happen at this point of the release cycle.

Therefore, I'll go back to your patch as posted on oct 13th.

Apologies for the long discussion.

Amicalement,
-- 
Albert.