[PATCH 1/2] DM_USB: allow building without OF_CONTROL

[Simon Glass]

Hi Pali,

On Fri, 25 Jun 2021 at 07:07, Pali Rohár <pali at kernel.org> wrote:
>
> On Friday 25 June 2021 08:38:47 Tom Rini wrote:
> > On Sun, Jun 20, 2021 at 09:43:43PM +0200, Marek Vasut wrote:
> > > On 6/20/21 5:54 PM, Tom Rini wrote:
> > >
> > > [...]
> > >
> > > > > As far as I understand, the RX51 has gigabytes of eMMC storage, so it can
> > > > > use SPL just like any other OMAP3 board.
> > > >
> > > > U-Boot is being called by the old vendor X-Loader fork and needs to take
> > > > up the existing flash spot.
> > >
> > > So, why not place SPL in those 256 kiB and load U-Boot proper from the eMMC
> > > ?
> > >
> > > > > > So we need to make
> > > > > > changes in subsystems they use so that they can continue to work.
> > > > > >
> > > > > > So, are the changes being proposed to the generic USB code, such that
> > > > > > DM_USB can be enabled, and when DM_USB_GADGET gets a deadline (Note,
> > > > > > that's not set yet, but that's not to say never, it's just not been set,
> > > > > > so getting ahead of problems here would be appreciated) that can also be
> > > > > > enabled, OK?
> > > > >
> > > > > I am confused by this reply. I noticed a lot of boards were removed over
> > > > > time because they were not converted to DM/DT, and to get rid of all the
> > > > > ifdefs, but now it seems the direction has been completely reversed and we
> > > > > should start adding back all the ifdefs to cater for boards which are not
> > > > > converted instead of fixing the boards ?
> > > >
> > > > A lot of boards are being removed because no one wants to update and
> > > > maintain them and they have likely not been run-time tested in years.
> > > > Trying to clean up the code in those cases is best done by removing the
> > > > platform, as no one using it.   That is not the case here.
> > >
> > > Note that there have been boards which had to be switched to SPL to even
> > > permit converting them to DM/DT, and thus prevent removal.
> > >
> > > > If your only
> > > > concern about the approach taken is some #ifdef's in the code, do you
> > > > want to see them converted to use some wrapper macro like we do in a few
> > > > other cases and __maybe_unused some functions as needed?
> > >
> > > I think there is a better option which does not add any ifdefs at all _and_
> > > is future-proof -- place SPL in those 256 kiB, load U-Boot from eMMC and
> > > then enable all the functionality you might need in U-Boot. That would free
> > > you from dealing with the size limitations basically indefinitely.
> >
> > So, at this point I'm waiting for either of:
> > - A response to Marek's questions about using SPL, from the Nokia NX51
> >   folks.
>
> Hello Tom! Here is my answer:
>
> > So, why not place SPL in those 256 kiB and load U-Boot proper from the eMMC ?
>
> U-Boot for N900 does not use SPL. There is no SPL code implemented.
> Nobody ever tried to implement it and neither tested. As you have
> correctly pointed instead of SPL is used vendor X-Loader binary, which
> is signed by RSA key.
>
> Add eMMC: On eMMC is stored existing operating system, which somehow
> also interacts with vendor X-Loader. There was no big investigation on
> this topic. Also direct booting from eMMC is not supported (unless you
> crack RSA, figure out how secure things work and generate compatible
> image) and neither from existing X-Loader (because vendor did not
> enabled it). There is no easy access to eMMC until you start full
> U-Boot. So even if all these problems are solved then "bootstrapping" or
> flashing U-Boot into such location is not possible, plus there is no
> recovery. Plus this loose existing and working operating system, which
> is no-go. So this way is basically undebugable and therefore perfectly
> hard to develop.

I don't want to inject myself in this discussion, although it does
sound like this platform should use SPL. But I do wonder about the
100KB growth you saw with DT/DM. That seems absolutely enormous to me!
Can you please point me to the git tree for this? I'd like to
investigate.

- Simon

>
> Not mentioning that implementing this means to implement all N900 code
> in U-Boot from scratch. And the last thing is testing...
>
> For me this idea looks like total perfectionism in corporate world when
> some software architect invent a new super-duper-über solution for
> everything which in reality is not possible to implement.
>
> PS: In past few people investigated topic on cracking RSA signature on
> Omap3 and nobody was able to find any "security issue" in it...
>
> > - A patch to rework things so that USB gadget support more cleanly
> >   removes from the code paths non-gadget code, so there's no #if's being
> >   added here.  Or some similar clean-up.
> >
> > --
> > Tom
>
>