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. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
