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

Wed Nov 28 14:59:55 UTC 2018

On Wed, Nov 28, 2018 at 10:33:56AM +0100, Stefano Babic wrote:
> 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.

OK, so yes, we're both in the same ballpark wrt size constraints.

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

Right, and we'll need to take a look at what tricks we have available
and what we've already used.

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

Yeah, that's probably one of the things that'll need to be changed then
is moving from "look we can do anything" to more production "here's what
the design has for regular and recovery".  We had to do that for the
longest time, again on am33xx to put USB SPL stuff in its own build but
we're now finally looking at being able to perhaps pull that back in to
the kitchen-sink EVM builds.

And part of moving from "edit the config file" to "enable what you want
via Kconfig" makes me feel less bad / worried about not showcasing every
possible feature of a SoC in all builds since it becomes easier to
document and less potentially error-prone to change what's configured.

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

Fully agree.

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

OK, so lets not worry too much about that part then until it's something
we can see is a real concern.

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

I suppose part of the problem is that we had "SPL" for dealing with NAND
booting, where we couldn't do what we used to do, and then we had "SPL"
for "lets allow ourselves to do a bunch of neat things".  Moving forward
it's more "TPL" is "we need one-off (or near enough) code to get
ourselves started" and "SPL" for "We need to handle a bunch of neat
things very early".

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

So yes, TPL is where we're going to have to, and will live with one-off
SoC-centric and lack of framework drivers to Just Work.

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

Please, yes.

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

So, I think we're largely in agreement here.  What I'd really like to
see happen next is get enough of what's remaining and not DM'ified on
the full U-Boot side of things (where the why is because that's what
drivers look like now) so that we can enable them for SPL too and see
where we really do hit a problem.  I'm sure we will, and the situations
like at91 where we have single-digit kilobytes to work with are going to
be hard.  But for i.MX, we're in the same ballpark as other platforms
that have been converted.

-- 
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/20181128/87c75971/attachment.sig>