On Friday 25 June 2021 10:04:14 Simon Glass wrote: > Hi Pali, > > On Fri, 25 Jun 2021 at 07:07, Pali Rohár <p...@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.
Well, we are using TI/Nokia X-Loader, not SPL due to above reasons. Like it was for all other TI Omap3/4 boards in past (I guess now TI X-Loader is being replaced by U-Boot SPL part). > 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. Patches in this series were written by Ivo. I do not know exact details and numbers. But the fact is that it was required to enable thumb-2 mode (which has hw bugs on this cpu, see earlier emails; reason why it was disabled). If you want to investigate it, you can try compare u-boot from master/next and u-boot with applying these patches + disable thumb-2 mode. Note that we have already enabled LTO. > > - 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 > > > >
