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

[Stefano Babic]

Hi Tom,

On 27/11/18 17:13, Tom Rini wrote:
> 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 at 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?

Solo has 68KB OCRAM available - if I remember well, letting some space
for early stack and some other thigs, there is still 49K available. This
was big enough when SPL was ported to MX, now we are approaching the limit.

This is worst when for some projects there is the need for some
customization, like additional code to get device data or calibration
for RAM. In some cases, it is becoming tricky.

Anyway, my concern is that the OCRAM is not so small, but nevertheless
we have now reached the point where the SPL has grown so much to take
all available size.

>  And what boot methods
> do we have to support there too?

I can imagine that at least booting from storages (NAND, SPI, SD) and
from SDP (usb gadget) should be supported in the same SPL. Maybe just a
couple of storages at the same time (main boot device and "backup" to
restore it).


>  The am335x with secure boot case is
> small, but might not be as small as you have to worry about here.

It looks to me that size is quite comparable to AM335x.

> 
>> - 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.

Fully agree.

>  But we can't use that as a reason to maintain wholly
> separate subsystems for some platforms either.

Right, but we have to find a solution.

> 
>> - 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.

I have no measures - this can be done after moving one of these i.MX6 to
a TPL based bootloader. I am just thinking about when we introduced SPL
some years ago. One goal was to have a "simpler" loader that provides
the first initialization (just RAM and console), letting u-boot to do
the rest. This sounds weird now - these are the requirement we ask for
TPL. So TPL looks to me an early SPL - can we just have a simpler SPL,
that just does the simple initialization ? TPL was initially thought for
SOCs having a very small RAM on board, and then they can boot from a
single storage only. This is also not the requirement for more complex
SOC, and even with TPL, a i.MX should boot from SPI, NAND / SD. And to
maintain the trust of chain, TPL should able to load just signed images,
too (it is another step and add complexity).

For aarch64, I agree with you and there is nothing we can do against it.
More layers were also introduced due to increased requirements for
security.On the other side, these SOCs could be faster during boot due
to better CPU.

What about the drivers we need in TPL ? They cannot be a DM driver, so
we still need some legacy drivers for storage. We should still have both
type of drivers (DM and not DM), and dropping current legacy drivers
from SPL does not help.

> 
>>> 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.

Fully agree.

> 
>>> 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".

I think I need some measure - if size remains small enough, it could be
a suitable way.

> 
>>> 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.

I agree - but let's me say that the advantages in that case were very
clear (no fixed RAM setup bound to the HW, run time detection, single
binary for multiple variants in case of i.MX6,..) and most important,
these advantages meant for manufacturers less costs. Less cost because
it is easier to relace a chip that reached EOL, or because they do not
have different part number for each bootloader (they have just one), or...

The same should happens now to convince again manufacturers and customers.

> 
> 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.

Nice to listen this - I was already scared from this thread and last
"CONFIG_BLK" :-)

> 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.
> 

Best regards,
Stefano

-- 
=====================================================================
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de
=====================================================================