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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 3C78CC433EF for ; Fri, 3 Dec 2021 09:12:54 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 6E89180F6E; Fri, 3 Dec 2021 10:12:51 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=fail (p=none dis=none) header.from=etri.re.kr 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=dooray.com header.i=@dooray.com header.b="T/l+XvbY"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 68AE980FD9; Fri, 3 Dec 2021 10:12:49 +0100 (CET) Received: from mscreen.etri.re.kr (mscreen.etri.re.kr [129.254.9.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id EEC2780F56 for ; Fri, 3 Dec 2021 10:12:40 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=etri.re.kr Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=ckim@etri.re.kr Received: from unknown (HELO send001-relay.gov-dooray.com) (211.180.235.152) by 129.254.9.16 with ESMTP; 3 Dec 2021 18:12:36 +0900 X-Original-SENDERIP: 211.180.235.152 X-Original-MAILFROM: ckim@etri.re.kr X-Original-RCPTTO: u-boot@lists.denx.de Received: from [10.162.225.112] (HELO smtp002-imp.gov-dooray.com) ([10.162.225.112]) by send001-relay.gov-dooray.com with SMTP id 26ba5b7561a9df84; Fri, 03 Dec 2021 18:12:36 +0900 DKIM-Signature: a=rsa-sha256; b=T/l+XvbYxY+hm+8xnWeDVVM2qONDj0GKEh+dHaq/epOl65gFb+CXXOsXMFuFwEZHL4a8hdLae9 BM3L21ww/PreuLroPnSz0FmGt6Z6pQM2tYyBgtkvc9fCzrNM9JxKWBP7rrBfIcPFhQWVz9jpC+Tb 9/EkV77Fd/eN+HEtawzYpXCgdIzQ0789kR21ti5otbhEhvUNTi2aIAmpsyOZW68gMFvhlVebr7HP u7gjYpDsIa+pdeIibkrWZg1cONnY6KE7u7ryLJyMYMn33bGmh+n95bZH/gzKqpGWmOqyPvwMuES8 ve32zeIHuJegBGbvAQEWmfVFCYxx98Laz3Y00erA==; c=relaxed/relaxed; s=selector; d=dooray.com; v=1; bh=fAd7qKnnhB97oOG0MMheS72qDhwt5YA3o/Xp2t5Mq9M=; h=From:To:Subject:Message-ID; Received: from [129.254.132.39] (HELO CHANKIMPC) ([129.254.132.39]) by smtp002-imp.gov-dooray.com with SMTP id 32ac544c61a9df84; Fri, 03 Dec 2021 18:12:36 +0900 From: "Chan Kim" To: "'Abder'" , "'Alex G.'" Cc: "'U-Boot Mailing List'" References: <027001d7e1cb$14bc3b90$3e34b2b0$@etri.re.kr> <27ce6d77-2a3e-a9e2-cce2-00f76d7af57e@gmail.com> <77f0b37f-3e1f-168b-b577-835cbcd9506c@gmail.com> In-Reply-To: Subject: RE: a question about falcon mode Date: Fri, 3 Dec 2021 18:12:36 +0900 Message-ID: <003601d7e825$ea213dc0$be63b940$@etri.re.kr> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJ5aaDc+BW56ASqsIz9Bx90TdqoXAGmVeQvAlZGV/8BapDEiwGXSD37qqWECIA= Content-Language: ko X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.38 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, Alex and Abder, Thank you for the comments. Those will be a good hint for me (especially CONFIG_SPL_RAM_SUPPORT , = using FIT image etc..) in reading the document and doing the experiment = later. Best regards Chan > -----Original Message----- > From: Abder > Sent: Wednesday, December 1, 2021 9:16 PM > To: Alex G. > Cc: Chan Kim ; U-Boot Mailing List = > Subject: Re: a question about falcon mode >=20 > Hi Alex, >=20 > Well yeah! I thought about that, my question was deliberately open to = that > answer too... but what I was looking for is if a dynamic capability = was > (already) implemented in the SPL for generating the fdtargs i.e., = taking > the dtb and the bootargs env variable (plus calculating the address = and > size of the initramfs if used) and putting all that info in the fdtarg > blob just like u-boot does ! > But surely that also can be implemented in the SPL. I'm willing to try > that in the near future... and eventually submit a patch for it, if > everything goes as expected ! >=20 > Thanks for the reply though, and the snippet code too ! >=20 > Best regards > -- > Abder >=20 >=20 > Le lun. 29 nov. 2021 =C3=A0 23:12, Alex G. a = =C3=A9crit : > > > > > > > > On 11/26/21 4:36 PM, Abder wrote: > > > Hi Alex, > > > > > > Just a quick remarque that intrigued me: > > > > > > Le jeu. 25 nov. 2021 =C3=A0 15:57, Alex G. = a =C3=A9crit : > > >> > > >> On 11/25/21 1:07 AM, Chan Kim wrote: > > >>> Hello all, > > >>> > > >>> I'm trying to implement falcon mode for our board. Then should I > > >>> first implement the normal mode(spl + proper)? > > >>> > > >>> It looks like so while I'm reading doc/README.falcon. (It says, > > >>> after loading kernel, DT etc. I should give 'spl export' = command). > > >>> > > >> > > >> Falcon mode is a bit board dependent. There are a couple of ways > > >> you could go about this. > > >> > > >> The first is to have an "fdtargs" partition. This is where "spl > export" > > >> comes in. Once you run "spl export", it will give a modified dtb = at > > >> "$fdtargsaddr". It's that DTB that you need to write to your > > >> ftdargs partition. For example: > > >> > > >> > spl export fdt $loadaddr - $fdt_addr_r > > >> > mmc write $fdtargsaddr 0x9800 0x8000 > > >> > > >> In this example the ftdargs partition starts at sector 0x9800, = and > > >> is > > >> 0x800 sectors long. > > >> > > >> > > >> The second option is to forget about "spl export" and "fdtargs", > > >> and package your kernel, devicetree, and overlays in a FIT > > >> container. You'd make sure to enable SPL_LOAD_FIT_APPLY_OVERLAY. > > >> There isn't much more to this other than the usual gotcha's with = FIT > and overlays. > > >> > > > > > > Do you mean by this that the SPL has the capability to generate = the > > > "fdtargs" by it self (if we provide it with the dtb in the = fitImage) ? > > > > > > Form my last experience with the falcon mode, I had a - not sure - > > > conclusion that the only way to generate the "fdtargs" is by using > > > the "spl export" command from uboot cmdline ! > > > because the reality of the fdtargs blob, as its name indicates, is > > > not just the fdt but it has also the bootargs (inside the chosen > > > node ) that are required by the kernel. So if you give only the = DTB > > > to the SPL it will not work - to my knowledge -, cuz the data that > > > will be passed to the kernel needs to contain also the bootargs ! > > > > > > Can you please confirm to me if this capability is implemented on > > > the SPL and that we can actually forget about the "spl export" > command ? > > > > It might not be obvious that an overlay can contain the "/chosen" = node > > with the appropriate bootargs: > > > > /dts-v1/; > > /plugin/; > > / { > > fragment@1 { > > target-path =3D "/chosen"; > > __overlay__ { > > bootargs =3D "root=3Dblablabla = console=3DttyeS0"; > > }; > > }; > > }; > > > > > Thanks > > > And apologies Chan for jumping on your thread, > > > > > > > > > Best regards, > > > -- > > > Abder > > >