[U-Boot] [PATCH v2 00/32] spi: DM_SPI migration timeout, remainder(2)

[Tom Rini <trini@konsulko.com>]

On Tue, Nov 27, 2018 at 03:39:39PM +0100, Stefano Babic wrote:
> Hi Jagan,
> 
> (CCing the world looks to me quite a terror attack, nevertheless):
> 
> On 27/11/18 06:51, Jagan Teki wrote:
> > On Mon, Nov 26, 2018 at 12:48 PM Peng Fan <peng.fan@nxp.com> wrote:
> >>
> >> Hi Jagan,
> >>
> >> Just have a quick question here.
> >>
> >> After dropping non-DM code, for SPL use non-DM code should switch to SPL_DM and use SPL OF CONTROL?
> > 
> 
> I can understand the reasons to switch completely to DM code, but let's
> face some real facts:
> 
> - dropping legacy code requires to use SPL_OF_CONTROL into SPL, and yes,
> footprint steadily increases. We are getting rid of place for MX6 Solo,
> and this is not an ancient processor we can forget.
> Size of SRAM is not something we can discuss - it is. Other features
> (secure boot, etc.) were pushed to SPL, and these features were
> requested by real projects. We cannot get rid of these feature just to
> make place for DM.

Just what is the limit on MX6 Solo, worst case?  And what boot methods
do we have to support there too?  The am335x with secure boot case is
small, but might not be as small as you have to worry about here.

> - the benefits cannot be really understood by the manufacturers or
> owners of boards, because they can see a step in the past if they have
> to forget some features they are currently using.

Yes, we need to make sure that we don't just drop functionality for no
apparent reason.  But we can't use that as a reason to maintain wholly
separate subsystems for some platforms either.

> - TPL adds an additional step and this increases the boottime - another
> *real* and *important* feature for most projects.

I _really_ want to see this measured so we know what time is being added
so we can think about what to do about it, too.  Yes, adding a few
kilobytes is a few cycles, and a few is more than zero, and there are
use cases that have demands screaming for less cycles to be used, not
more (aside, when this is coupled with "But we're moving to aarch64" and
that requires more firmware layers makes me shake my head internally a
little).  But by that same token, part of the notion behind
TPL->SPL->U-Boot or Linux is that some functionality is moved from SPL
to TPL.

> > Here are the options, that we dealt based on the size constraints
> > 1) try to use DM_SPL with SPL OF_CONTROL
> 
> There is no enough place for most SOCs, even quite recent. This is not
> due just to the size of SRAM, but also by some restriction on the usage
> of the SRAM itself by the internal BootROM.

This is debatable, frankly.  But yes, we do have modern platforms with a
still small usable by first non-ROM-application amount of memory.  So we
must have a solution.

> > 2) try PLATDATA
> 
> This is even not footprint friendly.

Why?  This is in fact our current method for "we need something more
footprint friendly to feed enough info in to get to the next
application".

> > 3) try TPL for truly small size
> 
> See above. There is an additional layer without evident advantages for
> manufacturers and / or customers.

"You need this in order to boot now".  Just like moving from say DCD
files to SPL required convincing manufacturers and customers that it was
a win even if you could do everything with DCD scripts and plugins, this
too requires explanation.

But also, I keep saying, and it feels like I keep not being heard, we
aren't declaring the death of non-DM for SPL for all platforms just yet.
There's likely a few more technical challenges to sort out, and some
explanation of why the world isn't static required before we can do
that.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20181127/5c3c9482/attachment.sig>