[U-Boot] [PATCH v3 8/9] tegra: i2c: Enable new CONFIG_SYS_I2C framework

[Stephen Warren <swarren@wwwdotorg.org>]

On 07/30/2013 03:21 PM, Simon Glass wrote:
> On Tue, Jul 30, 2013 at 2:00 PM, Stephen Warren <swarren@wwwdotorg.org
> <mailto:swarren@wwwdotorg.org>> wrote:
...
>     Oh, with the options Tegra has enabled, perhaps the call sequence is:
> 
>     board_init_f() (which uses init_sequence_f[]) -> init_func_i2c() ->
>     i2c_init_all(), which then calls:
> 
>     * i2c_init_board(), which is supposed to parse DT
>     * i2c_set_bus_num(), which will call I2C_ADAP->init
> 
>     However, according to the comments near the top of arch/arm/lib/crt0.S,
>     board_init_f() is called in an environment where variable data (.data,
>     .bss) is not available, hence i2c_init_board() cannot possibly operate
>     correctly since its whole purpose is to fill in variable data structures
>     from DT.
> 
> 
> I suppose you could mark i2c_controllers so that it is in the data
> section with __attribute__((section(".data"))). That's what eynos does,
> for example. It is valid since SPL or BCT has set up the SDRAM.

Neither .data nor .bss is available. Only .rodata and .text are.

In practice, perhaps we can assume that it will work on Tegra because we
know the DRAM is already set up, but then that makes Tegra work in some
strange special-case way, and completely violates the constraints
described in crt0.S. We should be striving to unify how all the
different chips work, rather than adding yet more strange special-cases
to the initialization sequence to hack around systemic problems.