On 26.06.21 г. 17:58 ч., Tom Rini wrote:
On Sat, Jun 26, 2021 at 12:59:21PM +0200, Merlijn Wajer wrote:
Hi Tom, Marek,
On 25/06/2021 23:59, Tom Rini wrote:
On Fri, Jun 25, 2021 at 11:51:51PM +0200, Pali Rohár wrote:
On Friday 25 June 2021 17:37:44 Tom Rini wrote:
One thing I want to say here as I think it maybe wasn't clear in Marek's
suggestion. Why not have X-Loader boot SPL which loads U-Boot from extN
on the eMMC?
Hello Tom! I have already answered this in my previous email.
I just re-read things and I don't see it. But perhaps I'm not being
clear enough. Why can't you just have NOLO start SPL, not re-initialize
things (which is a really common case now thanks to aarch64) and just
use that to load full U-Boot from a not size restricted place?
I think there are a few problems.
1. One is a practical one, from Pali's email:
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.
Not being able to access the eMMC to write u-boot until u-boot is
started does sound like it would make things a bit more tricky.
I don't understand this. Either way it's drivers/mmc/omap_hsmmc.c.
2. According to Pali, adding SPL support would not be a trivial task,
and might end up with a lot more "#ifdef"s in SPL than the one in
Ivaylo's patch. As I understand it, this hypothetical SPL would mostly
not do any hardware initialisation on the N900, so that might be where
instead hacks would need to be added to SPL.
Pali also wrote:
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.
And when I asked him today:
12:11 < Pali> in past (10 years ago?) I was investigating the way how we can
boot u-boot and the only reasable way was the current one, directly load main u-boot
by x-loader/nolo
12:12 < Pali> I have already spend some time with spl on n900 and at that time
I have rejected this idea, because it did not work that
12:13 < Pali> spl is also doing hw initialization which cannot be called on
n900 as this code basically crash / freeze n900
So perhaps it would make sense to get more clarity on that, since that
seems to be where the argument gets stuck.
This also doesn't make sense to me. CONFIG_SKIP_LOWLEVEL_INIT should
let you skip whatever initialization doesn't need to be done. If
there's some init that needs to be skipped but isn't, that's a bug.
Also, I'd like to point what Ivaylo wrote earlier:
This sounds like a workaround though. Can you instead do the full conversion of
the board? I am sure the board removal patch can be postponed if there is plan
to convert it.
Hard to say if migration to device-tree is even possible on N900 ATM, enabling
OF_CONTROL increases the size of the produced binary with some 100k (.dtb not
included), making the size of the binary way above our budget of ~256k. Sure,
board config does not enable -mthumb, but omap3 in rx-51 suffers from ARM
errata 430973 and noone can guarantee we're not going to see SIGILL faults if
we enable it. Which it seems we are forced to do even with DM_USB migration
only.
Re workaround - I took examples of #ifdef's from the current u-boot code (mmc,
i2c, etc.) so workaround or not, it is no different to what the other drivers
are doing.
If the other drivers have the same logic, it seems a bit weird to me
that the change made in Ivaylo's patch would be rejected because of a
preference to port the board to DT. Unless maybe this was the first
driver to be migrated to support only DT and the patch is in effect a
reversal of some prior work?
Yes, part of the problem here is that DM_USB is the first case that N900
has hit as part of DM conversion that written with using OF_CONTROL in
mind, only. And he's not interested in taking workarounds to provide
the required information via another mechanism (while i2c for example,
is).
It could be that I don't read drivers/usb/host/Makefile right, however,
what I see there is:
ifdef CONFIG_$(SPL_)DM_USB
obj-y += usb-uclass.o
obj-$(CONFIG_SANDBOX) += usb-sandbox.o
endif
to my understanding one can enable CONFIG_SPL_DM_USB and expect it to
build. On the other hand it was stated that OF_CONTROL/DT is not
mandatory for SPL, however, I don't see how is that going to work given
that drivers/usb/host/usb-uclass.c fails to link without OF_CONTROL (and
without $subject patch).
So, either DM_USB cannot be enabled for SPL without OF_CONTROL or I am
in error parsing that Makefile. If the former, then this is a bug the
$subject patch is fixing as a side effect and yet another reason to
merge it.
But another one of the problems here is that N900 doesn't need USB host,
only USB gadget, and you were disabling some of the host stuff that's
being built but not used. A change to not include unused host mode code
entirely would be another path, and you can address moving to
As I said over the irc, we would really appreciate some hints/help from
the maintainer(s) on doing that, "please see what can be done" and then
silence is not really helpful. Not to say shaving the dead weight (in a
shape of unused hostmode code) does not contradict to the $subject patch.
DM_USB_GADGET (which doesn't have a deadline yet, but should be done...)
and see if you have to re-visit the OF_CONTROL problem or not.
>> Of course, in the long run all boards should follow u-boot technological
preferences, but it feels a bit off that this patch would be treated
differently if the existing drivers already use the same logic, and as
far as I can see there is no deadline currently to convert boards to DT,
just for converting them to DM.
The deadline in question here is USB. It's going on 2 years past due
and 3 years since the warning was added. So that we're talking just now
about the problem, since I started off by just removing the platform,
isn't great. And it's not being treated differently, there's no
U_BOOT_DRVINFOS option for USB, which is where those other #ifdef's are
related to, I believe.
But, how is DM_USB going to work for SPL? So, either USB should be
disabled for SPL or DM_USB code must support U_BOOT_DRVINFOS, no?
Ivo
