On Fri, 24 Nov 2023 08:22:27 +0100
Ahmad Fatoum wrote:
Hi Ahmad!
> On 24.11.23 07:57, Ahmad Fatoum wrote:
> > Hi Antony,
> >
> > On 06.10.23 12:24, Ahmad Fatoum wrote:
> >> Hello Antony,
> >>
> >> On 30.09.23 11:17, Antony Pavlov wrote:
> >>> Hi Ahmad!
> >>>
> >>> barebox browser demo
Hi guys,
Is there a formal way to pass user compilation flags into Barebox build?
I couldn't find one so I just patched the main Makefile
diff --git a/Makefile b/Makefile
index 471bbc2679..febc94b7f3 100644
--- a/Makefile
+++ b/Makefile
@@ -443,7 +443,7 @@ KBUILD_CPPFLAGS:= -D__KERNEL__
We enter EL2 with MMU disabled even when it was enabled in EL3. Enable
MMU in EL2 again.
Signed-off-by: Sascha Hauer
---
arch/arm/mach-layerscape/ppa.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/mach-layerscape/ppa.c b/arch/arm/mach-layerscape/ppa.c
index
The reset and clock control peripheral of the STM32MP13 is with
publicly available firmware exclusively handled by the secure world and
normal world needs to employ SCMI to interact with OP-TEE to toggle clocks
for it. Import the Linux driver to facilitate this.
Signed-off-by: Ahmad Fatoum
---
clk_hw_reparent does a bit of work in Linux to update the cached clock
tree, but we have no cached clock tree in barebox, so just implement it
as empty stub.
Signed-off-by: Ahmad Fatoum
---
include/linux/clk.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/include/linux/clk.h
This is the inverse operation to clk_get_parent_index and is already
implemented inline in clk_get_parent. Factor that code out for use by
the incoming STM32MP13 clock driver.
Signed-off-by: Ahmad Fatoum
---
drivers/clk/clk.c | 25 +
include/linux/clk.h | 1 +
2 files
Now that we have proper clock controller support, let's configure the
board to have an environment on SD-Card, a barebox update handler for
the SD-Card and enable deep probe as well.
Signed-off-by: Ahmad Fatoum
---
arch/arm/boards/stm32mp13xx-dk/Makefile | 1 +
Legacy STM32 images were deprecated for STM32MP15 in TF-A and are no
longer supported in recent versions. For STM32MP13, FIP was the only
format supported since the beginning, so drop the unused entry point.
barebox chainloading for development can be done by booting the
The Linux driver for the STM32 ADC has only minor differences to the
STM32MP15 driver. Add these changes to barebox, even if untested.
Signed-off-by: Ahmad Fatoum
---
drivers/aiodev/stm32-adc.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/aiodev/stm32-adc.c
The pin controller on the STM32MP13 is identical to the STM32MP15.
Only the compatible is missing, so add it.
Signed-off-by: Ahmad Fatoum
---
drivers/pinctrl/pinctrl-stm32.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/pinctrl/pinctrl-stm32.c b/drivers/pinctrl/pinctrl-stm32.c
On Fri, Nov 24, 2023 at 09:01:28AM +0300, Antony Pavlov wrote:
> Antony Pavlov (2):
> virtio: ring: fix erroneous behavior on MIPS
> MIPS: qemu-malta*_defconfig: enable virtio network driver
Applied, thanks
Sascha
>
> arch/mips/configs/qemu-malta64el_defconfig | 1 +
>
While OP-TEE on STM32MP15 still implements the old SMC based API
to access the OTP, on STM32MP13, communication with the pseudo TA
is mandatory. Therefore add a driver that probes for OP-TEE and
talks to it to read and write the OTP.
Signed-off-by: Ahmad Fatoum
---
drivers/nvmem/Kconfig
STM32MP15 in trusted mode and STM32MP13 by default use OP-TEE as secure
monitor and some resets, clocks and voltage regulators are off-limits
to the normal world.
This series syncs barebox SCMI support with v6.6 and adds OP-TEE as
transport alongside SMCCC. This series has been tested on:
-
Devices with SCMI are booted by the ARM Trusted Firmware-A out of a FIP
bundle. The FIP bundle contains barebox-stm32mp-generic-bl33.img along
with a device tree.
Unlike EV1 and DK1/2, there is no SCMI-enabled upstream device tree for
the MC-1, so add one to barebox until that's rectified.
Devices with SCMI are booted by the ARM Trusted Firmware-A out of a FIP
bundle. The FIP bundle contains barebox-stm32mp-generic-bl33.img along
with a device tree. Let's build SCMI enabled device trees as well for
the EV1, which we already support in non-SCMI mode.
Signed-off-by: Ahmad Fatoum
---
Devices with SCMI are booted by the ARM Trusted Firmware-A out of a FIP
bundle. The FIP bundle contains barebox-stm32mp-generic-bl33.img along
with a device tree. Let's build SCMI enabled device trees as well for
the DK1 and DK2, which we already support in non-SCMI mode.
Signed-off-by: Ahmad
Upstream device trees use OP-TEE shared memory for SCMI, but upstream
OP-TEE also supports a compatibility mode to service SCMI over the
a sillicon provider secure monitor call, like what TF-A implements.
This can be enabled via including the device tree added here
and configuring OP-TEE
We don't preclude multiple devices pointing at the same device tree
node. It would be useful information for the user to indicate when
that's the case, so extend devinfo to show the information.
Signed-off-by: Ahmad Fatoum
---
commands/devinfo.c | 13 +++--
1 file changed, 11
From: Marc Kleine-Budde
So far, barebox support for OP-TEE was restricted to loading it either
early in PBL or via bootm and to not step over it when allocating
memory. This was guarded behind CONFIG_HAVE_OPTEE.
This commit imports from Linux the driver behind CONFIG_OPTEE, which
brings actual
of_device_ensure_probed() already returns error codes, e.g. when
of_device_create_on_demand attempts recreating a device with the same name.
In some error cases though that shouldn't happen in normal operation,
of_device_create_on_demand() returns NULL, which triggers a panic.
During development,
of_device_create_on_demand won't create a new device if the device tree
node already has a device associated. What it will do however, is to
create devices for all parent nodes in the device tree if they don't
already exist. This is unnecessary and clutters the device list
with nodes that won't
So far, barebox interaction by OP-TEE was limited to loading it and
maybe passing along its device tree fixup. In some scenarios, there
is a lot more that could need to be done however:
- Access to eMMC RPMB memory
- Access to keys stored in OP-TEE, e.g. in Trusted Keys TA or
in fTPM
-
From: Marc Kleine-Budde
Linux code imported in a follow-up commit will include user-facing ioctl
API that makes heavy use of the user accessors define in uaccess.h.
Instead of rewriting all this, let's just import the Linux header with
the default CONFIG_UACCESS_MEMCPY implementation meant for
Device nodes have a pointer to the device that was instantiated for it.
In some cases, we have both a platform device and a virtual device as
child instantiated from it with both pointing at the same device node.
So far, when unregistering the virtual device, we would clear the device
member,
From: Marc Kleine-Budde
Userspace accesses OP-TEE via ioctls and mmaps of the /dev/tee0
device. Replicating this in barebox is useful for verifying proper
operation of CONFIG_OPTEE by hacking libteeclient + optee_tests to
run under barebox.
Signed-off-by: Ahmad Fatoum
---
This driver provides support for OP-TEE based Random Number
Generator on ARM SoCs where hardware entropy sources are not
accessible to barebox running in the normal world.
It also makes for an easy target to test matching drivers with
devices via UUID and using the device enumeration pseudo TA.
The stm32mp1 clock driver is only used on the STM32MP15 and won't be
reused for the STM32MP13, so let's make it dependent on ARCH_STM32MP157
instead of CONFIG_ARCH_STM32MP.
Signed-off-by: Ahmad Fatoum
---
drivers/clk/Kconfig | 5 +
drivers/clk/Makefile | 2 +-
2 files changed, 6
clk_ops::set_parent passes the parent as an index, so clk_set_parent
needs to determine the index. Linux provides this information via
clk_hw_get_parent_index and some drivers depend on this, so factor out
the code in question in barebox as well.
Signed-off-by: Ahmad Fatoum
---
For cases where all clock parents are internal to the clock controller,
parent_hws allows specifying direct pointers to the clk_hw structures
instead of globally unique names. Add support for this to barebox to be
used by the incoming STM32MP13 clock driver.
Signed-off-by: Ahmad Fatoum
---
Linux now differentiates bween for consumers and
for providers. We have been putting
everything into , but for new API imported from Linux
that's only applicable to clock provider drivers, let's add a
header and add them there.
Signed-off-by: Ahmad Fatoum
---
include/linux/clk-provider.h |
We already support CLK_DIVIDER_ONE_BASED and incoming STM32MP13 clock
support can have clock dividers evaluate to zero. Add support for
CLK_DIVIDER_ALLOW_ZERO analogously to Linux.
Signed-off-by: Ahmad Fatoum
---
drivers/clk/clk-divider.c | 6 ++
include/linux/clk.h | 1 +
2 files
We only had rudimentary STM32MP13 support, because proper control of the
clocks and resets required communicating with OP-TEE as the RCC
peripheral was restricted to the secure world on that SoC.
Back when STM32MP13 support was added, this limitation was worked around
by defining placeholder
These functions will be used in the incoming STM32MP13 clock driver
support.
Signed-off-by: Ahmad Fatoum
---
drivers/clk/clk-divider.c| 35 ++-
include/linux/clk-provider.h | 21 +
2 files changed, 55 insertions(+), 1 deletion(-)
diff
33 matches
Mail list logo
