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

[Albert ARIBAUD <albert.u.boot@aribaud.net>]

Hi Heiko,

On Wed, 31 Jul 2013 10:31:12 +0200, Heiko Schocher <hs@denx.de> wrote:

> Hello Albert,
> 
> Am 31.07.2013 10:16, schrieb Albert ARIBAUD:
> > Hi Heiko,
> >
> > On Wed, 31 Jul 2013 09:36:19 +0200, Heiko Schocher<hs@denx.de>  wrote:
> >
> >>> On the other hand, it may be hard to immediately know what functions
> >>> throughout U-boot are safe to call from within board_init_f(); maybe we
> >>> should start thinking about checking and marking these, the simplest
> >>> way being to suffix them with "_f" once we have made sure they are safe
> >>> to call from within board_init_f().
> >>
> >> Hmmm... Maybe instead we should think (also in thinking common bring
> >> up for all boards) about:
> >>
> >> getting rid of board_init_f in u-boot code, instead use for all
> >> boards spl code to init needed things and copy and relocate u-boot
> >> to ram in spl code ... so we have in u-boot no longer such
> >> restictions ... but thats just an idea which whirs in my head ...
> >> without thinking to deep in it.
> >>
> >> But this approach would have some advantages ...
> >
> > Well, the original SPL was basically board_init_f() plus some code to
> > copy U-Boot from wherever it was to DDR, so it was tightly linked to
> > board_init_f(). But... first, SPL has evolved into a "U-Boot lite"
> > where much can happen beyond board_init_f() -- think Falcon mode, for
> > instance -- and second, there are boards which do not have SPL at all,
> > and their board_init_f() can thus not be "moved to SPL".
> 
> Hmm... all boards use board_init_f ... and spl do pieces from board_init_f
> So why should it not be possible to do all init things in spl code?
> Code beyond board_init_f is optional ...

It is, in the original "SPL is just board_init_f plus some copying"
view. In the current "SPL is U-boot only not full-featured", it becomes
false.

> And yes, there are a lot of boards, which have no spl, but they
> can execute spl code (thinking of the lof of powerpc boards which
> booting from nor flash ... spl code can also run from nor ... and
> copy the u-boot piece of the image to ram, relocate it ...)
> 
> And yes, a side effect could be, that all boards can use Falcon boot mode.
> 
> ;-)
> 
> > So no, I don't think we can move U-Boot's design from "_f/_r" to
> > "SPL/U-Boot".
> 
> I am not sure ...

I see this approach of likening SPL to _f and U-boot to _r as forcing a
dual-binary model onto all boards whereas not all boards require it. I
prefer a model where _f can exist, _r can exist, and for each target,
the maintainer decides which binaries are built and for each one,
whether _f and/or _r is present and what _r does.

Amicalement,
-- 
Albert.