| Message ID | 20191221075440.6944-3-jagan@amarulasolutions.com |
|---|---|
| State | New |
| Headers |
Return-Path: <linux-amarula+bncBD7MFH7A7EEBBUU767XQKGQEMBOPQLY@amarulasolutions.com> X-Original-To: linux-amarula@patchwork.amarulasolutions.com Delivered-To: linux-amarula@patchwork.amarulasolutions.com Received: from mail-pf1-f199.google.com (mail-pf1-f199.google.com [209.85.210.199]) by ganimede.amarulasolutions.com (Postfix) with ESMTPS id C5F763F08E for <linux-amarula@patchwork.amarulasolutions.com>; Sat, 21 Dec 2019 08:54:59 +0100 (CET) Received: by mail-pf1-f199.google.com with SMTP id r17sf7763399pfl.2 for <linux-amarula@patchwork.amarulasolutions.com>; Fri, 20 Dec 2019 23:54:59 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1576914898; cv=pass; d=google.com; s=arc-20160816; b=LhwP4aIDFPSCLW/0l0aYmvLSlA829FSVCYvPLI6VyoScfIWVtxskznMgBa9JQ3MgE7 +ZEW9fVODUZK20fu4nNHrnePfZPqhr5DoyAR4BJ3oFaVmLC2mVimBLXDJsWp2/xAqw4c wRt2jumQM1qJ6EjsflREfEihwANv7OtIqWOlkwH7GT0AVpa7yIZDCw1SWS+OF5p0jcJ8 Vgbmpgzayp29dZlbdz38UjHLPunlNj45ZB+fU0JmcyD6oS/vbTZEKlN8hwolWcT1E88l 63ePRXk2p/41hIKgAaCF3O2AXgyW91+HvCV+VHaYQnNzXgrAOtQl9RHhYHEc1xAX2P1O U4pg== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-unsubscribe:list-archive:list-help:list-post:list-id :mailing-list:precedence:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:dkim-signature; bh=Tm5NqBKEVBnOdzW2FSonNB+atSaRJ4sknf++zPRRtVQ=; b=YvF79EDhSZS5WffwKSvHxCj1rvSr4G+3kFGllnFZgXAfA7hYXs514UnThTq0YE7p3z xcdbLVsMRuYnAcie015roXBJugzy4g0YDlDieQdCwo6jffQkzRmJdEZcHMuD9ESAK3wE 5+k+SfEUU96uwKcykLzDnPmSMVgZxD76fZ+zMii6nauYuwuxEGJ9cdlLmitr8p+JyBc1 swWIhu5RL6NqkI0E2Uu7NKbpxN5M8MQVWyUl2xVPwSViphJdjsxSFdp2mn5q3E8NFLDG ceR4NZMpfEAgGBZCHQ5fg5tsvqzgEx+7TUVvlEO30+Oz8yOrkKW8MURsMCLf/er3sY0G PILg== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@amarulasolutions.com header.s=google header.b=rXgiNGgr; spf=pass (google.com: domain of jagan@amarulasolutions.com designates 209.85.220.65 as permitted sender) smtp.mailfrom=jagan@amarulasolutions.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amarulasolutions.com; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:x-original-sender:x-original-authentication-results :precedence:mailing-list:list-id:list-post:list-help:list-archive :list-unsubscribe; bh=Tm5NqBKEVBnOdzW2FSonNB+atSaRJ4sknf++zPRRtVQ=; b=XmRzfDP3dts9tQUkZqX/lxxMhvOrfEbrCbps1oxECWnlwObshYrL0JAcWUT1bHHTuQ C2n1C3CUJz2H68nWtVY7q2kcJGcCTTGDrLou3/Tq5v8oLILPIWRsiiTCCz81v5WAw8Mr d18KuiWqo3N0B/N7aGfrXG+QQGhX+ITpM1JIE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:x-original-sender :x-original-authentication-results:precedence:mailing-list:list-id :x-spam-checked-in-group:list-post:list-help:list-archive :list-unsubscribe; bh=Tm5NqBKEVBnOdzW2FSonNB+atSaRJ4sknf++zPRRtVQ=; b=uSojOiZ06js309JH4Q4vCaZYlMXF4rr4s8Egod6aiyCnU0J6nsqT483VObXH4H8/1F PmlVW1S+srqYuVTRHEBUnyHZAIMEwDgKWY/i7ub4k3IMq8BK8IpvuMvtkVk1kUKUJq0W nRilPRITlklHBdVUmciVvxsioSn+sFNRrM6Xfm67jg87XnqxHQtlnVL6Bu4bb87On1A4 NTuOq5jba/VL1uxO2ROE09RkLr5PLL/nvJE9spPmth88djSU8aaPiVNlDT5ETtQ3tlLK q+hgyQl5jqlNAzbRvYlMtrX9mQzcTuP6GM+qBA+VLQcCrl7ouUi72MnB5tvCrQnoEuvw B2tA== X-Gm-Message-State: APjAAAX141Dlimg1k41V1YwRokdby5S9pChm0yKtF5MFGylzurZextK5 f1dIkVpMVJ7Ujw3pRAbBH8Gg6JyL X-Google-Smtp-Source: APXvYqyCc/42Kt69Z9q7B7CQPMgsEvF1AIlMvvDMNiRhIG9vQ6tmyrhB5A6xIlF4e1D+5qHUQKe0yA== X-Received: by 2002:aa7:9729:: with SMTP id k9mr21056125pfg.72.1576914898650; Fri, 20 Dec 2019 23:54:58 -0800 (PST) X-BeenThere: linux-amarula@amarulasolutions.com Received: by 2002:aa7:8d43:: with SMTP id s3ls3045453pfe.14.gmail; Fri, 20 Dec 2019 23:54:58 -0800 (PST) X-Received: by 2002:a63:2cc8:: with SMTP id s191mr19285838pgs.206.1576914898144; Fri, 20 Dec 2019 23:54:58 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1576914898; cv=none; d=google.com; s=arc-20160816; b=cda6apd8b5gixni/AAiCy7wP5jZePStGj35wvsfwJzUEcLd4zLYgy9Tl0Xx9chJ5vr PxhKowq8X7FAD2XsRwcCPpF2RxPKvHwYzk2uUke1KpXHoi3Rzq10YCWpCMgbO/pONRNh v/ao3EJD/bFBi6rnv2qlBN+cnosKo3nUQmHxVhqa96s+PwiS4yQIb8bJ+yFQBK8Q1lpi tkf3ijfwIYq8fcp0vQvOjQ7N8c2INbbUkVFKfnPDZNUCHWbsJARmxdkVbZQfAQAe07q8 ieWTF3Wvf205/eW4mxoq33H0L9RD6FSES2YhjMEJSCsKtzKdjHh4PKQOHcd4fhvWkJ7n DgTA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:dkim-signature; bh=jM8vNSgXmvPlNxsqNzC3s3ZZdWuXAaTtjcTjHWND2aE=; b=j/RGdQ8mAncB1oCz87KiNsSqRSLqJHg/QFtvWCCm8mn5l3PBuw0/c2pFz1oTDmkDx+ VuAEKmKQzulFuSDEdo7dm/EIDj+nFCH1Y/y9lAF65Cu7nb+D87k6eH4c/Lphr0h2gjsE Lugj7M9hK4HO7SaufY3UcQV+vFWB7jF0HURmGujJvgvnhAtVzMoPOGnLfIq1uEQ1h6Ug fUt+Ytk33FH4LBioXc2vXcGviZiLuyyHICkvbQ91GxyXmzLg87Lo7R5quJqVHr8Kah86 CM87Oz1F/88hLz+AmDugL7HOmIDbCQyKnoZr3hWJDs71UQlu4Q7gXM5F+MxeN6pdhArA cA+A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@amarulasolutions.com header.s=google header.b=rXgiNGgr; spf=pass (google.com: domain of jagan@amarulasolutions.com designates 209.85.220.65 as permitted sender) smtp.mailfrom=jagan@amarulasolutions.com Received: from mail-sor-f65.google.com (mail-sor-f65.google.com. [209.85.220.65]) by mx.google.com with SMTPS id jx16sor12823609pjb.7.2019.12.20.23.54.57 for <linux-amarula@amarulasolutions.com> (Google Transport Security); Fri, 20 Dec 2019 23:54:57 -0800 (PST) Received-SPF: pass (google.com: domain of jagan@amarulasolutions.com designates 209.85.220.65 as permitted sender) client-ip=209.85.220.65; X-Received: by 2002:a17:90a:7781:: with SMTP id v1mr21241475pjk.57.1576914897548; Fri, 20 Dec 2019 23:54:57 -0800 (PST) Received: from localhost.localdomain ([49.206.202.177]) by smtp.gmail.com with ESMTPSA id i9sm15551018pfk.24.2019.12.20.23.54.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 20 Dec 2019 23:54:57 -0800 (PST) From: Jagan Teki <jagan@amarulasolutions.com> To: Simon Glass <sjg@chromium.org>, Kever Yang <kever.yang@rock-chips.com>, Philipp Tomsich <philipp.tomsich@theobroma-systems.com> Cc: u-boot@lists.denx.de, linux-amarula <linux-amarula@amarulasolutions.com>, linux-rockchip@lists.infradead.org, Jagan Teki <jagan@amarulasolutions.com>, Tom Rini <trini@konsulko.com> Subject: [PATCH 02/11] distro_bootcmd: Add SF support Date: Sat, 21 Dec 2019 13:24:31 +0530 Message-Id: <20191221075440.6944-3-jagan@amarulasolutions.com> X-Mailer: git-send-email 2.18.0.321.gffc6fa0e3 In-Reply-To: <20191221075440.6944-1-jagan@amarulasolutions.com> References: <20191221075440.6944-1-jagan@amarulasolutions.com> MIME-Version: 1.0 X-Original-Sender: jagan@amarulasolutions.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@amarulasolutions.com header.s=google header.b=rXgiNGgr; spf=pass (google.com: domain of jagan@amarulasolutions.com designates 209.85.220.65 as permitted sender) smtp.mailfrom=jagan@amarulasolutions.com Content-Type: text/plain; charset="UTF-8" Precedence: list Mailing-list: list linux-amarula@amarulasolutions.com; contact linux-amarula+owners@amarulasolutions.com List-ID: <linux-amarula.amarulasolutions.com> X-Spam-Checked-In-Group: linux-amarula@amarulasolutions.com X-Google-Group-Id: 476853432473 List-Post: <https://groups.google.com/a/amarulasolutions.com/group/linux-amarula/post>, <mailto:linux-amarula@amarulasolutions.com> List-Help: <https://support.google.com/a/amarulasolutions.com/bin/topic.py?topic=25838>, <mailto:linux-amarula+help@amarulasolutions.com> List-Archive: <https://groups.google.com/a/amarulasolutions.com/group/linux-amarula/> List-Unsubscribe: <mailto:googlegroups-manage+476853432473+unsubscribe@googlegroups.com>, <https://groups.google.com/a/amarulasolutions.com/group/linux-amarula/subscribe> |
| Series |
rk3399: SPI boot support (fixes, updates)
|
|
Commit Message
Jagan Teki
Dec. 21, 2019, 7:54 a.m. UTC
Add distro boot command support for SPI flash.
This distro boot will read the boot script at specific
location at the flash and start sourcing the same.
The common macro like BOOTENV_SHARED_FLASH would help
to extend the support for nand flash in future.
Cc: Tom Rini <trini@konsulko.com>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
include/config_distro_bootcmd.h | 35 +++++++++++++++++++++++++++++++++
1 file changed, 35 insertions(+)
Comments
On 2019/12/21 下午3:54, Jagan Teki wrote: > Add distro boot command support for SPI flash. > > This distro boot will read the boot script at specific > location at the flash and start sourcing the same. > > The common macro like BOOTENV_SHARED_FLASH would help > to extend the support for nand flash in future. > > Cc: Tom Rini <trini@konsulko.com> > Signed-off-by: Jagan Teki <jagan@amarulasolutions.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com> Thanks, - Kever > --- > include/config_distro_bootcmd.h | 35 +++++++++++++++++++++++++++++++++ > 1 file changed, 35 insertions(+) > > diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h > index fc0935fa21..d68b79e290 100644 > --- a/include/config_distro_bootcmd.h > +++ b/include/config_distro_bootcmd.h > @@ -43,6 +43,22 @@ > #define BOOTENV_DEV_NAME_BLKDEV(devtypeu, devtypel, instance) \ > #devtypel #instance " " > > +#define BOOTENV_SHARED_SF_BODY(devtypel) \ > + "if " #devtypel " probe ${devnum}; then " \ > + "devtype=" #devtypel "; " \ > + "run scan_flash_for_scripts; " \ > + "fi\0" > + > +#define BOOTENV_SHARED_FLASH(devtypel) \ > + #devtypel "_boot=" \ > + BOOTENV_SHARED_SF_BODY(devtypel) > + > +#define BOOTENV_DEV_FLASH(devtypeu, devtypel, instance) \ > + BOOTENV_DEV_BLKDEV(devtypeu, devtypel, instance) > + > +#define BOOTENV_DEV_NAME_FLASH(devtypeu, devtypel, instance) \ > + BOOTENV_DEV_NAME_BLKDEV(devtypeu, devtypel, instance) > + > #ifdef CONFIG_SANDBOX > #define BOOTENV_SHARED_HOST BOOTENV_SHARED_BLKDEV(host) > #define BOOTENV_DEV_HOST BOOTENV_DEV_BLKDEV > @@ -398,6 +414,18 @@ > BOOT_TARGET_DEVICES_references_PXE_without_CONFIG_CMD_DHCP_or_PXE > #endif > > +#if defined(CONFIG_CMD_SF) > +#define BOOTENV_SHARED_SF BOOTENV_SHARED_FLASH(sf) > +#define BOOTENV_DEV_SF BOOTENV_DEV_FLASH > +#define BOOTENV_DEV_NAME_SF BOOTENV_DEV_NAME_FLASH > +#else > +#define BOOTENV_SHARED_SF > +#define BOOTENV_DEV_SF \ > + BOOT_TARGET_DEVICES_references_SF_without_CONFIG_CMD_SF > +#define BOOTENV_DEV_NAME_SF \ > + BOOT_TARGET_DEVICES_references_SF_without_CONFIG_CMD_SF > +#endif > + > #define BOOTENV_DEV_NAME(devtypeu, devtypel, instance) \ > BOOTENV_DEV_NAME_##devtypeu(devtypeu, devtypel, instance) > #define BOOTENV_BOOT_TARGETS \ > @@ -412,6 +440,7 @@ > BOOTENV_SHARED_USB \ > BOOTENV_SHARED_SATA \ > BOOTENV_SHARED_SCSI \ > + BOOTENV_SHARED_SF \ > BOOTENV_SHARED_NVME \ > BOOTENV_SHARED_IDE \ > BOOTENV_SHARED_UBIFS \ > @@ -436,6 +465,12 @@ > "echo SCRIPT FAILED: continuing...; " \ > "fi\0" \ > \ > + "scan_flash_for_scripts=" \ > + "${devtype} read ${scriptaddr} " \ > + "${script_offset_f} ${script_size_f}; " \ > + "source ${scriptaddr}; " \ > + "echo SCRIPT FAILED: continuing...\0" \ > + \ > "boot_a_script=" \ > "load ${devtype} ${devnum}:${distro_bootpart} " \ > "${scriptaddr} ${prefix}${script}; " \
+A few people that may have insight to my question On Sat, Dec 21, 2019 at 01:24:31PM +0530, Jagan Teki wrote: > Add distro boot command support for SPI flash. > > This distro boot will read the boot script at specific > location at the flash and start sourcing the same. > > The common macro like BOOTENV_SHARED_FLASH would help > to extend the support for nand flash in future. > > Cc: Tom Rini <trini@konsulko.com> > Signed-off-by: Jagan Teki <jagan@amarulasolutions.com> What distro is this for? My concern here is that hundreds of boards (literally) grow by a few hundred bytes to add in this bit of additional default logic. That's not a big problem if distributions are now going to be using SPI flash as where they're programming in their bootscript. But, who is doing that? Thanks!
On Mon, Jan 20, 2020 at 11:10 PM Alexander Graf <agraf@csgraf.de> wrote: > > > On 20.01.20 18:22, Tom Rini wrote: > > +A few people that may have insight to my question > > > > On Sat, Dec 21, 2019 at 01:24:31PM +0530, Jagan Teki wrote: > > > >> Add distro boot command support for SPI flash. > >> > >> This distro boot will read the boot script at specific > >> location at the flash and start sourcing the same. > >> > >> The common macro like BOOTENV_SHARED_FLASH would help > >> to extend the support for nand flash in future. > >> > >> Cc: Tom Rini <trini@konsulko.com> > >> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com> > > What distro is this for? My concern here is that hundreds of boards > > (literally) grow by a few hundred bytes to add in this bit of additional > > default logic. That's not a big problem if distributions are now going > > to be using SPI flash as where they're programming in their bootscript. > > But, who is doing that? Thanks! > > > I am not aware of any "distro" that puts a U-Boot script at offset 0 of > the SPI Flash. > > Traditionally, SPI Flash boot setups were always very hand crafted - > exactly the opposite of what distro boot is for. That said, I think > supporting SPI Flash boot for rk3399 is great! Albeit I would personally > only store U-Boot and the environment on SPI, not the target OS. > > Jagan, is putting a U-Boot script on the SPI Flash something you thought > of or something that the rk3399 reference board already does? If it's > the latter, maybe you could add it as a board custom boot function? Yes it would be later that points to. rk3399 has SPI flash layout and out of which one of offset(script_offset_f=0xffe000 from include/configs/rk3399_common.h) stored the programming script. Jagan.
On Thu, Jan 23, 2020 at 10:25:50PM +0530, Jagan Teki wrote: > On Mon, Jan 20, 2020 at 11:10 PM Alexander Graf <agraf@csgraf.de> wrote: > > > > > > On 20.01.20 18:22, Tom Rini wrote: > > > +A few people that may have insight to my question > > > > > > On Sat, Dec 21, 2019 at 01:24:31PM +0530, Jagan Teki wrote: > > > > > >> Add distro boot command support for SPI flash. > > >> > > >> This distro boot will read the boot script at specific > > >> location at the flash and start sourcing the same. > > >> > > >> The common macro like BOOTENV_SHARED_FLASH would help > > >> to extend the support for nand flash in future. > > >> > > >> Cc: Tom Rini <trini@konsulko.com> > > >> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com> > > > What distro is this for? My concern here is that hundreds of boards > > > (literally) grow by a few hundred bytes to add in this bit of additional > > > default logic. That's not a big problem if distributions are now going > > > to be using SPI flash as where they're programming in their bootscript. > > > But, who is doing that? Thanks! > > > > > > I am not aware of any "distro" that puts a U-Boot script at offset 0 of > > the SPI Flash. > > > > Traditionally, SPI Flash boot setups were always very hand crafted - > > exactly the opposite of what distro boot is for. That said, I think > > supporting SPI Flash boot for rk3399 is great! Albeit I would personally > > only store U-Boot and the environment on SPI, not the target OS. > > > > Jagan, is putting a U-Boot script on the SPI Flash something you thought > > of or something that the rk3399 reference board already does? If it's > > the latter, maybe you could add it as a board custom boot function? > > Yes it would be later that points to. rk3399 has SPI flash layout and > out of which one of offset(script_offset_f=0xffe000 from > include/configs/rk3399_common.h) stored the programming script. So I'm not sure why we're adding distro boot support to SPI flash. What is the reference platform storing there exactly? Thanks!
On Thu, Jan 23, 2020 at 10:33 PM Tom Rini <trini@konsulko.com> wrote: > > On Thu, Jan 23, 2020 at 10:25:50PM +0530, Jagan Teki wrote: > > On Mon, Jan 20, 2020 at 11:10 PM Alexander Graf <agraf@csgraf.de> wrote: > > > > > > > > > On 20.01.20 18:22, Tom Rini wrote: > > > > +A few people that may have insight to my question > > > > > > > > On Sat, Dec 21, 2019 at 01:24:31PM +0530, Jagan Teki wrote: > > > > > > > >> Add distro boot command support for SPI flash. > > > >> > > > >> This distro boot will read the boot script at specific > > > >> location at the flash and start sourcing the same. > > > >> > > > >> The common macro like BOOTENV_SHARED_FLASH would help > > > >> to extend the support for nand flash in future. > > > >> > > > >> Cc: Tom Rini <trini@konsulko.com> > > > >> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com> > > > > What distro is this for? My concern here is that hundreds of boards > > > > (literally) grow by a few hundred bytes to add in this bit of additional > > > > default logic. That's not a big problem if distributions are now going > > > > to be using SPI flash as where they're programming in their bootscript. > > > > But, who is doing that? Thanks! > > > > > > > > > I am not aware of any "distro" that puts a U-Boot script at offset 0 of > > > the SPI Flash. > > > > > > Traditionally, SPI Flash boot setups were always very hand crafted - > > > exactly the opposite of what distro boot is for. That said, I think > > > supporting SPI Flash boot for rk3399 is great! Albeit I would personally > > > only store U-Boot and the environment on SPI, not the target OS. > > > > > > Jagan, is putting a U-Boot script on the SPI Flash something you thought > > > of or something that the rk3399 reference board already does? If it's > > > the latter, maybe you could add it as a board custom boot function? > > > > Yes it would be later that points to. rk3399 has SPI flash layout and > > out of which one of offset(script_offset_f=0xffe000 from > > include/configs/rk3399_common.h) stored the programming script. > > So I'm not sure why we're adding distro boot support to SPI flash. What > is the reference platform storing there exactly? Thanks! I'm not sure I understand the question? we have rk3399 SBC's that boot from SPI and have feasibility to run distro boot using programming script store in flash offset like boot.scr does for MMC.
On Thu, Jan 23, 2020 at 10:41:15PM +0530, Jagan Teki wrote: > On Thu, Jan 23, 2020 at 10:33 PM Tom Rini <trini@konsulko.com> wrote: > > > > On Thu, Jan 23, 2020 at 10:25:50PM +0530, Jagan Teki wrote: > > > On Mon, Jan 20, 2020 at 11:10 PM Alexander Graf <agraf@csgraf.de> wrote: > > > > > > > > > > > > On 20.01.20 18:22, Tom Rini wrote: > > > > > +A few people that may have insight to my question > > > > > > > > > > On Sat, Dec 21, 2019 at 01:24:31PM +0530, Jagan Teki wrote: > > > > > > > > > >> Add distro boot command support for SPI flash. > > > > >> > > > > >> This distro boot will read the boot script at specific > > > > >> location at the flash and start sourcing the same. > > > > >> > > > > >> The common macro like BOOTENV_SHARED_FLASH would help > > > > >> to extend the support for nand flash in future. > > > > >> > > > > >> Cc: Tom Rini <trini@konsulko.com> > > > > >> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com> > > > > > What distro is this for? My concern here is that hundreds of boards > > > > > (literally) grow by a few hundred bytes to add in this bit of additional > > > > > default logic. That's not a big problem if distributions are now going > > > > > to be using SPI flash as where they're programming in their bootscript. > > > > > But, who is doing that? Thanks! > > > > > > > > > > > > I am not aware of any "distro" that puts a U-Boot script at offset 0 of > > > > the SPI Flash. > > > > > > > > Traditionally, SPI Flash boot setups were always very hand crafted - > > > > exactly the opposite of what distro boot is for. That said, I think > > > > supporting SPI Flash boot for rk3399 is great! Albeit I would personally > > > > only store U-Boot and the environment on SPI, not the target OS. > > > > > > > > Jagan, is putting a U-Boot script on the SPI Flash something you thought > > > > of or something that the rk3399 reference board already does? If it's > > > > the latter, maybe you could add it as a board custom boot function? > > > > > > Yes it would be later that points to. rk3399 has SPI flash layout and > > > out of which one of offset(script_offset_f=0xffe000 from > > > include/configs/rk3399_common.h) stored the programming script. > > > > So I'm not sure why we're adding distro boot support to SPI flash. What > > is the reference platform storing there exactly? Thanks! > > I'm not sure I understand the question? we have rk3399 SBC's that boot > from SPI and have feasibility to run distro boot using programming > script store in flash offset like boot.scr does for MMC. OK, and what distro(s) today are doing that? I'm not happy with this patch as it's growing hundreds (literally) of boards in size and I'd like to know what is leveraging this functionality today, or is going to be as soon as it's upstream and widely available. Thanks!
On Thu, Jan 23, 2020 at 10:45 PM Tom Rini <trini@konsulko.com> wrote: > > On Thu, Jan 23, 2020 at 10:41:15PM +0530, Jagan Teki wrote: > > On Thu, Jan 23, 2020 at 10:33 PM Tom Rini <trini@konsulko.com> wrote: > > > > > > On Thu, Jan 23, 2020 at 10:25:50PM +0530, Jagan Teki wrote: > > > > On Mon, Jan 20, 2020 at 11:10 PM Alexander Graf <agraf@csgraf.de> wrote: > > > > > > > > > > > > > > > On 20.01.20 18:22, Tom Rini wrote: > > > > > > +A few people that may have insight to my question > > > > > > > > > > > > On Sat, Dec 21, 2019 at 01:24:31PM +0530, Jagan Teki wrote: > > > > > > > > > > > >> Add distro boot command support for SPI flash. > > > > > >> > > > > > >> This distro boot will read the boot script at specific > > > > > >> location at the flash and start sourcing the same. > > > > > >> > > > > > >> The common macro like BOOTENV_SHARED_FLASH would help > > > > > >> to extend the support for nand flash in future. > > > > > >> > > > > > >> Cc: Tom Rini <trini@konsulko.com> > > > > > >> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com> > > > > > > What distro is this for? My concern here is that hundreds of boards > > > > > > (literally) grow by a few hundred bytes to add in this bit of additional > > > > > > default logic. That's not a big problem if distributions are now going > > > > > > to be using SPI flash as where they're programming in their bootscript. > > > > > > But, who is doing that? Thanks! > > > > > > > > > > > > > > > I am not aware of any "distro" that puts a U-Boot script at offset 0 of > > > > > the SPI Flash. > > > > > > > > > > Traditionally, SPI Flash boot setups were always very hand crafted - > > > > > exactly the opposite of what distro boot is for. That said, I think > > > > > supporting SPI Flash boot for rk3399 is great! Albeit I would personally > > > > > only store U-Boot and the environment on SPI, not the target OS. > > > > > > > > > > Jagan, is putting a U-Boot script on the SPI Flash something you thought > > > > > of or something that the rk3399 reference board already does? If it's > > > > > the latter, maybe you could add it as a board custom boot function? > > > > > > > > Yes it would be later that points to. rk3399 has SPI flash layout and > > > > out of which one of offset(script_offset_f=0xffe000 from > > > > include/configs/rk3399_common.h) stored the programming script. > > > > > > So I'm not sure why we're adding distro boot support to SPI flash. What > > > is the reference platform storing there exactly? Thanks! > > > > I'm not sure I understand the question? we have rk3399 SBC's that boot > > from SPI and have feasibility to run distro boot using programming > > script store in flash offset like boot.scr does for MMC. > > OK, and what distro(s) today are doing that? I'm not happy with this > patch as it's growing hundreds (literally) of boards in size and I'd > like to know what is leveraging this functionality today, or is going to > be as soon as it's upstream and widely available. Thanks! Not sure about the possibility more boards using this at this point, but I was initially created custom to rockchip and feel that it would be useful to rest if it's generic. May be will split into rockchip area if it's eating too much footprint. Jagan.
On Thu, Jan 23, 2020 at 10:59:17PM +0530, Jagan Teki wrote: > On Thu, Jan 23, 2020 at 10:45 PM Tom Rini <trini@konsulko.com> wrote: > > > > On Thu, Jan 23, 2020 at 10:41:15PM +0530, Jagan Teki wrote: > > > On Thu, Jan 23, 2020 at 10:33 PM Tom Rini <trini@konsulko.com> wrote: > > > > > > > > On Thu, Jan 23, 2020 at 10:25:50PM +0530, Jagan Teki wrote: > > > > > On Mon, Jan 20, 2020 at 11:10 PM Alexander Graf <agraf@csgraf.de> wrote: > > > > > > > > > > > > > > > > > > On 20.01.20 18:22, Tom Rini wrote: > > > > > > > +A few people that may have insight to my question > > > > > > > > > > > > > > On Sat, Dec 21, 2019 at 01:24:31PM +0530, Jagan Teki wrote: > > > > > > > > > > > > > >> Add distro boot command support for SPI flash. > > > > > > >> > > > > > > >> This distro boot will read the boot script at specific > > > > > > >> location at the flash and start sourcing the same. > > > > > > >> > > > > > > >> The common macro like BOOTENV_SHARED_FLASH would help > > > > > > >> to extend the support for nand flash in future. > > > > > > >> > > > > > > >> Cc: Tom Rini <trini@konsulko.com> > > > > > > >> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com> > > > > > > > What distro is this for? My concern here is that hundreds of boards > > > > > > > (literally) grow by a few hundred bytes to add in this bit of additional > > > > > > > default logic. That's not a big problem if distributions are now going > > > > > > > to be using SPI flash as where they're programming in their bootscript. > > > > > > > But, who is doing that? Thanks! > > > > > > > > > > > > > > > > > > I am not aware of any "distro" that puts a U-Boot script at offset 0 of > > > > > > the SPI Flash. > > > > > > > > > > > > Traditionally, SPI Flash boot setups were always very hand crafted - > > > > > > exactly the opposite of what distro boot is for. That said, I think > > > > > > supporting SPI Flash boot for rk3399 is great! Albeit I would personally > > > > > > only store U-Boot and the environment on SPI, not the target OS. > > > > > > > > > > > > Jagan, is putting a U-Boot script on the SPI Flash something you thought > > > > > > of or something that the rk3399 reference board already does? If it's > > > > > > the latter, maybe you could add it as a board custom boot function? > > > > > > > > > > Yes it would be later that points to. rk3399 has SPI flash layout and > > > > > out of which one of offset(script_offset_f=0xffe000 from > > > > > include/configs/rk3399_common.h) stored the programming script. > > > > > > > > So I'm not sure why we're adding distro boot support to SPI flash. What > > > > is the reference platform storing there exactly? Thanks! > > > > > > I'm not sure I understand the question? we have rk3399 SBC's that boot > > > from SPI and have feasibility to run distro boot using programming > > > script store in flash offset like boot.scr does for MMC. > > > > OK, and what distro(s) today are doing that? I'm not happy with this > > patch as it's growing hundreds (literally) of boards in size and I'd > > like to know what is leveraging this functionality today, or is going to > > be as soon as it's upstream and widely available. Thanks! > > Not sure about the possibility more boards using this at this point, > but I was initially created custom to rockchip and feel that it would > be useful to rest if it's generic. May be will split into rockchip > area if it's eating too much footprint. Yes, the "distro boot" functionality refers to what we need to allow boards to easily Just Work with standard off the shelf *nix distributions. Thanks!
diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h index fc0935fa21..d68b79e290 100644 --- a/include/config_distro_bootcmd.h +++ b/include/config_distro_bootcmd.h @@ -43,6 +43,22 @@ #define BOOTENV_DEV_NAME_BLKDEV(devtypeu, devtypel, instance) \ #devtypel #instance " " +#define BOOTENV_SHARED_SF_BODY(devtypel) \ + "if " #devtypel " probe ${devnum}; then " \ + "devtype=" #devtypel "; " \ + "run scan_flash_for_scripts; " \ + "fi\0" + +#define BOOTENV_SHARED_FLASH(devtypel) \ + #devtypel "_boot=" \ + BOOTENV_SHARED_SF_BODY(devtypel) + +#define BOOTENV_DEV_FLASH(devtypeu, devtypel, instance) \ + BOOTENV_DEV_BLKDEV(devtypeu, devtypel, instance) + +#define BOOTENV_DEV_NAME_FLASH(devtypeu, devtypel, instance) \ + BOOTENV_DEV_NAME_BLKDEV(devtypeu, devtypel, instance) + #ifdef CONFIG_SANDBOX #define BOOTENV_SHARED_HOST BOOTENV_SHARED_BLKDEV(host) #define BOOTENV_DEV_HOST BOOTENV_DEV_BLKDEV @@ -398,6 +414,18 @@ BOOT_TARGET_DEVICES_references_PXE_without_CONFIG_CMD_DHCP_or_PXE #endif +#if defined(CONFIG_CMD_SF) +#define BOOTENV_SHARED_SF BOOTENV_SHARED_FLASH(sf) +#define BOOTENV_DEV_SF BOOTENV_DEV_FLASH +#define BOOTENV_DEV_NAME_SF BOOTENV_DEV_NAME_FLASH +#else +#define BOOTENV_SHARED_SF +#define BOOTENV_DEV_SF \ + BOOT_TARGET_DEVICES_references_SF_without_CONFIG_CMD_SF +#define BOOTENV_DEV_NAME_SF \ + BOOT_TARGET_DEVICES_references_SF_without_CONFIG_CMD_SF +#endif + #define BOOTENV_DEV_NAME(devtypeu, devtypel, instance) \ BOOTENV_DEV_NAME_##devtypeu(devtypeu, devtypel, instance) #define BOOTENV_BOOT_TARGETS \ @@ -412,6 +440,7 @@ BOOTENV_SHARED_USB \ BOOTENV_SHARED_SATA \ BOOTENV_SHARED_SCSI \ + BOOTENV_SHARED_SF \ BOOTENV_SHARED_NVME \ BOOTENV_SHARED_IDE \ BOOTENV_SHARED_UBIFS \ @@ -436,6 +465,12 @@ "echo SCRIPT FAILED: continuing...; " \ "fi\0" \ \ + "scan_flash_for_scripts=" \ + "${devtype} read ${scriptaddr} " \ + "${script_offset_f} ${script_size_f}; " \ + "source ${scriptaddr}; " \ + "echo SCRIPT FAILED: continuing...\0" \ + \ "boot_a_script=" \ "load ${devtype} ${devnum}:${distro_bootpart} " \ "${scriptaddr} ${prefix}${script}; " \