[PATCH 0/9] Switch internal registers address to 0xF1 on Armada 370/XP

[gregory.clement@free-electrons.com (Gregory CLEMENT)]

On 05/22/2013 05:18 PM, Arnd Bergmann wrote:
> On Wednesday 22 May 2013, Gregory CLEMENT wrote:
>>>> Therefore, the last patch of this series adds some early code in the
>>>> kernel, at the ->map_io() stage, to switch the internal registers from
>>>> 0xD0000000 to 0xF1000000 if this has not been done already by the
>>>> bootloader. As it was explained above, we unfortunately can't read the
>>>> current base address of the internal register window, so we need a
>>>> different mechanism to know if the bootloader has done the remapping
>>>> at 0xF1000000 (new generation bootloader) or has left the internal
>>>> registers at 0xD0000000 (old generation bootloader). In order to
>>>> distinguish between those two cases, a CP15 bit is being used. Old
>>>> bootloaders do not touch this CP15, so it is set to 0. New bootloaders
>>>> set this CP15 bit to 1, so that the kernel knows that the remapping
>>>> has already been done. The ->map_io() code looks at this bit to know
>>>> if the remapping should be done or not.
>>>
>>> As you already admit, using the CP15 register is a hack. It sounds
>>> to me that a cleaner approach would be to put the correct address
>>> into the device tree and use that value everywhere, rather than
>>> hardcoding one or more addresses.
>>
>> That means reading and decoding the device tree very early in the
>> auto-uncompress part of the kernel.
> 
> Why that? I was only implying that we would have no console output in
> the uncompressor, which is already the case on multiplatform these
> days when DEBUG_LL is disabled.

Loosing the earlyprintk would be a big regression. Having DEBUG_LL disabled
in multiplatform case is fine. If the kernel seems to not run at all we
can still build a kernel for only for mvebu, activate earlyprintk and see
what happened. With your proposal we won't have any more this feature, and
it will make the debug or the bug report for the user much harder. As we still
in active development I really want to avoid it.

> 
> 	Arnd
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 


-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com