All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tom Rini <trini@konsulko.com>
To: Conor Dooley <conor.dooley@microchip.com>,
	Simon Glass <sjg@chromium.org>,
	Ilias Apalodimas <ilias.apalodimas@linaro.org>
Cc: u-boot@lists.denx.de, conor@kernel.org,
	Ivan Griffin <ivan.griffin@microchip.com>,
	Padmarao Begari <padmarao.begari@microchip.com>,
	Cyril Jean <cyril.jean@microchip.com>
Subject: Re: [PATCH v1] board: mpfs_icicle: implement board_fdt_blob_setup()
Date: Tue, 25 Jun 2024 08:34:21 -0600	[thread overview]
Message-ID: <20240625143421.GR38804@bill-the-cat> (raw)
In-Reply-To: <20240625090806.1787287-2-conor.dooley@microchip.com>

[-- Attachment #1: Type: text/plain, Size: 3341 bytes --]

On Tue, Jun 25, 2024 at 10:08:06AM +0100, Conor Dooley wrote:

> The firmware on the Icicle is capable of providing a devicetree in a1 to
> U-Boot, but until now the devicetree has been packaged in a "payload" [1]
> alongside U-Boot (or other bootloaders/RTOSes) and appended to the image.
> The address of this appended devicetree is placed in a1 by the firmware.
> This meant that the mechanism used by OF_SEPARATE to locate the
> devicetree at the end of the image would pick up the one provided by the
> firmware when u-boot-nodtb.bin was in the payload and U-Boot's devicetree
> when u-boot.bin was.
> 
> The firmware is now going to be capable of providing a minimal devicetree
> (quite cut down due to severe space constraints), but this devicetree is
> linked into the firmware that runs out of the L2 rather than at the end
> of the U-Boot image. Implement board_fdt_blob_setup() so that this
> devicetree can be optionally used, and the devicetree provided in the
> "payload" can be used without relying on "happening" to implement the
> same strategy as OF_SEPARATE expects in combination with
> u-boot-nodtb.bin. Unlike other RISC-V boards, the firmware provided
> devicetree is only used when OF_BOARD is set, so that the almost
> certainly more complete devicetree in U-Boot will be used unless
> explicitly requested otherwise.
> 
> Link: https://github.com/polarfire-soc/hart-software-services/blob/master/tools/hss-payload-generator/README.md [1]
> Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
> ---
> CC: Ivan Griffin <ivan.griffin@microchip.com>
> CC: Padmarao Begari <padmarao.begari@microchip.com>
> CC: Cyril Jean <cyril.jean@microchip.com>
> CC: Tom Rini <trini@konsulko.com>
> CC: Conor Dooley <conor.dooley@microchip.com>
> CC: u-boot@lists.denx.de
> ---
>  board/microchip/mpfs_icicle/mpfs_icicle.c | 19 +++++++++++++++++++
>  1 file changed, 19 insertions(+)
> 
> diff --git a/board/microchip/mpfs_icicle/mpfs_icicle.c b/board/microchip/mpfs_icicle/mpfs_icicle.c
> index 4d7d843dfa3..2c1f7175f0e 100644
> --- a/board/microchip/mpfs_icicle/mpfs_icicle.c
> +++ b/board/microchip/mpfs_icicle/mpfs_icicle.c
> @@ -9,6 +9,7 @@
>  #include <init.h>
>  #include <asm/global_data.h>
>  #include <asm/io.h>
> +#include <asm/sections.h>
>  
>  DECLARE_GLOBAL_DATA_PTR;
>  
> @@ -50,6 +51,24 @@ static void read_device_serial_number(u8 *response, u8 response_size)
>  		response_buf[idx] = readb(MPFS_SYS_SERVICE_MAILBOX + idx);
>  }
>  
> +void *board_fdt_blob_setup(int *err)
> +{
> +	*err = 0;
> +	/*
> +	 * The devicetree provided by the previous stage is very minimal due to
> +	 * severe space constraints. The firmware performs no fixups etc.
> +	 * U-Boot, if providing a devicetree, almost certainly has a better
> +	 * more complete one than the firmware so that provided by the firmware
> +	 * is ignored for OF_SEPARATE.
> +	 */
> +	if (IS_ENABLED(CONFIG_OF_BOARD)) {
> +		if (gd->arch.firmware_fdt_addr)
> +			return (ulong *)(uintptr_t)gd->arch.firmware_fdt_addr;
> +	}
> +
> +	return (ulong *)_end;
> +}
> +
>  int board_init(void)
>  {
>  	/* For now nothing to do here. */

I'm adding in Simon and Ilias as this touches on one of those frequent
topics about how device trees can/should be passed along to us.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

  reply	other threads:[~2024-06-25 14:34 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-25  9:08 [PATCH v1] board: mpfs_icicle: implement board_fdt_blob_setup() Conor Dooley
2024-06-25 14:34 ` Tom Rini [this message]
2024-06-27  8:36   ` Simon Glass
2024-06-27  9:38     ` Conor Dooley
2024-06-27 10:50       ` Simon Glass
2024-06-27 20:27         ` Conor Dooley
2024-06-28  5:53           ` Ilias Apalodimas
2024-06-28  6:34             ` Conor Dooley
2024-06-28  6:22           ` Simon Glass
2024-06-28  6:29             ` Conor Dooley
2024-07-03 13:42 ` Conor Dooley

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240625143421.GR38804@bill-the-cat \
    --to=trini@konsulko.com \
    --cc=conor.dooley@microchip.com \
    --cc=conor@kernel.org \
    --cc=cyril.jean@microchip.com \
    --cc=ilias.apalodimas@linaro.org \
    --cc=ivan.griffin@microchip.com \
    --cc=padmarao.begari@microchip.com \
    --cc=sjg@chromium.org \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.