From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.2 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C8A66C2B9F4 for ; Fri, 25 Jun 2021 21:31:59 +0000 (UTC) Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 9D6C161879 for ; Fri, 25 Jun 2021 21:31:58 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9D6C161879 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 16EE182C0A; Fri, 25 Jun 2021 23:31:56 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="rl5gMSnU"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id AB52082C14; Fri, 25 Jun 2021 23:31:54 +0200 (CEST) Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 13D3E814A4 for ; Fri, 25 Jun 2021 23:31:51 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=ivo.g.dimitrov.75@gmail.com Received: by mail-wr1-x429.google.com with SMTP id b3so12063710wrm.6 for ; Fri, 25 Jun 2021 14:31:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=UgqbRxmKkRqnFBQJxxqtrLdnR1kpx7/TXtQnEpHg69E=; b=rl5gMSnU1fxYKEytAcaSTWuI5SFc0mqAo+Zj35akzoK1L6DuX5xfQv5nX8PkSPa8Sx 2CsWzJF9C0Ohgxz8fcHMAfeAV1r8sC8YrOoFjimmUUavXUU7x2G78vtrHJGgVgqmH5sc UGyQDaAjG2KNuv+eOPhUGhoYiX2gU2MQ8Dp5RoazYRiS6Vuiv0rlTA4mRvp0g2ISo0bE 8SLA/Or0GilSfAcDuxj2W2+Re8oF0YJwJRgFz3jTUx+fTkOAfGs29yCEZH2Bbmna2J97 3xUlBvfCOkk5GrLh/5q5L9x9b+ekH2yK61kY4JVL0uWgjoty9fFpH2gs/49A3gAVbFWU ZIkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=UgqbRxmKkRqnFBQJxxqtrLdnR1kpx7/TXtQnEpHg69E=; b=n2BuztMvJtR/skWaTfyL15NjsJ8QS2JEf6/SXyGpEk7EopVwk3rlYS56ApFFMD7Rzw kriYC5z9k7SikqjAGs6Ja2pkqSFq2oNBKnimzfyKY7z3pCyfjYKBxFRxOrl09H5hxVku P87osuE/2KDu4FHQ3Tt/c7D6ABEN8m5NnPe3k4W3MjRyOk4tu9RZVtl3wzrTlihyRKpk Ftxq8A4fESlkAU8EHp3+eQeHUKLWzfi56/14c7zsOR4Cmhaw4IT96GvpWNpodXs95mZh hSrDZ57r7ti5CYZ4/SCLwSL7+J3UZGFLpNecmhRgHSFLWXxpJw+YjJrPKBh6Yw7slsXS Y4UA== X-Gm-Message-State: AOAM533/KyNOY9Cxlp9NWT/U5/Q4uVdqknLfM+ENx/PIIn6zlq99Srp5 XCz0CGks8YYuZZTdUi4YuMs= X-Google-Smtp-Source: ABdhPJzqfCUrWbeD2gK9gvWzZlZqONi6SC1PW7of3sQ+ueM7814gXREI9joxcRNdGEz2KlIvbZr1vw== X-Received: by 2002:adf:f20c:: with SMTP id p12mr13534957wro.257.1624656710561; Fri, 25 Jun 2021 14:31:50 -0700 (PDT) Received: from [10.0.2.15] (ppp-94-69-158-249.home.otenet.gr. [94.69.158.249]) by smtp.googlemail.com with ESMTPSA id s18sm7123243wrw.33.2021.06.25.14.31.49 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 25 Jun 2021 14:31:50 -0700 (PDT) Subject: Re: [PATCH 1/2] DM_USB: allow building without OF_CONTROL To: Simon Glass , =?UTF-8?Q?Pali_Roh=c3=a1r?= Cc: Tom Rini , Marek Vasut , Lokesh Vutla , Merlijn Wajer , U-Boot Mailing List , Pavel Machek References: <3c44a3cf-b9ad-1b31-d0a4-54c896222d78@gmail.com> <0a8a9dab-ee44-fab7-d712-d66cb121c170@gmail.com> <249e8e4f-b5f7-1f97-adbd-a83d75883ef4@denx.de> <338bfdad-15f6-fbff-6fde-d0411e585bf4@gmail.com> <20210619205129.GA9516@bill-the-cat> <7c4024e6-f58e-1f9a-d969-0d0b190c2484@denx.de> <20210620155426.GB9516@bill-the-cat> <19957b67-732a-f53d-4453-d37ce28a92a9@denx.de> <20210625123847.GM9516@bill-the-cat> <20210625130752.uuh4imvgrab6dylq@pali> From: Ivaylo Dimitrov Message-ID: Date: Sat, 26 Jun 2021 00:31:49 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.34 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.2 at phobos.denx.de X-Virus-Status: Clean On 25.06.21 г. 19:04 ч., Simon Glass wrote: > Hi Pali, > > On Fri, 25 Jun 2021 at 07:07, Pali Rohár 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. It seems OF_CONTROL pulls everything and the kitchen sink (stuff like EFI loader support, for example). I am on holiday ATM with limited access to my home PC (slow internet), however, one can easily recreate the issue on the current master by just adding CONFIG_OF_CONTROL=y to N900 defconfig. Build will fail (no DTS), but no_dts binary built is well above 350kB vs ~240kB without . In regards to SPL - there is no way to sign SPL with the keys used by Nokia to sign NOLO(the proprietary second stage loader), we simply don't have them. Without that, we can't replace NOLO. Ivo > - 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 >>