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.3 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 A1DBCC11F65 for ; Wed, 30 Jun 2021 07:30:37 +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 A840E61D03 for ; Wed, 30 Jun 2021 07:30:36 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A840E61D03 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 3DDA583255; Wed, 30 Jun 2021 09:30:34 +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="PsgvE6m7"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 79A0583258; Wed, 30 Jun 2021 09:30:32 +0200 (CEST) Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) (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 5C64A83255 for ; Wed, 30 Jun 2021 09:30:29 +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-ed1-x534.google.com with SMTP id t3so1779393edt.12 for ; Wed, 30 Jun 2021 00:30:29 -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-language:content-transfer-encoding; bh=H3bNSk0UQURIx+H/M19WJfyRbtFRf+bpyeX9WUwPgi4=; b=PsgvE6m7/EUsVxP9oqPGxcXuTAZCkzgZqzFxC7BJAXm7RljYnvcCI+0enuOQZhTO9r 01P/whwqTG1f3B6z4SA9wF+6nAEx6OxVQBCb0sUHQdJJkUnCW8fJhvJiRdFLJm/QZ9kn HO8W2qFeVZB+Fy0xIAAuQZZN+RXmwbodJ4A1sUG8/qWHB4DeBgjmQ2PEJiq0hLhuYOIJ yzVQCpGEmCwaePGq5lIuzWQNTPqCabB/lzeHotFycsBRpAuB8yswFTfOHaEVRTA6GjKg 6DD3aY5XCn4gNxMS9632WtwQ1F9KVUz+9IzSjIWLyzGs0oxoWLLQUJE9qfgGr4JOaMlJ jQag== 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-language :content-transfer-encoding; bh=H3bNSk0UQURIx+H/M19WJfyRbtFRf+bpyeX9WUwPgi4=; b=K3+UEBGCUSd/Wc9RRWsZyfoGw4CLVzbwzTtzSNkwg4gMG26OKOMeNEXxQc4hZYMs32 prPXkxQFlSp9pDzOHuimqk7/ejwzgUEB34ozSFEUP/CYl33WUyMoYkaHBKqMvlucHnu+ cFWXbyFs7fld7cRQqnOtsiqg1soRZTNi7o5vLFobe6TnqMo0PVZxPK9NiOBYyzZhtL2B +xCft20ePjOxvyr71lQO0zG2whYJXAgwvCtJfH/k53iiSc3G60MpZAsgGniZCErE/oQy okUwxNXduTlRrvrq9x4ditw/cYRkkeYM+qxMgdm55EDngT9sNAc0ZU61Dy6Re0JiFcov yQTA== X-Gm-Message-State: AOAM531hW9KcJXZvPeKTcGqhx67nzkk4GC2ctF6XYmaBw9KDITj+aDkq mwzMoeOVm4xHDeIW8Gnwi/k= X-Google-Smtp-Source: ABdhPJzaZy/Xl8QfQzlW3mvyG2gT1BrFZhBm4obZR2ezk7vGdZM/9HuHRdjFAZfpqnOKJR25XtWQzg== X-Received: by 2002:aa7:d6d6:: with SMTP id x22mr44378317edr.224.1625038228973; Wed, 30 Jun 2021 00:30:28 -0700 (PDT) Received: from [192.168.1.10] ([46.249.74.23]) by smtp.googlemail.com with ESMTPSA id yd2sm9173959ejb.124.2021.06.30.00.30.27 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 30 Jun 2021 00:30:28 -0700 (PDT) Subject: Re: [PATCH 1/2] DM_USB: allow building without OF_CONTROL To: Tom Rini , =?UTF-8?Q?Pali_Roh=c3=a1r?= , Marek Vasut Cc: Merlijn Wajer , Simon Glass , Lokesh Vutla , U-Boot Mailing List , Pavel Machek References: <20210620155426.GB9516@bill-the-cat> <19957b67-732a-f53d-4453-d37ce28a92a9@denx.de> <20210625123847.GM9516@bill-the-cat> <20210625130752.uuh4imvgrab6dylq@pali> <20210625213744.GR9516@bill-the-cat> <20210625215151.ddapfie2feszjsc6@pali> <20210625215902.GS9516@bill-the-cat> <20210626145851.GT9516@bill-the-cat> From: Ivaylo Dimitrov Message-ID: Date: Wed, 30 Jun 2021 10:30:20 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <20210626145851.GT9516@bill-the-cat> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit 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 Hi, 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). > > 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 > 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. > Removing usb-uclass.c and usb_hub.c from the build allows me to enable DM_USB without OF_CONTROL. The resulting binary is 247312 bytes without -mthumb and runs just fine on a real HW. So I guess this is what we were aiming for. Please advice how to proceed - shall I introduce CONFIG_USB_HOST Kconfig option that is enabled by default and ifdef those files based on it? Regards, Ivo