Re: [PATCH v8 03/10] arm_ffa: introduce Arm FF-A low-level driver

On Wed, Jan 25, 2023 at 04:44:34PM +, Abdellatif El Khlifi wrote: [...] > Future SW features using SMC can be discovered by arm_smccc as well. > We can document this approach in U-Boot/Linux so future developments > will follow this approach. > OK as discussed in private, you must not need

Re: [PATCH v8 03/10] arm_ffa: introduce Arm FF-A low-level driver

On Wed, Jan 25, 2023 at 10:55:11AM +, Abdellatif El Khlifi wrote: > Hi Simon, Rob, Sudeep > > I'm tweaking my previous suggestion regarding the creation of a new > arm_smccc root node.. > > This node is the parent of all SW features using SMC calls like FF-A, PSCI, > optee, ... > > However, no

Re: [PATCH v8 03/10] arm_ffa: introduce Arm FF-A low-level driver

On Tue, Jan 24, 2023 at 03:56:19PM +, Abdellatif El Khlifi wrote: > > I'd like to suggest the creation of a root node called arm_smccc as shown > below. > Not sure if U-Boot already supports the existing binding of PSCI and OPTEE. > This node is the parent of all nodes using SMC calls like

Re: [PATCH v8 03/10] arm_ffa: introduce Arm FF-A low-level driver

On Tue, Jan 24, 2023 at 03:44:53PM -0700, Simon Glass wrote: > Hi Sudeep, > > On Tue, 24 Jan 2023 at 04:30, Sudeep Holla wrote: > > > > Hi Simon, > > [...] > > Not really. I think I have not conveyed the setup details properly. > > Let me try to e

Re: [PATCH v8 03/10] arm_ffa: introduce Arm FF-A low-level driver

Hi Simon, On Mon, Jan 23, 2023 at 09:32:19AM -0700, Simon Glass wrote: > Hi Sudeep, > > I'd like to see DT defined across firmware and OS, not just be a Linux > thing. Fair enough. > It is a better approach than having little fiefdoms everywhere > with their own config mechanisms. > Agreed.

Re: [PATCH v8 03/10] arm_ffa: introduce Arm FF-A low-level driver

On Thu, Jan 19, 2023 at 10:22:07AM -0700, Simon Glass wrote: > Hi Sudeep, > > On Thu, 19 Jan 2023 at 10:09, Sudeep Holla wrote: > > > > On Thu, Jan 19, 2023 at 11:57:44AM -0500, Tom Rini wrote: > > > > > > But it's also true that at run-time, within U-Boot,

Re: [PATCH v8 03/10] arm_ffa: introduce Arm FF-A low-level driver

Hi Simon, On Thu, Jan 19, 2023 at 11:04:16AM -0700, Simon Glass wrote: [...] > > Well we already have the code, right...? > Correct, that what we would like to see. > The entire device tree is optional. We could just use platform data or > even C function calls to set up devices. We could call

Re: [PATCH v8 03/10] arm_ffa: introduce Arm FF-A low-level driver

On Thu, Jan 19, 2023 at 12:11:34PM -0600, Rob Herring wrote: > On Thu, Jan 19, 2023 at 10:41 AM Simon Glass wrote: > > > > Can you add a DT node for the 'FF-A SW interfaces' and attach some > > sort of top-level driver to that? Perhaps simple-bus, or your own > > thing? You don't need to add

Re: [PATCH v8 03/10] arm_ffa: introduce Arm FF-A low-level driver

On Thu, Jan 19, 2023 at 11:57:44AM -0500, Tom Rini wrote: > > But it's also true that at run-time, within U-Boot, we can modify the > device tree we have, with live tree yes? So, the whole series in > question here can be done without modifying the base DT and getting in > to the further

Re: [PATCH v8 03/10] arm_ffa: introduce Arm FF-A low-level driver

On Thu, Jan 19, 2023 at 09:54:29AM -0700, Simon Glass wrote: > Hi Sudeep, > > On Thu, 19 Jan 2023 at 09:46, Sudeep Holla wrote: > > > > Thanks for the details. But IIRC this discussion is not about the FF-A bus > > and device(partitions) discovery, but

Re: [PATCH v8 03/10] arm_ffa: introduce Arm FF-A low-level driver

Hi Simon, (sorry we just crossed the emails) On Thu, Jan 19, 2023 at 09:41:12AM -0700, Simon Glass wrote: > > Can you add a DT node for the 'FF-A SW interfaces' and attach some > sort of top-level driver to that? Perhaps simple-bus, or your own > thing? You don't need to add compatible strings

Re: [PATCH v8 03/10] arm_ffa: introduce Arm FF-A low-level driver

Hi Abdellatif, On Thu, Jan 19, 2023 at 04:31:57PM +, Abdellatif El Khlifi wrote: > > Hi Simon, Tom, > > The FF-A transport is a SW bus and is not associated to any HW peripheral or > undiscoverable base address. > > There is only 1 way of discovering the FF-A bus and it's through the FF-A SW

Re: [PATCH v8 03/10] arm_ffa: introduce Arm FF-A low-level driver

On Wed, Jan 18, 2023 at 08:59:32AM -0500, Tom Rini wrote: > To be clear, if the position is that "this is what everyone else will > use, really" then yes, we'll follow this in U-Boot. Well, that's difficult question to provide an assertive answer TBH. I don't know all the projects using FF-A for

Re: [PATCH v8 03/10] arm_ffa: introduce Arm FF-A low-level driver

On Wed, Jan 18, 2023 at 12:49 PM Tom Rini wrote: > > I guess the problem comes down to, can we have one discovery method that > everyone shares, or do we have to let everyone invent a new discovery > method every time? No one needs to invent any discovery method every time if the firmware

Re: [PATCH 0/6] introduce Arm FF-A support

On Tue, Aug 02, 2022 at 08:22:19AM -0400, Tom Rini wrote: > On Mon, Aug 01, 2022 at 08:28:08PM +0100, Sudeep Holla wrote: > > On Mon, Aug 01, 2022 at 01:13:23PM -0600, Simon Glass wrote: > > > On Wed, 13 Apr 2022 at 10:46, Tom Rini wrote: > > > > > > > &g

Re: [PATCH 0/6] introduce Arm FF-A support

Hi Simon, On Mon, Aug 01, 2022 at 09:08:00PM -0600, Simon Glass wrote: > Hi Sudeep, > > I'm not sure either. In particular I'm not sure why it would be easier > to update whatever the FF-A software is than to update the DT, since > presumably they are both in the firmware. > No, that is not the

Re: [PATCH 0/6] introduce Arm FF-A support

On Mon, Aug 01, 2022 at 01:13:23PM -0600, Simon Glass wrote: > On Wed, 13 Apr 2022 at 10:46, Tom Rini wrote: > > > > How is it both discoverable and doesn't have a device tree node, in the > > kernel? > > Also, if it is discoverable, we can still use U-Boot to discover it > and then pass the info

Re: [PATCH] doc: develop: Add a note about importing code from other projects

ference. Thanks for the quick response in the form of patch. That is super fast and efficient . Acked-by: Sudeep Holla -- Regards, Sudeep

Re: [PATCH v3 1/4] arm64: smccc: add Xn registers support used by SMC calls

On Mon, Aug 01, 2022 at 06:20:50PM +0100, Abdellatif El Khlifi wrote: > use x0-x17 registers in the SMC32/SMC64 calls according to SMCCCv1.2 > > Signed-off-by: Sudeep Holla Please drop my signed-off as I didn't. I am seeing this patch on the list for the first time and AFAIK I haven

Re: [PATCH 0/6] introduce Arm FF-A support

On Wed, Apr 13, 2022 at 12:46:07PM -0400, Tom Rini wrote: > On Wed, Apr 13, 2022 at 03:20:23PM +0100, Abdellatif El Khlifi wrote: [...] > > Since we can not add an FFA node in the device tree, we will make FFA a > > discoverable bus. > > So, we will manually create the udevice, binding it to

Re: [PATCH v2 2/2] doc: add Arm Juno board documentation

On Mon, Dec 20, 2021 at 06:12:04PM +, Andre Przywara wrote: > The Juno Arm development board is an open, vendor-neutral, Armv8-A > development platform. > Add documentation that briefly outlines the hardware, and describes > building and installation of U-Boot. > Reviewed-b

Re: [PATCH v2 1/2] doc: Add documentation for the Arm VExpress64 board configs

On Mon, Dec 20, 2021 at 06:12:03PM +, Andre Przywara wrote: > From: Peter Hoyes > > Create a new documentation section for Arm Ltd boards with a sub-page > for the FVP VExpress64 system. > Reviewed-by: Sudeep Holla -- Regards, Sudeep

Re: [PATCH 1/2] doc: Add documentation for the Arm VExpress64 board configs

ndre Przywara Reviewed-by: Sudeep Holla -- Regards, Sudeep

Re: [PATCH 2/2] doc: add Arm Juno board documentation

On Tue, Dec 14, 2021 at 05:55:39PM +, Andre Przywara wrote: > The Juno Arm development board is an open, vendor-neutral, Armv8-A > development platform. > Add documentation that briefly outlines the hardware, and describes > building and installation of U-Boot. > > Signed-off-by: Andre

Re: [PATCH 3/4] clk: add clock driver for SCMI agents

On Tue, Aug 18, 2020 at 10:46:29AM +0200, Etienne Carriere wrote: > Hello Simon and all, > > On Sun, 26 Jul 2020 at 16:54, Simon Glass wrote: > > > > Hi Etienne, > > > > On Fri, 17 Jul 2020 at 09:43, Etienne Carriere > > wrote: > > > > > > This change introduces a clock driver for SCMI agent

Re: [U-Boot] [PATCH] Revert "vexpress64: fvp dram: add DRAM configuration"

On Tue, Aug 27, 2019 at 11:56:49AM +0100, Ryan Harkin wrote: > This reverts commit fc04b923541d984b1544056fd3bfa8129d4e5aac where the > FVP DRAM configuration was added. > Semi-hosting just works fine, so Acked-by: Sudeep Holla -- Regard

Re: [U-Boot] [PATCH] ARM: vexpress_*_defconfig: replace earlyprintk with earlycon

> > Cc: Ryan Harkin > > Cc: Liviu Dudau > > Cc: Linus Walleij > > Signed-off-by: Sudeep Holla > > --- > > configs/vexpress_aemv8a_dram_defconfig | 2 +- > > configs/vexpress_aemv8a_juno_defconfig | 2 +- > > configs/vexpress_aemv8a_semi_defcon

Re: [U-Boot] [PATCH] ARM: vexpress_*_defconfig: replace earlyprintk with earlycon

arm64 platforms. Replace it with earlycon > > > which works fine. > > > > > > Cc: Ryan Harkin > > > Cc: Liviu Dudau > > > Cc: Linus Walleij > > > Signed-off-by: Sudeep Holla > > > --- > > > configs/vexpress_aemv8a_dram_def

[U-Boot] [PATCH] ARM: vexpress_*_defconfig: replace earlyprintk with earlycon

earlyprintk no longer works on arm64 platforms. Replace it with earlycon which works fine. Cc: Ryan Harkin Cc: Liviu Dudau Cc: Linus Walleij Signed-off-by: Sudeep Holla --- configs/vexpress_aemv8a_dram_defconfig | 2 +- configs/vexpress_aemv8a_juno_defconfig | 2 +- configs

[U-Boot] [PATCH] vexpress/aemv8a: drop CONFIG_ARMV8_SWITCH_TO_EL1

To support KVM, we need to drop at EL2 and not EL1 before we boot Linux kernel. This causes issues on platform with VHE and secondaries booting at EL2 via TF-A PSCI CPU_ON call. Cc: Ryan Harkin Cc: Liviu Dudau Cc: Linus Walleij Cc: David Feng Signed-off-by: Sudeep Holla --- include/configs

Re: [U-Boot] [PATCH 4/4] ARM: dts: zynq: replace gpio-key, wakeup with wakeup-source property

On 16/12/16 13:30, Michal Simek wrote: > On 16.12.2016 14:23, Sudeep Holla wrote: >> >> >> On 16/12/16 12:38, Michal Simek wrote: >>> From: Sudeep Holla <sudeep.ho...@arm.com> >>> >>> Though the keyboard driver for GPIO buttons(gpio-keys) w

Re: [U-Boot] [PATCH 4/4] ARM: dts: zynq: replace gpio-key, wakeup with wakeup-source property

On 16/12/16 12:38, Michal Simek wrote: > From: Sudeep Holla <sudeep.ho...@arm.com> > > Though the keyboard driver for GPIO buttons(gpio-keys) will continue to > check for/support the legacy "gpio-key,wakeup" boolean property to > enable gpio buttons as wakeup sou

Re: [U-Boot] [PATCH] vexpress64: Juno: Change PCI buss addresses for IO to start from zero.

On 22/11/16 15:08, Tom Rini wrote: On Tue, Nov 22, 2016 at 12:08:49PM +, Liviu Dudau wrote: On Tue, Nov 22, 2016 at 11:29:20AM +, Sudeep Holla wrote: Hi Liviu, On Tue, Nov 22, 2016 at 11:19 AM, Liviu Dudau <liviu.du...@foss.arm.com> wrote: Juno uses a 1:1 mapping betwe

Re: [U-Boot] [PATCH] vexpress64: Juno: Change PCI buss addresses for IO to start from zero.

Hi Liviu, On Tue, Nov 22, 2016 at 11:19 AM, Liviu Dudau wrote: > Juno uses a 1:1 mapping between CPU and PCI addresses for IO. First, > that will trip devices that cannot use more than 16 bits of addresses > for IO, second it is un-necessary as the system can handle

Re: [U-Boot] [PATCH v2] vexpress: disable cci ace slave ports when booting in non-sec/hyp mode

On 26/09/16 14:19, Jon Medhurst (Tixy) wrote: On Mon, 2016-09-26 at 13:38 +0100, Sudeep Holla wrote: On 26/09/16 13:30, Jon Medhurst (Tixy) wrote: On Fri, 2016-09-23 at 17:38 +0100, Sudeep Holla wrote: Commit f225d39d3093 ("vexpress: Check TC2 firmware support before defaulting to n

Re: [U-Boot] [PATCH v2] vexpress: disable cci ace slave ports when booting in non-sec/hyp mode

On 26/09/16 13:30, Jon Medhurst (Tixy) wrote: On Fri, 2016-09-23 at 17:38 +0100, Sudeep Holla wrote: Commit f225d39d3093 ("vexpress: Check TC2 firmware support before defaulting to nonsec booting") added support to check if the firmware on TC2 is configured appropriately befo

Re: [U-Boot] [PATCH v2] vexpress: disable cci ace slave ports when booting in non-sec/hyp mode

On 26/09/16 12:35, Sudeep Holla wrote: On 26/09/16 12:30, Jon Medhurst (Tixy) wrote: On Fri, 2016-09-23 at 17:38 +0100, Sudeep Holla wrote: Commit f225d39d3093 ("vexpress: Check TC2 firmware support before defaulting to nonsec booting") added support to check if the firmw

Re: [U-Boot] [PATCH v2] vexpress: disable cci ace slave ports when booting in non-sec/hyp mode

On 26/09/16 12:30, Jon Medhurst (Tixy) wrote: On Fri, 2016-09-23 at 17:38 +0100, Sudeep Holla wrote: Commit f225d39d3093 ("vexpress: Check TC2 firmware support before defaulting to nonsec booting") added support to check if the firmware on TC2 is configured appropriately befo

[U-Boot] [PATCH] vexpress: disable cci ace slave ports when booting in non-sec/hyp mode

e firmware and can't be done in non-secure/hyp mode. In order to ensure that, this patch disables the cci slave port inteface so that it is not accessed at all. Cc: Jon Medhurst <t...@linaro.org> Signed-off-by: Sudeep Holla <sudeep.ho...@arm.com> --- board/armltd/vexpre

Re: [U-Boot] [PATCH] vexpress: disable cci ace slave ports when booting in non-sec/hyp mode

On 23/09/16 17:03, Jon Medhurst (Tixy) wrote: On Fri, 2016-09-23 at 16:10 +0100, Sudeep Holla wrote: +#ifdef CONFIG_OF_BOARD_SETUP +int ft_board_setup(void *fdt, bd_t *bd) +{ + int offset, tmp, len; + const struct fdt_property *prop; + const char *cci_compatible = "ar

[U-Boot] [PATCH v2] vexpress: disable cci ace slave ports when booting in non-sec/hyp mode

e firmware and can't be done in non-secure/hyp mode. In order to ensure that, this patch disables the cci slave port inteface so that it is not accessed at all. Cc: Jon Medhurst <t...@linaro.org> Acked-by: Marc Zyngier <marc.zyng...@arm.com> Signed-off-by: Sudeep Holla <sudeep.ho...@a

[U-Boot] [PATCH] cmd_fdt: save fdtaddr in hex format

at erroneous address generating fault if the address is out of memory. This patch changes back the format to hex while saving the fdtaddr as it was done before. Signed-off-by: Sudeep Holla sudeep.ho...@arm.com Cc: Linus Walleij linus.wall...@linaro.org Cc: Tom Rini tr...@konsulko.com Cc: Simon Glass s

Re: [U-Boot] [PATCH] cmd_fdt: save fdtaddr in hex format

Hi Simon, On 04/07/15 00:06, Simon Glass wrote: Hi Sudeep, On 3 July 2015 at 11:29, Sudeep Holla sudeep.ho...@arm.com wrote: Commit 90fbee3e4051 (cmd_fdt: Actually fix fdt command in sandbox) changed the format(from hex address to unsigned long) in which fdtaddr is saved . However do_fdt

[U-Boot] [PATCH] cmd_fdt: save fdtaddr in hex format

Commit 90fbee3e4051 (cmd_fdt: Actually fix fdt command in sandbox) changed the format(from hex address to unsigned long) in which fdtaddr is saved . However do_fdt continues reads the fdtaddr assuming it to be in hex format. This may lead to fdt being either loaded or attempted to load at

Re: [U-Boot] Booting armv8 kernel on uboot

On Wed, Jun 4, 2014 at 5:31 AM, Vishal Bhoj vishal.b...@linaro.org wrote: Hi, Thanks for the help. I am able to boot the kernel on foundation models but unable to boot the kernel on the FVP base models. The model itself seem to hang while booting the kernel. Here is the log: