[PATCH 02/14] omap: Make uncompress code and DEBUG_LL code generic

Kevin Hilman khilman at deeprootsystems.com
Fri Apr 30 11:07:02 EDT 2010


[resend to include RMK]

On Tue, 2010-01-26 at 12:12 -0800, Tony Lindgren wrote:
> Define arch_decomp_setup() the same way as some other
> architectures do. Use arch_id to configure the debug uart
> based on the machine_is by storing it into the uart
> scratchpad register for DEBUG_LL code to use.
> 
> Note that to avoid merge conflicts, this patch is using
> hardcoded register r1 until tmp register is being passed
> for all addruart macros.

This patch (now in mainline[1]) has been working well, but has a couple
serious limitations:

1. assumes bootloader has enabled UART1 clocks
2. assumes all OMAPs supported have the same UART1 base

With more platforms using USB-based UARTs, assumption (1) may not be
safe for very long, as bootloaders for these platforms don't really
*need* to enable UART1.  Currently, they happen to mainly because of
copied init code from other platforms. 

But more importantly, there are more OMAP derivative parts coming soon,
and one in particular coming soon[2] breaks assumption 2 by having a
different UART1 base (yes, it's branded as a DaVinci, but it's an OMAP
core as far as linux is concerned.  Don't get me started on TI
branding.)

To fix both problems, maybe we should just use a fixed memory location
to pass this temporary data from uncompress to the kernel.  We've had a
similar problem on DaVinci recently and a proposal has been made (and
tested) to use memory just below the page tables[3].)

Any comments on this proposal?  or alternative suggestions?

Kevin

[1] commit 0c8219f0302d0d27fda52c790d38406801e547ec
[1] http://www.ti.com/ww/en/dsp/davinci-netra/index.shtml
[2] https://patchwork.kernel.org/patch/94724/






More information about the linux-arm-kernel mailing list