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=-7.3 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, 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 1C668C2B9F4 for ; Thu, 17 Jun 2021 18:21:17 +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 122BD613D8 for ; Thu, 17 Jun 2021 18:21:14 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 122BD613D8 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=konsulko.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 A374282A29; Thu, 17 Jun 2021 20:21:12 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=konsulko.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (1024-bit key; unprotected) header.d=konsulko.com header.i=@konsulko.com header.b="c31tk1X3"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 00FF282A29; Thu, 17 Jun 2021 20:21:11 +0200 (CEST) Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com [IPv6:2607:f8b0:4864:20::836]) (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 8C13D82971 for ; Thu, 17 Jun 2021 20:21:06 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=konsulko.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=trini@konsulko.com Received: by mail-qt1-x836.google.com with SMTP id o20so5484219qtr.8 for ; Thu, 17 Jun 2021 11:21:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=konsulko.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=ZhXui6/DR7UH2ST7OQjmsoCz7d6A2zLtUVbW+UjItL0=; b=c31tk1X3cxZtl5Saus0yZdn7o+KdjNMwYAIqIDHSDwqKhjBGxZmPKFSdbvYDy/24fo 45bx5fR/nXDfQybJHMZzrioPgHR84iapORv4ZHJdRaeCrt50ORsxShLedwWdAGCsvqQH OqfBzI/ywwOP3HIHXqYWp9KqTHEuCvYTSR0JE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=ZhXui6/DR7UH2ST7OQjmsoCz7d6A2zLtUVbW+UjItL0=; b=DoVBRczukh2z4ZTZLEOR3cTpAQD99LOVn1lPp5BTmqgr16pTNGxViy/Q6l2CcJ+kHa OYMiGnsafgdtjVEbBlQOMBqvFsg9G89XXZzBBXg6f+l0lj1HeL1XIfyoYYRX2SBiN1Ex +B3WZMs11X+O+nSPYO1EXY0gnpEeNhHIkvb3mWXz9y3aEeQr2Tb2tslVu1N9o1r+MkWm Xj26mE9XrEmLXSUo/7HYhyHYHJibN/bUe7pINmEeYJayp+Tz3oE2pFE2G9vcqWBJVDK6 S8MirjGjy97rt4cLTUuNzSMf33JqdeJFZ8vJgP7pQvxUTurI3qwu6JgLNCIUtaY3ngYo Nedg== X-Gm-Message-State: AOAM532zZ4+sBvRV+GWBexf7P6fDfOBGI+lrX5WfTh3mSRH2LcXufDMZ nZMw4QS98GCo6+vg/68bpnY2cQ== X-Google-Smtp-Source: ABdhPJy8jehIyUY4w//+WSK7Ae68yE8iD7t3MFZ+fI+2r2OF6A/ZEPmIis8UMMaWDz7uRUHlX7hjig== X-Received: by 2002:ac8:6885:: with SMTP id m5mr6549386qtq.268.1623954065087; Thu, 17 Jun 2021 11:21:05 -0700 (PDT) Received: from bill-the-cat (2603-6081-7b01-cbda-8009-22e2-67e2-281e.res6.spectrum.com. [2603:6081:7b01:cbda:8009:22e2:67e2:281e]) by smtp.gmail.com with ESMTPSA id i21sm2278468qkl.20.2021.06.17.11.21.03 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Thu, 17 Jun 2021 11:21:03 -0700 (PDT) Date: Thu, 17 Jun 2021 14:21:02 -0400 From: Tom Rini To: Ivaylo Dimitrov Cc: Pali =?iso-8859-1?Q?Roh=E1r?= , maemo-leste@lists.dyne.org, u-boot@lists.denx.de, Merlijn Wajer Subject: Re: [maemo-leste] [PATCH] arm: Remove nokia_rx51 board Message-ID: <20210617182102.GM9516@bill-the-cat> References: <20210615123436.GH9516@bill-the-cat> <5848e9c9-4dab-00cc-07dc-ffa57b9417cd@gmail.com> <20210616121008.GR9516@bill-the-cat> <20210616121313.GS9516@bill-the-cat> <20210616173702.GW9516@bill-the-cat> <20210616211213.GZ9516@bill-the-cat> <6b4732f2-0733-7bbe-f7a1-95b39deba5cb@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="RM4LNcG2CLff9Gl5" Content-Disposition: inline In-Reply-To: <6b4732f2-0733-7bbe-f7a1-95b39deba5cb@gmail.com> X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.9.4 (2018-02-28) 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 --RM4LNcG2CLff9Gl5 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jun 17, 2021 at 10:18:07AM +0300, Ivaylo Dimitrov wrote: >=20 >=20 > On 17.06.21 =D0=B3. 0:12 =D1=87., Tom Rini wrote: > > On Thu, Jun 17, 2021 at 12:03:15AM +0300, Ivaylo Dimitrov wrote: > > > Hi Tom, > > >=20 > > > On 16.06.21 =D0=B3. 20:37 =D1=87., Tom Rini wrote: > > > > On Wed, Jun 16, 2021 at 08:25:28PM +0300, Ivaylo Dimitrov wrote: > > > > > Hi, > > > > >=20 > > > > > On 16.06.21 =D0=B3. 15:13 =D1=87., Tom Rini wrote: > > > > > > On Wed, Jun 16, 2021 at 08:10:08AM -0400, Tom Rini wrote: > > > > > > > On Wed, Jun 16, 2021 at 09:02:16AM +0300, Ivaylo Dimitrov wro= te: > > > > > > > > Hi, > > > > > > > >=20 > > > > > > > > On 15.06.21 =D0=B3. 15:34 =D1=87., Tom Rini wrote: > > > > > > > > > On Tue, Jun 15, 2021 at 08:40:30AM +0300, Ivaylo Dimitrov= wrote: > > > > > > > > > > Hi, > > > > > > > > > >=20 > > > > > > > > > > On 22.05.21 =D0=B3. 0:36 =D1=87., Pali Roh=C3=A1r wrote: > > > > > > > > > > > On Friday 21 May 2021 10:44:18 Tom Rini wrote: > > > > > > > > > > > > On Wed, May 19, 2021 at 11:52:03AM -0400, Tom Rini = wrote: > > > > > > > > > > > > > On Wed, May 19, 2021 at 03:27:48PM +0200, Pali Ro= h=C3=A1r wrote: > > > > > > > > > > > > >=20 > > > > > > > > > > > > > > On Tuesday 18 May 2021 21:26:40 Tom Rini wrote: > > > > > > > > > > > > > > > This board has not been converted to CONFIG_D= M_USB by the deadline. > > > > > > > > > > > > > > > Remove it. > > > > > > > > > > > > > >=20 > > > > > > > > > > > > > > I'm very disappointed that you want to remove N= okia N900 from U-Boot. > > > > > > > > > > > > > >=20 > > > > > > > > > > > > > > I was waiting waiting half of year because othe= r developers did not > > > > > > > > > > > > > > react to issues which were introduced and neith= er to patches which I > > > > > > > > > > > > > > sent (+ trying to remind open issues). And also= I was waiting another > > > > > > > > > > > > > > half of year until other N900 related patches w= ere merged. So the whole > > > > > > > > > > > > > > slowdown was not caused by me, why it is taking= so long. > > > > > > > > > > > > > >=20 > > > > > > > > > > > > > > Now there is still one N900 DM related patch wa= iting for review. I'm > > > > > > > > > > > > > > converting code step by step. > > > > > > > > > > > > > >=20 > > > > > > > > > > > > > > So the ball is not on my side. > > > > > > > > > > > > >=20 > > > > > > > > > > > > > So, what patch(es) need to be applied to get DM_U= SB enabled? Thanks. > > > > > > > > > > > >=20 > > > > > > > > > > > > I don't see any open patches from you that look rel= ated to enabling > > > > > > > > > > > > DM_USB on the platform. If you want to disable USB= on the platform for > > > > > > > > > > > > now instead, that's fine too. > > > > > > > > > > >=20 > > > > > > > > > >=20 > > > > > > > > > > I tried to migrate the latest master to DM_USB, but unf= ortunately the > > > > > > > > > > results are pretty much sad - adding OF_CONTROL (which = is a prerequisite to > > > > > > > > > > have DM_USB IIUC) and OF_BOARD (so binary to be compile= d), adds ~100k to the > > > > > > > > > > size of the u-boot binary, so it becomes 370284 bytes. = Given that we have > > > > > > > > > > less than 256k of storage space for the u-boot, the pro= duced binary cannot > > > > > > > > > > be used on n900 the same way current (no DM_USB) binary= is used. > > > > > > > > > >=20 > > > > > > > > > > As I see it, there are not much options left - u-boot o= n N900 is not SPL, so > > > > > > > > > > we can't use OF_PLATDATA, which in turn always links li= bfdt. > > > > > > > > > > Also, if I read the code (usb-uclass.c) correctly, enab= ling DM_USB requires > > > > > > > > > > the board to be converted to DT and this is way bigger = change. > > > > > > > > > >=20 > > > > > > > > > > Please advice on how to proceed. > > > > > > > > >=20 > > > > > > > > > Please post your WIP patches, thanks. > > > > > > > > >=20 > > > > > > > >=20 > > > > > > > > Sorry, I am not sure I understand what patches you want me = to post: > > > > > > > >=20 > > > > > > > > WDT patch has already been sent couple of months ago - > > > > > > > > https://lists.denx.de/pipermail/u-boot/2021-March/443868.ht= ml > > > > > > > > Do you want it to be rebased and resend? > > > > > > > >=20 > > > > > > > > DM_USB, I just started writing one and I immediately hit th= e OF_CONTROL > > > > > > > > requirement. Enabling OF_CONTROL requires a full blown migr= ation to DT, > > > > > > > > which is a huge task and not really equal to "Please update= the board to use > > > > > > > > CONFIG_DM_USB...". Without OF_CONTROL, I simply get link fa= ilures: > > > > > > > >=20 > > > > > > > > /usr/lib/gcc-cross/arm-linux-gnueabi/8/../../../../arm-linu= x-gnueabi/bin/ld: > > > > > > > > /usr/lib/gcc-cross/arm-linux-gnueabi/8/../../../../arm-linu= x-gnueabi/bin/ld: > > > > > > > > DWARF error: could not find abbrev number 3998 > > > > > > > > /tmp/cc0BOqms.ltrans0.ltrans.o: in function `usb_child_post= _bind': > > > > > > > > :(.text+0x5672): undefined reference to > > > > > > > > `ofnode_read_u32_default' > > > > > > > > /usr/lib/gcc-cross/arm-linux-gnueabi/8/../../../../arm-linu= x-gnueabi/bin/ld: > > > > > > > > :(.text+0x568c): undefined reference to > > > > > > > > `ofnode_read_u32_default' > > > > > > > > /usr/lib/gcc-cross/arm-linux-gnueabi/8/../../../../arm-linu= x-gnueabi/bin/ld: > > > > > > > > /tmp/cc0BOqms.ltrans0.ltrans.o: in function `usb_scan_devic= e': > > > > > > > > :(.text+0x6c84): undefined reference to `ofnode= _first_subnode' > > > > > > > > /usr/lib/gcc-cross/arm-linux-gnueabi/8/../../../../arm-linu= x-gnueabi/bin/ld: > > > > > > > > :(.text+0x6c96): undefined reference to `ofnode= _read_u32' > > > > > > > > /usr/lib/gcc-cross/arm-linux-gnueabi/8/../../../../arm-linu= x-gnueabi/bin/ld: > > > > > > > > :(.text+0x6ca4): undefined reference to `ofnode= _next_subnode' > > > > > > > > /usr/lib/gcc-cross/arm-linux-gnueabi/8/../../../../arm-linu= x-gnueabi/bin/ld: > > > > > > > > /tmp/cc0BOqms.ltrans0.ltrans.o:(.u_boot_list_2_uclass_drive= r_2_usb+0x8): > > > > > > > > undefined reference to `dm_scan_fdt_dev' > > > > > > > > /usr/lib/gcc-cross/arm-linux-gnueabi/8/../../../../arm-linu= x-gnueabi/bin/ld: > > > > > > > > /tmp/cc0BOqms.ltrans0.ltrans.o:(.u_boot_list_2_uclass_drive= r_2_usb_hub+0x8): > > > > > > > > undefined reference to `dm_scan_fdt_dev' > > > > > > > >=20 > > > > > > > > Fixing those requires enabling of OF_CONTROL and this in tu= rn means the > > > > > > > > board must be migrated to DT, unless I am missing something= =2E That's why my > > > > > > > > "please advice..." stance. > > > > > > >=20 > > > > > > > Please post the patches that bring you to the above link erro= rs, yes, > > > > > > > thanks. > > > > > >=20 > > > > > > To be clearer, finish up a patch that completes the migration b= ut is too > > > > > > large to install on the hardware so that others can take a look. > > > > >=20 > > > > > I am not sure I understand that - a patch that completes the migr= ation to > > > > > DM_USB cannot be done ATM as the binary does not link without OF_= CONTROL. > > > > > And I am not going to enable OF_CONTROL as this means I will have= to migrate > > > > > everything to DT. That's why I enable DM_USB only - see reply to = the other > > > > > mail. > > > >=20 > > > > My advise is to provide a linkable but not runnable (or, only runna= ble > > > > in QEMU, the problem is the fixed layout of the actual device flash, > > > > right?) patch so that we can figure out how and what needs to be tu= ned > > > > where so that we can see what to do about this platform. > > > >=20 > > >=20 > > > What about the following patch (once you confirm I am on the right tr= ack, I > > > will send a proper patch as well). Enabling thumb is a must, otherwise > > > binary does not fit. With the below changes code compiles and runs on= a real > > > HW: > >=20 > > Wait, why is thumb disabled? That's something I'd really like to know > > why on as my first guess is there's units with old enough cores that > > have some thumb errata maybe? >=20 > omap3 in N900 suffers from ARM errata 430973, I guess that's why -mthumb = was > disabled back then. I implemented N900 specific workaround to set the IBE > bit in ACR in the board code, but I don't see flush BTAC/BTB being execut= ed > on context switch (if there are context switches at all). The only places= I > was able to find that flush BTAC/BTB instruction are on startup > (cpu_init_cp15()) and cache invalidate (invalidate_icache_all()). >=20 > BTW the code in cpu_init_cp15() is buggy, as flush is executed before IBE > bit in ACR is set, making that flush effectively a noop on boards where I= BE > bit was not set by the previous stage loader, but that's another story not > affecting N900 :). A separate thread / patch on that would be much appreciated :) > So, as soon as there are no context switches in u-boot that may land > different code on a same physical address, we should be safe. Could you > confirm this is the case? Is there virtual addressing? Multiple processes? The only place I'm not 100% sure we wouldn't have virtual addressing would be when you start to involve the EFI loader and in turn EFI applications are running. But we're specifically disabling this here (and I don't think it's useful on this era hardware anyhow). > > For the second part, how are you binding > > the device? And oh, we didn't disable the EFI loader support already? >=20 > Yeah, looks like selecting libfdt automagically selects a whole bunch of > other things (like CMD_FDT and OF_LIBFDT_OVERLAY) >=20 > > Yeah, that would be another pretty easy choice to win back a bunch of > > space. So yes, this is certainly on the right track, thanks! > >=20 >=20 > Ok, we'll send a proper patch series as soon as it is confirmed that it is > safe to enable -mthumb. Thanks. > In the meanwhile, could you please have a look at the WDT patch Pali post= ed > back then? It's been merged to -next for a little while now, via the TI tree. --=20 Tom --RM4LNcG2CLff9Gl5 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAABCgAdFiEEGjx/cOCPqxcHgJu/FHw5/5Y0tywFAmDLkosACgkQFHw5/5Y0 tywfCQwAnt6swxCnvwZkineDD8qly7j4tvw8puHXLfW4Cfx6SjhLvez2K4oh/e1w 8HY0/0aAkwVJCKy4kTG+PYKsKeMavkyd1jWtp/xP9s4f2QLUu3qah7c78CDrV5mc v6/tRhtVenqQxRnkD+j5BCUTJSNj7c+8MAhOaLYcgbZrjqlwR/TCGm1DwEUIDkKm 3ojhMFmEVhhKy0p2IhKcP+b9rdnxSkwpRfVT6bjowbDxf72GYDZc6rjD/lBP8OMT 03fUilpS05ZXkAnMh8x0Q+KHth1BknnWLQhs1F2WDonNUfyAdTCVzraxdBpoGegC kNC72lQs6wxztndR8dh+JSquch7J9Z8s8pyZwcCtNUy4QXvdfOMepjyyVL1Z+L91 aBDTRcvhzRMgJqYPyOrEYShduqJaoY0bh1WmyiePw3Jt9IWwY6TXzE2yEUF9aatC qRPjcEkjN+1Bjwj+AcGG/y0liukOpsVKuRWgVKMlHrb0Uu9g20/TJ+bQo8Rno15G 1M9qXCIq =mUhz -----END PGP SIGNATURE----- --RM4LNcG2CLff9Gl5--