* Porting barebox to a new SoC
@ 2023-05-28 13:04 Lior Weintraub
2023-05-28 15:35 ` Ahmad Fatoum
0 siblings, 1 reply; 40+ messages in thread
From: Lior Weintraub @ 2023-05-28 13:04 UTC (permalink / raw)
To: barebox
Hi,
I tried to follow the porting guide on https://www.barebox.org/doc/latest/devel/porting.html# but couldn't follow the instructions.
I would like to port barebox to a new SoC (which is not a derivative of any known SoC).
It has the following:
* Single Cortex A53
* SRAM (4MB) located on address 0xC000000000
The below patch shows my initial test to try and have a starting point.
I am setting env variables:
export ARCH=arm64
export CROSS_COMPILE=/home/pliops/workspace/ARM/arm-gnu-toolchain/bin/aarch64-none-elf-
Then I build with:
make spider_defconfig && make
This gives an error:
aarch64-none-elf-gcc: error: unrecognized argument in option '-mabi=apcs-gnu'
aarch64-none-elf-gcc: note: valid arguments to '-mabi=' are: ilp32 lp64
aarch64-none-elf-gcc: error: unrecognized command-line option '-msoft-float'
aarch64-none-elf-gcc: error: unrecognized command-line option '-mno-unaligned-access'
/home/pliops/workspace/simplest-linux-demo/barebox/scripts/Makefile.build:140: recipe for target 'scripts/mod/empty.o' failed
make[2]: *** [scripts/mod/empty.o] Error 1
Not sure why the compiler flags get -mabi=apcs-gnu when I explicitly set CONFIG_CPU_V8 and the arch/arm/Makefile has:
ifeq ($(CONFIG_CPU_V8), y)
CFLAGS_ABI :=-mabi=lp64
The changes I did:
>From 848b5f9b18bb1bb96d197cbc1b368ee0a729d581 Mon Sep 17 00:00:00 2001
From: Lior Weintraub <liorw@pliops.com>
Date: Sun, 28 May 2023 15:51:44 +0300
Subject: [PATCH 1/1] Initial Pliops Spider board
---
arch/arm/boards/pliops/spider/Makefile | 4 ++++
arch/arm/boards/pliops/spider/board.c | 26 ++++++++++++++++++++++
arch/arm/boards/pliops/spider/lowlevel.c | 28 ++++++++++++++++++++++++
arch/arm/configs/spider_defconfig | 3 +++
4 files changed, 61 insertions(+)
create mode 100644 arch/arm/boards/pliops/spider/Makefile
create mode 100644 arch/arm/boards/pliops/spider/board.c
create mode 100644 arch/arm/boards/pliops/spider/lowlevel.c
create mode 100644 arch/arm/configs/spider_defconfig
diff --git a/arch/arm/boards/pliops/spider/Makefile b/arch/arm/boards/pliops/spider/Makefile
new file mode 100644
index 0000000000..da63d2625f
--- /dev/null
+++ b/arch/arm/boards/pliops/spider/Makefile
@@ -0,0 +1,4 @@
+# SPDX-License-Identifier: GPL-2.0-only
+
+obj-y += board.o
+lwl-y += lowlevel.o
diff --git a/arch/arm/boards/pliops/spider/board.c b/arch/arm/boards/pliops/spider/board.c
new file mode 100644
index 0000000000..17cdd5e2b9
--- /dev/null
+++ b/arch/arm/boards/pliops/spider/board.c
@@ -0,0 +1,26 @@
+#include <bbu.h>
+#include <boot.h>
+#include <bootm.h>
+#include <common.h>
+#include <deep-probe.h>
+#include <environment.h>
+#include <fcntl.h>
+#include <globalvar.h>
+
+static int spider_board_probe(struct device *dev)
+{
+ /* Do some board-specific setup */
+ return 0;
+}
+
+static const struct of_device_id spider_board_of_match[] = {
+ { .compatible = "spider,spider-board" },
+ { /* sentinel */ },
+};
+
+static struct driver spider_board_driver = {
+ .name = "board-spider",
+ .probe = spider_board_probe,
+ .of_compatible = spider_board_of_match,
+};
+device_platform_driver(spider_board_driver);
\ No newline at end of file
diff --git a/arch/arm/boards/pliops/spider/lowlevel.c b/arch/arm/boards/pliops/spider/lowlevel.c
new file mode 100644
index 0000000000..f3d5a27647
--- /dev/null
+++ b/arch/arm/boards/pliops/spider/lowlevel.c
@@ -0,0 +1,28 @@
+#include <common.h>
+#include <asm/barebox-arm.h>
+
+#define BASE_ADDR (0xD000307000)
+#define GPRAM_ADDR (0xC000000000)
+#define MY_STACK_TOP (0xC000000000 + SZ_2M) // Set the stack 2MB from GPRAM start (excatly in the middle)
+static inline void spider_serial_putc(void *base, int c)
+{
+// if (!(readl(base + UCR1) & UCR1_UARTEN))
+// return;
+//
+// while (!(readl(base + USR2) & USR2_TXDC));
+//
+// writel(c, base + URTX0);
+}
+
+ENTRY_FUNCTION_WITHSTACK(start_spider_board, MY_STACK_TOP, r0, r1, r2)
+{
+ extern char __dtb_spider_board_start[];
+ void *fdt;
+
+ relocate_to_current_adr();
+ setup_c();
+
+ pbl_set_putc(spider_serial_putc, (void *)BASE_ADDR);
+
+ barebox_arm_entry(GPRAM_ADDR, SZ_2M, __dtb_spider_board_start);
+}
diff --git a/arch/arm/configs/spider_defconfig b/arch/arm/configs/spider_defconfig
new file mode 100644
index 0000000000..b4c4a32de0
--- /dev/null
+++ b/arch/arm/configs/spider_defconfig
@@ -0,0 +1,3 @@
+CONFIG_TEXT_BASE=0x4000000000
+CONFIG_64BIT=y
+CONFIG_CPU_V8=y
--
2.40.0
Appreciate your kind advise,
Cheers,
Lior.
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Porting barebox to a new SoC
2023-05-28 13:04 Porting barebox to a new SoC Lior Weintraub
@ 2023-05-28 15:35 ` Ahmad Fatoum
2023-05-28 15:37 ` [PATCH v2] " Ahmad Fatoum
0 siblings, 1 reply; 40+ messages in thread
From: Ahmad Fatoum @ 2023-05-28 15:35 UTC (permalink / raw)
To: Lior Weintraub, barebox
Hello Lior,
On 28.05.23 15:04, Lior Weintraub wrote:
> Hi,
>
> I tried to follow the porting guide on https://www.barebox.org/doc/latest/devel/porting.html# but couldn't follow the instructions.
> I would like to port barebox to a new SoC (which is not a derivative of any known SoC).
> It has the following:
> * Single Cortex A53
> * SRAM (4MB) located on address 0xC000000000
Nice, that's plenty. But do you have DRAM as well for barebox to extract
itself into and for Linux to start from? If 4M is indeed all you got,
you will need to tweak barebox a bit.
> The below patch shows my initial test to try and have a starting point.
> I am setting env variables:
> export ARCH=arm64
> export CROSS_COMPILE=/home/pliops/workspace/ARM/arm-gnu-toolchain/bin/aarch64-none-elf-
Note that barebox is normally built by a Linux toolchain, e.g. aarch64-linux-gnu- running
in freestanding mode. This doesn't seem to be your issue though, but just something to
keep in mind.
> Then I build with:
> make spider_defconfig && make
>
> This gives an error:
> aarch64-none-elf-gcc: error: unrecognized argument in option '-mabi=apcs-gnu'
> aarch64-none-elf-gcc: note: valid arguments to '-mabi=' are: ilp32 lp64
> aarch64-none-elf-gcc: error: unrecognized command-line option '-msoft-float'
> aarch64-none-elf-gcc: error: unrecognized command-line option '-mno-unaligned-access'
> /home/pliops/workspace/simplest-linux-demo/barebox/scripts/Makefile.build:140: recipe for target 'scripts/mod/empty.o' failed
> make[2]: *** [scripts/mod/empty.o] Error 1
>
> Not sure why the compiler flags get -mabi=apcs-gnu when I explicitly set CONFIG_CPU_V8 and the arch/arm/Makefile has:
> ifeq ($(CONFIG_CPU_V8), y)
> CFLAGS_ABI :=-mabi=lp64
CONFIG_CPU_V8 doesn't have a prompt. That means it's a "hidden" symbol that
can only be selected by other config options. Without CONFIG_CPU_V8, barebox'
build system assumes you are building for 32-bit. Note that ARCH=arm64 and
ARCH=arm are the same architecture in barebox (arch/arm). The boards you
select is what defines what compiler options will be used.
If you did savedefconfig, the resulting defconfig should have shown you
that CONFIG_CPU_V8 is getting lost.
> The changes I did:
I inserted some comments below and will reply with a revised version
that adds sine if the needed boilerplate.
> From 848b5f9b18bb1bb96d197cbc1b368ee0a729d581 Mon Sep 17 00:00:00 2001
> From: Lior Weintraub <liorw@pliops.com>
> Date: Sun, 28 May 2023 15:51:44 +0300
> Subject: [PATCH 1/1] Initial Pliops Spider board
>
> ---
> arch/arm/boards/pliops/spider/Makefile | 4 ++++
> arch/arm/boards/pliops/spider/board.c | 26 ++++++++++++++++++++++
> arch/arm/boards/pliops/spider/lowlevel.c | 28 ++++++++++++++++++++++++
> arch/arm/configs/spider_defconfig | 3 +++
> 4 files changed, 61 insertions(+)
> create mode 100644 arch/arm/boards/pliops/spider/Makefile
> create mode 100644 arch/arm/boards/pliops/spider/board.c
> create mode 100644 arch/arm/boards/pliops/spider/lowlevel.c
> create mode 100644 arch/arm/configs/spider_defconfig
>
> diff --git a/arch/arm/boards/pliops/spider/Makefile b/arch/arm/boards/pliops/spider/Makefile
> new file mode 100644
> index 0000000000..da63d2625f
> --- /dev/null
> +++ b/arch/arm/boards/pliops/spider/Makefile
> @@ -0,0 +1,4 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +
> +obj-y += board.o
> +lwl-y += lowlevel.o
> diff --git a/arch/arm/boards/pliops/spider/board.c b/arch/arm/boards/pliops/spider/board.c
> new file mode 100644
> index 0000000000..17cdd5e2b9
> --- /dev/null
> +++ b/arch/arm/boards/pliops/spider/board.c
> @@ -0,0 +1,26 @@
> +#include <bbu.h>
> +#include <boot.h>
> +#include <bootm.h>
> +#include <common.h>
> +#include <deep-probe.h>
> +#include <environment.h>
> +#include <fcntl.h>
> +#include <globalvar.h>
> +
> +static int spider_board_probe(struct device *dev)
> +{
> + /* Do some board-specific setup */
> + return 0;
> +}
> +
> +static const struct of_device_id spider_board_of_match[] = {
> + { .compatible = "spider,spider-board" },
The first part before the comma is the vendor, so you will want
something like pliops,spider-evk (board is quite generic, evk = evaluation kit?)
> + { /* sentinel */ },
> +};
> +
> +static struct driver spider_board_driver = {
> + .name = "board-spider",
> + .probe = spider_board_probe,
> + .of_compatible = spider_board_of_match,
> +};
> +device_platform_driver(spider_board_driver);
> \ No newline at end of file
> diff --git a/arch/arm/boards/pliops/spider/lowlevel.c b/arch/arm/boards/pliops/spider/lowlevel.c
> new file mode 100644
> index 0000000000..f3d5a27647
> --- /dev/null
> +++ b/arch/arm/boards/pliops/spider/lowlevel.c
> @@ -0,0 +1,28 @@
> +#include <common.h>
> +#include <asm/barebox-arm.h>
> +
> +#define BASE_ADDR (0xD000307000)
> +#define GPRAM_ADDR (0xC000000000)
> +#define MY_STACK_TOP (0xC000000000 + SZ_2M) // Set the stack 2MB from GPRAM start (excatly in the middle)
> +static inline void spider_serial_putc(void *base, int c)
> +{
> +// if (!(readl(base + UCR1) & UCR1_UARTEN))
> +// return;
> +//
> +// while (!(readl(base + USR2) & USR2_TXDC));
> +//
> +// writel(c, base + URTX0);
> +}
Also consider defining PUTC_LL. This is useful for very early debugging.
> +ENTRY_FUNCTION_WITHSTACK(start_spider_board, MY_STACK_TOP, r0, r1, r2)
Current implementation of ENTRY_FUNCTION_WITHSTACK assumes MY_STACK_TOP
to be within the first 4G. The compiler will warn you when it gets
truncated. This can be fixed, but I am wondering if the SRAM address
is indeed correct? Many IPs have limitation on how big addresses they
handle, so RAM more often than not starts below 4G.
> +{
> + extern char __dtb_spider_board_start[];
> + void *fdt;
You miss arm_cpu_lowlevel_init() here. See my patch.
> +
> + relocate_to_current_adr();
> + setup_c();
> +
> + pbl_set_putc(spider_serial_putc, (void *)BASE_ADDR);
> +
> + barebox_arm_entry(GPRAM_ADDR, SZ_2M, __dtb_spider_board_start);
> +}
> diff --git a/arch/arm/configs/spider_defconfig b/arch/arm/configs/spider_defconfig
> new file mode 100644
> index 0000000000..b4c4a32de0
> --- /dev/null
> +++ b/arch/arm/configs/spider_defconfig
> @@ -0,0 +1,3 @@
> +CONFIG_TEXT_BASE=0x4000000000
This causes a cryptic error message, because BAREBOX_MAX_BARE_INIT_SIZE
is 0xffff_ffff at most, which is less than the text base here.
You should just set it to 0 and enable CONFIG_RELOCATABLE. That way
barebox is executable from any address.
Note, that even on 64-bit platforms, barebox itself was always placed in
the lower 4G, so may run into some more issues that need to be fixed
first (if you don't have any RAM < 4G).
By the way, the most recent SoC being posted for upstream inclusion
is Jules' series for Allwinner/Sunxi:
https://lore.barebox.org/barebox/20230524234328.82741-1-jmaselbas@zdiv.net/T/#t
You may find it useful to take a look at it.
Cheers,
Ahmad
> +CONFIG_64BIT=y
> +CONFIG_CPU_V8=y
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply [flat|nested] 40+ messages in thread
* [PATCH v2] Porting barebox to a new SoC
2023-05-28 15:35 ` Ahmad Fatoum
@ 2023-05-28 15:37 ` Ahmad Fatoum
2023-05-28 20:15 ` Lior Weintraub
0 siblings, 1 reply; 40+ messages in thread
From: Ahmad Fatoum @ 2023-05-28 15:37 UTC (permalink / raw)
To: barebox; +Cc: Lior Weintraub
From: Lior Weintraub <liorw@pliops.com>
Hi,
I tried to follow the porting guide on https://www.barebox.org/doc/latest/devel/porting.html# but couldn't follow the instructions.
I would like to port barebox to a new SoC (which is not a derivative of any known SoC).
It has the following:
* Single Cortex A53
* SRAM (4MB) located on address 0xC000000000
The below patch shows my initial test to try and have a starting point.
I am setting env variables:
export ARCH=arm64
export CROSS_COMPILE=/home/pliops/workspace/ARM/arm-gnu-toolchain/bin/aarch64-none-elf-
Then I build with:
make spider_defconfig && make
This gives an error:
aarch64-none-elf-gcc: error: unrecognized argument in option '-mabi=apcs-gnu'
aarch64-none-elf-gcc: note: valid arguments to '-mabi=' are: ilp32 lp64
aarch64-none-elf-gcc: error: unrecognized command-line option '-msoft-float'
aarch64-none-elf-gcc: error: unrecognized command-line option '-mno-unaligned-access'
/home/pliops/workspace/simplest-linux-demo/barebox/scripts/Makefile.build:140: recipe for target 'scripts/mod/empty.o' failed
make[2]: *** [scripts/mod/empty.o] Error 1
Not sure why the compiler flags get -mabi=apcs-gnu when I explicitly set CONFIG_CPU_V8 and the arch/arm/Makefile has:
ifeq ($(CONFIG_CPU_V8), y)
CFLAGS_ABI :=-mabi=lp64
The changes I did:
>From 848b5f9b18bb1bb96d197cbc1b368ee0a729d581 Mon Sep 17 00:00:00 2001
---
arch/arm/Kconfig | 13 ++++++++
arch/arm/Makefile | 1 +
arch/arm/boards/Makefile | 1 +
arch/arm/boards/spider-evk/Makefile | 4 +++
arch/arm/boards/spider-evk/board.c | 26 +++++++++++++++
arch/arm/boards/spider-evk/lowlevel.c | 30 +++++++++++++++++
arch/arm/configs/spider_defconfig | 8 +++++
arch/arm/dts/Makefile | 1 +
arch/arm/dts/spider-mk1-evk.dts | 10 ++++++
arch/arm/dts/spider-mk1.dtsi | 46 +++++++++++++++++++++++++++
arch/arm/mach-spider/Kconfig | 16 ++++++++++
arch/arm/mach-spider/Makefile | 1 +
arch/arm/mach-spider/lowlevel.c | 14 ++++++++
images/Makefile | 1 +
images/Makefile.spider | 5 +++
include/mach/spider/lowlevel.h | 7 ++++
16 files changed, 184 insertions(+)
create mode 100644 arch/arm/boards/spider-evk/Makefile
create mode 100644 arch/arm/boards/spider-evk/board.c
create mode 100644 arch/arm/boards/spider-evk/lowlevel.c
create mode 100644 arch/arm/configs/spider_defconfig
create mode 100644 arch/arm/dts/spider-mk1-evk.dts
create mode 100644 arch/arm/dts/spider-mk1.dtsi
create mode 100644 arch/arm/mach-spider/Kconfig
create mode 100644 arch/arm/mach-spider/Makefile
create mode 100644 arch/arm/mach-spider/lowlevel.c
create mode 100644 images/Makefile.spider
create mode 100644 include/mach/spider/lowlevel.h
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index e76ee0f6dfe1..e5dcf128447e 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -255,6 +255,18 @@ config ARCH_ROCKCHIP
select HAS_DEBUG_LL
imply GPIO_ROCKCHIP
+config ARCH_SPIDER
+ bool "Pliops Spider based"
+ depends on 64BIT
+ depends on ARCH_MULTIARCH
+ select GPIOLIB
+ select HAVE_PBL_MULTI_IMAGES
+ select COMMON_CLK
+ select CLKDEV_LOOKUP
+ select COMMON_CLK_OF_PROVIDER
+ select OFTREE
+ select OFDEVICE
+
config ARCH_STM32MP
bool "STMicroelectronics STM32MP"
depends on 32BIT
@@ -331,6 +343,7 @@ source "arch/arm/mach-omap/Kconfig"
source "arch/arm/mach-pxa/Kconfig"
source "arch/arm/mach-rockchip/Kconfig"
source "arch/arm/mach-socfpga/Kconfig"
+source "arch/arm/mach-spider/Kconfig"
source "arch/arm/mach-stm32mp/Kconfig"
source "arch/arm/mach-versatile/Kconfig"
source "arch/arm/mach-vexpress/Kconfig"
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 35ebc70f44e2..4c63dfee48f4 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -101,6 +101,7 @@ machine-$(CONFIG_ARCH_MXS) += mxs
machine-$(CONFIG_ARCH_MVEBU) += mvebu
machine-$(CONFIG_ARCH_NOMADIK) += nomadik
machine-$(CONFIG_ARCH_OMAP) += omap
+machine-$(CONFIG_ARCH_SPIDER) += spider
machine-$(CONFIG_ARCH_PXA) += pxa
machine-$(CONFIG_ARCH_ROCKCHIP) += rockchip
machine-$(CONFIG_ARCH_SAMSUNG) += samsung
diff --git a/arch/arm/boards/Makefile b/arch/arm/boards/Makefile
index 2877debad535..6fe0a90c81ea 100644
--- a/arch/arm/boards/Makefile
+++ b/arch/arm/boards/Makefile
@@ -135,6 +135,7 @@ obj-$(CONFIG_MACH_SOCFPGA_TERASIC_DE10_NANO) += terasic-de10-nano/
obj-$(CONFIG_MACH_SOCFPGA_TERASIC_SOCKIT) += terasic-sockit/
obj-$(CONFIG_MACH_SOLIDRUN_CUBOX) += solidrun-cubox/
obj-$(CONFIG_MACH_SOLIDRUN_MICROSOM) += solidrun-microsom/
+obj-$(CONFIG_MACH_SPIDER_MK1_EVK) += spider-evk/
obj-$(CONFIG_MACH_STM32MP15XX_DKX) += stm32mp15xx-dkx/
obj-$(CONFIG_MACH_STM32MP13XX_DK) += stm32mp13xx-dk/
obj-$(CONFIG_MACH_LXA_MC1) += lxa-mc1/
diff --git a/arch/arm/boards/spider-evk/Makefile b/arch/arm/boards/spider-evk/Makefile
new file mode 100644
index 000000000000..da63d2625f7a
--- /dev/null
+++ b/arch/arm/boards/spider-evk/Makefile
@@ -0,0 +1,4 @@
+# SPDX-License-Identifier: GPL-2.0-only
+
+obj-y += board.o
+lwl-y += lowlevel.o
diff --git a/arch/arm/boards/spider-evk/board.c b/arch/arm/boards/spider-evk/board.c
new file mode 100644
index 000000000000..3920e83b457d
--- /dev/null
+++ b/arch/arm/boards/spider-evk/board.c
@@ -0,0 +1,26 @@
+#include <bbu.h>
+#include <boot.h>
+#include <bootm.h>
+#include <common.h>
+#include <deep-probe.h>
+#include <environment.h>
+#include <fcntl.h>
+#include <globalvar.h>
+
+static int spider_board_probe(struct device *dev)
+{
+ /* Do some board-specific setup */
+ return 0;
+}
+
+static const struct of_device_id spider_board_of_match[] = {
+ { .compatible = "pliops,spider-mk1-evk" },
+ { /* sentinel */ },
+};
+
+static struct driver spider_board_driver = {
+ .name = "board-spider",
+ .probe = spider_board_probe,
+ .of_compatible = spider_board_of_match,
+};
+device_platform_driver(spider_board_driver);
diff --git a/arch/arm/boards/spider-evk/lowlevel.c b/arch/arm/boards/spider-evk/lowlevel.c
new file mode 100644
index 000000000000..e36fcde4208e
--- /dev/null
+++ b/arch/arm/boards/spider-evk/lowlevel.c
@@ -0,0 +1,30 @@
+#include <common.h>
+#include <asm/barebox-arm.h>
+#include <mach/spider/lowlevel.h>
+
+#define BASE_ADDR (0xD000307000)
+#define GPRAM_ADDR (0xC000000000)
+#define MY_STACK_TOP (0xC000000000 + SZ_2M) // Set the stack 2MB from GPRAM start (excatly in the middle)
+static inline void spider_serial_putc(void *base, int c)
+{
+// if (!(readl(base + UCR1) & UCR1_UARTEN))
+// return;
+//
+// while (!(readl(base + USR2) & USR2_TXDC));
+//
+// writel(c, base + URTX0);
+}
+
+ENTRY_FUNCTION_WITHSTACK(start_spider_mk1_evk, MY_STACK_TOP, r0, r1, r2)
+{
+ extern char __dtb_spider_mk1_evk_start[];
+
+ spider_lowlevel_init();
+
+ relocate_to_current_adr();
+ setup_c();
+
+ pbl_set_putc(spider_serial_putc, (void *)BASE_ADDR);
+
+ barebox_arm_entry(GPRAM_ADDR, SZ_2M, __dtb_spider_mk1_evk_start);
+}
diff --git a/arch/arm/configs/spider_defconfig b/arch/arm/configs/spider_defconfig
new file mode 100644
index 000000000000..c91bb889d97f
--- /dev/null
+++ b/arch/arm/configs/spider_defconfig
@@ -0,0 +1,8 @@
+CONFIG_ARCH_SPIDER=y
+CONFIG_MACH_SPIDER_MK1_EVK=y
+CONFIG_BOARD_ARM_GENERIC_DT=y
+CONFIG_MALLOC_TLSF=y
+CONFIG_KALLSYMS=y
+CONFIG_RELOCATABLE=y
+CONFIG_CONSOLE_ALLOW_COLOR=y
+CONFIG_PBL_CONSOLE=y
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 98f4c4e0194b..94b304d4878f 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -134,6 +134,7 @@ lwl-$(CONFIG_MACH_SOLIDRUN_CUBOX) += dove-cubox-bb.dtb.o
lwl-$(CONFIG_MACH_SOLIDRUN_MICROSOM) += imx6dl-hummingboard.dtb.o imx6q-hummingboard.dtb.o \
imx6dl-hummingboard2.dtb.o imx6q-hummingboard2.dtb.o \
imx6q-h100.dtb.o
+lwl-$(CONFIG_MACH_SPIDER_MK1_EVK) += spider-mk1-evk.dtb.o
lwl-$(CONFIG_MACH_SKOV_IMX6) += imx6s-skov-imx6.dtb.o imx6dl-skov-imx6.dtb.o imx6q-skov-imx6.dtb.o
lwl-$(CONFIG_MACH_SKOV_ARM9CPU) += at91-skov-arm9cpu.dtb.o
lwl-$(CONFIG_MACH_SEEED_ODYSSEY) += stm32mp157c-odyssey.dtb.o
diff --git a/arch/arm/dts/spider-mk1-evk.dts b/arch/arm/dts/spider-mk1-evk.dts
new file mode 100644
index 000000000000..b8081cb85bf8
--- /dev/null
+++ b/arch/arm/dts/spider-mk1-evk.dts
@@ -0,0 +1,10 @@
+// SPDX-License-Identifier: GPL-2.0 OR X11
+
+/dts-v1/;
+
+#include "spider-mk1.dtsi"
+
+/ {
+ model = "Pliops Spider MK-I EVK";
+ compatible = "pliops,spider-mk1-evk";
+};
diff --git a/arch/arm/dts/spider-mk1.dtsi b/arch/arm/dts/spider-mk1.dtsi
new file mode 100644
index 000000000000..d4613848169d
--- /dev/null
+++ b/arch/arm/dts/spider-mk1.dtsi
@@ -0,0 +1,46 @@
+// SPDX-License-Identifier: GPL-2.0 OR X11
+
+/ {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ chosen {
+ stdout-path = &uart0;
+ };
+
+ aliases {
+ serial0 = &uart0;
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu0: cpu@0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53";
+ reg = <0x0>;
+ };
+ };
+
+ memory@1000000 {
+ reg = <0x0 0x1000000 0x0 0x400000>; /* 128M */
+ device_type = "memory";
+ };
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ sram@c000000000 {
+ compatible = "mmio-sram";
+ reg = <0xc0 0x0 0x0 0x400000>;
+ };
+
+ uart0: serial@d000307000 {
+ compatible = "pliops,spider-uart";
+ reg = <0xd0 0x307000 0 0x1000>;
+ };
+ };
+};
diff --git a/arch/arm/mach-spider/Kconfig b/arch/arm/mach-spider/Kconfig
new file mode 100644
index 000000000000..6d2f888a5fd8
--- /dev/null
+++ b/arch/arm/mach-spider/Kconfig
@@ -0,0 +1,16 @@
+# SPDX-License-Identifier: GPL-2.0-only
+
+if ARCH_SPIDER
+
+config ARCH_SPIDER_MK1
+ bool
+ select CPU_V8
+ help
+ The first Cortex-A53-based SoC of the spider family.
+ This symbol is invisble and select by boards
+
+config MACH_SPIDER_MK1_EVK
+ bool "Pliops Spider Reference Design Board"
+ select ARCH_SPIDER_MK1
+
+endif
diff --git a/arch/arm/mach-spider/Makefile b/arch/arm/mach-spider/Makefile
new file mode 100644
index 000000000000..b08c4a93ca27
--- /dev/null
+++ b/arch/arm/mach-spider/Makefile
@@ -0,0 +1 @@
+lwl-y += lowlevel.o
diff --git a/arch/arm/mach-spider/lowlevel.c b/arch/arm/mach-spider/lowlevel.c
new file mode 100644
index 000000000000..5d62ef0f39e5
--- /dev/null
+++ b/arch/arm/mach-spider/lowlevel.c
@@ -0,0 +1,14 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+#include <linux/types.h>
+#include <mach/spider/lowlevel.h>
+#include <asm/barebox-arm-head.h>
+
+void spider_lowlevel_init(void)
+{
+ arm_cpu_lowlevel_init();
+ /*
+ * not yet relocated, only do writel/readl for stuff that's
+ * critical to run early. No global variables allowed.
+ */
+}
diff --git a/images/Makefile b/images/Makefile
index c93f9e268978..97521e713228 100644
--- a/images/Makefile
+++ b/images/Makefile
@@ -150,6 +150,7 @@ include $(srctree)/images/Makefile.mxs
include $(srctree)/images/Makefile.omap3
include $(srctree)/images/Makefile.rockchip
include $(srctree)/images/Makefile.socfpga
+include $(srctree)/images/Makefile.spider
include $(srctree)/images/Makefile.stm32mp
include $(srctree)/images/Makefile.tegra
include $(srctree)/images/Makefile.versatile
diff --git a/images/Makefile.spider b/images/Makefile.spider
new file mode 100644
index 000000000000..c32f2762df04
--- /dev/null
+++ b/images/Makefile.spider
@@ -0,0 +1,5 @@
+# SPDX-License-Identifier: GPL-2.0-only
+
+pblb-$(CONFIG_MACH_SPIDER_MK1_EVK) += start_spider_mk1_evk
+FILE_barebox-spider-mk1-evk.img = start_spider_mk1_evk.pblb
+image-$(CONFIG_MACH_SPIDER_MK1_EVK) += barebox-spider-mk1-evk.img
diff --git a/include/mach/spider/lowlevel.h b/include/mach/spider/lowlevel.h
new file mode 100644
index 000000000000..6e0ce1c77f7e
--- /dev/null
+++ b/include/mach/spider/lowlevel.h
@@ -0,0 +1,7 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+#ifndef __MACH_SPIDER_H_
+#define __MACH_SPIDER_H_
+
+void spider_lowlevel_init(void);
+
+#endif
--
2.38.4
^ permalink raw reply [flat|nested] 40+ messages in thread
* RE: [PATCH v2] Porting barebox to a new SoC
2023-05-28 15:37 ` [PATCH v2] " Ahmad Fatoum
@ 2023-05-28 20:15 ` Lior Weintraub
2023-05-29 13:34 ` Lior Weintraub
0 siblings, 1 reply; 40+ messages in thread
From: Lior Weintraub @ 2023-05-28 20:15 UTC (permalink / raw)
To: Ahmad Fatoum, barebox
Hi Ahmad,
Thank you so much for your kind support!
Indeed we also have a 16GB DRAM that starts from address 0 (though currently we don't have the controller settings (under development)).
I also wrote the BootROM (BL1) for this SoC (128KB ROM @ address 0xC004000000).
I understand now that it would be best for me to develop BL2 that will run from our SRAM.
As this BL2 code is bare-metal I have no problem or limitations with the 40 bit addresses.
The BL2 code will initialize the DRAM controller and then copy Barebox image from NOR Flash to address 0 of the DRAM.
Our NOR Flash is 128MB in size and it is accessed via QSPI controller.
I tried applying your suggested patch but got an error while doing so:
$git apply 0002-Ahmad.patch
0002-Ahmad.patch:115: trailing whitespace.
.of_compatible = spider_board_of_match, };
error: corrupt patch at line 117
After some digging I found that my Outlook probably messed with the patch format (even though I am using text only and no HTML format).
When I went to the web and copied the patch from there (mailing list archive) it was working well (i.e. no compilation error).
Cheers,
Lior.
-----Original Message-----
From: Ahmad Fatoum <ahmad@a3f.at>
Sent: Sunday, May 28, 2023 6:38 PM
To: barebox@lists.infradead.org
Cc: Lior Weintraub <liorw@pliops.com>
Subject: [PATCH v2] Porting barebox to a new SoC
CAUTION: External Sender
From: Lior Weintraub <liorw@pliops.com>
Hi,
I tried to follow the porting guide on https://ddec1-0-en-ctp.trendmicro.com:443/wis/clicktime/v1/query?url=https%3a%2f%2fwww.barebox.org%2fdoc%2flatest%2fdevel%2fporting.html%23&umid=60097eda-f136-45a1-9c8e-cf6a76e45cf8&auth=860a7ebb9feba264acc79b6e38eb59582349362c-480ae23736add41c88ab8d30c090a75517ca7f9e but couldn't follow the instructions.
I would like to port barebox to a new SoC (which is not a derivative of any known SoC).
It has the following:
* Single Cortex A53
* SRAM (4MB) located on address 0xC000000000
The below patch shows my initial test to try and have a starting point.
I am setting env variables:
export ARCH=arm64
export CROSS_COMPILE=/home/pliops/workspace/ARM/arm-gnu-toolchain/bin/aarch64-none-elf-
Then I build with:
make spider_defconfig && make
This gives an error:
aarch64-none-elf-gcc: error: unrecognized argument in option '-mabi=apcs-gnu'
aarch64-none-elf-gcc: note: valid arguments to '-mabi=' are: ilp32 lp64
aarch64-none-elf-gcc: error: unrecognized command-line option '-msoft-float'
aarch64-none-elf-gcc: error: unrecognized command-line option '-mno-unaligned-access'
/home/pliops/workspace/simplest-linux-demo/barebox/scripts/Makefile.build:140: recipe for target 'scripts/mod/empty.o' failed
make[2]: *** [scripts/mod/empty.o] Error 1
Not sure why the compiler flags get -mabi=apcs-gnu when I explicitly set CONFIG_CPU_V8 and the arch/arm/Makefile has:
ifeq ($(CONFIG_CPU_V8), y)
CFLAGS_ABI :=-mabi=lp64
The changes I did:
>From 848b5f9b18bb1bb96d197cbc1b368ee0a729d581 Mon Sep 17 00:00:00 2001
---
arch/arm/Kconfig | 13 ++++++++
arch/arm/Makefile | 1 +
arch/arm/boards/Makefile | 1 +
arch/arm/boards/spider-evk/Makefile | 4 +++
arch/arm/boards/spider-evk/board.c | 26 +++++++++++++++
arch/arm/boards/spider-evk/lowlevel.c | 30 +++++++++++++++++
arch/arm/configs/spider_defconfig | 8 +++++
arch/arm/dts/Makefile | 1 +
arch/arm/dts/spider-mk1-evk.dts | 10 ++++++
arch/arm/dts/spider-mk1.dtsi | 46 +++++++++++++++++++++++++++
arch/arm/mach-spider/Kconfig | 16 ++++++++++
arch/arm/mach-spider/Makefile | 1 +
arch/arm/mach-spider/lowlevel.c | 14 ++++++++
images/Makefile | 1 +
images/Makefile.spider | 5 +++
include/mach/spider/lowlevel.h | 7 ++++
16 files changed, 184 insertions(+)
create mode 100644 arch/arm/boards/spider-evk/Makefile
create mode 100644 arch/arm/boards/spider-evk/board.c
create mode 100644 arch/arm/boards/spider-evk/lowlevel.c
create mode 100644 arch/arm/configs/spider_defconfig create mode 100644 arch/arm/dts/spider-mk1-evk.dts create mode 100644 arch/arm/dts/spider-mk1.dtsi create mode 100644 arch/arm/mach-spider/Kconfig create mode 100644 arch/arm/mach-spider/Makefile create mode 100644 arch/arm/mach-spider/lowlevel.c create mode 100644 images/Makefile.spider create mode 100644 include/mach/spider/lowlevel.h
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index e76ee0f6dfe1..e5dcf128447e 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -255,6 +255,18 @@ config ARCH_ROCKCHIP
select HAS_DEBUG_LL
imply GPIO_ROCKCHIP
+config ARCH_SPIDER
+ bool "Pliops Spider based"
+ depends on 64BIT
+ depends on ARCH_MULTIARCH
+ select GPIOLIB
+ select HAVE_PBL_MULTI_IMAGES
+ select COMMON_CLK
+ select CLKDEV_LOOKUP
+ select COMMON_CLK_OF_PROVIDER
+ select OFTREE
+ select OFDEVICE
+
config ARCH_STM32MP
bool "STMicroelectronics STM32MP"
depends on 32BIT
@@ -331,6 +343,7 @@ source "arch/arm/mach-omap/Kconfig"
source "arch/arm/mach-pxa/Kconfig"
source "arch/arm/mach-rockchip/Kconfig"
source "arch/arm/mach-socfpga/Kconfig"
+source "arch/arm/mach-spider/Kconfig"
source "arch/arm/mach-stm32mp/Kconfig"
source "arch/arm/mach-versatile/Kconfig"
source "arch/arm/mach-vexpress/Kconfig"
diff --git a/arch/arm/Makefile b/arch/arm/Makefile index 35ebc70f44e2..4c63dfee48f4 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -101,6 +101,7 @@ machine-$(CONFIG_ARCH_MXS) += mxs
machine-$(CONFIG_ARCH_MVEBU) += mvebu
machine-$(CONFIG_ARCH_NOMADIK) += nomadik
machine-$(CONFIG_ARCH_OMAP) += omap
+machine-$(CONFIG_ARCH_SPIDER) += spider
machine-$(CONFIG_ARCH_PXA) += pxa
machine-$(CONFIG_ARCH_ROCKCHIP) += rockchip
machine-$(CONFIG_ARCH_SAMSUNG) += samsung
diff --git a/arch/arm/boards/Makefile b/arch/arm/boards/Makefile index 2877debad535..6fe0a90c81ea 100644
--- a/arch/arm/boards/Makefile
+++ b/arch/arm/boards/Makefile
@@ -135,6 +135,7 @@ obj-$(CONFIG_MACH_SOCFPGA_TERASIC_DE10_NANO) += terasic-de10-nano/
obj-$(CONFIG_MACH_SOCFPGA_TERASIC_SOCKIT) += terasic-sockit/
obj-$(CONFIG_MACH_SOLIDRUN_CUBOX) += solidrun-cubox/
obj-$(CONFIG_MACH_SOLIDRUN_MICROSOM) += solidrun-microsom/
+obj-$(CONFIG_MACH_SPIDER_MK1_EVK) += spider-evk/
obj-$(CONFIG_MACH_STM32MP15XX_DKX) += stm32mp15xx-dkx/
obj-$(CONFIG_MACH_STM32MP13XX_DK) += stm32mp13xx-dk/
obj-$(CONFIG_MACH_LXA_MC1) += lxa-mc1/
diff --git a/arch/arm/boards/spider-evk/Makefile b/arch/arm/boards/spider-evk/Makefile
new file mode 100644
index 000000000000..da63d2625f7a
--- /dev/null
+++ b/arch/arm/boards/spider-evk/Makefile
@@ -0,0 +1,4 @@
+# SPDX-License-Identifier: GPL-2.0-only
+
+obj-y += board.o
+lwl-y += lowlevel.o
diff --git a/arch/arm/boards/spider-evk/board.c b/arch/arm/boards/spider-evk/board.c
new file mode 100644
index 000000000000..3920e83b457d
--- /dev/null
+++ b/arch/arm/boards/spider-evk/board.c
@@ -0,0 +1,26 @@
+#include <bbu.h>
+#include <boot.h>
+#include <bootm.h>
+#include <common.h>
+#include <deep-probe.h>
+#include <environment.h>
+#include <fcntl.h>
+#include <globalvar.h>
+
+static int spider_board_probe(struct device *dev) {
+ /* Do some board-specific setup */
+ return 0;
+}
+
+static const struct of_device_id spider_board_of_match[] = {
+ { .compatible = "pliops,spider-mk1-evk" },
+ { /* sentinel */ },
+};
+
+static struct driver spider_board_driver = {
+ .name = "board-spider",
+ .probe = spider_board_probe,
+ .of_compatible = spider_board_of_match, };
+device_platform_driver(spider_board_driver);
diff --git a/arch/arm/boards/spider-evk/lowlevel.c b/arch/arm/boards/spider-evk/lowlevel.c
new file mode 100644
index 000000000000..e36fcde4208e
--- /dev/null
+++ b/arch/arm/boards/spider-evk/lowlevel.c
@@ -0,0 +1,30 @@
+#include <common.h>
+#include <asm/barebox-arm.h>
+#include <mach/spider/lowlevel.h>
+
+#define BASE_ADDR (0xD000307000)
+#define GPRAM_ADDR (0xC000000000)
+#define MY_STACK_TOP (0xC000000000 + SZ_2M) // Set the stack 2MB from GPRAM start (excatly in the middle)
+static inline void spider_serial_putc(void *base, int c) {
+// if (!(readl(base + UCR1) & UCR1_UARTEN))
+// return;
+//
+// while (!(readl(base + USR2) & USR2_TXDC));
+//
+// writel(c, base + URTX0);
+}
+
+ENTRY_FUNCTION_WITHSTACK(start_spider_mk1_evk, MY_STACK_TOP, r0, r1,
+r2) {
+ extern char __dtb_spider_mk1_evk_start[];
+
+ spider_lowlevel_init();
+
+ relocate_to_current_adr();
+ setup_c();
+
+ pbl_set_putc(spider_serial_putc, (void *)BASE_ADDR);
+
+ barebox_arm_entry(GPRAM_ADDR, SZ_2M,
+__dtb_spider_mk1_evk_start); }
diff --git a/arch/arm/configs/spider_defconfig b/arch/arm/configs/spider_defconfig
new file mode 100644
index 000000000000..c91bb889d97f
--- /dev/null
+++ b/arch/arm/configs/spider_defconfig
@@ -0,0 +1,8 @@
+CONFIG_ARCH_SPIDER=y
+CONFIG_MACH_SPIDER_MK1_EVK=y
+CONFIG_BOARD_ARM_GENERIC_DT=y
+CONFIG_MALLOC_TLSF=y
+CONFIG_KALLSYMS=y
+CONFIG_RELOCATABLE=y
+CONFIG_CONSOLE_ALLOW_COLOR=y
+CONFIG_PBL_CONSOLE=y
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile index 98f4c4e0194b..94b304d4878f 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -134,6 +134,7 @@ lwl-$(CONFIG_MACH_SOLIDRUN_CUBOX) += dove-cubox-bb.dtb.o
lwl-$(CONFIG_MACH_SOLIDRUN_MICROSOM) += imx6dl-hummingboard.dtb.o imx6q-hummingboard.dtb.o \
imx6dl-hummingboard2.dtb.o imx6q-hummingboard2.dtb.o \
imx6q-h100.dtb.o
+lwl-$(CONFIG_MACH_SPIDER_MK1_EVK) += spider-mk1-evk.dtb.o
lwl-$(CONFIG_MACH_SKOV_IMX6) += imx6s-skov-imx6.dtb.o imx6dl-skov-imx6.dtb.o imx6q-skov-imx6.dtb.o
lwl-$(CONFIG_MACH_SKOV_ARM9CPU) += at91-skov-arm9cpu.dtb.o
lwl-$(CONFIG_MACH_SEEED_ODYSSEY) += stm32mp157c-odyssey.dtb.o diff --git a/arch/arm/dts/spider-mk1-evk.dts b/arch/arm/dts/spider-mk1-evk.dts new file mode 100644 index 000000000000..b8081cb85bf8
--- /dev/null
+++ b/arch/arm/dts/spider-mk1-evk.dts
@@ -0,0 +1,10 @@
+// SPDX-License-Identifier: GPL-2.0 OR X11
+
+/dts-v1/;
+
+#include "spider-mk1.dtsi"
+
+/ {
+ model = "Pliops Spider MK-I EVK";
+ compatible = "pliops,spider-mk1-evk"; };
diff --git a/arch/arm/dts/spider-mk1.dtsi b/arch/arm/dts/spider-mk1.dtsi new file mode 100644 index 000000000000..d4613848169d
--- /dev/null
+++ b/arch/arm/dts/spider-mk1.dtsi
@@ -0,0 +1,46 @@
+// SPDX-License-Identifier: GPL-2.0 OR X11
+
+/ {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ chosen {
+ stdout-path = &uart0;
+ };
+
+ aliases {
+ serial0 = &uart0;
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu0: cpu@0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53";
+ reg = <0x0>;
+ };
+ };
+
+ memory@1000000 {
+ reg = <0x0 0x1000000 0x0 0x400000>; /* 128M */
+ device_type = "memory";
+ };
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ sram@c000000000 {
+ compatible = "mmio-sram";
+ reg = <0xc0 0x0 0x0 0x400000>;
+ };
+
+ uart0: serial@d000307000 {
+ compatible = "pliops,spider-uart";
+ reg = <0xd0 0x307000 0 0x1000>;
+ };
+ };
+};
diff --git a/arch/arm/mach-spider/Kconfig b/arch/arm/mach-spider/Kconfig new file mode 100644 index 000000000000..6d2f888a5fd8
--- /dev/null
+++ b/arch/arm/mach-spider/Kconfig
@@ -0,0 +1,16 @@
+# SPDX-License-Identifier: GPL-2.0-only
+
+if ARCH_SPIDER
+
+config ARCH_SPIDER_MK1
+ bool
+ select CPU_V8
+ help
+ The first Cortex-A53-based SoC of the spider family.
+ This symbol is invisble and select by boards
+
+config MACH_SPIDER_MK1_EVK
+ bool "Pliops Spider Reference Design Board"
+ select ARCH_SPIDER_MK1
+
+endif
diff --git a/arch/arm/mach-spider/Makefile b/arch/arm/mach-spider/Makefile new file mode 100644 index 000000000000..b08c4a93ca27
--- /dev/null
+++ b/arch/arm/mach-spider/Makefile
@@ -0,0 +1 @@
+lwl-y += lowlevel.o
diff --git a/arch/arm/mach-spider/lowlevel.c b/arch/arm/mach-spider/lowlevel.c new file mode 100644 index 000000000000..5d62ef0f39e5
--- /dev/null
+++ b/arch/arm/mach-spider/lowlevel.c
@@ -0,0 +1,14 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+#include <linux/types.h>
+#include <mach/spider/lowlevel.h>
+#include <asm/barebox-arm-head.h>
+
+void spider_lowlevel_init(void)
+{
+ arm_cpu_lowlevel_init();
+ /*
+ * not yet relocated, only do writel/readl for stuff that's
+ * critical to run early. No global variables allowed.
+ */
+}
diff --git a/images/Makefile b/images/Makefile index c93f9e268978..97521e713228 100644
--- a/images/Makefile
+++ b/images/Makefile
@@ -150,6 +150,7 @@ include $(srctree)/images/Makefile.mxs include $(srctree)/images/Makefile.omap3 include $(srctree)/images/Makefile.rockchip
include $(srctree)/images/Makefile.socfpga
+include $(srctree)/images/Makefile.spider
include $(srctree)/images/Makefile.stm32mp
include $(srctree)/images/Makefile.tegra include $(srctree)/images/Makefile.versatile
diff --git a/images/Makefile.spider b/images/Makefile.spider new file mode 100644 index 000000000000..c32f2762df04
--- /dev/null
+++ b/images/Makefile.spider
@@ -0,0 +1,5 @@
+# SPDX-License-Identifier: GPL-2.0-only
+
+pblb-$(CONFIG_MACH_SPIDER_MK1_EVK) += start_spider_mk1_evk
+FILE_barebox-spider-mk1-evk.img = start_spider_mk1_evk.pblb
+image-$(CONFIG_MACH_SPIDER_MK1_EVK) += barebox-spider-mk1-evk.img
diff --git a/include/mach/spider/lowlevel.h b/include/mach/spider/lowlevel.h new file mode 100644 index 000000000000..6e0ce1c77f7e
--- /dev/null
+++ b/include/mach/spider/lowlevel.h
@@ -0,0 +1,7 @@
+/* SPDX-License-Identifier: GPL-2.0+ */ #ifndef __MACH_SPIDER_H_
+#define __MACH_SPIDER_H_
+
+void spider_lowlevel_init(void);
+
+#endif
--
2.38.4
^ permalink raw reply [flat|nested] 40+ messages in thread
* RE: [PATCH v2] Porting barebox to a new SoC
2023-05-28 20:15 ` Lior Weintraub
@ 2023-05-29 13:34 ` Lior Weintraub
2023-05-29 19:03 ` Ahmad Fatoum
0 siblings, 1 reply; 40+ messages in thread
From: Lior Weintraub @ 2023-05-29 13:34 UTC (permalink / raw)
To: Ahmad Fatoum, barebox
Hi Ahmad,
I have revised the addresses and used DRAM address @ 0 instead:
#define UARTBASE (0xD000307000)
#define DRAM_ADDR (0x00000000)
#define MY_STACK_TOP (0x00000000 + SZ_2M) // Set the stack 2MB from DRAM start
static inline void spider_serial_putc(void *base, int c)
{
*((volatile unsigned *)base) = c;
}
I will try to test it on QEMU using an initial QEMU machine we made for Spider.
In this machine we only have 3 memory regions and a PL011 UART:
spider_soc_memories soc_memories[] = {
{.name = "SPIDER_GPRAM", .add = 0xC000000000ULL, .size = 4 * MiB},
{.name = "SPIDER_ROM", .add = 0xC004000000ULL, .size = 128 * KiB},
{.name = "SPIDER_DRAM", .add = 0x0000000000ULL, .size = 1 * GiB},
};
This special QEMU machine can run our BL1 code from "ROM" address (we set the RVBAR to point there).
So my idea is to test the barebox image by the following steps:
1. Modify the QEMU code to have a "ROM" with the size of 128M.
2. Compile our BL1 code to include the barebox.bin as a const array, copy it to "DRAM" @ address 0 and jump there.
For this to work I wanted to understand how to call (i.e. what arguments to pass) to barebox.
So I checked the barebox.map and found the function "start" on address 0.
Then I went to arch/arm/cpu/start.c and realized that the code is compiled with CONFIG_PBL_IMAGE.
In that case I assume I need to pass 3 arguments and use this function prototype:
void start(unsigned long membase, unsigned long memsize, void *boarddata);
Few questions:
1. Will that call work:
typedef void (*barebox_start)(unsigned long , unsigned long , void *);
#define DRAM_START (0)
barebox_start p_barebox = (barebox_start)DRAM_START;
p_barebox(DRAM_START, DRAM_START+SZ_2M, (void *)(DRAM_START+SZ_4M));
This assumes that my BL1 code also copied the device tree (barebox-dt-2nd.img? start_dt_2nd.pblb? start_spider_mk1_evk.pblb?)
2. Do I want to have my code compiled with CONFIG_PBL_IMAGE?
If I understand correctly, it means that my code will provide a PBL (a.k.a BL2) which will set the DRAM and STACK among other things (MMU?).
In that case I assume it is OK.
3. If I try to remove it by having CONFIG_PBL_IMAGE=n on spider_defconfig this doesn't do anything
The build (make spider_defconfig) ignores it and say that " No change to .config ".
4. I also tried to understand how to implement PUTC_LL but not sure I understand.
4.1 When I set "CONFIG_DEBUG_LL=y" on spider_defconfig it is again not written to .config and I get " No change to .config " message.
4.2 Do I need to have my own debug_ll.h file?
5. When I make changes to spider_defconfig and try to regenerate the .config and I get " No change to .config " message, does it mean that those macros are "hidden" symbols like you said about the CONFIG_CPU_V8?
Apologize for so many questions :-)
Cheers,
Lior.
-----Original Message-----
From: Lior Weintraub
Sent: Sunday, May 28, 2023 11:16 PM
To: Ahmad Fatoum <ahmad@a3f.at>; barebox@lists.infradead.org
Subject: RE: [PATCH v2] Porting barebox to a new SoC
Hi Ahmad,
Thank you so much for your kind support!
Indeed we also have a 16GB DRAM that starts from address 0 (though currently we don't have the controller settings (under development)).
I also wrote the BootROM (BL1) for this SoC (128KB ROM @ address 0xC004000000).
I understand now that it would be best for me to develop BL2 that will run from our SRAM.
As this BL2 code is bare-metal I have no problem or limitations with the 40 bit addresses.
The BL2 code will initialize the DRAM controller and then copy Barebox image from NOR Flash to address 0 of the DRAM.
Our NOR Flash is 128MB in size and it is accessed via QSPI controller.
I tried applying your suggested patch but got an error while doing so:
$git apply 0002-Ahmad.patch
0002-Ahmad.patch:115: trailing whitespace.
.of_compatible = spider_board_of_match, };
error: corrupt patch at line 117
After some digging I found that my Outlook probably messed with the patch format (even though I am using text only and no HTML format).
When I went to the web and copied the patch from there (mailing list archive) it was working well (i.e. no compilation error).
Cheers,
Lior.
-----Original Message-----
From: Ahmad Fatoum <ahmad@a3f.at>
Sent: Sunday, May 28, 2023 6:38 PM
To: barebox@lists.infradead.org
Cc: Lior Weintraub <liorw@pliops.com>
Subject: [PATCH v2] Porting barebox to a new SoC
CAUTION: External Sender
From: Lior Weintraub <liorw@pliops.com>
Hi,
I tried to follow the porting guide on https://ddec1-0-en-ctp.trendmicro.com:443/wis/clicktime/v1/query?url=https%3a%2f%2fwww.barebox.org%2fdoc%2flatest%2fdevel%2fporting.html%23&umid=60097eda-f136-45a1-9c8e-cf6a76e45cf8&auth=860a7ebb9feba264acc79b6e38eb59582349362c-480ae23736add41c88ab8d30c090a75517ca7f9e but couldn't follow the instructions.
I would like to port barebox to a new SoC (which is not a derivative of any known SoC).
It has the following:
* Single Cortex A53
* SRAM (4MB) located on address 0xC000000000
The below patch shows my initial test to try and have a starting point.
I am setting env variables:
export ARCH=arm64
export CROSS_COMPILE=/home/pliops/workspace/ARM/arm-gnu-toolchain/bin/aarch64-none-elf-
Then I build with:
make spider_defconfig && make
This gives an error:
aarch64-none-elf-gcc: error: unrecognized argument in option '-mabi=apcs-gnu'
aarch64-none-elf-gcc: note: valid arguments to '-mabi=' are: ilp32 lp64
aarch64-none-elf-gcc: error: unrecognized command-line option '-msoft-float'
aarch64-none-elf-gcc: error: unrecognized command-line option '-mno-unaligned-access'
/home/pliops/workspace/simplest-linux-demo/barebox/scripts/Makefile.build:140: recipe for target 'scripts/mod/empty.o' failed
make[2]: *** [scripts/mod/empty.o] Error 1
Not sure why the compiler flags get -mabi=apcs-gnu when I explicitly set CONFIG_CPU_V8 and the arch/arm/Makefile has:
ifeq ($(CONFIG_CPU_V8), y)
CFLAGS_ABI :=-mabi=lp64
The changes I did:
>From 848b5f9b18bb1bb96d197cbc1b368ee0a729d581 Mon Sep 17 00:00:00 2001
---
arch/arm/Kconfig | 13 ++++++++
arch/arm/Makefile | 1 +
arch/arm/boards/Makefile | 1 +
arch/arm/boards/spider-evk/Makefile | 4 +++
arch/arm/boards/spider-evk/board.c | 26 +++++++++++++++
arch/arm/boards/spider-evk/lowlevel.c | 30 +++++++++++++++++
arch/arm/configs/spider_defconfig | 8 +++++
arch/arm/dts/Makefile | 1 +
arch/arm/dts/spider-mk1-evk.dts | 10 ++++++
arch/arm/dts/spider-mk1.dtsi | 46 +++++++++++++++++++++++++++
arch/arm/mach-spider/Kconfig | 16 ++++++++++
arch/arm/mach-spider/Makefile | 1 +
arch/arm/mach-spider/lowlevel.c | 14 ++++++++
images/Makefile | 1 +
images/Makefile.spider | 5 +++
include/mach/spider/lowlevel.h | 7 ++++
16 files changed, 184 insertions(+)
create mode 100644 arch/arm/boards/spider-evk/Makefile
create mode 100644 arch/arm/boards/spider-evk/board.c
create mode 100644 arch/arm/boards/spider-evk/lowlevel.c
create mode 100644 arch/arm/configs/spider_defconfig create mode 100644 arch/arm/dts/spider-mk1-evk.dts create mode 100644 arch/arm/dts/spider-mk1.dtsi create mode 100644 arch/arm/mach-spider/Kconfig create mode 100644 arch/arm/mach-spider/Makefile create mode 100644 arch/arm/mach-spider/lowlevel.c create mode 100644 images/Makefile.spider create mode 100644 include/mach/spider/lowlevel.h
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index e76ee0f6dfe1..e5dcf128447e 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -255,6 +255,18 @@ config ARCH_ROCKCHIP
select HAS_DEBUG_LL
imply GPIO_ROCKCHIP
+config ARCH_SPIDER
+ bool "Pliops Spider based"
+ depends on 64BIT
+ depends on ARCH_MULTIARCH
+ select GPIOLIB
+ select HAVE_PBL_MULTI_IMAGES
+ select COMMON_CLK
+ select CLKDEV_LOOKUP
+ select COMMON_CLK_OF_PROVIDER
+ select OFTREE
+ select OFDEVICE
+
config ARCH_STM32MP
bool "STMicroelectronics STM32MP"
depends on 32BIT
@@ -331,6 +343,7 @@ source "arch/arm/mach-omap/Kconfig"
source "arch/arm/mach-pxa/Kconfig"
source "arch/arm/mach-rockchip/Kconfig"
source "arch/arm/mach-socfpga/Kconfig"
+source "arch/arm/mach-spider/Kconfig"
source "arch/arm/mach-stm32mp/Kconfig"
source "arch/arm/mach-versatile/Kconfig"
source "arch/arm/mach-vexpress/Kconfig"
diff --git a/arch/arm/Makefile b/arch/arm/Makefile index 35ebc70f44e2..4c63dfee48f4 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -101,6 +101,7 @@ machine-$(CONFIG_ARCH_MXS) += mxs
machine-$(CONFIG_ARCH_MVEBU) += mvebu
machine-$(CONFIG_ARCH_NOMADIK) += nomadik
machine-$(CONFIG_ARCH_OMAP) += omap
+machine-$(CONFIG_ARCH_SPIDER) += spider
machine-$(CONFIG_ARCH_PXA) += pxa
machine-$(CONFIG_ARCH_ROCKCHIP) += rockchip
machine-$(CONFIG_ARCH_SAMSUNG) += samsung
diff --git a/arch/arm/boards/Makefile b/arch/arm/boards/Makefile index 2877debad535..6fe0a90c81ea 100644
--- a/arch/arm/boards/Makefile
+++ b/arch/arm/boards/Makefile
@@ -135,6 +135,7 @@ obj-$(CONFIG_MACH_SOCFPGA_TERASIC_DE10_NANO) += terasic-de10-nano/
obj-$(CONFIG_MACH_SOCFPGA_TERASIC_SOCKIT) += terasic-sockit/
obj-$(CONFIG_MACH_SOLIDRUN_CUBOX) += solidrun-cubox/
obj-$(CONFIG_MACH_SOLIDRUN_MICROSOM) += solidrun-microsom/
+obj-$(CONFIG_MACH_SPIDER_MK1_EVK) += spider-evk/
obj-$(CONFIG_MACH_STM32MP15XX_DKX) += stm32mp15xx-dkx/
obj-$(CONFIG_MACH_STM32MP13XX_DK) += stm32mp13xx-dk/
obj-$(CONFIG_MACH_LXA_MC1) += lxa-mc1/
diff --git a/arch/arm/boards/spider-evk/Makefile b/arch/arm/boards/spider-evk/Makefile
new file mode 100644
index 000000000000..da63d2625f7a
--- /dev/null
+++ b/arch/arm/boards/spider-evk/Makefile
@@ -0,0 +1,4 @@
+# SPDX-License-Identifier: GPL-2.0-only
+
+obj-y += board.o
+lwl-y += lowlevel.o
diff --git a/arch/arm/boards/spider-evk/board.c b/arch/arm/boards/spider-evk/board.c
new file mode 100644
index 000000000000..3920e83b457d
--- /dev/null
+++ b/arch/arm/boards/spider-evk/board.c
@@ -0,0 +1,26 @@
+#include <bbu.h>
+#include <boot.h>
+#include <bootm.h>
+#include <common.h>
+#include <deep-probe.h>
+#include <environment.h>
+#include <fcntl.h>
+#include <globalvar.h>
+
+static int spider_board_probe(struct device *dev) {
+ /* Do some board-specific setup */
+ return 0;
+}
+
+static const struct of_device_id spider_board_of_match[] = {
+ { .compatible = "pliops,spider-mk1-evk" },
+ { /* sentinel */ },
+};
+
+static struct driver spider_board_driver = {
+ .name = "board-spider",
+ .probe = spider_board_probe,
+ .of_compatible = spider_board_of_match, };
+device_platform_driver(spider_board_driver);
diff --git a/arch/arm/boards/spider-evk/lowlevel.c b/arch/arm/boards/spider-evk/lowlevel.c
new file mode 100644
index 000000000000..e36fcde4208e
--- /dev/null
+++ b/arch/arm/boards/spider-evk/lowlevel.c
@@ -0,0 +1,30 @@
+#include <common.h>
+#include <asm/barebox-arm.h>
+#include <mach/spider/lowlevel.h>
+
+#define BASE_ADDR (0xD000307000)
+#define GPRAM_ADDR (0xC000000000)
+#define MY_STACK_TOP (0xC000000000 + SZ_2M) // Set the stack 2MB from GPRAM start (excatly in the middle)
+static inline void spider_serial_putc(void *base, int c) {
+// if (!(readl(base + UCR1) & UCR1_UARTEN))
+// return;
+//
+// while (!(readl(base + USR2) & USR2_TXDC));
+//
+// writel(c, base + URTX0);
+}
+
+ENTRY_FUNCTION_WITHSTACK(start_spider_mk1_evk, MY_STACK_TOP, r0, r1,
+r2) {
+ extern char __dtb_spider_mk1_evk_start[];
+
+ spider_lowlevel_init();
+
+ relocate_to_current_adr();
+ setup_c();
+
+ pbl_set_putc(spider_serial_putc, (void *)BASE_ADDR);
+
+ barebox_arm_entry(GPRAM_ADDR, SZ_2M,
+__dtb_spider_mk1_evk_start); }
diff --git a/arch/arm/configs/spider_defconfig b/arch/arm/configs/spider_defconfig
new file mode 100644
index 000000000000..c91bb889d97f
--- /dev/null
+++ b/arch/arm/configs/spider_defconfig
@@ -0,0 +1,8 @@
+CONFIG_ARCH_SPIDER=y
+CONFIG_MACH_SPIDER_MK1_EVK=y
+CONFIG_BOARD_ARM_GENERIC_DT=y
+CONFIG_MALLOC_TLSF=y
+CONFIG_KALLSYMS=y
+CONFIG_RELOCATABLE=y
+CONFIG_CONSOLE_ALLOW_COLOR=y
+CONFIG_PBL_CONSOLE=y
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile index 98f4c4e0194b..94b304d4878f 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -134,6 +134,7 @@ lwl-$(CONFIG_MACH_SOLIDRUN_CUBOX) += dove-cubox-bb.dtb.o
lwl-$(CONFIG_MACH_SOLIDRUN_MICROSOM) += imx6dl-hummingboard.dtb.o imx6q-hummingboard.dtb.o \
imx6dl-hummingboard2.dtb.o imx6q-hummingboard2.dtb.o \
imx6q-h100.dtb.o
+lwl-$(CONFIG_MACH_SPIDER_MK1_EVK) += spider-mk1-evk.dtb.o
lwl-$(CONFIG_MACH_SKOV_IMX6) += imx6s-skov-imx6.dtb.o imx6dl-skov-imx6.dtb.o imx6q-skov-imx6.dtb.o
lwl-$(CONFIG_MACH_SKOV_ARM9CPU) += at91-skov-arm9cpu.dtb.o
lwl-$(CONFIG_MACH_SEEED_ODYSSEY) += stm32mp157c-odyssey.dtb.o diff --git a/arch/arm/dts/spider-mk1-evk.dts b/arch/arm/dts/spider-mk1-evk.dts new file mode 100644 index 000000000000..b8081cb85bf8
--- /dev/null
+++ b/arch/arm/dts/spider-mk1-evk.dts
@@ -0,0 +1,10 @@
+// SPDX-License-Identifier: GPL-2.0 OR X11
+
+/dts-v1/;
+
+#include "spider-mk1.dtsi"
+
+/ {
+ model = "Pliops Spider MK-I EVK";
+ compatible = "pliops,spider-mk1-evk"; };
diff --git a/arch/arm/dts/spider-mk1.dtsi b/arch/arm/dts/spider-mk1.dtsi new file mode 100644 index 000000000000..d4613848169d
--- /dev/null
+++ b/arch/arm/dts/spider-mk1.dtsi
@@ -0,0 +1,46 @@
+// SPDX-License-Identifier: GPL-2.0 OR X11
+
+/ {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ chosen {
+ stdout-path = &uart0;
+ };
+
+ aliases {
+ serial0 = &uart0;
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu0: cpu@0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53";
+ reg = <0x0>;
+ };
+ };
+
+ memory@1000000 {
+ reg = <0x0 0x1000000 0x0 0x400000>; /* 128M */
+ device_type = "memory";
+ };
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ sram@c000000000 {
+ compatible = "mmio-sram";
+ reg = <0xc0 0x0 0x0 0x400000>;
+ };
+
+ uart0: serial@d000307000 {
+ compatible = "pliops,spider-uart";
+ reg = <0xd0 0x307000 0 0x1000>;
+ };
+ };
+};
diff --git a/arch/arm/mach-spider/Kconfig b/arch/arm/mach-spider/Kconfig new file mode 100644 index 000000000000..6d2f888a5fd8
--- /dev/null
+++ b/arch/arm/mach-spider/Kconfig
@@ -0,0 +1,16 @@
+# SPDX-License-Identifier: GPL-2.0-only
+
+if ARCH_SPIDER
+
+config ARCH_SPIDER_MK1
+ bool
+ select CPU_V8
+ help
+ The first Cortex-A53-based SoC of the spider family.
+ This symbol is invisble and select by boards
+
+config MACH_SPIDER_MK1_EVK
+ bool "Pliops Spider Reference Design Board"
+ select ARCH_SPIDER_MK1
+
+endif
diff --git a/arch/arm/mach-spider/Makefile b/arch/arm/mach-spider/Makefile new file mode 100644 index 000000000000..b08c4a93ca27
--- /dev/null
+++ b/arch/arm/mach-spider/Makefile
@@ -0,0 +1 @@
+lwl-y += lowlevel.o
diff --git a/arch/arm/mach-spider/lowlevel.c b/arch/arm/mach-spider/lowlevel.c new file mode 100644 index 000000000000..5d62ef0f39e5
--- /dev/null
+++ b/arch/arm/mach-spider/lowlevel.c
@@ -0,0 +1,14 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+#include <linux/types.h>
+#include <mach/spider/lowlevel.h>
+#include <asm/barebox-arm-head.h>
+
+void spider_lowlevel_init(void)
+{
+ arm_cpu_lowlevel_init();
+ /*
+ * not yet relocated, only do writel/readl for stuff that's
+ * critical to run early. No global variables allowed.
+ */
+}
diff --git a/images/Makefile b/images/Makefile index c93f9e268978..97521e713228 100644
--- a/images/Makefile
+++ b/images/Makefile
@@ -150,6 +150,7 @@ include $(srctree)/images/Makefile.mxs include $(srctree)/images/Makefile.omap3 include $(srctree)/images/Makefile.rockchip
include $(srctree)/images/Makefile.socfpga
+include $(srctree)/images/Makefile.spider
include $(srctree)/images/Makefile.stm32mp
include $(srctree)/images/Makefile.tegra include $(srctree)/images/Makefile.versatile
diff --git a/images/Makefile.spider b/images/Makefile.spider new file mode 100644 index 000000000000..c32f2762df04
--- /dev/null
+++ b/images/Makefile.spider
@@ -0,0 +1,5 @@
+# SPDX-License-Identifier: GPL-2.0-only
+
+pblb-$(CONFIG_MACH_SPIDER_MK1_EVK) += start_spider_mk1_evk
+FILE_barebox-spider-mk1-evk.img = start_spider_mk1_evk.pblb
+image-$(CONFIG_MACH_SPIDER_MK1_EVK) += barebox-spider-mk1-evk.img
diff --git a/include/mach/spider/lowlevel.h b/include/mach/spider/lowlevel.h new file mode 100644 index 000000000000..6e0ce1c77f7e
--- /dev/null
+++ b/include/mach/spider/lowlevel.h
@@ -0,0 +1,7 @@
+/* SPDX-License-Identifier: GPL-2.0+ */ #ifndef __MACH_SPIDER_H_
+#define __MACH_SPIDER_H_
+
+void spider_lowlevel_init(void);
+
+#endif
--
2.38.4
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [PATCH v2] Porting barebox to a new SoC
2023-05-29 13:34 ` Lior Weintraub
@ 2023-05-29 19:03 ` Ahmad Fatoum
2023-05-30 20:10 ` Lior Weintraub
0 siblings, 1 reply; 40+ messages in thread
From: Ahmad Fatoum @ 2023-05-29 19:03 UTC (permalink / raw)
To: Lior Weintraub, Ahmad Fatoum, barebox
Hello Lior,
On 29.05.23 15:34, Lior Weintraub wrote:
> Hi Ahmad,
>
> I have revised the addresses and used DRAM address @ 0 instead:
> #define UARTBASE (0xD000307000)
> #define DRAM_ADDR (0x00000000)
> #define MY_STACK_TOP (0x00000000 + SZ_2M) // Set the stack 2MB from DRAM start
Is DRAM configured by the time barebox runs? If not, you should keep stack top
in SRAM, until you have setup memory in prebootloader (PBL). Is the 4M SRAM
the only on-chip SRAM you have?
> static inline void spider_serial_putc(void *base, int c)
> {
> *((volatile unsigned *)base) = c;
There's a helper for that: writel(c, base); In barebox, it's equivalent
to the volatile access, but in Linux it involves a write memory barrier.
We try to write code in barebox, so it's easily reusable in Linux (and
the other way round).
> }
>
> I will try to test it on QEMU using an initial QEMU machine we made for Spider.
> In this machine we only have 3 memory regions and a PL011 UART:
> spider_soc_memories soc_memories[] = {
> {.name = "SPIDER_GPRAM", .add = 0xC000000000ULL, .size = 4 * MiB},
> {.name = "SPIDER_ROM", .add = 0xC004000000ULL, .size = 128 * KiB},
> {.name = "SPIDER_DRAM", .add = 0x0000000000ULL, .size = 1 * GiB},
> };
>
> This special QEMU machine can run our BL1 code from "ROM" address (we set the RVBAR to point there).
> So my idea is to test the barebox image by the following steps:
> 1. Modify the QEMU code to have a "ROM" with the size of 128M.
> 2. Compile our BL1 code to include the barebox.bin as a const array, copy it to "DRAM" @ address 0 and jump there.
Why not map QEMU -bios option to SRAM? (Or DRAM directly, if it needs no special setup from
barebox side).
> For this to work I wanted to understand how to call (i.e. what arguments to pass) to barebox.
barebox doesn't expect any arguments, because most BootROMs don't pass anything useful.
Some pass information about bootsource though, so that's why the ENTRY_FUNCTION has
r0, r1 and r2 as parameters, but you need not use them.
> So I checked the barebox.map and found the function "start" on address 0.
You may know that Linux on some platforms comes with a decompressor that is glued to the
front of the kernel image and extracts the compressed kernel image. barebox has the same
concept. The prebootloader is uncompressed and runs (starting from ENTRY_FUNCTION) and
then does some early setup (e.g. enable clocks, configure PMIC, setup DRAM, load secure
monitor (BL31), ...etc.) and then it decompresses barebox proper into DRAM.
barebox.bin <- barebox proper. You don't usually need that.
barebox.elf <- ELF binary for the above (for gdb)
barebox.map <- map file of the above
images/barebox-spider-mk1-evk.img <- complete barebox image (PBL + barebox proper)
images/start_spider_mk1_evk.pbl <- ELF image for the above
images/start_spider_mk1_evk.pbl.map <- map file of the above
If you want to follow barbeox from the start, begin at start_spider_mk1_evk.
> Then I went to arch/arm/cpu/start.c and realized that the code is compiled with CONFIG_PBL_IMAGE.
> In that case I assume I need to pass 3 arguments and use this function prototype:
> void start(unsigned long membase, unsigned long memsize, void *boarddata);
barebox prebootloader takes care of this, so you don't need to do anything.
> Few questions:
> 1. Will that call work:
> typedef void (*barebox_start)(unsigned long , unsigned long , void *);
> #define DRAM_START (0)
> barebox_start p_barebox = (barebox_start)DRAM_START;
> p_barebox(DRAM_START, DRAM_START+SZ_2M, (void *)(DRAM_START+SZ_4M));
> This assumes that my BL1 code also copied the device tree (barebox-dt-2nd.img? start_dt_2nd.pblb? start_spider_mk1_evk.pblb?)
The device tree is built into the PBL and passed to barebox proper. This
allows us to use the same barebox proper binary and link it with a different
prebootloader for each SoC/board, all in the same build.
barebox-dt-2nd.img is a special image that looks exactly like a Linux kernel:
images/barebox-dt-2nd.img: Linux kernel ARM64 boot executable Image, little-endian, 4K pages
and can thus be used for booting for easy chainloading from other bootloaders or for running
with QEMU -kernel. You shouldn't need it right now.
> 2. Do I want to have my code compiled with CONFIG_PBL_IMAGE?
> If I understand correctly, it means that my code will provide a PBL (a.k.a BL2) which will set the DRAM and STACK among other things (MMU?).
The patch I sent already builds a PBL. You will need to fill out start_spider_mk1_evk
to do all the other early initialization you need. Then you call barebox_arm_entry
with device tree and memory size and it will take care to do stack setup in new
memory region, MMU setup (if enabled) and chainloading barebox proper.
Note that PBL isn't necessary BL2. You can chainload barebox from within barebox (i.e.
in EL2 or EL1), which is useful for debugging. You will thus often find PBL code that
does
if (current_el() == 3) {
/* Do BL2 setup */
chainload();
__builtin_unreachable();
}
barebox_arm_entry(...)
See for example arch/arm/boards/innocomm-imx8mm-wb15/lowlevel.c
to see a real-world example of another Cortex-A53.
> In that case I assume it is OK.
> 3. If I try to remove it by having CONFIG_PBL_IMAGE=n on spider_defconfig this doesn't do anything
> The build (make spider_defconfig) ignores it and say that " No change to .config ".
Another symbol forces it to be enabled. If you are curious, run make menuconfig
and then search (/) for the symbol and it will list, whether it's enabled and why:
Selected by [y]:
- PBL_MULTI_IMAGES [=y] && HAVE_PBL_MULTI_IMAGES [=y]
I'd suggest you avoid modifying the .config file manually. always use menuconfig.
> 4. I also tried to understand how to implement PUTC_LL but not sure I understand.
> 4.1 When I set "CONFIG_DEBUG_LL=y" on spider_defconfig it is again not written to .config and I get " No change to .config " message.
You must:
- select HAS_DEBUG_LL from MACH_SPIDER
- Add your arch to arch/arm/include/asm/debug_ll.h
- Then implement PUTC_LL in e.g. mach/spider/debug_ll.h
> 4.2 Do I need to have my own debug_ll.h file?
Yes. See above.
> 5. When I make changes to spider_defconfig and try to regenerate the .config and I get " No change to .config " message, does it mean that those macros are "hidden" symbols like you said about the CONFIG_CPU_V8?
Yes. Just check menuconfig to see how symbols relate to each other.
This is 1:1 like it's in Linux, so it'll come in handy when you do
the kernel port too ;)
> Apologize for so many questions :-)
No problem. Looking forward to your patches ;)
Cheers,
Ahmad
> Cheers,
> Lior.
>
> -----Original Message-----
> From: Lior Weintraub
> Sent: Sunday, May 28, 2023 11:16 PM
> To: Ahmad Fatoum <ahmad@a3f.at>; barebox@lists.infradead.org
> Subject: RE: [PATCH v2] Porting barebox to a new SoC
>
> Hi Ahmad,
>
> Thank you so much for your kind support!
>
> Indeed we also have a 16GB DRAM that starts from address 0 (though currently we don't have the controller settings (under development)).
>
> I also wrote the BootROM (BL1) for this SoC (128KB ROM @ address 0xC004000000).
> I understand now that it would be best for me to develop BL2 that will run from our SRAM.
>
> As this BL2 code is bare-metal I have no problem or limitations with the 40 bit addresses.
> The BL2 code will initialize the DRAM controller and then copy Barebox image from NOR Flash to address 0 of the DRAM.
> Our NOR Flash is 128MB in size and it is accessed via QSPI controller.
>
> I tried applying your suggested patch but got an error while doing so:
> $git apply 0002-Ahmad.patch
> 0002-Ahmad.patch:115: trailing whitespace.
> .of_compatible = spider_board_of_match, };
> error: corrupt patch at line 117
>
> After some digging I found that my Outlook probably messed with the patch format (even though I am using text only and no HTML format).
> When I went to the web and copied the patch from there (mailing list archive) it was working well (i.e. no compilation error).
>
> Cheers,
> Lior.
>
> -----Original Message-----
> From: Ahmad Fatoum <ahmad@a3f.at>
> Sent: Sunday, May 28, 2023 6:38 PM
> To: barebox@lists.infradead.org
> Cc: Lior Weintraub <liorw@pliops.com>
> Subject: [PATCH v2] Porting barebox to a new SoC
>
> CAUTION: External Sender
>
> From: Lior Weintraub <liorw@pliops.com>
>
> Hi,
>
> I tried to follow the porting guide on https://ddec1-0-en-ctp.trendmicro.com:443/wis/clicktime/v1/query?url=https%3a%2f%2fwww.barebox.org%2fdoc%2flatest%2fdevel%2fporting.html%23&umid=60097eda-f136-45a1-9c8e-cf6a76e45cf8&auth=860a7ebb9feba264acc79b6e38eb59582349362c-480ae23736add41c88ab8d30c090a75517ca7f9e but couldn't follow the instructions.
> I would like to port barebox to a new SoC (which is not a derivative of any known SoC).
> It has the following:
> * Single Cortex A53
> * SRAM (4MB) located on address 0xC000000000
>
> The below patch shows my initial test to try and have a starting point.
> I am setting env variables:
> export ARCH=arm64
> export CROSS_COMPILE=/home/pliops/workspace/ARM/arm-gnu-toolchain/bin/aarch64-none-elf-
>
> Then I build with:
> make spider_defconfig && make
>
> This gives an error:
> aarch64-none-elf-gcc: error: unrecognized argument in option '-mabi=apcs-gnu'
> aarch64-none-elf-gcc: note: valid arguments to '-mabi=' are: ilp32 lp64
> aarch64-none-elf-gcc: error: unrecognized command-line option '-msoft-float'
> aarch64-none-elf-gcc: error: unrecognized command-line option '-mno-unaligned-access'
> /home/pliops/workspace/simplest-linux-demo/barebox/scripts/Makefile.build:140: recipe for target 'scripts/mod/empty.o' failed
> make[2]: *** [scripts/mod/empty.o] Error 1
>
> Not sure why the compiler flags get -mabi=apcs-gnu when I explicitly set CONFIG_CPU_V8 and the arch/arm/Makefile has:
> ifeq ($(CONFIG_CPU_V8), y)
> CFLAGS_ABI :=-mabi=lp64
>
> The changes I did:
>>From 848b5f9b18bb1bb96d197cbc1b368ee0a729d581 Mon Sep 17 00:00:00 2001
> ---
> arch/arm/Kconfig | 13 ++++++++
> arch/arm/Makefile | 1 +
> arch/arm/boards/Makefile | 1 +
> arch/arm/boards/spider-evk/Makefile | 4 +++
> arch/arm/boards/spider-evk/board.c | 26 +++++++++++++++
> arch/arm/boards/spider-evk/lowlevel.c | 30 +++++++++++++++++
> arch/arm/configs/spider_defconfig | 8 +++++
> arch/arm/dts/Makefile | 1 +
> arch/arm/dts/spider-mk1-evk.dts | 10 ++++++
> arch/arm/dts/spider-mk1.dtsi | 46 +++++++++++++++++++++++++++
> arch/arm/mach-spider/Kconfig | 16 ++++++++++
> arch/arm/mach-spider/Makefile | 1 +
> arch/arm/mach-spider/lowlevel.c | 14 ++++++++
> images/Makefile | 1 +
> images/Makefile.spider | 5 +++
> include/mach/spider/lowlevel.h | 7 ++++
> 16 files changed, 184 insertions(+)
> create mode 100644 arch/arm/boards/spider-evk/Makefile
> create mode 100644 arch/arm/boards/spider-evk/board.c
> create mode 100644 arch/arm/boards/spider-evk/lowlevel.c
> create mode 100644 arch/arm/configs/spider_defconfig create mode 100644 arch/arm/dts/spider-mk1-evk.dts create mode 100644 arch/arm/dts/spider-mk1.dtsi create mode 100644 arch/arm/mach-spider/Kconfig create mode 100644 arch/arm/mach-spider/Makefile create mode 100644 arch/arm/mach-spider/lowlevel.c create mode 100644 images/Makefile.spider create mode 100644 include/mach/spider/lowlevel.h
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index e76ee0f6dfe1..e5dcf128447e 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -255,6 +255,18 @@ config ARCH_ROCKCHIP
> select HAS_DEBUG_LL
> imply GPIO_ROCKCHIP
>
> +config ARCH_SPIDER
> + bool "Pliops Spider based"
> + depends on 64BIT
> + depends on ARCH_MULTIARCH
> + select GPIOLIB
> + select HAVE_PBL_MULTI_IMAGES
> + select COMMON_CLK
> + select CLKDEV_LOOKUP
> + select COMMON_CLK_OF_PROVIDER
> + select OFTREE
> + select OFDEVICE
> +
> config ARCH_STM32MP
> bool "STMicroelectronics STM32MP"
> depends on 32BIT
> @@ -331,6 +343,7 @@ source "arch/arm/mach-omap/Kconfig"
> source "arch/arm/mach-pxa/Kconfig"
> source "arch/arm/mach-rockchip/Kconfig"
> source "arch/arm/mach-socfpga/Kconfig"
> +source "arch/arm/mach-spider/Kconfig"
> source "arch/arm/mach-stm32mp/Kconfig"
> source "arch/arm/mach-versatile/Kconfig"
> source "arch/arm/mach-vexpress/Kconfig"
> diff --git a/arch/arm/Makefile b/arch/arm/Makefile index 35ebc70f44e2..4c63dfee48f4 100644
> --- a/arch/arm/Makefile
> +++ b/arch/arm/Makefile
> @@ -101,6 +101,7 @@ machine-$(CONFIG_ARCH_MXS) += mxs
> machine-$(CONFIG_ARCH_MVEBU) += mvebu
> machine-$(CONFIG_ARCH_NOMADIK) += nomadik
> machine-$(CONFIG_ARCH_OMAP) += omap
> +machine-$(CONFIG_ARCH_SPIDER) += spider
> machine-$(CONFIG_ARCH_PXA) += pxa
> machine-$(CONFIG_ARCH_ROCKCHIP) += rockchip
> machine-$(CONFIG_ARCH_SAMSUNG) += samsung
> diff --git a/arch/arm/boards/Makefile b/arch/arm/boards/Makefile index 2877debad535..6fe0a90c81ea 100644
> --- a/arch/arm/boards/Makefile
> +++ b/arch/arm/boards/Makefile
> @@ -135,6 +135,7 @@ obj-$(CONFIG_MACH_SOCFPGA_TERASIC_DE10_NANO) += terasic-de10-nano/
> obj-$(CONFIG_MACH_SOCFPGA_TERASIC_SOCKIT) += terasic-sockit/
> obj-$(CONFIG_MACH_SOLIDRUN_CUBOX) += solidrun-cubox/
> obj-$(CONFIG_MACH_SOLIDRUN_MICROSOM) += solidrun-microsom/
> +obj-$(CONFIG_MACH_SPIDER_MK1_EVK) += spider-evk/
> obj-$(CONFIG_MACH_STM32MP15XX_DKX) += stm32mp15xx-dkx/
> obj-$(CONFIG_MACH_STM32MP13XX_DK) += stm32mp13xx-dk/
> obj-$(CONFIG_MACH_LXA_MC1) += lxa-mc1/
> diff --git a/arch/arm/boards/spider-evk/Makefile b/arch/arm/boards/spider-evk/Makefile
> new file mode 100644
> index 000000000000..da63d2625f7a
> --- /dev/null
> +++ b/arch/arm/boards/spider-evk/Makefile
> @@ -0,0 +1,4 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +
> +obj-y += board.o
> +lwl-y += lowlevel.o
> diff --git a/arch/arm/boards/spider-evk/board.c b/arch/arm/boards/spider-evk/board.c
> new file mode 100644
> index 000000000000..3920e83b457d
> --- /dev/null
> +++ b/arch/arm/boards/spider-evk/board.c
> @@ -0,0 +1,26 @@
> +#include <bbu.h>
> +#include <boot.h>
> +#include <bootm.h>
> +#include <common.h>
> +#include <deep-probe.h>
> +#include <environment.h>
> +#include <fcntl.h>
> +#include <globalvar.h>
> +
> +static int spider_board_probe(struct device *dev) {
> + /* Do some board-specific setup */
> + return 0;
> +}
> +
> +static const struct of_device_id spider_board_of_match[] = {
> + { .compatible = "pliops,spider-mk1-evk" },
> + { /* sentinel */ },
> +};
> +
> +static struct driver spider_board_driver = {
> + .name = "board-spider",
> + .probe = spider_board_probe,
> + .of_compatible = spider_board_of_match, };
> +device_platform_driver(spider_board_driver);
> diff --git a/arch/arm/boards/spider-evk/lowlevel.c b/arch/arm/boards/spider-evk/lowlevel.c
> new file mode 100644
> index 000000000000..e36fcde4208e
> --- /dev/null
> +++ b/arch/arm/boards/spider-evk/lowlevel.c
> @@ -0,0 +1,30 @@
> +#include <common.h>
> +#include <asm/barebox-arm.h>
> +#include <mach/spider/lowlevel.h>
> +
> +#define BASE_ADDR (0xD000307000)
> +#define GPRAM_ADDR (0xC000000000)
> +#define MY_STACK_TOP (0xC000000000 + SZ_2M) // Set the stack 2MB from GPRAM start (excatly in the middle)
> +static inline void spider_serial_putc(void *base, int c) {
> +// if (!(readl(base + UCR1) & UCR1_UARTEN))
> +// return;
> +//
> +// while (!(readl(base + USR2) & USR2_TXDC));
> +//
> +// writel(c, base + URTX0);
> +}
> +
> +ENTRY_FUNCTION_WITHSTACK(start_spider_mk1_evk, MY_STACK_TOP, r0, r1,
> +r2) {
> + extern char __dtb_spider_mk1_evk_start[];
> +
> + spider_lowlevel_init();
> +
> + relocate_to_current_adr();
> + setup_c();
> +
> + pbl_set_putc(spider_serial_putc, (void *)BASE_ADDR);
> +
> + barebox_arm_entry(GPRAM_ADDR, SZ_2M,
> +__dtb_spider_mk1_evk_start); }
> diff --git a/arch/arm/configs/spider_defconfig b/arch/arm/configs/spider_defconfig
> new file mode 100644
> index 000000000000..c91bb889d97f
> --- /dev/null
> +++ b/arch/arm/configs/spider_defconfig
> @@ -0,0 +1,8 @@
> +CONFIG_ARCH_SPIDER=y
> +CONFIG_MACH_SPIDER_MK1_EVK=y
> +CONFIG_BOARD_ARM_GENERIC_DT=y
> +CONFIG_MALLOC_TLSF=y
> +CONFIG_KALLSYMS=y
> +CONFIG_RELOCATABLE=y
> +CONFIG_CONSOLE_ALLOW_COLOR=y
> +CONFIG_PBL_CONSOLE=y
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile index 98f4c4e0194b..94b304d4878f 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -134,6 +134,7 @@ lwl-$(CONFIG_MACH_SOLIDRUN_CUBOX) += dove-cubox-bb.dtb.o
> lwl-$(CONFIG_MACH_SOLIDRUN_MICROSOM) += imx6dl-hummingboard.dtb.o imx6q-hummingboard.dtb.o \
> imx6dl-hummingboard2.dtb.o imx6q-hummingboard2.dtb.o \
> imx6q-h100.dtb.o
> +lwl-$(CONFIG_MACH_SPIDER_MK1_EVK) += spider-mk1-evk.dtb.o
> lwl-$(CONFIG_MACH_SKOV_IMX6) += imx6s-skov-imx6.dtb.o imx6dl-skov-imx6.dtb.o imx6q-skov-imx6.dtb.o
> lwl-$(CONFIG_MACH_SKOV_ARM9CPU) += at91-skov-arm9cpu.dtb.o
> lwl-$(CONFIG_MACH_SEEED_ODYSSEY) += stm32mp157c-odyssey.dtb.o diff --git a/arch/arm/dts/spider-mk1-evk.dts b/arch/arm/dts/spider-mk1-evk.dts new file mode 100644 index 000000000000..b8081cb85bf8
> --- /dev/null
> +++ b/arch/arm/dts/spider-mk1-evk.dts
> @@ -0,0 +1,10 @@
> +// SPDX-License-Identifier: GPL-2.0 OR X11
> +
> +/dts-v1/;
> +
> +#include "spider-mk1.dtsi"
> +
> +/ {
> + model = "Pliops Spider MK-I EVK";
> + compatible = "pliops,spider-mk1-evk"; };
> diff --git a/arch/arm/dts/spider-mk1.dtsi b/arch/arm/dts/spider-mk1.dtsi new file mode 100644 index 000000000000..d4613848169d
> --- /dev/null
> +++ b/arch/arm/dts/spider-mk1.dtsi
> @@ -0,0 +1,46 @@
> +// SPDX-License-Identifier: GPL-2.0 OR X11
> +
> +/ {
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + chosen {
> + stdout-path = &uart0;
> + };
> +
> + aliases {
> + serial0 = &uart0;
> + };
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + cpu0: cpu@0 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a53";
> + reg = <0x0>;
> + };
> + };
> +
> + memory@1000000 {
> + reg = <0x0 0x1000000 0x0 0x400000>; /* 128M */
> + device_type = "memory";
> + };
> +
> + soc {
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
> +
> + sram@c000000000 {
> + compatible = "mmio-sram";
> + reg = <0xc0 0x0 0x0 0x400000>;
> + };
> +
> + uart0: serial@d000307000 {
> + compatible = "pliops,spider-uart";
> + reg = <0xd0 0x307000 0 0x1000>;
> + };
> + };
> +};
> diff --git a/arch/arm/mach-spider/Kconfig b/arch/arm/mach-spider/Kconfig new file mode 100644 index 000000000000..6d2f888a5fd8
> --- /dev/null
> +++ b/arch/arm/mach-spider/Kconfig
> @@ -0,0 +1,16 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +
> +if ARCH_SPIDER
> +
> +config ARCH_SPIDER_MK1
> + bool
> + select CPU_V8
> + help
> + The first Cortex-A53-based SoC of the spider family.
> + This symbol is invisble and select by boards
> +
> +config MACH_SPIDER_MK1_EVK
> + bool "Pliops Spider Reference Design Board"
> + select ARCH_SPIDER_MK1
> +
> +endif
> diff --git a/arch/arm/mach-spider/Makefile b/arch/arm/mach-spider/Makefile new file mode 100644 index 000000000000..b08c4a93ca27
> --- /dev/null
> +++ b/arch/arm/mach-spider/Makefile
> @@ -0,0 +1 @@
> +lwl-y += lowlevel.o
> diff --git a/arch/arm/mach-spider/lowlevel.c b/arch/arm/mach-spider/lowlevel.c new file mode 100644 index 000000000000..5d62ef0f39e5
> --- /dev/null
> +++ b/arch/arm/mach-spider/lowlevel.c
> @@ -0,0 +1,14 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +
> +#include <linux/types.h>
> +#include <mach/spider/lowlevel.h>
> +#include <asm/barebox-arm-head.h>
> +
> +void spider_lowlevel_init(void)
> +{
> + arm_cpu_lowlevel_init();
> + /*
> + * not yet relocated, only do writel/readl for stuff that's
> + * critical to run early. No global variables allowed.
> + */
> +}
> diff --git a/images/Makefile b/images/Makefile index c93f9e268978..97521e713228 100644
> --- a/images/Makefile
> +++ b/images/Makefile
> @@ -150,6 +150,7 @@ include $(srctree)/images/Makefile.mxs include $(srctree)/images/Makefile.omap3 include $(srctree)/images/Makefile.rockchip
> include $(srctree)/images/Makefile.socfpga
> +include $(srctree)/images/Makefile.spider
> include $(srctree)/images/Makefile.stm32mp
> include $(srctree)/images/Makefile.tegra include $(srctree)/images/Makefile.versatile
> diff --git a/images/Makefile.spider b/images/Makefile.spider new file mode 100644 index 000000000000..c32f2762df04
> --- /dev/null
> +++ b/images/Makefile.spider
> @@ -0,0 +1,5 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +
> +pblb-$(CONFIG_MACH_SPIDER_MK1_EVK) += start_spider_mk1_evk
> +FILE_barebox-spider-mk1-evk.img = start_spider_mk1_evk.pblb
> +image-$(CONFIG_MACH_SPIDER_MK1_EVK) += barebox-spider-mk1-evk.img
> diff --git a/include/mach/spider/lowlevel.h b/include/mach/spider/lowlevel.h new file mode 100644 index 000000000000..6e0ce1c77f7e
> --- /dev/null
> +++ b/include/mach/spider/lowlevel.h
> @@ -0,0 +1,7 @@
> +/* SPDX-License-Identifier: GPL-2.0+ */ #ifndef __MACH_SPIDER_H_
> +#define __MACH_SPIDER_H_
> +
> +void spider_lowlevel_init(void);
> +
> +#endif
> --
> 2.38.4
>
>
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply [flat|nested] 40+ messages in thread
* RE: [PATCH v2] Porting barebox to a new SoC
2023-05-29 19:03 ` Ahmad Fatoum
@ 2023-05-30 20:10 ` Lior Weintraub
2023-05-31 6:10 ` Ahmad Fatoum
0 siblings, 1 reply; 40+ messages in thread
From: Lior Weintraub @ 2023-05-30 20:10 UTC (permalink / raw)
To: Ahmad Fatoum, Ahmad Fatoum, barebox
Hello Ahmad,
Thanks again for your kind support!
Your comments helped me progress and the current situation is as follows:
Our QEMU Spider machine is running a BL1.elf file using the following command:
QEMU_AUDIO_DRV=none qemu-system-aarch64 -M spider-soc -smp 1 -m 128M -nographic \
-device loader,file=BL1.elf -cpu cortex-a53,rvbar=0xC004000000 \
-d unimp -semihosting-config enable=on,target=native \
-monitor telnet:localhost:1235,server,nowait \
-gdb tcp::1236
The BL1.elf is our BootROM application that runs from ROM address 0xC004000000.
Just for debugging purpose we've increased the ROM size so it can include the images/barebox-spider-mk1-evk.img (as a const array).
BL1 then copy it (using memcpy) to address 0 and jumps there for execution.
On the real ASIC this address will be the DRAM and indeed will need to be initialized before the copy but here on QEMU it is not required.
The lowlevel.c of spider-evk was modified to use DRAM_ADDR 0x400000 (4MB from start) and MY_STACK_TOP was set to 0x8000000 (128M).
In addition, I implemented putc_ll (currently hard-coded in include/debug_ll.h) and opened log level to VERBOSE_DEBUG (currently just hard-coded in printk.h).
I see the following (which makes sense) logs on QEMU terminal:
uncompress.c: memory at 0x00400000, size 0x00200000
uncompress.c: uncompressing barebox binary at 0x0000000000002200 (size 0x0001d3b2) to 0x00400000 (uncompressed size: 0x000373d0)
I then connect with aarch64-none-elf-gdb, load the barebox symbols (to 0x400000) and check the current execution state (program counter and stack).
Looks like the code is stuck on function register_autoboot_vars:
sp 0x5f7e60 0x5f7e60
pc 0x401264 0x401264 <register_autoboot_vars+24>
Few observations:
1. The PBL was using stack top located on 0x8000000 (which is MY_STACK_TOP). Found it be causing a breakpoint on the PBL.
2. Barebox uses a stack top on 0x600000 which is probably calculated from my new DRAM_ADDR and SZ_2M given to the function call:
barebox_arm_entry(DRAM_ADDR, SZ_2M, __dtb_spider_mk1_evk_start);
This is great! I am starting to find my way.
When the barebox execution didn't print anything to the terminal I remembered that we used a place holder on the dtsi for the uart.
So now I changed it to:
uart0: serial@d000307000 {
compatible = "arm,pl011", "arm,primecell";
reg = <0xd0 0x307000 0 0x1000>;
}
(Our QEMU UART is currently using pl011 device.)
After some time (trying to debug by enabling MMU but then reverted the code back), I got to a point that when I try to run again I am getting an exception.
I can swear all code changes were reverted back to the point where I saw the barebox stuck on register_autoboot_vars but now it just cases an exception.
The exception vector code is located on our ROM (part of BL1 code) and the logs shows that the link register has the value 0x401218 which suggest the following code:
0000000000001200 <load_environment>:
1200: a9be7bfd stp x29, x30, [sp, #-32]!
1204: 910003fd mov x29, sp
1208: a90153f3 stp x19, x20, [sp, #16]
120c: 94000a07 bl 3a28 <default_environment_path_get>
1210: d00000f3 adrp x19, 1f000 <do_cpuinfo+0x1f0>
1214: 912a7273 add x19, x19, #0xa9c
1218: aa0003f4 mov x20, x0
Any ideas or suggestions how to proceed with the debugging?
BTW, to answer your questions:
The SRAM of 4MB is the only one we have because we assumed it is only for BootROM to load a PBL
Thank you very much,
Cheers,
Lior.
> -----Original Message-----
> From: Ahmad Fatoum <a.fatoum@pengutronix.de>
> Sent: Monday, May 29, 2023 10:03 PM
> To: Lior Weintraub <liorw@pliops.com>; Ahmad Fatoum <ahmad@a3f.at>;
> barebox@lists.infradead.org
> Subject: Re: [PATCH v2] Porting barebox to a new SoC
>
> CAUTION: External Sender
>
> Hello Lior,
>
> On 29.05.23 15:34, Lior Weintraub wrote:
> > Hi Ahmad,
> >
> > I have revised the addresses and used DRAM address @ 0 instead:
> > #define UARTBASE (0xD000307000)
> > #define DRAM_ADDR (0x00000000)
> > #define MY_STACK_TOP (0x00000000 + SZ_2M) // Set the stack 2MB from
> DRAM start
>
> Is DRAM configured by the time barebox runs? If not, you should keep stack
> top
> in SRAM, until you have setup memory in prebootloader (PBL). Is the 4M
> SRAM
> the only on-chip SRAM you have?
>
> > static inline void spider_serial_putc(void *base, int c)
> > {
> > *((volatile unsigned *)base) = c;
>
> There's a helper for that: writel(c, base); In barebox, it's equivalent
> to the volatile access, but in Linux it involves a write memory barrier.
> We try to write code in barebox, so it's easily reusable in Linux (and
> the other way round).
>
> > }
> >
> > I will try to test it on QEMU using an initial QEMU machine we made for
> Spider.
> > In this machine we only have 3 memory regions and a PL011 UART:
> > spider_soc_memories soc_memories[] = {
> > {.name = "SPIDER_GPRAM", .add = 0xC000000000ULL, .size = 4 * MiB},
> > {.name = "SPIDER_ROM", .add = 0xC004000000ULL, .size = 128 * KiB},
> > {.name = "SPIDER_DRAM", .add = 0x0000000000ULL, .size = 1 * GiB},
> > };
> >
> > This special QEMU machine can run our BL1 code from "ROM" address (we
> set the RVBAR to point there).
> > So my idea is to test the barebox image by the following steps:
> > 1. Modify the QEMU code to have a "ROM" with the size of 128M.
> > 2. Compile our BL1 code to include the barebox.bin as a const array, copy it
> to "DRAM" @ address 0 and jump there.
>
> Why not map QEMU -bios option to SRAM? (Or DRAM directly, if it needs no
> special setup from
> barebox side).
>
> > For this to work I wanted to understand how to call (i.e. what arguments to
> pass) to barebox.
>
> barebox doesn't expect any arguments, because most BootROMs don't pass
> anything useful.
> Some pass information about bootsource though, so that's why the
> ENTRY_FUNCTION has
> r0, r1 and r2 as parameters, but you need not use them.
>
> > So I checked the barebox.map and found the function "start" on address 0.
>
> You may know that Linux on some platforms comes with a decompressor that
> is glued to the
> front of the kernel image and extracts the compressed kernel image. barebox
> has the same
> concept. The prebootloader is uncompressed and runs (starting from
> ENTRY_FUNCTION) and
> then does some early setup (e.g. enable clocks, configure PMIC, setup DRAM,
> load secure
> monitor (BL31), ...etc.) and then it decompresses barebox proper into DRAM.
>
> barebox.bin <- barebox proper. You don't usually need that.
> barebox.elf <- ELF binary for the above (for gdb)
> barebox.map <- map file of the above
>
> images/barebox-spider-mk1-evk.img <- complete barebox image (PBL +
> barebox proper)
> images/start_spider_mk1_evk.pbl <- ELF image for the above
> images/start_spider_mk1_evk.pbl.map <- map file of the above
>
> If you want to follow barbeox from the start, begin at start_spider_mk1_evk.
>
> > Then I went to arch/arm/cpu/start.c and realized that the code is compiled
> with CONFIG_PBL_IMAGE.
> > In that case I assume I need to pass 3 arguments and use this function
> prototype:
> > void start(unsigned long membase, unsigned long memsize, void
> *boarddata);
>
> barebox prebootloader takes care of this, so you don't need to do anything.
>
> > Few questions:
> > 1. Will that call work:
> > typedef void (*barebox_start)(unsigned long , unsigned long , void *);
> > #define DRAM_START (0)
> > barebox_start p_barebox = (barebox_start)DRAM_START;
> > p_barebox(DRAM_START, DRAM_START+SZ_2M, (void
> *)(DRAM_START+SZ_4M));
> > This assumes that my BL1 code also copied the device tree (barebox-dt-
> 2nd.img? start_dt_2nd.pblb? start_spider_mk1_evk.pblb?)
>
> The device tree is built into the PBL and passed to barebox proper. This
> allows us to use the same barebox proper binary and link it with a different
> prebootloader for each SoC/board, all in the same build.
>
> barebox-dt-2nd.img is a special image that looks exactly like a Linux kernel:
>
> images/barebox-dt-2nd.img: Linux kernel ARM64 boot executable Image,
> little-endian, 4K pages
>
> and can thus be used for booting for easy chainloading from other
> bootloaders or for running
> with QEMU -kernel. You shouldn't need it right now.
>
> > 2. Do I want to have my code compiled with CONFIG_PBL_IMAGE?
> > If I understand correctly, it means that my code will provide a PBL (a.k.a
> BL2) which will set the DRAM and STACK among other things (MMU?).
>
> The patch I sent already builds a PBL. You will need to fill out
> start_spider_mk1_evk
> to do all the other early initialization you need. Then you call
> barebox_arm_entry
> with device tree and memory size and it will take care to do stack setup in new
> memory region, MMU setup (if enabled) and chainloading barebox proper.
>
> Note that PBL isn't necessary BL2. You can chainload barebox from within
> barebox (i.e.
> in EL2 or EL1), which is useful for debugging. You will thus often find PBL code
> that
> does
>
> if (current_el() == 3) {
> /* Do BL2 setup */
> chainload();
> __builtin_unreachable();
> }
>
> barebox_arm_entry(...)
>
> See for example arch/arm/boards/innocomm-imx8mm-wb15/lowlevel.c
>
> to see a real-world example of another Cortex-A53.
>
> > In that case I assume it is OK.
> > 3. If I try to remove it by having CONFIG_PBL_IMAGE=n on spider_defconfig
> this doesn't do anything
> > The build (make spider_defconfig) ignores it and say that " No change to
> .config ".
>
> Another symbol forces it to be enabled. If you are curious, run make
> menuconfig
> and then search (/) for the symbol and it will list, whether it's enabled and
> why:
>
> Selected by [y]:
> - PBL_MULTI_IMAGES [=y] && HAVE_PBL_MULTI_IMAGES [=y]
>
> I'd suggest you avoid modifying the .config file manually. always use
> menuconfig.
>
> > 4. I also tried to understand how to implement PUTC_LL but not sure I
> understand.
> > 4.1 When I set "CONFIG_DEBUG_LL=y" on spider_defconfig it is again not
> written to .config and I get " No change to .config " message.
>
> You must:
>
> - select HAS_DEBUG_LL from MACH_SPIDER
> - Add your arch to arch/arm/include/asm/debug_ll.h
> - Then implement PUTC_LL in e.g. mach/spider/debug_ll.h
>
> > 4.2 Do I need to have my own debug_ll.h file?
>
> Yes. See above.
>
> > 5. When I make changes to spider_defconfig and try to regenerate the
> .config and I get " No change to .config " message, does it mean that those
> macros are "hidden" symbols like you said about the CONFIG_CPU_V8?
>
> Yes. Just check menuconfig to see how symbols relate to each other.
> This is 1:1 like it's in Linux, so it'll come in handy when you do
> the kernel port too ;)
>
> > Apologize for so many questions :-)
>
> No problem. Looking forward to your patches ;)
>
>
> Cheers,
> Ahmad
>
> > Cheers,
> > Lior.
> >
> > -----Original Message-----
> > From: Lior Weintraub
> > Sent: Sunday, May 28, 2023 11:16 PM
> > To: Ahmad Fatoum <ahmad@a3f.at>; barebox@lists.infradead.org
> > Subject: RE: [PATCH v2] Porting barebox to a new SoC
> >
> > Hi Ahmad,
> >
> > Thank you so much for your kind support!
> >
> > Indeed we also have a 16GB DRAM that starts from address 0 (though
> currently we don't have the controller settings (under development)).
> >
> > I also wrote the BootROM (BL1) for this SoC (128KB ROM @ address
> 0xC004000000).
> > I understand now that it would be best for me to develop BL2 that will run
> from our SRAM.
> >
> > As this BL2 code is bare-metal I have no problem or limitations with the 40
> bit addresses.
> > The BL2 code will initialize the DRAM controller and then copy Barebox image
> from NOR Flash to address 0 of the DRAM.
> > Our NOR Flash is 128MB in size and it is accessed via QSPI controller.
> >
> > I tried applying your suggested patch but got an error while doing so:
> > $git apply 0002-Ahmad.patch
> > 0002-Ahmad.patch:115: trailing whitespace.
> > .of_compatible = spider_board_of_match, };
> > error: corrupt patch at line 117
> >
> > After some digging I found that my Outlook probably messed with the patch
> format (even though I am using text only and no HTML format).
> > When I went to the web and copied the patch from there (mailing list
> archive) it was working well (i.e. no compilation error).
> >
> > Cheers,
> > Lior.
> >
> > -----Original Message-----
> > From: Ahmad Fatoum <ahmad@a3f.at>
> > Sent: Sunday, May 28, 2023 6:38 PM
> > To: barebox@lists.infradead.org
> > Cc: Lior Weintraub <liorw@pliops.com>
> > Subject: [PATCH v2] Porting barebox to a new SoC
> >
> > CAUTION: External Sender
> >
> > From: Lior Weintraub <liorw@pliops.com>
> >
> > Hi,
> >
> > I tried to follow the porting guide on https://ddec1-0-en-
> ctp.trendmicro.com:443/wis/clicktime/v1/query?url=https%3a%2f%2fwww.
> barebox.org%2fdoc%2flatest%2fdevel%2fporting.html%23&umid=60097eda
> -f136-45a1-9c8e-
> cf6a76e45cf8&auth=860a7ebb9feba264acc79b6e38eb59582349362c-
> 480ae23736add41c88ab8d30c090a75517ca7f9e but couldn't follow the
> instructions.
> > I would like to port barebox to a new SoC (which is not a derivative of any
> known SoC).
> > It has the following:
> > * Single Cortex A53
> > * SRAM (4MB) located on address 0xC000000000
> >
> > The below patch shows my initial test to try and have a starting point.
> > I am setting env variables:
> > export ARCH=arm64
> > export CROSS_COMPILE=/home/pliops/workspace/ARM/arm-gnu-
> toolchain/bin/aarch64-none-elf-
> >
> > Then I build with:
> > make spider_defconfig && make
> >
> > This gives an error:
> > aarch64-none-elf-gcc: error: unrecognized argument in option '-mabi=apcs-
> gnu'
> > aarch64-none-elf-gcc: note: valid arguments to '-mabi=' are: ilp32 lp64
> > aarch64-none-elf-gcc: error: unrecognized command-line option '-msoft-
> float'
> > aarch64-none-elf-gcc: error: unrecognized command-line option '-mno-
> unaligned-access'
> > /home/pliops/workspace/simplest-linux-
> demo/barebox/scripts/Makefile.build:140: recipe for target
> 'scripts/mod/empty.o' failed
> > make[2]: *** [scripts/mod/empty.o] Error 1
> >
> > Not sure why the compiler flags get -mabi=apcs-gnu when I explicitly set
> CONFIG_CPU_V8 and the arch/arm/Makefile has:
> > ifeq ($(CONFIG_CPU_V8), y)
> > CFLAGS_ABI :=-mabi=lp64
> >
> > The changes I did:
> >>From 848b5f9b18bb1bb96d197cbc1b368ee0a729d581 Mon Sep 17
> 00:00:00 2001
> > ---
> > arch/arm/Kconfig | 13 ++++++++
> > arch/arm/Makefile | 1 +
> > arch/arm/boards/Makefile | 1 +
> > arch/arm/boards/spider-evk/Makefile | 4 +++
> > arch/arm/boards/spider-evk/board.c | 26 +++++++++++++++
> > arch/arm/boards/spider-evk/lowlevel.c | 30 +++++++++++++++++
> > arch/arm/configs/spider_defconfig | 8 +++++
> > arch/arm/dts/Makefile | 1 +
> > arch/arm/dts/spider-mk1-evk.dts | 10 ++++++
> > arch/arm/dts/spider-mk1.dtsi | 46 +++++++++++++++++++++++++++
> > arch/arm/mach-spider/Kconfig | 16 ++++++++++
> > arch/arm/mach-spider/Makefile | 1 +
> > arch/arm/mach-spider/lowlevel.c | 14 ++++++++
> > images/Makefile | 1 +
> > images/Makefile.spider | 5 +++
> > include/mach/spider/lowlevel.h | 7 ++++
> > 16 files changed, 184 insertions(+)
> > create mode 100644 arch/arm/boards/spider-evk/Makefile
> > create mode 100644 arch/arm/boards/spider-evk/board.c
> > create mode 100644 arch/arm/boards/spider-evk/lowlevel.c
> > create mode 100644 arch/arm/configs/spider_defconfig create mode
> 100644 arch/arm/dts/spider-mk1-evk.dts create mode 100644
> arch/arm/dts/spider-mk1.dtsi create mode 100644 arch/arm/mach-
> spider/Kconfig create mode 100644 arch/arm/mach-spider/Makefile create
> mode 100644 arch/arm/mach-spider/lowlevel.c create mode 100644
> images/Makefile.spider create mode 100644 include/mach/spider/lowlevel.h
> >
> > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index
> e76ee0f6dfe1..e5dcf128447e 100644
> > --- a/arch/arm/Kconfig
> > +++ b/arch/arm/Kconfig
> > @@ -255,6 +255,18 @@ config ARCH_ROCKCHIP
> > select HAS_DEBUG_LL
> > imply GPIO_ROCKCHIP
> >
> > +config ARCH_SPIDER
> > + bool "Pliops Spider based"
> > + depends on 64BIT
> > + depends on ARCH_MULTIARCH
> > + select GPIOLIB
> > + select HAVE_PBL_MULTI_IMAGES
> > + select COMMON_CLK
> > + select CLKDEV_LOOKUP
> > + select COMMON_CLK_OF_PROVIDER
> > + select OFTREE
> > + select OFDEVICE
> > +
> > config ARCH_STM32MP
> > bool "STMicroelectronics STM32MP"
> > depends on 32BIT
> > @@ -331,6 +343,7 @@ source "arch/arm/mach-omap/Kconfig"
> > source "arch/arm/mach-pxa/Kconfig"
> > source "arch/arm/mach-rockchip/Kconfig"
> > source "arch/arm/mach-socfpga/Kconfig"
> > +source "arch/arm/mach-spider/Kconfig"
> > source "arch/arm/mach-stm32mp/Kconfig"
> > source "arch/arm/mach-versatile/Kconfig"
> > source "arch/arm/mach-vexpress/Kconfig"
> > diff --git a/arch/arm/Makefile b/arch/arm/Makefile index
> 35ebc70f44e2..4c63dfee48f4 100644
> > --- a/arch/arm/Makefile
> > +++ b/arch/arm/Makefile
> > @@ -101,6 +101,7 @@ machine-$(CONFIG_ARCH_MXS) += mxs
> > machine-$(CONFIG_ARCH_MVEBU) += mvebu
> > machine-$(CONFIG_ARCH_NOMADIK) += nomadik
> > machine-$(CONFIG_ARCH_OMAP) += omap
> > +machine-$(CONFIG_ARCH_SPIDER) += spider
> > machine-$(CONFIG_ARCH_PXA) += pxa
> > machine-$(CONFIG_ARCH_ROCKCHIP) += rockchip
> > machine-$(CONFIG_ARCH_SAMSUNG) += samsung
> > diff --git a/arch/arm/boards/Makefile b/arch/arm/boards/Makefile index
> 2877debad535..6fe0a90c81ea 100644
> > --- a/arch/arm/boards/Makefile
> > +++ b/arch/arm/boards/Makefile
> > @@ -135,6 +135,7 @@ obj-
> $(CONFIG_MACH_SOCFPGA_TERASIC_DE10_NANO) += terasic-de10-
> nano/
> > obj-$(CONFIG_MACH_SOCFPGA_TERASIC_SOCKIT) += terasic-sockit/
> > obj-$(CONFIG_MACH_SOLIDRUN_CUBOX) += solidrun-cubox/
> > obj-$(CONFIG_MACH_SOLIDRUN_MICROSOM) += solidrun-
> microsom/
> > +obj-$(CONFIG_MACH_SPIDER_MK1_EVK) += spider-evk/
> > obj-$(CONFIG_MACH_STM32MP15XX_DKX) += stm32mp15xx-dkx/
> > obj-$(CONFIG_MACH_STM32MP13XX_DK) += stm32mp13xx-dk/
> > obj-$(CONFIG_MACH_LXA_MC1) += lxa-mc1/
> > diff --git a/arch/arm/boards/spider-evk/Makefile
> b/arch/arm/boards/spider-evk/Makefile
> > new file mode 100644
> > index 000000000000..da63d2625f7a
> > --- /dev/null
> > +++ b/arch/arm/boards/spider-evk/Makefile
> > @@ -0,0 +1,4 @@
> > +# SPDX-License-Identifier: GPL-2.0-only
> > +
> > +obj-y += board.o
> > +lwl-y += lowlevel.o
> > diff --git a/arch/arm/boards/spider-evk/board.c b/arch/arm/boards/spider-
> evk/board.c
> > new file mode 100644
> > index 000000000000..3920e83b457d
> > --- /dev/null
> > +++ b/arch/arm/boards/spider-evk/board.c
> > @@ -0,0 +1,26 @@
> > +#include <bbu.h>
> > +#include <boot.h>
> > +#include <bootm.h>
> > +#include <common.h>
> > +#include <deep-probe.h>
> > +#include <environment.h>
> > +#include <fcntl.h>
> > +#include <globalvar.h>
> > +
> > +static int spider_board_probe(struct device *dev) {
> > + /* Do some board-specific setup */
> > + return 0;
> > +}
> > +
> > +static const struct of_device_id spider_board_of_match[] = {
> > + { .compatible = "pliops,spider-mk1-evk" },
> > + { /* sentinel */ },
> > +};
> > +
> > +static struct driver spider_board_driver = {
> > + .name = "board-spider",
> > + .probe = spider_board_probe,
> > + .of_compatible = spider_board_of_match, };
> > +device_platform_driver(spider_board_driver);
> > diff --git a/arch/arm/boards/spider-evk/lowlevel.c
> b/arch/arm/boards/spider-evk/lowlevel.c
> > new file mode 100644
> > index 000000000000..e36fcde4208e
> > --- /dev/null
> > +++ b/arch/arm/boards/spider-evk/lowlevel.c
> > @@ -0,0 +1,30 @@
> > +#include <common.h>
> > +#include <asm/barebox-arm.h>
> > +#include <mach/spider/lowlevel.h>
> > +
> > +#define BASE_ADDR (0xD000307000)
> > +#define GPRAM_ADDR (0xC000000000)
> > +#define MY_STACK_TOP (0xC000000000 + SZ_2M) // Set the stack 2MB
> from GPRAM start (excatly in the middle)
> > +static inline void spider_serial_putc(void *base, int c) {
> > +// if (!(readl(base + UCR1) & UCR1_UARTEN))
> > +// return;
> > +//
> > +// while (!(readl(base + USR2) & USR2_TXDC));
> > +//
> > +// writel(c, base + URTX0);
> > +}
> > +
> > +ENTRY_FUNCTION_WITHSTACK(start_spider_mk1_evk, MY_STACK_TOP,
> r0, r1,
> > +r2) {
> > + extern char __dtb_spider_mk1_evk_start[];
> > +
> > + spider_lowlevel_init();
> > +
> > + relocate_to_current_adr();
> > + setup_c();
> > +
> > + pbl_set_putc(spider_serial_putc, (void *)BASE_ADDR);
> > +
> > + barebox_arm_entry(GPRAM_ADDR, SZ_2M,
> > +__dtb_spider_mk1_evk_start); }
> > diff --git a/arch/arm/configs/spider_defconfig
> b/arch/arm/configs/spider_defconfig
> > new file mode 100644
> > index 000000000000..c91bb889d97f
> > --- /dev/null
> > +++ b/arch/arm/configs/spider_defconfig
> > @@ -0,0 +1,8 @@
> > +CONFIG_ARCH_SPIDER=y
> > +CONFIG_MACH_SPIDER_MK1_EVK=y
> > +CONFIG_BOARD_ARM_GENERIC_DT=y
> > +CONFIG_MALLOC_TLSF=y
> > +CONFIG_KALLSYMS=y
> > +CONFIG_RELOCATABLE=y
> > +CONFIG_CONSOLE_ALLOW_COLOR=y
> > +CONFIG_PBL_CONSOLE=y
> > diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile index
> 98f4c4e0194b..94b304d4878f 100644
> > --- a/arch/arm/dts/Makefile
> > +++ b/arch/arm/dts/Makefile
> > @@ -134,6 +134,7 @@ lwl-$(CONFIG_MACH_SOLIDRUN_CUBOX) += dove-
> cubox-bb.dtb.o
> > lwl-$(CONFIG_MACH_SOLIDRUN_MICROSOM) += imx6dl-
> hummingboard.dtb.o imx6q-hummingboard.dtb.o \
> > imx6dl-hummingboard2.dtb.o imx6q-
> hummingboard2.dtb.o \
> > imx6q-h100.dtb.o
> > +lwl-$(CONFIG_MACH_SPIDER_MK1_EVK) += spider-mk1-evk.dtb.o
> > lwl-$(CONFIG_MACH_SKOV_IMX6) += imx6s-skov-imx6.dtb.o imx6dl-skov-
> imx6.dtb.o imx6q-skov-imx6.dtb.o
> > lwl-$(CONFIG_MACH_SKOV_ARM9CPU) += at91-skov-arm9cpu.dtb.o
> > lwl-$(CONFIG_MACH_SEEED_ODYSSEY) += stm32mp157c-odyssey.dtb.o
> diff --git a/arch/arm/dts/spider-mk1-evk.dts b/arch/arm/dts/spider-mk1-
> evk.dts new file mode 100644 index 000000000000..b8081cb85bf8
> > --- /dev/null
> > +++ b/arch/arm/dts/spider-mk1-evk.dts
> > @@ -0,0 +1,10 @@
> > +// SPDX-License-Identifier: GPL-2.0 OR X11
> > +
> > +/dts-v1/;
> > +
> > +#include "spider-mk1.dtsi"
> > +
> > +/ {
> > + model = "Pliops Spider MK-I EVK";
> > + compatible = "pliops,spider-mk1-evk"; };
> > diff --git a/arch/arm/dts/spider-mk1.dtsi b/arch/arm/dts/spider-mk1.dtsi
> new file mode 100644 index 000000000000..d4613848169d
> > --- /dev/null
> > +++ b/arch/arm/dts/spider-mk1.dtsi
> > @@ -0,0 +1,46 @@
> > +// SPDX-License-Identifier: GPL-2.0 OR X11
> > +
> > +/ {
> > + #address-cells = <2>;
> > + #size-cells = <2>;
> > +
> > + chosen {
> > + stdout-path = &uart0;
> > + };
> > +
> > + aliases {
> > + serial0 = &uart0;
> > + };
> > +
> > + cpus {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + cpu0: cpu@0 {
> > + device_type = "cpu";
> > + compatible = "arm,cortex-a53";
> > + reg = <0x0>;
> > + };
> > + };
> > +
> > + memory@1000000 {
> > + reg = <0x0 0x1000000 0x0 0x400000>; /* 128M */
> > + device_type = "memory";
> > + };
> > +
> > + soc {
> > + #address-cells = <2>;
> > + #size-cells = <2>;
> > + ranges;
> > +
> > + sram@c000000000 {
> > + compatible = "mmio-sram";
> > + reg = <0xc0 0x0 0x0 0x400000>;
> > + };
> > +
> > + uart0: serial@d000307000 {
> > + compatible = "pliops,spider-uart";
> > + reg = <0xd0 0x307000 0 0x1000>;
> > + };
> > + };
> > +};
> > diff --git a/arch/arm/mach-spider/Kconfig b/arch/arm/mach-spider/Kconfig
> new file mode 100644 index 000000000000..6d2f888a5fd8
> > --- /dev/null
> > +++ b/arch/arm/mach-spider/Kconfig
> > @@ -0,0 +1,16 @@
> > +# SPDX-License-Identifier: GPL-2.0-only
> > +
> > +if ARCH_SPIDER
> > +
> > +config ARCH_SPIDER_MK1
> > + bool
> > + select CPU_V8
> > + help
> > + The first Cortex-A53-based SoC of the spider family.
> > + This symbol is invisble and select by boards
> > +
> > +config MACH_SPIDER_MK1_EVK
> > + bool "Pliops Spider Reference Design Board"
> > + select ARCH_SPIDER_MK1
> > +
> > +endif
> > diff --git a/arch/arm/mach-spider/Makefile b/arch/arm/mach-
> spider/Makefile new file mode 100644 index 000000000000..b08c4a93ca27
> > --- /dev/null
> > +++ b/arch/arm/mach-spider/Makefile
> > @@ -0,0 +1 @@
> > +lwl-y += lowlevel.o
> > diff --git a/arch/arm/mach-spider/lowlevel.c b/arch/arm/mach-
> spider/lowlevel.c new file mode 100644 index
> 000000000000..5d62ef0f39e5
> > --- /dev/null
> > +++ b/arch/arm/mach-spider/lowlevel.c
> > @@ -0,0 +1,14 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +
> > +#include <linux/types.h>
> > +#include <mach/spider/lowlevel.h>
> > +#include <asm/barebox-arm-head.h>
> > +
> > +void spider_lowlevel_init(void)
> > +{
> > + arm_cpu_lowlevel_init();
> > + /*
> > + * not yet relocated, only do writel/readl for stuff that's
> > + * critical to run early. No global variables allowed.
> > + */
> > +}
> > diff --git a/images/Makefile b/images/Makefile index
> c93f9e268978..97521e713228 100644
> > --- a/images/Makefile
> > +++ b/images/Makefile
> > @@ -150,6 +150,7 @@ include $(srctree)/images/Makefile.mxs include
> $(srctree)/images/Makefile.omap3 include
> $(srctree)/images/Makefile.rockchip
> > include $(srctree)/images/Makefile.socfpga
> > +include $(srctree)/images/Makefile.spider
> > include $(srctree)/images/Makefile.stm32mp
> > include $(srctree)/images/Makefile.tegra include
> $(srctree)/images/Makefile.versatile
> > diff --git a/images/Makefile.spider b/images/Makefile.spider new file mode
> 100644 index 000000000000..c32f2762df04
> > --- /dev/null
> > +++ b/images/Makefile.spider
> > @@ -0,0 +1,5 @@
> > +# SPDX-License-Identifier: GPL-2.0-only
> > +
> > +pblb-$(CONFIG_MACH_SPIDER_MK1_EVK) += start_spider_mk1_evk
> > +FILE_barebox-spider-mk1-evk.img = start_spider_mk1_evk.pblb
> > +image-$(CONFIG_MACH_SPIDER_MK1_EVK) += barebox-spider-mk1-
> evk.img
> > diff --git a/include/mach/spider/lowlevel.h
> b/include/mach/spider/lowlevel.h new file mode 100644 index
> 000000000000..6e0ce1c77f7e
> > --- /dev/null
> > +++ b/include/mach/spider/lowlevel.h
> > @@ -0,0 +1,7 @@
> > +/* SPDX-License-Identifier: GPL-2.0+ */ #ifndef __MACH_SPIDER_H_
> > +#define __MACH_SPIDER_H_
> > +
> > +void spider_lowlevel_init(void);
> > +
> > +#endif
> > --
> > 2.38.4
> >
> >
>
> --
> Pengutronix e.K. | |
> Steuerwalder Str. 21 | http://www.pengutronix.de/ |
> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [PATCH v2] Porting barebox to a new SoC
2023-05-30 20:10 ` Lior Weintraub
@ 2023-05-31 6:10 ` Ahmad Fatoum
2023-05-31 8:05 ` Lior Weintraub
0 siblings, 1 reply; 40+ messages in thread
From: Ahmad Fatoum @ 2023-05-31 6:10 UTC (permalink / raw)
To: Lior Weintraub, Ahmad Fatoum, barebox
Hi Lior,
On 30.05.23 22:10, Lior Weintraub wrote:
> Hello Ahmad,
>
> Thanks again for your kind support!
> Your comments helped me progress and the current situation is as follows:
> Our QEMU Spider machine is running a BL1.elf file using the following command:
> QEMU_AUDIO_DRV=none qemu-system-aarch64 -M spider-soc -smp 1 -m 128M -nographic \
> -device loader,file=BL1.elf -cpu cortex-a53,rvbar=0xC004000000 \
> -d unimp -semihosting-config enable=on,target=native \
> -monitor telnet:localhost:1235,server,nowait \
> -gdb tcp::1236
>
> The BL1.elf is our BootROM application that runs from ROM address 0xC004000000.
> Just for debugging purpose we've increased the ROM size so it can include the images/barebox-spider-mk1-evk.img (as a const array).
> BL1 then copy it (using memcpy) to address 0 and jumps there for execution.
Sounds ok.
> On the real ASIC this address will be the DRAM and indeed will need to be initialized before the copy but here on QEMU it is not required.
I see. You could still have your bootrom move barebox into SRAM and then
barebox_arm_entry(DRAM_ADDR, SZ_128M, __dtb_spider_mk1_evk_start);
To have PBL extract barebox to DRAM. Even if you don't need need DRAM
setup in QEMU, the flow would be similar to what you will have on actual
silicon.
> The lowlevel.c of spider-evk was modified to use DRAM_ADDR 0x400000 (4MB from start) and MY_STACK_TOP was set to 0x8000000 (128M).
That's not needed. While you don't have control where barebox PBL will be located
(depends on BootROM), barebox will extract itself to the end of DRAM without
overwriting itself, so you can just use DRAM_ADDR 0 normally. Eventually, stack
top should go into SRAM, but anywhere that works is ok.
> In addition, I implemented putc_ll (currently hard-coded in include/debug_ll.h) and opened log level to VERBOSE_DEBUG (currently just hard-coded in printk.h).
There's CONFIG_DEBUG_PBL you can enable to get all these messages by default.
> I see the following (which makes sense) logs on QEMU terminal:
> uncompress.c: memory at 0x00400000, size 0x00200000
> uncompress.c: uncompressing barebox binary at 0x0000000000002200 (size 0x0001d3b2) to 0x00400000 (uncompressed size: 0x000373d0)
Why pass only 2M to barebox_arm_entry? While this need not be the whole of RAM, this
initial memory is what barebox will use for itself including its final stack and
malloc area. barebox will also not place itself into the last 1M AFAIK, so 2M
may not work ok. You should use the minimum possible RAM here or if you can detect
in PBL how much RAM you have or just the whole RAM bank. I am not sure anything lower
than SZ_4M would work ok. (Note this is DRAM size, not SRAM. barebox PBL is fine being
called from 64K SRAMs, it just needs DRAM to extract to).
> I then connect with aarch64-none-elf-gdb, load the barebox symbols (to 0x400000) and check the current execution state (program counter and stack).
> Looks like the code is stuck on function register_autoboot_vars:
> sp 0x5f7e60 0x5f7e60
> pc 0x401264 0x401264 <register_autoboot_vars+24>
>
> Few observations:
> 1. The PBL was using stack top located on 0x8000000 (which is MY_STACK_TOP). Found it be causing a breakpoint on the PBL.
> 2. Barebox uses a stack top on 0x600000 which is probably calculated from my new DRAM_ADDR and SZ_2M given to the function call:
> barebox_arm_entry(DRAM_ADDR, SZ_2M, __dtb_spider_mk1_evk_start);
>
> This is great! I am starting to find my way.
:) Ye, the ENTRY_FUNCTION_WITHSTACK is only when the BootROM doesn't enter
with a valid stack pointer. It's overwritten as soon as barebox is told
about the initial memory layout (with barebox_arm_entry).
> When the barebox execution didn't print anything to the terminal I remembered that we used a place holder on the dtsi for the uart.
> So now I changed it to:
> uart0: serial@d000307000 {
> compatible = "arm,pl011", "arm,primecell";
> reg = <0xd0 0x307000 0 0x1000>;
> }
> (Our QEMU UART is currently using pl011 device.)
Looks ok. Don't forget to enable the driver (via make menuconfig).
> After some time (trying to debug by enabling MMU but then reverted the code back), I got to a point that when I try to run again I am getting an exception.
> I can swear all code changes were reverted back to the point where I saw the barebox stuck on register_autoboot_vars but now it just cases an exception.
> The exception vector code is located on our ROM (part of BL1 code) and the logs shows that the link register has the value 0x401218 which suggest the following code:
> 0000000000001200 <load_environment>:
> 1200: a9be7bfd stp x29, x30, [sp, #-32]!
> 1204: 910003fd mov x29, sp
> 1208: a90153f3 stp x19, x20, [sp, #16]
> 120c: 94000a07 bl 3a28 <default_environment_path_get>
> 1210: d00000f3 adrp x19, 1f000 <do_cpuinfo+0x1f0>
> 1214: 912a7273 add x19, x19, #0xa9c
> 1218: aa0003f4 mov x20, x0
>
> Any ideas or suggestions how to proceed with the debugging?
You shouldn't need to touch the MMU code. If your initial memory setup
is wonky, you may end up overwriting stuff. Try again with bigger memory.
> BTW, to answer your questions:
> The SRAM of 4MB is the only one we have because we assumed it is only for BootROM to load a PBL
Ok. Sometimes there are SRAMs for use with DMA. I asked, because a SRAM in the first 4M
would lend itself nicely as stack, but if there is none, we can adjust
ENTRY_FUNCTION_WITHSTACK to accept a 64-bit parameter.
Cheers,
Ahmad
> Thank you very much,
> Cheers,
> Lior.
>
>
>> -----Original Message-----
>> From: Ahmad Fatoum <a.fatoum@pengutronix.de>
>> Sent: Monday, May 29, 2023 10:03 PM
>> To: Lior Weintraub <liorw@pliops.com>; Ahmad Fatoum <ahmad@a3f.at>;
>> barebox@lists.infradead.org
>> Subject: Re: [PATCH v2] Porting barebox to a new SoC
>>
>> CAUTION: External Sender
>>
>> Hello Lior,
>>
>> On 29.05.23 15:34, Lior Weintraub wrote:
>>> Hi Ahmad,
>>>
>>> I have revised the addresses and used DRAM address @ 0 instead:
>>> #define UARTBASE (0xD000307000)
>>> #define DRAM_ADDR (0x00000000)
>>> #define MY_STACK_TOP (0x00000000 + SZ_2M) // Set the stack 2MB from
>> DRAM start
>>
>> Is DRAM configured by the time barebox runs? If not, you should keep stack
>> top
>> in SRAM, until you have setup memory in prebootloader (PBL). Is the 4M
>> SRAM
>> the only on-chip SRAM you have?
>>
>>> static inline void spider_serial_putc(void *base, int c)
>>> {
>>> *((volatile unsigned *)base) = c;
>>
>> There's a helper for that: writel(c, base); In barebox, it's equivalent
>> to the volatile access, but in Linux it involves a write memory barrier.
>> We try to write code in barebox, so it's easily reusable in Linux (and
>> the other way round).
>>
>>> }
>>>
>>> I will try to test it on QEMU using an initial QEMU machine we made for
>> Spider.
>>> In this machine we only have 3 memory regions and a PL011 UART:
>>> spider_soc_memories soc_memories[] = {
>>> {.name = "SPIDER_GPRAM", .add = 0xC000000000ULL, .size = 4 * MiB},
>>> {.name = "SPIDER_ROM", .add = 0xC004000000ULL, .size = 128 * KiB},
>>> {.name = "SPIDER_DRAM", .add = 0x0000000000ULL, .size = 1 * GiB},
>>> };
>>>
>>> This special QEMU machine can run our BL1 code from "ROM" address (we
>> set the RVBAR to point there).
>>> So my idea is to test the barebox image by the following steps:
>>> 1. Modify the QEMU code to have a "ROM" with the size of 128M.
>>> 2. Compile our BL1 code to include the barebox.bin as a const array, copy it
>> to "DRAM" @ address 0 and jump there.
>>
>> Why not map QEMU -bios option to SRAM? (Or DRAM directly, if it needs no
>> special setup from
>> barebox side).
>>
>>> For this to work I wanted to understand how to call (i.e. what arguments to
>> pass) to barebox.
>>
>> barebox doesn't expect any arguments, because most BootROMs don't pass
>> anything useful.
>> Some pass information about bootsource though, so that's why the
>> ENTRY_FUNCTION has
>> r0, r1 and r2 as parameters, but you need not use them.
>>
>>> So I checked the barebox.map and found the function "start" on address 0.
>>
>> You may know that Linux on some platforms comes with a decompressor that
>> is glued to the
>> front of the kernel image and extracts the compressed kernel image. barebox
>> has the same
>> concept. The prebootloader is uncompressed and runs (starting from
>> ENTRY_FUNCTION) and
>> then does some early setup (e.g. enable clocks, configure PMIC, setup DRAM,
>> load secure
>> monitor (BL31), ...etc.) and then it decompresses barebox proper into DRAM.
>>
>> barebox.bin <- barebox proper. You don't usually need that.
>> barebox.elf <- ELF binary for the above (for gdb)
>> barebox.map <- map file of the above
>>
>> images/barebox-spider-mk1-evk.img <- complete barebox image (PBL +
>> barebox proper)
>> images/start_spider_mk1_evk.pbl <- ELF image for the above
>> images/start_spider_mk1_evk.pbl.map <- map file of the above
>>
>> If you want to follow barbeox from the start, begin at start_spider_mk1_evk.
>>
>>> Then I went to arch/arm/cpu/start.c and realized that the code is compiled
>> with CONFIG_PBL_IMAGE.
>>> In that case I assume I need to pass 3 arguments and use this function
>> prototype:
>>> void start(unsigned long membase, unsigned long memsize, void
>> *boarddata);
>>
>> barebox prebootloader takes care of this, so you don't need to do anything.
>>
>>> Few questions:
>>> 1. Will that call work:
>>> typedef void (*barebox_start)(unsigned long , unsigned long , void *);
>>> #define DRAM_START (0)
>>> barebox_start p_barebox = (barebox_start)DRAM_START;
>>> p_barebox(DRAM_START, DRAM_START+SZ_2M, (void
>> *)(DRAM_START+SZ_4M));
>>> This assumes that my BL1 code also copied the device tree (barebox-dt-
>> 2nd.img? start_dt_2nd.pblb? start_spider_mk1_evk.pblb?)
>>
>> The device tree is built into the PBL and passed to barebox proper. This
>> allows us to use the same barebox proper binary and link it with a different
>> prebootloader for each SoC/board, all in the same build.
>>
>> barebox-dt-2nd.img is a special image that looks exactly like a Linux kernel:
>>
>> images/barebox-dt-2nd.img: Linux kernel ARM64 boot executable Image,
>> little-endian, 4K pages
>>
>> and can thus be used for booting for easy chainloading from other
>> bootloaders or for running
>> with QEMU -kernel. You shouldn't need it right now.
>>
>>> 2. Do I want to have my code compiled with CONFIG_PBL_IMAGE?
>>> If I understand correctly, it means that my code will provide a PBL (a.k.a
>> BL2) which will set the DRAM and STACK among other things (MMU?).
>>
>> The patch I sent already builds a PBL. You will need to fill out
>> start_spider_mk1_evk
>> to do all the other early initialization you need. Then you call
>> barebox_arm_entry
>> with device tree and memory size and it will take care to do stack setup in new
>> memory region, MMU setup (if enabled) and chainloading barebox proper.
>>
>> Note that PBL isn't necessary BL2. You can chainload barebox from within
>> barebox (i.e.
>> in EL2 or EL1), which is useful for debugging. You will thus often find PBL code
>> that
>> does
>>
>> if (current_el() == 3) {
>> /* Do BL2 setup */
>> chainload();
>> __builtin_unreachable();
>> }
>>
>> barebox_arm_entry(...)
>>
>> See for example arch/arm/boards/innocomm-imx8mm-wb15/lowlevel.c
>>
>> to see a real-world example of another Cortex-A53.
>>
>>> In that case I assume it is OK.
>>> 3. If I try to remove it by having CONFIG_PBL_IMAGE=n on spider_defconfig
>> this doesn't do anything
>>> The build (make spider_defconfig) ignores it and say that " No change to
>> .config ".
>>
>> Another symbol forces it to be enabled. If you are curious, run make
>> menuconfig
>> and then search (/) for the symbol and it will list, whether it's enabled and
>> why:
>>
>> Selected by [y]:
>> - PBL_MULTI_IMAGES [=y] && HAVE_PBL_MULTI_IMAGES [=y]
>>
>> I'd suggest you avoid modifying the .config file manually. always use
>> menuconfig.
>>
>>> 4. I also tried to understand how to implement PUTC_LL but not sure I
>> understand.
>>> 4.1 When I set "CONFIG_DEBUG_LL=y" on spider_defconfig it is again not
>> written to .config and I get " No change to .config " message.
>>
>> You must:
>>
>> - select HAS_DEBUG_LL from MACH_SPIDER
>> - Add your arch to arch/arm/include/asm/debug_ll.h
>> - Then implement PUTC_LL in e.g. mach/spider/debug_ll.h
>>
>>> 4.2 Do I need to have my own debug_ll.h file?
>>
>> Yes. See above.
>>
>>> 5. When I make changes to spider_defconfig and try to regenerate the
>> .config and I get " No change to .config " message, does it mean that those
>> macros are "hidden" symbols like you said about the CONFIG_CPU_V8?
>>
>> Yes. Just check menuconfig to see how symbols relate to each other.
>> This is 1:1 like it's in Linux, so it'll come in handy when you do
>> the kernel port too ;)
>>
>>> Apologize for so many questions :-)
>>
>> No problem. Looking forward to your patches ;)
>>
>>
>> Cheers,
>> Ahmad
>>
>>> Cheers,
>>> Lior.
>>>
>>> -----Original Message-----
>>> From: Lior Weintraub
>>> Sent: Sunday, May 28, 2023 11:16 PM
>>> To: Ahmad Fatoum <ahmad@a3f.at>; barebox@lists.infradead.org
>>> Subject: RE: [PATCH v2] Porting barebox to a new SoC
>>>
>>> Hi Ahmad,
>>>
>>> Thank you so much for your kind support!
>>>
>>> Indeed we also have a 16GB DRAM that starts from address 0 (though
>> currently we don't have the controller settings (under development)).
>>>
>>> I also wrote the BootROM (BL1) for this SoC (128KB ROM @ address
>> 0xC004000000).
>>> I understand now that it would be best for me to develop BL2 that will run
>> from our SRAM.
>>>
>>> As this BL2 code is bare-metal I have no problem or limitations with the 40
>> bit addresses.
>>> The BL2 code will initialize the DRAM controller and then copy Barebox image
>> from NOR Flash to address 0 of the DRAM.
>>> Our NOR Flash is 128MB in size and it is accessed via QSPI controller.
>>>
>>> I tried applying your suggested patch but got an error while doing so:
>>> $git apply 0002-Ahmad.patch
>>> 0002-Ahmad.patch:115: trailing whitespace.
>>> .of_compatible = spider_board_of_match, };
>>> error: corrupt patch at line 117
>>>
>>> After some digging I found that my Outlook probably messed with the patch
>> format (even though I am using text only and no HTML format).
>>> When I went to the web and copied the patch from there (mailing list
>> archive) it was working well (i.e. no compilation error).
>>>
>>> Cheers,
>>> Lior.
>>>
>>> -----Original Message-----
>>> From: Ahmad Fatoum <ahmad@a3f.at>
>>> Sent: Sunday, May 28, 2023 6:38 PM
>>> To: barebox@lists.infradead.org
>>> Cc: Lior Weintraub <liorw@pliops.com>
>>> Subject: [PATCH v2] Porting barebox to a new SoC
>>>
>>> CAUTION: External Sender
>>>
>>> From: Lior Weintraub <liorw@pliops.com>
>>>
>>> Hi,
>>>
>>> I tried to follow the porting guide on https://ddec1-0-en-
>> ctp.trendmicro.com:443/wis/clicktime/v1/query?url=https%3a%2f%2fwww.
>> barebox.org%2fdoc%2flatest%2fdevel%2fporting.html%23&umid=60097eda
>> -f136-45a1-9c8e-
>> cf6a76e45cf8&auth=860a7ebb9feba264acc79b6e38eb59582349362c-
>> 480ae23736add41c88ab8d30c090a75517ca7f9e but couldn't follow the
>> instructions.
>>> I would like to port barebox to a new SoC (which is not a derivative of any
>> known SoC).
>>> It has the following:
>>> * Single Cortex A53
>>> * SRAM (4MB) located on address 0xC000000000
>>>
>>> The below patch shows my initial test to try and have a starting point.
>>> I am setting env variables:
>>> export ARCH=arm64
>>> export CROSS_COMPILE=/home/pliops/workspace/ARM/arm-gnu-
>> toolchain/bin/aarch64-none-elf-
>>>
>>> Then I build with:
>>> make spider_defconfig && make
>>>
>>> This gives an error:
>>> aarch64-none-elf-gcc: error: unrecognized argument in option '-mabi=apcs-
>> gnu'
>>> aarch64-none-elf-gcc: note: valid arguments to '-mabi=' are: ilp32 lp64
>>> aarch64-none-elf-gcc: error: unrecognized command-line option '-msoft-
>> float'
>>> aarch64-none-elf-gcc: error: unrecognized command-line option '-mno-
>> unaligned-access'
>>> /home/pliops/workspace/simplest-linux-
>> demo/barebox/scripts/Makefile.build:140: recipe for target
>> 'scripts/mod/empty.o' failed
>>> make[2]: *** [scripts/mod/empty.o] Error 1
>>>
>>> Not sure why the compiler flags get -mabi=apcs-gnu when I explicitly set
>> CONFIG_CPU_V8 and the arch/arm/Makefile has:
>>> ifeq ($(CONFIG_CPU_V8), y)
>>> CFLAGS_ABI :=-mabi=lp64
>>>
>>> The changes I did:
>>> >From 848b5f9b18bb1bb96d197cbc1b368ee0a729d581 Mon Sep 17
>> 00:00:00 2001
>>> ---
>>> arch/arm/Kconfig | 13 ++++++++
>>> arch/arm/Makefile | 1 +
>>> arch/arm/boards/Makefile | 1 +
>>> arch/arm/boards/spider-evk/Makefile | 4 +++
>>> arch/arm/boards/spider-evk/board.c | 26 +++++++++++++++
>>> arch/arm/boards/spider-evk/lowlevel.c | 30 +++++++++++++++++
>>> arch/arm/configs/spider_defconfig | 8 +++++
>>> arch/arm/dts/Makefile | 1 +
>>> arch/arm/dts/spider-mk1-evk.dts | 10 ++++++
>>> arch/arm/dts/spider-mk1.dtsi | 46 +++++++++++++++++++++++++++
>>> arch/arm/mach-spider/Kconfig | 16 ++++++++++
>>> arch/arm/mach-spider/Makefile | 1 +
>>> arch/arm/mach-spider/lowlevel.c | 14 ++++++++
>>> images/Makefile | 1 +
>>> images/Makefile.spider | 5 +++
>>> include/mach/spider/lowlevel.h | 7 ++++
>>> 16 files changed, 184 insertions(+)
>>> create mode 100644 arch/arm/boards/spider-evk/Makefile
>>> create mode 100644 arch/arm/boards/spider-evk/board.c
>>> create mode 100644 arch/arm/boards/spider-evk/lowlevel.c
>>> create mode 100644 arch/arm/configs/spider_defconfig create mode
>> 100644 arch/arm/dts/spider-mk1-evk.dts create mode 100644
>> arch/arm/dts/spider-mk1.dtsi create mode 100644 arch/arm/mach-
>> spider/Kconfig create mode 100644 arch/arm/mach-spider/Makefile create
>> mode 100644 arch/arm/mach-spider/lowlevel.c create mode 100644
>> images/Makefile.spider create mode 100644 include/mach/spider/lowlevel.h
>>>
>>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index
>> e76ee0f6dfe1..e5dcf128447e 100644
>>> --- a/arch/arm/Kconfig
>>> +++ b/arch/arm/Kconfig
>>> @@ -255,6 +255,18 @@ config ARCH_ROCKCHIP
>>> select HAS_DEBUG_LL
>>> imply GPIO_ROCKCHIP
>>>
>>> +config ARCH_SPIDER
>>> + bool "Pliops Spider based"
>>> + depends on 64BIT
>>> + depends on ARCH_MULTIARCH
>>> + select GPIOLIB
>>> + select HAVE_PBL_MULTI_IMAGES
>>> + select COMMON_CLK
>>> + select CLKDEV_LOOKUP
>>> + select COMMON_CLK_OF_PROVIDER
>>> + select OFTREE
>>> + select OFDEVICE
>>> +
>>> config ARCH_STM32MP
>>> bool "STMicroelectronics STM32MP"
>>> depends on 32BIT
>>> @@ -331,6 +343,7 @@ source "arch/arm/mach-omap/Kconfig"
>>> source "arch/arm/mach-pxa/Kconfig"
>>> source "arch/arm/mach-rockchip/Kconfig"
>>> source "arch/arm/mach-socfpga/Kconfig"
>>> +source "arch/arm/mach-spider/Kconfig"
>>> source "arch/arm/mach-stm32mp/Kconfig"
>>> source "arch/arm/mach-versatile/Kconfig"
>>> source "arch/arm/mach-vexpress/Kconfig"
>>> diff --git a/arch/arm/Makefile b/arch/arm/Makefile index
>> 35ebc70f44e2..4c63dfee48f4 100644
>>> --- a/arch/arm/Makefile
>>> +++ b/arch/arm/Makefile
>>> @@ -101,6 +101,7 @@ machine-$(CONFIG_ARCH_MXS) += mxs
>>> machine-$(CONFIG_ARCH_MVEBU) += mvebu
>>> machine-$(CONFIG_ARCH_NOMADIK) += nomadik
>>> machine-$(CONFIG_ARCH_OMAP) += omap
>>> +machine-$(CONFIG_ARCH_SPIDER) += spider
>>> machine-$(CONFIG_ARCH_PXA) += pxa
>>> machine-$(CONFIG_ARCH_ROCKCHIP) += rockchip
>>> machine-$(CONFIG_ARCH_SAMSUNG) += samsung
>>> diff --git a/arch/arm/boards/Makefile b/arch/arm/boards/Makefile index
>> 2877debad535..6fe0a90c81ea 100644
>>> --- a/arch/arm/boards/Makefile
>>> +++ b/arch/arm/boards/Makefile
>>> @@ -135,6 +135,7 @@ obj-
>> $(CONFIG_MACH_SOCFPGA_TERASIC_DE10_NANO) += terasic-de10-
>> nano/
>>> obj-$(CONFIG_MACH_SOCFPGA_TERASIC_SOCKIT) += terasic-sockit/
>>> obj-$(CONFIG_MACH_SOLIDRUN_CUBOX) += solidrun-cubox/
>>> obj-$(CONFIG_MACH_SOLIDRUN_MICROSOM) += solidrun-
>> microsom/
>>> +obj-$(CONFIG_MACH_SPIDER_MK1_EVK) += spider-evk/
>>> obj-$(CONFIG_MACH_STM32MP15XX_DKX) += stm32mp15xx-dkx/
>>> obj-$(CONFIG_MACH_STM32MP13XX_DK) += stm32mp13xx-dk/
>>> obj-$(CONFIG_MACH_LXA_MC1) += lxa-mc1/
>>> diff --git a/arch/arm/boards/spider-evk/Makefile
>> b/arch/arm/boards/spider-evk/Makefile
>>> new file mode 100644
>>> index 000000000000..da63d2625f7a
>>> --- /dev/null
>>> +++ b/arch/arm/boards/spider-evk/Makefile
>>> @@ -0,0 +1,4 @@
>>> +# SPDX-License-Identifier: GPL-2.0-only
>>> +
>>> +obj-y += board.o
>>> +lwl-y += lowlevel.o
>>> diff --git a/arch/arm/boards/spider-evk/board.c b/arch/arm/boards/spider-
>> evk/board.c
>>> new file mode 100644
>>> index 000000000000..3920e83b457d
>>> --- /dev/null
>>> +++ b/arch/arm/boards/spider-evk/board.c
>>> @@ -0,0 +1,26 @@
>>> +#include <bbu.h>
>>> +#include <boot.h>
>>> +#include <bootm.h>
>>> +#include <common.h>
>>> +#include <deep-probe.h>
>>> +#include <environment.h>
>>> +#include <fcntl.h>
>>> +#include <globalvar.h>
>>> +
>>> +static int spider_board_probe(struct device *dev) {
>>> + /* Do some board-specific setup */
>>> + return 0;
>>> +}
>>> +
>>> +static const struct of_device_id spider_board_of_match[] = {
>>> + { .compatible = "pliops,spider-mk1-evk" },
>>> + { /* sentinel */ },
>>> +};
>>> +
>>> +static struct driver spider_board_driver = {
>>> + .name = "board-spider",
>>> + .probe = spider_board_probe,
>>> + .of_compatible = spider_board_of_match, };
>>> +device_platform_driver(spider_board_driver);
>>> diff --git a/arch/arm/boards/spider-evk/lowlevel.c
>> b/arch/arm/boards/spider-evk/lowlevel.c
>>> new file mode 100644
>>> index 000000000000..e36fcde4208e
>>> --- /dev/null
>>> +++ b/arch/arm/boards/spider-evk/lowlevel.c
>>> @@ -0,0 +1,30 @@
>>> +#include <common.h>
>>> +#include <asm/barebox-arm.h>
>>> +#include <mach/spider/lowlevel.h>
>>> +
>>> +#define BASE_ADDR (0xD000307000)
>>> +#define GPRAM_ADDR (0xC000000000)
>>> +#define MY_STACK_TOP (0xC000000000 + SZ_2M) // Set the stack 2MB
>> from GPRAM start (excatly in the middle)
>>> +static inline void spider_serial_putc(void *base, int c) {
>>> +// if (!(readl(base + UCR1) & UCR1_UARTEN))
>>> +// return;
>>> +//
>>> +// while (!(readl(base + USR2) & USR2_TXDC));
>>> +//
>>> +// writel(c, base + URTX0);
>>> +}
>>> +
>>> +ENTRY_FUNCTION_WITHSTACK(start_spider_mk1_evk, MY_STACK_TOP,
>> r0, r1,
>>> +r2) {
>>> + extern char __dtb_spider_mk1_evk_start[];
>>> +
>>> + spider_lowlevel_init();
>>> +
>>> + relocate_to_current_adr();
>>> + setup_c();
>>> +
>>> + pbl_set_putc(spider_serial_putc, (void *)BASE_ADDR);
>>> +
>>> + barebox_arm_entry(GPRAM_ADDR, SZ_2M,
>>> +__dtb_spider_mk1_evk_start); }
>>> diff --git a/arch/arm/configs/spider_defconfig
>> b/arch/arm/configs/spider_defconfig
>>> new file mode 100644
>>> index 000000000000..c91bb889d97f
>>> --- /dev/null
>>> +++ b/arch/arm/configs/spider_defconfig
>>> @@ -0,0 +1,8 @@
>>> +CONFIG_ARCH_SPIDER=y
>>> +CONFIG_MACH_SPIDER_MK1_EVK=y
>>> +CONFIG_BOARD_ARM_GENERIC_DT=y
>>> +CONFIG_MALLOC_TLSF=y
>>> +CONFIG_KALLSYMS=y
>>> +CONFIG_RELOCATABLE=y
>>> +CONFIG_CONSOLE_ALLOW_COLOR=y
>>> +CONFIG_PBL_CONSOLE=y
>>> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile index
>> 98f4c4e0194b..94b304d4878f 100644
>>> --- a/arch/arm/dts/Makefile
>>> +++ b/arch/arm/dts/Makefile
>>> @@ -134,6 +134,7 @@ lwl-$(CONFIG_MACH_SOLIDRUN_CUBOX) += dove-
>> cubox-bb.dtb.o
>>> lwl-$(CONFIG_MACH_SOLIDRUN_MICROSOM) += imx6dl-
>> hummingboard.dtb.o imx6q-hummingboard.dtb.o \
>>> imx6dl-hummingboard2.dtb.o imx6q-
>> hummingboard2.dtb.o \
>>> imx6q-h100.dtb.o
>>> +lwl-$(CONFIG_MACH_SPIDER_MK1_EVK) += spider-mk1-evk.dtb.o
>>> lwl-$(CONFIG_MACH_SKOV_IMX6) += imx6s-skov-imx6.dtb.o imx6dl-skov-
>> imx6.dtb.o imx6q-skov-imx6.dtb.o
>>> lwl-$(CONFIG_MACH_SKOV_ARM9CPU) += at91-skov-arm9cpu.dtb.o
>>> lwl-$(CONFIG_MACH_SEEED_ODYSSEY) += stm32mp157c-odyssey.dtb.o
>> diff --git a/arch/arm/dts/spider-mk1-evk.dts b/arch/arm/dts/spider-mk1-
>> evk.dts new file mode 100644 index 000000000000..b8081cb85bf8
>>> --- /dev/null
>>> +++ b/arch/arm/dts/spider-mk1-evk.dts
>>> @@ -0,0 +1,10 @@
>>> +// SPDX-License-Identifier: GPL-2.0 OR X11
>>> +
>>> +/dts-v1/;
>>> +
>>> +#include "spider-mk1.dtsi"
>>> +
>>> +/ {
>>> + model = "Pliops Spider MK-I EVK";
>>> + compatible = "pliops,spider-mk1-evk"; };
>>> diff --git a/arch/arm/dts/spider-mk1.dtsi b/arch/arm/dts/spider-mk1.dtsi
>> new file mode 100644 index 000000000000..d4613848169d
>>> --- /dev/null
>>> +++ b/arch/arm/dts/spider-mk1.dtsi
>>> @@ -0,0 +1,46 @@
>>> +// SPDX-License-Identifier: GPL-2.0 OR X11
>>> +
>>> +/ {
>>> + #address-cells = <2>;
>>> + #size-cells = <2>;
>>> +
>>> + chosen {
>>> + stdout-path = &uart0;
>>> + };
>>> +
>>> + aliases {
>>> + serial0 = &uart0;
>>> + };
>>> +
>>> + cpus {
>>> + #address-cells = <1>;
>>> + #size-cells = <0>;
>>> +
>>> + cpu0: cpu@0 {
>>> + device_type = "cpu";
>>> + compatible = "arm,cortex-a53";
>>> + reg = <0x0>;
>>> + };
>>> + };
>>> +
>>> + memory@1000000 {
>>> + reg = <0x0 0x1000000 0x0 0x400000>; /* 128M */
>>> + device_type = "memory";
>>> + };
>>> +
>>> + soc {
>>> + #address-cells = <2>;
>>> + #size-cells = <2>;
>>> + ranges;
>>> +
>>> + sram@c000000000 {
>>> + compatible = "mmio-sram";
>>> + reg = <0xc0 0x0 0x0 0x400000>;
>>> + };
>>> +
>>> + uart0: serial@d000307000 {
>>> + compatible = "pliops,spider-uart";
>>> + reg = <0xd0 0x307000 0 0x1000>;
>>> + };
>>> + };
>>> +};
>>> diff --git a/arch/arm/mach-spider/Kconfig b/arch/arm/mach-spider/Kconfig
>> new file mode 100644 index 000000000000..6d2f888a5fd8
>>> --- /dev/null
>>> +++ b/arch/arm/mach-spider/Kconfig
>>> @@ -0,0 +1,16 @@
>>> +# SPDX-License-Identifier: GPL-2.0-only
>>> +
>>> +if ARCH_SPIDER
>>> +
>>> +config ARCH_SPIDER_MK1
>>> + bool
>>> + select CPU_V8
>>> + help
>>> + The first Cortex-A53-based SoC of the spider family.
>>> + This symbol is invisble and select by boards
>>> +
>>> +config MACH_SPIDER_MK1_EVK
>>> + bool "Pliops Spider Reference Design Board"
>>> + select ARCH_SPIDER_MK1
>>> +
>>> +endif
>>> diff --git a/arch/arm/mach-spider/Makefile b/arch/arm/mach-
>> spider/Makefile new file mode 100644 index 000000000000..b08c4a93ca27
>>> --- /dev/null
>>> +++ b/arch/arm/mach-spider/Makefile
>>> @@ -0,0 +1 @@
>>> +lwl-y += lowlevel.o
>>> diff --git a/arch/arm/mach-spider/lowlevel.c b/arch/arm/mach-
>> spider/lowlevel.c new file mode 100644 index
>> 000000000000..5d62ef0f39e5
>>> --- /dev/null
>>> +++ b/arch/arm/mach-spider/lowlevel.c
>>> @@ -0,0 +1,14 @@
>>> +// SPDX-License-Identifier: GPL-2.0+
>>> +
>>> +#include <linux/types.h>
>>> +#include <mach/spider/lowlevel.h>
>>> +#include <asm/barebox-arm-head.h>
>>> +
>>> +void spider_lowlevel_init(void)
>>> +{
>>> + arm_cpu_lowlevel_init();
>>> + /*
>>> + * not yet relocated, only do writel/readl for stuff that's
>>> + * critical to run early. No global variables allowed.
>>> + */
>>> +}
>>> diff --git a/images/Makefile b/images/Makefile index
>> c93f9e268978..97521e713228 100644
>>> --- a/images/Makefile
>>> +++ b/images/Makefile
>>> @@ -150,6 +150,7 @@ include $(srctree)/images/Makefile.mxs include
>> $(srctree)/images/Makefile.omap3 include
>> $(srctree)/images/Makefile.rockchip
>>> include $(srctree)/images/Makefile.socfpga
>>> +include $(srctree)/images/Makefile.spider
>>> include $(srctree)/images/Makefile.stm32mp
>>> include $(srctree)/images/Makefile.tegra include
>> $(srctree)/images/Makefile.versatile
>>> diff --git a/images/Makefile.spider b/images/Makefile.spider new file mode
>> 100644 index 000000000000..c32f2762df04
>>> --- /dev/null
>>> +++ b/images/Makefile.spider
>>> @@ -0,0 +1,5 @@
>>> +# SPDX-License-Identifier: GPL-2.0-only
>>> +
>>> +pblb-$(CONFIG_MACH_SPIDER_MK1_EVK) += start_spider_mk1_evk
>>> +FILE_barebox-spider-mk1-evk.img = start_spider_mk1_evk.pblb
>>> +image-$(CONFIG_MACH_SPIDER_MK1_EVK) += barebox-spider-mk1-
>> evk.img
>>> diff --git a/include/mach/spider/lowlevel.h
>> b/include/mach/spider/lowlevel.h new file mode 100644 index
>> 000000000000..6e0ce1c77f7e
>>> --- /dev/null
>>> +++ b/include/mach/spider/lowlevel.h
>>> @@ -0,0 +1,7 @@
>>> +/* SPDX-License-Identifier: GPL-2.0+ */ #ifndef __MACH_SPIDER_H_
>>> +#define __MACH_SPIDER_H_
>>> +
>>> +void spider_lowlevel_init(void);
>>> +
>>> +#endif
>>> --
>>> 2.38.4
>>>
>>>
>>
>> --
>> Pengutronix e.K. | |
>> Steuerwalder Str. 21 | http://www.pengutronix.de/ |
>> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
>> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
>
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply [flat|nested] 40+ messages in thread
* RE: [PATCH v2] Porting barebox to a new SoC
2023-05-31 6:10 ` Ahmad Fatoum
@ 2023-05-31 8:05 ` Lior Weintraub
2023-05-31 8:40 ` Ahmad Fatoum
0 siblings, 1 reply; 40+ messages in thread
From: Lior Weintraub @ 2023-05-31 8:05 UTC (permalink / raw)
To: Ahmad Fatoum, Ahmad Fatoum, barebox
Hi Ahmad,
Thanks again for your prompt reply and accurate tips!
Took the following changes:
1. Increasing the DRAM size to 128MB (let barebox start from 0).
2. Set PBL stack to offset 2MB from DRAM
3. Fix the device tree "memory" entry to have 128MB.
4. Load barebox-spider-mk1-evk.img to SRAM and run from there.
Now I can see the following logs:
uncompress.c: memory at 0x00000000, size 0x08000000
uncompress.c: uncompressing barebox binary at 0x000000c0000021c0 (size 0x0001e3a4) to 0x07e00000 (uncompressed size: 0x000390d0)
uncompress.c: jumping to uncompressed image at 0x0000000007e00000
start.c: memory at 0x00000000, size 0x08000000
start.c: found DTB in boarddata, copying to 0x07dffcc0
start.c: initializing malloc pool at 0x079ffcc0 (size 0x00400000)
start.c: starting barebox...
initcall-> command_slice_init+0x0/0x3c
initcall-> globalvar_init+0x0/0x80
register_device: global
register_device: nv
initcall-> platform_init+0x0/0x1c
register_device: platform
initcall-> amba_bus_init+0x0/0x1c
register_device: amba
initcall-> spi_bus_init+0x0/0x1c
register_device: spi
initcall-> gpio_desc_alloc+0x0/0x24
initcall-> fs_bus_init+0x0/0x1c
register_device: fs
initcall-> aarch64_init_vectors+0x0/0x50
initcall-> gpio_gate_clock_driver_register+0x0/0x1c
register_driver: gpio-gate-clock
initcall-> of_arm_init+0x0/0x5c
start.c: barebox_arm_boot_dtb: using barebox_boarddata
using boarddata provided DTB
adding DT alias:serial0: stem=serial id=0 node=/soc/serial@d000307000
register_device: machine
of_platform_bus_create() - skipping /chosen, no compatible prop
of_platform_bus_create() - skipping /aliases, no compatible prop
of_platform_bus_create() - skipping /cpus, no compatible prop
of_platform_bus_create() - skipping /memory@0, no compatible prop
of_platform_bus_create() - skipping /soc, no compatible prop
initcall-> register_autoboot_vars+0x0/0x70
initcall-> arm_arch_timer_driver_register+0x0/0x1c
register_driver: arm-architected-timer
initcall-> of_timer_init+0x0/0x20
initcall-> init_fs+0x0/0x3c
initcall-> pl011_driver_register+0x0/0x1c
register_driver: uart-pl011
initcall-> of_stdoutpath_init+0x0/0x28
initcall-> of_probe_memory+0x0/0x60
__request_region ok: 0x00000000:0x07ffffff flags=0x0
initcall-> __bare_init_end+0x0/0x6c
register_device: mem0
initcall-> of_reserved_mem_walk+0x0/0x1ac
initcall-> mem_malloc_resource+0x0/0xa8
__request_region ok: 0x079ffcc0:0x07dffcbf flags=0x200
__request_region ok: 0x07e00000:0x07e2aeff flags=0x200
__request_region ok: 0x07e2af00:0x07e390cf flags=0x200
__request_region ok: 0x07e390d0:0x07e3adaf flags=0x200
initcall-> bootsource_init+0x0/0x40
initcall-> ramfs_init+0x0/0x1c
register_driver: ramfs
initcall-> devfs_init+0x0/0x1c
register_driver: devfs
initcall-> arm_request_stack+0x0/0x398
__request_region ok: 0x07ff0000:0x07ff7fff flags=0x200
initcall-> mount_root+0x0/0x7c
mount: none on / type ramfs, options=
register_device: ramfs0
probe-> ramfs0
mount: none on /dev type devfs, options=
register_device: devfs0
probe-> devfs0
initcall-> binfmt_sh_init+0x0/0x1c
initcall-> binfmt_uimage_init+0x0/0x1c
initcall-> console_common_init+0x0/0x48
initcall-> of_kernel_init+0x0/0x28
initcall-> console_ctrlc_init+0x0/0x30
initcall-> mem_init+0x0/0x90
register_device: mem1
register_driver: mem
probe-> mem0
probe-> mem1
initcall-> of_partition_init+0x0/0x48
initcall-> prng_init+0x0/0x40
initcall-> null_init+0x0/0x40
initcall-> full_init+0x0/0x40
initcall-> zero_init+0x0/0x40
initcall-> spider_board_driver_register+0x0/0x1c
register_driver: board-spider
probe-> machine
initcall-> barebox_memory_areas_init+0x0/0x40
__request_region ok: 0x07dffcc0:0x07dfffce flags=0x200
initcall-> barebox_of_populate+0x0/0x28
initcall-> of_register_memory_fixup+0x0/0x20
initcall-> dummy_csrc_warn+0x0/0x44
WARNING: Warning: Using dummy clocksource
initcall-> bootm_init+0x0/0xf4
initcall-> init_command_list+0x0/0x40
register command bootm
register command cat
register command cd
register command clear
register command cp
register command cpuinfo
register command devinfo
register command drvinfo
register command echo
register command exit
register command false
register command help
register command ?
register command ll
register command ls
register command md
register command memcmp
register command memcpy
register command memset
register command mkdir
register command mount
register command mw
register command pwd
register command rm
register command rmdir
register command setenv
register command sh
register command source
register command .
register command test
register command [
register command true
register command :
register command umount
register command version
initcall-> display_meminfo+0x0/0xa8
barebox code: 0x7e00000 -> 0x7e2aeff
bss segment: 0x7e390d0 -> 0x7e3adaf
malloc space: 0x079ffcc0 -> 0x07dffcbf (size 4 MiB)
initcall-> of_register_bootargs_fixup+0x0/0x3c
initcall-> device_probe_deferred+0x0/0x14c
initcall-> of_init_hostname+0x0/0x28
initcall-> aarch64_register_image_handler+0x0/0x2c
initcall-> load_environment+0x0/0x4c
loading defaultenv
environment load /dev/env0: No such file or directory
Maybe you have to create the partition.
initcalls done
Hit any to stop autoboot: 0
boot: No such file or directory
barebox:/
Few questions:
1. The serial input doesn't work. i.e. I cannot type anything hence cannot interact with barebox terminal.
Does it require GIC and setting interrupts for it to work?
2. What does "of_platform_bus_create() - skipping" means? Do I need to fix that?
3. Looks like I am still missing some stuff (rootfs? Environment? Mounting? Partitions?)
Thanks,
Have a great day,
Lior.
> -----Original Message-----
> From: Ahmad Fatoum <a.fatoum@pengutronix.de>
> Sent: Wednesday, May 31, 2023 9:11 AM
> To: Lior Weintraub <liorw@pliops.com>; Ahmad Fatoum <ahmad@a3f.at>;
> barebox@lists.infradead.org
> Subject: Re: [PATCH v2] Porting barebox to a new SoC
>
> CAUTION: External Sender
>
> Hi Lior,
>
> On 30.05.23 22:10, Lior Weintraub wrote:
> > Hello Ahmad,
> >
> > Thanks again for your kind support!
> > Your comments helped me progress and the current situation is as follows:
> > Our QEMU Spider machine is running a BL1.elf file using the following
> command:
> > QEMU_AUDIO_DRV=none qemu-system-aarch64 -M spider-soc -smp 1 -m
> 128M -nographic \
> > -device loader,file=BL1.elf -cpu cortex-a53,rvbar=0xC004000000 \
> > -d unimp -semihosting-config enable=on,target=native \
> > -monitor telnet:localhost:1235,server,nowait \
> > -gdb tcp::1236
> >
> > The BL1.elf is our BootROM application that runs from ROM address
> 0xC004000000.
> > Just for debugging purpose we've increased the ROM size so it can include
> the images/barebox-spider-mk1-evk.img (as a const array).
> > BL1 then copy it (using memcpy) to address 0 and jumps there for
> execution.
>
> Sounds ok.
>
> > On the real ASIC this address will be the DRAM and indeed will need to be
> initialized before the copy but here on QEMU it is not required.
>
> I see. You could still have your bootrom move barebox into SRAM and then
>
> barebox_arm_entry(DRAM_ADDR, SZ_128M, __dtb_spider_mk1_evk_start);
>
> To have PBL extract barebox to DRAM. Even if you don't need need DRAM
> setup in QEMU, the flow would be similar to what you will have on actual
> silicon.
>
> > The lowlevel.c of spider-evk was modified to use DRAM_ADDR 0x400000
> (4MB from start) and MY_STACK_TOP was set to 0x8000000 (128M).
>
> That's not needed. While you don't have control where barebox PBL will be
> located
> (depends on BootROM), barebox will extract itself to the end of DRAM
> without
> overwriting itself, so you can just use DRAM_ADDR 0 normally. Eventually,
> stack
> top should go into SRAM, but anywhere that works is ok.
>
> > In addition, I implemented putc_ll (currently hard-coded in
> include/debug_ll.h) and opened log level to VERBOSE_DEBUG (currently just
> hard-coded in printk.h).
>
> There's CONFIG_DEBUG_PBL you can enable to get all these messages by
> default.
>
> > I see the following (which makes sense) logs on QEMU terminal:
> > uncompress.c: memory at 0x00400000, size 0x00200000
> > uncompress.c: uncompressing barebox binary at 0x0000000000002200
> (size 0x0001d3b2) to 0x00400000 (uncompressed size: 0x000373d0)
>
> Why pass only 2M to barebox_arm_entry? While this need not be the whole
> of RAM, this
> initial memory is what barebox will use for itself including its final stack and
> malloc area. barebox will also not place itself into the last 1M AFAIK, so 2M
> may not work ok. You should use the minimum possible RAM here or if you
> can detect
> in PBL how much RAM you have or just the whole RAM bank. I am not sure
> anything lower
> than SZ_4M would work ok. (Note this is DRAM size, not SRAM. barebox PBL
> is fine being
> called from 64K SRAMs, it just needs DRAM to extract to).
>
> > I then connect with aarch64-none-elf-gdb, load the barebox symbols (to
> 0x400000) and check the current execution state (program counter and
> stack).
> > Looks like the code is stuck on function register_autoboot_vars:
> > sp 0x5f7e60 0x5f7e60
> > pc 0x401264 0x401264 <register_autoboot_vars+24>
> >
> > Few observations:
> > 1. The PBL was using stack top located on 0x8000000 (which is
> MY_STACK_TOP). Found it be causing a breakpoint on the PBL.
> > 2. Barebox uses a stack top on 0x600000 which is probably calculated from
> my new DRAM_ADDR and SZ_2M given to the function call:
> > barebox_arm_entry(DRAM_ADDR, SZ_2M, __dtb_spider_mk1_evk_start);
> >
> > This is great! I am starting to find my way.
>
> :) Ye, the ENTRY_FUNCTION_WITHSTACK is only when the BootROM doesn't
> enter
> with a valid stack pointer. It's overwritten as soon as barebox is told
> about the initial memory layout (with barebox_arm_entry).
>
> > When the barebox execution didn't print anything to the terminal I
> remembered that we used a place holder on the dtsi for the uart.
> > So now I changed it to:
> > uart0: serial@d000307000 {
> > compatible = "arm,pl011", "arm,primecell";
> > reg = <0xd0 0x307000 0 0x1000>;
> > }
> > (Our QEMU UART is currently using pl011 device.)
>
> Looks ok. Don't forget to enable the driver (via make menuconfig).
>
> > After some time (trying to debug by enabling MMU but then reverted the
> code back), I got to a point that when I try to run again I am getting an
> exception.
> > I can swear all code changes were reverted back to the point where I saw the
> barebox stuck on register_autoboot_vars but now it just cases an exception.
> > The exception vector code is located on our ROM (part of BL1 code) and the
> logs shows that the link register has the value 0x401218 which suggest the
> following code:
> > 0000000000001200 <load_environment>:
> > 1200: a9be7bfd stp x29, x30, [sp, #-32]!
> > 1204: 910003fd mov x29, sp
> > 1208: a90153f3 stp x19, x20, [sp, #16]
> > 120c: 94000a07 bl 3a28 <default_environment_path_get>
> > 1210: d00000f3 adrp x19, 1f000 <do_cpuinfo+0x1f0>
> > 1214: 912a7273 add x19, x19, #0xa9c
> > 1218: aa0003f4 mov x20, x0
> >
> > Any ideas or suggestions how to proceed with the debugging?
>
> You shouldn't need to touch the MMU code. If your initial memory setup
> is wonky, you may end up overwriting stuff. Try again with bigger memory.
>
> > BTW, to answer your questions:
> > The SRAM of 4MB is the only one we have because we assumed it is only for
> BootROM to load a PBL
>
> Ok. Sometimes there are SRAMs for use with DMA. I asked, because a SRAM
> in the first 4M
> would lend itself nicely as stack, but if there is none, we can adjust
> ENTRY_FUNCTION_WITHSTACK to accept a 64-bit parameter.
>
> Cheers,
> Ahmad
>
> > Thank you very much,
> > Cheers,
> > Lior.
> >
> >
> >> -----Original Message-----
> >> From: Ahmad Fatoum <a.fatoum@pengutronix.de>
> >> Sent: Monday, May 29, 2023 10:03 PM
> >> To: Lior Weintraub <liorw@pliops.com>; Ahmad Fatoum <ahmad@a3f.at>;
> >> barebox@lists.infradead.org
> >> Subject: Re: [PATCH v2] Porting barebox to a new SoC
> >>
> >> CAUTION: External Sender
> >>
> >> Hello Lior,
> >>
> >> On 29.05.23 15:34, Lior Weintraub wrote:
> >>> Hi Ahmad,
> >>>
> >>> I have revised the addresses and used DRAM address @ 0 instead:
> >>> #define UARTBASE (0xD000307000)
> >>> #define DRAM_ADDR (0x00000000)
> >>> #define MY_STACK_TOP (0x00000000 + SZ_2M) // Set the stack 2MB
> from
> >> DRAM start
> >>
> >> Is DRAM configured by the time barebox runs? If not, you should keep
> stack
> >> top
> >> in SRAM, until you have setup memory in prebootloader (PBL). Is the 4M
> >> SRAM
> >> the only on-chip SRAM you have?
> >>
> >>> static inline void spider_serial_putc(void *base, int c)
> >>> {
> >>> *((volatile unsigned *)base) = c;
> >>
> >> There's a helper for that: writel(c, base); In barebox, it's equivalent
> >> to the volatile access, but in Linux it involves a write memory barrier.
> >> We try to write code in barebox, so it's easily reusable in Linux (and
> >> the other way round).
> >>
> >>> }
> >>>
> >>> I will try to test it on QEMU using an initial QEMU machine we made for
> >> Spider.
> >>> In this machine we only have 3 memory regions and a PL011 UART:
> >>> spider_soc_memories soc_memories[] = {
> >>> {.name = "SPIDER_GPRAM", .add = 0xC000000000ULL, .size = 4 * MiB},
> >>> {.name = "SPIDER_ROM", .add = 0xC004000000ULL, .size = 128 *
> KiB},
> >>> {.name = "SPIDER_DRAM", .add = 0x0000000000ULL, .size = 1 * GiB},
> >>> };
> >>>
> >>> This special QEMU machine can run our BL1 code from "ROM" address
> (we
> >> set the RVBAR to point there).
> >>> So my idea is to test the barebox image by the following steps:
> >>> 1. Modify the QEMU code to have a "ROM" with the size of 128M.
> >>> 2. Compile our BL1 code to include the barebox.bin as a const array, copy
> it
> >> to "DRAM" @ address 0 and jump there.
> >>
> >> Why not map QEMU -bios option to SRAM? (Or DRAM directly, if it needs
> no
> >> special setup from
> >> barebox side).
> >>
> >>> For this to work I wanted to understand how to call (i.e. what arguments
> to
> >> pass) to barebox.
> >>
> >> barebox doesn't expect any arguments, because most BootROMs don't
> pass
> >> anything useful.
> >> Some pass information about bootsource though, so that's why the
> >> ENTRY_FUNCTION has
> >> r0, r1 and r2 as parameters, but you need not use them.
> >>
> >>> So I checked the barebox.map and found the function "start" on address
> 0.
> >>
> >> You may know that Linux on some platforms comes with a decompressor
> that
> >> is glued to the
> >> front of the kernel image and extracts the compressed kernel image.
> barebox
> >> has the same
> >> concept. The prebootloader is uncompressed and runs (starting from
> >> ENTRY_FUNCTION) and
> >> then does some early setup (e.g. enable clocks, configure PMIC, setup
> DRAM,
> >> load secure
> >> monitor (BL31), ...etc.) and then it decompresses barebox proper into
> DRAM.
> >>
> >> barebox.bin <- barebox proper. You don't usually need that.
> >> barebox.elf <- ELF binary for the above (for gdb)
> >> barebox.map <- map file of the above
> >>
> >> images/barebox-spider-mk1-evk.img <- complete barebox image (PBL +
> >> barebox proper)
> >> images/start_spider_mk1_evk.pbl <- ELF image for the above
> >> images/start_spider_mk1_evk.pbl.map <- map file of the above
> >>
> >> If you want to follow barbeox from the start, begin at
> start_spider_mk1_evk.
> >>
> >>> Then I went to arch/arm/cpu/start.c and realized that the code is compiled
> >> with CONFIG_PBL_IMAGE.
> >>> In that case I assume I need to pass 3 arguments and use this function
> >> prototype:
> >>> void start(unsigned long membase, unsigned long memsize, void
> >> *boarddata);
> >>
> >> barebox prebootloader takes care of this, so you don't need to do anything.
> >>
> >>> Few questions:
> >>> 1. Will that call work:
> >>> typedef void (*barebox_start)(unsigned long , unsigned long , void *);
> >>> #define DRAM_START (0)
> >>> barebox_start p_barebox = (barebox_start)DRAM_START;
> >>> p_barebox(DRAM_START, DRAM_START+SZ_2M, (void
> >> *)(DRAM_START+SZ_4M));
> >>> This assumes that my BL1 code also copied the device tree (barebox-dt-
> >> 2nd.img? start_dt_2nd.pblb? start_spider_mk1_evk.pblb?)
> >>
> >> The device tree is built into the PBL and passed to barebox proper. This
> >> allows us to use the same barebox proper binary and link it with a different
> >> prebootloader for each SoC/board, all in the same build.
> >>
> >> barebox-dt-2nd.img is a special image that looks exactly like a Linux kernel:
> >>
> >> images/barebox-dt-2nd.img: Linux kernel ARM64 boot executable Image,
> >> little-endian, 4K pages
> >>
> >> and can thus be used for booting for easy chainloading from other
> >> bootloaders or for running
> >> with QEMU -kernel. You shouldn't need it right now.
> >>
> >>> 2. Do I want to have my code compiled with CONFIG_PBL_IMAGE?
> >>> If I understand correctly, it means that my code will provide a PBL (a.k.a
> >> BL2) which will set the DRAM and STACK among other things (MMU?).
> >>
> >> The patch I sent already builds a PBL. You will need to fill out
> >> start_spider_mk1_evk
> >> to do all the other early initialization you need. Then you call
> >> barebox_arm_entry
> >> with device tree and memory size and it will take care to do stack setup in
> new
> >> memory region, MMU setup (if enabled) and chainloading barebox proper.
> >>
> >> Note that PBL isn't necessary BL2. You can chainload barebox from within
> >> barebox (i.e.
> >> in EL2 or EL1), which is useful for debugging. You will thus often find PBL
> code
> >> that
> >> does
> >>
> >> if (current_el() == 3) {
> >> /* Do BL2 setup */
> >> chainload();
> >> __builtin_unreachable();
> >> }
> >>
> >> barebox_arm_entry(...)
> >>
> >> See for example arch/arm/boards/innocomm-imx8mm-wb15/lowlevel.c
> >>
> >> to see a real-world example of another Cortex-A53.
> >>
> >>> In that case I assume it is OK.
> >>> 3. If I try to remove it by having CONFIG_PBL_IMAGE=n on
> spider_defconfig
> >> this doesn't do anything
> >>> The build (make spider_defconfig) ignores it and say that " No change to
> >> .config ".
> >>
> >> Another symbol forces it to be enabled. If you are curious, run make
> >> menuconfig
> >> and then search (/) for the symbol and it will list, whether it's enabled and
> >> why:
> >>
> >> Selected by [y]:
> >> - PBL_MULTI_IMAGES [=y] && HAVE_PBL_MULTI_IMAGES [=y]
> >>
> >> I'd suggest you avoid modifying the .config file manually. always use
> >> menuconfig.
> >>
> >>> 4. I also tried to understand how to implement PUTC_LL but not sure I
> >> understand.
> >>> 4.1 When I set "CONFIG_DEBUG_LL=y" on spider_defconfig it is again
> not
> >> written to .config and I get " No change to .config " message.
> >>
> >> You must:
> >>
> >> - select HAS_DEBUG_LL from MACH_SPIDER
> >> - Add your arch to arch/arm/include/asm/debug_ll.h
> >> - Then implement PUTC_LL in e.g. mach/spider/debug_ll.h
> >>
> >>> 4.2 Do I need to have my own debug_ll.h file?
> >>
> >> Yes. See above.
> >>
> >>> 5. When I make changes to spider_defconfig and try to regenerate the
> >> .config and I get " No change to .config " message, does it mean that those
> >> macros are "hidden" symbols like you said about the CONFIG_CPU_V8?
> >>
> >> Yes. Just check menuconfig to see how symbols relate to each other.
> >> This is 1:1 like it's in Linux, so it'll come in handy when you do
> >> the kernel port too ;)
> >>
> >>> Apologize for so many questions :-)
> >>
> >> No problem. Looking forward to your patches ;)
> >>
> >>
> >> Cheers,
> >> Ahmad
> >>
> >>> Cheers,
> >>> Lior.
> >>>
> >>> -----Original Message-----
> >>> From: Lior Weintraub
> >>> Sent: Sunday, May 28, 2023 11:16 PM
> >>> To: Ahmad Fatoum <ahmad@a3f.at>; barebox@lists.infradead.org
> >>> Subject: RE: [PATCH v2] Porting barebox to a new SoC
> >>>
> >>> Hi Ahmad,
> >>>
> >>> Thank you so much for your kind support!
> >>>
> >>> Indeed we also have a 16GB DRAM that starts from address 0 (though
> >> currently we don't have the controller settings (under development)).
> >>>
> >>> I also wrote the BootROM (BL1) for this SoC (128KB ROM @ address
> >> 0xC004000000).
> >>> I understand now that it would be best for me to develop BL2 that will run
> >> from our SRAM.
> >>>
> >>> As this BL2 code is bare-metal I have no problem or limitations with the 40
> >> bit addresses.
> >>> The BL2 code will initialize the DRAM controller and then copy Barebox
> image
> >> from NOR Flash to address 0 of the DRAM.
> >>> Our NOR Flash is 128MB in size and it is accessed via QSPI controller.
> >>>
> >>> I tried applying your suggested patch but got an error while doing so:
> >>> $git apply 0002-Ahmad.patch
> >>> 0002-Ahmad.patch:115: trailing whitespace.
> >>> .of_compatible = spider_board_of_match, };
> >>> error: corrupt patch at line 117
> >>>
> >>> After some digging I found that my Outlook probably messed with the
> patch
> >> format (even though I am using text only and no HTML format).
> >>> When I went to the web and copied the patch from there (mailing list
> >> archive) it was working well (i.e. no compilation error).
> >>>
> >>> Cheers,
> >>> Lior.
> >>>
> >>> -----Original Message-----
> >>> From: Ahmad Fatoum <ahmad@a3f.at>
> >>> Sent: Sunday, May 28, 2023 6:38 PM
> >>> To: barebox@lists.infradead.org
> >>> Cc: Lior Weintraub <liorw@pliops.com>
> >>> Subject: [PATCH v2] Porting barebox to a new SoC
> >>>
> >>> CAUTION: External Sender
> >>>
> >>> From: Lior Weintraub <liorw@pliops.com>
> >>>
> >>> Hi,
> >>>
> >>> I tried to follow the porting guide on https://ddec1-0-en-
> >>
> ctp.trendmicro.com:443/wis/clicktime/v1/query?url=https%3a%2f%2fwww.
> >>
> barebox.org%2fdoc%2flatest%2fdevel%2fporting.html%23&umid=60097eda
> >> -f136-45a1-9c8e-
> >> cf6a76e45cf8&auth=860a7ebb9feba264acc79b6e38eb59582349362c-
> >> 480ae23736add41c88ab8d30c090a75517ca7f9e but couldn't follow the
> >> instructions.
> >>> I would like to port barebox to a new SoC (which is not a derivative of any
> >> known SoC).
> >>> It has the following:
> >>> * Single Cortex A53
> >>> * SRAM (4MB) located on address 0xC000000000
> >>>
> >>> The below patch shows my initial test to try and have a starting point.
> >>> I am setting env variables:
> >>> export ARCH=arm64
> >>> export CROSS_COMPILE=/home/pliops/workspace/ARM/arm-gnu-
> >> toolchain/bin/aarch64-none-elf-
> >>>
> >>> Then I build with:
> >>> make spider_defconfig && make
> >>>
> >>> This gives an error:
> >>> aarch64-none-elf-gcc: error: unrecognized argument in option '-
> mabi=apcs-
> >> gnu'
> >>> aarch64-none-elf-gcc: note: valid arguments to '-mabi=' are: ilp32 lp64
> >>> aarch64-none-elf-gcc: error: unrecognized command-line option '-msoft-
> >> float'
> >>> aarch64-none-elf-gcc: error: unrecognized command-line option '-mno-
> >> unaligned-access'
> >>> /home/pliops/workspace/simplest-linux-
> >> demo/barebox/scripts/Makefile.build:140: recipe for target
> >> 'scripts/mod/empty.o' failed
> >>> make[2]: *** [scripts/mod/empty.o] Error 1
> >>>
> >>> Not sure why the compiler flags get -mabi=apcs-gnu when I explicitly set
> >> CONFIG_CPU_V8 and the arch/arm/Makefile has:
> >>> ifeq ($(CONFIG_CPU_V8), y)
> >>> CFLAGS_ABI :=-mabi=lp64
> >>>
> >>> The changes I did:
> >>> >From 848b5f9b18bb1bb96d197cbc1b368ee0a729d581 Mon Sep 17
> >> 00:00:00 2001
> >>> ---
> >>> arch/arm/Kconfig | 13 ++++++++
> >>> arch/arm/Makefile | 1 +
> >>> arch/arm/boards/Makefile | 1 +
> >>> arch/arm/boards/spider-evk/Makefile | 4 +++
> >>> arch/arm/boards/spider-evk/board.c | 26 +++++++++++++++
> >>> arch/arm/boards/spider-evk/lowlevel.c | 30 +++++++++++++++++
> >>> arch/arm/configs/spider_defconfig | 8 +++++
> >>> arch/arm/dts/Makefile | 1 +
> >>> arch/arm/dts/spider-mk1-evk.dts | 10 ++++++
> >>> arch/arm/dts/spider-mk1.dtsi | 46 +++++++++++++++++++++++++++
> >>> arch/arm/mach-spider/Kconfig | 16 ++++++++++
> >>> arch/arm/mach-spider/Makefile | 1 +
> >>> arch/arm/mach-spider/lowlevel.c | 14 ++++++++
> >>> images/Makefile | 1 +
> >>> images/Makefile.spider | 5 +++
> >>> include/mach/spider/lowlevel.h | 7 ++++
> >>> 16 files changed, 184 insertions(+)
> >>> create mode 100644 arch/arm/boards/spider-evk/Makefile
> >>> create mode 100644 arch/arm/boards/spider-evk/board.c
> >>> create mode 100644 arch/arm/boards/spider-evk/lowlevel.c
> >>> create mode 100644 arch/arm/configs/spider_defconfig create mode
> >> 100644 arch/arm/dts/spider-mk1-evk.dts create mode 100644
> >> arch/arm/dts/spider-mk1.dtsi create mode 100644 arch/arm/mach-
> >> spider/Kconfig create mode 100644 arch/arm/mach-spider/Makefile
> create
> >> mode 100644 arch/arm/mach-spider/lowlevel.c create mode 100644
> >> images/Makefile.spider create mode 100644
> include/mach/spider/lowlevel.h
> >>>
> >>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index
> >> e76ee0f6dfe1..e5dcf128447e 100644
> >>> --- a/arch/arm/Kconfig
> >>> +++ b/arch/arm/Kconfig
> >>> @@ -255,6 +255,18 @@ config ARCH_ROCKCHIP
> >>> select HAS_DEBUG_LL
> >>> imply GPIO_ROCKCHIP
> >>>
> >>> +config ARCH_SPIDER
> >>> + bool "Pliops Spider based"
> >>> + depends on 64BIT
> >>> + depends on ARCH_MULTIARCH
> >>> + select GPIOLIB
> >>> + select HAVE_PBL_MULTI_IMAGES
> >>> + select COMMON_CLK
> >>> + select CLKDEV_LOOKUP
> >>> + select COMMON_CLK_OF_PROVIDER
> >>> + select OFTREE
> >>> + select OFDEVICE
> >>> +
> >>> config ARCH_STM32MP
> >>> bool "STMicroelectronics STM32MP"
> >>> depends on 32BIT
> >>> @@ -331,6 +343,7 @@ source "arch/arm/mach-omap/Kconfig"
> >>> source "arch/arm/mach-pxa/Kconfig"
> >>> source "arch/arm/mach-rockchip/Kconfig"
> >>> source "arch/arm/mach-socfpga/Kconfig"
> >>> +source "arch/arm/mach-spider/Kconfig"
> >>> source "arch/arm/mach-stm32mp/Kconfig"
> >>> source "arch/arm/mach-versatile/Kconfig"
> >>> source "arch/arm/mach-vexpress/Kconfig"
> >>> diff --git a/arch/arm/Makefile b/arch/arm/Makefile index
> >> 35ebc70f44e2..4c63dfee48f4 100644
> >>> --- a/arch/arm/Makefile
> >>> +++ b/arch/arm/Makefile
> >>> @@ -101,6 +101,7 @@ machine-$(CONFIG_ARCH_MXS) += mxs
> >>> machine-$(CONFIG_ARCH_MVEBU) += mvebu
> >>> machine-$(CONFIG_ARCH_NOMADIK) += nomadik
> >>> machine-$(CONFIG_ARCH_OMAP) += omap
> >>> +machine-$(CONFIG_ARCH_SPIDER) += spider
> >>> machine-$(CONFIG_ARCH_PXA) += pxa
> >>> machine-$(CONFIG_ARCH_ROCKCHIP) += rockchip
> >>> machine-$(CONFIG_ARCH_SAMSUNG) += samsung
> >>> diff --git a/arch/arm/boards/Makefile b/arch/arm/boards/Makefile index
> >> 2877debad535..6fe0a90c81ea 100644
> >>> --- a/arch/arm/boards/Makefile
> >>> +++ b/arch/arm/boards/Makefile
> >>> @@ -135,6 +135,7 @@ obj-
> >> $(CONFIG_MACH_SOCFPGA_TERASIC_DE10_NANO) += terasic-de10-
> >> nano/
> >>> obj-$(CONFIG_MACH_SOCFPGA_TERASIC_SOCKIT) += terasic-sockit/
> >>> obj-$(CONFIG_MACH_SOLIDRUN_CUBOX) += solidrun-cubox/
> >>> obj-$(CONFIG_MACH_SOLIDRUN_MICROSOM) += solidrun-
> >> microsom/
> >>> +obj-$(CONFIG_MACH_SPIDER_MK1_EVK) += spider-evk/
> >>> obj-$(CONFIG_MACH_STM32MP15XX_DKX) += stm32mp15xx-
> dkx/
> >>> obj-$(CONFIG_MACH_STM32MP13XX_DK) += stm32mp13xx-dk/
> >>> obj-$(CONFIG_MACH_LXA_MC1) += lxa-mc1/
> >>> diff --git a/arch/arm/boards/spider-evk/Makefile
> >> b/arch/arm/boards/spider-evk/Makefile
> >>> new file mode 100644
> >>> index 000000000000..da63d2625f7a
> >>> --- /dev/null
> >>> +++ b/arch/arm/boards/spider-evk/Makefile
> >>> @@ -0,0 +1,4 @@
> >>> +# SPDX-License-Identifier: GPL-2.0-only
> >>> +
> >>> +obj-y += board.o
> >>> +lwl-y += lowlevel.o
> >>> diff --git a/arch/arm/boards/spider-evk/board.c
> b/arch/arm/boards/spider-
> >> evk/board.c
> >>> new file mode 100644
> >>> index 000000000000..3920e83b457d
> >>> --- /dev/null
> >>> +++ b/arch/arm/boards/spider-evk/board.c
> >>> @@ -0,0 +1,26 @@
> >>> +#include <bbu.h>
> >>> +#include <boot.h>
> >>> +#include <bootm.h>
> >>> +#include <common.h>
> >>> +#include <deep-probe.h>
> >>> +#include <environment.h>
> >>> +#include <fcntl.h>
> >>> +#include <globalvar.h>
> >>> +
> >>> +static int spider_board_probe(struct device *dev) {
> >>> + /* Do some board-specific setup */
> >>> + return 0;
> >>> +}
> >>> +
> >>> +static const struct of_device_id spider_board_of_match[] = {
> >>> + { .compatible = "pliops,spider-mk1-evk" },
> >>> + { /* sentinel */ },
> >>> +};
> >>> +
> >>> +static struct driver spider_board_driver = {
> >>> + .name = "board-spider",
> >>> + .probe = spider_board_probe,
> >>> + .of_compatible = spider_board_of_match, };
> >>> +device_platform_driver(spider_board_driver);
> >>> diff --git a/arch/arm/boards/spider-evk/lowlevel.c
> >> b/arch/arm/boards/spider-evk/lowlevel.c
> >>> new file mode 100644
> >>> index 000000000000..e36fcde4208e
> >>> --- /dev/null
> >>> +++ b/arch/arm/boards/spider-evk/lowlevel.c
> >>> @@ -0,0 +1,30 @@
> >>> +#include <common.h>
> >>> +#include <asm/barebox-arm.h>
> >>> +#include <mach/spider/lowlevel.h>
> >>> +
> >>> +#define BASE_ADDR (0xD000307000)
> >>> +#define GPRAM_ADDR (0xC000000000)
> >>> +#define MY_STACK_TOP (0xC000000000 + SZ_2M) // Set the stack
> 2MB
> >> from GPRAM start (excatly in the middle)
> >>> +static inline void spider_serial_putc(void *base, int c) {
> >>> +// if (!(readl(base + UCR1) & UCR1_UARTEN))
> >>> +// return;
> >>> +//
> >>> +// while (!(readl(base + USR2) & USR2_TXDC));
> >>> +//
> >>> +// writel(c, base + URTX0);
> >>> +}
> >>> +
> >>> +ENTRY_FUNCTION_WITHSTACK(start_spider_mk1_evk, MY_STACK_TOP,
> >> r0, r1,
> >>> +r2) {
> >>> + extern char __dtb_spider_mk1_evk_start[];
> >>> +
> >>> + spider_lowlevel_init();
> >>> +
> >>> + relocate_to_current_adr();
> >>> + setup_c();
> >>> +
> >>> + pbl_set_putc(spider_serial_putc, (void *)BASE_ADDR);
> >>> +
> >>> + barebox_arm_entry(GPRAM_ADDR, SZ_2M,
> >>> +__dtb_spider_mk1_evk_start); }
> >>> diff --git a/arch/arm/configs/spider_defconfig
> >> b/arch/arm/configs/spider_defconfig
> >>> new file mode 100644
> >>> index 000000000000..c91bb889d97f
> >>> --- /dev/null
> >>> +++ b/arch/arm/configs/spider_defconfig
> >>> @@ -0,0 +1,8 @@
> >>> +CONFIG_ARCH_SPIDER=y
> >>> +CONFIG_MACH_SPIDER_MK1_EVK=y
> >>> +CONFIG_BOARD_ARM_GENERIC_DT=y
> >>> +CONFIG_MALLOC_TLSF=y
> >>> +CONFIG_KALLSYMS=y
> >>> +CONFIG_RELOCATABLE=y
> >>> +CONFIG_CONSOLE_ALLOW_COLOR=y
> >>> +CONFIG_PBL_CONSOLE=y
> >>> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile index
> >> 98f4c4e0194b..94b304d4878f 100644
> >>> --- a/arch/arm/dts/Makefile
> >>> +++ b/arch/arm/dts/Makefile
> >>> @@ -134,6 +134,7 @@ lwl-$(CONFIG_MACH_SOLIDRUN_CUBOX) +=
> dove-
> >> cubox-bb.dtb.o
> >>> lwl-$(CONFIG_MACH_SOLIDRUN_MICROSOM) += imx6dl-
> >> hummingboard.dtb.o imx6q-hummingboard.dtb.o \
> >>> imx6dl-hummingboard2.dtb.o imx6q-
> >> hummingboard2.dtb.o \
> >>> imx6q-h100.dtb.o
> >>> +lwl-$(CONFIG_MACH_SPIDER_MK1_EVK) += spider-mk1-evk.dtb.o
> >>> lwl-$(CONFIG_MACH_SKOV_IMX6) += imx6s-skov-imx6.dtb.o imx6dl-
> skov-
> >> imx6.dtb.o imx6q-skov-imx6.dtb.o
> >>> lwl-$(CONFIG_MACH_SKOV_ARM9CPU) += at91-skov-arm9cpu.dtb.o
> >>> lwl-$(CONFIG_MACH_SEEED_ODYSSEY) += stm32mp157c-odyssey.dtb.o
> >> diff --git a/arch/arm/dts/spider-mk1-evk.dts b/arch/arm/dts/spider-mk1-
> >> evk.dts new file mode 100644 index 000000000000..b8081cb85bf8
> >>> --- /dev/null
> >>> +++ b/arch/arm/dts/spider-mk1-evk.dts
> >>> @@ -0,0 +1,10 @@
> >>> +// SPDX-License-Identifier: GPL-2.0 OR X11
> >>> +
> >>> +/dts-v1/;
> >>> +
> >>> +#include "spider-mk1.dtsi"
> >>> +
> >>> +/ {
> >>> + model = "Pliops Spider MK-I EVK";
> >>> + compatible = "pliops,spider-mk1-evk"; };
> >>> diff --git a/arch/arm/dts/spider-mk1.dtsi b/arch/arm/dts/spider-mk1.dtsi
> >> new file mode 100644 index 000000000000..d4613848169d
> >>> --- /dev/null
> >>> +++ b/arch/arm/dts/spider-mk1.dtsi
> >>> @@ -0,0 +1,46 @@
> >>> +// SPDX-License-Identifier: GPL-2.0 OR X11
> >>> +
> >>> +/ {
> >>> + #address-cells = <2>;
> >>> + #size-cells = <2>;
> >>> +
> >>> + chosen {
> >>> + stdout-path = &uart0;
> >>> + };
> >>> +
> >>> + aliases {
> >>> + serial0 = &uart0;
> >>> + };
> >>> +
> >>> + cpus {
> >>> + #address-cells = <1>;
> >>> + #size-cells = <0>;
> >>> +
> >>> + cpu0: cpu@0 {
> >>> + device_type = "cpu";
> >>> + compatible = "arm,cortex-a53";
> >>> + reg = <0x0>;
> >>> + };
> >>> + };
> >>> +
> >>> + memory@1000000 {
> >>> + reg = <0x0 0x1000000 0x0 0x400000>; /* 128M */
> >>> + device_type = "memory";
> >>> + };
> >>> +
> >>> + soc {
> >>> + #address-cells = <2>;
> >>> + #size-cells = <2>;
> >>> + ranges;
> >>> +
> >>> + sram@c000000000 {
> >>> + compatible = "mmio-sram";
> >>> + reg = <0xc0 0x0 0x0 0x400000>;
> >>> + };
> >>> +
> >>> + uart0: serial@d000307000 {
> >>> + compatible = "pliops,spider-uart";
> >>> + reg = <0xd0 0x307000 0 0x1000>;
> >>> + };
> >>> + };
> >>> +};
> >>> diff --git a/arch/arm/mach-spider/Kconfig b/arch/arm/mach-
> spider/Kconfig
> >> new file mode 100644 index 000000000000..6d2f888a5fd8
> >>> --- /dev/null
> >>> +++ b/arch/arm/mach-spider/Kconfig
> >>> @@ -0,0 +1,16 @@
> >>> +# SPDX-License-Identifier: GPL-2.0-only
> >>> +
> >>> +if ARCH_SPIDER
> >>> +
> >>> +config ARCH_SPIDER_MK1
> >>> + bool
> >>> + select CPU_V8
> >>> + help
> >>> + The first Cortex-A53-based SoC of the spider family.
> >>> + This symbol is invisble and select by boards
> >>> +
> >>> +config MACH_SPIDER_MK1_EVK
> >>> + bool "Pliops Spider Reference Design Board"
> >>> + select ARCH_SPIDER_MK1
> >>> +
> >>> +endif
> >>> diff --git a/arch/arm/mach-spider/Makefile b/arch/arm/mach-
> >> spider/Makefile new file mode 100644 index
> 000000000000..b08c4a93ca27
> >>> --- /dev/null
> >>> +++ b/arch/arm/mach-spider/Makefile
> >>> @@ -0,0 +1 @@
> >>> +lwl-y += lowlevel.o
> >>> diff --git a/arch/arm/mach-spider/lowlevel.c b/arch/arm/mach-
> >> spider/lowlevel.c new file mode 100644 index
> >> 000000000000..5d62ef0f39e5
> >>> --- /dev/null
> >>> +++ b/arch/arm/mach-spider/lowlevel.c
> >>> @@ -0,0 +1,14 @@
> >>> +// SPDX-License-Identifier: GPL-2.0+
> >>> +
> >>> +#include <linux/types.h>
> >>> +#include <mach/spider/lowlevel.h>
> >>> +#include <asm/barebox-arm-head.h>
> >>> +
> >>> +void spider_lowlevel_init(void)
> >>> +{
> >>> + arm_cpu_lowlevel_init();
> >>> + /*
> >>> + * not yet relocated, only do writel/readl for stuff that's
> >>> + * critical to run early. No global variables allowed.
> >>> + */
> >>> +}
> >>> diff --git a/images/Makefile b/images/Makefile index
> >> c93f9e268978..97521e713228 100644
> >>> --- a/images/Makefile
> >>> +++ b/images/Makefile
> >>> @@ -150,6 +150,7 @@ include $(srctree)/images/Makefile.mxs include
> >> $(srctree)/images/Makefile.omap3 include
> >> $(srctree)/images/Makefile.rockchip
> >>> include $(srctree)/images/Makefile.socfpga
> >>> +include $(srctree)/images/Makefile.spider
> >>> include $(srctree)/images/Makefile.stm32mp
> >>> include $(srctree)/images/Makefile.tegra include
> >> $(srctree)/images/Makefile.versatile
> >>> diff --git a/images/Makefile.spider b/images/Makefile.spider new file
> mode
> >> 100644 index 000000000000..c32f2762df04
> >>> --- /dev/null
> >>> +++ b/images/Makefile.spider
> >>> @@ -0,0 +1,5 @@
> >>> +# SPDX-License-Identifier: GPL-2.0-only
> >>> +
> >>> +pblb-$(CONFIG_MACH_SPIDER_MK1_EVK) += start_spider_mk1_evk
> >>> +FILE_barebox-spider-mk1-evk.img = start_spider_mk1_evk.pblb
> >>> +image-$(CONFIG_MACH_SPIDER_MK1_EVK) += barebox-spider-mk1-
> >> evk.img
> >>> diff --git a/include/mach/spider/lowlevel.h
> >> b/include/mach/spider/lowlevel.h new file mode 100644 index
> >> 000000000000..6e0ce1c77f7e
> >>> --- /dev/null
> >>> +++ b/include/mach/spider/lowlevel.h
> >>> @@ -0,0 +1,7 @@
> >>> +/* SPDX-License-Identifier: GPL-2.0+ */ #ifndef __MACH_SPIDER_H_
> >>> +#define __MACH_SPIDER_H_
> >>> +
> >>> +void spider_lowlevel_init(void);
> >>> +
> >>> +#endif
> >>> --
> >>> 2.38.4
> >>>
> >>>
> >>
> >> --
> >> Pengutronix e.K. | |
> >> Steuerwalder Str. 21 | http://www.pengutronix.de/ |
> >> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
> >> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
> >
>
> --
> Pengutronix e.K. | |
> Steuerwalder Str. 21 | http://www.pengutronix.de/ |
> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [PATCH v2] Porting barebox to a new SoC
2023-05-31 8:05 ` Lior Weintraub
@ 2023-05-31 8:40 ` Ahmad Fatoum
2023-05-31 16:13 ` Lior Weintraub
0 siblings, 1 reply; 40+ messages in thread
From: Ahmad Fatoum @ 2023-05-31 8:40 UTC (permalink / raw)
To: Lior Weintraub, Ahmad Fatoum, barebox
Hi Lior,
On 31.05.23 10:05, Lior Weintraub wrote:
> Hi Ahmad,
>
> Thanks again for your prompt reply and accurate tips!
> Took the following changes:
> 1. Increasing the DRAM size to 128MB (let barebox start from 0).
> 2. Set PBL stack to offset 2MB from DRAM
Just use end of SRAM, so you are completely independent of DRAM
until you call barebox_arm_entry.
> 3. Fix the device tree "memory" entry to have 128MB.
(y)
> 4. Load barebox-spider-mk1-evk.img to SRAM and run from there.
>
> Now I can see the following logs:
> uncompress.c: memory at 0x00000000, size 0x08000000
> uncompress.c: uncompressing barebox binary at 0x000000c0000021c0 (size 0x0001e3a4) to 0x07e00000 (uncompressed size: 0x000390d0)
> uncompress.c: jumping to uncompressed image at 0x0000000007e00000
> start.c: memory at 0x00000000, size 0x08000000
> start.c: found DTB in boarddata, copying to 0x07dffcc0
> start.c: initializing malloc pool at 0x079ffcc0 (size 0x00400000)
> start.c: starting barebox...
> initcall-> command_slice_init+0x0/0x3c
> initcall-> globalvar_init+0x0/0x80
> register_device: global
> register_device: nv
> initcall-> platform_init+0x0/0x1c
> register_device: platform
> initcall-> amba_bus_init+0x0/0x1c
> register_device: amba
> initcall-> spi_bus_init+0x0/0x1c
> register_device: spi
> initcall-> gpio_desc_alloc+0x0/0x24
> initcall-> fs_bus_init+0x0/0x1c
> register_device: fs
> initcall-> aarch64_init_vectors+0x0/0x50
> initcall-> gpio_gate_clock_driver_register+0x0/0x1c
> register_driver: gpio-gate-clock
> initcall-> of_arm_init+0x0/0x5c
> start.c: barebox_arm_boot_dtb: using barebox_boarddata
> using boarddata provided DTB
> adding DT alias:serial0: stem=serial id=0 node=/soc/serial@d000307000
> register_device: machine
> of_platform_bus_create() - skipping /chosen, no compatible prop
> of_platform_bus_create() - skipping /aliases, no compatible prop
> of_platform_bus_create() - skipping /cpus, no compatible prop
> of_platform_bus_create() - skipping /memory@0, no compatible prop
> of_platform_bus_create() - skipping /soc, no compatible prop
> initcall-> register_autoboot_vars+0x0/0x70
> initcall-> arm_arch_timer_driver_register+0x0/0x1c
> register_driver: arm-architected-timer
> initcall-> of_timer_init+0x0/0x20
> initcall-> init_fs+0x0/0x3c
> initcall-> pl011_driver_register+0x0/0x1c
> register_driver: uart-pl011
> initcall-> of_stdoutpath_init+0x0/0x28
> initcall-> of_probe_memory+0x0/0x60
> __request_region ok: 0x00000000:0x07ffffff flags=0x0
> initcall-> __bare_init_end+0x0/0x6c
> register_device: mem0
> initcall-> of_reserved_mem_walk+0x0/0x1ac
> initcall-> mem_malloc_resource+0x0/0xa8
> __request_region ok: 0x079ffcc0:0x07dffcbf flags=0x200
> __request_region ok: 0x07e00000:0x07e2aeff flags=0x200
> __request_region ok: 0x07e2af00:0x07e390cf flags=0x200
> __request_region ok: 0x07e390d0:0x07e3adaf flags=0x200
> initcall-> bootsource_init+0x0/0x40
> initcall-> ramfs_init+0x0/0x1c
> register_driver: ramfs
> initcall-> devfs_init+0x0/0x1c
> register_driver: devfs
> initcall-> arm_request_stack+0x0/0x398
> __request_region ok: 0x07ff0000:0x07ff7fff flags=0x200
> initcall-> mount_root+0x0/0x7c
> mount: none on / type ramfs, options=
> register_device: ramfs0
> probe-> ramfs0
> mount: none on /dev type devfs, options=
> register_device: devfs0
> probe-> devfs0
> initcall-> binfmt_sh_init+0x0/0x1c
> initcall-> binfmt_uimage_init+0x0/0x1c
> initcall-> console_common_init+0x0/0x48
> initcall-> of_kernel_init+0x0/0x28
> initcall-> console_ctrlc_init+0x0/0x30
> initcall-> mem_init+0x0/0x90
> register_device: mem1
> register_driver: mem
> probe-> mem0
> probe-> mem1
> initcall-> of_partition_init+0x0/0x48
> initcall-> prng_init+0x0/0x40
> initcall-> null_init+0x0/0x40
> initcall-> full_init+0x0/0x40
> initcall-> zero_init+0x0/0x40
> initcall-> spider_board_driver_register+0x0/0x1c
> register_driver: board-spider
> probe-> machine
> initcall-> barebox_memory_areas_init+0x0/0x40
> __request_region ok: 0x07dffcc0:0x07dfffce flags=0x200
> initcall-> barebox_of_populate+0x0/0x28
> initcall-> of_register_memory_fixup+0x0/0x20
> initcall-> dummy_csrc_warn+0x0/0x44
> WARNING: Warning: Using dummy clocksource
Add a arm,armv8-timer node into your SoC device tree.
This lets barebox and Linux know that you have the ARM
architected timer available. Without that, you'll notice
that timeouts are wrong.
> initcall-> bootm_init+0x0/0xf4
> initcall-> init_command_list+0x0/0x40
> register command bootm
> register command cat
> register command cd
> register command clear
> register command cp
> register command cpuinfo
> register command devinfo
> register command drvinfo
> register command echo
> register command exit
> register command false
> register command help
> register command ?
> register command ll
> register command ls
> register command md
> register command memcmp
> register command memcpy
> register command memset
> register command mkdir
> register command mount
> register command mw
> register command pwd
> register command rm
> register command rmdir
> register command setenv
> register command sh
> register command source
> register command .
> register command test
> register command [
> register command true
> register command :
> register command umount
> register command version
> initcall-> display_meminfo+0x0/0xa8
> barebox code: 0x7e00000 -> 0x7e2aeff
> bss segment: 0x7e390d0 -> 0x7e3adaf
> malloc space: 0x079ffcc0 -> 0x07dffcbf (size 4 MiB)
> initcall-> of_register_bootargs_fixup+0x0/0x3c
> initcall-> device_probe_deferred+0x0/0x14c
> initcall-> of_init_hostname+0x0/0x28
> initcall-> aarch64_register_image_handler+0x0/0x2c
> initcall-> load_environment+0x0/0x4c
> loading defaultenv
> environment load /dev/env0: No such file or directory
> Maybe you have to create the partition.
> initcalls done
>
> Hit any to stop autoboot: 0
> boot: No such file or directory
> barebox:/
>
>
> Few questions:
> 1. The serial input doesn't work. i.e. I cannot type anything hence cannot interact with barebox terminal.
DEBUG_LL only does otuput. For input, you will want to load the driver.
Do you have CONFIG_SERIAL_AMBA_PL011 enabled?
> Does it require GIC and setting interrupts for it to work?
No interrupts needed. barebox runs with interrupts disabled and everything
is done cooperatively.
> 2. What does "of_platform_bus_create() - skipping" means? Do I need to fix that?
That's normal debugging output. Some device tree nodes are busses, which have
children. These entries are skipped because they have no compatible. This is
expected. I'd suggest you remove your VERBOSED_DEBUG define, so you are not
spammed by too much debugging output.
> 3. Looks like I am still missing some stuff (rootfs? Environment? Mounting? Partitions?)
Take multi_v8_defconfig, open menuconfig and enable your SoC and use that.
That will be quicker than enabling everything yourself. If it doesn't work
out of the box, try imx_v8_defconfig.
Once you get around to upstreaming your SoC, I'd suggest you just add it
to multi_v8_defconfig. Not all ARMv8 SoCs are supported there, but those
that are make development easier, because we don't need to build as many
different configs..
Cheers,
Ahmad
>
> Thanks,
> Have a great day,
> Lior.
>
>
>> -----Original Message-----
>> From: Ahmad Fatoum <a.fatoum@pengutronix.de>
>> Sent: Wednesday, May 31, 2023 9:11 AM
>> To: Lior Weintraub <liorw@pliops.com>; Ahmad Fatoum <ahmad@a3f.at>;
>> barebox@lists.infradead.org
>> Subject: Re: [PATCH v2] Porting barebox to a new SoC
>>
>> CAUTION: External Sender
>>
>> Hi Lior,
>>
>> On 30.05.23 22:10, Lior Weintraub wrote:
>>> Hello Ahmad,
>>>
>>> Thanks again for your kind support!
>>> Your comments helped me progress and the current situation is as follows:
>>> Our QEMU Spider machine is running a BL1.elf file using the following
>> command:
>>> QEMU_AUDIO_DRV=none qemu-system-aarch64 -M spider-soc -smp 1 -m
>> 128M -nographic \
>>> -device loader,file=BL1.elf -cpu cortex-a53,rvbar=0xC004000000 \
>>> -d unimp -semihosting-config enable=on,target=native \
>>> -monitor telnet:localhost:1235,server,nowait \
>>> -gdb tcp::1236
>>>
>>> The BL1.elf is our BootROM application that runs from ROM address
>> 0xC004000000.
>>> Just for debugging purpose we've increased the ROM size so it can include
>> the images/barebox-spider-mk1-evk.img (as a const array).
>>> BL1 then copy it (using memcpy) to address 0 and jumps there for
>> execution.
>>
>> Sounds ok.
>>
>>> On the real ASIC this address will be the DRAM and indeed will need to be
>> initialized before the copy but here on QEMU it is not required.
>>
>> I see. You could still have your bootrom move barebox into SRAM and then
>>
>> barebox_arm_entry(DRAM_ADDR, SZ_128M, __dtb_spider_mk1_evk_start);
>>
>> To have PBL extract barebox to DRAM. Even if you don't need need DRAM
>> setup in QEMU, the flow would be similar to what you will have on actual
>> silicon.
>>
>>> The lowlevel.c of spider-evk was modified to use DRAM_ADDR 0x400000
>> (4MB from start) and MY_STACK_TOP was set to 0x8000000 (128M).
>>
>> That's not needed. While you don't have control where barebox PBL will be
>> located
>> (depends on BootROM), barebox will extract itself to the end of DRAM
>> without
>> overwriting itself, so you can just use DRAM_ADDR 0 normally. Eventually,
>> stack
>> top should go into SRAM, but anywhere that works is ok.
>>
>>> In addition, I implemented putc_ll (currently hard-coded in
>> include/debug_ll.h) and opened log level to VERBOSE_DEBUG (currently just
>> hard-coded in printk.h).
>>
>> There's CONFIG_DEBUG_PBL you can enable to get all these messages by
>> default.
>>
>>> I see the following (which makes sense) logs on QEMU terminal:
>>> uncompress.c: memory at 0x00400000, size 0x00200000
>>> uncompress.c: uncompressing barebox binary at 0x0000000000002200
>> (size 0x0001d3b2) to 0x00400000 (uncompressed size: 0x000373d0)
>>
>> Why pass only 2M to barebox_arm_entry? While this need not be the whole
>> of RAM, this
>> initial memory is what barebox will use for itself including its final stack and
>> malloc area. barebox will also not place itself into the last 1M AFAIK, so 2M
>> may not work ok. You should use the minimum possible RAM here or if you
>> can detect
>> in PBL how much RAM you have or just the whole RAM bank. I am not sure
>> anything lower
>> than SZ_4M would work ok. (Note this is DRAM size, not SRAM. barebox PBL
>> is fine being
>> called from 64K SRAMs, it just needs DRAM to extract to).
>>
>>> I then connect with aarch64-none-elf-gdb, load the barebox symbols (to
>> 0x400000) and check the current execution state (program counter and
>> stack).
>>> Looks like the code is stuck on function register_autoboot_vars:
>>> sp 0x5f7e60 0x5f7e60
>>> pc 0x401264 0x401264 <register_autoboot_vars+24>
>>>
>>> Few observations:
>>> 1. The PBL was using stack top located on 0x8000000 (which is
>> MY_STACK_TOP). Found it be causing a breakpoint on the PBL.
>>> 2. Barebox uses a stack top on 0x600000 which is probably calculated from
>> my new DRAM_ADDR and SZ_2M given to the function call:
>>> barebox_arm_entry(DRAM_ADDR, SZ_2M, __dtb_spider_mk1_evk_start);
>>>
>>> This is great! I am starting to find my way.
>>
>> :) Ye, the ENTRY_FUNCTION_WITHSTACK is only when the BootROM doesn't
>> enter
>> with a valid stack pointer. It's overwritten as soon as barebox is told
>> about the initial memory layout (with barebox_arm_entry).
>>
>>> When the barebox execution didn't print anything to the terminal I
>> remembered that we used a place holder on the dtsi for the uart.
>>> So now I changed it to:
>>> uart0: serial@d000307000 {
>>> compatible = "arm,pl011", "arm,primecell";
>>> reg = <0xd0 0x307000 0 0x1000>;
>>> }
>>> (Our QEMU UART is currently using pl011 device.)
>>
>> Looks ok. Don't forget to enable the driver (via make menuconfig).
>>
>>> After some time (trying to debug by enabling MMU but then reverted the
>> code back), I got to a point that when I try to run again I am getting an
>> exception.
>>> I can swear all code changes were reverted back to the point where I saw the
>> barebox stuck on register_autoboot_vars but now it just cases an exception.
>>> The exception vector code is located on our ROM (part of BL1 code) and the
>> logs shows that the link register has the value 0x401218 which suggest the
>> following code:
>>> 0000000000001200 <load_environment>:
>>> 1200: a9be7bfd stp x29, x30, [sp, #-32]!
>>> 1204: 910003fd mov x29, sp
>>> 1208: a90153f3 stp x19, x20, [sp, #16]
>>> 120c: 94000a07 bl 3a28 <default_environment_path_get>
>>> 1210: d00000f3 adrp x19, 1f000 <do_cpuinfo+0x1f0>
>>> 1214: 912a7273 add x19, x19, #0xa9c
>>> 1218: aa0003f4 mov x20, x0
>>>
>>> Any ideas or suggestions how to proceed with the debugging?
>>
>> You shouldn't need to touch the MMU code. If your initial memory setup
>> is wonky, you may end up overwriting stuff. Try again with bigger memory.
>>
>>> BTW, to answer your questions:
>>> The SRAM of 4MB is the only one we have because we assumed it is only for
>> BootROM to load a PBL
>>
>> Ok. Sometimes there are SRAMs for use with DMA. I asked, because a SRAM
>> in the first 4M
>> would lend itself nicely as stack, but if there is none, we can adjust
>> ENTRY_FUNCTION_WITHSTACK to accept a 64-bit parameter.
>>
>> Cheers,
>> Ahmad
>>
>>> Thank you very much,
>>> Cheers,
>>> Lior.
>>>
>>>
>>>> -----Original Message-----
>>>> From: Ahmad Fatoum <a.fatoum@pengutronix.de>
>>>> Sent: Monday, May 29, 2023 10:03 PM
>>>> To: Lior Weintraub <liorw@pliops.com>; Ahmad Fatoum <ahmad@a3f.at>;
>>>> barebox@lists.infradead.org
>>>> Subject: Re: [PATCH v2] Porting barebox to a new SoC
>>>>
>>>> CAUTION: External Sender
>>>>
>>>> Hello Lior,
>>>>
>>>> On 29.05.23 15:34, Lior Weintraub wrote:
>>>>> Hi Ahmad,
>>>>>
>>>>> I have revised the addresses and used DRAM address @ 0 instead:
>>>>> #define UARTBASE (0xD000307000)
>>>>> #define DRAM_ADDR (0x00000000)
>>>>> #define MY_STACK_TOP (0x00000000 + SZ_2M) // Set the stack 2MB
>> from
>>>> DRAM start
>>>>
>>>> Is DRAM configured by the time barebox runs? If not, you should keep
>> stack
>>>> top
>>>> in SRAM, until you have setup memory in prebootloader (PBL). Is the 4M
>>>> SRAM
>>>> the only on-chip SRAM you have?
>>>>
>>>>> static inline void spider_serial_putc(void *base, int c)
>>>>> {
>>>>> *((volatile unsigned *)base) = c;
>>>>
>>>> There's a helper for that: writel(c, base); In barebox, it's equivalent
>>>> to the volatile access, but in Linux it involves a write memory barrier.
>>>> We try to write code in barebox, so it's easily reusable in Linux (and
>>>> the other way round).
>>>>
>>>>> }
>>>>>
>>>>> I will try to test it on QEMU using an initial QEMU machine we made for
>>>> Spider.
>>>>> In this machine we only have 3 memory regions and a PL011 UART:
>>>>> spider_soc_memories soc_memories[] = {
>>>>> {.name = "SPIDER_GPRAM", .add = 0xC000000000ULL, .size = 4 * MiB},
>>>>> {.name = "SPIDER_ROM", .add = 0xC004000000ULL, .size = 128 *
>> KiB},
>>>>> {.name = "SPIDER_DRAM", .add = 0x0000000000ULL, .size = 1 * GiB},
>>>>> };
>>>>>
>>>>> This special QEMU machine can run our BL1 code from "ROM" address
>> (we
>>>> set the RVBAR to point there).
>>>>> So my idea is to test the barebox image by the following steps:
>>>>> 1. Modify the QEMU code to have a "ROM" with the size of 128M.
>>>>> 2. Compile our BL1 code to include the barebox.bin as a const array, copy
>> it
>>>> to "DRAM" @ address 0 and jump there.
>>>>
>>>> Why not map QEMU -bios option to SRAM? (Or DRAM directly, if it needs
>> no
>>>> special setup from
>>>> barebox side).
>>>>
>>>>> For this to work I wanted to understand how to call (i.e. what arguments
>> to
>>>> pass) to barebox.
>>>>
>>>> barebox doesn't expect any arguments, because most BootROMs don't
>> pass
>>>> anything useful.
>>>> Some pass information about bootsource though, so that's why the
>>>> ENTRY_FUNCTION has
>>>> r0, r1 and r2 as parameters, but you need not use them.
>>>>
>>>>> So I checked the barebox.map and found the function "start" on address
>> 0.
>>>>
>>>> You may know that Linux on some platforms comes with a decompressor
>> that
>>>> is glued to the
>>>> front of the kernel image and extracts the compressed kernel image.
>> barebox
>>>> has the same
>>>> concept. The prebootloader is uncompressed and runs (starting from
>>>> ENTRY_FUNCTION) and
>>>> then does some early setup (e.g. enable clocks, configure PMIC, setup
>> DRAM,
>>>> load secure
>>>> monitor (BL31), ...etc.) and then it decompresses barebox proper into
>> DRAM.
>>>>
>>>> barebox.bin <- barebox proper. You don't usually need that.
>>>> barebox.elf <- ELF binary for the above (for gdb)
>>>> barebox.map <- map file of the above
>>>>
>>>> images/barebox-spider-mk1-evk.img <- complete barebox image (PBL +
>>>> barebox proper)
>>>> images/start_spider_mk1_evk.pbl <- ELF image for the above
>>>> images/start_spider_mk1_evk.pbl.map <- map file of the above
>>>>
>>>> If you want to follow barbeox from the start, begin at
>> start_spider_mk1_evk.
>>>>
>>>>> Then I went to arch/arm/cpu/start.c and realized that the code is compiled
>>>> with CONFIG_PBL_IMAGE.
>>>>> In that case I assume I need to pass 3 arguments and use this function
>>>> prototype:
>>>>> void start(unsigned long membase, unsigned long memsize, void
>>>> *boarddata);
>>>>
>>>> barebox prebootloader takes care of this, so you don't need to do anything.
>>>>
>>>>> Few questions:
>>>>> 1. Will that call work:
>>>>> typedef void (*barebox_start)(unsigned long , unsigned long , void *);
>>>>> #define DRAM_START (0)
>>>>> barebox_start p_barebox = (barebox_start)DRAM_START;
>>>>> p_barebox(DRAM_START, DRAM_START+SZ_2M, (void
>>>> *)(DRAM_START+SZ_4M));
>>>>> This assumes that my BL1 code also copied the device tree (barebox-dt-
>>>> 2nd.img? start_dt_2nd.pblb? start_spider_mk1_evk.pblb?)
>>>>
>>>> The device tree is built into the PBL and passed to barebox proper. This
>>>> allows us to use the same barebox proper binary and link it with a different
>>>> prebootloader for each SoC/board, all in the same build.
>>>>
>>>> barebox-dt-2nd.img is a special image that looks exactly like a Linux kernel:
>>>>
>>>> images/barebox-dt-2nd.img: Linux kernel ARM64 boot executable Image,
>>>> little-endian, 4K pages
>>>>
>>>> and can thus be used for booting for easy chainloading from other
>>>> bootloaders or for running
>>>> with QEMU -kernel. You shouldn't need it right now.
>>>>
>>>>> 2. Do I want to have my code compiled with CONFIG_PBL_IMAGE?
>>>>> If I understand correctly, it means that my code will provide a PBL (a.k.a
>>>> BL2) which will set the DRAM and STACK among other things (MMU?).
>>>>
>>>> The patch I sent already builds a PBL. You will need to fill out
>>>> start_spider_mk1_evk
>>>> to do all the other early initialization you need. Then you call
>>>> barebox_arm_entry
>>>> with device tree and memory size and it will take care to do stack setup in
>> new
>>>> memory region, MMU setup (if enabled) and chainloading barebox proper.
>>>>
>>>> Note that PBL isn't necessary BL2. You can chainload barebox from within
>>>> barebox (i.e.
>>>> in EL2 or EL1), which is useful for debugging. You will thus often find PBL
>> code
>>>> that
>>>> does
>>>>
>>>> if (current_el() == 3) {
>>>> /* Do BL2 setup */
>>>> chainload();
>>>> __builtin_unreachable();
>>>> }
>>>>
>>>> barebox_arm_entry(...)
>>>>
>>>> See for example arch/arm/boards/innocomm-imx8mm-wb15/lowlevel.c
>>>>
>>>> to see a real-world example of another Cortex-A53.
>>>>
>>>>> In that case I assume it is OK.
>>>>> 3. If I try to remove it by having CONFIG_PBL_IMAGE=n on
>> spider_defconfig
>>>> this doesn't do anything
>>>>> The build (make spider_defconfig) ignores it and say that " No change to
>>>> .config ".
>>>>
>>>> Another symbol forces it to be enabled. If you are curious, run make
>>>> menuconfig
>>>> and then search (/) for the symbol and it will list, whether it's enabled and
>>>> why:
>>>>
>>>> Selected by [y]:
>>>> - PBL_MULTI_IMAGES [=y] && HAVE_PBL_MULTI_IMAGES [=y]
>>>>
>>>> I'd suggest you avoid modifying the .config file manually. always use
>>>> menuconfig.
>>>>
>>>>> 4. I also tried to understand how to implement PUTC_LL but not sure I
>>>> understand.
>>>>> 4.1 When I set "CONFIG_DEBUG_LL=y" on spider_defconfig it is again
>> not
>>>> written to .config and I get " No change to .config " message.
>>>>
>>>> You must:
>>>>
>>>> - select HAS_DEBUG_LL from MACH_SPIDER
>>>> - Add your arch to arch/arm/include/asm/debug_ll.h
>>>> - Then implement PUTC_LL in e.g. mach/spider/debug_ll.h
>>>>
>>>>> 4.2 Do I need to have my own debug_ll.h file?
>>>>
>>>> Yes. See above.
>>>>
>>>>> 5. When I make changes to spider_defconfig and try to regenerate the
>>>> .config and I get " No change to .config " message, does it mean that those
>>>> macros are "hidden" symbols like you said about the CONFIG_CPU_V8?
>>>>
>>>> Yes. Just check menuconfig to see how symbols relate to each other.
>>>> This is 1:1 like it's in Linux, so it'll come in handy when you do
>>>> the kernel port too ;)
>>>>
>>>>> Apologize for so many questions :-)
>>>>
>>>> No problem. Looking forward to your patches ;)
>>>>
>>>>
>>>> Cheers,
>>>> Ahmad
>>>>
>>>>> Cheers,
>>>>> Lior.
>>>>>
>>>>> -----Original Message-----
>>>>> From: Lior Weintraub
>>>>> Sent: Sunday, May 28, 2023 11:16 PM
>>>>> To: Ahmad Fatoum <ahmad@a3f.at>; barebox@lists.infradead.org
>>>>> Subject: RE: [PATCH v2] Porting barebox to a new SoC
>>>>>
>>>>> Hi Ahmad,
>>>>>
>>>>> Thank you so much for your kind support!
>>>>>
>>>>> Indeed we also have a 16GB DRAM that starts from address 0 (though
>>>> currently we don't have the controller settings (under development)).
>>>>>
>>>>> I also wrote the BootROM (BL1) for this SoC (128KB ROM @ address
>>>> 0xC004000000).
>>>>> I understand now that it would be best for me to develop BL2 that will run
>>>> from our SRAM.
>>>>>
>>>>> As this BL2 code is bare-metal I have no problem or limitations with the 40
>>>> bit addresses.
>>>>> The BL2 code will initialize the DRAM controller and then copy Barebox
>> image
>>>> from NOR Flash to address 0 of the DRAM.
>>>>> Our NOR Flash is 128MB in size and it is accessed via QSPI controller.
>>>>>
>>>>> I tried applying your suggested patch but got an error while doing so:
>>>>> $git apply 0002-Ahmad.patch
>>>>> 0002-Ahmad.patch:115: trailing whitespace.
>>>>> .of_compatible = spider_board_of_match, };
>>>>> error: corrupt patch at line 117
>>>>>
>>>>> After some digging I found that my Outlook probably messed with the
>> patch
>>>> format (even though I am using text only and no HTML format).
>>>>> When I went to the web and copied the patch from there (mailing list
>>>> archive) it was working well (i.e. no compilation error).
>>>>>
>>>>> Cheers,
>>>>> Lior.
>>>>>
>>>>> -----Original Message-----
>>>>> From: Ahmad Fatoum <ahmad@a3f.at>
>>>>> Sent: Sunday, May 28, 2023 6:38 PM
>>>>> To: barebox@lists.infradead.org
>>>>> Cc: Lior Weintraub <liorw@pliops.com>
>>>>> Subject: [PATCH v2] Porting barebox to a new SoC
>>>>>
>>>>> CAUTION: External Sender
>>>>>
>>>>> From: Lior Weintraub <liorw@pliops.com>
>>>>>
>>>>> Hi,
>>>>>
>>>>> I tried to follow the porting guide on https://ddec1-0-en-
>>>>
>> ctp.trendmicro.com:443/wis/clicktime/v1/query?url=https%3a%2f%2fwww.
>>>>
>> barebox.org%2fdoc%2flatest%2fdevel%2fporting.html%23&umid=60097eda
>>>> -f136-45a1-9c8e-
>>>> cf6a76e45cf8&auth=860a7ebb9feba264acc79b6e38eb59582349362c-
>>>> 480ae23736add41c88ab8d30c090a75517ca7f9e but couldn't follow the
>>>> instructions.
>>>>> I would like to port barebox to a new SoC (which is not a derivative of any
>>>> known SoC).
>>>>> It has the following:
>>>>> * Single Cortex A53
>>>>> * SRAM (4MB) located on address 0xC000000000
>>>>>
>>>>> The below patch shows my initial test to try and have a starting point.
>>>>> I am setting env variables:
>>>>> export ARCH=arm64
>>>>> export CROSS_COMPILE=/home/pliops/workspace/ARM/arm-gnu-
>>>> toolchain/bin/aarch64-none-elf-
>>>>>
>>>>> Then I build with:
>>>>> make spider_defconfig && make
>>>>>
>>>>> This gives an error:
>>>>> aarch64-none-elf-gcc: error: unrecognized argument in option '-
>> mabi=apcs-
>>>> gnu'
>>>>> aarch64-none-elf-gcc: note: valid arguments to '-mabi=' are: ilp32 lp64
>>>>> aarch64-none-elf-gcc: error: unrecognized command-line option '-msoft-
>>>> float'
>>>>> aarch64-none-elf-gcc: error: unrecognized command-line option '-mno-
>>>> unaligned-access'
>>>>> /home/pliops/workspace/simplest-linux-
>>>> demo/barebox/scripts/Makefile.build:140: recipe for target
>>>> 'scripts/mod/empty.o' failed
>>>>> make[2]: *** [scripts/mod/empty.o] Error 1
>>>>>
>>>>> Not sure why the compiler flags get -mabi=apcs-gnu when I explicitly set
>>>> CONFIG_CPU_V8 and the arch/arm/Makefile has:
>>>>> ifeq ($(CONFIG_CPU_V8), y)
>>>>> CFLAGS_ABI :=-mabi=lp64
>>>>>
>>>>> The changes I did:
>>>>> >From 848b5f9b18bb1bb96d197cbc1b368ee0a729d581 Mon Sep 17
>>>> 00:00:00 2001
>>>>> ---
>>>>> arch/arm/Kconfig | 13 ++++++++
>>>>> arch/arm/Makefile | 1 +
>>>>> arch/arm/boards/Makefile | 1 +
>>>>> arch/arm/boards/spider-evk/Makefile | 4 +++
>>>>> arch/arm/boards/spider-evk/board.c | 26 +++++++++++++++
>>>>> arch/arm/boards/spider-evk/lowlevel.c | 30 +++++++++++++++++
>>>>> arch/arm/configs/spider_defconfig | 8 +++++
>>>>> arch/arm/dts/Makefile | 1 +
>>>>> arch/arm/dts/spider-mk1-evk.dts | 10 ++++++
>>>>> arch/arm/dts/spider-mk1.dtsi | 46 +++++++++++++++++++++++++++
>>>>> arch/arm/mach-spider/Kconfig | 16 ++++++++++
>>>>> arch/arm/mach-spider/Makefile | 1 +
>>>>> arch/arm/mach-spider/lowlevel.c | 14 ++++++++
>>>>> images/Makefile | 1 +
>>>>> images/Makefile.spider | 5 +++
>>>>> include/mach/spider/lowlevel.h | 7 ++++
>>>>> 16 files changed, 184 insertions(+)
>>>>> create mode 100644 arch/arm/boards/spider-evk/Makefile
>>>>> create mode 100644 arch/arm/boards/spider-evk/board.c
>>>>> create mode 100644 arch/arm/boards/spider-evk/lowlevel.c
>>>>> create mode 100644 arch/arm/configs/spider_defconfig create mode
>>>> 100644 arch/arm/dts/spider-mk1-evk.dts create mode 100644
>>>> arch/arm/dts/spider-mk1.dtsi create mode 100644 arch/arm/mach-
>>>> spider/Kconfig create mode 100644 arch/arm/mach-spider/Makefile
>> create
>>>> mode 100644 arch/arm/mach-spider/lowlevel.c create mode 100644
>>>> images/Makefile.spider create mode 100644
>> include/mach/spider/lowlevel.h
>>>>>
>>>>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index
>>>> e76ee0f6dfe1..e5dcf128447e 100644
>>>>> --- a/arch/arm/Kconfig
>>>>> +++ b/arch/arm/Kconfig
>>>>> @@ -255,6 +255,18 @@ config ARCH_ROCKCHIP
>>>>> select HAS_DEBUG_LL
>>>>> imply GPIO_ROCKCHIP
>>>>>
>>>>> +config ARCH_SPIDER
>>>>> + bool "Pliops Spider based"
>>>>> + depends on 64BIT
>>>>> + depends on ARCH_MULTIARCH
>>>>> + select GPIOLIB
>>>>> + select HAVE_PBL_MULTI_IMAGES
>>>>> + select COMMON_CLK
>>>>> + select CLKDEV_LOOKUP
>>>>> + select COMMON_CLK_OF_PROVIDER
>>>>> + select OFTREE
>>>>> + select OFDEVICE
>>>>> +
>>>>> config ARCH_STM32MP
>>>>> bool "STMicroelectronics STM32MP"
>>>>> depends on 32BIT
>>>>> @@ -331,6 +343,7 @@ source "arch/arm/mach-omap/Kconfig"
>>>>> source "arch/arm/mach-pxa/Kconfig"
>>>>> source "arch/arm/mach-rockchip/Kconfig"
>>>>> source "arch/arm/mach-socfpga/Kconfig"
>>>>> +source "arch/arm/mach-spider/Kconfig"
>>>>> source "arch/arm/mach-stm32mp/Kconfig"
>>>>> source "arch/arm/mach-versatile/Kconfig"
>>>>> source "arch/arm/mach-vexpress/Kconfig"
>>>>> diff --git a/arch/arm/Makefile b/arch/arm/Makefile index
>>>> 35ebc70f44e2..4c63dfee48f4 100644
>>>>> --- a/arch/arm/Makefile
>>>>> +++ b/arch/arm/Makefile
>>>>> @@ -101,6 +101,7 @@ machine-$(CONFIG_ARCH_MXS) += mxs
>>>>> machine-$(CONFIG_ARCH_MVEBU) += mvebu
>>>>> machine-$(CONFIG_ARCH_NOMADIK) += nomadik
>>>>> machine-$(CONFIG_ARCH_OMAP) += omap
>>>>> +machine-$(CONFIG_ARCH_SPIDER) += spider
>>>>> machine-$(CONFIG_ARCH_PXA) += pxa
>>>>> machine-$(CONFIG_ARCH_ROCKCHIP) += rockchip
>>>>> machine-$(CONFIG_ARCH_SAMSUNG) += samsung
>>>>> diff --git a/arch/arm/boards/Makefile b/arch/arm/boards/Makefile index
>>>> 2877debad535..6fe0a90c81ea 100644
>>>>> --- a/arch/arm/boards/Makefile
>>>>> +++ b/arch/arm/boards/Makefile
>>>>> @@ -135,6 +135,7 @@ obj-
>>>> $(CONFIG_MACH_SOCFPGA_TERASIC_DE10_NANO) += terasic-de10-
>>>> nano/
>>>>> obj-$(CONFIG_MACH_SOCFPGA_TERASIC_SOCKIT) += terasic-sockit/
>>>>> obj-$(CONFIG_MACH_SOLIDRUN_CUBOX) += solidrun-cubox/
>>>>> obj-$(CONFIG_MACH_SOLIDRUN_MICROSOM) += solidrun-
>>>> microsom/
>>>>> +obj-$(CONFIG_MACH_SPIDER_MK1_EVK) += spider-evk/
>>>>> obj-$(CONFIG_MACH_STM32MP15XX_DKX) += stm32mp15xx-
>> dkx/
>>>>> obj-$(CONFIG_MACH_STM32MP13XX_DK) += stm32mp13xx-dk/
>>>>> obj-$(CONFIG_MACH_LXA_MC1) += lxa-mc1/
>>>>> diff --git a/arch/arm/boards/spider-evk/Makefile
>>>> b/arch/arm/boards/spider-evk/Makefile
>>>>> new file mode 100644
>>>>> index 000000000000..da63d2625f7a
>>>>> --- /dev/null
>>>>> +++ b/arch/arm/boards/spider-evk/Makefile
>>>>> @@ -0,0 +1,4 @@
>>>>> +# SPDX-License-Identifier: GPL-2.0-only
>>>>> +
>>>>> +obj-y += board.o
>>>>> +lwl-y += lowlevel.o
>>>>> diff --git a/arch/arm/boards/spider-evk/board.c
>> b/arch/arm/boards/spider-
>>>> evk/board.c
>>>>> new file mode 100644
>>>>> index 000000000000..3920e83b457d
>>>>> --- /dev/null
>>>>> +++ b/arch/arm/boards/spider-evk/board.c
>>>>> @@ -0,0 +1,26 @@
>>>>> +#include <bbu.h>
>>>>> +#include <boot.h>
>>>>> +#include <bootm.h>
>>>>> +#include <common.h>
>>>>> +#include <deep-probe.h>
>>>>> +#include <environment.h>
>>>>> +#include <fcntl.h>
>>>>> +#include <globalvar.h>
>>>>> +
>>>>> +static int spider_board_probe(struct device *dev) {
>>>>> + /* Do some board-specific setup */
>>>>> + return 0;
>>>>> +}
>>>>> +
>>>>> +static const struct of_device_id spider_board_of_match[] = {
>>>>> + { .compatible = "pliops,spider-mk1-evk" },
>>>>> + { /* sentinel */ },
>>>>> +};
>>>>> +
>>>>> +static struct driver spider_board_driver = {
>>>>> + .name = "board-spider",
>>>>> + .probe = spider_board_probe,
>>>>> + .of_compatible = spider_board_of_match, };
>>>>> +device_platform_driver(spider_board_driver);
>>>>> diff --git a/arch/arm/boards/spider-evk/lowlevel.c
>>>> b/arch/arm/boards/spider-evk/lowlevel.c
>>>>> new file mode 100644
>>>>> index 000000000000..e36fcde4208e
>>>>> --- /dev/null
>>>>> +++ b/arch/arm/boards/spider-evk/lowlevel.c
>>>>> @@ -0,0 +1,30 @@
>>>>> +#include <common.h>
>>>>> +#include <asm/barebox-arm.h>
>>>>> +#include <mach/spider/lowlevel.h>
>>>>> +
>>>>> +#define BASE_ADDR (0xD000307000)
>>>>> +#define GPRAM_ADDR (0xC000000000)
>>>>> +#define MY_STACK_TOP (0xC000000000 + SZ_2M) // Set the stack
>> 2MB
>>>> from GPRAM start (excatly in the middle)
>>>>> +static inline void spider_serial_putc(void *base, int c) {
>>>>> +// if (!(readl(base + UCR1) & UCR1_UARTEN))
>>>>> +// return;
>>>>> +//
>>>>> +// while (!(readl(base + USR2) & USR2_TXDC));
>>>>> +//
>>>>> +// writel(c, base + URTX0);
>>>>> +}
>>>>> +
>>>>> +ENTRY_FUNCTION_WITHSTACK(start_spider_mk1_evk, MY_STACK_TOP,
>>>> r0, r1,
>>>>> +r2) {
>>>>> + extern char __dtb_spider_mk1_evk_start[];
>>>>> +
>>>>> + spider_lowlevel_init();
>>>>> +
>>>>> + relocate_to_current_adr();
>>>>> + setup_c();
>>>>> +
>>>>> + pbl_set_putc(spider_serial_putc, (void *)BASE_ADDR);
>>>>> +
>>>>> + barebox_arm_entry(GPRAM_ADDR, SZ_2M,
>>>>> +__dtb_spider_mk1_evk_start); }
>>>>> diff --git a/arch/arm/configs/spider_defconfig
>>>> b/arch/arm/configs/spider_defconfig
>>>>> new file mode 100644
>>>>> index 000000000000..c91bb889d97f
>>>>> --- /dev/null
>>>>> +++ b/arch/arm/configs/spider_defconfig
>>>>> @@ -0,0 +1,8 @@
>>>>> +CONFIG_ARCH_SPIDER=y
>>>>> +CONFIG_MACH_SPIDER_MK1_EVK=y
>>>>> +CONFIG_BOARD_ARM_GENERIC_DT=y
>>>>> +CONFIG_MALLOC_TLSF=y
>>>>> +CONFIG_KALLSYMS=y
>>>>> +CONFIG_RELOCATABLE=y
>>>>> +CONFIG_CONSOLE_ALLOW_COLOR=y
>>>>> +CONFIG_PBL_CONSOLE=y
>>>>> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile index
>>>> 98f4c4e0194b..94b304d4878f 100644
>>>>> --- a/arch/arm/dts/Makefile
>>>>> +++ b/arch/arm/dts/Makefile
>>>>> @@ -134,6 +134,7 @@ lwl-$(CONFIG_MACH_SOLIDRUN_CUBOX) +=
>> dove-
>>>> cubox-bb.dtb.o
>>>>> lwl-$(CONFIG_MACH_SOLIDRUN_MICROSOM) += imx6dl-
>>>> hummingboard.dtb.o imx6q-hummingboard.dtb.o \
>>>>> imx6dl-hummingboard2.dtb.o imx6q-
>>>> hummingboard2.dtb.o \
>>>>> imx6q-h100.dtb.o
>>>>> +lwl-$(CONFIG_MACH_SPIDER_MK1_EVK) += spider-mk1-evk.dtb.o
>>>>> lwl-$(CONFIG_MACH_SKOV_IMX6) += imx6s-skov-imx6.dtb.o imx6dl-
>> skov-
>>>> imx6.dtb.o imx6q-skov-imx6.dtb.o
>>>>> lwl-$(CONFIG_MACH_SKOV_ARM9CPU) += at91-skov-arm9cpu.dtb.o
>>>>> lwl-$(CONFIG_MACH_SEEED_ODYSSEY) += stm32mp157c-odyssey.dtb.o
>>>> diff --git a/arch/arm/dts/spider-mk1-evk.dts b/arch/arm/dts/spider-mk1-
>>>> evk.dts new file mode 100644 index 000000000000..b8081cb85bf8
>>>>> --- /dev/null
>>>>> +++ b/arch/arm/dts/spider-mk1-evk.dts
>>>>> @@ -0,0 +1,10 @@
>>>>> +// SPDX-License-Identifier: GPL-2.0 OR X11
>>>>> +
>>>>> +/dts-v1/;
>>>>> +
>>>>> +#include "spider-mk1.dtsi"
>>>>> +
>>>>> +/ {
>>>>> + model = "Pliops Spider MK-I EVK";
>>>>> + compatible = "pliops,spider-mk1-evk"; };
>>>>> diff --git a/arch/arm/dts/spider-mk1.dtsi b/arch/arm/dts/spider-mk1.dtsi
>>>> new file mode 100644 index 000000000000..d4613848169d
>>>>> --- /dev/null
>>>>> +++ b/arch/arm/dts/spider-mk1.dtsi
>>>>> @@ -0,0 +1,46 @@
>>>>> +// SPDX-License-Identifier: GPL-2.0 OR X11
>>>>> +
>>>>> +/ {
>>>>> + #address-cells = <2>;
>>>>> + #size-cells = <2>;
>>>>> +
>>>>> + chosen {
>>>>> + stdout-path = &uart0;
>>>>> + };
>>>>> +
>>>>> + aliases {
>>>>> + serial0 = &uart0;
>>>>> + };
>>>>> +
>>>>> + cpus {
>>>>> + #address-cells = <1>;
>>>>> + #size-cells = <0>;
>>>>> +
>>>>> + cpu0: cpu@0 {
>>>>> + device_type = "cpu";
>>>>> + compatible = "arm,cortex-a53";
>>>>> + reg = <0x0>;
>>>>> + };
>>>>> + };
>>>>> +
>>>>> + memory@1000000 {
>>>>> + reg = <0x0 0x1000000 0x0 0x400000>; /* 128M */
>>>>> + device_type = "memory";
>>>>> + };
>>>>> +
>>>>> + soc {
>>>>> + #address-cells = <2>;
>>>>> + #size-cells = <2>;
>>>>> + ranges;
>>>>> +
>>>>> + sram@c000000000 {
>>>>> + compatible = "mmio-sram";
>>>>> + reg = <0xc0 0x0 0x0 0x400000>;
>>>>> + };
>>>>> +
>>>>> + uart0: serial@d000307000 {
>>>>> + compatible = "pliops,spider-uart";
>>>>> + reg = <0xd0 0x307000 0 0x1000>;
>>>>> + };
>>>>> + };
>>>>> +};
>>>>> diff --git a/arch/arm/mach-spider/Kconfig b/arch/arm/mach-
>> spider/Kconfig
>>>> new file mode 100644 index 000000000000..6d2f888a5fd8
>>>>> --- /dev/null
>>>>> +++ b/arch/arm/mach-spider/Kconfig
>>>>> @@ -0,0 +1,16 @@
>>>>> +# SPDX-License-Identifier: GPL-2.0-only
>>>>> +
>>>>> +if ARCH_SPIDER
>>>>> +
>>>>> +config ARCH_SPIDER_MK1
>>>>> + bool
>>>>> + select CPU_V8
>>>>> + help
>>>>> + The first Cortex-A53-based SoC of the spider family.
>>>>> + This symbol is invisble and select by boards
>>>>> +
>>>>> +config MACH_SPIDER_MK1_EVK
>>>>> + bool "Pliops Spider Reference Design Board"
>>>>> + select ARCH_SPIDER_MK1
>>>>> +
>>>>> +endif
>>>>> diff --git a/arch/arm/mach-spider/Makefile b/arch/arm/mach-
>>>> spider/Makefile new file mode 100644 index
>> 000000000000..b08c4a93ca27
>>>>> --- /dev/null
>>>>> +++ b/arch/arm/mach-spider/Makefile
>>>>> @@ -0,0 +1 @@
>>>>> +lwl-y += lowlevel.o
>>>>> diff --git a/arch/arm/mach-spider/lowlevel.c b/arch/arm/mach-
>>>> spider/lowlevel.c new file mode 100644 index
>>>> 000000000000..5d62ef0f39e5
>>>>> --- /dev/null
>>>>> +++ b/arch/arm/mach-spider/lowlevel.c
>>>>> @@ -0,0 +1,14 @@
>>>>> +// SPDX-License-Identifier: GPL-2.0+
>>>>> +
>>>>> +#include <linux/types.h>
>>>>> +#include <mach/spider/lowlevel.h>
>>>>> +#include <asm/barebox-arm-head.h>
>>>>> +
>>>>> +void spider_lowlevel_init(void)
>>>>> +{
>>>>> + arm_cpu_lowlevel_init();
>>>>> + /*
>>>>> + * not yet relocated, only do writel/readl for stuff that's
>>>>> + * critical to run early. No global variables allowed.
>>>>> + */
>>>>> +}
>>>>> diff --git a/images/Makefile b/images/Makefile index
>>>> c93f9e268978..97521e713228 100644
>>>>> --- a/images/Makefile
>>>>> +++ b/images/Makefile
>>>>> @@ -150,6 +150,7 @@ include $(srctree)/images/Makefile.mxs include
>>>> $(srctree)/images/Makefile.omap3 include
>>>> $(srctree)/images/Makefile.rockchip
>>>>> include $(srctree)/images/Makefile.socfpga
>>>>> +include $(srctree)/images/Makefile.spider
>>>>> include $(srctree)/images/Makefile.stm32mp
>>>>> include $(srctree)/images/Makefile.tegra include
>>>> $(srctree)/images/Makefile.versatile
>>>>> diff --git a/images/Makefile.spider b/images/Makefile.spider new file
>> mode
>>>> 100644 index 000000000000..c32f2762df04
>>>>> --- /dev/null
>>>>> +++ b/images/Makefile.spider
>>>>> @@ -0,0 +1,5 @@
>>>>> +# SPDX-License-Identifier: GPL-2.0-only
>>>>> +
>>>>> +pblb-$(CONFIG_MACH_SPIDER_MK1_EVK) += start_spider_mk1_evk
>>>>> +FILE_barebox-spider-mk1-evk.img = start_spider_mk1_evk.pblb
>>>>> +image-$(CONFIG_MACH_SPIDER_MK1_EVK) += barebox-spider-mk1-
>>>> evk.img
>>>>> diff --git a/include/mach/spider/lowlevel.h
>>>> b/include/mach/spider/lowlevel.h new file mode 100644 index
>>>> 000000000000..6e0ce1c77f7e
>>>>> --- /dev/null
>>>>> +++ b/include/mach/spider/lowlevel.h
>>>>> @@ -0,0 +1,7 @@
>>>>> +/* SPDX-License-Identifier: GPL-2.0+ */ #ifndef __MACH_SPIDER_H_
>>>>> +#define __MACH_SPIDER_H_
>>>>> +
>>>>> +void spider_lowlevel_init(void);
>>>>> +
>>>>> +#endif
>>>>> --
>>>>> 2.38.4
>>>>>
>>>>>
>>>>
>>>> --
>>>> Pengutronix e.K. | |
>>>> Steuerwalder Str. 21 | http://www.pengutronix.de/ |
>>>> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
>>>> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
>>>
>>
>> --
>> Pengutronix e.K. | |
>> Steuerwalder Str. 21 | http://www.pengutronix.de/ |
>> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
>> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
>
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply [flat|nested] 40+ messages in thread
* RE: [PATCH v2] Porting barebox to a new SoC
2023-05-31 8:40 ` Ahmad Fatoum
@ 2023-05-31 16:13 ` Lior Weintraub
2023-05-31 17:55 ` Ahmad Fatoum
0 siblings, 1 reply; 40+ messages in thread
From: Lior Weintraub @ 2023-05-31 16:13 UTC (permalink / raw)
To: Ahmad Fatoum, Ahmad Fatoum, barebox
Hi Ahmad,
Using end of SRAM as PBL stack is currently not working because we need 40bit address (0xC0_0020_0000).
This needs a fix to ENTRY_FUNCTION_WITHSTACK macro.
I tried just to change const u32 __stack_top = (stack_top); to const u64 __stack_top = (stack_top); but there were linking errors caused by:
ASSERT(. - __pbl_board_stack_top <= 8, "Only One PBL per Image allowed")
Regarding the arm timer:
Adding the timer entry to DT solved the issue.
Regarding the UART:
Indeed CONFIG_SERIAL_AMBA_PL011 was set on spider_defconfig (also verified it generated the correct entry on .config).
I also noticed that if I remove the putc_ll implementation there is no Tx at all from Barebox.
Could it be a hint?
Thanks,
Lior.
> -----Original Message-----
> From: Ahmad Fatoum <a.fatoum@pengutronix.de>
> Sent: Wednesday, May 31, 2023 11:40 AM
> To: Lior Weintraub <liorw@pliops.com>; Ahmad Fatoum <ahmad@a3f.at>;
> barebox@lists.infradead.org
> Subject: Re: [PATCH v2] Porting barebox to a new SoC
>
> CAUTION: External Sender
>
> Hi Lior,
>
> On 31.05.23 10:05, Lior Weintraub wrote:
> > Hi Ahmad,
> >
> > Thanks again for your prompt reply and accurate tips!
> > Took the following changes:
> > 1. Increasing the DRAM size to 128MB (let barebox start from 0).
> > 2. Set PBL stack to offset 2MB from DRAM
>
> Just use end of SRAM, so you are completely independent of DRAM
> until you call barebox_arm_entry.
>
> > 3. Fix the device tree "memory" entry to have 128MB.
>
> (y)
>
> > 4. Load barebox-spider-mk1-evk.img to SRAM and run from there.
> >
> > Now I can see the following logs:
> > uncompress.c: memory at 0x00000000, size 0x08000000
> > uncompress.c: uncompressing barebox binary at 0x000000c0000021c0
> (size 0x0001e3a4) to 0x07e00000 (uncompressed size: 0x000390d0)
> > uncompress.c: jumping to uncompressed image at 0x0000000007e00000
> > start.c: memory at 0x00000000, size 0x08000000
> > start.c: found DTB in boarddata, copying to 0x07dffcc0
> > start.c: initializing malloc pool at 0x079ffcc0 (size 0x00400000)
> > start.c: starting barebox...
> > initcall-> command_slice_init+0x0/0x3c
> > initcall-> globalvar_init+0x0/0x80
> > register_device: global
> > register_device: nv
> > initcall-> platform_init+0x0/0x1c
> > register_device: platform
> > initcall-> amba_bus_init+0x0/0x1c
> > register_device: amba
> > initcall-> spi_bus_init+0x0/0x1c
> > register_device: spi
> > initcall-> gpio_desc_alloc+0x0/0x24
> > initcall-> fs_bus_init+0x0/0x1c
> > register_device: fs
> > initcall-> aarch64_init_vectors+0x0/0x50
> > initcall-> gpio_gate_clock_driver_register+0x0/0x1c
> > register_driver: gpio-gate-clock
> > initcall-> of_arm_init+0x0/0x5c
> > start.c: barebox_arm_boot_dtb: using barebox_boarddata
> > using boarddata provided DTB
> > adding DT alias:serial0: stem=serial id=0 node=/soc/serial@d000307000
> > register_device: machine
> > of_platform_bus_create() - skipping /chosen, no compatible prop
> > of_platform_bus_create() - skipping /aliases, no compatible prop
> > of_platform_bus_create() - skipping /cpus, no compatible prop
> > of_platform_bus_create() - skipping /memory@0, no compatible prop
> > of_platform_bus_create() - skipping /soc, no compatible prop
> > initcall-> register_autoboot_vars+0x0/0x70
> > initcall-> arm_arch_timer_driver_register+0x0/0x1c
> > register_driver: arm-architected-timer
> > initcall-> of_timer_init+0x0/0x20
> > initcall-> init_fs+0x0/0x3c
> > initcall-> pl011_driver_register+0x0/0x1c
> > register_driver: uart-pl011
> > initcall-> of_stdoutpath_init+0x0/0x28
> > initcall-> of_probe_memory+0x0/0x60
> > __request_region ok: 0x00000000:0x07ffffff flags=0x0
> > initcall-> __bare_init_end+0x0/0x6c
> > register_device: mem0
> > initcall-> of_reserved_mem_walk+0x0/0x1ac
> > initcall-> mem_malloc_resource+0x0/0xa8
> > __request_region ok: 0x079ffcc0:0x07dffcbf flags=0x200
> > __request_region ok: 0x07e00000:0x07e2aeff flags=0x200
> > __request_region ok: 0x07e2af00:0x07e390cf flags=0x200
> > __request_region ok: 0x07e390d0:0x07e3adaf flags=0x200
> > initcall-> bootsource_init+0x0/0x40
> > initcall-> ramfs_init+0x0/0x1c
> > register_driver: ramfs
> > initcall-> devfs_init+0x0/0x1c
> > register_driver: devfs
> > initcall-> arm_request_stack+0x0/0x398
> > __request_region ok: 0x07ff0000:0x07ff7fff flags=0x200
> > initcall-> mount_root+0x0/0x7c
> > mount: none on / type ramfs, options=
> > register_device: ramfs0
> > probe-> ramfs0
> > mount: none on /dev type devfs, options=
> > register_device: devfs0
> > probe-> devfs0
> > initcall-> binfmt_sh_init+0x0/0x1c
> > initcall-> binfmt_uimage_init+0x0/0x1c
> > initcall-> console_common_init+0x0/0x48
> > initcall-> of_kernel_init+0x0/0x28
> > initcall-> console_ctrlc_init+0x0/0x30
> > initcall-> mem_init+0x0/0x90
> > register_device: mem1
> > register_driver: mem
> > probe-> mem0
> > probe-> mem1
> > initcall-> of_partition_init+0x0/0x48
> > initcall-> prng_init+0x0/0x40
> > initcall-> null_init+0x0/0x40
> > initcall-> full_init+0x0/0x40
> > initcall-> zero_init+0x0/0x40
> > initcall-> spider_board_driver_register+0x0/0x1c
> > register_driver: board-spider
> > probe-> machine
> > initcall-> barebox_memory_areas_init+0x0/0x40
> > __request_region ok: 0x07dffcc0:0x07dfffce flags=0x200
> > initcall-> barebox_of_populate+0x0/0x28
> > initcall-> of_register_memory_fixup+0x0/0x20
> > initcall-> dummy_csrc_warn+0x0/0x44
> > WARNING: Warning: Using dummy clocksource
>
> Add a arm,armv8-timer node into your SoC device tree.
> This lets barebox and Linux know that you have the ARM
> architected timer available. Without that, you'll notice
> that timeouts are wrong.
>
> > initcall-> bootm_init+0x0/0xf4
> > initcall-> init_command_list+0x0/0x40
> > register command bootm
> > register command cat
> > register command cd
> > register command clear
> > register command cp
> > register command cpuinfo
> > register command devinfo
> > register command drvinfo
> > register command echo
> > register command exit
> > register command false
> > register command help
> > register command ?
> > register command ll
> > register command ls
> > register command md
> > register command memcmp
> > register command memcpy
> > register command memset
> > register command mkdir
> > register command mount
> > register command mw
> > register command pwd
> > register command rm
> > register command rmdir
> > register command setenv
> > register command sh
> > register command source
> > register command .
> > register command test
> > register command [
> > register command true
> > register command :
> > register command umount
> > register command version
> > initcall-> display_meminfo+0x0/0xa8
> > barebox code: 0x7e00000 -> 0x7e2aeff
> > bss segment: 0x7e390d0 -> 0x7e3adaf
> > malloc space: 0x079ffcc0 -> 0x07dffcbf (size 4 MiB)
> > initcall-> of_register_bootargs_fixup+0x0/0x3c
> > initcall-> device_probe_deferred+0x0/0x14c
> > initcall-> of_init_hostname+0x0/0x28
> > initcall-> aarch64_register_image_handler+0x0/0x2c
> > initcall-> load_environment+0x0/0x4c
> > loading defaultenv
> > environment load /dev/env0: No such file or directory
> > Maybe you have to create the partition.
> > initcalls done
> >
> > Hit any to stop autoboot: 0
> > boot: No such file or directory
> > barebox:/
> >
> >
> > Few questions:
> > 1. The serial input doesn't work. i.e. I cannot type anything hence cannot
> interact with barebox terminal.
>
> DEBUG_LL only does otuput. For input, you will want to load the driver.
> Do you have CONFIG_SERIAL_AMBA_PL011 enabled?
>
> > Does it require GIC and setting interrupts for it to work?
>
> No interrupts needed. barebox runs with interrupts disabled and everything
> is done cooperatively.
>
> > 2. What does "of_platform_bus_create() - skipping" means? Do I need to fix
> that?
>
> That's normal debugging output. Some device tree nodes are busses, which
> have
> children. These entries are skipped because they have no compatible. This is
> expected. I'd suggest you remove your VERBOSED_DEBUG define, so you are
> not
> spammed by too much debugging output.
>
> > 3. Looks like I am still missing some stuff (rootfs? Environment? Mounting?
> Partitions?)
>
> Take multi_v8_defconfig, open menuconfig and enable your SoC and use that.
> That will be quicker than enabling everything yourself. If it doesn't work
> out of the box, try imx_v8_defconfig.
>
> Once you get around to upstreaming your SoC, I'd suggest you just add it
> to multi_v8_defconfig. Not all ARMv8 SoCs are supported there, but those
> that are make development easier, because we don't need to build as many
> different configs..
>
> Cheers,
> Ahmad
>
> >
> > Thanks,
> > Have a great day,
> > Lior.
> >
> >
> >> -----Original Message-----
> >> From: Ahmad Fatoum <a.fatoum@pengutronix.de>
> >> Sent: Wednesday, May 31, 2023 9:11 AM
> >> To: Lior Weintraub <liorw@pliops.com>; Ahmad Fatoum <ahmad@a3f.at>;
> >> barebox@lists.infradead.org
> >> Subject: Re: [PATCH v2] Porting barebox to a new SoC
> >>
> >> CAUTION: External Sender
> >>
> >> Hi Lior,
> >>
> >> On 30.05.23 22:10, Lior Weintraub wrote:
> >>> Hello Ahmad,
> >>>
> >>> Thanks again for your kind support!
> >>> Your comments helped me progress and the current situation is as
> follows:
> >>> Our QEMU Spider machine is running a BL1.elf file using the following
> >> command:
> >>> QEMU_AUDIO_DRV=none qemu-system-aarch64 -M spider-soc -smp 1 -
> m
> >> 128M -nographic \
> >>> -device loader,file=BL1.elf -cpu cortex-a53,rvbar=0xC004000000 \
> >>> -d unimp -semihosting-config enable=on,target=native \
> >>> -monitor telnet:localhost:1235,server,nowait \
> >>> -gdb tcp::1236
> >>>
> >>> The BL1.elf is our BootROM application that runs from ROM address
> >> 0xC004000000.
> >>> Just for debugging purpose we've increased the ROM size so it can include
> >> the images/barebox-spider-mk1-evk.img (as a const array).
> >>> BL1 then copy it (using memcpy) to address 0 and jumps there for
> >> execution.
> >>
> >> Sounds ok.
> >>
> >>> On the real ASIC this address will be the DRAM and indeed will need to be
> >> initialized before the copy but here on QEMU it is not required.
> >>
> >> I see. You could still have your bootrom move barebox into SRAM and then
> >>
> >> barebox_arm_entry(DRAM_ADDR, SZ_128M,
> __dtb_spider_mk1_evk_start);
> >>
> >> To have PBL extract barebox to DRAM. Even if you don't need need DRAM
> >> setup in QEMU, the flow would be similar to what you will have on actual
> >> silicon.
> >>
> >>> The lowlevel.c of spider-evk was modified to use DRAM_ADDR 0x400000
> >> (4MB from start) and MY_STACK_TOP was set to 0x8000000 (128M).
> >>
> >> That's not needed. While you don't have control where barebox PBL will be
> >> located
> >> (depends on BootROM), barebox will extract itself to the end of DRAM
> >> without
> >> overwriting itself, so you can just use DRAM_ADDR 0 normally. Eventually,
> >> stack
> >> top should go into SRAM, but anywhere that works is ok.
> >>
> >>> In addition, I implemented putc_ll (currently hard-coded in
> >> include/debug_ll.h) and opened log level to VERBOSE_DEBUG (currently
> just
> >> hard-coded in printk.h).
> >>
> >> There's CONFIG_DEBUG_PBL you can enable to get all these messages by
> >> default.
> >>
> >>> I see the following (which makes sense) logs on QEMU terminal:
> >>> uncompress.c: memory at 0x00400000, size 0x00200000
> >>> uncompress.c: uncompressing barebox binary at 0x0000000000002200
> >> (size 0x0001d3b2) to 0x00400000 (uncompressed size: 0x000373d0)
> >>
> >> Why pass only 2M to barebox_arm_entry? While this need not be the
> whole
> >> of RAM, this
> >> initial memory is what barebox will use for itself including its final stack and
> >> malloc area. barebox will also not place itself into the last 1M AFAIK, so 2M
> >> may not work ok. You should use the minimum possible RAM here or if you
> >> can detect
> >> in PBL how much RAM you have or just the whole RAM bank. I am not sure
> >> anything lower
> >> than SZ_4M would work ok. (Note this is DRAM size, not SRAM. barebox
> PBL
> >> is fine being
> >> called from 64K SRAMs, it just needs DRAM to extract to).
> >>
> >>> I then connect with aarch64-none-elf-gdb, load the barebox symbols (to
> >> 0x400000) and check the current execution state (program counter and
> >> stack).
> >>> Looks like the code is stuck on function register_autoboot_vars:
> >>> sp 0x5f7e60 0x5f7e60
> >>> pc 0x401264 0x401264 <register_autoboot_vars+24>
> >>>
> >>> Few observations:
> >>> 1. The PBL was using stack top located on 0x8000000 (which is
> >> MY_STACK_TOP). Found it be causing a breakpoint on the PBL.
> >>> 2. Barebox uses a stack top on 0x600000 which is probably calculated
> from
> >> my new DRAM_ADDR and SZ_2M given to the function call:
> >>> barebox_arm_entry(DRAM_ADDR, SZ_2M,
> __dtb_spider_mk1_evk_start);
> >>>
> >>> This is great! I am starting to find my way.
> >>
> >> :) Ye, the ENTRY_FUNCTION_WITHSTACK is only when the BootROM
> doesn't
> >> enter
> >> with a valid stack pointer. It's overwritten as soon as barebox is told
> >> about the initial memory layout (with barebox_arm_entry).
> >>
> >>> When the barebox execution didn't print anything to the terminal I
> >> remembered that we used a place holder on the dtsi for the uart.
> >>> So now I changed it to:
> >>> uart0: serial@d000307000 {
> >>> compatible = "arm,pl011", "arm,primecell";
> >>> reg = <0xd0 0x307000 0 0x1000>;
> >>> }
> >>> (Our QEMU UART is currently using pl011 device.)
> >>
> >> Looks ok. Don't forget to enable the driver (via make menuconfig).
> >>
> >>> After some time (trying to debug by enabling MMU but then reverted the
> >> code back), I got to a point that when I try to run again I am getting an
> >> exception.
> >>> I can swear all code changes were reverted back to the point where I saw
> the
> >> barebox stuck on register_autoboot_vars but now it just cases an
> exception.
> >>> The exception vector code is located on our ROM (part of BL1 code) and
> the
> >> logs shows that the link register has the value 0x401218 which suggest the
> >> following code:
> >>> 0000000000001200 <load_environment>:
> >>> 1200: a9be7bfd stp x29, x30, [sp, #-32]!
> >>> 1204: 910003fd mov x29, sp
> >>> 1208: a90153f3 stp x19, x20, [sp, #16]
> >>> 120c: 94000a07 bl 3a28 <default_environment_path_get>
> >>> 1210: d00000f3 adrp x19, 1f000 <do_cpuinfo+0x1f0>
> >>> 1214: 912a7273 add x19, x19, #0xa9c
> >>> 1218: aa0003f4 mov x20, x0
> >>>
> >>> Any ideas or suggestions how to proceed with the debugging?
> >>
> >> You shouldn't need to touch the MMU code. If your initial memory setup
> >> is wonky, you may end up overwriting stuff. Try again with bigger memory.
> >>
> >>> BTW, to answer your questions:
> >>> The SRAM of 4MB is the only one we have because we assumed it is only
> for
> >> BootROM to load a PBL
> >>
> >> Ok. Sometimes there are SRAMs for use with DMA. I asked, because a
> SRAM
> >> in the first 4M
> >> would lend itself nicely as stack, but if there is none, we can adjust
> >> ENTRY_FUNCTION_WITHSTACK to accept a 64-bit parameter.
> >>
> >> Cheers,
> >> Ahmad
> >>
> >>> Thank you very much,
> >>> Cheers,
> >>> Lior.
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: Ahmad Fatoum <a.fatoum@pengutronix.de>
> >>>> Sent: Monday, May 29, 2023 10:03 PM
> >>>> To: Lior Weintraub <liorw@pliops.com>; Ahmad Fatoum
> <ahmad@a3f.at>;
> >>>> barebox@lists.infradead.org
> >>>> Subject: Re: [PATCH v2] Porting barebox to a new SoC
> >>>>
> >>>> CAUTION: External Sender
> >>>>
> >>>> Hello Lior,
> >>>>
> >>>> On 29.05.23 15:34, Lior Weintraub wrote:
> >>>>> Hi Ahmad,
> >>>>>
> >>>>> I have revised the addresses and used DRAM address @ 0 instead:
> >>>>> #define UARTBASE (0xD000307000)
> >>>>> #define DRAM_ADDR (0x00000000)
> >>>>> #define MY_STACK_TOP (0x00000000 + SZ_2M) // Set the stack 2MB
> >> from
> >>>> DRAM start
> >>>>
> >>>> Is DRAM configured by the time barebox runs? If not, you should keep
> >> stack
> >>>> top
> >>>> in SRAM, until you have setup memory in prebootloader (PBL). Is the 4M
> >>>> SRAM
> >>>> the only on-chip SRAM you have?
> >>>>
> >>>>> static inline void spider_serial_putc(void *base, int c)
> >>>>> {
> >>>>> *((volatile unsigned *)base) = c;
> >>>>
> >>>> There's a helper for that: writel(c, base); In barebox, it's equivalent
> >>>> to the volatile access, but in Linux it involves a write memory barrier.
> >>>> We try to write code in barebox, so it's easily reusable in Linux (and
> >>>> the other way round).
> >>>>
> >>>>> }
> >>>>>
> >>>>> I will try to test it on QEMU using an initial QEMU machine we made for
> >>>> Spider.
> >>>>> In this machine we only have 3 memory regions and a PL011 UART:
> >>>>> spider_soc_memories soc_memories[] = {
> >>>>> {.name = "SPIDER_GPRAM", .add = 0xC000000000ULL, .size = 4 *
> MiB},
> >>>>> {.name = "SPIDER_ROM", .add = 0xC004000000ULL, .size = 128 *
> >> KiB},
> >>>>> {.name = "SPIDER_DRAM", .add = 0x0000000000ULL, .size = 1 *
> GiB},
> >>>>> };
> >>>>>
> >>>>> This special QEMU machine can run our BL1 code from "ROM" address
> >> (we
> >>>> set the RVBAR to point there).
> >>>>> So my idea is to test the barebox image by the following steps:
> >>>>> 1. Modify the QEMU code to have a "ROM" with the size of 128M.
> >>>>> 2. Compile our BL1 code to include the barebox.bin as a const array,
> copy
> >> it
> >>>> to "DRAM" @ address 0 and jump there.
> >>>>
> >>>> Why not map QEMU -bios option to SRAM? (Or DRAM directly, if it
> needs
> >> no
> >>>> special setup from
> >>>> barebox side).
> >>>>
> >>>>> For this to work I wanted to understand how to call (i.e. what
> arguments
> >> to
> >>>> pass) to barebox.
> >>>>
> >>>> barebox doesn't expect any arguments, because most BootROMs don't
> >> pass
> >>>> anything useful.
> >>>> Some pass information about bootsource though, so that's why the
> >>>> ENTRY_FUNCTION has
> >>>> r0, r1 and r2 as parameters, but you need not use them.
> >>>>
> >>>>> So I checked the barebox.map and found the function "start" on
> address
> >> 0.
> >>>>
> >>>> You may know that Linux on some platforms comes with a decompressor
> >> that
> >>>> is glued to the
> >>>> front of the kernel image and extracts the compressed kernel image.
> >> barebox
> >>>> has the same
> >>>> concept. The prebootloader is uncompressed and runs (starting from
> >>>> ENTRY_FUNCTION) and
> >>>> then does some early setup (e.g. enable clocks, configure PMIC, setup
> >> DRAM,
> >>>> load secure
> >>>> monitor (BL31), ...etc.) and then it decompresses barebox proper into
> >> DRAM.
> >>>>
> >>>> barebox.bin <- barebox proper. You don't usually need that.
> >>>> barebox.elf <- ELF binary for the above (for gdb)
> >>>> barebox.map <- map file of the above
> >>>>
> >>>> images/barebox-spider-mk1-evk.img <- complete barebox image (PBL +
> >>>> barebox proper)
> >>>> images/start_spider_mk1_evk.pbl <- ELF image for the above
> >>>> images/start_spider_mk1_evk.pbl.map <- map file of the above
> >>>>
> >>>> If you want to follow barbeox from the start, begin at
> >> start_spider_mk1_evk.
> >>>>
> >>>>> Then I went to arch/arm/cpu/start.c and realized that the code is
> compiled
> >>>> with CONFIG_PBL_IMAGE.
> >>>>> In that case I assume I need to pass 3 arguments and use this function
> >>>> prototype:
> >>>>> void start(unsigned long membase, unsigned long memsize, void
> >>>> *boarddata);
> >>>>
> >>>> barebox prebootloader takes care of this, so you don't need to do
> anything.
> >>>>
> >>>>> Few questions:
> >>>>> 1. Will that call work:
> >>>>> typedef void (*barebox_start)(unsigned long , unsigned long , void *);
> >>>>> #define DRAM_START (0)
> >>>>> barebox_start p_barebox = (barebox_start)DRAM_START;
> >>>>> p_barebox(DRAM_START, DRAM_START+SZ_2M, (void
> >>>> *)(DRAM_START+SZ_4M));
> >>>>> This assumes that my BL1 code also copied the device tree (barebox-
> dt-
> >>>> 2nd.img? start_dt_2nd.pblb? start_spider_mk1_evk.pblb?)
> >>>>
> >>>> The device tree is built into the PBL and passed to barebox proper. This
> >>>> allows us to use the same barebox proper binary and link it with a
> different
> >>>> prebootloader for each SoC/board, all in the same build.
> >>>>
> >>>> barebox-dt-2nd.img is a special image that looks exactly like a Linux
> kernel:
> >>>>
> >>>> images/barebox-dt-2nd.img: Linux kernel ARM64 boot executable
> Image,
> >>>> little-endian, 4K pages
> >>>>
> >>>> and can thus be used for booting for easy chainloading from other
> >>>> bootloaders or for running
> >>>> with QEMU -kernel. You shouldn't need it right now.
> >>>>
> >>>>> 2. Do I want to have my code compiled with CONFIG_PBL_IMAGE?
> >>>>> If I understand correctly, it means that my code will provide a PBL
> (a.k.a
> >>>> BL2) which will set the DRAM and STACK among other things (MMU?).
> >>>>
> >>>> The patch I sent already builds a PBL. You will need to fill out
> >>>> start_spider_mk1_evk
> >>>> to do all the other early initialization you need. Then you call
> >>>> barebox_arm_entry
> >>>> with device tree and memory size and it will take care to do stack setup in
> >> new
> >>>> memory region, MMU setup (if enabled) and chainloading barebox
> proper.
> >>>>
> >>>> Note that PBL isn't necessary BL2. You can chainload barebox from within
> >>>> barebox (i.e.
> >>>> in EL2 or EL1), which is useful for debugging. You will thus often find PBL
> >> code
> >>>> that
> >>>> does
> >>>>
> >>>> if (current_el() == 3) {
> >>>> /* Do BL2 setup */
> >>>> chainload();
> >>>> __builtin_unreachable();
> >>>> }
> >>>>
> >>>> barebox_arm_entry(...)
> >>>>
> >>>> See for example arch/arm/boards/innocomm-imx8mm-wb15/lowlevel.c
> >>>>
> >>>> to see a real-world example of another Cortex-A53.
> >>>>
> >>>>> In that case I assume it is OK.
> >>>>> 3. If I try to remove it by having CONFIG_PBL_IMAGE=n on
> >> spider_defconfig
> >>>> this doesn't do anything
> >>>>> The build (make spider_defconfig) ignores it and say that " No change
> to
> >>>> .config ".
> >>>>
> >>>> Another symbol forces it to be enabled. If you are curious, run make
> >>>> menuconfig
> >>>> and then search (/) for the symbol and it will list, whether it's enabled
> and
> >>>> why:
> >>>>
> >>>> Selected by [y]:
> >>>> - PBL_MULTI_IMAGES [=y] && HAVE_PBL_MULTI_IMAGES [=y]
> >>>>
> >>>> I'd suggest you avoid modifying the .config file manually. always use
> >>>> menuconfig.
> >>>>
> >>>>> 4. I also tried to understand how to implement PUTC_LL but not sure I
> >>>> understand.
> >>>>> 4.1 When I set "CONFIG_DEBUG_LL=y" on spider_defconfig it is again
> >> not
> >>>> written to .config and I get " No change to .config " message.
> >>>>
> >>>> You must:
> >>>>
> >>>> - select HAS_DEBUG_LL from MACH_SPIDER
> >>>> - Add your arch to arch/arm/include/asm/debug_ll.h
> >>>> - Then implement PUTC_LL in e.g. mach/spider/debug_ll.h
> >>>>
> >>>>> 4.2 Do I need to have my own debug_ll.h file?
> >>>>
> >>>> Yes. See above.
> >>>>
> >>>>> 5. When I make changes to spider_defconfig and try to regenerate the
> >>>> .config and I get " No change to .config " message, does it mean that
> those
> >>>> macros are "hidden" symbols like you said about the CONFIG_CPU_V8?
> >>>>
> >>>> Yes. Just check menuconfig to see how symbols relate to each other.
> >>>> This is 1:1 like it's in Linux, so it'll come in handy when you do
> >>>> the kernel port too ;)
> >>>>
> >>>>> Apologize for so many questions :-)
> >>>>
> >>>> No problem. Looking forward to your patches ;)
> >>>>
> >>>>
> >>>> Cheers,
> >>>> Ahmad
> >>>>
> >>>>> Cheers,
> >>>>> Lior.
> >>>>>
> >>>>> -----Original Message-----
> >>>>> From: Lior Weintraub
> >>>>> Sent: Sunday, May 28, 2023 11:16 PM
> >>>>> To: Ahmad Fatoum <ahmad@a3f.at>; barebox@lists.infradead.org
> >>>>> Subject: RE: [PATCH v2] Porting barebox to a new SoC
> >>>>>
> >>>>> Hi Ahmad,
> >>>>>
> >>>>> Thank you so much for your kind support!
> >>>>>
> >>>>> Indeed we also have a 16GB DRAM that starts from address 0 (though
> >>>> currently we don't have the controller settings (under development)).
> >>>>>
> >>>>> I also wrote the BootROM (BL1) for this SoC (128KB ROM @ address
> >>>> 0xC004000000).
> >>>>> I understand now that it would be best for me to develop BL2 that will
> run
> >>>> from our SRAM.
> >>>>>
> >>>>> As this BL2 code is bare-metal I have no problem or limitations with the
> 40
> >>>> bit addresses.
> >>>>> The BL2 code will initialize the DRAM controller and then copy Barebox
> >> image
> >>>> from NOR Flash to address 0 of the DRAM.
> >>>>> Our NOR Flash is 128MB in size and it is accessed via QSPI controller.
> >>>>>
> >>>>> I tried applying your suggested patch but got an error while doing so:
> >>>>> $git apply 0002-Ahmad.patch
> >>>>> 0002-Ahmad.patch:115: trailing whitespace.
> >>>>> .of_compatible = spider_board_of_match, };
> >>>>> error: corrupt patch at line 117
> >>>>>
> >>>>> After some digging I found that my Outlook probably messed with the
> >> patch
> >>>> format (even though I am using text only and no HTML format).
> >>>>> When I went to the web and copied the patch from there (mailing list
> >>>> archive) it was working well (i.e. no compilation error).
> >>>>>
> >>>>> Cheers,
> >>>>> Lior.
> >>>>>
> >>>>> -----Original Message-----
> >>>>> From: Ahmad Fatoum <ahmad@a3f.at>
> >>>>> Sent: Sunday, May 28, 2023 6:38 PM
> >>>>> To: barebox@lists.infradead.org
> >>>>> Cc: Lior Weintraub <liorw@pliops.com>
> >>>>> Subject: [PATCH v2] Porting barebox to a new SoC
> >>>>>
> >>>>> CAUTION: External Sender
> >>>>>
> >>>>> From: Lior Weintraub <liorw@pliops.com>
> >>>>>
> >>>>> Hi,
> >>>>>
> >>>>> I tried to follow the porting guide on https://ddec1-0-en-
> >>>>
> >>
> ctp.trendmicro.com:443/wis/clicktime/v1/query?url=https%3a%2f%2fwww.
> >>>>
> >>
> barebox.org%2fdoc%2flatest%2fdevel%2fporting.html%23&umid=60097eda
> >>>> -f136-45a1-9c8e-
> >>>> cf6a76e45cf8&auth=860a7ebb9feba264acc79b6e38eb59582349362c-
> >>>> 480ae23736add41c88ab8d30c090a75517ca7f9e but couldn't follow
> the
> >>>> instructions.
> >>>>> I would like to port barebox to a new SoC (which is not a derivative of
> any
> >>>> known SoC).
> >>>>> It has the following:
> >>>>> * Single Cortex A53
> >>>>> * SRAM (4MB) located on address 0xC000000000
> >>>>>
> >>>>> The below patch shows my initial test to try and have a starting point.
> >>>>> I am setting env variables:
> >>>>> export ARCH=arm64
> >>>>> export CROSS_COMPILE=/home/pliops/workspace/ARM/arm-gnu-
> >>>> toolchain/bin/aarch64-none-elf-
> >>>>>
> >>>>> Then I build with:
> >>>>> make spider_defconfig && make
> >>>>>
> >>>>> This gives an error:
> >>>>> aarch64-none-elf-gcc: error: unrecognized argument in option '-
> >> mabi=apcs-
> >>>> gnu'
> >>>>> aarch64-none-elf-gcc: note: valid arguments to '-mabi=' are: ilp32 lp64
> >>>>> aarch64-none-elf-gcc: error: unrecognized command-line option '-
> msoft-
> >>>> float'
> >>>>> aarch64-none-elf-gcc: error: unrecognized command-line option '-mno-
> >>>> unaligned-access'
> >>>>> /home/pliops/workspace/simplest-linux-
> >>>> demo/barebox/scripts/Makefile.build:140: recipe for target
> >>>> 'scripts/mod/empty.o' failed
> >>>>> make[2]: *** [scripts/mod/empty.o] Error 1
> >>>>>
> >>>>> Not sure why the compiler flags get -mabi=apcs-gnu when I explicitly set
> >>>> CONFIG_CPU_V8 and the arch/arm/Makefile has:
> >>>>> ifeq ($(CONFIG_CPU_V8), y)
> >>>>> CFLAGS_ABI :=-mabi=lp64
> >>>>>
> >>>>> The changes I did:
> >>>>> >From 848b5f9b18bb1bb96d197cbc1b368ee0a729d581 Mon Sep 17
> >>>> 00:00:00 2001
> >>>>> ---
> >>>>> arch/arm/Kconfig | 13 ++++++++
> >>>>> arch/arm/Makefile | 1 +
> >>>>> arch/arm/boards/Makefile | 1 +
> >>>>> arch/arm/boards/spider-evk/Makefile | 4 +++
> >>>>> arch/arm/boards/spider-evk/board.c | 26 +++++++++++++++
> >>>>> arch/arm/boards/spider-evk/lowlevel.c | 30 +++++++++++++++++
> >>>>> arch/arm/configs/spider_defconfig | 8 +++++
> >>>>> arch/arm/dts/Makefile | 1 +
> >>>>> arch/arm/dts/spider-mk1-evk.dts | 10 ++++++
> >>>>> arch/arm/dts/spider-mk1.dtsi | 46
> +++++++++++++++++++++++++++
> >>>>> arch/arm/mach-spider/Kconfig | 16 ++++++++++
> >>>>> arch/arm/mach-spider/Makefile | 1 +
> >>>>> arch/arm/mach-spider/lowlevel.c | 14 ++++++++
> >>>>> images/Makefile | 1 +
> >>>>> images/Makefile.spider | 5 +++
> >>>>> include/mach/spider/lowlevel.h | 7 ++++
> >>>>> 16 files changed, 184 insertions(+)
> >>>>> create mode 100644 arch/arm/boards/spider-evk/Makefile
> >>>>> create mode 100644 arch/arm/boards/spider-evk/board.c
> >>>>> create mode 100644 arch/arm/boards/spider-evk/lowlevel.c
> >>>>> create mode 100644 arch/arm/configs/spider_defconfig create mode
> >>>> 100644 arch/arm/dts/spider-mk1-evk.dts create mode 100644
> >>>> arch/arm/dts/spider-mk1.dtsi create mode 100644 arch/arm/mach-
> >>>> spider/Kconfig create mode 100644 arch/arm/mach-spider/Makefile
> >> create
> >>>> mode 100644 arch/arm/mach-spider/lowlevel.c create mode 100644
> >>>> images/Makefile.spider create mode 100644
> >> include/mach/spider/lowlevel.h
> >>>>>
> >>>>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index
> >>>> e76ee0f6dfe1..e5dcf128447e 100644
> >>>>> --- a/arch/arm/Kconfig
> >>>>> +++ b/arch/arm/Kconfig
> >>>>> @@ -255,6 +255,18 @@ config ARCH_ROCKCHIP
> >>>>> select HAS_DEBUG_LL
> >>>>> imply GPIO_ROCKCHIP
> >>>>>
> >>>>> +config ARCH_SPIDER
> >>>>> + bool "Pliops Spider based"
> >>>>> + depends on 64BIT
> >>>>> + depends on ARCH_MULTIARCH
> >>>>> + select GPIOLIB
> >>>>> + select HAVE_PBL_MULTI_IMAGES
> >>>>> + select COMMON_CLK
> >>>>> + select CLKDEV_LOOKUP
> >>>>> + select COMMON_CLK_OF_PROVIDER
> >>>>> + select OFTREE
> >>>>> + select OFDEVICE
> >>>>> +
> >>>>> config ARCH_STM32MP
> >>>>> bool "STMicroelectronics STM32MP"
> >>>>> depends on 32BIT
> >>>>> @@ -331,6 +343,7 @@ source "arch/arm/mach-omap/Kconfig"
> >>>>> source "arch/arm/mach-pxa/Kconfig"
> >>>>> source "arch/arm/mach-rockchip/Kconfig"
> >>>>> source "arch/arm/mach-socfpga/Kconfig"
> >>>>> +source "arch/arm/mach-spider/Kconfig"
> >>>>> source "arch/arm/mach-stm32mp/Kconfig"
> >>>>> source "arch/arm/mach-versatile/Kconfig"
> >>>>> source "arch/arm/mach-vexpress/Kconfig"
> >>>>> diff --git a/arch/arm/Makefile b/arch/arm/Makefile index
> >>>> 35ebc70f44e2..4c63dfee48f4 100644
> >>>>> --- a/arch/arm/Makefile
> >>>>> +++ b/arch/arm/Makefile
> >>>>> @@ -101,6 +101,7 @@ machine-$(CONFIG_ARCH_MXS) += mxs
> >>>>> machine-$(CONFIG_ARCH_MVEBU) += mvebu
> >>>>> machine-$(CONFIG_ARCH_NOMADIK) += nomadik
> >>>>> machine-$(CONFIG_ARCH_OMAP) += omap
> >>>>> +machine-$(CONFIG_ARCH_SPIDER) += spider
> >>>>> machine-$(CONFIG_ARCH_PXA) += pxa
> >>>>> machine-$(CONFIG_ARCH_ROCKCHIP) += rockchip
> >>>>> machine-$(CONFIG_ARCH_SAMSUNG) += samsung
> >>>>> diff --git a/arch/arm/boards/Makefile b/arch/arm/boards/Makefile
> index
> >>>> 2877debad535..6fe0a90c81ea 100644
> >>>>> --- a/arch/arm/boards/Makefile
> >>>>> +++ b/arch/arm/boards/Makefile
> >>>>> @@ -135,6 +135,7 @@ obj-
> >>>> $(CONFIG_MACH_SOCFPGA_TERASIC_DE10_NANO) += terasic-
> de10-
> >>>> nano/
> >>>>> obj-$(CONFIG_MACH_SOCFPGA_TERASIC_SOCKIT) += terasic-
> sockit/
> >>>>> obj-$(CONFIG_MACH_SOLIDRUN_CUBOX) += solidrun-cubox/
> >>>>> obj-$(CONFIG_MACH_SOLIDRUN_MICROSOM) += solidrun-
> >>>> microsom/
> >>>>> +obj-$(CONFIG_MACH_SPIDER_MK1_EVK) += spider-evk/
> >>>>> obj-$(CONFIG_MACH_STM32MP15XX_DKX) += stm32mp15xx-
> >> dkx/
> >>>>> obj-$(CONFIG_MACH_STM32MP13XX_DK) += stm32mp13xx-
> dk/
> >>>>> obj-$(CONFIG_MACH_LXA_MC1) += lxa-mc1/
> >>>>> diff --git a/arch/arm/boards/spider-evk/Makefile
> >>>> b/arch/arm/boards/spider-evk/Makefile
> >>>>> new file mode 100644
> >>>>> index 000000000000..da63d2625f7a
> >>>>> --- /dev/null
> >>>>> +++ b/arch/arm/boards/spider-evk/Makefile
> >>>>> @@ -0,0 +1,4 @@
> >>>>> +# SPDX-License-Identifier: GPL-2.0-only
> >>>>> +
> >>>>> +obj-y += board.o
> >>>>> +lwl-y += lowlevel.o
> >>>>> diff --git a/arch/arm/boards/spider-evk/board.c
> >> b/arch/arm/boards/spider-
> >>>> evk/board.c
> >>>>> new file mode 100644
> >>>>> index 000000000000..3920e83b457d
> >>>>> --- /dev/null
> >>>>> +++ b/arch/arm/boards/spider-evk/board.c
> >>>>> @@ -0,0 +1,26 @@
> >>>>> +#include <bbu.h>
> >>>>> +#include <boot.h>
> >>>>> +#include <bootm.h>
> >>>>> +#include <common.h>
> >>>>> +#include <deep-probe.h>
> >>>>> +#include <environment.h>
> >>>>> +#include <fcntl.h>
> >>>>> +#include <globalvar.h>
> >>>>> +
> >>>>> +static int spider_board_probe(struct device *dev) {
> >>>>> + /* Do some board-specific setup */
> >>>>> + return 0;
> >>>>> +}
> >>>>> +
> >>>>> +static const struct of_device_id spider_board_of_match[] = {
> >>>>> + { .compatible = "pliops,spider-mk1-evk" },
> >>>>> + { /* sentinel */ },
> >>>>> +};
> >>>>> +
> >>>>> +static struct driver spider_board_driver = {
> >>>>> + .name = "board-spider",
> >>>>> + .probe = spider_board_probe,
> >>>>> + .of_compatible = spider_board_of_match, };
> >>>>> +device_platform_driver(spider_board_driver);
> >>>>> diff --git a/arch/arm/boards/spider-evk/lowlevel.c
> >>>> b/arch/arm/boards/spider-evk/lowlevel.c
> >>>>> new file mode 100644
> >>>>> index 000000000000..e36fcde4208e
> >>>>> --- /dev/null
> >>>>> +++ b/arch/arm/boards/spider-evk/lowlevel.c
> >>>>> @@ -0,0 +1,30 @@
> >>>>> +#include <common.h>
> >>>>> +#include <asm/barebox-arm.h>
> >>>>> +#include <mach/spider/lowlevel.h>
> >>>>> +
> >>>>> +#define BASE_ADDR (0xD000307000)
> >>>>> +#define GPRAM_ADDR (0xC000000000)
> >>>>> +#define MY_STACK_TOP (0xC000000000 + SZ_2M) // Set the stack
> >> 2MB
> >>>> from GPRAM start (excatly in the middle)
> >>>>> +static inline void spider_serial_putc(void *base, int c) {
> >>>>> +// if (!(readl(base + UCR1) & UCR1_UARTEN))
> >>>>> +// return;
> >>>>> +//
> >>>>> +// while (!(readl(base + USR2) & USR2_TXDC));
> >>>>> +//
> >>>>> +// writel(c, base + URTX0);
> >>>>> +}
> >>>>> +
> >>>>> +ENTRY_FUNCTION_WITHSTACK(start_spider_mk1_evk,
> MY_STACK_TOP,
> >>>> r0, r1,
> >>>>> +r2) {
> >>>>> + extern char __dtb_spider_mk1_evk_start[];
> >>>>> +
> >>>>> + spider_lowlevel_init();
> >>>>> +
> >>>>> + relocate_to_current_adr();
> >>>>> + setup_c();
> >>>>> +
> >>>>> + pbl_set_putc(spider_serial_putc, (void *)BASE_ADDR);
> >>>>> +
> >>>>> + barebox_arm_entry(GPRAM_ADDR, SZ_2M,
> >>>>> +__dtb_spider_mk1_evk_start); }
> >>>>> diff --git a/arch/arm/configs/spider_defconfig
> >>>> b/arch/arm/configs/spider_defconfig
> >>>>> new file mode 100644
> >>>>> index 000000000000..c91bb889d97f
> >>>>> --- /dev/null
> >>>>> +++ b/arch/arm/configs/spider_defconfig
> >>>>> @@ -0,0 +1,8 @@
> >>>>> +CONFIG_ARCH_SPIDER=y
> >>>>> +CONFIG_MACH_SPIDER_MK1_EVK=y
> >>>>> +CONFIG_BOARD_ARM_GENERIC_DT=y
> >>>>> +CONFIG_MALLOC_TLSF=y
> >>>>> +CONFIG_KALLSYMS=y
> >>>>> +CONFIG_RELOCATABLE=y
> >>>>> +CONFIG_CONSOLE_ALLOW_COLOR=y
> >>>>> +CONFIG_PBL_CONSOLE=y
> >>>>> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile index
> >>>> 98f4c4e0194b..94b304d4878f 100644
> >>>>> --- a/arch/arm/dts/Makefile
> >>>>> +++ b/arch/arm/dts/Makefile
> >>>>> @@ -134,6 +134,7 @@ lwl-$(CONFIG_MACH_SOLIDRUN_CUBOX) +=
> >> dove-
> >>>> cubox-bb.dtb.o
> >>>>> lwl-$(CONFIG_MACH_SOLIDRUN_MICROSOM) += imx6dl-
> >>>> hummingboard.dtb.o imx6q-hummingboard.dtb.o \
> >>>>> imx6dl-hummingboard2.dtb.o imx6q-
> >>>> hummingboard2.dtb.o \
> >>>>> imx6q-h100.dtb.o
> >>>>> +lwl-$(CONFIG_MACH_SPIDER_MK1_EVK) += spider-mk1-evk.dtb.o
> >>>>> lwl-$(CONFIG_MACH_SKOV_IMX6) += imx6s-skov-imx6.dtb.o imx6dl-
> >> skov-
> >>>> imx6.dtb.o imx6q-skov-imx6.dtb.o
> >>>>> lwl-$(CONFIG_MACH_SKOV_ARM9CPU) += at91-skov-arm9cpu.dtb.o
> >>>>> lwl-$(CONFIG_MACH_SEEED_ODYSSEY) += stm32mp157c-
> odyssey.dtb.o
> >>>> diff --git a/arch/arm/dts/spider-mk1-evk.dts b/arch/arm/dts/spider-
> mk1-
> >>>> evk.dts new file mode 100644 index 000000000000..b8081cb85bf8
> >>>>> --- /dev/null
> >>>>> +++ b/arch/arm/dts/spider-mk1-evk.dts
> >>>>> @@ -0,0 +1,10 @@
> >>>>> +// SPDX-License-Identifier: GPL-2.0 OR X11
> >>>>> +
> >>>>> +/dts-v1/;
> >>>>> +
> >>>>> +#include "spider-mk1.dtsi"
> >>>>> +
> >>>>> +/ {
> >>>>> + model = "Pliops Spider MK-I EVK";
> >>>>> + compatible = "pliops,spider-mk1-evk"; };
> >>>>> diff --git a/arch/arm/dts/spider-mk1.dtsi b/arch/arm/dts/spider-
> mk1.dtsi
> >>>> new file mode 100644 index 000000000000..d4613848169d
> >>>>> --- /dev/null
> >>>>> +++ b/arch/arm/dts/spider-mk1.dtsi
> >>>>> @@ -0,0 +1,46 @@
> >>>>> +// SPDX-License-Identifier: GPL-2.0 OR X11
> >>>>> +
> >>>>> +/ {
> >>>>> + #address-cells = <2>;
> >>>>> + #size-cells = <2>;
> >>>>> +
> >>>>> + chosen {
> >>>>> + stdout-path = &uart0;
> >>>>> + };
> >>>>> +
> >>>>> + aliases {
> >>>>> + serial0 = &uart0;
> >>>>> + };
> >>>>> +
> >>>>> + cpus {
> >>>>> + #address-cells = <1>;
> >>>>> + #size-cells = <0>;
> >>>>> +
> >>>>> + cpu0: cpu@0 {
> >>>>> + device_type = "cpu";
> >>>>> + compatible = "arm,cortex-a53";
> >>>>> + reg = <0x0>;
> >>>>> + };
> >>>>> + };
> >>>>> +
> >>>>> + memory@1000000 {
> >>>>> + reg = <0x0 0x1000000 0x0 0x400000>; /* 128M */
> >>>>> + device_type = "memory";
> >>>>> + };
> >>>>> +
> >>>>> + soc {
> >>>>> + #address-cells = <2>;
> >>>>> + #size-cells = <2>;
> >>>>> + ranges;
> >>>>> +
> >>>>> + sram@c000000000 {
> >>>>> + compatible = "mmio-sram";
> >>>>> + reg = <0xc0 0x0 0x0 0x400000>;
> >>>>> + };
> >>>>> +
> >>>>> + uart0: serial@d000307000 {
> >>>>> + compatible = "pliops,spider-uart";
> >>>>> + reg = <0xd0 0x307000 0 0x1000>;
> >>>>> + };
> >>>>> + };
> >>>>> +};
> >>>>> diff --git a/arch/arm/mach-spider/Kconfig b/arch/arm/mach-
> >> spider/Kconfig
> >>>> new file mode 100644 index 000000000000..6d2f888a5fd8
> >>>>> --- /dev/null
> >>>>> +++ b/arch/arm/mach-spider/Kconfig
> >>>>> @@ -0,0 +1,16 @@
> >>>>> +# SPDX-License-Identifier: GPL-2.0-only
> >>>>> +
> >>>>> +if ARCH_SPIDER
> >>>>> +
> >>>>> +config ARCH_SPIDER_MK1
> >>>>> + bool
> >>>>> + select CPU_V8
> >>>>> + help
> >>>>> + The first Cortex-A53-based SoC of the spider family.
> >>>>> + This symbol is invisble and select by boards
> >>>>> +
> >>>>> +config MACH_SPIDER_MK1_EVK
> >>>>> + bool "Pliops Spider Reference Design Board"
> >>>>> + select ARCH_SPIDER_MK1
> >>>>> +
> >>>>> +endif
> >>>>> diff --git a/arch/arm/mach-spider/Makefile b/arch/arm/mach-
> >>>> spider/Makefile new file mode 100644 index
> >> 000000000000..b08c4a93ca27
> >>>>> --- /dev/null
> >>>>> +++ b/arch/arm/mach-spider/Makefile
> >>>>> @@ -0,0 +1 @@
> >>>>> +lwl-y += lowlevel.o
> >>>>> diff --git a/arch/arm/mach-spider/lowlevel.c b/arch/arm/mach-
> >>>> spider/lowlevel.c new file mode 100644 index
> >>>> 000000000000..5d62ef0f39e5
> >>>>> --- /dev/null
> >>>>> +++ b/arch/arm/mach-spider/lowlevel.c
> >>>>> @@ -0,0 +1,14 @@
> >>>>> +// SPDX-License-Identifier: GPL-2.0+
> >>>>> +
> >>>>> +#include <linux/types.h>
> >>>>> +#include <mach/spider/lowlevel.h>
> >>>>> +#include <asm/barebox-arm-head.h>
> >>>>> +
> >>>>> +void spider_lowlevel_init(void)
> >>>>> +{
> >>>>> + arm_cpu_lowlevel_init();
> >>>>> + /*
> >>>>> + * not yet relocated, only do writel/readl for stuff that's
> >>>>> + * critical to run early. No global variables allowed.
> >>>>> + */
> >>>>> +}
> >>>>> diff --git a/images/Makefile b/images/Makefile index
> >>>> c93f9e268978..97521e713228 100644
> >>>>> --- a/images/Makefile
> >>>>> +++ b/images/Makefile
> >>>>> @@ -150,6 +150,7 @@ include $(srctree)/images/Makefile.mxs
> include
> >>>> $(srctree)/images/Makefile.omap3 include
> >>>> $(srctree)/images/Makefile.rockchip
> >>>>> include $(srctree)/images/Makefile.socfpga
> >>>>> +include $(srctree)/images/Makefile.spider
> >>>>> include $(srctree)/images/Makefile.stm32mp
> >>>>> include $(srctree)/images/Makefile.tegra include
> >>>> $(srctree)/images/Makefile.versatile
> >>>>> diff --git a/images/Makefile.spider b/images/Makefile.spider new file
> >> mode
> >>>> 100644 index 000000000000..c32f2762df04
> >>>>> --- /dev/null
> >>>>> +++ b/images/Makefile.spider
> >>>>> @@ -0,0 +1,5 @@
> >>>>> +# SPDX-License-Identifier: GPL-2.0-only
> >>>>> +
> >>>>> +pblb-$(CONFIG_MACH_SPIDER_MK1_EVK) += start_spider_mk1_evk
> >>>>> +FILE_barebox-spider-mk1-evk.img = start_spider_mk1_evk.pblb
> >>>>> +image-$(CONFIG_MACH_SPIDER_MK1_EVK) += barebox-spider-mk1-
> >>>> evk.img
> >>>>> diff --git a/include/mach/spider/lowlevel.h
> >>>> b/include/mach/spider/lowlevel.h new file mode 100644 index
> >>>> 000000000000..6e0ce1c77f7e
> >>>>> --- /dev/null
> >>>>> +++ b/include/mach/spider/lowlevel.h
> >>>>> @@ -0,0 +1,7 @@
> >>>>> +/* SPDX-License-Identifier: GPL-2.0+ */ #ifndef __MACH_SPIDER_H_
> >>>>> +#define __MACH_SPIDER_H_
> >>>>> +
> >>>>> +void spider_lowlevel_init(void);
> >>>>> +
> >>>>> +#endif
> >>>>> --
> >>>>> 2.38.4
> >>>>>
> >>>>>
> >>>>
> >>>> --
> >>>> Pengutronix e.K. | |
> >>>> Steuerwalder Str. 21 | http://www.pengutronix.de/ |
> >>>> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
> >>>> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555
> |
> >>>
> >>
> >> --
> >> Pengutronix e.K. | |
> >> Steuerwalder Str. 21 | http://www.pengutronix.de/ |
> >> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
> >> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
> >
>
> --
> Pengutronix e.K. | |
> Steuerwalder Str. 21 | http://www.pengutronix.de/ |
> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [PATCH v2] Porting barebox to a new SoC
2023-05-31 16:13 ` Lior Weintraub
@ 2023-05-31 17:55 ` Ahmad Fatoum
2023-05-31 17:59 ` Ahmad Fatoum
2023-06-01 8:54 ` Lior Weintraub
0 siblings, 2 replies; 40+ messages in thread
From: Ahmad Fatoum @ 2023-05-31 17:55 UTC (permalink / raw)
To: Lior Weintraub, Ahmad Fatoum, barebox
Hi Lior,
On 31.05.23 18:13, Lior Weintraub wrote:
> Hi Ahmad,
>
> Using end of SRAM as PBL stack is currently not working because we need 40bit address (0xC0_0020_0000).
> This needs a fix to ENTRY_FUNCTION_WITHSTACK macro.
Ah, right. I just sent an (untested) patch. Would be cool if you could
try it out.
> I tried just to change const u32 __stack_top = (stack_top); to const u64 __stack_top = (stack_top); but there were linking errors caused by:
> ASSERT(. - __pbl_board_stack_top <= 8, "Only One PBL per Image allowed")
The easy way would have been using a __attribute__((naked)) function, but
those are only supported for arm32, not arm64. The alternative is thus
writing the entry point in assembly and to make board authors life easier
the linker script ensures that the stack setup entry point is invoked prior
to the board entry.
> Regarding the arm timer:
> Adding the timer entry to DT solved the issue.
>
> Regarding the UART:
> Indeed CONFIG_SERIAL_AMBA_PL011 was set on spider_defconfig (also verified it generated the correct entry on .config).
> I also noticed that if I remove the putc_ll implementation there is no Tx at all from Barebox.
I've led you astray. Indeed:
>>> of_platform_bus_create() - skipping /soc, no compatible prop
points at the issue.
Try adding into /soc
compatible = "simple,bus";
ranges;
dma-ranges;
This matches /soc with the simple bus driver which just instantiates devices for the
contained children. Those in turn should be matched by the drivers.
The ranges stuff just tells that memory and SoC peripherals exist in the same
address space.
When it probes you may need to describe the clock in the DT. Eventually, you will
want to have a clock driver for your hardware (good news: barebox and Linux have
basically the same API, so you only need to write it once). But for now, you can
fake it using fixed-clock in the DT. Take a look at:
snps,dw-apb-uart in arch/riscv/dts/jh7100.dtsi and compare with dts/src/arm/imx28.dtsi
to see how to map that to PL011.
> Could it be a hint?
DEBUG_LL bridges the gap until a driver registers a console that's enabled. If this
never happens, you are left with a non-interactive shell.
Cheers,
Ahmad
>
> Thanks,
> Lior.
>
>> -----Original Message-----
>> From: Ahmad Fatoum <a.fatoum@pengutronix.de>
>> Sent: Wednesday, May 31, 2023 11:40 AM
>> To: Lior Weintraub <liorw@pliops.com>; Ahmad Fatoum <ahmad@a3f.at>;
>> barebox@lists.infradead.org
>> Subject: Re: [PATCH v2] Porting barebox to a new SoC
>>
>> CAUTION: External Sender
>>
>> Hi Lior,
>>
>> On 31.05.23 10:05, Lior Weintraub wrote:
>>> Hi Ahmad,
>>>
>>> Thanks again for your prompt reply and accurate tips!
>>> Took the following changes:
>>> 1. Increasing the DRAM size to 128MB (let barebox start from 0).
>>> 2. Set PBL stack to offset 2MB from DRAM
>>
>> Just use end of SRAM, so you are completely independent of DRAM
>> until you call barebox_arm_entry.
>>
>>> 3. Fix the device tree "memory" entry to have 128MB.
>>
>> (y)
>>
>>> 4. Load barebox-spider-mk1-evk.img to SRAM and run from there.
>>>
>>> Now I can see the following logs:
>>> uncompress.c: memory at 0x00000000, size 0x08000000
>>> uncompress.c: uncompressing barebox binary at 0x000000c0000021c0
>> (size 0x0001e3a4) to 0x07e00000 (uncompressed size: 0x000390d0)
>>> uncompress.c: jumping to uncompressed image at 0x0000000007e00000
>>> start.c: memory at 0x00000000, size 0x08000000
>>> start.c: found DTB in boarddata, copying to 0x07dffcc0
>>> start.c: initializing malloc pool at 0x079ffcc0 (size 0x00400000)
>>> start.c: starting barebox...
>>> initcall-> command_slice_init+0x0/0x3c
>>> initcall-> globalvar_init+0x0/0x80
>>> register_device: global
>>> register_device: nv
>>> initcall-> platform_init+0x0/0x1c
>>> register_device: platform
>>> initcall-> amba_bus_init+0x0/0x1c
>>> register_device: amba
>>> initcall-> spi_bus_init+0x0/0x1c
>>> register_device: spi
>>> initcall-> gpio_desc_alloc+0x0/0x24
>>> initcall-> fs_bus_init+0x0/0x1c
>>> register_device: fs
>>> initcall-> aarch64_init_vectors+0x0/0x50
>>> initcall-> gpio_gate_clock_driver_register+0x0/0x1c
>>> register_driver: gpio-gate-clock
>>> initcall-> of_arm_init+0x0/0x5c
>>> start.c: barebox_arm_boot_dtb: using barebox_boarddata
>>> using boarddata provided DTB
>>> adding DT alias:serial0: stem=serial id=0 node=/soc/serial@d000307000
>>> register_device: machine
>>> of_platform_bus_create() - skipping /chosen, no compatible prop
>>> of_platform_bus_create() - skipping /aliases, no compatible prop
>>> of_platform_bus_create() - skipping /cpus, no compatible prop
>>> of_platform_bus_create() - skipping /memory@0, no compatible prop
>>> of_platform_bus_create() - skipping /soc, no compatible prop
>>> initcall-> register_autoboot_vars+0x0/0x70
>>> initcall-> arm_arch_timer_driver_register+0x0/0x1c
>>> register_driver: arm-architected-timer
>>> initcall-> of_timer_init+0x0/0x20
>>> initcall-> init_fs+0x0/0x3c
>>> initcall-> pl011_driver_register+0x0/0x1c
>>> register_driver: uart-pl011
>>> initcall-> of_stdoutpath_init+0x0/0x28
>>> initcall-> of_probe_memory+0x0/0x60
>>> __request_region ok: 0x00000000:0x07ffffff flags=0x0
>>> initcall-> __bare_init_end+0x0/0x6c
>>> register_device: mem0
>>> initcall-> of_reserved_mem_walk+0x0/0x1ac
>>> initcall-> mem_malloc_resource+0x0/0xa8
>>> __request_region ok: 0x079ffcc0:0x07dffcbf flags=0x200
>>> __request_region ok: 0x07e00000:0x07e2aeff flags=0x200
>>> __request_region ok: 0x07e2af00:0x07e390cf flags=0x200
>>> __request_region ok: 0x07e390d0:0x07e3adaf flags=0x200
>>> initcall-> bootsource_init+0x0/0x40
>>> initcall-> ramfs_init+0x0/0x1c
>>> register_driver: ramfs
>>> initcall-> devfs_init+0x0/0x1c
>>> register_driver: devfs
>>> initcall-> arm_request_stack+0x0/0x398
>>> __request_region ok: 0x07ff0000:0x07ff7fff flags=0x200
>>> initcall-> mount_root+0x0/0x7c
>>> mount: none on / type ramfs, options=
>>> register_device: ramfs0
>>> probe-> ramfs0
>>> mount: none on /dev type devfs, options=
>>> register_device: devfs0
>>> probe-> devfs0
>>> initcall-> binfmt_sh_init+0x0/0x1c
>>> initcall-> binfmt_uimage_init+0x0/0x1c
>>> initcall-> console_common_init+0x0/0x48
>>> initcall-> of_kernel_init+0x0/0x28
>>> initcall-> console_ctrlc_init+0x0/0x30
>>> initcall-> mem_init+0x0/0x90
>>> register_device: mem1
>>> register_driver: mem
>>> probe-> mem0
>>> probe-> mem1
>>> initcall-> of_partition_init+0x0/0x48
>>> initcall-> prng_init+0x0/0x40
>>> initcall-> null_init+0x0/0x40
>>> initcall-> full_init+0x0/0x40
>>> initcall-> zero_init+0x0/0x40
>>> initcall-> spider_board_driver_register+0x0/0x1c
>>> register_driver: board-spider
>>> probe-> machine
>>> initcall-> barebox_memory_areas_init+0x0/0x40
>>> __request_region ok: 0x07dffcc0:0x07dfffce flags=0x200
>>> initcall-> barebox_of_populate+0x0/0x28
>>> initcall-> of_register_memory_fixup+0x0/0x20
>>> initcall-> dummy_csrc_warn+0x0/0x44
>>> WARNING: Warning: Using dummy clocksource
>>
>> Add a arm,armv8-timer node into your SoC device tree.
>> This lets barebox and Linux know that you have the ARM
>> architected timer available. Without that, you'll notice
>> that timeouts are wrong.
>>
>>> initcall-> bootm_init+0x0/0xf4
>>> initcall-> init_command_list+0x0/0x40
>>> register command bootm
>>> register command cat
>>> register command cd
>>> register command clear
>>> register command cp
>>> register command cpuinfo
>>> register command devinfo
>>> register command drvinfo
>>> register command echo
>>> register command exit
>>> register command false
>>> register command help
>>> register command ?
>>> register command ll
>>> register command ls
>>> register command md
>>> register command memcmp
>>> register command memcpy
>>> register command memset
>>> register command mkdir
>>> register command mount
>>> register command mw
>>> register command pwd
>>> register command rm
>>> register command rmdir
>>> register command setenv
>>> register command sh
>>> register command source
>>> register command .
>>> register command test
>>> register command [
>>> register command true
>>> register command :
>>> register command umount
>>> register command version
>>> initcall-> display_meminfo+0x0/0xa8
>>> barebox code: 0x7e00000 -> 0x7e2aeff
>>> bss segment: 0x7e390d0 -> 0x7e3adaf
>>> malloc space: 0x079ffcc0 -> 0x07dffcbf (size 4 MiB)
>>> initcall-> of_register_bootargs_fixup+0x0/0x3c
>>> initcall-> device_probe_deferred+0x0/0x14c
>>> initcall-> of_init_hostname+0x0/0x28
>>> initcall-> aarch64_register_image_handler+0x0/0x2c
>>> initcall-> load_environment+0x0/0x4c
>>> loading defaultenv
>>> environment load /dev/env0: No such file or directory
>>> Maybe you have to create the partition.
>>> initcalls done
>>>
>>> Hit any to stop autoboot: 0
>>> boot: No such file or directory
>>> barebox:/
>>>
>>>
>>> Few questions:
>>> 1. The serial input doesn't work. i.e. I cannot type anything hence cannot
>> interact with barebox terminal.
>>
>> DEBUG_LL only does otuput. For input, you will want to load the driver.
>> Do you have CONFIG_SERIAL_AMBA_PL011 enabled?
>>
>>> Does it require GIC and setting interrupts for it to work?
>>
>> No interrupts needed. barebox runs with interrupts disabled and everything
>> is done cooperatively.
>>
>>> 2. What does "of_platform_bus_create() - skipping" means? Do I need to fix
>> that?
>>
>> That's normal debugging output. Some device tree nodes are busses, which
>> have
>> children. These entries are skipped because they have no compatible. This is
>> expected. I'd suggest you remove your VERBOSED_DEBUG define, so you are
>> not
>> spammed by too much debugging output.
>>
>>> 3. Looks like I am still missing some stuff (rootfs? Environment? Mounting?
>> Partitions?)
>>
>> Take multi_v8_defconfig, open menuconfig and enable your SoC and use that.
>> That will be quicker than enabling everything yourself. If it doesn't work
>> out of the box, try imx_v8_defconfig.
>>
>> Once you get around to upstreaming your SoC, I'd suggest you just add it
>> to multi_v8_defconfig. Not all ARMv8 SoCs are supported there, but those
>> that are make development easier, because we don't need to build as many
>> different configs..
>>
>> Cheers,
>> Ahmad
>>
>>>
>>> Thanks,
>>> Have a great day,
>>> Lior.
>>>
>>>
>>>> -----Original Message-----
>>>> From: Ahmad Fatoum <a.fatoum@pengutronix.de>
>>>> Sent: Wednesday, May 31, 2023 9:11 AM
>>>> To: Lior Weintraub <liorw@pliops.com>; Ahmad Fatoum <ahmad@a3f.at>;
>>>> barebox@lists.infradead.org
>>>> Subject: Re: [PATCH v2] Porting barebox to a new SoC
>>>>
>>>> CAUTION: External Sender
>>>>
>>>> Hi Lior,
>>>>
>>>> On 30.05.23 22:10, Lior Weintraub wrote:
>>>>> Hello Ahmad,
>>>>>
>>>>> Thanks again for your kind support!
>>>>> Your comments helped me progress and the current situation is as
>> follows:
>>>>> Our QEMU Spider machine is running a BL1.elf file using the following
>>>> command:
>>>>> QEMU_AUDIO_DRV=none qemu-system-aarch64 -M spider-soc -smp 1 -
>> m
>>>> 128M -nographic \
>>>>> -device loader,file=BL1.elf -cpu cortex-a53,rvbar=0xC004000000 \
>>>>> -d unimp -semihosting-config enable=on,target=native \
>>>>> -monitor telnet:localhost:1235,server,nowait \
>>>>> -gdb tcp::1236
>>>>>
>>>>> The BL1.elf is our BootROM application that runs from ROM address
>>>> 0xC004000000.
>>>>> Just for debugging purpose we've increased the ROM size so it can include
>>>> the images/barebox-spider-mk1-evk.img (as a const array).
>>>>> BL1 then copy it (using memcpy) to address 0 and jumps there for
>>>> execution.
>>>>
>>>> Sounds ok.
>>>>
>>>>> On the real ASIC this address will be the DRAM and indeed will need to be
>>>> initialized before the copy but here on QEMU it is not required.
>>>>
>>>> I see. You could still have your bootrom move barebox into SRAM and then
>>>>
>>>> barebox_arm_entry(DRAM_ADDR, SZ_128M,
>> __dtb_spider_mk1_evk_start);
>>>>
>>>> To have PBL extract barebox to DRAM. Even if you don't need need DRAM
>>>> setup in QEMU, the flow would be similar to what you will have on actual
>>>> silicon.
>>>>
>>>>> The lowlevel.c of spider-evk was modified to use DRAM_ADDR 0x400000
>>>> (4MB from start) and MY_STACK_TOP was set to 0x8000000 (128M).
>>>>
>>>> That's not needed. While you don't have control where barebox PBL will be
>>>> located
>>>> (depends on BootROM), barebox will extract itself to the end of DRAM
>>>> without
>>>> overwriting itself, so you can just use DRAM_ADDR 0 normally. Eventually,
>>>> stack
>>>> top should go into SRAM, but anywhere that works is ok.
>>>>
>>>>> In addition, I implemented putc_ll (currently hard-coded in
>>>> include/debug_ll.h) and opened log level to VERBOSE_DEBUG (currently
>> just
>>>> hard-coded in printk.h).
>>>>
>>>> There's CONFIG_DEBUG_PBL you can enable to get all these messages by
>>>> default.
>>>>
>>>>> I see the following (which makes sense) logs on QEMU terminal:
>>>>> uncompress.c: memory at 0x00400000, size 0x00200000
>>>>> uncompress.c: uncompressing barebox binary at 0x0000000000002200
>>>> (size 0x0001d3b2) to 0x00400000 (uncompressed size: 0x000373d0)
>>>>
>>>> Why pass only 2M to barebox_arm_entry? While this need not be the
>> whole
>>>> of RAM, this
>>>> initial memory is what barebox will use for itself including its final stack and
>>>> malloc area. barebox will also not place itself into the last 1M AFAIK, so 2M
>>>> may not work ok. You should use the minimum possible RAM here or if you
>>>> can detect
>>>> in PBL how much RAM you have or just the whole RAM bank. I am not sure
>>>> anything lower
>>>> than SZ_4M would work ok. (Note this is DRAM size, not SRAM. barebox
>> PBL
>>>> is fine being
>>>> called from 64K SRAMs, it just needs DRAM to extract to).
>>>>
>>>>> I then connect with aarch64-none-elf-gdb, load the barebox symbols (to
>>>> 0x400000) and check the current execution state (program counter and
>>>> stack).
>>>>> Looks like the code is stuck on function register_autoboot_vars:
>>>>> sp 0x5f7e60 0x5f7e60
>>>>> pc 0x401264 0x401264 <register_autoboot_vars+24>
>>>>>
>>>>> Few observations:
>>>>> 1. The PBL was using stack top located on 0x8000000 (which is
>>>> MY_STACK_TOP). Found it be causing a breakpoint on the PBL.
>>>>> 2. Barebox uses a stack top on 0x600000 which is probably calculated
>> from
>>>> my new DRAM_ADDR and SZ_2M given to the function call:
>>>>> barebox_arm_entry(DRAM_ADDR, SZ_2M,
>> __dtb_spider_mk1_evk_start);
>>>>>
>>>>> This is great! I am starting to find my way.
>>>>
>>>> :) Ye, the ENTRY_FUNCTION_WITHSTACK is only when the BootROM
>> doesn't
>>>> enter
>>>> with a valid stack pointer. It's overwritten as soon as barebox is told
>>>> about the initial memory layout (with barebox_arm_entry).
>>>>
>>>>> When the barebox execution didn't print anything to the terminal I
>>>> remembered that we used a place holder on the dtsi for the uart.
>>>>> So now I changed it to:
>>>>> uart0: serial@d000307000 {
>>>>> compatible = "arm,pl011", "arm,primecell";
>>>>> reg = <0xd0 0x307000 0 0x1000>;
>>>>> }
>>>>> (Our QEMU UART is currently using pl011 device.)
>>>>
>>>> Looks ok. Don't forget to enable the driver (via make menuconfig).
>>>>
>>>>> After some time (trying to debug by enabling MMU but then reverted the
>>>> code back), I got to a point that when I try to run again I am getting an
>>>> exception.
>>>>> I can swear all code changes were reverted back to the point where I saw
>> the
>>>> barebox stuck on register_autoboot_vars but now it just cases an
>> exception.
>>>>> The exception vector code is located on our ROM (part of BL1 code) and
>> the
>>>> logs shows that the link register has the value 0x401218 which suggest the
>>>> following code:
>>>>> 0000000000001200 <load_environment>:
>>>>> 1200: a9be7bfd stp x29, x30, [sp, #-32]!
>>>>> 1204: 910003fd mov x29, sp
>>>>> 1208: a90153f3 stp x19, x20, [sp, #16]
>>>>> 120c: 94000a07 bl 3a28 <default_environment_path_get>
>>>>> 1210: d00000f3 adrp x19, 1f000 <do_cpuinfo+0x1f0>
>>>>> 1214: 912a7273 add x19, x19, #0xa9c
>>>>> 1218: aa0003f4 mov x20, x0
>>>>>
>>>>> Any ideas or suggestions how to proceed with the debugging?
>>>>
>>>> You shouldn't need to touch the MMU code. If your initial memory setup
>>>> is wonky, you may end up overwriting stuff. Try again with bigger memory.
>>>>
>>>>> BTW, to answer your questions:
>>>>> The SRAM of 4MB is the only one we have because we assumed it is only
>> for
>>>> BootROM to load a PBL
>>>>
>>>> Ok. Sometimes there are SRAMs for use with DMA. I asked, because a
>> SRAM
>>>> in the first 4M
>>>> would lend itself nicely as stack, but if there is none, we can adjust
>>>> ENTRY_FUNCTION_WITHSTACK to accept a 64-bit parameter.
>>>>
>>>> Cheers,
>>>> Ahmad
>>>>
>>>>> Thank you very much,
>>>>> Cheers,
>>>>> Lior.
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Ahmad Fatoum <a.fatoum@pengutronix.de>
>>>>>> Sent: Monday, May 29, 2023 10:03 PM
>>>>>> To: Lior Weintraub <liorw@pliops.com>; Ahmad Fatoum
>> <ahmad@a3f.at>;
>>>>>> barebox@lists.infradead.org
>>>>>> Subject: Re: [PATCH v2] Porting barebox to a new SoC
>>>>>>
>>>>>> CAUTION: External Sender
>>>>>>
>>>>>> Hello Lior,
>>>>>>
>>>>>> On 29.05.23 15:34, Lior Weintraub wrote:
>>>>>>> Hi Ahmad,
>>>>>>>
>>>>>>> I have revised the addresses and used DRAM address @ 0 instead:
>>>>>>> #define UARTBASE (0xD000307000)
>>>>>>> #define DRAM_ADDR (0x00000000)
>>>>>>> #define MY_STACK_TOP (0x00000000 + SZ_2M) // Set the stack 2MB
>>>> from
>>>>>> DRAM start
>>>>>>
>>>>>> Is DRAM configured by the time barebox runs? If not, you should keep
>>>> stack
>>>>>> top
>>>>>> in SRAM, until you have setup memory in prebootloader (PBL). Is the 4M
>>>>>> SRAM
>>>>>> the only on-chip SRAM you have?
>>>>>>
>>>>>>> static inline void spider_serial_putc(void *base, int c)
>>>>>>> {
>>>>>>> *((volatile unsigned *)base) = c;
>>>>>>
>>>>>> There's a helper for that: writel(c, base); In barebox, it's equivalent
>>>>>> to the volatile access, but in Linux it involves a write memory barrier.
>>>>>> We try to write code in barebox, so it's easily reusable in Linux (and
>>>>>> the other way round).
>>>>>>
>>>>>>> }
>>>>>>>
>>>>>>> I will try to test it on QEMU using an initial QEMU machine we made for
>>>>>> Spider.
>>>>>>> In this machine we only have 3 memory regions and a PL011 UART:
>>>>>>> spider_soc_memories soc_memories[] = {
>>>>>>> {.name = "SPIDER_GPRAM", .add = 0xC000000000ULL, .size = 4 *
>> MiB},
>>>>>>> {.name = "SPIDER_ROM", .add = 0xC004000000ULL, .size = 128 *
>>>> KiB},
>>>>>>> {.name = "SPIDER_DRAM", .add = 0x0000000000ULL, .size = 1 *
>> GiB},
>>>>>>> };
>>>>>>>
>>>>>>> This special QEMU machine can run our BL1 code from "ROM" address
>>>> (we
>>>>>> set the RVBAR to point there).
>>>>>>> So my idea is to test the barebox image by the following steps:
>>>>>>> 1. Modify the QEMU code to have a "ROM" with the size of 128M.
>>>>>>> 2. Compile our BL1 code to include the barebox.bin as a const array,
>> copy
>>>> it
>>>>>> to "DRAM" @ address 0 and jump there.
>>>>>>
>>>>>> Why not map QEMU -bios option to SRAM? (Or DRAM directly, if it
>> needs
>>>> no
>>>>>> special setup from
>>>>>> barebox side).
>>>>>>
>>>>>>> For this to work I wanted to understand how to call (i.e. what
>> arguments
>>>> to
>>>>>> pass) to barebox.
>>>>>>
>>>>>> barebox doesn't expect any arguments, because most BootROMs don't
>>>> pass
>>>>>> anything useful.
>>>>>> Some pass information about bootsource though, so that's why the
>>>>>> ENTRY_FUNCTION has
>>>>>> r0, r1 and r2 as parameters, but you need not use them.
>>>>>>
>>>>>>> So I checked the barebox.map and found the function "start" on
>> address
>>>> 0.
>>>>>>
>>>>>> You may know that Linux on some platforms comes with a decompressor
>>>> that
>>>>>> is glued to the
>>>>>> front of the kernel image and extracts the compressed kernel image.
>>>> barebox
>>>>>> has the same
>>>>>> concept. The prebootloader is uncompressed and runs (starting from
>>>>>> ENTRY_FUNCTION) and
>>>>>> then does some early setup (e.g. enable clocks, configure PMIC, setup
>>>> DRAM,
>>>>>> load secure
>>>>>> monitor (BL31), ...etc.) and then it decompresses barebox proper into
>>>> DRAM.
>>>>>>
>>>>>> barebox.bin <- barebox proper. You don't usually need that.
>>>>>> barebox.elf <- ELF binary for the above (for gdb)
>>>>>> barebox.map <- map file of the above
>>>>>>
>>>>>> images/barebox-spider-mk1-evk.img <- complete barebox image (PBL +
>>>>>> barebox proper)
>>>>>> images/start_spider_mk1_evk.pbl <- ELF image for the above
>>>>>> images/start_spider_mk1_evk.pbl.map <- map file of the above
>>>>>>
>>>>>> If you want to follow barbeox from the start, begin at
>>>> start_spider_mk1_evk.
>>>>>>
>>>>>>> Then I went to arch/arm/cpu/start.c and realized that the code is
>> compiled
>>>>>> with CONFIG_PBL_IMAGE.
>>>>>>> In that case I assume I need to pass 3 arguments and use this function
>>>>>> prototype:
>>>>>>> void start(unsigned long membase, unsigned long memsize, void
>>>>>> *boarddata);
>>>>>>
>>>>>> barebox prebootloader takes care of this, so you don't need to do
>> anything.
>>>>>>
>>>>>>> Few questions:
>>>>>>> 1. Will that call work:
>>>>>>> typedef void (*barebox_start)(unsigned long , unsigned long , void *);
>>>>>>> #define DRAM_START (0)
>>>>>>> barebox_start p_barebox = (barebox_start)DRAM_START;
>>>>>>> p_barebox(DRAM_START, DRAM_START+SZ_2M, (void
>>>>>> *)(DRAM_START+SZ_4M));
>>>>>>> This assumes that my BL1 code also copied the device tree (barebox-
>> dt-
>>>>>> 2nd.img? start_dt_2nd.pblb? start_spider_mk1_evk.pblb?)
>>>>>>
>>>>>> The device tree is built into the PBL and passed to barebox proper. This
>>>>>> allows us to use the same barebox proper binary and link it with a
>> different
>>>>>> prebootloader for each SoC/board, all in the same build.
>>>>>>
>>>>>> barebox-dt-2nd.img is a special image that looks exactly like a Linux
>> kernel:
>>>>>>
>>>>>> images/barebox-dt-2nd.img: Linux kernel ARM64 boot executable
>> Image,
>>>>>> little-endian, 4K pages
>>>>>>
>>>>>> and can thus be used for booting for easy chainloading from other
>>>>>> bootloaders or for running
>>>>>> with QEMU -kernel. You shouldn't need it right now.
>>>>>>
>>>>>>> 2. Do I want to have my code compiled with CONFIG_PBL_IMAGE?
>>>>>>> If I understand correctly, it means that my code will provide a PBL
>> (a.k.a
>>>>>> BL2) which will set the DRAM and STACK among other things (MMU?).
>>>>>>
>>>>>> The patch I sent already builds a PBL. You will need to fill out
>>>>>> start_spider_mk1_evk
>>>>>> to do all the other early initialization you need. Then you call
>>>>>> barebox_arm_entry
>>>>>> with device tree and memory size and it will take care to do stack setup in
>>>> new
>>>>>> memory region, MMU setup (if enabled) and chainloading barebox
>> proper.
>>>>>>
>>>>>> Note that PBL isn't necessary BL2. You can chainload barebox from within
>>>>>> barebox (i.e.
>>>>>> in EL2 or EL1), which is useful for debugging. You will thus often find PBL
>>>> code
>>>>>> that
>>>>>> does
>>>>>>
>>>>>> if (current_el() == 3) {
>>>>>> /* Do BL2 setup */
>>>>>> chainload();
>>>>>> __builtin_unreachable();
>>>>>> }
>>>>>>
>>>>>> barebox_arm_entry(...)
>>>>>>
>>>>>> See for example arch/arm/boards/innocomm-imx8mm-wb15/lowlevel.c
>>>>>>
>>>>>> to see a real-world example of another Cortex-A53.
>>>>>>
>>>>>>> In that case I assume it is OK.
>>>>>>> 3. If I try to remove it by having CONFIG_PBL_IMAGE=n on
>>>> spider_defconfig
>>>>>> this doesn't do anything
>>>>>>> The build (make spider_defconfig) ignores it and say that " No change
>> to
>>>>>> .config ".
>>>>>>
>>>>>> Another symbol forces it to be enabled. If you are curious, run make
>>>>>> menuconfig
>>>>>> and then search (/) for the symbol and it will list, whether it's enabled
>> and
>>>>>> why:
>>>>>>
>>>>>> Selected by [y]:
>>>>>> - PBL_MULTI_IMAGES [=y] && HAVE_PBL_MULTI_IMAGES [=y]
>>>>>>
>>>>>> I'd suggest you avoid modifying the .config file manually. always use
>>>>>> menuconfig.
>>>>>>
>>>>>>> 4. I also tried to understand how to implement PUTC_LL but not sure I
>>>>>> understand.
>>>>>>> 4.1 When I set "CONFIG_DEBUG_LL=y" on spider_defconfig it is again
>>>> not
>>>>>> written to .config and I get " No change to .config " message.
>>>>>>
>>>>>> You must:
>>>>>>
>>>>>> - select HAS_DEBUG_LL from MACH_SPIDER
>>>>>> - Add your arch to arch/arm/include/asm/debug_ll.h
>>>>>> - Then implement PUTC_LL in e.g. mach/spider/debug_ll.h
>>>>>>
>>>>>>> 4.2 Do I need to have my own debug_ll.h file?
>>>>>>
>>>>>> Yes. See above.
>>>>>>
>>>>>>> 5. When I make changes to spider_defconfig and try to regenerate the
>>>>>> .config and I get " No change to .config " message, does it mean that
>> those
>>>>>> macros are "hidden" symbols like you said about the CONFIG_CPU_V8?
>>>>>>
>>>>>> Yes. Just check menuconfig to see how symbols relate to each other.
>>>>>> This is 1:1 like it's in Linux, so it'll come in handy when you do
>>>>>> the kernel port too ;)
>>>>>>
>>>>>>> Apologize for so many questions :-)
>>>>>>
>>>>>> No problem. Looking forward to your patches ;)
>>>>>>
>>>>>>
>>>>>> Cheers,
>>>>>> Ahmad
>>>>>>
>>>>>>> Cheers,
>>>>>>> Lior.
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Lior Weintraub
>>>>>>> Sent: Sunday, May 28, 2023 11:16 PM
>>>>>>> To: Ahmad Fatoum <ahmad@a3f.at>; barebox@lists.infradead.org
>>>>>>> Subject: RE: [PATCH v2] Porting barebox to a new SoC
>>>>>>>
>>>>>>> Hi Ahmad,
>>>>>>>
>>>>>>> Thank you so much for your kind support!
>>>>>>>
>>>>>>> Indeed we also have a 16GB DRAM that starts from address 0 (though
>>>>>> currently we don't have the controller settings (under development)).
>>>>>>>
>>>>>>> I also wrote the BootROM (BL1) for this SoC (128KB ROM @ address
>>>>>> 0xC004000000).
>>>>>>> I understand now that it would be best for me to develop BL2 that will
>> run
>>>>>> from our SRAM.
>>>>>>>
>>>>>>> As this BL2 code is bare-metal I have no problem or limitations with the
>> 40
>>>>>> bit addresses.
>>>>>>> The BL2 code will initialize the DRAM controller and then copy Barebox
>>>> image
>>>>>> from NOR Flash to address 0 of the DRAM.
>>>>>>> Our NOR Flash is 128MB in size and it is accessed via QSPI controller.
>>>>>>>
>>>>>>> I tried applying your suggested patch but got an error while doing so:
>>>>>>> $git apply 0002-Ahmad.patch
>>>>>>> 0002-Ahmad.patch:115: trailing whitespace.
>>>>>>> .of_compatible = spider_board_of_match, };
>>>>>>> error: corrupt patch at line 117
>>>>>>>
>>>>>>> After some digging I found that my Outlook probably messed with the
>>>> patch
>>>>>> format (even though I am using text only and no HTML format).
>>>>>>> When I went to the web and copied the patch from there (mailing list
>>>>>> archive) it was working well (i.e. no compilation error).
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Lior.
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Ahmad Fatoum <ahmad@a3f.at>
>>>>>>> Sent: Sunday, May 28, 2023 6:38 PM
>>>>>>> To: barebox@lists.infradead.org
>>>>>>> Cc: Lior Weintraub <liorw@pliops.com>
>>>>>>> Subject: [PATCH v2] Porting barebox to a new SoC
>>>>>>>
>>>>>>> CAUTION: External Sender
>>>>>>>
>>>>>>> From: Lior Weintraub <liorw@pliops.com>
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> I tried to follow the porting guide on https://ddec1-0-en-
>>>>>>
>>>>
>> ctp.trendmicro.com:443/wis/clicktime/v1/query?url=https%3a%2f%2fwww.
>>>>>>
>>>>
>> barebox.org%2fdoc%2flatest%2fdevel%2fporting.html%23&umid=60097eda
>>>>>> -f136-45a1-9c8e-
>>>>>> cf6a76e45cf8&auth=860a7ebb9feba264acc79b6e38eb59582349362c-
>>>>>> 480ae23736add41c88ab8d30c090a75517ca7f9e but couldn't follow
>> the
>>>>>> instructions.
>>>>>>> I would like to port barebox to a new SoC (which is not a derivative of
>> any
>>>>>> known SoC).
>>>>>>> It has the following:
>>>>>>> * Single Cortex A53
>>>>>>> * SRAM (4MB) located on address 0xC000000000
>>>>>>>
>>>>>>> The below patch shows my initial test to try and have a starting point.
>>>>>>> I am setting env variables:
>>>>>>> export ARCH=arm64
>>>>>>> export CROSS_COMPILE=/home/pliops/workspace/ARM/arm-gnu-
>>>>>> toolchain/bin/aarch64-none-elf-
>>>>>>>
>>>>>>> Then I build with:
>>>>>>> make spider_defconfig && make
>>>>>>>
>>>>>>> This gives an error:
>>>>>>> aarch64-none-elf-gcc: error: unrecognized argument in option '-
>>>> mabi=apcs-
>>>>>> gnu'
>>>>>>> aarch64-none-elf-gcc: note: valid arguments to '-mabi=' are: ilp32 lp64
>>>>>>> aarch64-none-elf-gcc: error: unrecognized command-line option '-
>> msoft-
>>>>>> float'
>>>>>>> aarch64-none-elf-gcc: error: unrecognized command-line option '-mno-
>>>>>> unaligned-access'
>>>>>>> /home/pliops/workspace/simplest-linux-
>>>>>> demo/barebox/scripts/Makefile.build:140: recipe for target
>>>>>> 'scripts/mod/empty.o' failed
>>>>>>> make[2]: *** [scripts/mod/empty.o] Error 1
>>>>>>>
>>>>>>> Not sure why the compiler flags get -mabi=apcs-gnu when I explicitly set
>>>>>> CONFIG_CPU_V8 and the arch/arm/Makefile has:
>>>>>>> ifeq ($(CONFIG_CPU_V8), y)
>>>>>>> CFLAGS_ABI :=-mabi=lp64
>>>>>>>
>>>>>>> The changes I did:
>>>>>>> >From 848b5f9b18bb1bb96d197cbc1b368ee0a729d581 Mon Sep 17
>>>>>> 00:00:00 2001
>>>>>>> ---
>>>>>>> arch/arm/Kconfig | 13 ++++++++
>>>>>>> arch/arm/Makefile | 1 +
>>>>>>> arch/arm/boards/Makefile | 1 +
>>>>>>> arch/arm/boards/spider-evk/Makefile | 4 +++
>>>>>>> arch/arm/boards/spider-evk/board.c | 26 +++++++++++++++
>>>>>>> arch/arm/boards/spider-evk/lowlevel.c | 30 +++++++++++++++++
>>>>>>> arch/arm/configs/spider_defconfig | 8 +++++
>>>>>>> arch/arm/dts/Makefile | 1 +
>>>>>>> arch/arm/dts/spider-mk1-evk.dts | 10 ++++++
>>>>>>> arch/arm/dts/spider-mk1.dtsi | 46
>> +++++++++++++++++++++++++++
>>>>>>> arch/arm/mach-spider/Kconfig | 16 ++++++++++
>>>>>>> arch/arm/mach-spider/Makefile | 1 +
>>>>>>> arch/arm/mach-spider/lowlevel.c | 14 ++++++++
>>>>>>> images/Makefile | 1 +
>>>>>>> images/Makefile.spider | 5 +++
>>>>>>> include/mach/spider/lowlevel.h | 7 ++++
>>>>>>> 16 files changed, 184 insertions(+)
>>>>>>> create mode 100644 arch/arm/boards/spider-evk/Makefile
>>>>>>> create mode 100644 arch/arm/boards/spider-evk/board.c
>>>>>>> create mode 100644 arch/arm/boards/spider-evk/lowlevel.c
>>>>>>> create mode 100644 arch/arm/configs/spider_defconfig create mode
>>>>>> 100644 arch/arm/dts/spider-mk1-evk.dts create mode 100644
>>>>>> arch/arm/dts/spider-mk1.dtsi create mode 100644 arch/arm/mach-
>>>>>> spider/Kconfig create mode 100644 arch/arm/mach-spider/Makefile
>>>> create
>>>>>> mode 100644 arch/arm/mach-spider/lowlevel.c create mode 100644
>>>>>> images/Makefile.spider create mode 100644
>>>> include/mach/spider/lowlevel.h
>>>>>>>
>>>>>>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index
>>>>>> e76ee0f6dfe1..e5dcf128447e 100644
>>>>>>> --- a/arch/arm/Kconfig
>>>>>>> +++ b/arch/arm/Kconfig
>>>>>>> @@ -255,6 +255,18 @@ config ARCH_ROCKCHIP
>>>>>>> select HAS_DEBUG_LL
>>>>>>> imply GPIO_ROCKCHIP
>>>>>>>
>>>>>>> +config ARCH_SPIDER
>>>>>>> + bool "Pliops Spider based"
>>>>>>> + depends on 64BIT
>>>>>>> + depends on ARCH_MULTIARCH
>>>>>>> + select GPIOLIB
>>>>>>> + select HAVE_PBL_MULTI_IMAGES
>>>>>>> + select COMMON_CLK
>>>>>>> + select CLKDEV_LOOKUP
>>>>>>> + select COMMON_CLK_OF_PROVIDER
>>>>>>> + select OFTREE
>>>>>>> + select OFDEVICE
>>>>>>> +
>>>>>>> config ARCH_STM32MP
>>>>>>> bool "STMicroelectronics STM32MP"
>>>>>>> depends on 32BIT
>>>>>>> @@ -331,6 +343,7 @@ source "arch/arm/mach-omap/Kconfig"
>>>>>>> source "arch/arm/mach-pxa/Kconfig"
>>>>>>> source "arch/arm/mach-rockchip/Kconfig"
>>>>>>> source "arch/arm/mach-socfpga/Kconfig"
>>>>>>> +source "arch/arm/mach-spider/Kconfig"
>>>>>>> source "arch/arm/mach-stm32mp/Kconfig"
>>>>>>> source "arch/arm/mach-versatile/Kconfig"
>>>>>>> source "arch/arm/mach-vexpress/Kconfig"
>>>>>>> diff --git a/arch/arm/Makefile b/arch/arm/Makefile index
>>>>>> 35ebc70f44e2..4c63dfee48f4 100644
>>>>>>> --- a/arch/arm/Makefile
>>>>>>> +++ b/arch/arm/Makefile
>>>>>>> @@ -101,6 +101,7 @@ machine-$(CONFIG_ARCH_MXS) += mxs
>>>>>>> machine-$(CONFIG_ARCH_MVEBU) += mvebu
>>>>>>> machine-$(CONFIG_ARCH_NOMADIK) += nomadik
>>>>>>> machine-$(CONFIG_ARCH_OMAP) += omap
>>>>>>> +machine-$(CONFIG_ARCH_SPIDER) += spider
>>>>>>> machine-$(CONFIG_ARCH_PXA) += pxa
>>>>>>> machine-$(CONFIG_ARCH_ROCKCHIP) += rockchip
>>>>>>> machine-$(CONFIG_ARCH_SAMSUNG) += samsung
>>>>>>> diff --git a/arch/arm/boards/Makefile b/arch/arm/boards/Makefile
>> index
>>>>>> 2877debad535..6fe0a90c81ea 100644
>>>>>>> --- a/arch/arm/boards/Makefile
>>>>>>> +++ b/arch/arm/boards/Makefile
>>>>>>> @@ -135,6 +135,7 @@ obj-
>>>>>> $(CONFIG_MACH_SOCFPGA_TERASIC_DE10_NANO) += terasic-
>> de10-
>>>>>> nano/
>>>>>>> obj-$(CONFIG_MACH_SOCFPGA_TERASIC_SOCKIT) += terasic-
>> sockit/
>>>>>>> obj-$(CONFIG_MACH_SOLIDRUN_CUBOX) += solidrun-cubox/
>>>>>>> obj-$(CONFIG_MACH_SOLIDRUN_MICROSOM) += solidrun-
>>>>>> microsom/
>>>>>>> +obj-$(CONFIG_MACH_SPIDER_MK1_EVK) += spider-evk/
>>>>>>> obj-$(CONFIG_MACH_STM32MP15XX_DKX) += stm32mp15xx-
>>>> dkx/
>>>>>>> obj-$(CONFIG_MACH_STM32MP13XX_DK) += stm32mp13xx-
>> dk/
>>>>>>> obj-$(CONFIG_MACH_LXA_MC1) += lxa-mc1/
>>>>>>> diff --git a/arch/arm/boards/spider-evk/Makefile
>>>>>> b/arch/arm/boards/spider-evk/Makefile
>>>>>>> new file mode 100644
>>>>>>> index 000000000000..da63d2625f7a
>>>>>>> --- /dev/null
>>>>>>> +++ b/arch/arm/boards/spider-evk/Makefile
>>>>>>> @@ -0,0 +1,4 @@
>>>>>>> +# SPDX-License-Identifier: GPL-2.0-only
>>>>>>> +
>>>>>>> +obj-y += board.o
>>>>>>> +lwl-y += lowlevel.o
>>>>>>> diff --git a/arch/arm/boards/spider-evk/board.c
>>>> b/arch/arm/boards/spider-
>>>>>> evk/board.c
>>>>>>> new file mode 100644
>>>>>>> index 000000000000..3920e83b457d
>>>>>>> --- /dev/null
>>>>>>> +++ b/arch/arm/boards/spider-evk/board.c
>>>>>>> @@ -0,0 +1,26 @@
>>>>>>> +#include <bbu.h>
>>>>>>> +#include <boot.h>
>>>>>>> +#include <bootm.h>
>>>>>>> +#include <common.h>
>>>>>>> +#include <deep-probe.h>
>>>>>>> +#include <environment.h>
>>>>>>> +#include <fcntl.h>
>>>>>>> +#include <globalvar.h>
>>>>>>> +
>>>>>>> +static int spider_board_probe(struct device *dev) {
>>>>>>> + /* Do some board-specific setup */
>>>>>>> + return 0;
>>>>>>> +}
>>>>>>> +
>>>>>>> +static const struct of_device_id spider_board_of_match[] = {
>>>>>>> + { .compatible = "pliops,spider-mk1-evk" },
>>>>>>> + { /* sentinel */ },
>>>>>>> +};
>>>>>>> +
>>>>>>> +static struct driver spider_board_driver = {
>>>>>>> + .name = "board-spider",
>>>>>>> + .probe = spider_board_probe,
>>>>>>> + .of_compatible = spider_board_of_match, };
>>>>>>> +device_platform_driver(spider_board_driver);
>>>>>>> diff --git a/arch/arm/boards/spider-evk/lowlevel.c
>>>>>> b/arch/arm/boards/spider-evk/lowlevel.c
>>>>>>> new file mode 100644
>>>>>>> index 000000000000..e36fcde4208e
>>>>>>> --- /dev/null
>>>>>>> +++ b/arch/arm/boards/spider-evk/lowlevel.c
>>>>>>> @@ -0,0 +1,30 @@
>>>>>>> +#include <common.h>
>>>>>>> +#include <asm/barebox-arm.h>
>>>>>>> +#include <mach/spider/lowlevel.h>
>>>>>>> +
>>>>>>> +#define BASE_ADDR (0xD000307000)
>>>>>>> +#define GPRAM_ADDR (0xC000000000)
>>>>>>> +#define MY_STACK_TOP (0xC000000000 + SZ_2M) // Set the stack
>>>> 2MB
>>>>>> from GPRAM start (excatly in the middle)
>>>>>>> +static inline void spider_serial_putc(void *base, int c) {
>>>>>>> +// if (!(readl(base + UCR1) & UCR1_UARTEN))
>>>>>>> +// return;
>>>>>>> +//
>>>>>>> +// while (!(readl(base + USR2) & USR2_TXDC));
>>>>>>> +//
>>>>>>> +// writel(c, base + URTX0);
>>>>>>> +}
>>>>>>> +
>>>>>>> +ENTRY_FUNCTION_WITHSTACK(start_spider_mk1_evk,
>> MY_STACK_TOP,
>>>>>> r0, r1,
>>>>>>> +r2) {
>>>>>>> + extern char __dtb_spider_mk1_evk_start[];
>>>>>>> +
>>>>>>> + spider_lowlevel_init();
>>>>>>> +
>>>>>>> + relocate_to_current_adr();
>>>>>>> + setup_c();
>>>>>>> +
>>>>>>> + pbl_set_putc(spider_serial_putc, (void *)BASE_ADDR);
>>>>>>> +
>>>>>>> + barebox_arm_entry(GPRAM_ADDR, SZ_2M,
>>>>>>> +__dtb_spider_mk1_evk_start); }
>>>>>>> diff --git a/arch/arm/configs/spider_defconfig
>>>>>> b/arch/arm/configs/spider_defconfig
>>>>>>> new file mode 100644
>>>>>>> index 000000000000..c91bb889d97f
>>>>>>> --- /dev/null
>>>>>>> +++ b/arch/arm/configs/spider_defconfig
>>>>>>> @@ -0,0 +1,8 @@
>>>>>>> +CONFIG_ARCH_SPIDER=y
>>>>>>> +CONFIG_MACH_SPIDER_MK1_EVK=y
>>>>>>> +CONFIG_BOARD_ARM_GENERIC_DT=y
>>>>>>> +CONFIG_MALLOC_TLSF=y
>>>>>>> +CONFIG_KALLSYMS=y
>>>>>>> +CONFIG_RELOCATABLE=y
>>>>>>> +CONFIG_CONSOLE_ALLOW_COLOR=y
>>>>>>> +CONFIG_PBL_CONSOLE=y
>>>>>>> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile index
>>>>>> 98f4c4e0194b..94b304d4878f 100644
>>>>>>> --- a/arch/arm/dts/Makefile
>>>>>>> +++ b/arch/arm/dts/Makefile
>>>>>>> @@ -134,6 +134,7 @@ lwl-$(CONFIG_MACH_SOLIDRUN_CUBOX) +=
>>>> dove-
>>>>>> cubox-bb.dtb.o
>>>>>>> lwl-$(CONFIG_MACH_SOLIDRUN_MICROSOM) += imx6dl-
>>>>>> hummingboard.dtb.o imx6q-hummingboard.dtb.o \
>>>>>>> imx6dl-hummingboard2.dtb.o imx6q-
>>>>>> hummingboard2.dtb.o \
>>>>>>> imx6q-h100.dtb.o
>>>>>>> +lwl-$(CONFIG_MACH_SPIDER_MK1_EVK) += spider-mk1-evk.dtb.o
>>>>>>> lwl-$(CONFIG_MACH_SKOV_IMX6) += imx6s-skov-imx6.dtb.o imx6dl-
>>>> skov-
>>>>>> imx6.dtb.o imx6q-skov-imx6.dtb.o
>>>>>>> lwl-$(CONFIG_MACH_SKOV_ARM9CPU) += at91-skov-arm9cpu.dtb.o
>>>>>>> lwl-$(CONFIG_MACH_SEEED_ODYSSEY) += stm32mp157c-
>> odyssey.dtb.o
>>>>>> diff --git a/arch/arm/dts/spider-mk1-evk.dts b/arch/arm/dts/spider-
>> mk1-
>>>>>> evk.dts new file mode 100644 index 000000000000..b8081cb85bf8
>>>>>>> --- /dev/null
>>>>>>> +++ b/arch/arm/dts/spider-mk1-evk.dts
>>>>>>> @@ -0,0 +1,10 @@
>>>>>>> +// SPDX-License-Identifier: GPL-2.0 OR X11
>>>>>>> +
>>>>>>> +/dts-v1/;
>>>>>>> +
>>>>>>> +#include "spider-mk1.dtsi"
>>>>>>> +
>>>>>>> +/ {
>>>>>>> + model = "Pliops Spider MK-I EVK";
>>>>>>> + compatible = "pliops,spider-mk1-evk"; };
>>>>>>> diff --git a/arch/arm/dts/spider-mk1.dtsi b/arch/arm/dts/spider-
>> mk1.dtsi
>>>>>> new file mode 100644 index 000000000000..d4613848169d
>>>>>>> --- /dev/null
>>>>>>> +++ b/arch/arm/dts/spider-mk1.dtsi
>>>>>>> @@ -0,0 +1,46 @@
>>>>>>> +// SPDX-License-Identifier: GPL-2.0 OR X11
>>>>>>> +
>>>>>>> +/ {
>>>>>>> + #address-cells = <2>;
>>>>>>> + #size-cells = <2>;
>>>>>>> +
>>>>>>> + chosen {
>>>>>>> + stdout-path = &uart0;
>>>>>>> + };
>>>>>>> +
>>>>>>> + aliases {
>>>>>>> + serial0 = &uart0;
>>>>>>> + };
>>>>>>> +
>>>>>>> + cpus {
>>>>>>> + #address-cells = <1>;
>>>>>>> + #size-cells = <0>;
>>>>>>> +
>>>>>>> + cpu0: cpu@0 {
>>>>>>> + device_type = "cpu";
>>>>>>> + compatible = "arm,cortex-a53";
>>>>>>> + reg = <0x0>;
>>>>>>> + };
>>>>>>> + };
>>>>>>> +
>>>>>>> + memory@1000000 {
>>>>>>> + reg = <0x0 0x1000000 0x0 0x400000>; /* 128M */
>>>>>>> + device_type = "memory";
>>>>>>> + };
>>>>>>> +
>>>>>>> + soc {
>>>>>>> + #address-cells = <2>;
>>>>>>> + #size-cells = <2>;
>>>>>>> + ranges;
>>>>>>> +
>>>>>>> + sram@c000000000 {
>>>>>>> + compatible = "mmio-sram";
>>>>>>> + reg = <0xc0 0x0 0x0 0x400000>;
>>>>>>> + };
>>>>>>> +
>>>>>>> + uart0: serial@d000307000 {
>>>>>>> + compatible = "pliops,spider-uart";
>>>>>>> + reg = <0xd0 0x307000 0 0x1000>;
>>>>>>> + };
>>>>>>> + };
>>>>>>> +};
>>>>>>> diff --git a/arch/arm/mach-spider/Kconfig b/arch/arm/mach-
>>>> spider/Kconfig
>>>>>> new file mode 100644 index 000000000000..6d2f888a5fd8
>>>>>>> --- /dev/null
>>>>>>> +++ b/arch/arm/mach-spider/Kconfig
>>>>>>> @@ -0,0 +1,16 @@
>>>>>>> +# SPDX-License-Identifier: GPL-2.0-only
>>>>>>> +
>>>>>>> +if ARCH_SPIDER
>>>>>>> +
>>>>>>> +config ARCH_SPIDER_MK1
>>>>>>> + bool
>>>>>>> + select CPU_V8
>>>>>>> + help
>>>>>>> + The first Cortex-A53-based SoC of the spider family.
>>>>>>> + This symbol is invisble and select by boards
>>>>>>> +
>>>>>>> +config MACH_SPIDER_MK1_EVK
>>>>>>> + bool "Pliops Spider Reference Design Board"
>>>>>>> + select ARCH_SPIDER_MK1
>>>>>>> +
>>>>>>> +endif
>>>>>>> diff --git a/arch/arm/mach-spider/Makefile b/arch/arm/mach-
>>>>>> spider/Makefile new file mode 100644 index
>>>> 000000000000..b08c4a93ca27
>>>>>>> --- /dev/null
>>>>>>> +++ b/arch/arm/mach-spider/Makefile
>>>>>>> @@ -0,0 +1 @@
>>>>>>> +lwl-y += lowlevel.o
>>>>>>> diff --git a/arch/arm/mach-spider/lowlevel.c b/arch/arm/mach-
>>>>>> spider/lowlevel.c new file mode 100644 index
>>>>>> 000000000000..5d62ef0f39e5
>>>>>>> --- /dev/null
>>>>>>> +++ b/arch/arm/mach-spider/lowlevel.c
>>>>>>> @@ -0,0 +1,14 @@
>>>>>>> +// SPDX-License-Identifier: GPL-2.0+
>>>>>>> +
>>>>>>> +#include <linux/types.h>
>>>>>>> +#include <mach/spider/lowlevel.h>
>>>>>>> +#include <asm/barebox-arm-head.h>
>>>>>>> +
>>>>>>> +void spider_lowlevel_init(void)
>>>>>>> +{
>>>>>>> + arm_cpu_lowlevel_init();
>>>>>>> + /*
>>>>>>> + * not yet relocated, only do writel/readl for stuff that's
>>>>>>> + * critical to run early. No global variables allowed.
>>>>>>> + */
>>>>>>> +}
>>>>>>> diff --git a/images/Makefile b/images/Makefile index
>>>>>> c93f9e268978..97521e713228 100644
>>>>>>> --- a/images/Makefile
>>>>>>> +++ b/images/Makefile
>>>>>>> @@ -150,6 +150,7 @@ include $(srctree)/images/Makefile.mxs
>> include
>>>>>> $(srctree)/images/Makefile.omap3 include
>>>>>> $(srctree)/images/Makefile.rockchip
>>>>>>> include $(srctree)/images/Makefile.socfpga
>>>>>>> +include $(srctree)/images/Makefile.spider
>>>>>>> include $(srctree)/images/Makefile.stm32mp
>>>>>>> include $(srctree)/images/Makefile.tegra include
>>>>>> $(srctree)/images/Makefile.versatile
>>>>>>> diff --git a/images/Makefile.spider b/images/Makefile.spider new file
>>>> mode
>>>>>> 100644 index 000000000000..c32f2762df04
>>>>>>> --- /dev/null
>>>>>>> +++ b/images/Makefile.spider
>>>>>>> @@ -0,0 +1,5 @@
>>>>>>> +# SPDX-License-Identifier: GPL-2.0-only
>>>>>>> +
>>>>>>> +pblb-$(CONFIG_MACH_SPIDER_MK1_EVK) += start_spider_mk1_evk
>>>>>>> +FILE_barebox-spider-mk1-evk.img = start_spider_mk1_evk.pblb
>>>>>>> +image-$(CONFIG_MACH_SPIDER_MK1_EVK) += barebox-spider-mk1-
>>>>>> evk.img
>>>>>>> diff --git a/include/mach/spider/lowlevel.h
>>>>>> b/include/mach/spider/lowlevel.h new file mode 100644 index
>>>>>> 000000000000..6e0ce1c77f7e
>>>>>>> --- /dev/null
>>>>>>> +++ b/include/mach/spider/lowlevel.h
>>>>>>> @@ -0,0 +1,7 @@
>>>>>>> +/* SPDX-License-Identifier: GPL-2.0+ */ #ifndef __MACH_SPIDER_H_
>>>>>>> +#define __MACH_SPIDER_H_
>>>>>>> +
>>>>>>> +void spider_lowlevel_init(void);
>>>>>>> +
>>>>>>> +#endif
>>>>>>> --
>>>>>>> 2.38.4
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Pengutronix e.K. | |
>>>>>> Steuerwalder Str. 21 | http://www.pengutronix.de/ |
>>>>>> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
>>>>>> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555
>> |
>>>>>
>>>>
>>>> --
>>>> Pengutronix e.K. | |
>>>> Steuerwalder Str. 21 | http://www.pengutronix.de/ |
>>>> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
>>>> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
>>>
>>
>> --
>> Pengutronix e.K. | |
>> Steuerwalder Str. 21 | http://www.pengutronix.de/ |
>> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
>> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
>
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [PATCH v2] Porting barebox to a new SoC
2023-05-31 17:55 ` Ahmad Fatoum
@ 2023-05-31 17:59 ` Ahmad Fatoum
2023-06-01 8:54 ` Lior Weintraub
1 sibling, 0 replies; 40+ messages in thread
From: Ahmad Fatoum @ 2023-05-31 17:59 UTC (permalink / raw)
To: Lior Weintraub, Ahmad Fatoum, barebox
On 31.05.23 19:55, Ahmad Fatoum wrote:
> Hi Lior,
>
> On 31.05.23 18:13, Lior Weintraub wrote:
>> Hi Ahmad,
>>
>> Using end of SRAM as PBL stack is currently not working because we need 40bit address (0xC0_0020_0000).
>> This needs a fix to ENTRY_FUNCTION_WITHSTACK macro.
>
> Ah, right. I just sent an (untested) patch. Would be cool if you could
> try it out.
>
>> I tried just to change const u32 __stack_top = (stack_top); to const u64 __stack_top = (stack_top); but there were linking errors caused by:
>> ASSERT(. - __pbl_board_stack_top <= 8, "Only One PBL per Image allowed")
>
> The easy way would have been using a __attribute__((naked)) function, but
> those are only supported for arm32, not arm64. The alternative is thus
> writing the entry point in assembly and to make board authors life easier
> the linker script ensures that the stack setup entry point is invoked prior
> to the board entry.
>
>> Regarding the arm timer:
>> Adding the timer entry to DT solved the issue.
>>
>> Regarding the UART:
>> Indeed CONFIG_SERIAL_AMBA_PL011 was set on spider_defconfig (also verified it generated the correct entry on .config).
>> I also noticed that if I remove the putc_ll implementation there is no Tx at all from Barebox.
>
> I've led you astray. Indeed:
>
>>>> of_platform_bus_create() - skipping /soc, no compatible prop
>
> points at the issue.
>
> Try adding into /soc
>
> compatible = "simple,bus";
"simple-bus". If you need an example, check out aforementioned jh7100.dtsi
> ranges;
> dma-ranges;
>
> This matches /soc with the simple bus driver which just instantiates devices for the
> contained children. Those in turn should be matched by the drivers.
>
> The ranges stuff just tells that memory and SoC peripherals exist in the same
> address space.
>
> When it probes you may need to describe the clock in the DT. Eventually, you will
> want to have a clock driver for your hardware (good news: barebox and Linux have
> basically the same API, so you only need to write it once). But for now, you can
> fake it using fixed-clock in the DT. Take a look at:
>
> snps,dw-apb-uart in arch/riscv/dts/jh7100.dtsi and compare with dts/src/arm/imx28.dtsi
> to see how to map that to PL011.
>
>> Could it be a hint?
>
> DEBUG_LL bridges the gap until a driver registers a console that's enabled. If this
> never happens, you are left with a non-interactive shell.
>
> Cheers,
> Ahmad
>
>>
>> Thanks,
>> Lior.
>>
>>> -----Original Message-----
>>> From: Ahmad Fatoum <a.fatoum@pengutronix.de>
>>> Sent: Wednesday, May 31, 2023 11:40 AM
>>> To: Lior Weintraub <liorw@pliops.com>; Ahmad Fatoum <ahmad@a3f.at>;
>>> barebox@lists.infradead.org
>>> Subject: Re: [PATCH v2] Porting barebox to a new SoC
>>>
>>> CAUTION: External Sender
>>>
>>> Hi Lior,
>>>
>>> On 31.05.23 10:05, Lior Weintraub wrote:
>>>> Hi Ahmad,
>>>>
>>>> Thanks again for your prompt reply and accurate tips!
>>>> Took the following changes:
>>>> 1. Increasing the DRAM size to 128MB (let barebox start from 0).
>>>> 2. Set PBL stack to offset 2MB from DRAM
>>>
>>> Just use end of SRAM, so you are completely independent of DRAM
>>> until you call barebox_arm_entry.
>>>
>>>> 3. Fix the device tree "memory" entry to have 128MB.
>>>
>>> (y)
>>>
>>>> 4. Load barebox-spider-mk1-evk.img to SRAM and run from there.
>>>>
>>>> Now I can see the following logs:
>>>> uncompress.c: memory at 0x00000000, size 0x08000000
>>>> uncompress.c: uncompressing barebox binary at 0x000000c0000021c0
>>> (size 0x0001e3a4) to 0x07e00000 (uncompressed size: 0x000390d0)
>>>> uncompress.c: jumping to uncompressed image at 0x0000000007e00000
>>>> start.c: memory at 0x00000000, size 0x08000000
>>>> start.c: found DTB in boarddata, copying to 0x07dffcc0
>>>> start.c: initializing malloc pool at 0x079ffcc0 (size 0x00400000)
>>>> start.c: starting barebox...
>>>> initcall-> command_slice_init+0x0/0x3c
>>>> initcall-> globalvar_init+0x0/0x80
>>>> register_device: global
>>>> register_device: nv
>>>> initcall-> platform_init+0x0/0x1c
>>>> register_device: platform
>>>> initcall-> amba_bus_init+0x0/0x1c
>>>> register_device: amba
>>>> initcall-> spi_bus_init+0x0/0x1c
>>>> register_device: spi
>>>> initcall-> gpio_desc_alloc+0x0/0x24
>>>> initcall-> fs_bus_init+0x0/0x1c
>>>> register_device: fs
>>>> initcall-> aarch64_init_vectors+0x0/0x50
>>>> initcall-> gpio_gate_clock_driver_register+0x0/0x1c
>>>> register_driver: gpio-gate-clock
>>>> initcall-> of_arm_init+0x0/0x5c
>>>> start.c: barebox_arm_boot_dtb: using barebox_boarddata
>>>> using boarddata provided DTB
>>>> adding DT alias:serial0: stem=serial id=0 node=/soc/serial@d000307000
>>>> register_device: machine
>>>> of_platform_bus_create() - skipping /chosen, no compatible prop
>>>> of_platform_bus_create() - skipping /aliases, no compatible prop
>>>> of_platform_bus_create() - skipping /cpus, no compatible prop
>>>> of_platform_bus_create() - skipping /memory@0, no compatible prop
>>>> of_platform_bus_create() - skipping /soc, no compatible prop
>>>> initcall-> register_autoboot_vars+0x0/0x70
>>>> initcall-> arm_arch_timer_driver_register+0x0/0x1c
>>>> register_driver: arm-architected-timer
>>>> initcall-> of_timer_init+0x0/0x20
>>>> initcall-> init_fs+0x0/0x3c
>>>> initcall-> pl011_driver_register+0x0/0x1c
>>>> register_driver: uart-pl011
>>>> initcall-> of_stdoutpath_init+0x0/0x28
>>>> initcall-> of_probe_memory+0x0/0x60
>>>> __request_region ok: 0x00000000:0x07ffffff flags=0x0
>>>> initcall-> __bare_init_end+0x0/0x6c
>>>> register_device: mem0
>>>> initcall-> of_reserved_mem_walk+0x0/0x1ac
>>>> initcall-> mem_malloc_resource+0x0/0xa8
>>>> __request_region ok: 0x079ffcc0:0x07dffcbf flags=0x200
>>>> __request_region ok: 0x07e00000:0x07e2aeff flags=0x200
>>>> __request_region ok: 0x07e2af00:0x07e390cf flags=0x200
>>>> __request_region ok: 0x07e390d0:0x07e3adaf flags=0x200
>>>> initcall-> bootsource_init+0x0/0x40
>>>> initcall-> ramfs_init+0x0/0x1c
>>>> register_driver: ramfs
>>>> initcall-> devfs_init+0x0/0x1c
>>>> register_driver: devfs
>>>> initcall-> arm_request_stack+0x0/0x398
>>>> __request_region ok: 0x07ff0000:0x07ff7fff flags=0x200
>>>> initcall-> mount_root+0x0/0x7c
>>>> mount: none on / type ramfs, options=
>>>> register_device: ramfs0
>>>> probe-> ramfs0
>>>> mount: none on /dev type devfs, options=
>>>> register_device: devfs0
>>>> probe-> devfs0
>>>> initcall-> binfmt_sh_init+0x0/0x1c
>>>> initcall-> binfmt_uimage_init+0x0/0x1c
>>>> initcall-> console_common_init+0x0/0x48
>>>> initcall-> of_kernel_init+0x0/0x28
>>>> initcall-> console_ctrlc_init+0x0/0x30
>>>> initcall-> mem_init+0x0/0x90
>>>> register_device: mem1
>>>> register_driver: mem
>>>> probe-> mem0
>>>> probe-> mem1
>>>> initcall-> of_partition_init+0x0/0x48
>>>> initcall-> prng_init+0x0/0x40
>>>> initcall-> null_init+0x0/0x40
>>>> initcall-> full_init+0x0/0x40
>>>> initcall-> zero_init+0x0/0x40
>>>> initcall-> spider_board_driver_register+0x0/0x1c
>>>> register_driver: board-spider
>>>> probe-> machine
>>>> initcall-> barebox_memory_areas_init+0x0/0x40
>>>> __request_region ok: 0x07dffcc0:0x07dfffce flags=0x200
>>>> initcall-> barebox_of_populate+0x0/0x28
>>>> initcall-> of_register_memory_fixup+0x0/0x20
>>>> initcall-> dummy_csrc_warn+0x0/0x44
>>>> WARNING: Warning: Using dummy clocksource
>>>
>>> Add a arm,armv8-timer node into your SoC device tree.
>>> This lets barebox and Linux know that you have the ARM
>>> architected timer available. Without that, you'll notice
>>> that timeouts are wrong.
>>>
>>>> initcall-> bootm_init+0x0/0xf4
>>>> initcall-> init_command_list+0x0/0x40
>>>> register command bootm
>>>> register command cat
>>>> register command cd
>>>> register command clear
>>>> register command cp
>>>> register command cpuinfo
>>>> register command devinfo
>>>> register command drvinfo
>>>> register command echo
>>>> register command exit
>>>> register command false
>>>> register command help
>>>> register command ?
>>>> register command ll
>>>> register command ls
>>>> register command md
>>>> register command memcmp
>>>> register command memcpy
>>>> register command memset
>>>> register command mkdir
>>>> register command mount
>>>> register command mw
>>>> register command pwd
>>>> register command rm
>>>> register command rmdir
>>>> register command setenv
>>>> register command sh
>>>> register command source
>>>> register command .
>>>> register command test
>>>> register command [
>>>> register command true
>>>> register command :
>>>> register command umount
>>>> register command version
>>>> initcall-> display_meminfo+0x0/0xa8
>>>> barebox code: 0x7e00000 -> 0x7e2aeff
>>>> bss segment: 0x7e390d0 -> 0x7e3adaf
>>>> malloc space: 0x079ffcc0 -> 0x07dffcbf (size 4 MiB)
>>>> initcall-> of_register_bootargs_fixup+0x0/0x3c
>>>> initcall-> device_probe_deferred+0x0/0x14c
>>>> initcall-> of_init_hostname+0x0/0x28
>>>> initcall-> aarch64_register_image_handler+0x0/0x2c
>>>> initcall-> load_environment+0x0/0x4c
>>>> loading defaultenv
>>>> environment load /dev/env0: No such file or directory
>>>> Maybe you have to create the partition.
>>>> initcalls done
>>>>
>>>> Hit any to stop autoboot: 0
>>>> boot: No such file or directory
>>>> barebox:/
>>>>
>>>>
>>>> Few questions:
>>>> 1. The serial input doesn't work. i.e. I cannot type anything hence cannot
>>> interact with barebox terminal.
>>>
>>> DEBUG_LL only does otuput. For input, you will want to load the driver.
>>> Do you have CONFIG_SERIAL_AMBA_PL011 enabled?
>>>
>>>> Does it require GIC and setting interrupts for it to work?
>>>
>>> No interrupts needed. barebox runs with interrupts disabled and everything
>>> is done cooperatively.
>>>
>>>> 2. What does "of_platform_bus_create() - skipping" means? Do I need to fix
>>> that?
>>>
>>> That's normal debugging output. Some device tree nodes are busses, which
>>> have
>>> children. These entries are skipped because they have no compatible. This is
>>> expected. I'd suggest you remove your VERBOSED_DEBUG define, so you are
>>> not
>>> spammed by too much debugging output.
>>>
>>>> 3. Looks like I am still missing some stuff (rootfs? Environment? Mounting?
>>> Partitions?)
>>>
>>> Take multi_v8_defconfig, open menuconfig and enable your SoC and use that.
>>> That will be quicker than enabling everything yourself. If it doesn't work
>>> out of the box, try imx_v8_defconfig.
>>>
>>> Once you get around to upstreaming your SoC, I'd suggest you just add it
>>> to multi_v8_defconfig. Not all ARMv8 SoCs are supported there, but those
>>> that are make development easier, because we don't need to build as many
>>> different configs..
>>>
>>> Cheers,
>>> Ahmad
>>>
>>>>
>>>> Thanks,
>>>> Have a great day,
>>>> Lior.
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: Ahmad Fatoum <a.fatoum@pengutronix.de>
>>>>> Sent: Wednesday, May 31, 2023 9:11 AM
>>>>> To: Lior Weintraub <liorw@pliops.com>; Ahmad Fatoum <ahmad@a3f.at>;
>>>>> barebox@lists.infradead.org
>>>>> Subject: Re: [PATCH v2] Porting barebox to a new SoC
>>>>>
>>>>> CAUTION: External Sender
>>>>>
>>>>> Hi Lior,
>>>>>
>>>>> On 30.05.23 22:10, Lior Weintraub wrote:
>>>>>> Hello Ahmad,
>>>>>>
>>>>>> Thanks again for your kind support!
>>>>>> Your comments helped me progress and the current situation is as
>>> follows:
>>>>>> Our QEMU Spider machine is running a BL1.elf file using the following
>>>>> command:
>>>>>> QEMU_AUDIO_DRV=none qemu-system-aarch64 -M spider-soc -smp 1 -
>>> m
>>>>> 128M -nographic \
>>>>>> -device loader,file=BL1.elf -cpu cortex-a53,rvbar=0xC004000000 \
>>>>>> -d unimp -semihosting-config enable=on,target=native \
>>>>>> -monitor telnet:localhost:1235,server,nowait \
>>>>>> -gdb tcp::1236
>>>>>>
>>>>>> The BL1.elf is our BootROM application that runs from ROM address
>>>>> 0xC004000000.
>>>>>> Just for debugging purpose we've increased the ROM size so it can include
>>>>> the images/barebox-spider-mk1-evk.img (as a const array).
>>>>>> BL1 then copy it (using memcpy) to address 0 and jumps there for
>>>>> execution.
>>>>>
>>>>> Sounds ok.
>>>>>
>>>>>> On the real ASIC this address will be the DRAM and indeed will need to be
>>>>> initialized before the copy but here on QEMU it is not required.
>>>>>
>>>>> I see. You could still have your bootrom move barebox into SRAM and then
>>>>>
>>>>> barebox_arm_entry(DRAM_ADDR, SZ_128M,
>>> __dtb_spider_mk1_evk_start);
>>>>>
>>>>> To have PBL extract barebox to DRAM. Even if you don't need need DRAM
>>>>> setup in QEMU, the flow would be similar to what you will have on actual
>>>>> silicon.
>>>>>
>>>>>> The lowlevel.c of spider-evk was modified to use DRAM_ADDR 0x400000
>>>>> (4MB from start) and MY_STACK_TOP was set to 0x8000000 (128M).
>>>>>
>>>>> That's not needed. While you don't have control where barebox PBL will be
>>>>> located
>>>>> (depends on BootROM), barebox will extract itself to the end of DRAM
>>>>> without
>>>>> overwriting itself, so you can just use DRAM_ADDR 0 normally. Eventually,
>>>>> stack
>>>>> top should go into SRAM, but anywhere that works is ok.
>>>>>
>>>>>> In addition, I implemented putc_ll (currently hard-coded in
>>>>> include/debug_ll.h) and opened log level to VERBOSE_DEBUG (currently
>>> just
>>>>> hard-coded in printk.h).
>>>>>
>>>>> There's CONFIG_DEBUG_PBL you can enable to get all these messages by
>>>>> default.
>>>>>
>>>>>> I see the following (which makes sense) logs on QEMU terminal:
>>>>>> uncompress.c: memory at 0x00400000, size 0x00200000
>>>>>> uncompress.c: uncompressing barebox binary at 0x0000000000002200
>>>>> (size 0x0001d3b2) to 0x00400000 (uncompressed size: 0x000373d0)
>>>>>
>>>>> Why pass only 2M to barebox_arm_entry? While this need not be the
>>> whole
>>>>> of RAM, this
>>>>> initial memory is what barebox will use for itself including its final stack and
>>>>> malloc area. barebox will also not place itself into the last 1M AFAIK, so 2M
>>>>> may not work ok. You should use the minimum possible RAM here or if you
>>>>> can detect
>>>>> in PBL how much RAM you have or just the whole RAM bank. I am not sure
>>>>> anything lower
>>>>> than SZ_4M would work ok. (Note this is DRAM size, not SRAM. barebox
>>> PBL
>>>>> is fine being
>>>>> called from 64K SRAMs, it just needs DRAM to extract to).
>>>>>
>>>>>> I then connect with aarch64-none-elf-gdb, load the barebox symbols (to
>>>>> 0x400000) and check the current execution state (program counter and
>>>>> stack).
>>>>>> Looks like the code is stuck on function register_autoboot_vars:
>>>>>> sp 0x5f7e60 0x5f7e60
>>>>>> pc 0x401264 0x401264 <register_autoboot_vars+24>
>>>>>>
>>>>>> Few observations:
>>>>>> 1. The PBL was using stack top located on 0x8000000 (which is
>>>>> MY_STACK_TOP). Found it be causing a breakpoint on the PBL.
>>>>>> 2. Barebox uses a stack top on 0x600000 which is probably calculated
>>> from
>>>>> my new DRAM_ADDR and SZ_2M given to the function call:
>>>>>> barebox_arm_entry(DRAM_ADDR, SZ_2M,
>>> __dtb_spider_mk1_evk_start);
>>>>>>
>>>>>> This is great! I am starting to find my way.
>>>>>
>>>>> :) Ye, the ENTRY_FUNCTION_WITHSTACK is only when the BootROM
>>> doesn't
>>>>> enter
>>>>> with a valid stack pointer. It's overwritten as soon as barebox is told
>>>>> about the initial memory layout (with barebox_arm_entry).
>>>>>
>>>>>> When the barebox execution didn't print anything to the terminal I
>>>>> remembered that we used a place holder on the dtsi for the uart.
>>>>>> So now I changed it to:
>>>>>> uart0: serial@d000307000 {
>>>>>> compatible = "arm,pl011", "arm,primecell";
>>>>>> reg = <0xd0 0x307000 0 0x1000>;
>>>>>> }
>>>>>> (Our QEMU UART is currently using pl011 device.)
>>>>>
>>>>> Looks ok. Don't forget to enable the driver (via make menuconfig).
>>>>>
>>>>>> After some time (trying to debug by enabling MMU but then reverted the
>>>>> code back), I got to a point that when I try to run again I am getting an
>>>>> exception.
>>>>>> I can swear all code changes were reverted back to the point where I saw
>>> the
>>>>> barebox stuck on register_autoboot_vars but now it just cases an
>>> exception.
>>>>>> The exception vector code is located on our ROM (part of BL1 code) and
>>> the
>>>>> logs shows that the link register has the value 0x401218 which suggest the
>>>>> following code:
>>>>>> 0000000000001200 <load_environment>:
>>>>>> 1200: a9be7bfd stp x29, x30, [sp, #-32]!
>>>>>> 1204: 910003fd mov x29, sp
>>>>>> 1208: a90153f3 stp x19, x20, [sp, #16]
>>>>>> 120c: 94000a07 bl 3a28 <default_environment_path_get>
>>>>>> 1210: d00000f3 adrp x19, 1f000 <do_cpuinfo+0x1f0>
>>>>>> 1214: 912a7273 add x19, x19, #0xa9c
>>>>>> 1218: aa0003f4 mov x20, x0
>>>>>>
>>>>>> Any ideas or suggestions how to proceed with the debugging?
>>>>>
>>>>> You shouldn't need to touch the MMU code. If your initial memory setup
>>>>> is wonky, you may end up overwriting stuff. Try again with bigger memory.
>>>>>
>>>>>> BTW, to answer your questions:
>>>>>> The SRAM of 4MB is the only one we have because we assumed it is only
>>> for
>>>>> BootROM to load a PBL
>>>>>
>>>>> Ok. Sometimes there are SRAMs for use with DMA. I asked, because a
>>> SRAM
>>>>> in the first 4M
>>>>> would lend itself nicely as stack, but if there is none, we can adjust
>>>>> ENTRY_FUNCTION_WITHSTACK to accept a 64-bit parameter.
>>>>>
>>>>> Cheers,
>>>>> Ahmad
>>>>>
>>>>>> Thank you very much,
>>>>>> Cheers,
>>>>>> Lior.
>>>>>>
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Ahmad Fatoum <a.fatoum@pengutronix.de>
>>>>>>> Sent: Monday, May 29, 2023 10:03 PM
>>>>>>> To: Lior Weintraub <liorw@pliops.com>; Ahmad Fatoum
>>> <ahmad@a3f.at>;
>>>>>>> barebox@lists.infradead.org
>>>>>>> Subject: Re: [PATCH v2] Porting barebox to a new SoC
>>>>>>>
>>>>>>> CAUTION: External Sender
>>>>>>>
>>>>>>> Hello Lior,
>>>>>>>
>>>>>>> On 29.05.23 15:34, Lior Weintraub wrote:
>>>>>>>> Hi Ahmad,
>>>>>>>>
>>>>>>>> I have revised the addresses and used DRAM address @ 0 instead:
>>>>>>>> #define UARTBASE (0xD000307000)
>>>>>>>> #define DRAM_ADDR (0x00000000)
>>>>>>>> #define MY_STACK_TOP (0x00000000 + SZ_2M) // Set the stack 2MB
>>>>> from
>>>>>>> DRAM start
>>>>>>>
>>>>>>> Is DRAM configured by the time barebox runs? If not, you should keep
>>>>> stack
>>>>>>> top
>>>>>>> in SRAM, until you have setup memory in prebootloader (PBL). Is the 4M
>>>>>>> SRAM
>>>>>>> the only on-chip SRAM you have?
>>>>>>>
>>>>>>>> static inline void spider_serial_putc(void *base, int c)
>>>>>>>> {
>>>>>>>> *((volatile unsigned *)base) = c;
>>>>>>>
>>>>>>> There's a helper for that: writel(c, base); In barebox, it's equivalent
>>>>>>> to the volatile access, but in Linux it involves a write memory barrier.
>>>>>>> We try to write code in barebox, so it's easily reusable in Linux (and
>>>>>>> the other way round).
>>>>>>>
>>>>>>>> }
>>>>>>>>
>>>>>>>> I will try to test it on QEMU using an initial QEMU machine we made for
>>>>>>> Spider.
>>>>>>>> In this machine we only have 3 memory regions and a PL011 UART:
>>>>>>>> spider_soc_memories soc_memories[] = {
>>>>>>>> {.name = "SPIDER_GPRAM", .add = 0xC000000000ULL, .size = 4 *
>>> MiB},
>>>>>>>> {.name = "SPIDER_ROM", .add = 0xC004000000ULL, .size = 128 *
>>>>> KiB},
>>>>>>>> {.name = "SPIDER_DRAM", .add = 0x0000000000ULL, .size = 1 *
>>> GiB},
>>>>>>>> };
>>>>>>>>
>>>>>>>> This special QEMU machine can run our BL1 code from "ROM" address
>>>>> (we
>>>>>>> set the RVBAR to point there).
>>>>>>>> So my idea is to test the barebox image by the following steps:
>>>>>>>> 1. Modify the QEMU code to have a "ROM" with the size of 128M.
>>>>>>>> 2. Compile our BL1 code to include the barebox.bin as a const array,
>>> copy
>>>>> it
>>>>>>> to "DRAM" @ address 0 and jump there.
>>>>>>>
>>>>>>> Why not map QEMU -bios option to SRAM? (Or DRAM directly, if it
>>> needs
>>>>> no
>>>>>>> special setup from
>>>>>>> barebox side).
>>>>>>>
>>>>>>>> For this to work I wanted to understand how to call (i.e. what
>>> arguments
>>>>> to
>>>>>>> pass) to barebox.
>>>>>>>
>>>>>>> barebox doesn't expect any arguments, because most BootROMs don't
>>>>> pass
>>>>>>> anything useful.
>>>>>>> Some pass information about bootsource though, so that's why the
>>>>>>> ENTRY_FUNCTION has
>>>>>>> r0, r1 and r2 as parameters, but you need not use them.
>>>>>>>
>>>>>>>> So I checked the barebox.map and found the function "start" on
>>> address
>>>>> 0.
>>>>>>>
>>>>>>> You may know that Linux on some platforms comes with a decompressor
>>>>> that
>>>>>>> is glued to the
>>>>>>> front of the kernel image and extracts the compressed kernel image.
>>>>> barebox
>>>>>>> has the same
>>>>>>> concept. The prebootloader is uncompressed and runs (starting from
>>>>>>> ENTRY_FUNCTION) and
>>>>>>> then does some early setup (e.g. enable clocks, configure PMIC, setup
>>>>> DRAM,
>>>>>>> load secure
>>>>>>> monitor (BL31), ...etc.) and then it decompresses barebox proper into
>>>>> DRAM.
>>>>>>>
>>>>>>> barebox.bin <- barebox proper. You don't usually need that.
>>>>>>> barebox.elf <- ELF binary for the above (for gdb)
>>>>>>> barebox.map <- map file of the above
>>>>>>>
>>>>>>> images/barebox-spider-mk1-evk.img <- complete barebox image (PBL +
>>>>>>> barebox proper)
>>>>>>> images/start_spider_mk1_evk.pbl <- ELF image for the above
>>>>>>> images/start_spider_mk1_evk.pbl.map <- map file of the above
>>>>>>>
>>>>>>> If you want to follow barbeox from the start, begin at
>>>>> start_spider_mk1_evk.
>>>>>>>
>>>>>>>> Then I went to arch/arm/cpu/start.c and realized that the code is
>>> compiled
>>>>>>> with CONFIG_PBL_IMAGE.
>>>>>>>> In that case I assume I need to pass 3 arguments and use this function
>>>>>>> prototype:
>>>>>>>> void start(unsigned long membase, unsigned long memsize, void
>>>>>>> *boarddata);
>>>>>>>
>>>>>>> barebox prebootloader takes care of this, so you don't need to do
>>> anything.
>>>>>>>
>>>>>>>> Few questions:
>>>>>>>> 1. Will that call work:
>>>>>>>> typedef void (*barebox_start)(unsigned long , unsigned long , void *);
>>>>>>>> #define DRAM_START (0)
>>>>>>>> barebox_start p_barebox = (barebox_start)DRAM_START;
>>>>>>>> p_barebox(DRAM_START, DRAM_START+SZ_2M, (void
>>>>>>> *)(DRAM_START+SZ_4M));
>>>>>>>> This assumes that my BL1 code also copied the device tree (barebox-
>>> dt-
>>>>>>> 2nd.img? start_dt_2nd.pblb? start_spider_mk1_evk.pblb?)
>>>>>>>
>>>>>>> The device tree is built into the PBL and passed to barebox proper. This
>>>>>>> allows us to use the same barebox proper binary and link it with a
>>> different
>>>>>>> prebootloader for each SoC/board, all in the same build.
>>>>>>>
>>>>>>> barebox-dt-2nd.img is a special image that looks exactly like a Linux
>>> kernel:
>>>>>>>
>>>>>>> images/barebox-dt-2nd.img: Linux kernel ARM64 boot executable
>>> Image,
>>>>>>> little-endian, 4K pages
>>>>>>>
>>>>>>> and can thus be used for booting for easy chainloading from other
>>>>>>> bootloaders or for running
>>>>>>> with QEMU -kernel. You shouldn't need it right now.
>>>>>>>
>>>>>>>> 2. Do I want to have my code compiled with CONFIG_PBL_IMAGE?
>>>>>>>> If I understand correctly, it means that my code will provide a PBL
>>> (a.k.a
>>>>>>> BL2) which will set the DRAM and STACK among other things (MMU?).
>>>>>>>
>>>>>>> The patch I sent already builds a PBL. You will need to fill out
>>>>>>> start_spider_mk1_evk
>>>>>>> to do all the other early initialization you need. Then you call
>>>>>>> barebox_arm_entry
>>>>>>> with device tree and memory size and it will take care to do stack setup in
>>>>> new
>>>>>>> memory region, MMU setup (if enabled) and chainloading barebox
>>> proper.
>>>>>>>
>>>>>>> Note that PBL isn't necessary BL2. You can chainload barebox from within
>>>>>>> barebox (i.e.
>>>>>>> in EL2 or EL1), which is useful for debugging. You will thus often find PBL
>>>>> code
>>>>>>> that
>>>>>>> does
>>>>>>>
>>>>>>> if (current_el() == 3) {
>>>>>>> /* Do BL2 setup */
>>>>>>> chainload();
>>>>>>> __builtin_unreachable();
>>>>>>> }
>>>>>>>
>>>>>>> barebox_arm_entry(...)
>>>>>>>
>>>>>>> See for example arch/arm/boards/innocomm-imx8mm-wb15/lowlevel.c
>>>>>>>
>>>>>>> to see a real-world example of another Cortex-A53.
>>>>>>>
>>>>>>>> In that case I assume it is OK.
>>>>>>>> 3. If I try to remove it by having CONFIG_PBL_IMAGE=n on
>>>>> spider_defconfig
>>>>>>> this doesn't do anything
>>>>>>>> The build (make spider_defconfig) ignores it and say that " No change
>>> to
>>>>>>> .config ".
>>>>>>>
>>>>>>> Another symbol forces it to be enabled. If you are curious, run make
>>>>>>> menuconfig
>>>>>>> and then search (/) for the symbol and it will list, whether it's enabled
>>> and
>>>>>>> why:
>>>>>>>
>>>>>>> Selected by [y]:
>>>>>>> - PBL_MULTI_IMAGES [=y] && HAVE_PBL_MULTI_IMAGES [=y]
>>>>>>>
>>>>>>> I'd suggest you avoid modifying the .config file manually. always use
>>>>>>> menuconfig.
>>>>>>>
>>>>>>>> 4. I also tried to understand how to implement PUTC_LL but not sure I
>>>>>>> understand.
>>>>>>>> 4.1 When I set "CONFIG_DEBUG_LL=y" on spider_defconfig it is again
>>>>> not
>>>>>>> written to .config and I get " No change to .config " message.
>>>>>>>
>>>>>>> You must:
>>>>>>>
>>>>>>> - select HAS_DEBUG_LL from MACH_SPIDER
>>>>>>> - Add your arch to arch/arm/include/asm/debug_ll.h
>>>>>>> - Then implement PUTC_LL in e.g. mach/spider/debug_ll.h
>>>>>>>
>>>>>>>> 4.2 Do I need to have my own debug_ll.h file?
>>>>>>>
>>>>>>> Yes. See above.
>>>>>>>
>>>>>>>> 5. When I make changes to spider_defconfig and try to regenerate the
>>>>>>> .config and I get " No change to .config " message, does it mean that
>>> those
>>>>>>> macros are "hidden" symbols like you said about the CONFIG_CPU_V8?
>>>>>>>
>>>>>>> Yes. Just check menuconfig to see how symbols relate to each other.
>>>>>>> This is 1:1 like it's in Linux, so it'll come in handy when you do
>>>>>>> the kernel port too ;)
>>>>>>>
>>>>>>>> Apologize for so many questions :-)
>>>>>>>
>>>>>>> No problem. Looking forward to your patches ;)
>>>>>>>
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Ahmad
>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Lior.
>>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Lior Weintraub
>>>>>>>> Sent: Sunday, May 28, 2023 11:16 PM
>>>>>>>> To: Ahmad Fatoum <ahmad@a3f.at>; barebox@lists.infradead.org
>>>>>>>> Subject: RE: [PATCH v2] Porting barebox to a new SoC
>>>>>>>>
>>>>>>>> Hi Ahmad,
>>>>>>>>
>>>>>>>> Thank you so much for your kind support!
>>>>>>>>
>>>>>>>> Indeed we also have a 16GB DRAM that starts from address 0 (though
>>>>>>> currently we don't have the controller settings (under development)).
>>>>>>>>
>>>>>>>> I also wrote the BootROM (BL1) for this SoC (128KB ROM @ address
>>>>>>> 0xC004000000).
>>>>>>>> I understand now that it would be best for me to develop BL2 that will
>>> run
>>>>>>> from our SRAM.
>>>>>>>>
>>>>>>>> As this BL2 code is bare-metal I have no problem or limitations with the
>>> 40
>>>>>>> bit addresses.
>>>>>>>> The BL2 code will initialize the DRAM controller and then copy Barebox
>>>>> image
>>>>>>> from NOR Flash to address 0 of the DRAM.
>>>>>>>> Our NOR Flash is 128MB in size and it is accessed via QSPI controller.
>>>>>>>>
>>>>>>>> I tried applying your suggested patch but got an error while doing so:
>>>>>>>> $git apply 0002-Ahmad.patch
>>>>>>>> 0002-Ahmad.patch:115: trailing whitespace.
>>>>>>>> .of_compatible = spider_board_of_match, };
>>>>>>>> error: corrupt patch at line 117
>>>>>>>>
>>>>>>>> After some digging I found that my Outlook probably messed with the
>>>>> patch
>>>>>>> format (even though I am using text only and no HTML format).
>>>>>>>> When I went to the web and copied the patch from there (mailing list
>>>>>>> archive) it was working well (i.e. no compilation error).
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Lior.
>>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Ahmad Fatoum <ahmad@a3f.at>
>>>>>>>> Sent: Sunday, May 28, 2023 6:38 PM
>>>>>>>> To: barebox@lists.infradead.org
>>>>>>>> Cc: Lior Weintraub <liorw@pliops.com>
>>>>>>>> Subject: [PATCH v2] Porting barebox to a new SoC
>>>>>>>>
>>>>>>>> CAUTION: External Sender
>>>>>>>>
>>>>>>>> From: Lior Weintraub <liorw@pliops.com>
>>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I tried to follow the porting guide on https://ddec1-0-en-
>>>>>>>
>>>>>
>>> ctp.trendmicro.com:443/wis/clicktime/v1/query?url=https%3a%2f%2fwww.
>>>>>>>
>>>>>
>>> barebox.org%2fdoc%2flatest%2fdevel%2fporting.html%23&umid=60097eda
>>>>>>> -f136-45a1-9c8e-
>>>>>>> cf6a76e45cf8&auth=860a7ebb9feba264acc79b6e38eb59582349362c-
>>>>>>> 480ae23736add41c88ab8d30c090a75517ca7f9e but couldn't follow
>>> the
>>>>>>> instructions.
>>>>>>>> I would like to port barebox to a new SoC (which is not a derivative of
>>> any
>>>>>>> known SoC).
>>>>>>>> It has the following:
>>>>>>>> * Single Cortex A53
>>>>>>>> * SRAM (4MB) located on address 0xC000000000
>>>>>>>>
>>>>>>>> The below patch shows my initial test to try and have a starting point.
>>>>>>>> I am setting env variables:
>>>>>>>> export ARCH=arm64
>>>>>>>> export CROSS_COMPILE=/home/pliops/workspace/ARM/arm-gnu-
>>>>>>> toolchain/bin/aarch64-none-elf-
>>>>>>>>
>>>>>>>> Then I build with:
>>>>>>>> make spider_defconfig && make
>>>>>>>>
>>>>>>>> This gives an error:
>>>>>>>> aarch64-none-elf-gcc: error: unrecognized argument in option '-
>>>>> mabi=apcs-
>>>>>>> gnu'
>>>>>>>> aarch64-none-elf-gcc: note: valid arguments to '-mabi=' are: ilp32 lp64
>>>>>>>> aarch64-none-elf-gcc: error: unrecognized command-line option '-
>>> msoft-
>>>>>>> float'
>>>>>>>> aarch64-none-elf-gcc: error: unrecognized command-line option '-mno-
>>>>>>> unaligned-access'
>>>>>>>> /home/pliops/workspace/simplest-linux-
>>>>>>> demo/barebox/scripts/Makefile.build:140: recipe for target
>>>>>>> 'scripts/mod/empty.o' failed
>>>>>>>> make[2]: *** [scripts/mod/empty.o] Error 1
>>>>>>>>
>>>>>>>> Not sure why the compiler flags get -mabi=apcs-gnu when I explicitly set
>>>>>>> CONFIG_CPU_V8 and the arch/arm/Makefile has:
>>>>>>>> ifeq ($(CONFIG_CPU_V8), y)
>>>>>>>> CFLAGS_ABI :=-mabi=lp64
>>>>>>>>
>>>>>>>> The changes I did:
>>>>>>>> >From 848b5f9b18bb1bb96d197cbc1b368ee0a729d581 Mon Sep 17
>>>>>>> 00:00:00 2001
>>>>>>>> ---
>>>>>>>> arch/arm/Kconfig | 13 ++++++++
>>>>>>>> arch/arm/Makefile | 1 +
>>>>>>>> arch/arm/boards/Makefile | 1 +
>>>>>>>> arch/arm/boards/spider-evk/Makefile | 4 +++
>>>>>>>> arch/arm/boards/spider-evk/board.c | 26 +++++++++++++++
>>>>>>>> arch/arm/boards/spider-evk/lowlevel.c | 30 +++++++++++++++++
>>>>>>>> arch/arm/configs/spider_defconfig | 8 +++++
>>>>>>>> arch/arm/dts/Makefile | 1 +
>>>>>>>> arch/arm/dts/spider-mk1-evk.dts | 10 ++++++
>>>>>>>> arch/arm/dts/spider-mk1.dtsi | 46
>>> +++++++++++++++++++++++++++
>>>>>>>> arch/arm/mach-spider/Kconfig | 16 ++++++++++
>>>>>>>> arch/arm/mach-spider/Makefile | 1 +
>>>>>>>> arch/arm/mach-spider/lowlevel.c | 14 ++++++++
>>>>>>>> images/Makefile | 1 +
>>>>>>>> images/Makefile.spider | 5 +++
>>>>>>>> include/mach/spider/lowlevel.h | 7 ++++
>>>>>>>> 16 files changed, 184 insertions(+)
>>>>>>>> create mode 100644 arch/arm/boards/spider-evk/Makefile
>>>>>>>> create mode 100644 arch/arm/boards/spider-evk/board.c
>>>>>>>> create mode 100644 arch/arm/boards/spider-evk/lowlevel.c
>>>>>>>> create mode 100644 arch/arm/configs/spider_defconfig create mode
>>>>>>> 100644 arch/arm/dts/spider-mk1-evk.dts create mode 100644
>>>>>>> arch/arm/dts/spider-mk1.dtsi create mode 100644 arch/arm/mach-
>>>>>>> spider/Kconfig create mode 100644 arch/arm/mach-spider/Makefile
>>>>> create
>>>>>>> mode 100644 arch/arm/mach-spider/lowlevel.c create mode 100644
>>>>>>> images/Makefile.spider create mode 100644
>>>>> include/mach/spider/lowlevel.h
>>>>>>>>
>>>>>>>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index
>>>>>>> e76ee0f6dfe1..e5dcf128447e 100644
>>>>>>>> --- a/arch/arm/Kconfig
>>>>>>>> +++ b/arch/arm/Kconfig
>>>>>>>> @@ -255,6 +255,18 @@ config ARCH_ROCKCHIP
>>>>>>>> select HAS_DEBUG_LL
>>>>>>>> imply GPIO_ROCKCHIP
>>>>>>>>
>>>>>>>> +config ARCH_SPIDER
>>>>>>>> + bool "Pliops Spider based"
>>>>>>>> + depends on 64BIT
>>>>>>>> + depends on ARCH_MULTIARCH
>>>>>>>> + select GPIOLIB
>>>>>>>> + select HAVE_PBL_MULTI_IMAGES
>>>>>>>> + select COMMON_CLK
>>>>>>>> + select CLKDEV_LOOKUP
>>>>>>>> + select COMMON_CLK_OF_PROVIDER
>>>>>>>> + select OFTREE
>>>>>>>> + select OFDEVICE
>>>>>>>> +
>>>>>>>> config ARCH_STM32MP
>>>>>>>> bool "STMicroelectronics STM32MP"
>>>>>>>> depends on 32BIT
>>>>>>>> @@ -331,6 +343,7 @@ source "arch/arm/mach-omap/Kconfig"
>>>>>>>> source "arch/arm/mach-pxa/Kconfig"
>>>>>>>> source "arch/arm/mach-rockchip/Kconfig"
>>>>>>>> source "arch/arm/mach-socfpga/Kconfig"
>>>>>>>> +source "arch/arm/mach-spider/Kconfig"
>>>>>>>> source "arch/arm/mach-stm32mp/Kconfig"
>>>>>>>> source "arch/arm/mach-versatile/Kconfig"
>>>>>>>> source "arch/arm/mach-vexpress/Kconfig"
>>>>>>>> diff --git a/arch/arm/Makefile b/arch/arm/Makefile index
>>>>>>> 35ebc70f44e2..4c63dfee48f4 100644
>>>>>>>> --- a/arch/arm/Makefile
>>>>>>>> +++ b/arch/arm/Makefile
>>>>>>>> @@ -101,6 +101,7 @@ machine-$(CONFIG_ARCH_MXS) += mxs
>>>>>>>> machine-$(CONFIG_ARCH_MVEBU) += mvebu
>>>>>>>> machine-$(CONFIG_ARCH_NOMADIK) += nomadik
>>>>>>>> machine-$(CONFIG_ARCH_OMAP) += omap
>>>>>>>> +machine-$(CONFIG_ARCH_SPIDER) += spider
>>>>>>>> machine-$(CONFIG_ARCH_PXA) += pxa
>>>>>>>> machine-$(CONFIG_ARCH_ROCKCHIP) += rockchip
>>>>>>>> machine-$(CONFIG_ARCH_SAMSUNG) += samsung
>>>>>>>> diff --git a/arch/arm/boards/Makefile b/arch/arm/boards/Makefile
>>> index
>>>>>>> 2877debad535..6fe0a90c81ea 100644
>>>>>>>> --- a/arch/arm/boards/Makefile
>>>>>>>> +++ b/arch/arm/boards/Makefile
>>>>>>>> @@ -135,6 +135,7 @@ obj-
>>>>>>> $(CONFIG_MACH_SOCFPGA_TERASIC_DE10_NANO) += terasic-
>>> de10-
>>>>>>> nano/
>>>>>>>> obj-$(CONFIG_MACH_SOCFPGA_TERASIC_SOCKIT) += terasic-
>>> sockit/
>>>>>>>> obj-$(CONFIG_MACH_SOLIDRUN_CUBOX) += solidrun-cubox/
>>>>>>>> obj-$(CONFIG_MACH_SOLIDRUN_MICROSOM) += solidrun-
>>>>>>> microsom/
>>>>>>>> +obj-$(CONFIG_MACH_SPIDER_MK1_EVK) += spider-evk/
>>>>>>>> obj-$(CONFIG_MACH_STM32MP15XX_DKX) += stm32mp15xx-
>>>>> dkx/
>>>>>>>> obj-$(CONFIG_MACH_STM32MP13XX_DK) += stm32mp13xx-
>>> dk/
>>>>>>>> obj-$(CONFIG_MACH_LXA_MC1) += lxa-mc1/
>>>>>>>> diff --git a/arch/arm/boards/spider-evk/Makefile
>>>>>>> b/arch/arm/boards/spider-evk/Makefile
>>>>>>>> new file mode 100644
>>>>>>>> index 000000000000..da63d2625f7a
>>>>>>>> --- /dev/null
>>>>>>>> +++ b/arch/arm/boards/spider-evk/Makefile
>>>>>>>> @@ -0,0 +1,4 @@
>>>>>>>> +# SPDX-License-Identifier: GPL-2.0-only
>>>>>>>> +
>>>>>>>> +obj-y += board.o
>>>>>>>> +lwl-y += lowlevel.o
>>>>>>>> diff --git a/arch/arm/boards/spider-evk/board.c
>>>>> b/arch/arm/boards/spider-
>>>>>>> evk/board.c
>>>>>>>> new file mode 100644
>>>>>>>> index 000000000000..3920e83b457d
>>>>>>>> --- /dev/null
>>>>>>>> +++ b/arch/arm/boards/spider-evk/board.c
>>>>>>>> @@ -0,0 +1,26 @@
>>>>>>>> +#include <bbu.h>
>>>>>>>> +#include <boot.h>
>>>>>>>> +#include <bootm.h>
>>>>>>>> +#include <common.h>
>>>>>>>> +#include <deep-probe.h>
>>>>>>>> +#include <environment.h>
>>>>>>>> +#include <fcntl.h>
>>>>>>>> +#include <globalvar.h>
>>>>>>>> +
>>>>>>>> +static int spider_board_probe(struct device *dev) {
>>>>>>>> + /* Do some board-specific setup */
>>>>>>>> + return 0;
>>>>>>>> +}
>>>>>>>> +
>>>>>>>> +static const struct of_device_id spider_board_of_match[] = {
>>>>>>>> + { .compatible = "pliops,spider-mk1-evk" },
>>>>>>>> + { /* sentinel */ },
>>>>>>>> +};
>>>>>>>> +
>>>>>>>> +static struct driver spider_board_driver = {
>>>>>>>> + .name = "board-spider",
>>>>>>>> + .probe = spider_board_probe,
>>>>>>>> + .of_compatible = spider_board_of_match, };
>>>>>>>> +device_platform_driver(spider_board_driver);
>>>>>>>> diff --git a/arch/arm/boards/spider-evk/lowlevel.c
>>>>>>> b/arch/arm/boards/spider-evk/lowlevel.c
>>>>>>>> new file mode 100644
>>>>>>>> index 000000000000..e36fcde4208e
>>>>>>>> --- /dev/null
>>>>>>>> +++ b/arch/arm/boards/spider-evk/lowlevel.c
>>>>>>>> @@ -0,0 +1,30 @@
>>>>>>>> +#include <common.h>
>>>>>>>> +#include <asm/barebox-arm.h>
>>>>>>>> +#include <mach/spider/lowlevel.h>
>>>>>>>> +
>>>>>>>> +#define BASE_ADDR (0xD000307000)
>>>>>>>> +#define GPRAM_ADDR (0xC000000000)
>>>>>>>> +#define MY_STACK_TOP (0xC000000000 + SZ_2M) // Set the stack
>>>>> 2MB
>>>>>>> from GPRAM start (excatly in the middle)
>>>>>>>> +static inline void spider_serial_putc(void *base, int c) {
>>>>>>>> +// if (!(readl(base + UCR1) & UCR1_UARTEN))
>>>>>>>> +// return;
>>>>>>>> +//
>>>>>>>> +// while (!(readl(base + USR2) & USR2_TXDC));
>>>>>>>> +//
>>>>>>>> +// writel(c, base + URTX0);
>>>>>>>> +}
>>>>>>>> +
>>>>>>>> +ENTRY_FUNCTION_WITHSTACK(start_spider_mk1_evk,
>>> MY_STACK_TOP,
>>>>>>> r0, r1,
>>>>>>>> +r2) {
>>>>>>>> + extern char __dtb_spider_mk1_evk_start[];
>>>>>>>> +
>>>>>>>> + spider_lowlevel_init();
>>>>>>>> +
>>>>>>>> + relocate_to_current_adr();
>>>>>>>> + setup_c();
>>>>>>>> +
>>>>>>>> + pbl_set_putc(spider_serial_putc, (void *)BASE_ADDR);
>>>>>>>> +
>>>>>>>> + barebox_arm_entry(GPRAM_ADDR, SZ_2M,
>>>>>>>> +__dtb_spider_mk1_evk_start); }
>>>>>>>> diff --git a/arch/arm/configs/spider_defconfig
>>>>>>> b/arch/arm/configs/spider_defconfig
>>>>>>>> new file mode 100644
>>>>>>>> index 000000000000..c91bb889d97f
>>>>>>>> --- /dev/null
>>>>>>>> +++ b/arch/arm/configs/spider_defconfig
>>>>>>>> @@ -0,0 +1,8 @@
>>>>>>>> +CONFIG_ARCH_SPIDER=y
>>>>>>>> +CONFIG_MACH_SPIDER_MK1_EVK=y
>>>>>>>> +CONFIG_BOARD_ARM_GENERIC_DT=y
>>>>>>>> +CONFIG_MALLOC_TLSF=y
>>>>>>>> +CONFIG_KALLSYMS=y
>>>>>>>> +CONFIG_RELOCATABLE=y
>>>>>>>> +CONFIG_CONSOLE_ALLOW_COLOR=y
>>>>>>>> +CONFIG_PBL_CONSOLE=y
>>>>>>>> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile index
>>>>>>> 98f4c4e0194b..94b304d4878f 100644
>>>>>>>> --- a/arch/arm/dts/Makefile
>>>>>>>> +++ b/arch/arm/dts/Makefile
>>>>>>>> @@ -134,6 +134,7 @@ lwl-$(CONFIG_MACH_SOLIDRUN_CUBOX) +=
>>>>> dove-
>>>>>>> cubox-bb.dtb.o
>>>>>>>> lwl-$(CONFIG_MACH_SOLIDRUN_MICROSOM) += imx6dl-
>>>>>>> hummingboard.dtb.o imx6q-hummingboard.dtb.o \
>>>>>>>> imx6dl-hummingboard2.dtb.o imx6q-
>>>>>>> hummingboard2.dtb.o \
>>>>>>>> imx6q-h100.dtb.o
>>>>>>>> +lwl-$(CONFIG_MACH_SPIDER_MK1_EVK) += spider-mk1-evk.dtb.o
>>>>>>>> lwl-$(CONFIG_MACH_SKOV_IMX6) += imx6s-skov-imx6.dtb.o imx6dl-
>>>>> skov-
>>>>>>> imx6.dtb.o imx6q-skov-imx6.dtb.o
>>>>>>>> lwl-$(CONFIG_MACH_SKOV_ARM9CPU) += at91-skov-arm9cpu.dtb.o
>>>>>>>> lwl-$(CONFIG_MACH_SEEED_ODYSSEY) += stm32mp157c-
>>> odyssey.dtb.o
>>>>>>> diff --git a/arch/arm/dts/spider-mk1-evk.dts b/arch/arm/dts/spider-
>>> mk1-
>>>>>>> evk.dts new file mode 100644 index 000000000000..b8081cb85bf8
>>>>>>>> --- /dev/null
>>>>>>>> +++ b/arch/arm/dts/spider-mk1-evk.dts
>>>>>>>> @@ -0,0 +1,10 @@
>>>>>>>> +// SPDX-License-Identifier: GPL-2.0 OR X11
>>>>>>>> +
>>>>>>>> +/dts-v1/;
>>>>>>>> +
>>>>>>>> +#include "spider-mk1.dtsi"
>>>>>>>> +
>>>>>>>> +/ {
>>>>>>>> + model = "Pliops Spider MK-I EVK";
>>>>>>>> + compatible = "pliops,spider-mk1-evk"; };
>>>>>>>> diff --git a/arch/arm/dts/spider-mk1.dtsi b/arch/arm/dts/spider-
>>> mk1.dtsi
>>>>>>> new file mode 100644 index 000000000000..d4613848169d
>>>>>>>> --- /dev/null
>>>>>>>> +++ b/arch/arm/dts/spider-mk1.dtsi
>>>>>>>> @@ -0,0 +1,46 @@
>>>>>>>> +// SPDX-License-Identifier: GPL-2.0 OR X11
>>>>>>>> +
>>>>>>>> +/ {
>>>>>>>> + #address-cells = <2>;
>>>>>>>> + #size-cells = <2>;
>>>>>>>> +
>>>>>>>> + chosen {
>>>>>>>> + stdout-path = &uart0;
>>>>>>>> + };
>>>>>>>> +
>>>>>>>> + aliases {
>>>>>>>> + serial0 = &uart0;
>>>>>>>> + };
>>>>>>>> +
>>>>>>>> + cpus {
>>>>>>>> + #address-cells = <1>;
>>>>>>>> + #size-cells = <0>;
>>>>>>>> +
>>>>>>>> + cpu0: cpu@0 {
>>>>>>>> + device_type = "cpu";
>>>>>>>> + compatible = "arm,cortex-a53";
>>>>>>>> + reg = <0x0>;
>>>>>>>> + };
>>>>>>>> + };
>>>>>>>> +
>>>>>>>> + memory@1000000 {
>>>>>>>> + reg = <0x0 0x1000000 0x0 0x400000>; /* 128M */
>>>>>>>> + device_type = "memory";
>>>>>>>> + };
>>>>>>>> +
>>>>>>>> + soc {
>>>>>>>> + #address-cells = <2>;
>>>>>>>> + #size-cells = <2>;
>>>>>>>> + ranges;
>>>>>>>> +
>>>>>>>> + sram@c000000000 {
>>>>>>>> + compatible = "mmio-sram";
>>>>>>>> + reg = <0xc0 0x0 0x0 0x400000>;
>>>>>>>> + };
>>>>>>>> +
>>>>>>>> + uart0: serial@d000307000 {
>>>>>>>> + compatible = "pliops,spider-uart";
>>>>>>>> + reg = <0xd0 0x307000 0 0x1000>;
>>>>>>>> + };
>>>>>>>> + };
>>>>>>>> +};
>>>>>>>> diff --git a/arch/arm/mach-spider/Kconfig b/arch/arm/mach-
>>>>> spider/Kconfig
>>>>>>> new file mode 100644 index 000000000000..6d2f888a5fd8
>>>>>>>> --- /dev/null
>>>>>>>> +++ b/arch/arm/mach-spider/Kconfig
>>>>>>>> @@ -0,0 +1,16 @@
>>>>>>>> +# SPDX-License-Identifier: GPL-2.0-only
>>>>>>>> +
>>>>>>>> +if ARCH_SPIDER
>>>>>>>> +
>>>>>>>> +config ARCH_SPIDER_MK1
>>>>>>>> + bool
>>>>>>>> + select CPU_V8
>>>>>>>> + help
>>>>>>>> + The first Cortex-A53-based SoC of the spider family.
>>>>>>>> + This symbol is invisble and select by boards
>>>>>>>> +
>>>>>>>> +config MACH_SPIDER_MK1_EVK
>>>>>>>> + bool "Pliops Spider Reference Design Board"
>>>>>>>> + select ARCH_SPIDER_MK1
>>>>>>>> +
>>>>>>>> +endif
>>>>>>>> diff --git a/arch/arm/mach-spider/Makefile b/arch/arm/mach-
>>>>>>> spider/Makefile new file mode 100644 index
>>>>> 000000000000..b08c4a93ca27
>>>>>>>> --- /dev/null
>>>>>>>> +++ b/arch/arm/mach-spider/Makefile
>>>>>>>> @@ -0,0 +1 @@
>>>>>>>> +lwl-y += lowlevel.o
>>>>>>>> diff --git a/arch/arm/mach-spider/lowlevel.c b/arch/arm/mach-
>>>>>>> spider/lowlevel.c new file mode 100644 index
>>>>>>> 000000000000..5d62ef0f39e5
>>>>>>>> --- /dev/null
>>>>>>>> +++ b/arch/arm/mach-spider/lowlevel.c
>>>>>>>> @@ -0,0 +1,14 @@
>>>>>>>> +// SPDX-License-Identifier: GPL-2.0+
>>>>>>>> +
>>>>>>>> +#include <linux/types.h>
>>>>>>>> +#include <mach/spider/lowlevel.h>
>>>>>>>> +#include <asm/barebox-arm-head.h>
>>>>>>>> +
>>>>>>>> +void spider_lowlevel_init(void)
>>>>>>>> +{
>>>>>>>> + arm_cpu_lowlevel_init();
>>>>>>>> + /*
>>>>>>>> + * not yet relocated, only do writel/readl for stuff that's
>>>>>>>> + * critical to run early. No global variables allowed.
>>>>>>>> + */
>>>>>>>> +}
>>>>>>>> diff --git a/images/Makefile b/images/Makefile index
>>>>>>> c93f9e268978..97521e713228 100644
>>>>>>>> --- a/images/Makefile
>>>>>>>> +++ b/images/Makefile
>>>>>>>> @@ -150,6 +150,7 @@ include $(srctree)/images/Makefile.mxs
>>> include
>>>>>>> $(srctree)/images/Makefile.omap3 include
>>>>>>> $(srctree)/images/Makefile.rockchip
>>>>>>>> include $(srctree)/images/Makefile.socfpga
>>>>>>>> +include $(srctree)/images/Makefile.spider
>>>>>>>> include $(srctree)/images/Makefile.stm32mp
>>>>>>>> include $(srctree)/images/Makefile.tegra include
>>>>>>> $(srctree)/images/Makefile.versatile
>>>>>>>> diff --git a/images/Makefile.spider b/images/Makefile.spider new file
>>>>> mode
>>>>>>> 100644 index 000000000000..c32f2762df04
>>>>>>>> --- /dev/null
>>>>>>>> +++ b/images/Makefile.spider
>>>>>>>> @@ -0,0 +1,5 @@
>>>>>>>> +# SPDX-License-Identifier: GPL-2.0-only
>>>>>>>> +
>>>>>>>> +pblb-$(CONFIG_MACH_SPIDER_MK1_EVK) += start_spider_mk1_evk
>>>>>>>> +FILE_barebox-spider-mk1-evk.img = start_spider_mk1_evk.pblb
>>>>>>>> +image-$(CONFIG_MACH_SPIDER_MK1_EVK) += barebox-spider-mk1-
>>>>>>> evk.img
>>>>>>>> diff --git a/include/mach/spider/lowlevel.h
>>>>>>> b/include/mach/spider/lowlevel.h new file mode 100644 index
>>>>>>> 000000000000..6e0ce1c77f7e
>>>>>>>> --- /dev/null
>>>>>>>> +++ b/include/mach/spider/lowlevel.h
>>>>>>>> @@ -0,0 +1,7 @@
>>>>>>>> +/* SPDX-License-Identifier: GPL-2.0+ */ #ifndef __MACH_SPIDER_H_
>>>>>>>> +#define __MACH_SPIDER_H_
>>>>>>>> +
>>>>>>>> +void spider_lowlevel_init(void);
>>>>>>>> +
>>>>>>>> +#endif
>>>>>>>> --
>>>>>>>> 2.38.4
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Pengutronix e.K. | |
>>>>>>> Steuerwalder Str. 21 | http://www.pengutronix.de/ |
>>>>>>> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
>>>>>>> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555
>>> |
>>>>>>
>>>>>
>>>>> --
>>>>> Pengutronix e.K. | |
>>>>> Steuerwalder Str. 21 | http://www.pengutronix.de/ |
>>>>> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
>>>>> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
>>>>
>>>
>>> --
>>> Pengutronix e.K. | |
>>> Steuerwalder Str. 21 | http://www.pengutronix.de/ |
>>> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
>>> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
>>
>
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply [flat|nested] 40+ messages in thread
* RE: [PATCH v2] Porting barebox to a new SoC
2023-05-31 17:55 ` Ahmad Fatoum
2023-05-31 17:59 ` Ahmad Fatoum
@ 2023-06-01 8:54 ` Lior Weintraub
2023-06-01 9:29 ` Ahmad Fatoum
1 sibling, 1 reply; 40+ messages in thread
From: Lior Weintraub @ 2023-06-01 8:54 UTC (permalink / raw)
To: Ahmad Fatoum, Ahmad Fatoum, barebox
Hi Ahmad,
Thanks again for your great support and the patch.
I've checked it and it works perfectly!
The UART issue was solved after fixing the device tree per your recommendations.
Now I can write into barbox terminal :-)
When I type "cpuinfo" on the terminal I am getting:
implementer: ARM
architecture: v8
core: Cortex-A53 r0p4
exception level: 3
cache: no cache
Control register: P D Z DT IT U XP
Notice that it say "no cache".
I tried to add cache to cpu0 but it didn't help.
.
.
d-cache-size = <0x8000>;
d-cache-line-size = <64>;
d-cache-sets = <128>; // 32KiB(size)/64(line-size)=512ways/4-way set
i-cache-size = <0x8000>;
i-cache-line-size = <64>;
i-cache-sets = <256>; // 32KiB(size)/64(line-size)=512ways/2-way set
next-level-cache = <&l2>;
};
l2: l2-cache0 {
compatible = "cache";
cache-unified;
cache-size = <0x80000>;
cache-line-size = <64>;
cache-sets = <512>; // 512KiB(size)/64(line-size)=8192ways/16-way set
cache-level = <2>;
}
Regarding Linux kernel:
This would be the next step but I assume that it would be a bit more complicated.
I guess we will have to integrate the interrupt controlled (GIC-600) into QEMU and into the device tree for it to work.
Is that a valid assumption?
Thanks,
Lior.
> -----Original Message-----
> From: Ahmad Fatoum <a.fatoum@pengutronix.de>
> Sent: Wednesday, May 31, 2023 8:55 PM
> To: Lior Weintraub <liorw@pliops.com>; Ahmad Fatoum <ahmad@a3f.at>;
> barebox@lists.infradead.org
> Subject: Re: [PATCH v2] Porting barebox to a new SoC
>
> CAUTION: External Sender
>
> Hi Lior,
>
> On 31.05.23 18:13, Lior Weintraub wrote:
> > Hi Ahmad,
> >
> > Using end of SRAM as PBL stack is currently not working because we need
> 40bit address (0xC0_0020_0000).
> > This needs a fix to ENTRY_FUNCTION_WITHSTACK macro.
>
> Ah, right. I just sent an (untested) patch. Would be cool if you could
> try it out.
>
> > I tried just to change const u32 __stack_top = (stack_top); to const u64
> __stack_top = (stack_top); but there were linking errors caused by:
> > ASSERT(. - __pbl_board_stack_top <= 8, "Only One PBL per Image allowed")
>
> The easy way would have been using a __attribute__((naked)) function, but
> those are only supported for arm32, not arm64. The alternative is thus
> writing the entry point in assembly and to make board authors life easier
> the linker script ensures that the stack setup entry point is invoked prior
> to the board entry.
>
> > Regarding the arm timer:
> > Adding the timer entry to DT solved the issue.
> >
> > Regarding the UART:
> > Indeed CONFIG_SERIAL_AMBA_PL011 was set on spider_defconfig (also
> verified it generated the correct entry on .config).
> > I also noticed that if I remove the putc_ll implementation there is no Tx at all
> from Barebox.
>
> I've led you astray. Indeed:
>
> >>> of_platform_bus_create() - skipping /soc, no compatible prop
>
> points at the issue.
>
> Try adding into /soc
>
> compatible = "simple,bus";
> ranges;
> dma-ranges;
>
> This matches /soc with the simple bus driver which just instantiates devices
> for the
> contained children. Those in turn should be matched by the drivers.
>
> The ranges stuff just tells that memory and SoC peripherals exist in the same
> address space.
>
> When it probes you may need to describe the clock in the DT. Eventually, you
> will
> want to have a clock driver for your hardware (good news: barebox and Linux
> have
> basically the same API, so you only need to write it once). But for now, you
> can
> fake it using fixed-clock in the DT. Take a look at:
>
> snps,dw-apb-uart in arch/riscv/dts/jh7100.dtsi and compare with
> dts/src/arm/imx28.dtsi
> to see how to map that to PL011.
>
> > Could it be a hint?
>
> DEBUG_LL bridges the gap until a driver registers a console that's enabled. If
> this
> never happens, you are left with a non-interactive shell.
>
> Cheers,
> Ahmad
>
> >
> > Thanks,
> > Lior.
> >
> >> -----Original Message-----
> >> From: Ahmad Fatoum <a.fatoum@pengutronix.de>
> >> Sent: Wednesday, May 31, 2023 11:40 AM
> >> To: Lior Weintraub <liorw@pliops.com>; Ahmad Fatoum <ahmad@a3f.at>;
> >> barebox@lists.infradead.org
> >> Subject: Re: [PATCH v2] Porting barebox to a new SoC
> >>
> >> CAUTION: External Sender
> >>
> >> Hi Lior,
> >>
> >> On 31.05.23 10:05, Lior Weintraub wrote:
> >>> Hi Ahmad,
> >>>
> >>> Thanks again for your prompt reply and accurate tips!
> >>> Took the following changes:
> >>> 1. Increasing the DRAM size to 128MB (let barebox start from 0).
> >>> 2. Set PBL stack to offset 2MB from DRAM
> >>
> >> Just use end of SRAM, so you are completely independent of DRAM
> >> until you call barebox_arm_entry.
> >>
> >>> 3. Fix the device tree "memory" entry to have 128MB.
> >>
> >> (y)
> >>
> >>> 4. Load barebox-spider-mk1-evk.img to SRAM and run from there.
> >>>
> >>> Now I can see the following logs:
> >>> uncompress.c: memory at 0x00000000, size 0x08000000
> >>> uncompress.c: uncompressing barebox binary at 0x000000c0000021c0
> >> (size 0x0001e3a4) to 0x07e00000 (uncompressed size: 0x000390d0)
> >>> uncompress.c: jumping to uncompressed image at
> 0x0000000007e00000
> >>> start.c: memory at 0x00000000, size 0x08000000
> >>> start.c: found DTB in boarddata, copying to 0x07dffcc0
> >>> start.c: initializing malloc pool at 0x079ffcc0 (size 0x00400000)
> >>> start.c: starting barebox...
> >>> initcall-> command_slice_init+0x0/0x3c
> >>> initcall-> globalvar_init+0x0/0x80
> >>> register_device: global
> >>> register_device: nv
> >>> initcall-> platform_init+0x0/0x1c
> >>> register_device: platform
> >>> initcall-> amba_bus_init+0x0/0x1c
> >>> register_device: amba
> >>> initcall-> spi_bus_init+0x0/0x1c
> >>> register_device: spi
> >>> initcall-> gpio_desc_alloc+0x0/0x24
> >>> initcall-> fs_bus_init+0x0/0x1c
> >>> register_device: fs
> >>> initcall-> aarch64_init_vectors+0x0/0x50
> >>> initcall-> gpio_gate_clock_driver_register+0x0/0x1c
> >>> register_driver: gpio-gate-clock
> >>> initcall-> of_arm_init+0x0/0x5c
> >>> start.c: barebox_arm_boot_dtb: using barebox_boarddata
> >>> using boarddata provided DTB
> >>> adding DT alias:serial0: stem=serial id=0 node=/soc/serial@d000307000
> >>> register_device: machine
> >>> of_platform_bus_create() - skipping /chosen, no compatible prop
> >>> of_platform_bus_create() - skipping /aliases, no compatible prop
> >>> of_platform_bus_create() - skipping /cpus, no compatible prop
> >>> of_platform_bus_create() - skipping /memory@0, no compatible prop
> >>> of_platform_bus_create() - skipping /soc, no compatible prop
> >>> initcall-> register_autoboot_vars+0x0/0x70
> >>> initcall-> arm_arch_timer_driver_register+0x0/0x1c
> >>> register_driver: arm-architected-timer
> >>> initcall-> of_timer_init+0x0/0x20
> >>> initcall-> init_fs+0x0/0x3c
> >>> initcall-> pl011_driver_register+0x0/0x1c
> >>> register_driver: uart-pl011
> >>> initcall-> of_stdoutpath_init+0x0/0x28
> >>> initcall-> of_probe_memory+0x0/0x60
> >>> __request_region ok: 0x00000000:0x07ffffff flags=0x0
> >>> initcall-> __bare_init_end+0x0/0x6c
> >>> register_device: mem0
> >>> initcall-> of_reserved_mem_walk+0x0/0x1ac
> >>> initcall-> mem_malloc_resource+0x0/0xa8
> >>> __request_region ok: 0x079ffcc0:0x07dffcbf flags=0x200
> >>> __request_region ok: 0x07e00000:0x07e2aeff flags=0x200
> >>> __request_region ok: 0x07e2af00:0x07e390cf flags=0x200
> >>> __request_region ok: 0x07e390d0:0x07e3adaf flags=0x200
> >>> initcall-> bootsource_init+0x0/0x40
> >>> initcall-> ramfs_init+0x0/0x1c
> >>> register_driver: ramfs
> >>> initcall-> devfs_init+0x0/0x1c
> >>> register_driver: devfs
> >>> initcall-> arm_request_stack+0x0/0x398
> >>> __request_region ok: 0x07ff0000:0x07ff7fff flags=0x200
> >>> initcall-> mount_root+0x0/0x7c
> >>> mount: none on / type ramfs, options=
> >>> register_device: ramfs0
> >>> probe-> ramfs0
> >>> mount: none on /dev type devfs, options=
> >>> register_device: devfs0
> >>> probe-> devfs0
> >>> initcall-> binfmt_sh_init+0x0/0x1c
> >>> initcall-> binfmt_uimage_init+0x0/0x1c
> >>> initcall-> console_common_init+0x0/0x48
> >>> initcall-> of_kernel_init+0x0/0x28
> >>> initcall-> console_ctrlc_init+0x0/0x30
> >>> initcall-> mem_init+0x0/0x90
> >>> register_device: mem1
> >>> register_driver: mem
> >>> probe-> mem0
> >>> probe-> mem1
> >>> initcall-> of_partition_init+0x0/0x48
> >>> initcall-> prng_init+0x0/0x40
> >>> initcall-> null_init+0x0/0x40
> >>> initcall-> full_init+0x0/0x40
> >>> initcall-> zero_init+0x0/0x40
> >>> initcall-> spider_board_driver_register+0x0/0x1c
> >>> register_driver: board-spider
> >>> probe-> machine
> >>> initcall-> barebox_memory_areas_init+0x0/0x40
> >>> __request_region ok: 0x07dffcc0:0x07dfffce flags=0x200
> >>> initcall-> barebox_of_populate+0x0/0x28
> >>> initcall-> of_register_memory_fixup+0x0/0x20
> >>> initcall-> dummy_csrc_warn+0x0/0x44
> >>> WARNING: Warning: Using dummy clocksource
> >>
> >> Add a arm,armv8-timer node into your SoC device tree.
> >> This lets barebox and Linux know that you have the ARM
> >> architected timer available. Without that, you'll notice
> >> that timeouts are wrong.
> >>
> >>> initcall-> bootm_init+0x0/0xf4
> >>> initcall-> init_command_list+0x0/0x40
> >>> register command bootm
> >>> register command cat
> >>> register command cd
> >>> register command clear
> >>> register command cp
> >>> register command cpuinfo
> >>> register command devinfo
> >>> register command drvinfo
> >>> register command echo
> >>> register command exit
> >>> register command false
> >>> register command help
> >>> register command ?
> >>> register command ll
> >>> register command ls
> >>> register command md
> >>> register command memcmp
> >>> register command memcpy
> >>> register command memset
> >>> register command mkdir
> >>> register command mount
> >>> register command mw
> >>> register command pwd
> >>> register command rm
> >>> register command rmdir
> >>> register command setenv
> >>> register command sh
> >>> register command source
> >>> register command .
> >>> register command test
> >>> register command [
> >>> register command true
> >>> register command :
> >>> register command umount
> >>> register command version
> >>> initcall-> display_meminfo+0x0/0xa8
> >>> barebox code: 0x7e00000 -> 0x7e2aeff
> >>> bss segment: 0x7e390d0 -> 0x7e3adaf
> >>> malloc space: 0x079ffcc0 -> 0x07dffcbf (size 4 MiB)
> >>> initcall-> of_register_bootargs_fixup+0x0/0x3c
> >>> initcall-> device_probe_deferred+0x0/0x14c
> >>> initcall-> of_init_hostname+0x0/0x28
> >>> initcall-> aarch64_register_image_handler+0x0/0x2c
> >>> initcall-> load_environment+0x0/0x4c
> >>> loading defaultenv
> >>> environment load /dev/env0: No such file or directory
> >>> Maybe you have to create the partition.
> >>> initcalls done
> >>>
> >>> Hit any to stop autoboot: 0
> >>> boot: No such file or directory
> >>> barebox:/
> >>>
> >>>
> >>> Few questions:
> >>> 1. The serial input doesn't work. i.e. I cannot type anything hence cannot
> >> interact with barebox terminal.
> >>
> >> DEBUG_LL only does otuput. For input, you will want to load the driver.
> >> Do you have CONFIG_SERIAL_AMBA_PL011 enabled?
> >>
> >>> Does it require GIC and setting interrupts for it to work?
> >>
> >> No interrupts needed. barebox runs with interrupts disabled and
> everything
> >> is done cooperatively.
> >>
> >>> 2. What does "of_platform_bus_create() - skipping" means? Do I need to
> fix
> >> that?
> >>
> >> That's normal debugging output. Some device tree nodes are busses, which
> >> have
> >> children. These entries are skipped because they have no compatible. This is
> >> expected. I'd suggest you remove your VERBOSED_DEBUG define, so you
> are
> >> not
> >> spammed by too much debugging output.
> >>
> >>> 3. Looks like I am still missing some stuff (rootfs? Environment?
> Mounting?
> >> Partitions?)
> >>
> >> Take multi_v8_defconfig, open menuconfig and enable your SoC and use
> that.
> >> That will be quicker than enabling everything yourself. If it doesn't work
> >> out of the box, try imx_v8_defconfig.
> >>
> >> Once you get around to upstreaming your SoC, I'd suggest you just add it
> >> to multi_v8_defconfig. Not all ARMv8 SoCs are supported there, but those
> >> that are make development easier, because we don't need to build as many
> >> different configs..
> >>
> >> Cheers,
> >> Ahmad
> >>
> >>>
> >>> Thanks,
> >>> Have a great day,
> >>> Lior.
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: Ahmad Fatoum <a.fatoum@pengutronix.de>
> >>>> Sent: Wednesday, May 31, 2023 9:11 AM
> >>>> To: Lior Weintraub <liorw@pliops.com>; Ahmad Fatoum
> <ahmad@a3f.at>;
> >>>> barebox@lists.infradead.org
> >>>> Subject: Re: [PATCH v2] Porting barebox to a new SoC
> >>>>
> >>>> CAUTION: External Sender
> >>>>
> >>>> Hi Lior,
> >>>>
> >>>> On 30.05.23 22:10, Lior Weintraub wrote:
> >>>>> Hello Ahmad,
> >>>>>
> >>>>> Thanks again for your kind support!
> >>>>> Your comments helped me progress and the current situation is as
> >> follows:
> >>>>> Our QEMU Spider machine is running a BL1.elf file using the following
> >>>> command:
> >>>>> QEMU_AUDIO_DRV=none qemu-system-aarch64 -M spider-soc -smp 1
> -
> >> m
> >>>> 128M -nographic \
> >>>>> -device loader,file=BL1.elf -cpu cortex-a53,rvbar=0xC004000000 \
> >>>>> -d unimp -semihosting-config enable=on,target=native \
> >>>>> -monitor telnet:localhost:1235,server,nowait \
> >>>>> -gdb tcp::1236
> >>>>>
> >>>>> The BL1.elf is our BootROM application that runs from ROM address
> >>>> 0xC004000000.
> >>>>> Just for debugging purpose we've increased the ROM size so it can
> include
> >>>> the images/barebox-spider-mk1-evk.img (as a const array).
> >>>>> BL1 then copy it (using memcpy) to address 0 and jumps there for
> >>>> execution.
> >>>>
> >>>> Sounds ok.
> >>>>
> >>>>> On the real ASIC this address will be the DRAM and indeed will need to
> be
> >>>> initialized before the copy but here on QEMU it is not required.
> >>>>
> >>>> I see. You could still have your bootrom move barebox into SRAM and
> then
> >>>>
> >>>> barebox_arm_entry(DRAM_ADDR, SZ_128M,
> >> __dtb_spider_mk1_evk_start);
> >>>>
> >>>> To have PBL extract barebox to DRAM. Even if you don't need need
> DRAM
> >>>> setup in QEMU, the flow would be similar to what you will have on actual
> >>>> silicon.
> >>>>
> >>>>> The lowlevel.c of spider-evk was modified to use DRAM_ADDR
> 0x400000
> >>>> (4MB from start) and MY_STACK_TOP was set to 0x8000000 (128M).
> >>>>
> >>>> That's not needed. While you don't have control where barebox PBL will
> be
> >>>> located
> >>>> (depends on BootROM), barebox will extract itself to the end of DRAM
> >>>> without
> >>>> overwriting itself, so you can just use DRAM_ADDR 0 normally.
> Eventually,
> >>>> stack
> >>>> top should go into SRAM, but anywhere that works is ok.
> >>>>
> >>>>> In addition, I implemented putc_ll (currently hard-coded in
> >>>> include/debug_ll.h) and opened log level to VERBOSE_DEBUG (currently
> >> just
> >>>> hard-coded in printk.h).
> >>>>
> >>>> There's CONFIG_DEBUG_PBL you can enable to get all these messages by
> >>>> default.
> >>>>
> >>>>> I see the following (which makes sense) logs on QEMU terminal:
> >>>>> uncompress.c: memory at 0x00400000, size 0x00200000
> >>>>> uncompress.c: uncompressing barebox binary at
> 0x0000000000002200
> >>>> (size 0x0001d3b2) to 0x00400000 (uncompressed size: 0x000373d0)
> >>>>
> >>>> Why pass only 2M to barebox_arm_entry? While this need not be the
> >> whole
> >>>> of RAM, this
> >>>> initial memory is what barebox will use for itself including its final stack
> and
> >>>> malloc area. barebox will also not place itself into the last 1M AFAIK, so
> 2M
> >>>> may not work ok. You should use the minimum possible RAM here or if
> you
> >>>> can detect
> >>>> in PBL how much RAM you have or just the whole RAM bank. I am not
> sure
> >>>> anything lower
> >>>> than SZ_4M would work ok. (Note this is DRAM size, not SRAM. barebox
> >> PBL
> >>>> is fine being
> >>>> called from 64K SRAMs, it just needs DRAM to extract to).
> >>>>
> >>>>> I then connect with aarch64-none-elf-gdb, load the barebox symbols
> (to
> >>>> 0x400000) and check the current execution state (program counter and
> >>>> stack).
> >>>>> Looks like the code is stuck on function register_autoboot_vars:
> >>>>> sp 0x5f7e60 0x5f7e60
> >>>>> pc 0x401264 0x401264 <register_autoboot_vars+24>
> >>>>>
> >>>>> Few observations:
> >>>>> 1. The PBL was using stack top located on 0x8000000 (which is
> >>>> MY_STACK_TOP). Found it be causing a breakpoint on the PBL.
> >>>>> 2. Barebox uses a stack top on 0x600000 which is probably calculated
> >> from
> >>>> my new DRAM_ADDR and SZ_2M given to the function call:
> >>>>> barebox_arm_entry(DRAM_ADDR, SZ_2M,
> >> __dtb_spider_mk1_evk_start);
> >>>>>
> >>>>> This is great! I am starting to find my way.
> >>>>
> >>>> :) Ye, the ENTRY_FUNCTION_WITHSTACK is only when the BootROM
> >> doesn't
> >>>> enter
> >>>> with a valid stack pointer. It's overwritten as soon as barebox is told
> >>>> about the initial memory layout (with barebox_arm_entry).
> >>>>
> >>>>> When the barebox execution didn't print anything to the terminal I
> >>>> remembered that we used a place holder on the dtsi for the uart.
> >>>>> So now I changed it to:
> >>>>> uart0: serial@d000307000 {
> >>>>> compatible = "arm,pl011", "arm,primecell";
> >>>>> reg = <0xd0 0x307000 0 0x1000>;
> >>>>> }
> >>>>> (Our QEMU UART is currently using pl011 device.)
> >>>>
> >>>> Looks ok. Don't forget to enable the driver (via make menuconfig).
> >>>>
> >>>>> After some time (trying to debug by enabling MMU but then reverted
> the
> >>>> code back), I got to a point that when I try to run again I am getting an
> >>>> exception.
> >>>>> I can swear all code changes were reverted back to the point where I
> saw
> >> the
> >>>> barebox stuck on register_autoboot_vars but now it just cases an
> >> exception.
> >>>>> The exception vector code is located on our ROM (part of BL1 code) and
> >> the
> >>>> logs shows that the link register has the value 0x401218 which suggest
> the
> >>>> following code:
> >>>>> 0000000000001200 <load_environment>:
> >>>>> 1200: a9be7bfd stp x29, x30, [sp, #-32]!
> >>>>> 1204: 910003fd mov x29, sp
> >>>>> 1208: a90153f3 stp x19, x20, [sp, #16]
> >>>>> 120c: 94000a07 bl 3a28 <default_environment_path_get>
> >>>>> 1210: d00000f3 adrp x19, 1f000 <do_cpuinfo+0x1f0>
> >>>>> 1214: 912a7273 add x19, x19, #0xa9c
> >>>>> 1218: aa0003f4 mov x20, x0
> >>>>>
> >>>>> Any ideas or suggestions how to proceed with the debugging?
> >>>>
> >>>> You shouldn't need to touch the MMU code. If your initial memory setup
> >>>> is wonky, you may end up overwriting stuff. Try again with bigger
> memory.
> >>>>
> >>>>> BTW, to answer your questions:
> >>>>> The SRAM of 4MB is the only one we have because we assumed it is
> only
> >> for
> >>>> BootROM to load a PBL
> >>>>
> >>>> Ok. Sometimes there are SRAMs for use with DMA. I asked, because a
> >> SRAM
> >>>> in the first 4M
> >>>> would lend itself nicely as stack, but if there is none, we can adjust
> >>>> ENTRY_FUNCTION_WITHSTACK to accept a 64-bit parameter.
> >>>>
> >>>> Cheers,
> >>>> Ahmad
> >>>>
> >>>>> Thank you very much,
> >>>>> Cheers,
> >>>>> Lior.
> >>>>>
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: Ahmad Fatoum <a.fatoum@pengutronix.de>
> >>>>>> Sent: Monday, May 29, 2023 10:03 PM
> >>>>>> To: Lior Weintraub <liorw@pliops.com>; Ahmad Fatoum
> >> <ahmad@a3f.at>;
> >>>>>> barebox@lists.infradead.org
> >>>>>> Subject: Re: [PATCH v2] Porting barebox to a new SoC
> >>>>>>
> >>>>>> CAUTION: External Sender
> >>>>>>
> >>>>>> Hello Lior,
> >>>>>>
> >>>>>> On 29.05.23 15:34, Lior Weintraub wrote:
> >>>>>>> Hi Ahmad,
> >>>>>>>
> >>>>>>> I have revised the addresses and used DRAM address @ 0 instead:
> >>>>>>> #define UARTBASE (0xD000307000)
> >>>>>>> #define DRAM_ADDR (0x00000000)
> >>>>>>> #define MY_STACK_TOP (0x00000000 + SZ_2M) // Set the stack
> 2MB
> >>>> from
> >>>>>> DRAM start
> >>>>>>
> >>>>>> Is DRAM configured by the time barebox runs? If not, you should keep
> >>>> stack
> >>>>>> top
> >>>>>> in SRAM, until you have setup memory in prebootloader (PBL). Is the
> 4M
> >>>>>> SRAM
> >>>>>> the only on-chip SRAM you have?
> >>>>>>
> >>>>>>> static inline void spider_serial_putc(void *base, int c)
> >>>>>>> {
> >>>>>>> *((volatile unsigned *)base) = c;
> >>>>>>
> >>>>>> There's a helper for that: writel(c, base); In barebox, it's equivalent
> >>>>>> to the volatile access, but in Linux it involves a write memory barrier.
> >>>>>> We try to write code in barebox, so it's easily reusable in Linux (and
> >>>>>> the other way round).
> >>>>>>
> >>>>>>> }
> >>>>>>>
> >>>>>>> I will try to test it on QEMU using an initial QEMU machine we made
> for
> >>>>>> Spider.
> >>>>>>> In this machine we only have 3 memory regions and a PL011 UART:
> >>>>>>> spider_soc_memories soc_memories[] = {
> >>>>>>> {.name = "SPIDER_GPRAM", .add = 0xC000000000ULL, .size = 4 *
> >> MiB},
> >>>>>>> {.name = "SPIDER_ROM", .add = 0xC004000000ULL, .size = 128 *
> >>>> KiB},
> >>>>>>> {.name = "SPIDER_DRAM", .add = 0x0000000000ULL, .size = 1 *
> >> GiB},
> >>>>>>> };
> >>>>>>>
> >>>>>>> This special QEMU machine can run our BL1 code from "ROM"
> address
> >>>> (we
> >>>>>> set the RVBAR to point there).
> >>>>>>> So my idea is to test the barebox image by the following steps:
> >>>>>>> 1. Modify the QEMU code to have a "ROM" with the size of 128M.
> >>>>>>> 2. Compile our BL1 code to include the barebox.bin as a const array,
> >> copy
> >>>> it
> >>>>>> to "DRAM" @ address 0 and jump there.
> >>>>>>
> >>>>>> Why not map QEMU -bios option to SRAM? (Or DRAM directly, if it
> >> needs
> >>>> no
> >>>>>> special setup from
> >>>>>> barebox side).
> >>>>>>
> >>>>>>> For this to work I wanted to understand how to call (i.e. what
> >> arguments
> >>>> to
> >>>>>> pass) to barebox.
> >>>>>>
> >>>>>> barebox doesn't expect any arguments, because most BootROMs
> don't
> >>>> pass
> >>>>>> anything useful.
> >>>>>> Some pass information about bootsource though, so that's why the
> >>>>>> ENTRY_FUNCTION has
> >>>>>> r0, r1 and r2 as parameters, but you need not use them.
> >>>>>>
> >>>>>>> So I checked the barebox.map and found the function "start" on
> >> address
> >>>> 0.
> >>>>>>
> >>>>>> You may know that Linux on some platforms comes with a
> decompressor
> >>>> that
> >>>>>> is glued to the
> >>>>>> front of the kernel image and extracts the compressed kernel image.
> >>>> barebox
> >>>>>> has the same
> >>>>>> concept. The prebootloader is uncompressed and runs (starting from
> >>>>>> ENTRY_FUNCTION) and
> >>>>>> then does some early setup (e.g. enable clocks, configure PMIC, setup
> >>>> DRAM,
> >>>>>> load secure
> >>>>>> monitor (BL31), ...etc.) and then it decompresses barebox proper into
> >>>> DRAM.
> >>>>>>
> >>>>>> barebox.bin <- barebox proper. You don't usually need that.
> >>>>>> barebox.elf <- ELF binary for the above (for gdb)
> >>>>>> barebox.map <- map file of the above
> >>>>>>
> >>>>>> images/barebox-spider-mk1-evk.img <- complete barebox image (PBL
> +
> >>>>>> barebox proper)
> >>>>>> images/start_spider_mk1_evk.pbl <- ELF image for the above
> >>>>>> images/start_spider_mk1_evk.pbl.map <- map file of the above
> >>>>>>
> >>>>>> If you want to follow barbeox from the start, begin at
> >>>> start_spider_mk1_evk.
> >>>>>>
> >>>>>>> Then I went to arch/arm/cpu/start.c and realized that the code is
> >> compiled
> >>>>>> with CONFIG_PBL_IMAGE.
> >>>>>>> In that case I assume I need to pass 3 arguments and use this
> function
> >>>>>> prototype:
> >>>>>>> void start(unsigned long membase, unsigned long memsize, void
> >>>>>> *boarddata);
> >>>>>>
> >>>>>> barebox prebootloader takes care of this, so you don't need to do
> >> anything.
> >>>>>>
> >>>>>>> Few questions:
> >>>>>>> 1. Will that call work:
> >>>>>>> typedef void (*barebox_start)(unsigned long , unsigned long , void
> *);
> >>>>>>> #define DRAM_START (0)
> >>>>>>> barebox_start p_barebox = (barebox_start)DRAM_START;
> >>>>>>> p_barebox(DRAM_START, DRAM_START+SZ_2M, (void
> >>>>>> *)(DRAM_START+SZ_4M));
> >>>>>>> This assumes that my BL1 code also copied the device tree
> (barebox-
> >> dt-
> >>>>>> 2nd.img? start_dt_2nd.pblb? start_spider_mk1_evk.pblb?)
> >>>>>>
> >>>>>> The device tree is built into the PBL and passed to barebox proper. This
> >>>>>> allows us to use the same barebox proper binary and link it with a
> >> different
> >>>>>> prebootloader for each SoC/board, all in the same build.
> >>>>>>
> >>>>>> barebox-dt-2nd.img is a special image that looks exactly like a Linux
> >> kernel:
> >>>>>>
> >>>>>> images/barebox-dt-2nd.img: Linux kernel ARM64 boot executable
> >> Image,
> >>>>>> little-endian, 4K pages
> >>>>>>
> >>>>>> and can thus be used for booting for easy chainloading from other
> >>>>>> bootloaders or for running
> >>>>>> with QEMU -kernel. You shouldn't need it right now.
> >>>>>>
> >>>>>>> 2. Do I want to have my code compiled with CONFIG_PBL_IMAGE?
> >>>>>>> If I understand correctly, it means that my code will provide a PBL
> >> (a.k.a
> >>>>>> BL2) which will set the DRAM and STACK among other things (MMU?).
> >>>>>>
> >>>>>> The patch I sent already builds a PBL. You will need to fill out
> >>>>>> start_spider_mk1_evk
> >>>>>> to do all the other early initialization you need. Then you call
> >>>>>> barebox_arm_entry
> >>>>>> with device tree and memory size and it will take care to do stack setup
> in
> >>>> new
> >>>>>> memory region, MMU setup (if enabled) and chainloading barebox
> >> proper.
> >>>>>>
> >>>>>> Note that PBL isn't necessary BL2. You can chainload barebox from
> within
> >>>>>> barebox (i.e.
> >>>>>> in EL2 or EL1), which is useful for debugging. You will thus often find
> PBL
> >>>> code
> >>>>>> that
> >>>>>> does
> >>>>>>
> >>>>>> if (current_el() == 3) {
> >>>>>> /* Do BL2 setup */
> >>>>>> chainload();
> >>>>>> __builtin_unreachable();
> >>>>>> }
> >>>>>>
> >>>>>> barebox_arm_entry(...)
> >>>>>>
> >>>>>> See for example arch/arm/boards/innocomm-imx8mm-
> wb15/lowlevel.c
> >>>>>>
> >>>>>> to see a real-world example of another Cortex-A53.
> >>>>>>
> >>>>>>> In that case I assume it is OK.
> >>>>>>> 3. If I try to remove it by having CONFIG_PBL_IMAGE=n on
> >>>> spider_defconfig
> >>>>>> this doesn't do anything
> >>>>>>> The build (make spider_defconfig) ignores it and say that " No
> change
> >> to
> >>>>>> .config ".
> >>>>>>
> >>>>>> Another symbol forces it to be enabled. If you are curious, run make
> >>>>>> menuconfig
> >>>>>> and then search (/) for the symbol and it will list, whether it's enabled
> >> and
> >>>>>> why:
> >>>>>>
> >>>>>> Selected by [y]:
> >>>>>> - PBL_MULTI_IMAGES [=y] && HAVE_PBL_MULTI_IMAGES [=y]
> >>>>>>
> >>>>>> I'd suggest you avoid modifying the .config file manually. always use
> >>>>>> menuconfig.
> >>>>>>
> >>>>>>> 4. I also tried to understand how to implement PUTC_LL but not sure
> I
> >>>>>> understand.
> >>>>>>> 4.1 When I set "CONFIG_DEBUG_LL=y" on spider_defconfig it is
> again
> >>>> not
> >>>>>> written to .config and I get " No change to .config " message.
> >>>>>>
> >>>>>> You must:
> >>>>>>
> >>>>>> - select HAS_DEBUG_LL from MACH_SPIDER
> >>>>>> - Add your arch to arch/arm/include/asm/debug_ll.h
> >>>>>> - Then implement PUTC_LL in e.g. mach/spider/debug_ll.h
> >>>>>>
> >>>>>>> 4.2 Do I need to have my own debug_ll.h file?
> >>>>>>
> >>>>>> Yes. See above.
> >>>>>>
> >>>>>>> 5. When I make changes to spider_defconfig and try to regenerate
> the
> >>>>>> .config and I get " No change to .config " message, does it mean that
> >> those
> >>>>>> macros are "hidden" symbols like you said about the
> CONFIG_CPU_V8?
> >>>>>>
> >>>>>> Yes. Just check menuconfig to see how symbols relate to each other.
> >>>>>> This is 1:1 like it's in Linux, so it'll come in handy when you do
> >>>>>> the kernel port too ;)
> >>>>>>
> >>>>>>> Apologize for so many questions :-)
> >>>>>>
> >>>>>> No problem. Looking forward to your patches ;)
> >>>>>>
> >>>>>>
> >>>>>> Cheers,
> >>>>>> Ahmad
> >>>>>>
> >>>>>>> Cheers,
> >>>>>>> Lior.
> >>>>>>>
> >>>>>>> -----Original Message-----
> >>>>>>> From: Lior Weintraub
> >>>>>>> Sent: Sunday, May 28, 2023 11:16 PM
> >>>>>>> To: Ahmad Fatoum <ahmad@a3f.at>; barebox@lists.infradead.org
> >>>>>>> Subject: RE: [PATCH v2] Porting barebox to a new SoC
> >>>>>>>
> >>>>>>> Hi Ahmad,
> >>>>>>>
> >>>>>>> Thank you so much for your kind support!
> >>>>>>>
> >>>>>>> Indeed we also have a 16GB DRAM that starts from address 0
> (though
> >>>>>> currently we don't have the controller settings (under development)).
> >>>>>>>
> >>>>>>> I also wrote the BootROM (BL1) for this SoC (128KB ROM @ address
> >>>>>> 0xC004000000).
> >>>>>>> I understand now that it would be best for me to develop BL2 that
> will
> >> run
> >>>>>> from our SRAM.
> >>>>>>>
> >>>>>>> As this BL2 code is bare-metal I have no problem or limitations with
> the
> >> 40
> >>>>>> bit addresses.
> >>>>>>> The BL2 code will initialize the DRAM controller and then copy
> Barebox
> >>>> image
> >>>>>> from NOR Flash to address 0 of the DRAM.
> >>>>>>> Our NOR Flash is 128MB in size and it is accessed via QSPI controller.
> >>>>>>>
> >>>>>>> I tried applying your suggested patch but got an error while doing so:
> >>>>>>> $git apply 0002-Ahmad.patch
> >>>>>>> 0002-Ahmad.patch:115: trailing whitespace.
> >>>>>>> .of_compatible = spider_board_of_match, };
> >>>>>>> error: corrupt patch at line 117
> >>>>>>>
> >>>>>>> After some digging I found that my Outlook probably messed with
> the
> >>>> patch
> >>>>>> format (even though I am using text only and no HTML format).
> >>>>>>> When I went to the web and copied the patch from there (mailing list
> >>>>>> archive) it was working well (i.e. no compilation error).
> >>>>>>>
> >>>>>>> Cheers,
> >>>>>>> Lior.
> >>>>>>>
> >>>>>>> -----Original Message-----
> >>>>>>> From: Ahmad Fatoum <ahmad@a3f.at>
> >>>>>>> Sent: Sunday, May 28, 2023 6:38 PM
> >>>>>>> To: barebox@lists.infradead.org
> >>>>>>> Cc: Lior Weintraub <liorw@pliops.com>
> >>>>>>> Subject: [PATCH v2] Porting barebox to a new SoC
> >>>>>>>
> >>>>>>> CAUTION: External Sender
> >>>>>>>
> >>>>>>> From: Lior Weintraub <liorw@pliops.com>
> >>>>>>>
> >>>>>>> Hi,
> >>>>>>>
> >>>>>>> I tried to follow the porting guide on https://ddec1-0-en-
> >>>>>>
> >>>>
> >>
> ctp.trendmicro.com:443/wis/clicktime/v1/query?url=https%3a%2f%2fwww.
> >>>>>>
> >>>>
> >>
> barebox.org%2fdoc%2flatest%2fdevel%2fporting.html%23&umid=60097eda
> >>>>>> -f136-45a1-9c8e-
> >>>>>>
> cf6a76e45cf8&auth=860a7ebb9feba264acc79b6e38eb59582349362c-
> >>>>>> 480ae23736add41c88ab8d30c090a75517ca7f9e but couldn't follow
> >> the
> >>>>>> instructions.
> >>>>>>> I would like to port barebox to a new SoC (which is not a derivative of
> >> any
> >>>>>> known SoC).
> >>>>>>> It has the following:
> >>>>>>> * Single Cortex A53
> >>>>>>> * SRAM (4MB) located on address 0xC000000000
> >>>>>>>
> >>>>>>> The below patch shows my initial test to try and have a starting point.
> >>>>>>> I am setting env variables:
> >>>>>>> export ARCH=arm64
> >>>>>>> export CROSS_COMPILE=/home/pliops/workspace/ARM/arm-gnu-
> >>>>>> toolchain/bin/aarch64-none-elf-
> >>>>>>>
> >>>>>>> Then I build with:
> >>>>>>> make spider_defconfig && make
> >>>>>>>
> >>>>>>> This gives an error:
> >>>>>>> aarch64-none-elf-gcc: error: unrecognized argument in option '-
> >>>> mabi=apcs-
> >>>>>> gnu'
> >>>>>>> aarch64-none-elf-gcc: note: valid arguments to '-mabi=' are: ilp32
> lp64
> >>>>>>> aarch64-none-elf-gcc: error: unrecognized command-line option '-
> >> msoft-
> >>>>>> float'
> >>>>>>> aarch64-none-elf-gcc: error: unrecognized command-line option '-
> mno-
> >>>>>> unaligned-access'
> >>>>>>> /home/pliops/workspace/simplest-linux-
> >>>>>> demo/barebox/scripts/Makefile.build:140: recipe for target
> >>>>>> 'scripts/mod/empty.o' failed
> >>>>>>> make[2]: *** [scripts/mod/empty.o] Error 1
> >>>>>>>
> >>>>>>> Not sure why the compiler flags get -mabi=apcs-gnu when I explicitly
> set
> >>>>>> CONFIG_CPU_V8 and the arch/arm/Makefile has:
> >>>>>>> ifeq ($(CONFIG_CPU_V8), y)
> >>>>>>> CFLAGS_ABI :=-mabi=lp64
> >>>>>>>
> >>>>>>> The changes I did:
> >>>>>>> >From 848b5f9b18bb1bb96d197cbc1b368ee0a729d581 Mon Sep
> 17
> >>>>>> 00:00:00 2001
> >>>>>>> ---
> >>>>>>> arch/arm/Kconfig | 13 ++++++++
> >>>>>>> arch/arm/Makefile | 1 +
> >>>>>>> arch/arm/boards/Makefile | 1 +
> >>>>>>> arch/arm/boards/spider-evk/Makefile | 4 +++
> >>>>>>> arch/arm/boards/spider-evk/board.c | 26 +++++++++++++++
> >>>>>>> arch/arm/boards/spider-evk/lowlevel.c | 30 +++++++++++++++++
> >>>>>>> arch/arm/configs/spider_defconfig | 8 +++++
> >>>>>>> arch/arm/dts/Makefile | 1 +
> >>>>>>> arch/arm/dts/spider-mk1-evk.dts | 10 ++++++
> >>>>>>> arch/arm/dts/spider-mk1.dtsi | 46
> >> +++++++++++++++++++++++++++
> >>>>>>> arch/arm/mach-spider/Kconfig | 16 ++++++++++
> >>>>>>> arch/arm/mach-spider/Makefile | 1 +
> >>>>>>> arch/arm/mach-spider/lowlevel.c | 14 ++++++++
> >>>>>>> images/Makefile | 1 +
> >>>>>>> images/Makefile.spider | 5 +++
> >>>>>>> include/mach/spider/lowlevel.h | 7 ++++
> >>>>>>> 16 files changed, 184 insertions(+)
> >>>>>>> create mode 100644 arch/arm/boards/spider-evk/Makefile
> >>>>>>> create mode 100644 arch/arm/boards/spider-evk/board.c
> >>>>>>> create mode 100644 arch/arm/boards/spider-evk/lowlevel.c
> >>>>>>> create mode 100644 arch/arm/configs/spider_defconfig create
> mode
> >>>>>> 100644 arch/arm/dts/spider-mk1-evk.dts create mode 100644
> >>>>>> arch/arm/dts/spider-mk1.dtsi create mode 100644 arch/arm/mach-
> >>>>>> spider/Kconfig create mode 100644 arch/arm/mach-spider/Makefile
> >>>> create
> >>>>>> mode 100644 arch/arm/mach-spider/lowlevel.c create mode 100644
> >>>>>> images/Makefile.spider create mode 100644
> >>>> include/mach/spider/lowlevel.h
> >>>>>>>
> >>>>>>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index
> >>>>>> e76ee0f6dfe1..e5dcf128447e 100644
> >>>>>>> --- a/arch/arm/Kconfig
> >>>>>>> +++ b/arch/arm/Kconfig
> >>>>>>> @@ -255,6 +255,18 @@ config ARCH_ROCKCHIP
> >>>>>>> select HAS_DEBUG_LL
> >>>>>>> imply GPIO_ROCKCHIP
> >>>>>>>
> >>>>>>> +config ARCH_SPIDER
> >>>>>>> + bool "Pliops Spider based"
> >>>>>>> + depends on 64BIT
> >>>>>>> + depends on ARCH_MULTIARCH
> >>>>>>> + select GPIOLIB
> >>>>>>> + select HAVE_PBL_MULTI_IMAGES
> >>>>>>> + select COMMON_CLK
> >>>>>>> + select CLKDEV_LOOKUP
> >>>>>>> + select COMMON_CLK_OF_PROVIDER
> >>>>>>> + select OFTREE
> >>>>>>> + select OFDEVICE
> >>>>>>> +
> >>>>>>> config ARCH_STM32MP
> >>>>>>> bool "STMicroelectronics STM32MP"
> >>>>>>> depends on 32BIT
> >>>>>>> @@ -331,6 +343,7 @@ source "arch/arm/mach-omap/Kconfig"
> >>>>>>> source "arch/arm/mach-pxa/Kconfig"
> >>>>>>> source "arch/arm/mach-rockchip/Kconfig"
> >>>>>>> source "arch/arm/mach-socfpga/Kconfig"
> >>>>>>> +source "arch/arm/mach-spider/Kconfig"
> >>>>>>> source "arch/arm/mach-stm32mp/Kconfig"
> >>>>>>> source "arch/arm/mach-versatile/Kconfig"
> >>>>>>> source "arch/arm/mach-vexpress/Kconfig"
> >>>>>>> diff --git a/arch/arm/Makefile b/arch/arm/Makefile index
> >>>>>> 35ebc70f44e2..4c63dfee48f4 100644
> >>>>>>> --- a/arch/arm/Makefile
> >>>>>>> +++ b/arch/arm/Makefile
> >>>>>>> @@ -101,6 +101,7 @@ machine-$(CONFIG_ARCH_MXS) += mxs
> >>>>>>> machine-$(CONFIG_ARCH_MVEBU) += mvebu
> >>>>>>> machine-$(CONFIG_ARCH_NOMADIK) += nomadik
> >>>>>>> machine-$(CONFIG_ARCH_OMAP) += omap
> >>>>>>> +machine-$(CONFIG_ARCH_SPIDER) += spider
> >>>>>>> machine-$(CONFIG_ARCH_PXA) += pxa
> >>>>>>> machine-$(CONFIG_ARCH_ROCKCHIP) += rockchip
> >>>>>>> machine-$(CONFIG_ARCH_SAMSUNG) += samsung
> >>>>>>> diff --git a/arch/arm/boards/Makefile b/arch/arm/boards/Makefile
> >> index
> >>>>>> 2877debad535..6fe0a90c81ea 100644
> >>>>>>> --- a/arch/arm/boards/Makefile
> >>>>>>> +++ b/arch/arm/boards/Makefile
> >>>>>>> @@ -135,6 +135,7 @@ obj-
> >>>>>> $(CONFIG_MACH_SOCFPGA_TERASIC_DE10_NANO) += terasic-
> >> de10-
> >>>>>> nano/
> >>>>>>> obj-$(CONFIG_MACH_SOCFPGA_TERASIC_SOCKIT) += terasic-
> >> sockit/
> >>>>>>> obj-$(CONFIG_MACH_SOLIDRUN_CUBOX) += solidrun-cubox/
> >>>>>>> obj-$(CONFIG_MACH_SOLIDRUN_MICROSOM) += solidrun-
> >>>>>> microsom/
> >>>>>>> +obj-$(CONFIG_MACH_SPIDER_MK1_EVK) += spider-evk/
> >>>>>>> obj-$(CONFIG_MACH_STM32MP15XX_DKX) +=
> stm32mp15xx-
> >>>> dkx/
> >>>>>>> obj-$(CONFIG_MACH_STM32MP13XX_DK) += stm32mp13xx-
> >> dk/
> >>>>>>> obj-$(CONFIG_MACH_LXA_MC1) += lxa-mc1/
> >>>>>>> diff --git a/arch/arm/boards/spider-evk/Makefile
> >>>>>> b/arch/arm/boards/spider-evk/Makefile
> >>>>>>> new file mode 100644
> >>>>>>> index 000000000000..da63d2625f7a
> >>>>>>> --- /dev/null
> >>>>>>> +++ b/arch/arm/boards/spider-evk/Makefile
> >>>>>>> @@ -0,0 +1,4 @@
> >>>>>>> +# SPDX-License-Identifier: GPL-2.0-only
> >>>>>>> +
> >>>>>>> +obj-y += board.o
> >>>>>>> +lwl-y += lowlevel.o
> >>>>>>> diff --git a/arch/arm/boards/spider-evk/board.c
> >>>> b/arch/arm/boards/spider-
> >>>>>> evk/board.c
> >>>>>>> new file mode 100644
> >>>>>>> index 000000000000..3920e83b457d
> >>>>>>> --- /dev/null
> >>>>>>> +++ b/arch/arm/boards/spider-evk/board.c
> >>>>>>> @@ -0,0 +1,26 @@
> >>>>>>> +#include <bbu.h>
> >>>>>>> +#include <boot.h>
> >>>>>>> +#include <bootm.h>
> >>>>>>> +#include <common.h>
> >>>>>>> +#include <deep-probe.h>
> >>>>>>> +#include <environment.h>
> >>>>>>> +#include <fcntl.h>
> >>>>>>> +#include <globalvar.h>
> >>>>>>> +
> >>>>>>> +static int spider_board_probe(struct device *dev) {
> >>>>>>> + /* Do some board-specific setup */
> >>>>>>> + return 0;
> >>>>>>> +}
> >>>>>>> +
> >>>>>>> +static const struct of_device_id spider_board_of_match[] = {
> >>>>>>> + { .compatible = "pliops,spider-mk1-evk" },
> >>>>>>> + { /* sentinel */ },
> >>>>>>> +};
> >>>>>>> +
> >>>>>>> +static struct driver spider_board_driver = {
> >>>>>>> + .name = "board-spider",
> >>>>>>> + .probe = spider_board_probe,
> >>>>>>> + .of_compatible = spider_board_of_match, };
> >>>>>>> +device_platform_driver(spider_board_driver);
> >>>>>>> diff --git a/arch/arm/boards/spider-evk/lowlevel.c
> >>>>>> b/arch/arm/boards/spider-evk/lowlevel.c
> >>>>>>> new file mode 100644
> >>>>>>> index 000000000000..e36fcde4208e
> >>>>>>> --- /dev/null
> >>>>>>> +++ b/arch/arm/boards/spider-evk/lowlevel.c
> >>>>>>> @@ -0,0 +1,30 @@
> >>>>>>> +#include <common.h>
> >>>>>>> +#include <asm/barebox-arm.h>
> >>>>>>> +#include <mach/spider/lowlevel.h>
> >>>>>>> +
> >>>>>>> +#define BASE_ADDR (0xD000307000)
> >>>>>>> +#define GPRAM_ADDR (0xC000000000)
> >>>>>>> +#define MY_STACK_TOP (0xC000000000 + SZ_2M) // Set the stack
> >>>> 2MB
> >>>>>> from GPRAM start (excatly in the middle)
> >>>>>>> +static inline void spider_serial_putc(void *base, int c) {
> >>>>>>> +// if (!(readl(base + UCR1) & UCR1_UARTEN))
> >>>>>>> +// return;
> >>>>>>> +//
> >>>>>>> +// while (!(readl(base + USR2) & USR2_TXDC));
> >>>>>>> +//
> >>>>>>> +// writel(c, base + URTX0);
> >>>>>>> +}
> >>>>>>> +
> >>>>>>> +ENTRY_FUNCTION_WITHSTACK(start_spider_mk1_evk,
> >> MY_STACK_TOP,
> >>>>>> r0, r1,
> >>>>>>> +r2) {
> >>>>>>> + extern char __dtb_spider_mk1_evk_start[];
> >>>>>>> +
> >>>>>>> + spider_lowlevel_init();
> >>>>>>> +
> >>>>>>> + relocate_to_current_adr();
> >>>>>>> + setup_c();
> >>>>>>> +
> >>>>>>> + pbl_set_putc(spider_serial_putc, (void *)BASE_ADDR);
> >>>>>>> +
> >>>>>>> + barebox_arm_entry(GPRAM_ADDR, SZ_2M,
> >>>>>>> +__dtb_spider_mk1_evk_start); }
> >>>>>>> diff --git a/arch/arm/configs/spider_defconfig
> >>>>>> b/arch/arm/configs/spider_defconfig
> >>>>>>> new file mode 100644
> >>>>>>> index 000000000000..c91bb889d97f
> >>>>>>> --- /dev/null
> >>>>>>> +++ b/arch/arm/configs/spider_defconfig
> >>>>>>> @@ -0,0 +1,8 @@
> >>>>>>> +CONFIG_ARCH_SPIDER=y
> >>>>>>> +CONFIG_MACH_SPIDER_MK1_EVK=y
> >>>>>>> +CONFIG_BOARD_ARM_GENERIC_DT=y
> >>>>>>> +CONFIG_MALLOC_TLSF=y
> >>>>>>> +CONFIG_KALLSYMS=y
> >>>>>>> +CONFIG_RELOCATABLE=y
> >>>>>>> +CONFIG_CONSOLE_ALLOW_COLOR=y
> >>>>>>> +CONFIG_PBL_CONSOLE=y
> >>>>>>> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile index
> >>>>>> 98f4c4e0194b..94b304d4878f 100644
> >>>>>>> --- a/arch/arm/dts/Makefile
> >>>>>>> +++ b/arch/arm/dts/Makefile
> >>>>>>> @@ -134,6 +134,7 @@ lwl-$(CONFIG_MACH_SOLIDRUN_CUBOX)
> +=
> >>>> dove-
> >>>>>> cubox-bb.dtb.o
> >>>>>>> lwl-$(CONFIG_MACH_SOLIDRUN_MICROSOM) += imx6dl-
> >>>>>> hummingboard.dtb.o imx6q-hummingboard.dtb.o \
> >>>>>>> imx6dl-hummingboard2.dtb.o imx6q-
> >>>>>> hummingboard2.dtb.o \
> >>>>>>> imx6q-h100.dtb.o
> >>>>>>> +lwl-$(CONFIG_MACH_SPIDER_MK1_EVK) += spider-mk1-evk.dtb.o
> >>>>>>> lwl-$(CONFIG_MACH_SKOV_IMX6) += imx6s-skov-imx6.dtb.o
> imx6dl-
> >>>> skov-
> >>>>>> imx6.dtb.o imx6q-skov-imx6.dtb.o
> >>>>>>> lwl-$(CONFIG_MACH_SKOV_ARM9CPU) += at91-skov-
> arm9cpu.dtb.o
> >>>>>>> lwl-$(CONFIG_MACH_SEEED_ODYSSEY) += stm32mp157c-
> >> odyssey.dtb.o
> >>>>>> diff --git a/arch/arm/dts/spider-mk1-evk.dts b/arch/arm/dts/spider-
> >> mk1-
> >>>>>> evk.dts new file mode 100644 index 000000000000..b8081cb85bf8
> >>>>>>> --- /dev/null
> >>>>>>> +++ b/arch/arm/dts/spider-mk1-evk.dts
> >>>>>>> @@ -0,0 +1,10 @@
> >>>>>>> +// SPDX-License-Identifier: GPL-2.0 OR X11
> >>>>>>> +
> >>>>>>> +/dts-v1/;
> >>>>>>> +
> >>>>>>> +#include "spider-mk1.dtsi"
> >>>>>>> +
> >>>>>>> +/ {
> >>>>>>> + model = "Pliops Spider MK-I EVK";
> >>>>>>> + compatible = "pliops,spider-mk1-evk"; };
> >>>>>>> diff --git a/arch/arm/dts/spider-mk1.dtsi b/arch/arm/dts/spider-
> >> mk1.dtsi
> >>>>>> new file mode 100644 index 000000000000..d4613848169d
> >>>>>>> --- /dev/null
> >>>>>>> +++ b/arch/arm/dts/spider-mk1.dtsi
> >>>>>>> @@ -0,0 +1,46 @@
> >>>>>>> +// SPDX-License-Identifier: GPL-2.0 OR X11
> >>>>>>> +
> >>>>>>> +/ {
> >>>>>>> + #address-cells = <2>;
> >>>>>>> + #size-cells = <2>;
> >>>>>>> +
> >>>>>>> + chosen {
> >>>>>>> + stdout-path = &uart0;
> >>>>>>> + };
> >>>>>>> +
> >>>>>>> + aliases {
> >>>>>>> + serial0 = &uart0;
> >>>>>>> + };
> >>>>>>> +
> >>>>>>> + cpus {
> >>>>>>> + #address-cells = <1>;
> >>>>>>> + #size-cells = <0>;
> >>>>>>> +
> >>>>>>> + cpu0: cpu@0 {
> >>>>>>> + device_type = "cpu";
> >>>>>>> + compatible = "arm,cortex-a53";
> >>>>>>> + reg = <0x0>;
> >>>>>>> + };
> >>>>>>> + };
> >>>>>>> +
> >>>>>>> + memory@1000000 {
> >>>>>>> + reg = <0x0 0x1000000 0x0 0x400000>; /* 128M */
> >>>>>>> + device_type = "memory";
> >>>>>>> + };
> >>>>>>> +
> >>>>>>> + soc {
> >>>>>>> + #address-cells = <2>;
> >>>>>>> + #size-cells = <2>;
> >>>>>>> + ranges;
> >>>>>>> +
> >>>>>>> + sram@c000000000 {
> >>>>>>> + compatible = "mmio-sram";
> >>>>>>> + reg = <0xc0 0x0 0x0 0x400000>;
> >>>>>>> + };
> >>>>>>> +
> >>>>>>> + uart0: serial@d000307000 {
> >>>>>>> + compatible = "pliops,spider-uart";
> >>>>>>> + reg = <0xd0 0x307000 0 0x1000>;
> >>>>>>> + };
> >>>>>>> + };
> >>>>>>> +};
> >>>>>>> diff --git a/arch/arm/mach-spider/Kconfig b/arch/arm/mach-
> >>>> spider/Kconfig
> >>>>>> new file mode 100644 index 000000000000..6d2f888a5fd8
> >>>>>>> --- /dev/null
> >>>>>>> +++ b/arch/arm/mach-spider/Kconfig
> >>>>>>> @@ -0,0 +1,16 @@
> >>>>>>> +# SPDX-License-Identifier: GPL-2.0-only
> >>>>>>> +
> >>>>>>> +if ARCH_SPIDER
> >>>>>>> +
> >>>>>>> +config ARCH_SPIDER_MK1
> >>>>>>> + bool
> >>>>>>> + select CPU_V8
> >>>>>>> + help
> >>>>>>> + The first Cortex-A53-based SoC of the spider family.
> >>>>>>> + This symbol is invisble and select by boards
> >>>>>>> +
> >>>>>>> +config MACH_SPIDER_MK1_EVK
> >>>>>>> + bool "Pliops Spider Reference Design Board"
> >>>>>>> + select ARCH_SPIDER_MK1
> >>>>>>> +
> >>>>>>> +endif
> >>>>>>> diff --git a/arch/arm/mach-spider/Makefile b/arch/arm/mach-
> >>>>>> spider/Makefile new file mode 100644 index
> >>>> 000000000000..b08c4a93ca27
> >>>>>>> --- /dev/null
> >>>>>>> +++ b/arch/arm/mach-spider/Makefile
> >>>>>>> @@ -0,0 +1 @@
> >>>>>>> +lwl-y += lowlevel.o
> >>>>>>> diff --git a/arch/arm/mach-spider/lowlevel.c b/arch/arm/mach-
> >>>>>> spider/lowlevel.c new file mode 100644 index
> >>>>>> 000000000000..5d62ef0f39e5
> >>>>>>> --- /dev/null
> >>>>>>> +++ b/arch/arm/mach-spider/lowlevel.c
> >>>>>>> @@ -0,0 +1,14 @@
> >>>>>>> +// SPDX-License-Identifier: GPL-2.0+
> >>>>>>> +
> >>>>>>> +#include <linux/types.h>
> >>>>>>> +#include <mach/spider/lowlevel.h>
> >>>>>>> +#include <asm/barebox-arm-head.h>
> >>>>>>> +
> >>>>>>> +void spider_lowlevel_init(void)
> >>>>>>> +{
> >>>>>>> + arm_cpu_lowlevel_init();
> >>>>>>> + /*
> >>>>>>> + * not yet relocated, only do writel/readl for stuff that's
> >>>>>>> + * critical to run early. No global variables allowed.
> >>>>>>> + */
> >>>>>>> +}
> >>>>>>> diff --git a/images/Makefile b/images/Makefile index
> >>>>>> c93f9e268978..97521e713228 100644
> >>>>>>> --- a/images/Makefile
> >>>>>>> +++ b/images/Makefile
> >>>>>>> @@ -150,6 +150,7 @@ include $(srctree)/images/Makefile.mxs
> >> include
> >>>>>> $(srctree)/images/Makefile.omap3 include
> >>>>>> $(srctree)/images/Makefile.rockchip
> >>>>>>> include $(srctree)/images/Makefile.socfpga
> >>>>>>> +include $(srctree)/images/Makefile.spider
> >>>>>>> include $(srctree)/images/Makefile.stm32mp
> >>>>>>> include $(srctree)/images/Makefile.tegra include
> >>>>>> $(srctree)/images/Makefile.versatile
> >>>>>>> diff --git a/images/Makefile.spider b/images/Makefile.spider new file
> >>>> mode
> >>>>>> 100644 index 000000000000..c32f2762df04
> >>>>>>> --- /dev/null
> >>>>>>> +++ b/images/Makefile.spider
> >>>>>>> @@ -0,0 +1,5 @@
> >>>>>>> +# SPDX-License-Identifier: GPL-2.0-only
> >>>>>>> +
> >>>>>>> +pblb-$(CONFIG_MACH_SPIDER_MK1_EVK) +=
> start_spider_mk1_evk
> >>>>>>> +FILE_barebox-spider-mk1-evk.img = start_spider_mk1_evk.pblb
> >>>>>>> +image-$(CONFIG_MACH_SPIDER_MK1_EVK) += barebox-spider-
> mk1-
> >>>>>> evk.img
> >>>>>>> diff --git a/include/mach/spider/lowlevel.h
> >>>>>> b/include/mach/spider/lowlevel.h new file mode 100644 index
> >>>>>> 000000000000..6e0ce1c77f7e
> >>>>>>> --- /dev/null
> >>>>>>> +++ b/include/mach/spider/lowlevel.h
> >>>>>>> @@ -0,0 +1,7 @@
> >>>>>>> +/* SPDX-License-Identifier: GPL-2.0+ */ #ifndef __MACH_SPIDER_H_
> >>>>>>> +#define __MACH_SPIDER_H_
> >>>>>>> +
> >>>>>>> +void spider_lowlevel_init(void);
> >>>>>>> +
> >>>>>>> +#endif
> >>>>>>> --
> >>>>>>> 2.38.4
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> Pengutronix e.K. | |
> >>>>>> Steuerwalder Str. 21 | http://www.pengutronix.de/ |
> >>>>>> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0
> |
> >>>>>> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-
> 5555
> >> |
> >>>>>
> >>>>
> >>>> --
> >>>> Pengutronix e.K. | |
> >>>> Steuerwalder Str. 21 | http://www.pengutronix.de/ |
> >>>> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
> >>>> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555
> |
> >>>
> >>
> >> --
> >> Pengutronix e.K. | |
> >> Steuerwalder Str. 21 | http://www.pengutronix.de/ |
> >> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
> >> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
> >
>
> --
> Pengutronix e.K. | |
> Steuerwalder Str. 21 | http://www.pengutronix.de/ |
> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [PATCH v2] Porting barebox to a new SoC
2023-06-01 8:54 ` Lior Weintraub
@ 2023-06-01 9:29 ` Ahmad Fatoum
2023-06-01 11:45 ` Lior Weintraub
0 siblings, 1 reply; 40+ messages in thread
From: Ahmad Fatoum @ 2023-06-01 9:29 UTC (permalink / raw)
To: Lior Weintraub, Ahmad Fatoum, barebox
Hello Lior,
On 01.06.23 10:54, Lior Weintraub wrote:
> Hi Ahmad,
>
> Thanks again for your great support and the patch.
> I've checked it and it works perfectly!
> The UART issue was solved after fixing the device tree per your recommendations.
> Now I can write into barbox terminal :-)
Nice!
> When I type "cpuinfo" on the terminal I am getting:
> implementer: ARM
> architecture: v8
> core: Cortex-A53 r0p4
> exception level: 3
> cache: no cache
> Control register: P D Z DT IT U XP
FYI, barebox next (or maybe master?) branch adds mmuinfo command to arm64.
You can use that to check if a specific address is cached or not.
> Notice that it say "no cache".
> I tried to add cache to cpu0 but it didn't help.
>
> .
> .
> d-cache-size = <0x8000>;
> d-cache-line-size = <64>;
> d-cache-sets = <128>; // 32KiB(size)/64(line-size)=512ways/4-way set
> i-cache-size = <0x8000>;
> i-cache-line-size = <64>;
> i-cache-sets = <256>; // 32KiB(size)/64(line-size)=512ways/2-way set
> next-level-cache = <&l2>;
> };
>
> l2: l2-cache0 {
> compatible = "cache";
> cache-unified;
> cache-size = <0x80000>;
> cache-line-size = <64>;
> cache-sets = <512>; // 512KiB(size)/64(line-size)=8192ways/16-way set
> cache-level = <2>;
> }
barebox doesn't consume these nodes. What may be happening is that cpuinfo
was written with the assumption that barebox executes at EL2 or EL1, so
executing it at EL3 may end up accessing the wrong MSRs. Feel free to send
a patch against arch/arm/cpu/cpuinfo.c, so it uses the correct register for
EL3. current_el() will tell you which EL you are at.
> Regarding Linux kernel:
> This would be the next step but I assume that it would be a bit more complicated.
Linux ARM64 Maintainers mandate that platforms implement the PSCI protocol.
In your case with single core that means providing reset and poweroff handlers
that the kernel can invoke via secure monitor call.
barebox can consume psci: CONFIG_ARM_PSCI_CLIENT, CONFIG_CMD_SMC, but what
you're missing is the provider side. barebox as PSCI provider is implemented
only for a single ARM32 SoC, the i.MX7. All supported ARM64 platforms use
TF-A as BL31 with the exception of Layerscape (which uses PPA, an NXP BL31
implementation).
What does this mean for you?
1) Either add your SoC to TF-A
2) Extend PSCI implementation in barebox for ARM64.
While I think it would be cool to have barebox provide all of BL2, BL31 and
BL32, I think you are better advised to use TF-A, because that's what most
other ARM Silicon Vendors use. That means less effort for you and easier
maintenance as you benefit from fixes done for other SoCs using the same
IPs. barebox certainly benefits from being able to focus on being a bootloader
and leaving the errata workarounds, GIC init stuff and runtime services
to TF-A.
The boot flow would then be:
- barebox PBL runs as BL2 in SRAM and sets up DRAM
- barebox PBL executes BL31 (TF-A) which was compiled into PBL
- TF-A installs secure monitor and returns control to DRAM in EL2
- barebox resumes execution in EL2 as BL33
- Linux is invoked in EL2 and can communicate with secure monitor.
You may find this talk interesting: https://fosdem.org/2023/schedule/event/uboot_psci/
Even if I disagree a bit with the takeaway.
> I guess we will have to integrate the interrupt controlled (GIC-600) into QEMU and into the device tree for it to work.
> Is that a valid assumption?
I never had to add a new SoC to Linux, so I can't give any better
suggestions than Yes. Where you're going, you'll need interrupts.
Godspeed and keep me posted :)
Ahmad
>
> Thanks,
> Lior.
>
>
>
>
>> -----Original Message-----
>> From: Ahmad Fatoum <a.fatoum@pengutronix.de>
>> Sent: Wednesday, May 31, 2023 8:55 PM
>> To: Lior Weintraub <liorw@pliops.com>; Ahmad Fatoum <ahmad@a3f.at>;
>> barebox@lists.infradead.org
>> Subject: Re: [PATCH v2] Porting barebox to a new SoC
>>
>> CAUTION: External Sender
>>
>> Hi Lior,
>>
>> On 31.05.23 18:13, Lior Weintraub wrote:
>>> Hi Ahmad,
>>>
>>> Using end of SRAM as PBL stack is currently not working because we need
>> 40bit address (0xC0_0020_0000).
>>> This needs a fix to ENTRY_FUNCTION_WITHSTACK macro.
>>
>> Ah, right. I just sent an (untested) patch. Would be cool if you could
>> try it out.
>>
>>> I tried just to change const u32 __stack_top = (stack_top); to const u64
>> __stack_top = (stack_top); but there were linking errors caused by:
>>> ASSERT(. - __pbl_board_stack_top <= 8, "Only One PBL per Image allowed")
>>
>> The easy way would have been using a __attribute__((naked)) function, but
>> those are only supported for arm32, not arm64. The alternative is thus
>> writing the entry point in assembly and to make board authors life easier
>> the linker script ensures that the stack setup entry point is invoked prior
>> to the board entry.
>>
>>> Regarding the arm timer:
>>> Adding the timer entry to DT solved the issue.
>>>
>>> Regarding the UART:
>>> Indeed CONFIG_SERIAL_AMBA_PL011 was set on spider_defconfig (also
>> verified it generated the correct entry on .config).
>>> I also noticed that if I remove the putc_ll implementation there is no Tx at all
>> from Barebox.
>>
>> I've led you astray. Indeed:
>>
>>>>> of_platform_bus_create() - skipping /soc, no compatible prop
>>
>> points at the issue.
>>
>> Try adding into /soc
>>
>> compatible = "simple,bus";
>> ranges;
>> dma-ranges;
>>
>> This matches /soc with the simple bus driver which just instantiates devices
>> for the
>> contained children. Those in turn should be matched by the drivers.
>>
>> The ranges stuff just tells that memory and SoC peripherals exist in the same
>> address space.
>>
>> When it probes you may need to describe the clock in the DT. Eventually, you
>> will
>> want to have a clock driver for your hardware (good news: barebox and Linux
>> have
>> basically the same API, so you only need to write it once). But for now, you
>> can
>> fake it using fixed-clock in the DT. Take a look at:
>>
>> snps,dw-apb-uart in arch/riscv/dts/jh7100.dtsi and compare with
>> dts/src/arm/imx28.dtsi
>> to see how to map that to PL011.
>>
>>> Could it be a hint?
>>
>> DEBUG_LL bridges the gap until a driver registers a console that's enabled. If
>> this
>> never happens, you are left with a non-interactive shell.
>>
>> Cheers,
>> Ahmad
>>
>>>
>>> Thanks,
>>> Lior.
>>>
>>>> -----Original Message-----
>>>> From: Ahmad Fatoum <a.fatoum@pengutronix.de>
>>>> Sent: Wednesday, May 31, 2023 11:40 AM
>>>> To: Lior Weintraub <liorw@pliops.com>; Ahmad Fatoum <ahmad@a3f.at>;
>>>> barebox@lists.infradead.org
>>>> Subject: Re: [PATCH v2] Porting barebox to a new SoC
>>>>
>>>> CAUTION: External Sender
>>>>
>>>> Hi Lior,
>>>>
>>>> On 31.05.23 10:05, Lior Weintraub wrote:
>>>>> Hi Ahmad,
>>>>>
>>>>> Thanks again for your prompt reply and accurate tips!
>>>>> Took the following changes:
>>>>> 1. Increasing the DRAM size to 128MB (let barebox start from 0).
>>>>> 2. Set PBL stack to offset 2MB from DRAM
>>>>
>>>> Just use end of SRAM, so you are completely independent of DRAM
>>>> until you call barebox_arm_entry.
>>>>
>>>>> 3. Fix the device tree "memory" entry to have 128MB.
>>>>
>>>> (y)
>>>>
>>>>> 4. Load barebox-spider-mk1-evk.img to SRAM and run from there.
>>>>>
>>>>> Now I can see the following logs:
>>>>> uncompress.c: memory at 0x00000000, size 0x08000000
>>>>> uncompress.c: uncompressing barebox binary at 0x000000c0000021c0
>>>> (size 0x0001e3a4) to 0x07e00000 (uncompressed size: 0x000390d0)
>>>>> uncompress.c: jumping to uncompressed image at
>> 0x0000000007e00000
>>>>> start.c: memory at 0x00000000, size 0x08000000
>>>>> start.c: found DTB in boarddata, copying to 0x07dffcc0
>>>>> start.c: initializing malloc pool at 0x079ffcc0 (size 0x00400000)
>>>>> start.c: starting barebox...
>>>>> initcall-> command_slice_init+0x0/0x3c
>>>>> initcall-> globalvar_init+0x0/0x80
>>>>> register_device: global
>>>>> register_device: nv
>>>>> initcall-> platform_init+0x0/0x1c
>>>>> register_device: platform
>>>>> initcall-> amba_bus_init+0x0/0x1c
>>>>> register_device: amba
>>>>> initcall-> spi_bus_init+0x0/0x1c
>>>>> register_device: spi
>>>>> initcall-> gpio_desc_alloc+0x0/0x24
>>>>> initcall-> fs_bus_init+0x0/0x1c
>>>>> register_device: fs
>>>>> initcall-> aarch64_init_vectors+0x0/0x50
>>>>> initcall-> gpio_gate_clock_driver_register+0x0/0x1c
>>>>> register_driver: gpio-gate-clock
>>>>> initcall-> of_arm_init+0x0/0x5c
>>>>> start.c: barebox_arm_boot_dtb: using barebox_boarddata
>>>>> using boarddata provided DTB
>>>>> adding DT alias:serial0: stem=serial id=0 node=/soc/serial@d000307000
>>>>> register_device: machine
>>>>> of_platform_bus_create() - skipping /chosen, no compatible prop
>>>>> of_platform_bus_create() - skipping /aliases, no compatible prop
>>>>> of_platform_bus_create() - skipping /cpus, no compatible prop
>>>>> of_platform_bus_create() - skipping /memory@0, no compatible prop
>>>>> of_platform_bus_create() - skipping /soc, no compatible prop
>>>>> initcall-> register_autoboot_vars+0x0/0x70
>>>>> initcall-> arm_arch_timer_driver_register+0x0/0x1c
>>>>> register_driver: arm-architected-timer
>>>>> initcall-> of_timer_init+0x0/0x20
>>>>> initcall-> init_fs+0x0/0x3c
>>>>> initcall-> pl011_driver_register+0x0/0x1c
>>>>> register_driver: uart-pl011
>>>>> initcall-> of_stdoutpath_init+0x0/0x28
>>>>> initcall-> of_probe_memory+0x0/0x60
>>>>> __request_region ok: 0x00000000:0x07ffffff flags=0x0
>>>>> initcall-> __bare_init_end+0x0/0x6c
>>>>> register_device: mem0
>>>>> initcall-> of_reserved_mem_walk+0x0/0x1ac
>>>>> initcall-> mem_malloc_resource+0x0/0xa8
>>>>> __request_region ok: 0x079ffcc0:0x07dffcbf flags=0x200
>>>>> __request_region ok: 0x07e00000:0x07e2aeff flags=0x200
>>>>> __request_region ok: 0x07e2af00:0x07e390cf flags=0x200
>>>>> __request_region ok: 0x07e390d0:0x07e3adaf flags=0x200
>>>>> initcall-> bootsource_init+0x0/0x40
>>>>> initcall-> ramfs_init+0x0/0x1c
>>>>> register_driver: ramfs
>>>>> initcall-> devfs_init+0x0/0x1c
>>>>> register_driver: devfs
>>>>> initcall-> arm_request_stack+0x0/0x398
>>>>> __request_region ok: 0x07ff0000:0x07ff7fff flags=0x200
>>>>> initcall-> mount_root+0x0/0x7c
>>>>> mount: none on / type ramfs, options=
>>>>> register_device: ramfs0
>>>>> probe-> ramfs0
>>>>> mount: none on /dev type devfs, options=
>>>>> register_device: devfs0
>>>>> probe-> devfs0
>>>>> initcall-> binfmt_sh_init+0x0/0x1c
>>>>> initcall-> binfmt_uimage_init+0x0/0x1c
>>>>> initcall-> console_common_init+0x0/0x48
>>>>> initcall-> of_kernel_init+0x0/0x28
>>>>> initcall-> console_ctrlc_init+0x0/0x30
>>>>> initcall-> mem_init+0x0/0x90
>>>>> register_device: mem1
>>>>> register_driver: mem
>>>>> probe-> mem0
>>>>> probe-> mem1
>>>>> initcall-> of_partition_init+0x0/0x48
>>>>> initcall-> prng_init+0x0/0x40
>>>>> initcall-> null_init+0x0/0x40
>>>>> initcall-> full_init+0x0/0x40
>>>>> initcall-> zero_init+0x0/0x40
>>>>> initcall-> spider_board_driver_register+0x0/0x1c
>>>>> register_driver: board-spider
>>>>> probe-> machine
>>>>> initcall-> barebox_memory_areas_init+0x0/0x40
>>>>> __request_region ok: 0x07dffcc0:0x07dfffce flags=0x200
>>>>> initcall-> barebox_of_populate+0x0/0x28
>>>>> initcall-> of_register_memory_fixup+0x0/0x20
>>>>> initcall-> dummy_csrc_warn+0x0/0x44
>>>>> WARNING: Warning: Using dummy clocksource
>>>>
>>>> Add a arm,armv8-timer node into your SoC device tree.
>>>> This lets barebox and Linux know that you have the ARM
>>>> architected timer available. Without that, you'll notice
>>>> that timeouts are wrong.
>>>>
>>>>> initcall-> bootm_init+0x0/0xf4
>>>>> initcall-> init_command_list+0x0/0x40
>>>>> register command bootm
>>>>> register command cat
>>>>> register command cd
>>>>> register command clear
>>>>> register command cp
>>>>> register command cpuinfo
>>>>> register command devinfo
>>>>> register command drvinfo
>>>>> register command echo
>>>>> register command exit
>>>>> register command false
>>>>> register command help
>>>>> register command ?
>>>>> register command ll
>>>>> register command ls
>>>>> register command md
>>>>> register command memcmp
>>>>> register command memcpy
>>>>> register command memset
>>>>> register command mkdir
>>>>> register command mount
>>>>> register command mw
>>>>> register command pwd
>>>>> register command rm
>>>>> register command rmdir
>>>>> register command setenv
>>>>> register command sh
>>>>> register command source
>>>>> register command .
>>>>> register command test
>>>>> register command [
>>>>> register command true
>>>>> register command :
>>>>> register command umount
>>>>> register command version
>>>>> initcall-> display_meminfo+0x0/0xa8
>>>>> barebox code: 0x7e00000 -> 0x7e2aeff
>>>>> bss segment: 0x7e390d0 -> 0x7e3adaf
>>>>> malloc space: 0x079ffcc0 -> 0x07dffcbf (size 4 MiB)
>>>>> initcall-> of_register_bootargs_fixup+0x0/0x3c
>>>>> initcall-> device_probe_deferred+0x0/0x14c
>>>>> initcall-> of_init_hostname+0x0/0x28
>>>>> initcall-> aarch64_register_image_handler+0x0/0x2c
>>>>> initcall-> load_environment+0x0/0x4c
>>>>> loading defaultenv
>>>>> environment load /dev/env0: No such file or directory
>>>>> Maybe you have to create the partition.
>>>>> initcalls done
>>>>>
>>>>> Hit any to stop autoboot: 0
>>>>> boot: No such file or directory
>>>>> barebox:/
>>>>>
>>>>>
>>>>> Few questions:
>>>>> 1. The serial input doesn't work. i.e. I cannot type anything hence cannot
>>>> interact with barebox terminal.
>>>>
>>>> DEBUG_LL only does otuput. For input, you will want to load the driver.
>>>> Do you have CONFIG_SERIAL_AMBA_PL011 enabled?
>>>>
>>>>> Does it require GIC and setting interrupts for it to work?
>>>>
>>>> No interrupts needed. barebox runs with interrupts disabled and
>> everything
>>>> is done cooperatively.
>>>>
>>>>> 2. What does "of_platform_bus_create() - skipping" means? Do I need to
>> fix
>>>> that?
>>>>
>>>> That's normal debugging output. Some device tree nodes are busses, which
>>>> have
>>>> children. These entries are skipped because they have no compatible. This is
>>>> expected. I'd suggest you remove your VERBOSED_DEBUG define, so you
>> are
>>>> not
>>>> spammed by too much debugging output.
>>>>
>>>>> 3. Looks like I am still missing some stuff (rootfs? Environment?
>> Mounting?
>>>> Partitions?)
>>>>
>>>> Take multi_v8_defconfig, open menuconfig and enable your SoC and use
>> that.
>>>> That will be quicker than enabling everything yourself. If it doesn't work
>>>> out of the box, try imx_v8_defconfig.
>>>>
>>>> Once you get around to upstreaming your SoC, I'd suggest you just add it
>>>> to multi_v8_defconfig. Not all ARMv8 SoCs are supported there, but those
>>>> that are make development easier, because we don't need to build as many
>>>> different configs..
>>>>
>>>> Cheers,
>>>> Ahmad
>>>>
>>>>>
>>>>> Thanks,
>>>>> Have a great day,
>>>>> Lior.
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Ahmad Fatoum <a.fatoum@pengutronix.de>
>>>>>> Sent: Wednesday, May 31, 2023 9:11 AM
>>>>>> To: Lior Weintraub <liorw@pliops.com>; Ahmad Fatoum
>> <ahmad@a3f.at>;
>>>>>> barebox@lists.infradead.org
>>>>>> Subject: Re: [PATCH v2] Porting barebox to a new SoC
>>>>>>
>>>>>> CAUTION: External Sender
>>>>>>
>>>>>> Hi Lior,
>>>>>>
>>>>>> On 30.05.23 22:10, Lior Weintraub wrote:
>>>>>>> Hello Ahmad,
>>>>>>>
>>>>>>> Thanks again for your kind support!
>>>>>>> Your comments helped me progress and the current situation is as
>>>> follows:
>>>>>>> Our QEMU Spider machine is running a BL1.elf file using the following
>>>>>> command:
>>>>>>> QEMU_AUDIO_DRV=none qemu-system-aarch64 -M spider-soc -smp 1
>> -
>>>> m
>>>>>> 128M -nographic \
>>>>>>> -device loader,file=BL1.elf -cpu cortex-a53,rvbar=0xC004000000 \
>>>>>>> -d unimp -semihosting-config enable=on,target=native \
>>>>>>> -monitor telnet:localhost:1235,server,nowait \
>>>>>>> -gdb tcp::1236
>>>>>>>
>>>>>>> The BL1.elf is our BootROM application that runs from ROM address
>>>>>> 0xC004000000.
>>>>>>> Just for debugging purpose we've increased the ROM size so it can
>> include
>>>>>> the images/barebox-spider-mk1-evk.img (as a const array).
>>>>>>> BL1 then copy it (using memcpy) to address 0 and jumps there for
>>>>>> execution.
>>>>>>
>>>>>> Sounds ok.
>>>>>>
>>>>>>> On the real ASIC this address will be the DRAM and indeed will need to
>> be
>>>>>> initialized before the copy but here on QEMU it is not required.
>>>>>>
>>>>>> I see. You could still have your bootrom move barebox into SRAM and
>> then
>>>>>>
>>>>>> barebox_arm_entry(DRAM_ADDR, SZ_128M,
>>>> __dtb_spider_mk1_evk_start);
>>>>>>
>>>>>> To have PBL extract barebox to DRAM. Even if you don't need need
>> DRAM
>>>>>> setup in QEMU, the flow would be similar to what you will have on actual
>>>>>> silicon.
>>>>>>
>>>>>>> The lowlevel.c of spider-evk was modified to use DRAM_ADDR
>> 0x400000
>>>>>> (4MB from start) and MY_STACK_TOP was set to 0x8000000 (128M).
>>>>>>
>>>>>> That's not needed. While you don't have control where barebox PBL will
>> be
>>>>>> located
>>>>>> (depends on BootROM), barebox will extract itself to the end of DRAM
>>>>>> without
>>>>>> overwriting itself, so you can just use DRAM_ADDR 0 normally.
>> Eventually,
>>>>>> stack
>>>>>> top should go into SRAM, but anywhere that works is ok.
>>>>>>
>>>>>>> In addition, I implemented putc_ll (currently hard-coded in
>>>>>> include/debug_ll.h) and opened log level to VERBOSE_DEBUG (currently
>>>> just
>>>>>> hard-coded in printk.h).
>>>>>>
>>>>>> There's CONFIG_DEBUG_PBL you can enable to get all these messages by
>>>>>> default.
>>>>>>
>>>>>>> I see the following (which makes sense) logs on QEMU terminal:
>>>>>>> uncompress.c: memory at 0x00400000, size 0x00200000
>>>>>>> uncompress.c: uncompressing barebox binary at
>> 0x0000000000002200
>>>>>> (size 0x0001d3b2) to 0x00400000 (uncompressed size: 0x000373d0)
>>>>>>
>>>>>> Why pass only 2M to barebox_arm_entry? While this need not be the
>>>> whole
>>>>>> of RAM, this
>>>>>> initial memory is what barebox will use for itself including its final stack
>> and
>>>>>> malloc area. barebox will also not place itself into the last 1M AFAIK, so
>> 2M
>>>>>> may not work ok. You should use the minimum possible RAM here or if
>> you
>>>>>> can detect
>>>>>> in PBL how much RAM you have or just the whole RAM bank. I am not
>> sure
>>>>>> anything lower
>>>>>> than SZ_4M would work ok. (Note this is DRAM size, not SRAM. barebox
>>>> PBL
>>>>>> is fine being
>>>>>> called from 64K SRAMs, it just needs DRAM to extract to).
>>>>>>
>>>>>>> I then connect with aarch64-none-elf-gdb, load the barebox symbols
>> (to
>>>>>> 0x400000) and check the current execution state (program counter and
>>>>>> stack).
>>>>>>> Looks like the code is stuck on function register_autoboot_vars:
>>>>>>> sp 0x5f7e60 0x5f7e60
>>>>>>> pc 0x401264 0x401264 <register_autoboot_vars+24>
>>>>>>>
>>>>>>> Few observations:
>>>>>>> 1. The PBL was using stack top located on 0x8000000 (which is
>>>>>> MY_STACK_TOP). Found it be causing a breakpoint on the PBL.
>>>>>>> 2. Barebox uses a stack top on 0x600000 which is probably calculated
>>>> from
>>>>>> my new DRAM_ADDR and SZ_2M given to the function call:
>>>>>>> barebox_arm_entry(DRAM_ADDR, SZ_2M,
>>>> __dtb_spider_mk1_evk_start);
>>>>>>>
>>>>>>> This is great! I am starting to find my way.
>>>>>>
>>>>>> :) Ye, the ENTRY_FUNCTION_WITHSTACK is only when the BootROM
>>>> doesn't
>>>>>> enter
>>>>>> with a valid stack pointer. It's overwritten as soon as barebox is told
>>>>>> about the initial memory layout (with barebox_arm_entry).
>>>>>>
>>>>>>> When the barebox execution didn't print anything to the terminal I
>>>>>> remembered that we used a place holder on the dtsi for the uart.
>>>>>>> So now I changed it to:
>>>>>>> uart0: serial@d000307000 {
>>>>>>> compatible = "arm,pl011", "arm,primecell";
>>>>>>> reg = <0xd0 0x307000 0 0x1000>;
>>>>>>> }
>>>>>>> (Our QEMU UART is currently using pl011 device.)
>>>>>>
>>>>>> Looks ok. Don't forget to enable the driver (via make menuconfig).
>>>>>>
>>>>>>> After some time (trying to debug by enabling MMU but then reverted
>> the
>>>>>> code back), I got to a point that when I try to run again I am getting an
>>>>>> exception.
>>>>>>> I can swear all code changes were reverted back to the point where I
>> saw
>>>> the
>>>>>> barebox stuck on register_autoboot_vars but now it just cases an
>>>> exception.
>>>>>>> The exception vector code is located on our ROM (part of BL1 code) and
>>>> the
>>>>>> logs shows that the link register has the value 0x401218 which suggest
>> the
>>>>>> following code:
>>>>>>> 0000000000001200 <load_environment>:
>>>>>>> 1200: a9be7bfd stp x29, x30, [sp, #-32]!
>>>>>>> 1204: 910003fd mov x29, sp
>>>>>>> 1208: a90153f3 stp x19, x20, [sp, #16]
>>>>>>> 120c: 94000a07 bl 3a28 <default_environment_path_get>
>>>>>>> 1210: d00000f3 adrp x19, 1f000 <do_cpuinfo+0x1f0>
>>>>>>> 1214: 912a7273 add x19, x19, #0xa9c
>>>>>>> 1218: aa0003f4 mov x20, x0
>>>>>>>
>>>>>>> Any ideas or suggestions how to proceed with the debugging?
>>>>>>
>>>>>> You shouldn't need to touch the MMU code. If your initial memory setup
>>>>>> is wonky, you may end up overwriting stuff. Try again with bigger
>> memory.
>>>>>>
>>>>>>> BTW, to answer your questions:
>>>>>>> The SRAM of 4MB is the only one we have because we assumed it is
>> only
>>>> for
>>>>>> BootROM to load a PBL
>>>>>>
>>>>>> Ok. Sometimes there are SRAMs for use with DMA. I asked, because a
>>>> SRAM
>>>>>> in the first 4M
>>>>>> would lend itself nicely as stack, but if there is none, we can adjust
>>>>>> ENTRY_FUNCTION_WITHSTACK to accept a 64-bit parameter.
>>>>>>
>>>>>> Cheers,
>>>>>> Ahmad
>>>>>>
>>>>>>> Thank you very much,
>>>>>>> Cheers,
>>>>>>> Lior.
>>>>>>>
>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Ahmad Fatoum <a.fatoum@pengutronix.de>
>>>>>>>> Sent: Monday, May 29, 2023 10:03 PM
>>>>>>>> To: Lior Weintraub <liorw@pliops.com>; Ahmad Fatoum
>>>> <ahmad@a3f.at>;
>>>>>>>> barebox@lists.infradead.org
>>>>>>>> Subject: Re: [PATCH v2] Porting barebox to a new SoC
>>>>>>>>
>>>>>>>> CAUTION: External Sender
>>>>>>>>
>>>>>>>> Hello Lior,
>>>>>>>>
>>>>>>>> On 29.05.23 15:34, Lior Weintraub wrote:
>>>>>>>>> Hi Ahmad,
>>>>>>>>>
>>>>>>>>> I have revised the addresses and used DRAM address @ 0 instead:
>>>>>>>>> #define UARTBASE (0xD000307000)
>>>>>>>>> #define DRAM_ADDR (0x00000000)
>>>>>>>>> #define MY_STACK_TOP (0x00000000 + SZ_2M) // Set the stack
>> 2MB
>>>>>> from
>>>>>>>> DRAM start
>>>>>>>>
>>>>>>>> Is DRAM configured by the time barebox runs? If not, you should keep
>>>>>> stack
>>>>>>>> top
>>>>>>>> in SRAM, until you have setup memory in prebootloader (PBL). Is the
>> 4M
>>>>>>>> SRAM
>>>>>>>> the only on-chip SRAM you have?
>>>>>>>>
>>>>>>>>> static inline void spider_serial_putc(void *base, int c)
>>>>>>>>> {
>>>>>>>>> *((volatile unsigned *)base) = c;
>>>>>>>>
>>>>>>>> There's a helper for that: writel(c, base); In barebox, it's equivalent
>>>>>>>> to the volatile access, but in Linux it involves a write memory barrier.
>>>>>>>> We try to write code in barebox, so it's easily reusable in Linux (and
>>>>>>>> the other way round).
>>>>>>>>
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> I will try to test it on QEMU using an initial QEMU machine we made
>> for
>>>>>>>> Spider.
>>>>>>>>> In this machine we only have 3 memory regions and a PL011 UART:
>>>>>>>>> spider_soc_memories soc_memories[] = {
>>>>>>>>> {.name = "SPIDER_GPRAM", .add = 0xC000000000ULL, .size = 4 *
>>>> MiB},
>>>>>>>>> {.name = "SPIDER_ROM", .add = 0xC004000000ULL, .size = 128 *
>>>>>> KiB},
>>>>>>>>> {.name = "SPIDER_DRAM", .add = 0x0000000000ULL, .size = 1 *
>>>> GiB},
>>>>>>>>> };
>>>>>>>>>
>>>>>>>>> This special QEMU machine can run our BL1 code from "ROM"
>> address
>>>>>> (we
>>>>>>>> set the RVBAR to point there).
>>>>>>>>> So my idea is to test the barebox image by the following steps:
>>>>>>>>> 1. Modify the QEMU code to have a "ROM" with the size of 128M.
>>>>>>>>> 2. Compile our BL1 code to include the barebox.bin as a const array,
>>>> copy
>>>>>> it
>>>>>>>> to "DRAM" @ address 0 and jump there.
>>>>>>>>
>>>>>>>> Why not map QEMU -bios option to SRAM? (Or DRAM directly, if it
>>>> needs
>>>>>> no
>>>>>>>> special setup from
>>>>>>>> barebox side).
>>>>>>>>
>>>>>>>>> For this to work I wanted to understand how to call (i.e. what
>>>> arguments
>>>>>> to
>>>>>>>> pass) to barebox.
>>>>>>>>
>>>>>>>> barebox doesn't expect any arguments, because most BootROMs
>> don't
>>>>>> pass
>>>>>>>> anything useful.
>>>>>>>> Some pass information about bootsource though, so that's why the
>>>>>>>> ENTRY_FUNCTION has
>>>>>>>> r0, r1 and r2 as parameters, but you need not use them.
>>>>>>>>
>>>>>>>>> So I checked the barebox.map and found the function "start" on
>>>> address
>>>>>> 0.
>>>>>>>>
>>>>>>>> You may know that Linux on some platforms comes with a
>> decompressor
>>>>>> that
>>>>>>>> is glued to the
>>>>>>>> front of the kernel image and extracts the compressed kernel image.
>>>>>> barebox
>>>>>>>> has the same
>>>>>>>> concept. The prebootloader is uncompressed and runs (starting from
>>>>>>>> ENTRY_FUNCTION) and
>>>>>>>> then does some early setup (e.g. enable clocks, configure PMIC, setup
>>>>>> DRAM,
>>>>>>>> load secure
>>>>>>>> monitor (BL31), ...etc.) and then it decompresses barebox proper into
>>>>>> DRAM.
>>>>>>>>
>>>>>>>> barebox.bin <- barebox proper. You don't usually need that.
>>>>>>>> barebox.elf <- ELF binary for the above (for gdb)
>>>>>>>> barebox.map <- map file of the above
>>>>>>>>
>>>>>>>> images/barebox-spider-mk1-evk.img <- complete barebox image (PBL
>> +
>>>>>>>> barebox proper)
>>>>>>>> images/start_spider_mk1_evk.pbl <- ELF image for the above
>>>>>>>> images/start_spider_mk1_evk.pbl.map <- map file of the above
>>>>>>>>
>>>>>>>> If you want to follow barbeox from the start, begin at
>>>>>> start_spider_mk1_evk.
>>>>>>>>
>>>>>>>>> Then I went to arch/arm/cpu/start.c and realized that the code is
>>>> compiled
>>>>>>>> with CONFIG_PBL_IMAGE.
>>>>>>>>> In that case I assume I need to pass 3 arguments and use this
>> function
>>>>>>>> prototype:
>>>>>>>>> void start(unsigned long membase, unsigned long memsize, void
>>>>>>>> *boarddata);
>>>>>>>>
>>>>>>>> barebox prebootloader takes care of this, so you don't need to do
>>>> anything.
>>>>>>>>
>>>>>>>>> Few questions:
>>>>>>>>> 1. Will that call work:
>>>>>>>>> typedef void (*barebox_start)(unsigned long , unsigned long , void
>> *);
>>>>>>>>> #define DRAM_START (0)
>>>>>>>>> barebox_start p_barebox = (barebox_start)DRAM_START;
>>>>>>>>> p_barebox(DRAM_START, DRAM_START+SZ_2M, (void
>>>>>>>> *)(DRAM_START+SZ_4M));
>>>>>>>>> This assumes that my BL1 code also copied the device tree
>> (barebox-
>>>> dt-
>>>>>>>> 2nd.img? start_dt_2nd.pblb? start_spider_mk1_evk.pblb?)
>>>>>>>>
>>>>>>>> The device tree is built into the PBL and passed to barebox proper. This
>>>>>>>> allows us to use the same barebox proper binary and link it with a
>>>> different
>>>>>>>> prebootloader for each SoC/board, all in the same build.
>>>>>>>>
>>>>>>>> barebox-dt-2nd.img is a special image that looks exactly like a Linux
>>>> kernel:
>>>>>>>>
>>>>>>>> images/barebox-dt-2nd.img: Linux kernel ARM64 boot executable
>>>> Image,
>>>>>>>> little-endian, 4K pages
>>>>>>>>
>>>>>>>> and can thus be used for booting for easy chainloading from other
>>>>>>>> bootloaders or for running
>>>>>>>> with QEMU -kernel. You shouldn't need it right now.
>>>>>>>>
>>>>>>>>> 2. Do I want to have my code compiled with CONFIG_PBL_IMAGE?
>>>>>>>>> If I understand correctly, it means that my code will provide a PBL
>>>> (a.k.a
>>>>>>>> BL2) which will set the DRAM and STACK among other things (MMU?).
>>>>>>>>
>>>>>>>> The patch I sent already builds a PBL. You will need to fill out
>>>>>>>> start_spider_mk1_evk
>>>>>>>> to do all the other early initialization you need. Then you call
>>>>>>>> barebox_arm_entry
>>>>>>>> with device tree and memory size and it will take care to do stack setup
>> in
>>>>>> new
>>>>>>>> memory region, MMU setup (if enabled) and chainloading barebox
>>>> proper.
>>>>>>>>
>>>>>>>> Note that PBL isn't necessary BL2. You can chainload barebox from
>> within
>>>>>>>> barebox (i.e.
>>>>>>>> in EL2 or EL1), which is useful for debugging. You will thus often find
>> PBL
>>>>>> code
>>>>>>>> that
>>>>>>>> does
>>>>>>>>
>>>>>>>> if (current_el() == 3) {
>>>>>>>> /* Do BL2 setup */
>>>>>>>> chainload();
>>>>>>>> __builtin_unreachable();
>>>>>>>> }
>>>>>>>>
>>>>>>>> barebox_arm_entry(...)
>>>>>>>>
>>>>>>>> See for example arch/arm/boards/innocomm-imx8mm-
>> wb15/lowlevel.c
>>>>>>>>
>>>>>>>> to see a real-world example of another Cortex-A53.
>>>>>>>>
>>>>>>>>> In that case I assume it is OK.
>>>>>>>>> 3. If I try to remove it by having CONFIG_PBL_IMAGE=n on
>>>>>> spider_defconfig
>>>>>>>> this doesn't do anything
>>>>>>>>> The build (make spider_defconfig) ignores it and say that " No
>> change
>>>> to
>>>>>>>> .config ".
>>>>>>>>
>>>>>>>> Another symbol forces it to be enabled. If you are curious, run make
>>>>>>>> menuconfig
>>>>>>>> and then search (/) for the symbol and it will list, whether it's enabled
>>>> and
>>>>>>>> why:
>>>>>>>>
>>>>>>>> Selected by [y]:
>>>>>>>> - PBL_MULTI_IMAGES [=y] && HAVE_PBL_MULTI_IMAGES [=y]
>>>>>>>>
>>>>>>>> I'd suggest you avoid modifying the .config file manually. always use
>>>>>>>> menuconfig.
>>>>>>>>
>>>>>>>>> 4. I also tried to understand how to implement PUTC_LL but not sure
>> I
>>>>>>>> understand.
>>>>>>>>> 4.1 When I set "CONFIG_DEBUG_LL=y" on spider_defconfig it is
>> again
>>>>>> not
>>>>>>>> written to .config and I get " No change to .config " message.
>>>>>>>>
>>>>>>>> You must:
>>>>>>>>
>>>>>>>> - select HAS_DEBUG_LL from MACH_SPIDER
>>>>>>>> - Add your arch to arch/arm/include/asm/debug_ll.h
>>>>>>>> - Then implement PUTC_LL in e.g. mach/spider/debug_ll.h
>>>>>>>>
>>>>>>>>> 4.2 Do I need to have my own debug_ll.h file?
>>>>>>>>
>>>>>>>> Yes. See above.
>>>>>>>>
>>>>>>>>> 5. When I make changes to spider_defconfig and try to regenerate
>> the
>>>>>>>> .config and I get " No change to .config " message, does it mean that
>>>> those
>>>>>>>> macros are "hidden" symbols like you said about the
>> CONFIG_CPU_V8?
>>>>>>>>
>>>>>>>> Yes. Just check menuconfig to see how symbols relate to each other.
>>>>>>>> This is 1:1 like it's in Linux, so it'll come in handy when you do
>>>>>>>> the kernel port too ;)
>>>>>>>>
>>>>>>>>> Apologize for so many questions :-)
>>>>>>>>
>>>>>>>> No problem. Looking forward to your patches ;)
>>>>>>>>
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Ahmad
>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>> Lior.
>>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Lior Weintraub
>>>>>>>>> Sent: Sunday, May 28, 2023 11:16 PM
>>>>>>>>> To: Ahmad Fatoum <ahmad@a3f.at>; barebox@lists.infradead.org
>>>>>>>>> Subject: RE: [PATCH v2] Porting barebox to a new SoC
>>>>>>>>>
>>>>>>>>> Hi Ahmad,
>>>>>>>>>
>>>>>>>>> Thank you so much for your kind support!
>>>>>>>>>
>>>>>>>>> Indeed we also have a 16GB DRAM that starts from address 0
>> (though
>>>>>>>> currently we don't have the controller settings (under development)).
>>>>>>>>>
>>>>>>>>> I also wrote the BootROM (BL1) for this SoC (128KB ROM @ address
>>>>>>>> 0xC004000000).
>>>>>>>>> I understand now that it would be best for me to develop BL2 that
>> will
>>>> run
>>>>>>>> from our SRAM.
>>>>>>>>>
>>>>>>>>> As this BL2 code is bare-metal I have no problem or limitations with
>> the
>>>> 40
>>>>>>>> bit addresses.
>>>>>>>>> The BL2 code will initialize the DRAM controller and then copy
>> Barebox
>>>>>> image
>>>>>>>> from NOR Flash to address 0 of the DRAM.
>>>>>>>>> Our NOR Flash is 128MB in size and it is accessed via QSPI controller.
>>>>>>>>>
>>>>>>>>> I tried applying your suggested patch but got an error while doing so:
>>>>>>>>> $git apply 0002-Ahmad.patch
>>>>>>>>> 0002-Ahmad.patch:115: trailing whitespace.
>>>>>>>>> .of_compatible = spider_board_of_match, };
>>>>>>>>> error: corrupt patch at line 117
>>>>>>>>>
>>>>>>>>> After some digging I found that my Outlook probably messed with
>> the
>>>>>> patch
>>>>>>>> format (even though I am using text only and no HTML format).
>>>>>>>>> When I went to the web and copied the patch from there (mailing list
>>>>>>>> archive) it was working well (i.e. no compilation error).
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>> Lior.
>>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Ahmad Fatoum <ahmad@a3f.at>
>>>>>>>>> Sent: Sunday, May 28, 2023 6:38 PM
>>>>>>>>> To: barebox@lists.infradead.org
>>>>>>>>> Cc: Lior Weintraub <liorw@pliops.com>
>>>>>>>>> Subject: [PATCH v2] Porting barebox to a new SoC
>>>>>>>>>
>>>>>>>>> CAUTION: External Sender
>>>>>>>>>
>>>>>>>>> From: Lior Weintraub <liorw@pliops.com>
>>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> I tried to follow the porting guide on https://ddec1-0-en-
>>>>>>>>
>>>>>>
>>>>
>> ctp.trendmicro.com:443/wis/clicktime/v1/query?url=https%3a%2f%2fwww.
>>>>>>>>
>>>>>>
>>>>
>> barebox.org%2fdoc%2flatest%2fdevel%2fporting.html%23&umid=60097eda
>>>>>>>> -f136-45a1-9c8e-
>>>>>>>>
>> cf6a76e45cf8&auth=860a7ebb9feba264acc79b6e38eb59582349362c-
>>>>>>>> 480ae23736add41c88ab8d30c090a75517ca7f9e but couldn't follow
>>>> the
>>>>>>>> instructions.
>>>>>>>>> I would like to port barebox to a new SoC (which is not a derivative of
>>>> any
>>>>>>>> known SoC).
>>>>>>>>> It has the following:
>>>>>>>>> * Single Cortex A53
>>>>>>>>> * SRAM (4MB) located on address 0xC000000000
>>>>>>>>>
>>>>>>>>> The below patch shows my initial test to try and have a starting point.
>>>>>>>>> I am setting env variables:
>>>>>>>>> export ARCH=arm64
>>>>>>>>> export CROSS_COMPILE=/home/pliops/workspace/ARM/arm-gnu-
>>>>>>>> toolchain/bin/aarch64-none-elf-
>>>>>>>>>
>>>>>>>>> Then I build with:
>>>>>>>>> make spider_defconfig && make
>>>>>>>>>
>>>>>>>>> This gives an error:
>>>>>>>>> aarch64-none-elf-gcc: error: unrecognized argument in option '-
>>>>>> mabi=apcs-
>>>>>>>> gnu'
>>>>>>>>> aarch64-none-elf-gcc: note: valid arguments to '-mabi=' are: ilp32
>> lp64
>>>>>>>>> aarch64-none-elf-gcc: error: unrecognized command-line option '-
>>>> msoft-
>>>>>>>> float'
>>>>>>>>> aarch64-none-elf-gcc: error: unrecognized command-line option '-
>> mno-
>>>>>>>> unaligned-access'
>>>>>>>>> /home/pliops/workspace/simplest-linux-
>>>>>>>> demo/barebox/scripts/Makefile.build:140: recipe for target
>>>>>>>> 'scripts/mod/empty.o' failed
>>>>>>>>> make[2]: *** [scripts/mod/empty.o] Error 1
>>>>>>>>>
>>>>>>>>> Not sure why the compiler flags get -mabi=apcs-gnu when I explicitly
>> set
>>>>>>>> CONFIG_CPU_V8 and the arch/arm/Makefile has:
>>>>>>>>> ifeq ($(CONFIG_CPU_V8), y)
>>>>>>>>> CFLAGS_ABI :=-mabi=lp64
>>>>>>>>>
>>>>>>>>> The changes I did:
>>>>>>>>> >From 848b5f9b18bb1bb96d197cbc1b368ee0a729d581 Mon Sep
>> 17
>>>>>>>> 00:00:00 2001
>>>>>>>>> ---
>>>>>>>>> arch/arm/Kconfig | 13 ++++++++
>>>>>>>>> arch/arm/Makefile | 1 +
>>>>>>>>> arch/arm/boards/Makefile | 1 +
>>>>>>>>> arch/arm/boards/spider-evk/Makefile | 4 +++
>>>>>>>>> arch/arm/boards/spider-evk/board.c | 26 +++++++++++++++
>>>>>>>>> arch/arm/boards/spider-evk/lowlevel.c | 30 +++++++++++++++++
>>>>>>>>> arch/arm/configs/spider_defconfig | 8 +++++
>>>>>>>>> arch/arm/dts/Makefile | 1 +
>>>>>>>>> arch/arm/dts/spider-mk1-evk.dts | 10 ++++++
>>>>>>>>> arch/arm/dts/spider-mk1.dtsi | 46
>>>> +++++++++++++++++++++++++++
>>>>>>>>> arch/arm/mach-spider/Kconfig | 16 ++++++++++
>>>>>>>>> arch/arm/mach-spider/Makefile | 1 +
>>>>>>>>> arch/arm/mach-spider/lowlevel.c | 14 ++++++++
>>>>>>>>> images/Makefile | 1 +
>>>>>>>>> images/Makefile.spider | 5 +++
>>>>>>>>> include/mach/spider/lowlevel.h | 7 ++++
>>>>>>>>> 16 files changed, 184 insertions(+)
>>>>>>>>> create mode 100644 arch/arm/boards/spider-evk/Makefile
>>>>>>>>> create mode 100644 arch/arm/boards/spider-evk/board.c
>>>>>>>>> create mode 100644 arch/arm/boards/spider-evk/lowlevel.c
>>>>>>>>> create mode 100644 arch/arm/configs/spider_defconfig create
>> mode
>>>>>>>> 100644 arch/arm/dts/spider-mk1-evk.dts create mode 100644
>>>>>>>> arch/arm/dts/spider-mk1.dtsi create mode 100644 arch/arm/mach-
>>>>>>>> spider/Kconfig create mode 100644 arch/arm/mach-spider/Makefile
>>>>>> create
>>>>>>>> mode 100644 arch/arm/mach-spider/lowlevel.c create mode 100644
>>>>>>>> images/Makefile.spider create mode 100644
>>>>>> include/mach/spider/lowlevel.h
>>>>>>>>>
>>>>>>>>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index
>>>>>>>> e76ee0f6dfe1..e5dcf128447e 100644
>>>>>>>>> --- a/arch/arm/Kconfig
>>>>>>>>> +++ b/arch/arm/Kconfig
>>>>>>>>> @@ -255,6 +255,18 @@ config ARCH_ROCKCHIP
>>>>>>>>> select HAS_DEBUG_LL
>>>>>>>>> imply GPIO_ROCKCHIP
>>>>>>>>>
>>>>>>>>> +config ARCH_SPIDER
>>>>>>>>> + bool "Pliops Spider based"
>>>>>>>>> + depends on 64BIT
>>>>>>>>> + depends on ARCH_MULTIARCH
>>>>>>>>> + select GPIOLIB
>>>>>>>>> + select HAVE_PBL_MULTI_IMAGES
>>>>>>>>> + select COMMON_CLK
>>>>>>>>> + select CLKDEV_LOOKUP
>>>>>>>>> + select COMMON_CLK_OF_PROVIDER
>>>>>>>>> + select OFTREE
>>>>>>>>> + select OFDEVICE
>>>>>>>>> +
>>>>>>>>> config ARCH_STM32MP
>>>>>>>>> bool "STMicroelectronics STM32MP"
>>>>>>>>> depends on 32BIT
>>>>>>>>> @@ -331,6 +343,7 @@ source "arch/arm/mach-omap/Kconfig"
>>>>>>>>> source "arch/arm/mach-pxa/Kconfig"
>>>>>>>>> source "arch/arm/mach-rockchip/Kconfig"
>>>>>>>>> source "arch/arm/mach-socfpga/Kconfig"
>>>>>>>>> +source "arch/arm/mach-spider/Kconfig"
>>>>>>>>> source "arch/arm/mach-stm32mp/Kconfig"
>>>>>>>>> source "arch/arm/mach-versatile/Kconfig"
>>>>>>>>> source "arch/arm/mach-vexpress/Kconfig"
>>>>>>>>> diff --git a/arch/arm/Makefile b/arch/arm/Makefile index
>>>>>>>> 35ebc70f44e2..4c63dfee48f4 100644
>>>>>>>>> --- a/arch/arm/Makefile
>>>>>>>>> +++ b/arch/arm/Makefile
>>>>>>>>> @@ -101,6 +101,7 @@ machine-$(CONFIG_ARCH_MXS) += mxs
>>>>>>>>> machine-$(CONFIG_ARCH_MVEBU) += mvebu
>>>>>>>>> machine-$(CONFIG_ARCH_NOMADIK) += nomadik
>>>>>>>>> machine-$(CONFIG_ARCH_OMAP) += omap
>>>>>>>>> +machine-$(CONFIG_ARCH_SPIDER) += spider
>>>>>>>>> machine-$(CONFIG_ARCH_PXA) += pxa
>>>>>>>>> machine-$(CONFIG_ARCH_ROCKCHIP) += rockchip
>>>>>>>>> machine-$(CONFIG_ARCH_SAMSUNG) += samsung
>>>>>>>>> diff --git a/arch/arm/boards/Makefile b/arch/arm/boards/Makefile
>>>> index
>>>>>>>> 2877debad535..6fe0a90c81ea 100644
>>>>>>>>> --- a/arch/arm/boards/Makefile
>>>>>>>>> +++ b/arch/arm/boards/Makefile
>>>>>>>>> @@ -135,6 +135,7 @@ obj-
>>>>>>>> $(CONFIG_MACH_SOCFPGA_TERASIC_DE10_NANO) += terasic-
>>>> de10-
>>>>>>>> nano/
>>>>>>>>> obj-$(CONFIG_MACH_SOCFPGA_TERASIC_SOCKIT) += terasic-
>>>> sockit/
>>>>>>>>> obj-$(CONFIG_MACH_SOLIDRUN_CUBOX) += solidrun-cubox/
>>>>>>>>> obj-$(CONFIG_MACH_SOLIDRUN_MICROSOM) += solidrun-
>>>>>>>> microsom/
>>>>>>>>> +obj-$(CONFIG_MACH_SPIDER_MK1_EVK) += spider-evk/
>>>>>>>>> obj-$(CONFIG_MACH_STM32MP15XX_DKX) +=
>> stm32mp15xx-
>>>>>> dkx/
>>>>>>>>> obj-$(CONFIG_MACH_STM32MP13XX_DK) += stm32mp13xx-
>>>> dk/
>>>>>>>>> obj-$(CONFIG_MACH_LXA_MC1) += lxa-mc1/
>>>>>>>>> diff --git a/arch/arm/boards/spider-evk/Makefile
>>>>>>>> b/arch/arm/boards/spider-evk/Makefile
>>>>>>>>> new file mode 100644
>>>>>>>>> index 000000000000..da63d2625f7a
>>>>>>>>> --- /dev/null
>>>>>>>>> +++ b/arch/arm/boards/spider-evk/Makefile
>>>>>>>>> @@ -0,0 +1,4 @@
>>>>>>>>> +# SPDX-License-Identifier: GPL-2.0-only
>>>>>>>>> +
>>>>>>>>> +obj-y += board.o
>>>>>>>>> +lwl-y += lowlevel.o
>>>>>>>>> diff --git a/arch/arm/boards/spider-evk/board.c
>>>>>> b/arch/arm/boards/spider-
>>>>>>>> evk/board.c
>>>>>>>>> new file mode 100644
>>>>>>>>> index 000000000000..3920e83b457d
>>>>>>>>> --- /dev/null
>>>>>>>>> +++ b/arch/arm/boards/spider-evk/board.c
>>>>>>>>> @@ -0,0 +1,26 @@
>>>>>>>>> +#include <bbu.h>
>>>>>>>>> +#include <boot.h>
>>>>>>>>> +#include <bootm.h>
>>>>>>>>> +#include <common.h>
>>>>>>>>> +#include <deep-probe.h>
>>>>>>>>> +#include <environment.h>
>>>>>>>>> +#include <fcntl.h>
>>>>>>>>> +#include <globalvar.h>
>>>>>>>>> +
>>>>>>>>> +static int spider_board_probe(struct device *dev) {
>>>>>>>>> + /* Do some board-specific setup */
>>>>>>>>> + return 0;
>>>>>>>>> +}
>>>>>>>>> +
>>>>>>>>> +static const struct of_device_id spider_board_of_match[] = {
>>>>>>>>> + { .compatible = "pliops,spider-mk1-evk" },
>>>>>>>>> + { /* sentinel */ },
>>>>>>>>> +};
>>>>>>>>> +
>>>>>>>>> +static struct driver spider_board_driver = {
>>>>>>>>> + .name = "board-spider",
>>>>>>>>> + .probe = spider_board_probe,
>>>>>>>>> + .of_compatible = spider_board_of_match, };
>>>>>>>>> +device_platform_driver(spider_board_driver);
>>>>>>>>> diff --git a/arch/arm/boards/spider-evk/lowlevel.c
>>>>>>>> b/arch/arm/boards/spider-evk/lowlevel.c
>>>>>>>>> new file mode 100644
>>>>>>>>> index 000000000000..e36fcde4208e
>>>>>>>>> --- /dev/null
>>>>>>>>> +++ b/arch/arm/boards/spider-evk/lowlevel.c
>>>>>>>>> @@ -0,0 +1,30 @@
>>>>>>>>> +#include <common.h>
>>>>>>>>> +#include <asm/barebox-arm.h>
>>>>>>>>> +#include <mach/spider/lowlevel.h>
>>>>>>>>> +
>>>>>>>>> +#define BASE_ADDR (0xD000307000)
>>>>>>>>> +#define GPRAM_ADDR (0xC000000000)
>>>>>>>>> +#define MY_STACK_TOP (0xC000000000 + SZ_2M) // Set the stack
>>>>>> 2MB
>>>>>>>> from GPRAM start (excatly in the middle)
>>>>>>>>> +static inline void spider_serial_putc(void *base, int c) {
>>>>>>>>> +// if (!(readl(base + UCR1) & UCR1_UARTEN))
>>>>>>>>> +// return;
>>>>>>>>> +//
>>>>>>>>> +// while (!(readl(base + USR2) & USR2_TXDC));
>>>>>>>>> +//
>>>>>>>>> +// writel(c, base + URTX0);
>>>>>>>>> +}
>>>>>>>>> +
>>>>>>>>> +ENTRY_FUNCTION_WITHSTACK(start_spider_mk1_evk,
>>>> MY_STACK_TOP,
>>>>>>>> r0, r1,
>>>>>>>>> +r2) {
>>>>>>>>> + extern char __dtb_spider_mk1_evk_start[];
>>>>>>>>> +
>>>>>>>>> + spider_lowlevel_init();
>>>>>>>>> +
>>>>>>>>> + relocate_to_current_adr();
>>>>>>>>> + setup_c();
>>>>>>>>> +
>>>>>>>>> + pbl_set_putc(spider_serial_putc, (void *)BASE_ADDR);
>>>>>>>>> +
>>>>>>>>> + barebox_arm_entry(GPRAM_ADDR, SZ_2M,
>>>>>>>>> +__dtb_spider_mk1_evk_start); }
>>>>>>>>> diff --git a/arch/arm/configs/spider_defconfig
>>>>>>>> b/arch/arm/configs/spider_defconfig
>>>>>>>>> new file mode 100644
>>>>>>>>> index 000000000000..c91bb889d97f
>>>>>>>>> --- /dev/null
>>>>>>>>> +++ b/arch/arm/configs/spider_defconfig
>>>>>>>>> @@ -0,0 +1,8 @@
>>>>>>>>> +CONFIG_ARCH_SPIDER=y
>>>>>>>>> +CONFIG_MACH_SPIDER_MK1_EVK=y
>>>>>>>>> +CONFIG_BOARD_ARM_GENERIC_DT=y
>>>>>>>>> +CONFIG_MALLOC_TLSF=y
>>>>>>>>> +CONFIG_KALLSYMS=y
>>>>>>>>> +CONFIG_RELOCATABLE=y
>>>>>>>>> +CONFIG_CONSOLE_ALLOW_COLOR=y
>>>>>>>>> +CONFIG_PBL_CONSOLE=y
>>>>>>>>> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile index
>>>>>>>> 98f4c4e0194b..94b304d4878f 100644
>>>>>>>>> --- a/arch/arm/dts/Makefile
>>>>>>>>> +++ b/arch/arm/dts/Makefile
>>>>>>>>> @@ -134,6 +134,7 @@ lwl-$(CONFIG_MACH_SOLIDRUN_CUBOX)
>> +=
>>>>>> dove-
>>>>>>>> cubox-bb.dtb.o
>>>>>>>>> lwl-$(CONFIG_MACH_SOLIDRUN_MICROSOM) += imx6dl-
>>>>>>>> hummingboard.dtb.o imx6q-hummingboard.dtb.o \
>>>>>>>>> imx6dl-hummingboard2.dtb.o imx6q-
>>>>>>>> hummingboard2.dtb.o \
>>>>>>>>> imx6q-h100.dtb.o
>>>>>>>>> +lwl-$(CONFIG_MACH_SPIDER_MK1_EVK) += spider-mk1-evk.dtb.o
>>>>>>>>> lwl-$(CONFIG_MACH_SKOV_IMX6) += imx6s-skov-imx6.dtb.o
>> imx6dl-
>>>>>> skov-
>>>>>>>> imx6.dtb.o imx6q-skov-imx6.dtb.o
>>>>>>>>> lwl-$(CONFIG_MACH_SKOV_ARM9CPU) += at91-skov-
>> arm9cpu.dtb.o
>>>>>>>>> lwl-$(CONFIG_MACH_SEEED_ODYSSEY) += stm32mp157c-
>>>> odyssey.dtb.o
>>>>>>>> diff --git a/arch/arm/dts/spider-mk1-evk.dts b/arch/arm/dts/spider-
>>>> mk1-
>>>>>>>> evk.dts new file mode 100644 index 000000000000..b8081cb85bf8
>>>>>>>>> --- /dev/null
>>>>>>>>> +++ b/arch/arm/dts/spider-mk1-evk.dts
>>>>>>>>> @@ -0,0 +1,10 @@
>>>>>>>>> +// SPDX-License-Identifier: GPL-2.0 OR X11
>>>>>>>>> +
>>>>>>>>> +/dts-v1/;
>>>>>>>>> +
>>>>>>>>> +#include "spider-mk1.dtsi"
>>>>>>>>> +
>>>>>>>>> +/ {
>>>>>>>>> + model = "Pliops Spider MK-I EVK";
>>>>>>>>> + compatible = "pliops,spider-mk1-evk"; };
>>>>>>>>> diff --git a/arch/arm/dts/spider-mk1.dtsi b/arch/arm/dts/spider-
>>>> mk1.dtsi
>>>>>>>> new file mode 100644 index 000000000000..d4613848169d
>>>>>>>>> --- /dev/null
>>>>>>>>> +++ b/arch/arm/dts/spider-mk1.dtsi
>>>>>>>>> @@ -0,0 +1,46 @@
>>>>>>>>> +// SPDX-License-Identifier: GPL-2.0 OR X11
>>>>>>>>> +
>>>>>>>>> +/ {
>>>>>>>>> + #address-cells = <2>;
>>>>>>>>> + #size-cells = <2>;
>>>>>>>>> +
>>>>>>>>> + chosen {
>>>>>>>>> + stdout-path = &uart0;
>>>>>>>>> + };
>>>>>>>>> +
>>>>>>>>> + aliases {
>>>>>>>>> + serial0 = &uart0;
>>>>>>>>> + };
>>>>>>>>> +
>>>>>>>>> + cpus {
>>>>>>>>> + #address-cells = <1>;
>>>>>>>>> + #size-cells = <0>;
>>>>>>>>> +
>>>>>>>>> + cpu0: cpu@0 {
>>>>>>>>> + device_type = "cpu";
>>>>>>>>> + compatible = "arm,cortex-a53";
>>>>>>>>> + reg = <0x0>;
>>>>>>>>> + };
>>>>>>>>> + };
>>>>>>>>> +
>>>>>>>>> + memory@1000000 {
>>>>>>>>> + reg = <0x0 0x1000000 0x0 0x400000>; /* 128M */
>>>>>>>>> + device_type = "memory";
>>>>>>>>> + };
>>>>>>>>> +
>>>>>>>>> + soc {
>>>>>>>>> + #address-cells = <2>;
>>>>>>>>> + #size-cells = <2>;
>>>>>>>>> + ranges;
>>>>>>>>> +
>>>>>>>>> + sram@c000000000 {
>>>>>>>>> + compatible = "mmio-sram";
>>>>>>>>> + reg = <0xc0 0x0 0x0 0x400000>;
>>>>>>>>> + };
>>>>>>>>> +
>>>>>>>>> + uart0: serial@d000307000 {
>>>>>>>>> + compatible = "pliops,spider-uart";
>>>>>>>>> + reg = <0xd0 0x307000 0 0x1000>;
>>>>>>>>> + };
>>>>>>>>> + };
>>>>>>>>> +};
>>>>>>>>> diff --git a/arch/arm/mach-spider/Kconfig b/arch/arm/mach-
>>>>>> spider/Kconfig
>>>>>>>> new file mode 100644 index 000000000000..6d2f888a5fd8
>>>>>>>>> --- /dev/null
>>>>>>>>> +++ b/arch/arm/mach-spider/Kconfig
>>>>>>>>> @@ -0,0 +1,16 @@
>>>>>>>>> +# SPDX-License-Identifier: GPL-2.0-only
>>>>>>>>> +
>>>>>>>>> +if ARCH_SPIDER
>>>>>>>>> +
>>>>>>>>> +config ARCH_SPIDER_MK1
>>>>>>>>> + bool
>>>>>>>>> + select CPU_V8
>>>>>>>>> + help
>>>>>>>>> + The first Cortex-A53-based SoC of the spider family.
>>>>>>>>> + This symbol is invisble and select by boards
>>>>>>>>> +
>>>>>>>>> +config MACH_SPIDER_MK1_EVK
>>>>>>>>> + bool "Pliops Spider Reference Design Board"
>>>>>>>>> + select ARCH_SPIDER_MK1
>>>>>>>>> +
>>>>>>>>> +endif
>>>>>>>>> diff --git a/arch/arm/mach-spider/Makefile b/arch/arm/mach-
>>>>>>>> spider/Makefile new file mode 100644 index
>>>>>> 000000000000..b08c4a93ca27
>>>>>>>>> --- /dev/null
>>>>>>>>> +++ b/arch/arm/mach-spider/Makefile
>>>>>>>>> @@ -0,0 +1 @@
>>>>>>>>> +lwl-y += lowlevel.o
>>>>>>>>> diff --git a/arch/arm/mach-spider/lowlevel.c b/arch/arm/mach-
>>>>>>>> spider/lowlevel.c new file mode 100644 index
>>>>>>>> 000000000000..5d62ef0f39e5
>>>>>>>>> --- /dev/null
>>>>>>>>> +++ b/arch/arm/mach-spider/lowlevel.c
>>>>>>>>> @@ -0,0 +1,14 @@
>>>>>>>>> +// SPDX-License-Identifier: GPL-2.0+
>>>>>>>>> +
>>>>>>>>> +#include <linux/types.h>
>>>>>>>>> +#include <mach/spider/lowlevel.h>
>>>>>>>>> +#include <asm/barebox-arm-head.h>
>>>>>>>>> +
>>>>>>>>> +void spider_lowlevel_init(void)
>>>>>>>>> +{
>>>>>>>>> + arm_cpu_lowlevel_init();
>>>>>>>>> + /*
>>>>>>>>> + * not yet relocated, only do writel/readl for stuff that's
>>>>>>>>> + * critical to run early. No global variables allowed.
>>>>>>>>> + */
>>>>>>>>> +}
>>>>>>>>> diff --git a/images/Makefile b/images/Makefile index
>>>>>>>> c93f9e268978..97521e713228 100644
>>>>>>>>> --- a/images/Makefile
>>>>>>>>> +++ b/images/Makefile
>>>>>>>>> @@ -150,6 +150,7 @@ include $(srctree)/images/Makefile.mxs
>>>> include
>>>>>>>> $(srctree)/images/Makefile.omap3 include
>>>>>>>> $(srctree)/images/Makefile.rockchip
>>>>>>>>> include $(srctree)/images/Makefile.socfpga
>>>>>>>>> +include $(srctree)/images/Makefile.spider
>>>>>>>>> include $(srctree)/images/Makefile.stm32mp
>>>>>>>>> include $(srctree)/images/Makefile.tegra include
>>>>>>>> $(srctree)/images/Makefile.versatile
>>>>>>>>> diff --git a/images/Makefile.spider b/images/Makefile.spider new file
>>>>>> mode
>>>>>>>> 100644 index 000000000000..c32f2762df04
>>>>>>>>> --- /dev/null
>>>>>>>>> +++ b/images/Makefile.spider
>>>>>>>>> @@ -0,0 +1,5 @@
>>>>>>>>> +# SPDX-License-Identifier: GPL-2.0-only
>>>>>>>>> +
>>>>>>>>> +pblb-$(CONFIG_MACH_SPIDER_MK1_EVK) +=
>> start_spider_mk1_evk
>>>>>>>>> +FILE_barebox-spider-mk1-evk.img = start_spider_mk1_evk.pblb
>>>>>>>>> +image-$(CONFIG_MACH_SPIDER_MK1_EVK) += barebox-spider-
>> mk1-
>>>>>>>> evk.img
>>>>>>>>> diff --git a/include/mach/spider/lowlevel.h
>>>>>>>> b/include/mach/spider/lowlevel.h new file mode 100644 index
>>>>>>>> 000000000000..6e0ce1c77f7e
>>>>>>>>> --- /dev/null
>>>>>>>>> +++ b/include/mach/spider/lowlevel.h
>>>>>>>>> @@ -0,0 +1,7 @@
>>>>>>>>> +/* SPDX-License-Identifier: GPL-2.0+ */ #ifndef __MACH_SPIDER_H_
>>>>>>>>> +#define __MACH_SPIDER_H_
>>>>>>>>> +
>>>>>>>>> +void spider_lowlevel_init(void);
>>>>>>>>> +
>>>>>>>>> +#endif
>>>>>>>>> --
>>>>>>>>> 2.38.4
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Pengutronix e.K. | |
>>>>>>>> Steuerwalder Str. 21 | http://www.pengutronix.de/ |
>>>>>>>> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0
>> |
>>>>>>>> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-
>> 5555
>>>> |
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Pengutronix e.K. | |
>>>>>> Steuerwalder Str. 21 | http://www.pengutronix.de/ |
>>>>>> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
>>>>>> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555
>> |
>>>>>
>>>>
>>>> --
>>>> Pengutronix e.K. | |
>>>> Steuerwalder Str. 21 | http://www.pengutronix.de/ |
>>>> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
>>>> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
>>>
>>
>> --
>> Pengutronix e.K. | |
>> Steuerwalder Str. 21 | http://www.pengutronix.de/ |
>> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
>> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
>
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply [flat|nested] 40+ messages in thread
* RE: [PATCH v2] Porting barebox to a new SoC
2023-06-01 9:29 ` Ahmad Fatoum
@ 2023-06-01 11:45 ` Lior Weintraub
2023-06-01 12:35 ` Ahmad Fatoum
0 siblings, 1 reply; 40+ messages in thread
From: Lior Weintraub @ 2023-06-01 11:45 UTC (permalink / raw)
To: Ahmad Fatoum, Ahmad Fatoum, barebox
Hello Ahmad,
Very interesting stuff.
We actually did started TF-A integration few months ago and tested it on the QEMU running ARM virt machine.
The TF-A compilation didn't include BL31 image (probably this explains the "ERROR: BL2: Failed to load image id 3").
For this code to run we used the following QEMU command:
qemu-system-aarch64 -nographic -machine virt,secure=on -cpu cortex-a53,rvbar=0x0000000000 \
-smp 1 -m 1024 -bios bl1.bin -d unimp -semihosting-config enable=on,target=native \
-monitor telnet:localhost:1235,server,nowait -gdb tcp::1236
Output:
NOTICE: bl1_early_platform_set
NOTICE: Booting Trusted Firmware
NOTICE: BL1: v2.7(debug):831de6588
NOTICE: BL1: Built : 12:40:08, May 28 2023
INFO: BL1: RAM 0xe0ee000 - 0xe0f6000
INFO: BL1: cortex_a53: CPU workaround for 835769 was applied
INFO: BL1: cortex_a53: CPU workaround for 843419 was applied
INFO: BL1: cortex_a53: CPU workaround for 855873 was applied
INFO: BL1: cortex_a53: CPU workaround for 1530924 was applied
INFO: BL1: Loading BL2
WARNING: Firmware Image Package header check failed.
INFO: Loading image id=1 at address 0xe07b000
INFO: Image id=1 loaded: 0xe07b000 - 0xe081201
NOTICE: BL1: Booting BL2
INFO: Entry point address = 0xe07b000
INFO: SPSR = 0x3c5
NOTICE: BL2: v2.7(debug):831de6588
NOTICE: BL2: Built : 12:40:08, May 28 2023
INFO: BL2: Doing platform setup
INFO: BL2: Loading image id 3
WARNING: Firmware Image Package header check failed.
WARNING: Failed to obtain reference to image id=3 (-2)
ERROR: BL2: Failed to load image id 3 (-2)
When we tried to modify the TF-A code to use our SoC (e.g. change the start address to 0xC0_0400_0000 and use UART on 0xD0_0030_7000) it crashed with seg. Fault.
We didn't continue with this development effort and decided we will write our own BootROM as BL1 and use that to load u-boot or barebox.
Now I understand we better go back and study how to port TF-A to our SoC.
Cheers,
Lior.
> -----Original Message-----
> From: Ahmad Fatoum <a.fatoum@pengutronix.de>
> Sent: Thursday, June 1, 2023 12:29 PM
> To: Lior Weintraub <liorw@pliops.com>; Ahmad Fatoum <ahmad@a3f.at>;
> barebox@lists.infradead.org
> Subject: Re: [PATCH v2] Porting barebox to a new SoC
>
> CAUTION: External Sender
>
> Hello Lior,
>
> On 01.06.23 10:54, Lior Weintraub wrote:
> > Hi Ahmad,
> >
> > Thanks again for your great support and the patch.
> > I've checked it and it works perfectly!
> > The UART issue was solved after fixing the device tree per your
> recommendations.
> > Now I can write into barbox terminal :-)
>
> Nice!
>
> > When I type "cpuinfo" on the terminal I am getting:
> > implementer: ARM
> > architecture: v8
> > core: Cortex-A53 r0p4
> > exception level: 3
> > cache: no cache
> > Control register: P D Z DT IT U XP
>
> FYI, barebox next (or maybe master?) branch adds mmuinfo command to
> arm64.
> You can use that to check if a specific address is cached or not.
>
> > Notice that it say "no cache".
> > I tried to add cache to cpu0 but it didn't help.
> >
> > .
> > .
> > d-cache-size = <0x8000>;
> > d-cache-line-size = <64>;
> > d-cache-sets = <128>; // 32KiB(size)/64(line-size)=512ways/4-way set
> > i-cache-size = <0x8000>;
> > i-cache-line-size = <64>;
> > i-cache-sets = <256>; // 32KiB(size)/64(line-size)=512ways/2-way set
> > next-level-cache = <&l2>;
> > };
> >
> > l2: l2-cache0 {
> > compatible = "cache";
> > cache-unified;
> > cache-size = <0x80000>;
> > cache-line-size = <64>;
> > cache-sets = <512>; // 512KiB(size)/64(line-size)=8192ways/16-way set
> > cache-level = <2>;
> > }
>
> barebox doesn't consume these nodes. What may be happening is that
> cpuinfo
> was written with the assumption that barebox executes at EL2 or EL1, so
> executing it at EL3 may end up accessing the wrong MSRs. Feel free to send
> a patch against arch/arm/cpu/cpuinfo.c, so it uses the correct register for
> EL3. current_el() will tell you which EL you are at.
>
> > Regarding Linux kernel:
> > This would be the next step but I assume that it would be a bit more
> complicated.
>
> Linux ARM64 Maintainers mandate that platforms implement the PSCI
> protocol.
> In your case with single core that means providing reset and poweroff
> handlers
> that the kernel can invoke via secure monitor call.
>
> barebox can consume psci: CONFIG_ARM_PSCI_CLIENT, CONFIG_CMD_SMC,
> but what
> you're missing is the provider side. barebox as PSCI provider is implemented
> only for a single ARM32 SoC, the i.MX7. All supported ARM64 platforms use
> TF-A as BL31 with the exception of Layerscape (which uses PPA, an NXP BL31
> implementation).
>
> What does this mean for you?
>
> 1) Either add your SoC to TF-A
> 2) Extend PSCI implementation in barebox for ARM64.
>
> While I think it would be cool to have barebox provide all of BL2, BL31 and
> BL32, I think you are better advised to use TF-A, because that's what most
> other ARM Silicon Vendors use. That means less effort for you and easier
> maintenance as you benefit from fixes done for other SoCs using the same
> IPs. barebox certainly benefits from being able to focus on being a bootloader
> and leaving the errata workarounds, GIC init stuff and runtime services
> to TF-A.
>
> The boot flow would then be:
>
> - barebox PBL runs as BL2 in SRAM and sets up DRAM
> - barebox PBL executes BL31 (TF-A) which was compiled into PBL
> - TF-A installs secure monitor and returns control to DRAM in EL2
> - barebox resumes execution in EL2 as BL33
> - Linux is invoked in EL2 and can communicate with secure monitor.
>
> You may find this talk interesting:
> https://fosdem.org/2023/schedule/event/uboot_psci/
> Even if I disagree a bit with the takeaway.
>
> > I guess we will have to integrate the interrupt controlled (GIC-600) into
> QEMU and into the device tree for it to work.
> > Is that a valid assumption?
>
> I never had to add a new SoC to Linux, so I can't give any better
> suggestions than Yes. Where you're going, you'll need interrupts.
>
> Godspeed and keep me posted :)
> Ahmad
>
> >
> > Thanks,
> > Lior.
> >
> >
> >
> >
> >> -----Original Message-----
> >> From: Ahmad Fatoum <a.fatoum@pengutronix.de>
> >> Sent: Wednesday, May 31, 2023 8:55 PM
> >> To: Lior Weintraub <liorw@pliops.com>; Ahmad Fatoum <ahmad@a3f.at>;
> >> barebox@lists.infradead.org
> >> Subject: Re: [PATCH v2] Porting barebox to a new SoC
> >>
> >> CAUTION: External Sender
> >>
> >> Hi Lior,
> >>
> >> On 31.05.23 18:13, Lior Weintraub wrote:
> >>> Hi Ahmad,
> >>>
> >>> Using end of SRAM as PBL stack is currently not working because we need
> >> 40bit address (0xC0_0020_0000).
> >>> This needs a fix to ENTRY_FUNCTION_WITHSTACK macro.
> >>
> >> Ah, right. I just sent an (untested) patch. Would be cool if you could
> >> try it out.
> >>
> >>> I tried just to change const u32 __stack_top = (stack_top); to const u64
> >> __stack_top = (stack_top); but there were linking errors caused by:
> >>> ASSERT(. - __pbl_board_stack_top <= 8, "Only One PBL per Image
> allowed")
> >>
> >> The easy way would have been using a __attribute__((naked)) function,
> but
> >> those are only supported for arm32, not arm64. The alternative is thus
> >> writing the entry point in assembly and to make board authors life easier
> >> the linker script ensures that the stack setup entry point is invoked prior
> >> to the board entry.
> >>
> >>> Regarding the arm timer:
> >>> Adding the timer entry to DT solved the issue.
> >>>
> >>> Regarding the UART:
> >>> Indeed CONFIG_SERIAL_AMBA_PL011 was set on spider_defconfig (also
> >> verified it generated the correct entry on .config).
> >>> I also noticed that if I remove the putc_ll implementation there is no Tx at
> all
> >> from Barebox.
> >>
> >> I've led you astray. Indeed:
> >>
> >>>>> of_platform_bus_create() - skipping /soc, no compatible prop
> >>
> >> points at the issue.
> >>
> >> Try adding into /soc
> >>
> >> compatible = "simple,bus";
> >> ranges;
> >> dma-ranges;
> >>
> >> This matches /soc with the simple bus driver which just instantiates devices
> >> for the
> >> contained children. Those in turn should be matched by the drivers.
> >>
> >> The ranges stuff just tells that memory and SoC peripherals exist in the
> same
> >> address space.
> >>
> >> When it probes you may need to describe the clock in the DT. Eventually,
> you
> >> will
> >> want to have a clock driver for your hardware (good news: barebox and
> Linux
> >> have
> >> basically the same API, so you only need to write it once). But for now, you
> >> can
> >> fake it using fixed-clock in the DT. Take a look at:
> >>
> >> snps,dw-apb-uart in arch/riscv/dts/jh7100.dtsi and compare with
> >> dts/src/arm/imx28.dtsi
> >> to see how to map that to PL011.
> >>
> >>> Could it be a hint?
> >>
> >> DEBUG_LL bridges the gap until a driver registers a console that's enabled. If
> >> this
> >> never happens, you are left with a non-interactive shell.
> >>
> >> Cheers,
> >> Ahmad
> >>
> >>>
> >>> Thanks,
> >>> Lior.
> >>>
> >>>> -----Original Message-----
> >>>> From: Ahmad Fatoum <a.fatoum@pengutronix.de>
> >>>> Sent: Wednesday, May 31, 2023 11:40 AM
> >>>> To: Lior Weintraub <liorw@pliops.com>; Ahmad Fatoum
> <ahmad@a3f.at>;
> >>>> barebox@lists.infradead.org
> >>>> Subject: Re: [PATCH v2] Porting barebox to a new SoC
> >>>>
> >>>> CAUTION: External Sender
> >>>>
> >>>> Hi Lior,
> >>>>
> >>>> On 31.05.23 10:05, Lior Weintraub wrote:
> >>>>> Hi Ahmad,
> >>>>>
> >>>>> Thanks again for your prompt reply and accurate tips!
> >>>>> Took the following changes:
> >>>>> 1. Increasing the DRAM size to 128MB (let barebox start from 0).
> >>>>> 2. Set PBL stack to offset 2MB from DRAM
> >>>>
> >>>> Just use end of SRAM, so you are completely independent of DRAM
> >>>> until you call barebox_arm_entry.
> >>>>
> >>>>> 3. Fix the device tree "memory" entry to have 128MB.
> >>>>
> >>>> (y)
> >>>>
> >>>>> 4. Load barebox-spider-mk1-evk.img to SRAM and run from there.
> >>>>>
> >>>>> Now I can see the following logs:
> >>>>> uncompress.c: memory at 0x00000000, size 0x08000000
> >>>>> uncompress.c: uncompressing barebox binary at 0x000000c0000021c0
> >>>> (size 0x0001e3a4) to 0x07e00000 (uncompressed size: 0x000390d0)
> >>>>> uncompress.c: jumping to uncompressed image at
> >> 0x0000000007e00000
> >>>>> start.c: memory at 0x00000000, size 0x08000000
> >>>>> start.c: found DTB in boarddata, copying to 0x07dffcc0
> >>>>> start.c: initializing malloc pool at 0x079ffcc0 (size 0x00400000)
> >>>>> start.c: starting barebox...
> >>>>> initcall-> command_slice_init+0x0/0x3c
> >>>>> initcall-> globalvar_init+0x0/0x80
> >>>>> register_device: global
> >>>>> register_device: nv
> >>>>> initcall-> platform_init+0x0/0x1c
> >>>>> register_device: platform
> >>>>> initcall-> amba_bus_init+0x0/0x1c
> >>>>> register_device: amba
> >>>>> initcall-> spi_bus_init+0x0/0x1c
> >>>>> register_device: spi
> >>>>> initcall-> gpio_desc_alloc+0x0/0x24
> >>>>> initcall-> fs_bus_init+0x0/0x1c
> >>>>> register_device: fs
> >>>>> initcall-> aarch64_init_vectors+0x0/0x50
> >>>>> initcall-> gpio_gate_clock_driver_register+0x0/0x1c
> >>>>> register_driver: gpio-gate-clock
> >>>>> initcall-> of_arm_init+0x0/0x5c
> >>>>> start.c: barebox_arm_boot_dtb: using barebox_boarddata
> >>>>> using boarddata provided DTB
> >>>>> adding DT alias:serial0: stem=serial id=0
> node=/soc/serial@d000307000
> >>>>> register_device: machine
> >>>>> of_platform_bus_create() - skipping /chosen, no compatible prop
> >>>>> of_platform_bus_create() - skipping /aliases, no compatible prop
> >>>>> of_platform_bus_create() - skipping /cpus, no compatible prop
> >>>>> of_platform_bus_create() - skipping /memory@0, no compatible prop
> >>>>> of_platform_bus_create() - skipping /soc, no compatible prop
> >>>>> initcall-> register_autoboot_vars+0x0/0x70
> >>>>> initcall-> arm_arch_timer_driver_register+0x0/0x1c
> >>>>> register_driver: arm-architected-timer
> >>>>> initcall-> of_timer_init+0x0/0x20
> >>>>> initcall-> init_fs+0x0/0x3c
> >>>>> initcall-> pl011_driver_register+0x0/0x1c
> >>>>> register_driver: uart-pl011
> >>>>> initcall-> of_stdoutpath_init+0x0/0x28
> >>>>> initcall-> of_probe_memory+0x0/0x60
> >>>>> __request_region ok: 0x00000000:0x07ffffff flags=0x0
> >>>>> initcall-> __bare_init_end+0x0/0x6c
> >>>>> register_device: mem0
> >>>>> initcall-> of_reserved_mem_walk+0x0/0x1ac
> >>>>> initcall-> mem_malloc_resource+0x0/0xa8
> >>>>> __request_region ok: 0x079ffcc0:0x07dffcbf flags=0x200
> >>>>> __request_region ok: 0x07e00000:0x07e2aeff flags=0x200
> >>>>> __request_region ok: 0x07e2af00:0x07e390cf flags=0x200
> >>>>> __request_region ok: 0x07e390d0:0x07e3adaf flags=0x200
> >>>>> initcall-> bootsource_init+0x0/0x40
> >>>>> initcall-> ramfs_init+0x0/0x1c
> >>>>> register_driver: ramfs
> >>>>> initcall-> devfs_init+0x0/0x1c
> >>>>> register_driver: devfs
> >>>>> initcall-> arm_request_stack+0x0/0x398
> >>>>> __request_region ok: 0x07ff0000:0x07ff7fff flags=0x200
> >>>>> initcall-> mount_root+0x0/0x7c
> >>>>> mount: none on / type ramfs, options=
> >>>>> register_device: ramfs0
> >>>>> probe-> ramfs0
> >>>>> mount: none on /dev type devfs, options=
> >>>>> register_device: devfs0
> >>>>> probe-> devfs0
> >>>>> initcall-> binfmt_sh_init+0x0/0x1c
> >>>>> initcall-> binfmt_uimage_init+0x0/0x1c
> >>>>> initcall-> console_common_init+0x0/0x48
> >>>>> initcall-> of_kernel_init+0x0/0x28
> >>>>> initcall-> console_ctrlc_init+0x0/0x30
> >>>>> initcall-> mem_init+0x0/0x90
> >>>>> register_device: mem1
> >>>>> register_driver: mem
> >>>>> probe-> mem0
> >>>>> probe-> mem1
> >>>>> initcall-> of_partition_init+0x0/0x48
> >>>>> initcall-> prng_init+0x0/0x40
> >>>>> initcall-> null_init+0x0/0x40
> >>>>> initcall-> full_init+0x0/0x40
> >>>>> initcall-> zero_init+0x0/0x40
> >>>>> initcall-> spider_board_driver_register+0x0/0x1c
> >>>>> register_driver: board-spider
> >>>>> probe-> machine
> >>>>> initcall-> barebox_memory_areas_init+0x0/0x40
> >>>>> __request_region ok: 0x07dffcc0:0x07dfffce flags=0x200
> >>>>> initcall-> barebox_of_populate+0x0/0x28
> >>>>> initcall-> of_register_memory_fixup+0x0/0x20
> >>>>> initcall-> dummy_csrc_warn+0x0/0x44
> >>>>> WARNING: Warning: Using dummy clocksource
> >>>>
> >>>> Add a arm,armv8-timer node into your SoC device tree.
> >>>> This lets barebox and Linux know that you have the ARM
> >>>> architected timer available. Without that, you'll notice
> >>>> that timeouts are wrong.
> >>>>
> >>>>> initcall-> bootm_init+0x0/0xf4
> >>>>> initcall-> init_command_list+0x0/0x40
> >>>>> register command bootm
> >>>>> register command cat
> >>>>> register command cd
> >>>>> register command clear
> >>>>> register command cp
> >>>>> register command cpuinfo
> >>>>> register command devinfo
> >>>>> register command drvinfo
> >>>>> register command echo
> >>>>> register command exit
> >>>>> register command false
> >>>>> register command help
> >>>>> register command ?
> >>>>> register command ll
> >>>>> register command ls
> >>>>> register command md
> >>>>> register command memcmp
> >>>>> register command memcpy
> >>>>> register command memset
> >>>>> register command mkdir
> >>>>> register command mount
> >>>>> register command mw
> >>>>> register command pwd
> >>>>> register command rm
> >>>>> register command rmdir
> >>>>> register command setenv
> >>>>> register command sh
> >>>>> register command source
> >>>>> register command .
> >>>>> register command test
> >>>>> register command [
> >>>>> register command true
> >>>>> register command :
> >>>>> register command umount
> >>>>> register command version
> >>>>> initcall-> display_meminfo+0x0/0xa8
> >>>>> barebox code: 0x7e00000 -> 0x7e2aeff
> >>>>> bss segment: 0x7e390d0 -> 0x7e3adaf
> >>>>> malloc space: 0x079ffcc0 -> 0x07dffcbf (size 4 MiB)
> >>>>> initcall-> of_register_bootargs_fixup+0x0/0x3c
> >>>>> initcall-> device_probe_deferred+0x0/0x14c
> >>>>> initcall-> of_init_hostname+0x0/0x28
> >>>>> initcall-> aarch64_register_image_handler+0x0/0x2c
> >>>>> initcall-> load_environment+0x0/0x4c
> >>>>> loading defaultenv
> >>>>> environment load /dev/env0: No such file or directory
> >>>>> Maybe you have to create the partition.
> >>>>> initcalls done
> >>>>>
> >>>>> Hit any to stop autoboot: 0
> >>>>> boot: No such file or directory
> >>>>> barebox:/
> >>>>>
> >>>>>
> >>>>> Few questions:
> >>>>> 1. The serial input doesn't work. i.e. I cannot type anything hence
> cannot
> >>>> interact with barebox terminal.
> >>>>
> >>>> DEBUG_LL only does otuput. For input, you will want to load the driver.
> >>>> Do you have CONFIG_SERIAL_AMBA_PL011 enabled?
> >>>>
> >>>>> Does it require GIC and setting interrupts for it to work?
> >>>>
> >>>> No interrupts needed. barebox runs with interrupts disabled and
> >> everything
> >>>> is done cooperatively.
> >>>>
> >>>>> 2. What does "of_platform_bus_create() - skipping" means? Do I need
> to
> >> fix
> >>>> that?
> >>>>
> >>>> That's normal debugging output. Some device tree nodes are busses,
> which
> >>>> have
> >>>> children. These entries are skipped because they have no compatible.
> This is
> >>>> expected. I'd suggest you remove your VERBOSED_DEBUG define, so you
> >> are
> >>>> not
> >>>> spammed by too much debugging output.
> >>>>
> >>>>> 3. Looks like I am still missing some stuff (rootfs? Environment?
> >> Mounting?
> >>>> Partitions?)
> >>>>
> >>>> Take multi_v8_defconfig, open menuconfig and enable your SoC and use
> >> that.
> >>>> That will be quicker than enabling everything yourself. If it doesn't work
> >>>> out of the box, try imx_v8_defconfig.
> >>>>
> >>>> Once you get around to upstreaming your SoC, I'd suggest you just add it
> >>>> to multi_v8_defconfig. Not all ARMv8 SoCs are supported there, but
> those
> >>>> that are make development easier, because we don't need to build as
> many
> >>>> different configs..
> >>>>
> >>>> Cheers,
> >>>> Ahmad
> >>>>
> >>>>>
> >>>>> Thanks,
> >>>>> Have a great day,
> >>>>> Lior.
> >>>>>
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: Ahmad Fatoum <a.fatoum@pengutronix.de>
> >>>>>> Sent: Wednesday, May 31, 2023 9:11 AM
> >>>>>> To: Lior Weintraub <liorw@pliops.com>; Ahmad Fatoum
> >> <ahmad@a3f.at>;
> >>>>>> barebox@lists.infradead.org
> >>>>>> Subject: Re: [PATCH v2] Porting barebox to a new SoC
> >>>>>>
> >>>>>> CAUTION: External Sender
> >>>>>>
> >>>>>> Hi Lior,
> >>>>>>
> >>>>>> On 30.05.23 22:10, Lior Weintraub wrote:
> >>>>>>> Hello Ahmad,
> >>>>>>>
> >>>>>>> Thanks again for your kind support!
> >>>>>>> Your comments helped me progress and the current situation is as
> >>>> follows:
> >>>>>>> Our QEMU Spider machine is running a BL1.elf file using the following
> >>>>>> command:
> >>>>>>> QEMU_AUDIO_DRV=none qemu-system-aarch64 -M spider-soc -
> smp 1
> >> -
> >>>> m
> >>>>>> 128M -nographic \
> >>>>>>> -device loader,file=BL1.elf -cpu cortex-a53,rvbar=0xC004000000 \
> >>>>>>> -d unimp -semihosting-config enable=on,target=native \
> >>>>>>> -monitor telnet:localhost:1235,server,nowait \
> >>>>>>> -gdb tcp::1236
> >>>>>>>
> >>>>>>> The BL1.elf is our BootROM application that runs from ROM address
> >>>>>> 0xC004000000.
> >>>>>>> Just for debugging purpose we've increased the ROM size so it can
> >> include
> >>>>>> the images/barebox-spider-mk1-evk.img (as a const array).
> >>>>>>> BL1 then copy it (using memcpy) to address 0 and jumps there for
> >>>>>> execution.
> >>>>>>
> >>>>>> Sounds ok.
> >>>>>>
> >>>>>>> On the real ASIC this address will be the DRAM and indeed will need
> to
> >> be
> >>>>>> initialized before the copy but here on QEMU it is not required.
> >>>>>>
> >>>>>> I see. You could still have your bootrom move barebox into SRAM and
> >> then
> >>>>>>
> >>>>>> barebox_arm_entry(DRAM_ADDR, SZ_128M,
> >>>> __dtb_spider_mk1_evk_start);
> >>>>>>
> >>>>>> To have PBL extract barebox to DRAM. Even if you don't need need
> >> DRAM
> >>>>>> setup in QEMU, the flow would be similar to what you will have on
> actual
> >>>>>> silicon.
> >>>>>>
> >>>>>>> The lowlevel.c of spider-evk was modified to use DRAM_ADDR
> >> 0x400000
> >>>>>> (4MB from start) and MY_STACK_TOP was set to 0x8000000 (128M).
> >>>>>>
> >>>>>> That's not needed. While you don't have control where barebox PBL
> will
> >> be
> >>>>>> located
> >>>>>> (depends on BootROM), barebox will extract itself to the end of DRAM
> >>>>>> without
> >>>>>> overwriting itself, so you can just use DRAM_ADDR 0 normally.
> >> Eventually,
> >>>>>> stack
> >>>>>> top should go into SRAM, but anywhere that works is ok.
> >>>>>>
> >>>>>>> In addition, I implemented putc_ll (currently hard-coded in
> >>>>>> include/debug_ll.h) and opened log level to VERBOSE_DEBUG
> (currently
> >>>> just
> >>>>>> hard-coded in printk.h).
> >>>>>>
> >>>>>> There's CONFIG_DEBUG_PBL you can enable to get all these messages
> by
> >>>>>> default.
> >>>>>>
> >>>>>>> I see the following (which makes sense) logs on QEMU terminal:
> >>>>>>> uncompress.c: memory at 0x00400000, size 0x00200000
> >>>>>>> uncompress.c: uncompressing barebox binary at
> >> 0x0000000000002200
> >>>>>> (size 0x0001d3b2) to 0x00400000 (uncompressed size: 0x000373d0)
> >>>>>>
> >>>>>> Why pass only 2M to barebox_arm_entry? While this need not be the
> >>>> whole
> >>>>>> of RAM, this
> >>>>>> initial memory is what barebox will use for itself including its final stack
> >> and
> >>>>>> malloc area. barebox will also not place itself into the last 1M AFAIK, so
> >> 2M
> >>>>>> may not work ok. You should use the minimum possible RAM here or
> if
> >> you
> >>>>>> can detect
> >>>>>> in PBL how much RAM you have or just the whole RAM bank. I am not
> >> sure
> >>>>>> anything lower
> >>>>>> than SZ_4M would work ok. (Note this is DRAM size, not SRAM.
> barebox
> >>>> PBL
> >>>>>> is fine being
> >>>>>> called from 64K SRAMs, it just needs DRAM to extract to).
> >>>>>>
> >>>>>>> I then connect with aarch64-none-elf-gdb, load the barebox symbols
> >> (to
> >>>>>> 0x400000) and check the current execution state (program counter
> and
> >>>>>> stack).
> >>>>>>> Looks like the code is stuck on function register_autoboot_vars:
> >>>>>>> sp 0x5f7e60 0x5f7e60
> >>>>>>> pc 0x401264 0x401264 <register_autoboot_vars+24>
> >>>>>>>
> >>>>>>> Few observations:
> >>>>>>> 1. The PBL was using stack top located on 0x8000000 (which is
> >>>>>> MY_STACK_TOP). Found it be causing a breakpoint on the PBL.
> >>>>>>> 2. Barebox uses a stack top on 0x600000 which is probably calculated
> >>>> from
> >>>>>> my new DRAM_ADDR and SZ_2M given to the function call:
> >>>>>>> barebox_arm_entry(DRAM_ADDR, SZ_2M,
> >>>> __dtb_spider_mk1_evk_start);
> >>>>>>>
> >>>>>>> This is great! I am starting to find my way.
> >>>>>>
> >>>>>> :) Ye, the ENTRY_FUNCTION_WITHSTACK is only when the BootROM
> >>>> doesn't
> >>>>>> enter
> >>>>>> with a valid stack pointer. It's overwritten as soon as barebox is told
> >>>>>> about the initial memory layout (with barebox_arm_entry).
> >>>>>>
> >>>>>>> When the barebox execution didn't print anything to the terminal I
> >>>>>> remembered that we used a place holder on the dtsi for the uart.
> >>>>>>> So now I changed it to:
> >>>>>>> uart0: serial@d000307000 {
> >>>>>>> compatible = "arm,pl011", "arm,primecell";
> >>>>>>> reg = <0xd0 0x307000 0 0x1000>;
> >>>>>>> }
> >>>>>>> (Our QEMU UART is currently using pl011 device.)
> >>>>>>
> >>>>>> Looks ok. Don't forget to enable the driver (via make menuconfig).
> >>>>>>
> >>>>>>> After some time (trying to debug by enabling MMU but then reverted
> >> the
> >>>>>> code back), I got to a point that when I try to run again I am getting an
> >>>>>> exception.
> >>>>>>> I can swear all code changes were reverted back to the point where I
> >> saw
> >>>> the
> >>>>>> barebox stuck on register_autoboot_vars but now it just cases an
> >>>> exception.
> >>>>>>> The exception vector code is located on our ROM (part of BL1 code)
> and
> >>>> the
> >>>>>> logs shows that the link register has the value 0x401218 which suggest
> >> the
> >>>>>> following code:
> >>>>>>> 0000000000001200 <load_environment>:
> >>>>>>> 1200: a9be7bfd stp x29, x30, [sp, #-32]!
> >>>>>>> 1204: 910003fd mov x29, sp
> >>>>>>> 1208: a90153f3 stp x19, x20, [sp, #16]
> >>>>>>> 120c: 94000a07 bl 3a28 <default_environment_path_get>
> >>>>>>> 1210: d00000f3 adrp x19, 1f000 <do_cpuinfo+0x1f0>
> >>>>>>> 1214: 912a7273 add x19, x19, #0xa9c
> >>>>>>> 1218: aa0003f4 mov x20, x0
> >>>>>>>
> >>>>>>> Any ideas or suggestions how to proceed with the debugging?
> >>>>>>
> >>>>>> You shouldn't need to touch the MMU code. If your initial memory
> setup
> >>>>>> is wonky, you may end up overwriting stuff. Try again with bigger
> >> memory.
> >>>>>>
> >>>>>>> BTW, to answer your questions:
> >>>>>>> The SRAM of 4MB is the only one we have because we assumed it is
> >> only
> >>>> for
> >>>>>> BootROM to load a PBL
> >>>>>>
> >>>>>> Ok. Sometimes there are SRAMs for use with DMA. I asked, because a
> >>>> SRAM
> >>>>>> in the first 4M
> >>>>>> would lend itself nicely as stack, but if there is none, we can adjust
> >>>>>> ENTRY_FUNCTION_WITHSTACK to accept a 64-bit parameter.
> >>>>>>
> >>>>>> Cheers,
> >>>>>> Ahmad
> >>>>>>
> >>>>>>> Thank you very much,
> >>>>>>> Cheers,
> >>>>>>> Lior.
> >>>>>>>
> >>>>>>>
> >>>>>>>> -----Original Message-----
> >>>>>>>> From: Ahmad Fatoum <a.fatoum@pengutronix.de>
> >>>>>>>> Sent: Monday, May 29, 2023 10:03 PM
> >>>>>>>> To: Lior Weintraub <liorw@pliops.com>; Ahmad Fatoum
> >>>> <ahmad@a3f.at>;
> >>>>>>>> barebox@lists.infradead.org
> >>>>>>>> Subject: Re: [PATCH v2] Porting barebox to a new SoC
> >>>>>>>>
> >>>>>>>> CAUTION: External Sender
> >>>>>>>>
> >>>>>>>> Hello Lior,
> >>>>>>>>
> >>>>>>>> On 29.05.23 15:34, Lior Weintraub wrote:
> >>>>>>>>> Hi Ahmad,
> >>>>>>>>>
> >>>>>>>>> I have revised the addresses and used DRAM address @ 0 instead:
> >>>>>>>>> #define UARTBASE (0xD000307000)
> >>>>>>>>> #define DRAM_ADDR (0x00000000)
> >>>>>>>>> #define MY_STACK_TOP (0x00000000 + SZ_2M) // Set the stack
> >> 2MB
> >>>>>> from
> >>>>>>>> DRAM start
> >>>>>>>>
> >>>>>>>> Is DRAM configured by the time barebox runs? If not, you should
> keep
> >>>>>> stack
> >>>>>>>> top
> >>>>>>>> in SRAM, until you have setup memory in prebootloader (PBL). Is
> the
> >> 4M
> >>>>>>>> SRAM
> >>>>>>>> the only on-chip SRAM you have?
> >>>>>>>>
> >>>>>>>>> static inline void spider_serial_putc(void *base, int c)
> >>>>>>>>> {
> >>>>>>>>> *((volatile unsigned *)base) = c;
> >>>>>>>>
> >>>>>>>> There's a helper for that: writel(c, base); In barebox, it's equivalent
> >>>>>>>> to the volatile access, but in Linux it involves a write memory barrier.
> >>>>>>>> We try to write code in barebox, so it's easily reusable in Linux (and
> >>>>>>>> the other way round).
> >>>>>>>>
> >>>>>>>>> }
> >>>>>>>>>
> >>>>>>>>> I will try to test it on QEMU using an initial QEMU machine we
> made
> >> for
> >>>>>>>> Spider.
> >>>>>>>>> In this machine we only have 3 memory regions and a PL011 UART:
> >>>>>>>>> spider_soc_memories soc_memories[] = {
> >>>>>>>>> {.name = "SPIDER_GPRAM", .add = 0xC000000000ULL, .size = 4
> *
> >>>> MiB},
> >>>>>>>>> {.name = "SPIDER_ROM", .add = 0xC004000000ULL, .size =
> 128 *
> >>>>>> KiB},
> >>>>>>>>> {.name = "SPIDER_DRAM", .add = 0x0000000000ULL, .size = 1
> *
> >>>> GiB},
> >>>>>>>>> };
> >>>>>>>>>
> >>>>>>>>> This special QEMU machine can run our BL1 code from "ROM"
> >> address
> >>>>>> (we
> >>>>>>>> set the RVBAR to point there).
> >>>>>>>>> So my idea is to test the barebox image by the following steps:
> >>>>>>>>> 1. Modify the QEMU code to have a "ROM" with the size of 128M.
> >>>>>>>>> 2. Compile our BL1 code to include the barebox.bin as a const
> array,
> >>>> copy
> >>>>>> it
> >>>>>>>> to "DRAM" @ address 0 and jump there.
> >>>>>>>>
> >>>>>>>> Why not map QEMU -bios option to SRAM? (Or DRAM directly, if it
> >>>> needs
> >>>>>> no
> >>>>>>>> special setup from
> >>>>>>>> barebox side).
> >>>>>>>>
> >>>>>>>>> For this to work I wanted to understand how to call (i.e. what
> >>>> arguments
> >>>>>> to
> >>>>>>>> pass) to barebox.
> >>>>>>>>
> >>>>>>>> barebox doesn't expect any arguments, because most BootROMs
> >> don't
> >>>>>> pass
> >>>>>>>> anything useful.
> >>>>>>>> Some pass information about bootsource though, so that's why the
> >>>>>>>> ENTRY_FUNCTION has
> >>>>>>>> r0, r1 and r2 as parameters, but you need not use them.
> >>>>>>>>
> >>>>>>>>> So I checked the barebox.map and found the function "start" on
> >>>> address
> >>>>>> 0.
> >>>>>>>>
> >>>>>>>> You may know that Linux on some platforms comes with a
> >> decompressor
> >>>>>> that
> >>>>>>>> is glued to the
> >>>>>>>> front of the kernel image and extracts the compressed kernel image.
> >>>>>> barebox
> >>>>>>>> has the same
> >>>>>>>> concept. The prebootloader is uncompressed and runs (starting
> from
> >>>>>>>> ENTRY_FUNCTION) and
> >>>>>>>> then does some early setup (e.g. enable clocks, configure PMIC,
> setup
> >>>>>> DRAM,
> >>>>>>>> load secure
> >>>>>>>> monitor (BL31), ...etc.) and then it decompresses barebox proper
> into
> >>>>>> DRAM.
> >>>>>>>>
> >>>>>>>> barebox.bin <- barebox proper. You don't usually need that.
> >>>>>>>> barebox.elf <- ELF binary for the above (for gdb)
> >>>>>>>> barebox.map <- map file of the above
> >>>>>>>>
> >>>>>>>> images/barebox-spider-mk1-evk.img <- complete barebox image
> (PBL
> >> +
> >>>>>>>> barebox proper)
> >>>>>>>> images/start_spider_mk1_evk.pbl <- ELF image for the above
> >>>>>>>> images/start_spider_mk1_evk.pbl.map <- map file of the above
> >>>>>>>>
> >>>>>>>> If you want to follow barbeox from the start, begin at
> >>>>>> start_spider_mk1_evk.
> >>>>>>>>
> >>>>>>>>> Then I went to arch/arm/cpu/start.c and realized that the code is
> >>>> compiled
> >>>>>>>> with CONFIG_PBL_IMAGE.
> >>>>>>>>> In that case I assume I need to pass 3 arguments and use this
> >> function
> >>>>>>>> prototype:
> >>>>>>>>> void start(unsigned long membase, unsigned long memsize, void
> >>>>>>>> *boarddata);
> >>>>>>>>
> >>>>>>>> barebox prebootloader takes care of this, so you don't need to do
> >>>> anything.
> >>>>>>>>
> >>>>>>>>> Few questions:
> >>>>>>>>> 1. Will that call work:
> >>>>>>>>> typedef void (*barebox_start)(unsigned long , unsigned long ,
> void
> >> *);
> >>>>>>>>> #define DRAM_START (0)
> >>>>>>>>> barebox_start p_barebox = (barebox_start)DRAM_START;
> >>>>>>>>> p_barebox(DRAM_START, DRAM_START+SZ_2M, (void
> >>>>>>>> *)(DRAM_START+SZ_4M));
> >>>>>>>>> This assumes that my BL1 code also copied the device tree
> >> (barebox-
> >>>> dt-
> >>>>>>>> 2nd.img? start_dt_2nd.pblb? start_spider_mk1_evk.pblb?)
> >>>>>>>>
> >>>>>>>> The device tree is built into the PBL and passed to barebox proper.
> This
> >>>>>>>> allows us to use the same barebox proper binary and link it with a
> >>>> different
> >>>>>>>> prebootloader for each SoC/board, all in the same build.
> >>>>>>>>
> >>>>>>>> barebox-dt-2nd.img is a special image that looks exactly like a Linux
> >>>> kernel:
> >>>>>>>>
> >>>>>>>> images/barebox-dt-2nd.img: Linux kernel ARM64 boot executable
> >>>> Image,
> >>>>>>>> little-endian, 4K pages
> >>>>>>>>
> >>>>>>>> and can thus be used for booting for easy chainloading from other
> >>>>>>>> bootloaders or for running
> >>>>>>>> with QEMU -kernel. You shouldn't need it right now.
> >>>>>>>>
> >>>>>>>>> 2. Do I want to have my code compiled with CONFIG_PBL_IMAGE?
> >>>>>>>>> If I understand correctly, it means that my code will provide a PBL
> >>>> (a.k.a
> >>>>>>>> BL2) which will set the DRAM and STACK among other things
> (MMU?).
> >>>>>>>>
> >>>>>>>> The patch I sent already builds a PBL. You will need to fill out
> >>>>>>>> start_spider_mk1_evk
> >>>>>>>> to do all the other early initialization you need. Then you call
> >>>>>>>> barebox_arm_entry
> >>>>>>>> with device tree and memory size and it will take care to do stack
> setup
> >> in
> >>>>>> new
> >>>>>>>> memory region, MMU setup (if enabled) and chainloading barebox
> >>>> proper.
> >>>>>>>>
> >>>>>>>> Note that PBL isn't necessary BL2. You can chainload barebox from
> >> within
> >>>>>>>> barebox (i.e.
> >>>>>>>> in EL2 or EL1), which is useful for debugging. You will thus often find
> >> PBL
> >>>>>> code
> >>>>>>>> that
> >>>>>>>> does
> >>>>>>>>
> >>>>>>>> if (current_el() == 3) {
> >>>>>>>> /* Do BL2 setup */
> >>>>>>>> chainload();
> >>>>>>>> __builtin_unreachable();
> >>>>>>>> }
> >>>>>>>>
> >>>>>>>> barebox_arm_entry(...)
> >>>>>>>>
> >>>>>>>> See for example arch/arm/boards/innocomm-imx8mm-
> >> wb15/lowlevel.c
> >>>>>>>>
> >>>>>>>> to see a real-world example of another Cortex-A53.
> >>>>>>>>
> >>>>>>>>> In that case I assume it is OK.
> >>>>>>>>> 3. If I try to remove it by having CONFIG_PBL_IMAGE=n on
> >>>>>> spider_defconfig
> >>>>>>>> this doesn't do anything
> >>>>>>>>> The build (make spider_defconfig) ignores it and say that " No
> >> change
> >>>> to
> >>>>>>>> .config ".
> >>>>>>>>
> >>>>>>>> Another symbol forces it to be enabled. If you are curious, run make
> >>>>>>>> menuconfig
> >>>>>>>> and then search (/) for the symbol and it will list, whether it's
> enabled
> >>>> and
> >>>>>>>> why:
> >>>>>>>>
> >>>>>>>> Selected by [y]:
> >>>>>>>> - PBL_MULTI_IMAGES [=y] && HAVE_PBL_MULTI_IMAGES [=y]
> >>>>>>>>
> >>>>>>>> I'd suggest you avoid modifying the .config file manually. always use
> >>>>>>>> menuconfig.
> >>>>>>>>
> >>>>>>>>> 4. I also tried to understand how to implement PUTC_LL but not
> sure
> >> I
> >>>>>>>> understand.
> >>>>>>>>> 4.1 When I set "CONFIG_DEBUG_LL=y" on spider_defconfig it is
> >> again
> >>>>>> not
> >>>>>>>> written to .config and I get " No change to .config " message.
> >>>>>>>>
> >>>>>>>> You must:
> >>>>>>>>
> >>>>>>>> - select HAS_DEBUG_LL from MACH_SPIDER
> >>>>>>>> - Add your arch to arch/arm/include/asm/debug_ll.h
> >>>>>>>> - Then implement PUTC_LL in e.g. mach/spider/debug_ll.h
> >>>>>>>>
> >>>>>>>>> 4.2 Do I need to have my own debug_ll.h file?
> >>>>>>>>
> >>>>>>>> Yes. See above.
> >>>>>>>>
> >>>>>>>>> 5. When I make changes to spider_defconfig and try to regenerate
> >> the
> >>>>>>>> .config and I get " No change to .config " message, does it mean that
> >>>> those
> >>>>>>>> macros are "hidden" symbols like you said about the
> >> CONFIG_CPU_V8?
> >>>>>>>>
> >>>>>>>> Yes. Just check menuconfig to see how symbols relate to each other.
> >>>>>>>> This is 1:1 like it's in Linux, so it'll come in handy when you do
> >>>>>>>> the kernel port too ;)
> >>>>>>>>
> >>>>>>>>> Apologize for so many questions :-)
> >>>>>>>>
> >>>>>>>> No problem. Looking forward to your patches ;)
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Cheers,
> >>>>>>>> Ahmad
> >>>>>>>>
> >>>>>>>>> Cheers,
> >>>>>>>>> Lior.
> >>>>>>>>>
> >>>>>>>>> -----Original Message-----
> >>>>>>>>> From: Lior Weintraub
> >>>>>>>>> Sent: Sunday, May 28, 2023 11:16 PM
> >>>>>>>>> To: Ahmad Fatoum <ahmad@a3f.at>; barebox@lists.infradead.org
> >>>>>>>>> Subject: RE: [PATCH v2] Porting barebox to a new SoC
> >>>>>>>>>
> >>>>>>>>> Hi Ahmad,
> >>>>>>>>>
> >>>>>>>>> Thank you so much for your kind support!
> >>>>>>>>>
> >>>>>>>>> Indeed we also have a 16GB DRAM that starts from address 0
> >> (though
> >>>>>>>> currently we don't have the controller settings (under
> development)).
> >>>>>>>>>
> >>>>>>>>> I also wrote the BootROM (BL1) for this SoC (128KB ROM @
> address
> >>>>>>>> 0xC004000000).
> >>>>>>>>> I understand now that it would be best for me to develop BL2 that
> >> will
> >>>> run
> >>>>>>>> from our SRAM.
> >>>>>>>>>
> >>>>>>>>> As this BL2 code is bare-metal I have no problem or limitations with
> >> the
> >>>> 40
> >>>>>>>> bit addresses.
> >>>>>>>>> The BL2 code will initialize the DRAM controller and then copy
> >> Barebox
> >>>>>> image
> >>>>>>>> from NOR Flash to address 0 of the DRAM.
> >>>>>>>>> Our NOR Flash is 128MB in size and it is accessed via QSPI
> controller.
> >>>>>>>>>
> >>>>>>>>> I tried applying your suggested patch but got an error while doing
> so:
> >>>>>>>>> $git apply 0002-Ahmad.patch
> >>>>>>>>> 0002-Ahmad.patch:115: trailing whitespace.
> >>>>>>>>> .of_compatible = spider_board_of_match, };
> >>>>>>>>> error: corrupt patch at line 117
> >>>>>>>>>
> >>>>>>>>> After some digging I found that my Outlook probably messed with
> >> the
> >>>>>> patch
> >>>>>>>> format (even though I am using text only and no HTML format).
> >>>>>>>>> When I went to the web and copied the patch from there (mailing
> list
> >>>>>>>> archive) it was working well (i.e. no compilation error).
> >>>>>>>>>
> >>>>>>>>> Cheers,
> >>>>>>>>> Lior.
> >>>>>>>>>
> >>>>>>>>> -----Original Message-----
> >>>>>>>>> From: Ahmad Fatoum <ahmad@a3f.at>
> >>>>>>>>> Sent: Sunday, May 28, 2023 6:38 PM
> >>>>>>>>> To: barebox@lists.infradead.org
> >>>>>>>>> Cc: Lior Weintraub <liorw@pliops.com>
> >>>>>>>>> Subject: [PATCH v2] Porting barebox to a new SoC
> >>>>>>>>>
> >>>>>>>>> CAUTION: External Sender
> >>>>>>>>>
> >>>>>>>>> From: Lior Weintraub <liorw@pliops.com>
> >>>>>>>>>
> >>>>>>>>> Hi,
> >>>>>>>>>
> >>>>>>>>> I tried to follow the porting guide on https://ddec1-0-en-
> >>>>>>>>
> >>>>>>
> >>>>
> >>
> ctp.trendmicro.com:443/wis/clicktime/v1/query?url=https%3a%2f%2fwww.
> >>>>>>>>
> >>>>>>
> >>>>
> >>
> barebox.org%2fdoc%2flatest%2fdevel%2fporting.html%23&umid=60097eda
> >>>>>>>> -f136-45a1-9c8e-
> >>>>>>>>
> >> cf6a76e45cf8&auth=860a7ebb9feba264acc79b6e38eb59582349362c-
> >>>>>>>> 480ae23736add41c88ab8d30c090a75517ca7f9e but couldn't
> follow
> >>>> the
> >>>>>>>> instructions.
> >>>>>>>>> I would like to port barebox to a new SoC (which is not a derivative
> of
> >>>> any
> >>>>>>>> known SoC).
> >>>>>>>>> It has the following:
> >>>>>>>>> * Single Cortex A53
> >>>>>>>>> * SRAM (4MB) located on address 0xC000000000
> >>>>>>>>>
> >>>>>>>>> The below patch shows my initial test to try and have a starting
> point.
> >>>>>>>>> I am setting env variables:
> >>>>>>>>> export ARCH=arm64
> >>>>>>>>> export CROSS_COMPILE=/home/pliops/workspace/ARM/arm-
> gnu-
> >>>>>>>> toolchain/bin/aarch64-none-elf-
> >>>>>>>>>
> >>>>>>>>> Then I build with:
> >>>>>>>>> make spider_defconfig && make
> >>>>>>>>>
> >>>>>>>>> This gives an error:
> >>>>>>>>> aarch64-none-elf-gcc: error: unrecognized argument in option '-
> >>>>>> mabi=apcs-
> >>>>>>>> gnu'
> >>>>>>>>> aarch64-none-elf-gcc: note: valid arguments to '-mabi=' are: ilp32
> >> lp64
> >>>>>>>>> aarch64-none-elf-gcc: error: unrecognized command-line option '-
> >>>> msoft-
> >>>>>>>> float'
> >>>>>>>>> aarch64-none-elf-gcc: error: unrecognized command-line option '-
> >> mno-
> >>>>>>>> unaligned-access'
> >>>>>>>>> /home/pliops/workspace/simplest-linux-
> >>>>>>>> demo/barebox/scripts/Makefile.build:140: recipe for target
> >>>>>>>> 'scripts/mod/empty.o' failed
> >>>>>>>>> make[2]: *** [scripts/mod/empty.o] Error 1
> >>>>>>>>>
> >>>>>>>>> Not sure why the compiler flags get -mabi=apcs-gnu when I
> explicitly
> >> set
> >>>>>>>> CONFIG_CPU_V8 and the arch/arm/Makefile has:
> >>>>>>>>> ifeq ($(CONFIG_CPU_V8), y)
> >>>>>>>>> CFLAGS_ABI :=-mabi=lp64
> >>>>>>>>>
> >>>>>>>>> The changes I did:
> >>>>>>>>> >From 848b5f9b18bb1bb96d197cbc1b368ee0a729d581 Mon
> Sep
> >> 17
> >>>>>>>> 00:00:00 2001
> >>>>>>>>> ---
> >>>>>>>>> arch/arm/Kconfig | 13 ++++++++
> >>>>>>>>> arch/arm/Makefile | 1 +
> >>>>>>>>> arch/arm/boards/Makefile | 1 +
> >>>>>>>>> arch/arm/boards/spider-evk/Makefile | 4 +++
> >>>>>>>>> arch/arm/boards/spider-evk/board.c | 26 +++++++++++++++
> >>>>>>>>> arch/arm/boards/spider-evk/lowlevel.c | 30 +++++++++++++++++
> >>>>>>>>> arch/arm/configs/spider_defconfig | 8 +++++
> >>>>>>>>> arch/arm/dts/Makefile | 1 +
> >>>>>>>>> arch/arm/dts/spider-mk1-evk.dts | 10 ++++++
> >>>>>>>>> arch/arm/dts/spider-mk1.dtsi | 46
> >>>> +++++++++++++++++++++++++++
> >>>>>>>>> arch/arm/mach-spider/Kconfig | 16 ++++++++++
> >>>>>>>>> arch/arm/mach-spider/Makefile | 1 +
> >>>>>>>>> arch/arm/mach-spider/lowlevel.c | 14 ++++++++
> >>>>>>>>> images/Makefile | 1 +
> >>>>>>>>> images/Makefile.spider | 5 +++
> >>>>>>>>> include/mach/spider/lowlevel.h | 7 ++++
> >>>>>>>>> 16 files changed, 184 insertions(+)
> >>>>>>>>> create mode 100644 arch/arm/boards/spider-evk/Makefile
> >>>>>>>>> create mode 100644 arch/arm/boards/spider-evk/board.c
> >>>>>>>>> create mode 100644 arch/arm/boards/spider-evk/lowlevel.c
> >>>>>>>>> create mode 100644 arch/arm/configs/spider_defconfig create
> >> mode
> >>>>>>>> 100644 arch/arm/dts/spider-mk1-evk.dts create mode 100644
> >>>>>>>> arch/arm/dts/spider-mk1.dtsi create mode 100644
> arch/arm/mach-
> >>>>>>>> spider/Kconfig create mode 100644 arch/arm/mach-
> spider/Makefile
> >>>>>> create
> >>>>>>>> mode 100644 arch/arm/mach-spider/lowlevel.c create mode
> 100644
> >>>>>>>> images/Makefile.spider create mode 100644
> >>>>>> include/mach/spider/lowlevel.h
> >>>>>>>>>
> >>>>>>>>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index
> >>>>>>>> e76ee0f6dfe1..e5dcf128447e 100644
> >>>>>>>>> --- a/arch/arm/Kconfig
> >>>>>>>>> +++ b/arch/arm/Kconfig
> >>>>>>>>> @@ -255,6 +255,18 @@ config ARCH_ROCKCHIP
> >>>>>>>>> select HAS_DEBUG_LL
> >>>>>>>>> imply GPIO_ROCKCHIP
> >>>>>>>>>
> >>>>>>>>> +config ARCH_SPIDER
> >>>>>>>>> + bool "Pliops Spider based"
> >>>>>>>>> + depends on 64BIT
> >>>>>>>>> + depends on ARCH_MULTIARCH
> >>>>>>>>> + select GPIOLIB
> >>>>>>>>> + select HAVE_PBL_MULTI_IMAGES
> >>>>>>>>> + select COMMON_CLK
> >>>>>>>>> + select CLKDEV_LOOKUP
> >>>>>>>>> + select COMMON_CLK_OF_PROVIDER
> >>>>>>>>> + select OFTREE
> >>>>>>>>> + select OFDEVICE
> >>>>>>>>> +
> >>>>>>>>> config ARCH_STM32MP
> >>>>>>>>> bool "STMicroelectronics STM32MP"
> >>>>>>>>> depends on 32BIT
> >>>>>>>>> @@ -331,6 +343,7 @@ source "arch/arm/mach-omap/Kconfig"
> >>>>>>>>> source "arch/arm/mach-pxa/Kconfig"
> >>>>>>>>> source "arch/arm/mach-rockchip/Kconfig"
> >>>>>>>>> source "arch/arm/mach-socfpga/Kconfig"
> >>>>>>>>> +source "arch/arm/mach-spider/Kconfig"
> >>>>>>>>> source "arch/arm/mach-stm32mp/Kconfig"
> >>>>>>>>> source "arch/arm/mach-versatile/Kconfig"
> >>>>>>>>> source "arch/arm/mach-vexpress/Kconfig"
> >>>>>>>>> diff --git a/arch/arm/Makefile b/arch/arm/Makefile index
> >>>>>>>> 35ebc70f44e2..4c63dfee48f4 100644
> >>>>>>>>> --- a/arch/arm/Makefile
> >>>>>>>>> +++ b/arch/arm/Makefile
> >>>>>>>>> @@ -101,6 +101,7 @@ machine-$(CONFIG_ARCH_MXS) +=
> mxs
> >>>>>>>>> machine-$(CONFIG_ARCH_MVEBU) += mvebu
> >>>>>>>>> machine-$(CONFIG_ARCH_NOMADIK) += nomadik
> >>>>>>>>> machine-$(CONFIG_ARCH_OMAP) += omap
> >>>>>>>>> +machine-$(CONFIG_ARCH_SPIDER) += spider
> >>>>>>>>> machine-$(CONFIG_ARCH_PXA) += pxa
> >>>>>>>>> machine-$(CONFIG_ARCH_ROCKCHIP) += rockchip
> >>>>>>>>> machine-$(CONFIG_ARCH_SAMSUNG) += samsung
> >>>>>>>>> diff --git a/arch/arm/boards/Makefile
> b/arch/arm/boards/Makefile
> >>>> index
> >>>>>>>> 2877debad535..6fe0a90c81ea 100644
> >>>>>>>>> --- a/arch/arm/boards/Makefile
> >>>>>>>>> +++ b/arch/arm/boards/Makefile
> >>>>>>>>> @@ -135,6 +135,7 @@ obj-
> >>>>>>>> $(CONFIG_MACH_SOCFPGA_TERASIC_DE10_NANO) += terasic-
> >>>> de10-
> >>>>>>>> nano/
> >>>>>>>>> obj-$(CONFIG_MACH_SOCFPGA_TERASIC_SOCKIT) += terasic-
> >>>> sockit/
> >>>>>>>>> obj-$(CONFIG_MACH_SOLIDRUN_CUBOX) += solidrun-
> cubox/
> >>>>>>>>> obj-$(CONFIG_MACH_SOLIDRUN_MICROSOM) += solidrun-
> >>>>>>>> microsom/
> >>>>>>>>> +obj-$(CONFIG_MACH_SPIDER_MK1_EVK) += spider-evk/
> >>>>>>>>> obj-$(CONFIG_MACH_STM32MP15XX_DKX) +=
> >> stm32mp15xx-
> >>>>>> dkx/
> >>>>>>>>> obj-$(CONFIG_MACH_STM32MP13XX_DK) +=
> stm32mp13xx-
> >>>> dk/
> >>>>>>>>> obj-$(CONFIG_MACH_LXA_MC1) += lxa-mc1/
> >>>>>>>>> diff --git a/arch/arm/boards/spider-evk/Makefile
> >>>>>>>> b/arch/arm/boards/spider-evk/Makefile
> >>>>>>>>> new file mode 100644
> >>>>>>>>> index 000000000000..da63d2625f7a
> >>>>>>>>> --- /dev/null
> >>>>>>>>> +++ b/arch/arm/boards/spider-evk/Makefile
> >>>>>>>>> @@ -0,0 +1,4 @@
> >>>>>>>>> +# SPDX-License-Identifier: GPL-2.0-only
> >>>>>>>>> +
> >>>>>>>>> +obj-y += board.o
> >>>>>>>>> +lwl-y += lowlevel.o
> >>>>>>>>> diff --git a/arch/arm/boards/spider-evk/board.c
> >>>>>> b/arch/arm/boards/spider-
> >>>>>>>> evk/board.c
> >>>>>>>>> new file mode 100644
> >>>>>>>>> index 000000000000..3920e83b457d
> >>>>>>>>> --- /dev/null
> >>>>>>>>> +++ b/arch/arm/boards/spider-evk/board.c
> >>>>>>>>> @@ -0,0 +1,26 @@
> >>>>>>>>> +#include <bbu.h>
> >>>>>>>>> +#include <boot.h>
> >>>>>>>>> +#include <bootm.h>
> >>>>>>>>> +#include <common.h>
> >>>>>>>>> +#include <deep-probe.h>
> >>>>>>>>> +#include <environment.h>
> >>>>>>>>> +#include <fcntl.h>
> >>>>>>>>> +#include <globalvar.h>
> >>>>>>>>> +
> >>>>>>>>> +static int spider_board_probe(struct device *dev) {
> >>>>>>>>> + /* Do some board-specific setup */
> >>>>>>>>> + return 0;
> >>>>>>>>> +}
> >>>>>>>>> +
> >>>>>>>>> +static const struct of_device_id spider_board_of_match[] = {
> >>>>>>>>> + { .compatible = "pliops,spider-mk1-evk" },
> >>>>>>>>> + { /* sentinel */ },
> >>>>>>>>> +};
> >>>>>>>>> +
> >>>>>>>>> +static struct driver spider_board_driver = {
> >>>>>>>>> + .name = "board-spider",
> >>>>>>>>> + .probe = spider_board_probe,
> >>>>>>>>> + .of_compatible = spider_board_of_match, };
> >>>>>>>>> +device_platform_driver(spider_board_driver);
> >>>>>>>>> diff --git a/arch/arm/boards/spider-evk/lowlevel.c
> >>>>>>>> b/arch/arm/boards/spider-evk/lowlevel.c
> >>>>>>>>> new file mode 100644
> >>>>>>>>> index 000000000000..e36fcde4208e
> >>>>>>>>> --- /dev/null
> >>>>>>>>> +++ b/arch/arm/boards/spider-evk/lowlevel.c
> >>>>>>>>> @@ -0,0 +1,30 @@
> >>>>>>>>> +#include <common.h>
> >>>>>>>>> +#include <asm/barebox-arm.h>
> >>>>>>>>> +#include <mach/spider/lowlevel.h>
> >>>>>>>>> +
> >>>>>>>>> +#define BASE_ADDR (0xD000307000)
> >>>>>>>>> +#define GPRAM_ADDR (0xC000000000)
> >>>>>>>>> +#define MY_STACK_TOP (0xC000000000 + SZ_2M) // Set the
> stack
> >>>>>> 2MB
> >>>>>>>> from GPRAM start (excatly in the middle)
> >>>>>>>>> +static inline void spider_serial_putc(void *base, int c) {
> >>>>>>>>> +// if (!(readl(base + UCR1) & UCR1_UARTEN))
> >>>>>>>>> +// return;
> >>>>>>>>> +//
> >>>>>>>>> +// while (!(readl(base + USR2) & USR2_TXDC));
> >>>>>>>>> +//
> >>>>>>>>> +// writel(c, base + URTX0);
> >>>>>>>>> +}
> >>>>>>>>> +
> >>>>>>>>> +ENTRY_FUNCTION_WITHSTACK(start_spider_mk1_evk,
> >>>> MY_STACK_TOP,
> >>>>>>>> r0, r1,
> >>>>>>>>> +r2) {
> >>>>>>>>> + extern char __dtb_spider_mk1_evk_start[];
> >>>>>>>>> +
> >>>>>>>>> + spider_lowlevel_init();
> >>>>>>>>> +
> >>>>>>>>> + relocate_to_current_adr();
> >>>>>>>>> + setup_c();
> >>>>>>>>> +
> >>>>>>>>> + pbl_set_putc(spider_serial_putc, (void *)BASE_ADDR);
> >>>>>>>>> +
> >>>>>>>>> + barebox_arm_entry(GPRAM_ADDR, SZ_2M,
> >>>>>>>>> +__dtb_spider_mk1_evk_start); }
> >>>>>>>>> diff --git a/arch/arm/configs/spider_defconfig
> >>>>>>>> b/arch/arm/configs/spider_defconfig
> >>>>>>>>> new file mode 100644
> >>>>>>>>> index 000000000000..c91bb889d97f
> >>>>>>>>> --- /dev/null
> >>>>>>>>> +++ b/arch/arm/configs/spider_defconfig
> >>>>>>>>> @@ -0,0 +1,8 @@
> >>>>>>>>> +CONFIG_ARCH_SPIDER=y
> >>>>>>>>> +CONFIG_MACH_SPIDER_MK1_EVK=y
> >>>>>>>>> +CONFIG_BOARD_ARM_GENERIC_DT=y
> >>>>>>>>> +CONFIG_MALLOC_TLSF=y
> >>>>>>>>> +CONFIG_KALLSYMS=y
> >>>>>>>>> +CONFIG_RELOCATABLE=y
> >>>>>>>>> +CONFIG_CONSOLE_ALLOW_COLOR=y
> >>>>>>>>> +CONFIG_PBL_CONSOLE=y
> >>>>>>>>> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile index
> >>>>>>>> 98f4c4e0194b..94b304d4878f 100644
> >>>>>>>>> --- a/arch/arm/dts/Makefile
> >>>>>>>>> +++ b/arch/arm/dts/Makefile
> >>>>>>>>> @@ -134,6 +134,7 @@ lwl-$(CONFIG_MACH_SOLIDRUN_CUBOX)
> >> +=
> >>>>>> dove-
> >>>>>>>> cubox-bb.dtb.o
> >>>>>>>>> lwl-$(CONFIG_MACH_SOLIDRUN_MICROSOM) += imx6dl-
> >>>>>>>> hummingboard.dtb.o imx6q-hummingboard.dtb.o \
> >>>>>>>>> imx6dl-hummingboard2.dtb.o imx6q-
> >>>>>>>> hummingboard2.dtb.o \
> >>>>>>>>> imx6q-h100.dtb.o
> >>>>>>>>> +lwl-$(CONFIG_MACH_SPIDER_MK1_EVK) += spider-mk1-
> evk.dtb.o
> >>>>>>>>> lwl-$(CONFIG_MACH_SKOV_IMX6) += imx6s-skov-imx6.dtb.o
> >> imx6dl-
> >>>>>> skov-
> >>>>>>>> imx6.dtb.o imx6q-skov-imx6.dtb.o
> >>>>>>>>> lwl-$(CONFIG_MACH_SKOV_ARM9CPU) += at91-skov-
> >> arm9cpu.dtb.o
> >>>>>>>>> lwl-$(CONFIG_MACH_SEEED_ODYSSEY) += stm32mp157c-
> >>>> odyssey.dtb.o
> >>>>>>>> diff --git a/arch/arm/dts/spider-mk1-evk.dts
> b/arch/arm/dts/spider-
> >>>> mk1-
> >>>>>>>> evk.dts new file mode 100644 index
> 000000000000..b8081cb85bf8
> >>>>>>>>> --- /dev/null
> >>>>>>>>> +++ b/arch/arm/dts/spider-mk1-evk.dts
> >>>>>>>>> @@ -0,0 +1,10 @@
> >>>>>>>>> +// SPDX-License-Identifier: GPL-2.0 OR X11
> >>>>>>>>> +
> >>>>>>>>> +/dts-v1/;
> >>>>>>>>> +
> >>>>>>>>> +#include "spider-mk1.dtsi"
> >>>>>>>>> +
> >>>>>>>>> +/ {
> >>>>>>>>> + model = "Pliops Spider MK-I EVK";
> >>>>>>>>> + compatible = "pliops,spider-mk1-evk"; };
> >>>>>>>>> diff --git a/arch/arm/dts/spider-mk1.dtsi b/arch/arm/dts/spider-
> >>>> mk1.dtsi
> >>>>>>>> new file mode 100644 index 000000000000..d4613848169d
> >>>>>>>>> --- /dev/null
> >>>>>>>>> +++ b/arch/arm/dts/spider-mk1.dtsi
> >>>>>>>>> @@ -0,0 +1,46 @@
> >>>>>>>>> +// SPDX-License-Identifier: GPL-2.0 OR X11
> >>>>>>>>> +
> >>>>>>>>> +/ {
> >>>>>>>>> + #address-cells = <2>;
> >>>>>>>>> + #size-cells = <2>;
> >>>>>>>>> +
> >>>>>>>>> + chosen {
> >>>>>>>>> + stdout-path = &uart0;
> >>>>>>>>> + };
> >>>>>>>>> +
> >>>>>>>>> + aliases {
> >>>>>>>>> + serial0 = &uart0;
> >>>>>>>>> + };
> >>>>>>>>> +
> >>>>>>>>> + cpus {
> >>>>>>>>> + #address-cells = <1>;
> >>>>>>>>> + #size-cells = <0>;
> >>>>>>>>> +
> >>>>>>>>> + cpu0: cpu@0 {
> >>>>>>>>> + device_type = "cpu";
> >>>>>>>>> + compatible = "arm,cortex-a53";
> >>>>>>>>> + reg = <0x0>;
> >>>>>>>>> + };
> >>>>>>>>> + };
> >>>>>>>>> +
> >>>>>>>>> + memory@1000000 {
> >>>>>>>>> + reg = <0x0 0x1000000 0x0 0x400000>; /* 128M */
> >>>>>>>>> + device_type = "memory";
> >>>>>>>>> + };
> >>>>>>>>> +
> >>>>>>>>> + soc {
> >>>>>>>>> + #address-cells = <2>;
> >>>>>>>>> + #size-cells = <2>;
> >>>>>>>>> + ranges;
> >>>>>>>>> +
> >>>>>>>>> + sram@c000000000 {
> >>>>>>>>> + compatible = "mmio-sram";
> >>>>>>>>> + reg = <0xc0 0x0 0x0 0x400000>;
> >>>>>>>>> + };
> >>>>>>>>> +
> >>>>>>>>> + uart0: serial@d000307000 {
> >>>>>>>>> + compatible = "pliops,spider-uart";
> >>>>>>>>> + reg = <0xd0 0x307000 0 0x1000>;
> >>>>>>>>> + };
> >>>>>>>>> + };
> >>>>>>>>> +};
> >>>>>>>>> diff --git a/arch/arm/mach-spider/Kconfig b/arch/arm/mach-
> >>>>>> spider/Kconfig
> >>>>>>>> new file mode 100644 index 000000000000..6d2f888a5fd8
> >>>>>>>>> --- /dev/null
> >>>>>>>>> +++ b/arch/arm/mach-spider/Kconfig
> >>>>>>>>> @@ -0,0 +1,16 @@
> >>>>>>>>> +# SPDX-License-Identifier: GPL-2.0-only
> >>>>>>>>> +
> >>>>>>>>> +if ARCH_SPIDER
> >>>>>>>>> +
> >>>>>>>>> +config ARCH_SPIDER_MK1
> >>>>>>>>> + bool
> >>>>>>>>> + select CPU_V8
> >>>>>>>>> + help
> >>>>>>>>> + The first Cortex-A53-based SoC of the spider family.
> >>>>>>>>> + This symbol is invisble and select by boards
> >>>>>>>>> +
> >>>>>>>>> +config MACH_SPIDER_MK1_EVK
> >>>>>>>>> + bool "Pliops Spider Reference Design Board"
> >>>>>>>>> + select ARCH_SPIDER_MK1
> >>>>>>>>> +
> >>>>>>>>> +endif
> >>>>>>>>> diff --git a/arch/arm/mach-spider/Makefile b/arch/arm/mach-
> >>>>>>>> spider/Makefile new file mode 100644 index
> >>>>>> 000000000000..b08c4a93ca27
> >>>>>>>>> --- /dev/null
> >>>>>>>>> +++ b/arch/arm/mach-spider/Makefile
> >>>>>>>>> @@ -0,0 +1 @@
> >>>>>>>>> +lwl-y += lowlevel.o
> >>>>>>>>> diff --git a/arch/arm/mach-spider/lowlevel.c b/arch/arm/mach-
> >>>>>>>> spider/lowlevel.c new file mode 100644 index
> >>>>>>>> 000000000000..5d62ef0f39e5
> >>>>>>>>> --- /dev/null
> >>>>>>>>> +++ b/arch/arm/mach-spider/lowlevel.c
> >>>>>>>>> @@ -0,0 +1,14 @@
> >>>>>>>>> +// SPDX-License-Identifier: GPL-2.0+
> >>>>>>>>> +
> >>>>>>>>> +#include <linux/types.h>
> >>>>>>>>> +#include <mach/spider/lowlevel.h>
> >>>>>>>>> +#include <asm/barebox-arm-head.h>
> >>>>>>>>> +
> >>>>>>>>> +void spider_lowlevel_init(void)
> >>>>>>>>> +{
> >>>>>>>>> + arm_cpu_lowlevel_init();
> >>>>>>>>> + /*
> >>>>>>>>> + * not yet relocated, only do writel/readl for stuff that's
> >>>>>>>>> + * critical to run early. No global variables allowed.
> >>>>>>>>> + */
> >>>>>>>>> +}
> >>>>>>>>> diff --git a/images/Makefile b/images/Makefile index
> >>>>>>>> c93f9e268978..97521e713228 100644
> >>>>>>>>> --- a/images/Makefile
> >>>>>>>>> +++ b/images/Makefile
> >>>>>>>>> @@ -150,6 +150,7 @@ include $(srctree)/images/Makefile.mxs
> >>>> include
> >>>>>>>> $(srctree)/images/Makefile.omap3 include
> >>>>>>>> $(srctree)/images/Makefile.rockchip
> >>>>>>>>> include $(srctree)/images/Makefile.socfpga
> >>>>>>>>> +include $(srctree)/images/Makefile.spider
> >>>>>>>>> include $(srctree)/images/Makefile.stm32mp
> >>>>>>>>> include $(srctree)/images/Makefile.tegra include
> >>>>>>>> $(srctree)/images/Makefile.versatile
> >>>>>>>>> diff --git a/images/Makefile.spider b/images/Makefile.spider new
> file
> >>>>>> mode
> >>>>>>>> 100644 index 000000000000..c32f2762df04
> >>>>>>>>> --- /dev/null
> >>>>>>>>> +++ b/images/Makefile.spider
> >>>>>>>>> @@ -0,0 +1,5 @@
> >>>>>>>>> +# SPDX-License-Identifier: GPL-2.0-only
> >>>>>>>>> +
> >>>>>>>>> +pblb-$(CONFIG_MACH_SPIDER_MK1_EVK) +=
> >> start_spider_mk1_evk
> >>>>>>>>> +FILE_barebox-spider-mk1-evk.img = start_spider_mk1_evk.pblb
> >>>>>>>>> +image-$(CONFIG_MACH_SPIDER_MK1_EVK) += barebox-spider-
> >> mk1-
> >>>>>>>> evk.img
> >>>>>>>>> diff --git a/include/mach/spider/lowlevel.h
> >>>>>>>> b/include/mach/spider/lowlevel.h new file mode 100644 index
> >>>>>>>> 000000000000..6e0ce1c77f7e
> >>>>>>>>> --- /dev/null
> >>>>>>>>> +++ b/include/mach/spider/lowlevel.h
> >>>>>>>>> @@ -0,0 +1,7 @@
> >>>>>>>>> +/* SPDX-License-Identifier: GPL-2.0+ */ #ifndef
> __MACH_SPIDER_H_
> >>>>>>>>> +#define __MACH_SPIDER_H_
> >>>>>>>>> +
> >>>>>>>>> +void spider_lowlevel_init(void);
> >>>>>>>>> +
> >>>>>>>>> +#endif
> >>>>>>>>> --
> >>>>>>>>> 2.38.4
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> --
> >>>>>>>> Pengutronix e.K. | |
> >>>>>>>> Steuerwalder Str. 21 | http://www.pengutronix.de/ |
> >>>>>>>> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0
> >> |
> >>>>>>>> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-
> >> 5555
> >>>> |
> >>>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> Pengutronix e.K. | |
> >>>>>> Steuerwalder Str. 21 | http://www.pengutronix.de/ |
> >>>>>> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0
> |
> >>>>>> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-
> 5555
> >> |
> >>>>>
> >>>>
> >>>> --
> >>>> Pengutronix e.K. | |
> >>>> Steuerwalder Str. 21 | http://www.pengutronix.de/ |
> >>>> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
> >>>> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555
> |
> >>>
> >>
> >> --
> >> Pengutronix e.K. | |
> >> Steuerwalder Str. 21 | http://www.pengutronix.de/ |
> >> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
> >> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
> >
>
> --
> Pengutronix e.K. | |
> Steuerwalder Str. 21 | http://www.pengutronix.de/ |
> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [PATCH v2] Porting barebox to a new SoC
2023-06-01 11:45 ` Lior Weintraub
@ 2023-06-01 12:35 ` Ahmad Fatoum
2023-06-06 12:54 ` Lior Weintraub
0 siblings, 1 reply; 40+ messages in thread
From: Ahmad Fatoum @ 2023-06-01 12:35 UTC (permalink / raw)
To: Lior Weintraub, Ahmad Fatoum, barebox
Hello Lior,
On 01.06.23 13:45, Lior Weintraub wrote:
> Hello Ahmad,
>
> Very interesting stuff.
>
> We actually did started TF-A integration few months ago and tested it on the QEMU running ARM virt machine.
> The TF-A compilation didn't include BL31 image (probably this explains the "ERROR: BL2: Failed to load image id 3").
I wouldn't recommend using TF-A as BL2. I am quite content with how
it's done on NXP's i.MX SoCs, which is the flow I described at the
end of my last mail. Instead of loading a FIP, TF-A would just
return to DRAM (or maintain LR on TF-A entry and return to it).
> For this code to run we used the following QEMU command:
>
> qemu-system-aarch64 -nographic -machine virt,secure=on -cpu cortex-a53,rvbar=0x0000000000 \
> -smp 1 -m 1024 -bios bl1.bin -d unimp -semihosting-config enable=on,target=native \
> -monitor telnet:localhost:1235,server,nowait -gdb tcp::1236
>
> Output:
> NOTICE: bl1_early_platform_set
> NOTICE: Booting Trusted Firmware
> NOTICE: BL1: v2.7(debug):831de6588
> NOTICE: BL1: Built : 12:40:08, May 28 2023
> INFO: BL1: RAM 0xe0ee000 - 0xe0f6000
> INFO: BL1: cortex_a53: CPU workaround for 835769 was applied
> INFO: BL1: cortex_a53: CPU workaround for 843419 was applied
> INFO: BL1: cortex_a53: CPU workaround for 855873 was applied
> INFO: BL1: cortex_a53: CPU workaround for 1530924 was applied
> INFO: BL1: Loading BL2
> WARNING: Firmware Image Package header check failed.
> INFO: Loading image id=1 at address 0xe07b000
> INFO: Image id=1 loaded: 0xe07b000 - 0xe081201
> NOTICE: BL1: Booting BL2
> INFO: Entry point address = 0xe07b000
> INFO: SPSR = 0x3c5
> NOTICE: BL2: v2.7(debug):831de6588
> NOTICE: BL2: Built : 12:40:08, May 28 2023
> INFO: BL2: Doing platform setup
> INFO: BL2: Loading image id 3
> WARNING: Firmware Image Package header check failed.
> WARNING: Failed to obtain reference to image id=3 (-2)
> ERROR: BL2: Failed to load image id 3 (-2)
>
> When we tried to modify the TF-A code to use our SoC (e.g. change the start address to 0xC0_0400_0000 and use UART on 0xD0_0030_7000) it crashed with seg. Fault.
Try building your BL31 as position-independent executable. The code doing
fixed text area may be hardcoded to 32-bit. See here for an example
of turning on PIE:
https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/16370
> We didn't continue with this development effort and decided we will write our own BootROM as BL1
Ye, I don't think TF-A is a good candidate for a BL1 (are there even
other users that user TF-A that way?).
> and use that to load u-boot or barebox
That's ok. You just need BL31 to provide you runtime services (or maintain your
Linux SoC support patches for ever).
> Now I understand we better go back and study how to port TF-A to our SoC.
:)
Cheers,
Ahmad
>
> Cheers,
> Lior.
>
>
>> -----Original Message-----
>> From: Ahmad Fatoum <a.fatoum@pengutronix.de>
>> Sent: Thursday, June 1, 2023 12:29 PM
>> To: Lior Weintraub <liorw@pliops.com>; Ahmad Fatoum <ahmad@a3f.at>;
>> barebox@lists.infradead.org
>> Subject: Re: [PATCH v2] Porting barebox to a new SoC
>>
>> CAUTION: External Sender
>>
>> Hello Lior,
>>
>> On 01.06.23 10:54, Lior Weintraub wrote:
>>> Hi Ahmad,
>>>
>>> Thanks again for your great support and the patch.
>>> I've checked it and it works perfectly!
>>> The UART issue was solved after fixing the device tree per your
>> recommendations.
>>> Now I can write into barbox terminal :-)
>>
>> Nice!
>>
>>> When I type "cpuinfo" on the terminal I am getting:
>>> implementer: ARM
>>> architecture: v8
>>> core: Cortex-A53 r0p4
>>> exception level: 3
>>> cache: no cache
>>> Control register: P D Z DT IT U XP
>>
>> FYI, barebox next (or maybe master?) branch adds mmuinfo command to
>> arm64.
>> You can use that to check if a specific address is cached or not.
>>
>>> Notice that it say "no cache".
>>> I tried to add cache to cpu0 but it didn't help.
>>>
>>> .
>>> .
>>> d-cache-size = <0x8000>;
>>> d-cache-line-size = <64>;
>>> d-cache-sets = <128>; // 32KiB(size)/64(line-size)=512ways/4-way set
>>> i-cache-size = <0x8000>;
>>> i-cache-line-size = <64>;
>>> i-cache-sets = <256>; // 32KiB(size)/64(line-size)=512ways/2-way set
>>> next-level-cache = <&l2>;
>>> };
>>>
>>> l2: l2-cache0 {
>>> compatible = "cache";
>>> cache-unified;
>>> cache-size = <0x80000>;
>>> cache-line-size = <64>;
>>> cache-sets = <512>; // 512KiB(size)/64(line-size)=8192ways/16-way set
>>> cache-level = <2>;
>>> }
>>
>> barebox doesn't consume these nodes. What may be happening is that
>> cpuinfo
>> was written with the assumption that barebox executes at EL2 or EL1, so
>> executing it at EL3 may end up accessing the wrong MSRs. Feel free to send
>> a patch against arch/arm/cpu/cpuinfo.c, so it uses the correct register for
>> EL3. current_el() will tell you which EL you are at.
>>
>>> Regarding Linux kernel:
>>> This would be the next step but I assume that it would be a bit more
>> complicated.
>>
>> Linux ARM64 Maintainers mandate that platforms implement the PSCI
>> protocol.
>> In your case with single core that means providing reset and poweroff
>> handlers
>> that the kernel can invoke via secure monitor call.
>>
>> barebox can consume psci: CONFIG_ARM_PSCI_CLIENT, CONFIG_CMD_SMC,
>> but what
>> you're missing is the provider side. barebox as PSCI provider is implemented
>> only for a single ARM32 SoC, the i.MX7. All supported ARM64 platforms use
>> TF-A as BL31 with the exception of Layerscape (which uses PPA, an NXP BL31
>> implementation).
>>
>> What does this mean for you?
>>
>> 1) Either add your SoC to TF-A
>> 2) Extend PSCI implementation in barebox for ARM64.
>>
>> While I think it would be cool to have barebox provide all of BL2, BL31 and
>> BL32, I think you are better advised to use TF-A, because that's what most
>> other ARM Silicon Vendors use. That means less effort for you and easier
>> maintenance as you benefit from fixes done for other SoCs using the same
>> IPs. barebox certainly benefits from being able to focus on being a bootloader
>> and leaving the errata workarounds, GIC init stuff and runtime services
>> to TF-A.
>>
>> The boot flow would then be:
>>
>> - barebox PBL runs as BL2 in SRAM and sets up DRAM
>> - barebox PBL executes BL31 (TF-A) which was compiled into PBL
>> - TF-A installs secure monitor and returns control to DRAM in EL2
>> - barebox resumes execution in EL2 as BL33
>> - Linux is invoked in EL2 and can communicate with secure monitor.
>>
>> You may find this talk interesting:
>> https://fosdem.org/2023/schedule/event/uboot_psci/
>> Even if I disagree a bit with the takeaway.
>>
>>> I guess we will have to integrate the interrupt controlled (GIC-600) into
>> QEMU and into the device tree for it to work.
>>> Is that a valid assumption?
>>
>> I never had to add a new SoC to Linux, so I can't give any better
>> suggestions than Yes. Where you're going, you'll need interrupts.
>>
>> Godspeed and keep me posted :)
>> Ahmad
>>
>>>
>>> Thanks,
>>> Lior.
>>>
>>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: Ahmad Fatoum <a.fatoum@pengutronix.de>
>>>> Sent: Wednesday, May 31, 2023 8:55 PM
>>>> To: Lior Weintraub <liorw@pliops.com>; Ahmad Fatoum <ahmad@a3f.at>;
>>>> barebox@lists.infradead.org
>>>> Subject: Re: [PATCH v2] Porting barebox to a new SoC
>>>>
>>>> CAUTION: External Sender
>>>>
>>>> Hi Lior,
>>>>
>>>> On 31.05.23 18:13, Lior Weintraub wrote:
>>>>> Hi Ahmad,
>>>>>
>>>>> Using end of SRAM as PBL stack is currently not working because we need
>>>> 40bit address (0xC0_0020_0000).
>>>>> This needs a fix to ENTRY_FUNCTION_WITHSTACK macro.
>>>>
>>>> Ah, right. I just sent an (untested) patch. Would be cool if you could
>>>> try it out.
>>>>
>>>>> I tried just to change const u32 __stack_top = (stack_top); to const u64
>>>> __stack_top = (stack_top); but there were linking errors caused by:
>>>>> ASSERT(. - __pbl_board_stack_top <= 8, "Only One PBL per Image
>> allowed")
>>>>
>>>> The easy way would have been using a __attribute__((naked)) function,
>> but
>>>> those are only supported for arm32, not arm64. The alternative is thus
>>>> writing the entry point in assembly and to make board authors life easier
>>>> the linker script ensures that the stack setup entry point is invoked prior
>>>> to the board entry.
>>>>
>>>>> Regarding the arm timer:
>>>>> Adding the timer entry to DT solved the issue.
>>>>>
>>>>> Regarding the UART:
>>>>> Indeed CONFIG_SERIAL_AMBA_PL011 was set on spider_defconfig (also
>>>> verified it generated the correct entry on .config).
>>>>> I also noticed that if I remove the putc_ll implementation there is no Tx at
>> all
>>>> from Barebox.
>>>>
>>>> I've led you astray. Indeed:
>>>>
>>>>>>> of_platform_bus_create() - skipping /soc, no compatible prop
>>>>
>>>> points at the issue.
>>>>
>>>> Try adding into /soc
>>>>
>>>> compatible = "simple,bus";
>>>> ranges;
>>>> dma-ranges;
>>>>
>>>> This matches /soc with the simple bus driver which just instantiates devices
>>>> for the
>>>> contained children. Those in turn should be matched by the drivers.
>>>>
>>>> The ranges stuff just tells that memory and SoC peripherals exist in the
>> same
>>>> address space.
>>>>
>>>> When it probes you may need to describe the clock in the DT. Eventually,
>> you
>>>> will
>>>> want to have a clock driver for your hardware (good news: barebox and
>> Linux
>>>> have
>>>> basically the same API, so you only need to write it once). But for now, you
>>>> can
>>>> fake it using fixed-clock in the DT. Take a look at:
>>>>
>>>> snps,dw-apb-uart in arch/riscv/dts/jh7100.dtsi and compare with
>>>> dts/src/arm/imx28.dtsi
>>>> to see how to map that to PL011.
>>>>
>>>>> Could it be a hint?
>>>>
>>>> DEBUG_LL bridges the gap until a driver registers a console that's enabled. If
>>>> this
>>>> never happens, you are left with a non-interactive shell.
>>>>
>>>> Cheers,
>>>> Ahmad
>>>>
>>>>>
>>>>> Thanks,
>>>>> Lior.
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Ahmad Fatoum <a.fatoum@pengutronix.de>
>>>>>> Sent: Wednesday, May 31, 2023 11:40 AM
>>>>>> To: Lior Weintraub <liorw@pliops.com>; Ahmad Fatoum
>> <ahmad@a3f.at>;
>>>>>> barebox@lists.infradead.org
>>>>>> Subject: Re: [PATCH v2] Porting barebox to a new SoC
>>>>>>
>>>>>> CAUTION: External Sender
>>>>>>
>>>>>> Hi Lior,
>>>>>>
>>>>>> On 31.05.23 10:05, Lior Weintraub wrote:
>>>>>>> Hi Ahmad,
>>>>>>>
>>>>>>> Thanks again for your prompt reply and accurate tips!
>>>>>>> Took the following changes:
>>>>>>> 1. Increasing the DRAM size to 128MB (let barebox start from 0).
>>>>>>> 2. Set PBL stack to offset 2MB from DRAM
>>>>>>
>>>>>> Just use end of SRAM, so you are completely independent of DRAM
>>>>>> until you call barebox_arm_entry.
>>>>>>
>>>>>>> 3. Fix the device tree "memory" entry to have 128MB.
>>>>>>
>>>>>> (y)
>>>>>>
>>>>>>> 4. Load barebox-spider-mk1-evk.img to SRAM and run from there.
>>>>>>>
>>>>>>> Now I can see the following logs:
>>>>>>> uncompress.c: memory at 0x00000000, size 0x08000000
>>>>>>> uncompress.c: uncompressing barebox binary at 0x000000c0000021c0
>>>>>> (size 0x0001e3a4) to 0x07e00000 (uncompressed size: 0x000390d0)
>>>>>>> uncompress.c: jumping to uncompressed image at
>>>> 0x0000000007e00000
>>>>>>> start.c: memory at 0x00000000, size 0x08000000
>>>>>>> start.c: found DTB in boarddata, copying to 0x07dffcc0
>>>>>>> start.c: initializing malloc pool at 0x079ffcc0 (size 0x00400000)
>>>>>>> start.c: starting barebox...
>>>>>>> initcall-> command_slice_init+0x0/0x3c
>>>>>>> initcall-> globalvar_init+0x0/0x80
>>>>>>> register_device: global
>>>>>>> register_device: nv
>>>>>>> initcall-> platform_init+0x0/0x1c
>>>>>>> register_device: platform
>>>>>>> initcall-> amba_bus_init+0x0/0x1c
>>>>>>> register_device: amba
>>>>>>> initcall-> spi_bus_init+0x0/0x1c
>>>>>>> register_device: spi
>>>>>>> initcall-> gpio_desc_alloc+0x0/0x24
>>>>>>> initcall-> fs_bus_init+0x0/0x1c
>>>>>>> register_device: fs
>>>>>>> initcall-> aarch64_init_vectors+0x0/0x50
>>>>>>> initcall-> gpio_gate_clock_driver_register+0x0/0x1c
>>>>>>> register_driver: gpio-gate-clock
>>>>>>> initcall-> of_arm_init+0x0/0x5c
>>>>>>> start.c: barebox_arm_boot_dtb: using barebox_boarddata
>>>>>>> using boarddata provided DTB
>>>>>>> adding DT alias:serial0: stem=serial id=0
>> node=/soc/serial@d000307000
>>>>>>> register_device: machine
>>>>>>> of_platform_bus_create() - skipping /chosen, no compatible prop
>>>>>>> of_platform_bus_create() - skipping /aliases, no compatible prop
>>>>>>> of_platform_bus_create() - skipping /cpus, no compatible prop
>>>>>>> of_platform_bus_create() - skipping /memory@0, no compatible prop
>>>>>>> of_platform_bus_create() - skipping /soc, no compatible prop
>>>>>>> initcall-> register_autoboot_vars+0x0/0x70
>>>>>>> initcall-> arm_arch_timer_driver_register+0x0/0x1c
>>>>>>> register_driver: arm-architected-timer
>>>>>>> initcall-> of_timer_init+0x0/0x20
>>>>>>> initcall-> init_fs+0x0/0x3c
>>>>>>> initcall-> pl011_driver_register+0x0/0x1c
>>>>>>> register_driver: uart-pl011
>>>>>>> initcall-> of_stdoutpath_init+0x0/0x28
>>>>>>> initcall-> of_probe_memory+0x0/0x60
>>>>>>> __request_region ok: 0x00000000:0x07ffffff flags=0x0
>>>>>>> initcall-> __bare_init_end+0x0/0x6c
>>>>>>> register_device: mem0
>>>>>>> initcall-> of_reserved_mem_walk+0x0/0x1ac
>>>>>>> initcall-> mem_malloc_resource+0x0/0xa8
>>>>>>> __request_region ok: 0x079ffcc0:0x07dffcbf flags=0x200
>>>>>>> __request_region ok: 0x07e00000:0x07e2aeff flags=0x200
>>>>>>> __request_region ok: 0x07e2af00:0x07e390cf flags=0x200
>>>>>>> __request_region ok: 0x07e390d0:0x07e3adaf flags=0x200
>>>>>>> initcall-> bootsource_init+0x0/0x40
>>>>>>> initcall-> ramfs_init+0x0/0x1c
>>>>>>> register_driver: ramfs
>>>>>>> initcall-> devfs_init+0x0/0x1c
>>>>>>> register_driver: devfs
>>>>>>> initcall-> arm_request_stack+0x0/0x398
>>>>>>> __request_region ok: 0x07ff0000:0x07ff7fff flags=0x200
>>>>>>> initcall-> mount_root+0x0/0x7c
>>>>>>> mount: none on / type ramfs, options=
>>>>>>> register_device: ramfs0
>>>>>>> probe-> ramfs0
>>>>>>> mount: none on /dev type devfs, options=
>>>>>>> register_device: devfs0
>>>>>>> probe-> devfs0
>>>>>>> initcall-> binfmt_sh_init+0x0/0x1c
>>>>>>> initcall-> binfmt_uimage_init+0x0/0x1c
>>>>>>> initcall-> console_common_init+0x0/0x48
>>>>>>> initcall-> of_kernel_init+0x0/0x28
>>>>>>> initcall-> console_ctrlc_init+0x0/0x30
>>>>>>> initcall-> mem_init+0x0/0x90
>>>>>>> register_device: mem1
>>>>>>> register_driver: mem
>>>>>>> probe-> mem0
>>>>>>> probe-> mem1
>>>>>>> initcall-> of_partition_init+0x0/0x48
>>>>>>> initcall-> prng_init+0x0/0x40
>>>>>>> initcall-> null_init+0x0/0x40
>>>>>>> initcall-> full_init+0x0/0x40
>>>>>>> initcall-> zero_init+0x0/0x40
>>>>>>> initcall-> spider_board_driver_register+0x0/0x1c
>>>>>>> register_driver: board-spider
>>>>>>> probe-> machine
>>>>>>> initcall-> barebox_memory_areas_init+0x0/0x40
>>>>>>> __request_region ok: 0x07dffcc0:0x07dfffce flags=0x200
>>>>>>> initcall-> barebox_of_populate+0x0/0x28
>>>>>>> initcall-> of_register_memory_fixup+0x0/0x20
>>>>>>> initcall-> dummy_csrc_warn+0x0/0x44
>>>>>>> WARNING: Warning: Using dummy clocksource
>>>>>>
>>>>>> Add a arm,armv8-timer node into your SoC device tree.
>>>>>> This lets barebox and Linux know that you have the ARM
>>>>>> architected timer available. Without that, you'll notice
>>>>>> that timeouts are wrong.
>>>>>>
>>>>>>> initcall-> bootm_init+0x0/0xf4
>>>>>>> initcall-> init_command_list+0x0/0x40
>>>>>>> register command bootm
>>>>>>> register command cat
>>>>>>> register command cd
>>>>>>> register command clear
>>>>>>> register command cp
>>>>>>> register command cpuinfo
>>>>>>> register command devinfo
>>>>>>> register command drvinfo
>>>>>>> register command echo
>>>>>>> register command exit
>>>>>>> register command false
>>>>>>> register command help
>>>>>>> register command ?
>>>>>>> register command ll
>>>>>>> register command ls
>>>>>>> register command md
>>>>>>> register command memcmp
>>>>>>> register command memcpy
>>>>>>> register command memset
>>>>>>> register command mkdir
>>>>>>> register command mount
>>>>>>> register command mw
>>>>>>> register command pwd
>>>>>>> register command rm
>>>>>>> register command rmdir
>>>>>>> register command setenv
>>>>>>> register command sh
>>>>>>> register command source
>>>>>>> register command .
>>>>>>> register command test
>>>>>>> register command [
>>>>>>> register command true
>>>>>>> register command :
>>>>>>> register command umount
>>>>>>> register command version
>>>>>>> initcall-> display_meminfo+0x0/0xa8
>>>>>>> barebox code: 0x7e00000 -> 0x7e2aeff
>>>>>>> bss segment: 0x7e390d0 -> 0x7e3adaf
>>>>>>> malloc space: 0x079ffcc0 -> 0x07dffcbf (size 4 MiB)
>>>>>>> initcall-> of_register_bootargs_fixup+0x0/0x3c
>>>>>>> initcall-> device_probe_deferred+0x0/0x14c
>>>>>>> initcall-> of_init_hostname+0x0/0x28
>>>>>>> initcall-> aarch64_register_image_handler+0x0/0x2c
>>>>>>> initcall-> load_environment+0x0/0x4c
>>>>>>> loading defaultenv
>>>>>>> environment load /dev/env0: No such file or directory
>>>>>>> Maybe you have to create the partition.
>>>>>>> initcalls done
>>>>>>>
>>>>>>> Hit any to stop autoboot: 0
>>>>>>> boot: No such file or directory
>>>>>>> barebox:/
>>>>>>>
>>>>>>>
>>>>>>> Few questions:
>>>>>>> 1. The serial input doesn't work. i.e. I cannot type anything hence
>> cannot
>>>>>> interact with barebox terminal.
>>>>>>
>>>>>> DEBUG_LL only does otuput. For input, you will want to load the driver.
>>>>>> Do you have CONFIG_SERIAL_AMBA_PL011 enabled?
>>>>>>
>>>>>>> Does it require GIC and setting interrupts for it to work?
>>>>>>
>>>>>> No interrupts needed. barebox runs with interrupts disabled and
>>>> everything
>>>>>> is done cooperatively.
>>>>>>
>>>>>>> 2. What does "of_platform_bus_create() - skipping" means? Do I need
>> to
>>>> fix
>>>>>> that?
>>>>>>
>>>>>> That's normal debugging output. Some device tree nodes are busses,
>> which
>>>>>> have
>>>>>> children. These entries are skipped because they have no compatible.
>> This is
>>>>>> expected. I'd suggest you remove your VERBOSED_DEBUG define, so you
>>>> are
>>>>>> not
>>>>>> spammed by too much debugging output.
>>>>>>
>>>>>>> 3. Looks like I am still missing some stuff (rootfs? Environment?
>>>> Mounting?
>>>>>> Partitions?)
>>>>>>
>>>>>> Take multi_v8_defconfig, open menuconfig and enable your SoC and use
>>>> that.
>>>>>> That will be quicker than enabling everything yourself. If it doesn't work
>>>>>> out of the box, try imx_v8_defconfig.
>>>>>>
>>>>>> Once you get around to upstreaming your SoC, I'd suggest you just add it
>>>>>> to multi_v8_defconfig. Not all ARMv8 SoCs are supported there, but
>> those
>>>>>> that are make development easier, because we don't need to build as
>> many
>>>>>> different configs..
>>>>>>
>>>>>> Cheers,
>>>>>> Ahmad
>>>>>>
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Have a great day,
>>>>>>> Lior.
>>>>>>>
>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Ahmad Fatoum <a.fatoum@pengutronix.de>
>>>>>>>> Sent: Wednesday, May 31, 2023 9:11 AM
>>>>>>>> To: Lior Weintraub <liorw@pliops.com>; Ahmad Fatoum
>>>> <ahmad@a3f.at>;
>>>>>>>> barebox@lists.infradead.org
>>>>>>>> Subject: Re: [PATCH v2] Porting barebox to a new SoC
>>>>>>>>
>>>>>>>> CAUTION: External Sender
>>>>>>>>
>>>>>>>> Hi Lior,
>>>>>>>>
>>>>>>>> On 30.05.23 22:10, Lior Weintraub wrote:
>>>>>>>>> Hello Ahmad,
>>>>>>>>>
>>>>>>>>> Thanks again for your kind support!
>>>>>>>>> Your comments helped me progress and the current situation is as
>>>>>> follows:
>>>>>>>>> Our QEMU Spider machine is running a BL1.elf file using the following
>>>>>>>> command:
>>>>>>>>> QEMU_AUDIO_DRV=none qemu-system-aarch64 -M spider-soc -
>> smp 1
>>>> -
>>>>>> m
>>>>>>>> 128M -nographic \
>>>>>>>>> -device loader,file=BL1.elf -cpu cortex-a53,rvbar=0xC004000000 \
>>>>>>>>> -d unimp -semihosting-config enable=on,target=native \
>>>>>>>>> -monitor telnet:localhost:1235,server,nowait \
>>>>>>>>> -gdb tcp::1236
>>>>>>>>>
>>>>>>>>> The BL1.elf is our BootROM application that runs from ROM address
>>>>>>>> 0xC004000000.
>>>>>>>>> Just for debugging purpose we've increased the ROM size so it can
>>>> include
>>>>>>>> the images/barebox-spider-mk1-evk.img (as a const array).
>>>>>>>>> BL1 then copy it (using memcpy) to address 0 and jumps there for
>>>>>>>> execution.
>>>>>>>>
>>>>>>>> Sounds ok.
>>>>>>>>
>>>>>>>>> On the real ASIC this address will be the DRAM and indeed will need
>> to
>>>> be
>>>>>>>> initialized before the copy but here on QEMU it is not required.
>>>>>>>>
>>>>>>>> I see. You could still have your bootrom move barebox into SRAM and
>>>> then
>>>>>>>>
>>>>>>>> barebox_arm_entry(DRAM_ADDR, SZ_128M,
>>>>>> __dtb_spider_mk1_evk_start);
>>>>>>>>
>>>>>>>> To have PBL extract barebox to DRAM. Even if you don't need need
>>>> DRAM
>>>>>>>> setup in QEMU, the flow would be similar to what you will have on
>> actual
>>>>>>>> silicon.
>>>>>>>>
>>>>>>>>> The lowlevel.c of spider-evk was modified to use DRAM_ADDR
>>>> 0x400000
>>>>>>>> (4MB from start) and MY_STACK_TOP was set to 0x8000000 (128M).
>>>>>>>>
>>>>>>>> That's not needed. While you don't have control where barebox PBL
>> will
>>>> be
>>>>>>>> located
>>>>>>>> (depends on BootROM), barebox will extract itself to the end of DRAM
>>>>>>>> without
>>>>>>>> overwriting itself, so you can just use DRAM_ADDR 0 normally.
>>>> Eventually,
>>>>>>>> stack
>>>>>>>> top should go into SRAM, but anywhere that works is ok.
>>>>>>>>
>>>>>>>>> In addition, I implemented putc_ll (currently hard-coded in
>>>>>>>> include/debug_ll.h) and opened log level to VERBOSE_DEBUG
>> (currently
>>>>>> just
>>>>>>>> hard-coded in printk.h).
>>>>>>>>
>>>>>>>> There's CONFIG_DEBUG_PBL you can enable to get all these messages
>> by
>>>>>>>> default.
>>>>>>>>
>>>>>>>>> I see the following (which makes sense) logs on QEMU terminal:
>>>>>>>>> uncompress.c: memory at 0x00400000, size 0x00200000
>>>>>>>>> uncompress.c: uncompressing barebox binary at
>>>> 0x0000000000002200
>>>>>>>> (size 0x0001d3b2) to 0x00400000 (uncompressed size: 0x000373d0)
>>>>>>>>
>>>>>>>> Why pass only 2M to barebox_arm_entry? While this need not be the
>>>>>> whole
>>>>>>>> of RAM, this
>>>>>>>> initial memory is what barebox will use for itself including its final stack
>>>> and
>>>>>>>> malloc area. barebox will also not place itself into the last 1M AFAIK, so
>>>> 2M
>>>>>>>> may not work ok. You should use the minimum possible RAM here or
>> if
>>>> you
>>>>>>>> can detect
>>>>>>>> in PBL how much RAM you have or just the whole RAM bank. I am not
>>>> sure
>>>>>>>> anything lower
>>>>>>>> than SZ_4M would work ok. (Note this is DRAM size, not SRAM.
>> barebox
>>>>>> PBL
>>>>>>>> is fine being
>>>>>>>> called from 64K SRAMs, it just needs DRAM to extract to).
>>>>>>>>
>>>>>>>>> I then connect with aarch64-none-elf-gdb, load the barebox symbols
>>>> (to
>>>>>>>> 0x400000) and check the current execution state (program counter
>> and
>>>>>>>> stack).
>>>>>>>>> Looks like the code is stuck on function register_autoboot_vars:
>>>>>>>>> sp 0x5f7e60 0x5f7e60
>>>>>>>>> pc 0x401264 0x401264 <register_autoboot_vars+24>
>>>>>>>>>
>>>>>>>>> Few observations:
>>>>>>>>> 1. The PBL was using stack top located on 0x8000000 (which is
>>>>>>>> MY_STACK_TOP). Found it be causing a breakpoint on the PBL.
>>>>>>>>> 2. Barebox uses a stack top on 0x600000 which is probably calculated
>>>>>> from
>>>>>>>> my new DRAM_ADDR and SZ_2M given to the function call:
>>>>>>>>> barebox_arm_entry(DRAM_ADDR, SZ_2M,
>>>>>> __dtb_spider_mk1_evk_start);
>>>>>>>>>
>>>>>>>>> This is great! I am starting to find my way.
>>>>>>>>
>>>>>>>> :) Ye, the ENTRY_FUNCTION_WITHSTACK is only when the BootROM
>>>>>> doesn't
>>>>>>>> enter
>>>>>>>> with a valid stack pointer. It's overwritten as soon as barebox is told
>>>>>>>> about the initial memory layout (with barebox_arm_entry).
>>>>>>>>
>>>>>>>>> When the barebox execution didn't print anything to the terminal I
>>>>>>>> remembered that we used a place holder on the dtsi for the uart.
>>>>>>>>> So now I changed it to:
>>>>>>>>> uart0: serial@d000307000 {
>>>>>>>>> compatible = "arm,pl011", "arm,primecell";
>>>>>>>>> reg = <0xd0 0x307000 0 0x1000>;
>>>>>>>>> }
>>>>>>>>> (Our QEMU UART is currently using pl011 device.)
>>>>>>>>
>>>>>>>> Looks ok. Don't forget to enable the driver (via make menuconfig).
>>>>>>>>
>>>>>>>>> After some time (trying to debug by enabling MMU but then reverted
>>>> the
>>>>>>>> code back), I got to a point that when I try to run again I am getting an
>>>>>>>> exception.
>>>>>>>>> I can swear all code changes were reverted back to the point where I
>>>> saw
>>>>>> the
>>>>>>>> barebox stuck on register_autoboot_vars but now it just cases an
>>>>>> exception.
>>>>>>>>> The exception vector code is located on our ROM (part of BL1 code)
>> and
>>>>>> the
>>>>>>>> logs shows that the link register has the value 0x401218 which suggest
>>>> the
>>>>>>>> following code:
>>>>>>>>> 0000000000001200 <load_environment>:
>>>>>>>>> 1200: a9be7bfd stp x29, x30, [sp, #-32]!
>>>>>>>>> 1204: 910003fd mov x29, sp
>>>>>>>>> 1208: a90153f3 stp x19, x20, [sp, #16]
>>>>>>>>> 120c: 94000a07 bl 3a28 <default_environment_path_get>
>>>>>>>>> 1210: d00000f3 adrp x19, 1f000 <do_cpuinfo+0x1f0>
>>>>>>>>> 1214: 912a7273 add x19, x19, #0xa9c
>>>>>>>>> 1218: aa0003f4 mov x20, x0
>>>>>>>>>
>>>>>>>>> Any ideas or suggestions how to proceed with the debugging?
>>>>>>>>
>>>>>>>> You shouldn't need to touch the MMU code. If your initial memory
>> setup
>>>>>>>> is wonky, you may end up overwriting stuff. Try again with bigger
>>>> memory.
>>>>>>>>
>>>>>>>>> BTW, to answer your questions:
>>>>>>>>> The SRAM of 4MB is the only one we have because we assumed it is
>>>> only
>>>>>> for
>>>>>>>> BootROM to load a PBL
>>>>>>>>
>>>>>>>> Ok. Sometimes there are SRAMs for use with DMA. I asked, because a
>>>>>> SRAM
>>>>>>>> in the first 4M
>>>>>>>> would lend itself nicely as stack, but if there is none, we can adjust
>>>>>>>> ENTRY_FUNCTION_WITHSTACK to accept a 64-bit parameter.
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Ahmad
>>>>>>>>
>>>>>>>>> Thank you very much,
>>>>>>>>> Cheers,
>>>>>>>>> Lior.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: Ahmad Fatoum <a.fatoum@pengutronix.de>
>>>>>>>>>> Sent: Monday, May 29, 2023 10:03 PM
>>>>>>>>>> To: Lior Weintraub <liorw@pliops.com>; Ahmad Fatoum
>>>>>> <ahmad@a3f.at>;
>>>>>>>>>> barebox@lists.infradead.org
>>>>>>>>>> Subject: Re: [PATCH v2] Porting barebox to a new SoC
>>>>>>>>>>
>>>>>>>>>> CAUTION: External Sender
>>>>>>>>>>
>>>>>>>>>> Hello Lior,
>>>>>>>>>>
>>>>>>>>>> On 29.05.23 15:34, Lior Weintraub wrote:
>>>>>>>>>>> Hi Ahmad,
>>>>>>>>>>>
>>>>>>>>>>> I have revised the addresses and used DRAM address @ 0 instead:
>>>>>>>>>>> #define UARTBASE (0xD000307000)
>>>>>>>>>>> #define DRAM_ADDR (0x00000000)
>>>>>>>>>>> #define MY_STACK_TOP (0x00000000 + SZ_2M) // Set the stack
>>>> 2MB
>>>>>>>> from
>>>>>>>>>> DRAM start
>>>>>>>>>>
>>>>>>>>>> Is DRAM configured by the time barebox runs? If not, you should
>> keep
>>>>>>>> stack
>>>>>>>>>> top
>>>>>>>>>> in SRAM, until you have setup memory in prebootloader (PBL). Is
>> the
>>>> 4M
>>>>>>>>>> SRAM
>>>>>>>>>> the only on-chip SRAM you have?
>>>>>>>>>>
>>>>>>>>>>> static inline void spider_serial_putc(void *base, int c)
>>>>>>>>>>> {
>>>>>>>>>>> *((volatile unsigned *)base) = c;
>>>>>>>>>>
>>>>>>>>>> There's a helper for that: writel(c, base); In barebox, it's equivalent
>>>>>>>>>> to the volatile access, but in Linux it involves a write memory barrier.
>>>>>>>>>> We try to write code in barebox, so it's easily reusable in Linux (and
>>>>>>>>>> the other way round).
>>>>>>>>>>
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> I will try to test it on QEMU using an initial QEMU machine we
>> made
>>>> for
>>>>>>>>>> Spider.
>>>>>>>>>>> In this machine we only have 3 memory regions and a PL011 UART:
>>>>>>>>>>> spider_soc_memories soc_memories[] = {
>>>>>>>>>>> {.name = "SPIDER_GPRAM", .add = 0xC000000000ULL, .size = 4
>> *
>>>>>> MiB},
>>>>>>>>>>> {.name = "SPIDER_ROM", .add = 0xC004000000ULL, .size =
>> 128 *
>>>>>>>> KiB},
>>>>>>>>>>> {.name = "SPIDER_DRAM", .add = 0x0000000000ULL, .size = 1
>> *
>>>>>> GiB},
>>>>>>>>>>> };
>>>>>>>>>>>
>>>>>>>>>>> This special QEMU machine can run our BL1 code from "ROM"
>>>> address
>>>>>>>> (we
>>>>>>>>>> set the RVBAR to point there).
>>>>>>>>>>> So my idea is to test the barebox image by the following steps:
>>>>>>>>>>> 1. Modify the QEMU code to have a "ROM" with the size of 128M.
>>>>>>>>>>> 2. Compile our BL1 code to include the barebox.bin as a const
>> array,
>>>>>> copy
>>>>>>>> it
>>>>>>>>>> to "DRAM" @ address 0 and jump there.
>>>>>>>>>>
>>>>>>>>>> Why not map QEMU -bios option to SRAM? (Or DRAM directly, if it
>>>>>> needs
>>>>>>>> no
>>>>>>>>>> special setup from
>>>>>>>>>> barebox side).
>>>>>>>>>>
>>>>>>>>>>> For this to work I wanted to understand how to call (i.e. what
>>>>>> arguments
>>>>>>>> to
>>>>>>>>>> pass) to barebox.
>>>>>>>>>>
>>>>>>>>>> barebox doesn't expect any arguments, because most BootROMs
>>>> don't
>>>>>>>> pass
>>>>>>>>>> anything useful.
>>>>>>>>>> Some pass information about bootsource though, so that's why the
>>>>>>>>>> ENTRY_FUNCTION has
>>>>>>>>>> r0, r1 and r2 as parameters, but you need not use them.
>>>>>>>>>>
>>>>>>>>>>> So I checked the barebox.map and found the function "start" on
>>>>>> address
>>>>>>>> 0.
>>>>>>>>>>
>>>>>>>>>> You may know that Linux on some platforms comes with a
>>>> decompressor
>>>>>>>> that
>>>>>>>>>> is glued to the
>>>>>>>>>> front of the kernel image and extracts the compressed kernel image.
>>>>>>>> barebox
>>>>>>>>>> has the same
>>>>>>>>>> concept. The prebootloader is uncompressed and runs (starting
>> from
>>>>>>>>>> ENTRY_FUNCTION) and
>>>>>>>>>> then does some early setup (e.g. enable clocks, configure PMIC,
>> setup
>>>>>>>> DRAM,
>>>>>>>>>> load secure
>>>>>>>>>> monitor (BL31), ...etc.) and then it decompresses barebox proper
>> into
>>>>>>>> DRAM.
>>>>>>>>>>
>>>>>>>>>> barebox.bin <- barebox proper. You don't usually need that.
>>>>>>>>>> barebox.elf <- ELF binary for the above (for gdb)
>>>>>>>>>> barebox.map <- map file of the above
>>>>>>>>>>
>>>>>>>>>> images/barebox-spider-mk1-evk.img <- complete barebox image
>> (PBL
>>>> +
>>>>>>>>>> barebox proper)
>>>>>>>>>> images/start_spider_mk1_evk.pbl <- ELF image for the above
>>>>>>>>>> images/start_spider_mk1_evk.pbl.map <- map file of the above
>>>>>>>>>>
>>>>>>>>>> If you want to follow barbeox from the start, begin at
>>>>>>>> start_spider_mk1_evk.
>>>>>>>>>>
>>>>>>>>>>> Then I went to arch/arm/cpu/start.c and realized that the code is
>>>>>> compiled
>>>>>>>>>> with CONFIG_PBL_IMAGE.
>>>>>>>>>>> In that case I assume I need to pass 3 arguments and use this
>>>> function
>>>>>>>>>> prototype:
>>>>>>>>>>> void start(unsigned long membase, unsigned long memsize, void
>>>>>>>>>> *boarddata);
>>>>>>>>>>
>>>>>>>>>> barebox prebootloader takes care of this, so you don't need to do
>>>>>> anything.
>>>>>>>>>>
>>>>>>>>>>> Few questions:
>>>>>>>>>>> 1. Will that call work:
>>>>>>>>>>> typedef void (*barebox_start)(unsigned long , unsigned long ,
>> void
>>>> *);
>>>>>>>>>>> #define DRAM_START (0)
>>>>>>>>>>> barebox_start p_barebox = (barebox_start)DRAM_START;
>>>>>>>>>>> p_barebox(DRAM_START, DRAM_START+SZ_2M, (void
>>>>>>>>>> *)(DRAM_START+SZ_4M));
>>>>>>>>>>> This assumes that my BL1 code also copied the device tree
>>>> (barebox-
>>>>>> dt-
>>>>>>>>>> 2nd.img? start_dt_2nd.pblb? start_spider_mk1_evk.pblb?)
>>>>>>>>>>
>>>>>>>>>> The device tree is built into the PBL and passed to barebox proper.
>> This
>>>>>>>>>> allows us to use the same barebox proper binary and link it with a
>>>>>> different
>>>>>>>>>> prebootloader for each SoC/board, all in the same build.
>>>>>>>>>>
>>>>>>>>>> barebox-dt-2nd.img is a special image that looks exactly like a Linux
>>>>>> kernel:
>>>>>>>>>>
>>>>>>>>>> images/barebox-dt-2nd.img: Linux kernel ARM64 boot executable
>>>>>> Image,
>>>>>>>>>> little-endian, 4K pages
>>>>>>>>>>
>>>>>>>>>> and can thus be used for booting for easy chainloading from other
>>>>>>>>>> bootloaders or for running
>>>>>>>>>> with QEMU -kernel. You shouldn't need it right now.
>>>>>>>>>>
>>>>>>>>>>> 2. Do I want to have my code compiled with CONFIG_PBL_IMAGE?
>>>>>>>>>>> If I understand correctly, it means that my code will provide a PBL
>>>>>> (a.k.a
>>>>>>>>>> BL2) which will set the DRAM and STACK among other things
>> (MMU?).
>>>>>>>>>>
>>>>>>>>>> The patch I sent already builds a PBL. You will need to fill out
>>>>>>>>>> start_spider_mk1_evk
>>>>>>>>>> to do all the other early initialization you need. Then you call
>>>>>>>>>> barebox_arm_entry
>>>>>>>>>> with device tree and memory size and it will take care to do stack
>> setup
>>>> in
>>>>>>>> new
>>>>>>>>>> memory region, MMU setup (if enabled) and chainloading barebox
>>>>>> proper.
>>>>>>>>>>
>>>>>>>>>> Note that PBL isn't necessary BL2. You can chainload barebox from
>>>> within
>>>>>>>>>> barebox (i.e.
>>>>>>>>>> in EL2 or EL1), which is useful for debugging. You will thus often find
>>>> PBL
>>>>>>>> code
>>>>>>>>>> that
>>>>>>>>>> does
>>>>>>>>>>
>>>>>>>>>> if (current_el() == 3) {
>>>>>>>>>> /* Do BL2 setup */
>>>>>>>>>> chainload();
>>>>>>>>>> __builtin_unreachable();
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> barebox_arm_entry(...)
>>>>>>>>>>
>>>>>>>>>> See for example arch/arm/boards/innocomm-imx8mm-
>>>> wb15/lowlevel.c
>>>>>>>>>>
>>>>>>>>>> to see a real-world example of another Cortex-A53.
>>>>>>>>>>
>>>>>>>>>>> In that case I assume it is OK.
>>>>>>>>>>> 3. If I try to remove it by having CONFIG_PBL_IMAGE=n on
>>>>>>>> spider_defconfig
>>>>>>>>>> this doesn't do anything
>>>>>>>>>>> The build (make spider_defconfig) ignores it and say that " No
>>>> change
>>>>>> to
>>>>>>>>>> .config ".
>>>>>>>>>>
>>>>>>>>>> Another symbol forces it to be enabled. If you are curious, run make
>>>>>>>>>> menuconfig
>>>>>>>>>> and then search (/) for the symbol and it will list, whether it's
>> enabled
>>>>>> and
>>>>>>>>>> why:
>>>>>>>>>>
>>>>>>>>>> Selected by [y]:
>>>>>>>>>> - PBL_MULTI_IMAGES [=y] && HAVE_PBL_MULTI_IMAGES [=y]
>>>>>>>>>>
>>>>>>>>>> I'd suggest you avoid modifying the .config file manually. always use
>>>>>>>>>> menuconfig.
>>>>>>>>>>
>>>>>>>>>>> 4. I also tried to understand how to implement PUTC_LL but not
>> sure
>>>> I
>>>>>>>>>> understand.
>>>>>>>>>>> 4.1 When I set "CONFIG_DEBUG_LL=y" on spider_defconfig it is
>>>> again
>>>>>>>> not
>>>>>>>>>> written to .config and I get " No change to .config " message.
>>>>>>>>>>
>>>>>>>>>> You must:
>>>>>>>>>>
>>>>>>>>>> - select HAS_DEBUG_LL from MACH_SPIDER
>>>>>>>>>> - Add your arch to arch/arm/include/asm/debug_ll.h
>>>>>>>>>> - Then implement PUTC_LL in e.g. mach/spider/debug_ll.h
>>>>>>>>>>
>>>>>>>>>>> 4.2 Do I need to have my own debug_ll.h file?
>>>>>>>>>>
>>>>>>>>>> Yes. See above.
>>>>>>>>>>
>>>>>>>>>>> 5. When I make changes to spider_defconfig and try to regenerate
>>>> the
>>>>>>>>>> .config and I get " No change to .config " message, does it mean that
>>>>>> those
>>>>>>>>>> macros are "hidden" symbols like you said about the
>>>> CONFIG_CPU_V8?
>>>>>>>>>>
>>>>>>>>>> Yes. Just check menuconfig to see how symbols relate to each other.
>>>>>>>>>> This is 1:1 like it's in Linux, so it'll come in handy when you do
>>>>>>>>>> the kernel port too ;)
>>>>>>>>>>
>>>>>>>>>>> Apologize for so many questions :-)
>>>>>>>>>>
>>>>>>>>>> No problem. Looking forward to your patches ;)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Cheers,
>>>>>>>>>> Ahmad
>>>>>>>>>>
>>>>>>>>>>> Cheers,
>>>>>>>>>>> Lior.
>>>>>>>>>>>
>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>> From: Lior Weintraub
>>>>>>>>>>> Sent: Sunday, May 28, 2023 11:16 PM
>>>>>>>>>>> To: Ahmad Fatoum <ahmad@a3f.at>; barebox@lists.infradead.org
>>>>>>>>>>> Subject: RE: [PATCH v2] Porting barebox to a new SoC
>>>>>>>>>>>
>>>>>>>>>>> Hi Ahmad,
>>>>>>>>>>>
>>>>>>>>>>> Thank you so much for your kind support!
>>>>>>>>>>>
>>>>>>>>>>> Indeed we also have a 16GB DRAM that starts from address 0
>>>> (though
>>>>>>>>>> currently we don't have the controller settings (under
>> development)).
>>>>>>>>>>>
>>>>>>>>>>> I also wrote the BootROM (BL1) for this SoC (128KB ROM @
>> address
>>>>>>>>>> 0xC004000000).
>>>>>>>>>>> I understand now that it would be best for me to develop BL2 that
>>>> will
>>>>>> run
>>>>>>>>>> from our SRAM.
>>>>>>>>>>>
>>>>>>>>>>> As this BL2 code is bare-metal I have no problem or limitations with
>>>> the
>>>>>> 40
>>>>>>>>>> bit addresses.
>>>>>>>>>>> The BL2 code will initialize the DRAM controller and then copy
>>>> Barebox
>>>>>>>> image
>>>>>>>>>> from NOR Flash to address 0 of the DRAM.
>>>>>>>>>>> Our NOR Flash is 128MB in size and it is accessed via QSPI
>> controller.
>>>>>>>>>>>
>>>>>>>>>>> I tried applying your suggested patch but got an error while doing
>> so:
>>>>>>>>>>> $git apply 0002-Ahmad.patch
>>>>>>>>>>> 0002-Ahmad.patch:115: trailing whitespace.
>>>>>>>>>>> .of_compatible = spider_board_of_match, };
>>>>>>>>>>> error: corrupt patch at line 117
>>>>>>>>>>>
>>>>>>>>>>> After some digging I found that my Outlook probably messed with
>>>> the
>>>>>>>> patch
>>>>>>>>>> format (even though I am using text only and no HTML format).
>>>>>>>>>>> When I went to the web and copied the patch from there (mailing
>> list
>>>>>>>>>> archive) it was working well (i.e. no compilation error).
>>>>>>>>>>>
>>>>>>>>>>> Cheers,
>>>>>>>>>>> Lior.
>>>>>>>>>>>
>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>> From: Ahmad Fatoum <ahmad@a3f.at>
>>>>>>>>>>> Sent: Sunday, May 28, 2023 6:38 PM
>>>>>>>>>>> To: barebox@lists.infradead.org
>>>>>>>>>>> Cc: Lior Weintraub <liorw@pliops.com>
>>>>>>>>>>> Subject: [PATCH v2] Porting barebox to a new SoC
>>>>>>>>>>>
>>>>>>>>>>> CAUTION: External Sender
>>>>>>>>>>>
>>>>>>>>>>> From: Lior Weintraub <liorw@pliops.com>
>>>>>>>>>>>
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> I tried to follow the porting guide on https://ddec1-0-en-
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>> ctp.trendmicro.com:443/wis/clicktime/v1/query?url=https%3a%2f%2fwww.
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>> barebox.org%2fdoc%2flatest%2fdevel%2fporting.html%23&umid=60097eda
>>>>>>>>>> -f136-45a1-9c8e-
>>>>>>>>>>
>>>> cf6a76e45cf8&auth=860a7ebb9feba264acc79b6e38eb59582349362c-
>>>>>>>>>> 480ae23736add41c88ab8d30c090a75517ca7f9e but couldn't
>> follow
>>>>>> the
>>>>>>>>>> instructions.
>>>>>>>>>>> I would like to port barebox to a new SoC (which is not a derivative
>> of
>>>>>> any
>>>>>>>>>> known SoC).
>>>>>>>>>>> It has the following:
>>>>>>>>>>> * Single Cortex A53
>>>>>>>>>>> * SRAM (4MB) located on address 0xC000000000
>>>>>>>>>>>
>>>>>>>>>>> The below patch shows my initial test to try and have a starting
>> point.
>>>>>>>>>>> I am setting env variables:
>>>>>>>>>>> export ARCH=arm64
>>>>>>>>>>> export CROSS_COMPILE=/home/pliops/workspace/ARM/arm-
>> gnu-
>>>>>>>>>> toolchain/bin/aarch64-none-elf-
>>>>>>>>>>>
>>>>>>>>>>> Then I build with:
>>>>>>>>>>> make spider_defconfig && make
>>>>>>>>>>>
>>>>>>>>>>> This gives an error:
>>>>>>>>>>> aarch64-none-elf-gcc: error: unrecognized argument in option '-
>>>>>>>> mabi=apcs-
>>>>>>>>>> gnu'
>>>>>>>>>>> aarch64-none-elf-gcc: note: valid arguments to '-mabi=' are: ilp32
>>>> lp64
>>>>>>>>>>> aarch64-none-elf-gcc: error: unrecognized command-line option '-
>>>>>> msoft-
>>>>>>>>>> float'
>>>>>>>>>>> aarch64-none-elf-gcc: error: unrecognized command-line option '-
>>>> mno-
>>>>>>>>>> unaligned-access'
>>>>>>>>>>> /home/pliops/workspace/simplest-linux-
>>>>>>>>>> demo/barebox/scripts/Makefile.build:140: recipe for target
>>>>>>>>>> 'scripts/mod/empty.o' failed
>>>>>>>>>>> make[2]: *** [scripts/mod/empty.o] Error 1
>>>>>>>>>>>
>>>>>>>>>>> Not sure why the compiler flags get -mabi=apcs-gnu when I
>> explicitly
>>>> set
>>>>>>>>>> CONFIG_CPU_V8 and the arch/arm/Makefile has:
>>>>>>>>>>> ifeq ($(CONFIG_CPU_V8), y)
>>>>>>>>>>> CFLAGS_ABI :=-mabi=lp64
>>>>>>>>>>>
>>>>>>>>>>> The changes I did:
>>>>>>>>>>> >From 848b5f9b18bb1bb96d197cbc1b368ee0a729d581 Mon
>> Sep
>>>> 17
>>>>>>>>>> 00:00:00 2001
>>>>>>>>>>> ---
>>>>>>>>>>> arch/arm/Kconfig | 13 ++++++++
>>>>>>>>>>> arch/arm/Makefile | 1 +
>>>>>>>>>>> arch/arm/boards/Makefile | 1 +
>>>>>>>>>>> arch/arm/boards/spider-evk/Makefile | 4 +++
>>>>>>>>>>> arch/arm/boards/spider-evk/board.c | 26 +++++++++++++++
>>>>>>>>>>> arch/arm/boards/spider-evk/lowlevel.c | 30 +++++++++++++++++
>>>>>>>>>>> arch/arm/configs/spider_defconfig | 8 +++++
>>>>>>>>>>> arch/arm/dts/Makefile | 1 +
>>>>>>>>>>> arch/arm/dts/spider-mk1-evk.dts | 10 ++++++
>>>>>>>>>>> arch/arm/dts/spider-mk1.dtsi | 46
>>>>>> +++++++++++++++++++++++++++
>>>>>>>>>>> arch/arm/mach-spider/Kconfig | 16 ++++++++++
>>>>>>>>>>> arch/arm/mach-spider/Makefile | 1 +
>>>>>>>>>>> arch/arm/mach-spider/lowlevel.c | 14 ++++++++
>>>>>>>>>>> images/Makefile | 1 +
>>>>>>>>>>> images/Makefile.spider | 5 +++
>>>>>>>>>>> include/mach/spider/lowlevel.h | 7 ++++
>>>>>>>>>>> 16 files changed, 184 insertions(+)
>>>>>>>>>>> create mode 100644 arch/arm/boards/spider-evk/Makefile
>>>>>>>>>>> create mode 100644 arch/arm/boards/spider-evk/board.c
>>>>>>>>>>> create mode 100644 arch/arm/boards/spider-evk/lowlevel.c
>>>>>>>>>>> create mode 100644 arch/arm/configs/spider_defconfig create
>>>> mode
>>>>>>>>>> 100644 arch/arm/dts/spider-mk1-evk.dts create mode 100644
>>>>>>>>>> arch/arm/dts/spider-mk1.dtsi create mode 100644
>> arch/arm/mach-
>>>>>>>>>> spider/Kconfig create mode 100644 arch/arm/mach-
>> spider/Makefile
>>>>>>>> create
>>>>>>>>>> mode 100644 arch/arm/mach-spider/lowlevel.c create mode
>> 100644
>>>>>>>>>> images/Makefile.spider create mode 100644
>>>>>>>> include/mach/spider/lowlevel.h
>>>>>>>>>>>
>>>>>>>>>>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index
>>>>>>>>>> e76ee0f6dfe1..e5dcf128447e 100644
>>>>>>>>>>> --- a/arch/arm/Kconfig
>>>>>>>>>>> +++ b/arch/arm/Kconfig
>>>>>>>>>>> @@ -255,6 +255,18 @@ config ARCH_ROCKCHIP
>>>>>>>>>>> select HAS_DEBUG_LL
>>>>>>>>>>> imply GPIO_ROCKCHIP
>>>>>>>>>>>
>>>>>>>>>>> +config ARCH_SPIDER
>>>>>>>>>>> + bool "Pliops Spider based"
>>>>>>>>>>> + depends on 64BIT
>>>>>>>>>>> + depends on ARCH_MULTIARCH
>>>>>>>>>>> + select GPIOLIB
>>>>>>>>>>> + select HAVE_PBL_MULTI_IMAGES
>>>>>>>>>>> + select COMMON_CLK
>>>>>>>>>>> + select CLKDEV_LOOKUP
>>>>>>>>>>> + select COMMON_CLK_OF_PROVIDER
>>>>>>>>>>> + select OFTREE
>>>>>>>>>>> + select OFDEVICE
>>>>>>>>>>> +
>>>>>>>>>>> config ARCH_STM32MP
>>>>>>>>>>> bool "STMicroelectronics STM32MP"
>>>>>>>>>>> depends on 32BIT
>>>>>>>>>>> @@ -331,6 +343,7 @@ source "arch/arm/mach-omap/Kconfig"
>>>>>>>>>>> source "arch/arm/mach-pxa/Kconfig"
>>>>>>>>>>> source "arch/arm/mach-rockchip/Kconfig"
>>>>>>>>>>> source "arch/arm/mach-socfpga/Kconfig"
>>>>>>>>>>> +source "arch/arm/mach-spider/Kconfig"
>>>>>>>>>>> source "arch/arm/mach-stm32mp/Kconfig"
>>>>>>>>>>> source "arch/arm/mach-versatile/Kconfig"
>>>>>>>>>>> source "arch/arm/mach-vexpress/Kconfig"
>>>>>>>>>>> diff --git a/arch/arm/Makefile b/arch/arm/Makefile index
>>>>>>>>>> 35ebc70f44e2..4c63dfee48f4 100644
>>>>>>>>>>> --- a/arch/arm/Makefile
>>>>>>>>>>> +++ b/arch/arm/Makefile
>>>>>>>>>>> @@ -101,6 +101,7 @@ machine-$(CONFIG_ARCH_MXS) +=
>> mxs
>>>>>>>>>>> machine-$(CONFIG_ARCH_MVEBU) += mvebu
>>>>>>>>>>> machine-$(CONFIG_ARCH_NOMADIK) += nomadik
>>>>>>>>>>> machine-$(CONFIG_ARCH_OMAP) += omap
>>>>>>>>>>> +machine-$(CONFIG_ARCH_SPIDER) += spider
>>>>>>>>>>> machine-$(CONFIG_ARCH_PXA) += pxa
>>>>>>>>>>> machine-$(CONFIG_ARCH_ROCKCHIP) += rockchip
>>>>>>>>>>> machine-$(CONFIG_ARCH_SAMSUNG) += samsung
>>>>>>>>>>> diff --git a/arch/arm/boards/Makefile
>> b/arch/arm/boards/Makefile
>>>>>> index
>>>>>>>>>> 2877debad535..6fe0a90c81ea 100644
>>>>>>>>>>> --- a/arch/arm/boards/Makefile
>>>>>>>>>>> +++ b/arch/arm/boards/Makefile
>>>>>>>>>>> @@ -135,6 +135,7 @@ obj-
>>>>>>>>>> $(CONFIG_MACH_SOCFPGA_TERASIC_DE10_NANO) += terasic-
>>>>>> de10-
>>>>>>>>>> nano/
>>>>>>>>>>> obj-$(CONFIG_MACH_SOCFPGA_TERASIC_SOCKIT) += terasic-
>>>>>> sockit/
>>>>>>>>>>> obj-$(CONFIG_MACH_SOLIDRUN_CUBOX) += solidrun-
>> cubox/
>>>>>>>>>>> obj-$(CONFIG_MACH_SOLIDRUN_MICROSOM) += solidrun-
>>>>>>>>>> microsom/
>>>>>>>>>>> +obj-$(CONFIG_MACH_SPIDER_MK1_EVK) += spider-evk/
>>>>>>>>>>> obj-$(CONFIG_MACH_STM32MP15XX_DKX) +=
>>>> stm32mp15xx-
>>>>>>>> dkx/
>>>>>>>>>>> obj-$(CONFIG_MACH_STM32MP13XX_DK) +=
>> stm32mp13xx-
>>>>>> dk/
>>>>>>>>>>> obj-$(CONFIG_MACH_LXA_MC1) += lxa-mc1/
>>>>>>>>>>> diff --git a/arch/arm/boards/spider-evk/Makefile
>>>>>>>>>> b/arch/arm/boards/spider-evk/Makefile
>>>>>>>>>>> new file mode 100644
>>>>>>>>>>> index 000000000000..da63d2625f7a
>>>>>>>>>>> --- /dev/null
>>>>>>>>>>> +++ b/arch/arm/boards/spider-evk/Makefile
>>>>>>>>>>> @@ -0,0 +1,4 @@
>>>>>>>>>>> +# SPDX-License-Identifier: GPL-2.0-only
>>>>>>>>>>> +
>>>>>>>>>>> +obj-y += board.o
>>>>>>>>>>> +lwl-y += lowlevel.o
>>>>>>>>>>> diff --git a/arch/arm/boards/spider-evk/board.c
>>>>>>>> b/arch/arm/boards/spider-
>>>>>>>>>> evk/board.c
>>>>>>>>>>> new file mode 100644
>>>>>>>>>>> index 000000000000..3920e83b457d
>>>>>>>>>>> --- /dev/null
>>>>>>>>>>> +++ b/arch/arm/boards/spider-evk/board.c
>>>>>>>>>>> @@ -0,0 +1,26 @@
>>>>>>>>>>> +#include <bbu.h>
>>>>>>>>>>> +#include <boot.h>
>>>>>>>>>>> +#include <bootm.h>
>>>>>>>>>>> +#include <common.h>
>>>>>>>>>>> +#include <deep-probe.h>
>>>>>>>>>>> +#include <environment.h>
>>>>>>>>>>> +#include <fcntl.h>
>>>>>>>>>>> +#include <globalvar.h>
>>>>>>>>>>> +
>>>>>>>>>>> +static int spider_board_probe(struct device *dev) {
>>>>>>>>>>> + /* Do some board-specific setup */
>>>>>>>>>>> + return 0;
>>>>>>>>>>> +}
>>>>>>>>>>> +
>>>>>>>>>>> +static const struct of_device_id spider_board_of_match[] = {
>>>>>>>>>>> + { .compatible = "pliops,spider-mk1-evk" },
>>>>>>>>>>> + { /* sentinel */ },
>>>>>>>>>>> +};
>>>>>>>>>>> +
>>>>>>>>>>> +static struct driver spider_board_driver = {
>>>>>>>>>>> + .name = "board-spider",
>>>>>>>>>>> + .probe = spider_board_probe,
>>>>>>>>>>> + .of_compatible = spider_board_of_match, };
>>>>>>>>>>> +device_platform_driver(spider_board_driver);
>>>>>>>>>>> diff --git a/arch/arm/boards/spider-evk/lowlevel.c
>>>>>>>>>> b/arch/arm/boards/spider-evk/lowlevel.c
>>>>>>>>>>> new file mode 100644
>>>>>>>>>>> index 000000000000..e36fcde4208e
>>>>>>>>>>> --- /dev/null
>>>>>>>>>>> +++ b/arch/arm/boards/spider-evk/lowlevel.c
>>>>>>>>>>> @@ -0,0 +1,30 @@
>>>>>>>>>>> +#include <common.h>
>>>>>>>>>>> +#include <asm/barebox-arm.h>
>>>>>>>>>>> +#include <mach/spider/lowlevel.h>
>>>>>>>>>>> +
>>>>>>>>>>> +#define BASE_ADDR (0xD000307000)
>>>>>>>>>>> +#define GPRAM_ADDR (0xC000000000)
>>>>>>>>>>> +#define MY_STACK_TOP (0xC000000000 + SZ_2M) // Set the
>> stack
>>>>>>>> 2MB
>>>>>>>>>> from GPRAM start (excatly in the middle)
>>>>>>>>>>> +static inline void spider_serial_putc(void *base, int c) {
>>>>>>>>>>> +// if (!(readl(base + UCR1) & UCR1_UARTEN))
>>>>>>>>>>> +// return;
>>>>>>>>>>> +//
>>>>>>>>>>> +// while (!(readl(base + USR2) & USR2_TXDC));
>>>>>>>>>>> +//
>>>>>>>>>>> +// writel(c, base + URTX0);
>>>>>>>>>>> +}
>>>>>>>>>>> +
>>>>>>>>>>> +ENTRY_FUNCTION_WITHSTACK(start_spider_mk1_evk,
>>>>>> MY_STACK_TOP,
>>>>>>>>>> r0, r1,
>>>>>>>>>>> +r2) {
>>>>>>>>>>> + extern char __dtb_spider_mk1_evk_start[];
>>>>>>>>>>> +
>>>>>>>>>>> + spider_lowlevel_init();
>>>>>>>>>>> +
>>>>>>>>>>> + relocate_to_current_adr();
>>>>>>>>>>> + setup_c();
>>>>>>>>>>> +
>>>>>>>>>>> + pbl_set_putc(spider_serial_putc, (void *)BASE_ADDR);
>>>>>>>>>>> +
>>>>>>>>>>> + barebox_arm_entry(GPRAM_ADDR, SZ_2M,
>>>>>>>>>>> +__dtb_spider_mk1_evk_start); }
>>>>>>>>>>> diff --git a/arch/arm/configs/spider_defconfig
>>>>>>>>>> b/arch/arm/configs/spider_defconfig
>>>>>>>>>>> new file mode 100644
>>>>>>>>>>> index 000000000000..c91bb889d97f
>>>>>>>>>>> --- /dev/null
>>>>>>>>>>> +++ b/arch/arm/configs/spider_defconfig
>>>>>>>>>>> @@ -0,0 +1,8 @@
>>>>>>>>>>> +CONFIG_ARCH_SPIDER=y
>>>>>>>>>>> +CONFIG_MACH_SPIDER_MK1_EVK=y
>>>>>>>>>>> +CONFIG_BOARD_ARM_GENERIC_DT=y
>>>>>>>>>>> +CONFIG_MALLOC_TLSF=y
>>>>>>>>>>> +CONFIG_KALLSYMS=y
>>>>>>>>>>> +CONFIG_RELOCATABLE=y
>>>>>>>>>>> +CONFIG_CONSOLE_ALLOW_COLOR=y
>>>>>>>>>>> +CONFIG_PBL_CONSOLE=y
>>>>>>>>>>> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile index
>>>>>>>>>> 98f4c4e0194b..94b304d4878f 100644
>>>>>>>>>>> --- a/arch/arm/dts/Makefile
>>>>>>>>>>> +++ b/arch/arm/dts/Makefile
>>>>>>>>>>> @@ -134,6 +134,7 @@ lwl-$(CONFIG_MACH_SOLIDRUN_CUBOX)
>>>> +=
>>>>>>>> dove-
>>>>>>>>>> cubox-bb.dtb.o
>>>>>>>>>>> lwl-$(CONFIG_MACH_SOLIDRUN_MICROSOM) += imx6dl-
>>>>>>>>>> hummingboard.dtb.o imx6q-hummingboard.dtb.o \
>>>>>>>>>>> imx6dl-hummingboard2.dtb.o imx6q-
>>>>>>>>>> hummingboard2.dtb.o \
>>>>>>>>>>> imx6q-h100.dtb.o
>>>>>>>>>>> +lwl-$(CONFIG_MACH_SPIDER_MK1_EVK) += spider-mk1-
>> evk.dtb.o
>>>>>>>>>>> lwl-$(CONFIG_MACH_SKOV_IMX6) += imx6s-skov-imx6.dtb.o
>>>> imx6dl-
>>>>>>>> skov-
>>>>>>>>>> imx6.dtb.o imx6q-skov-imx6.dtb.o
>>>>>>>>>>> lwl-$(CONFIG_MACH_SKOV_ARM9CPU) += at91-skov-
>>>> arm9cpu.dtb.o
>>>>>>>>>>> lwl-$(CONFIG_MACH_SEEED_ODYSSEY) += stm32mp157c-
>>>>>> odyssey.dtb.o
>>>>>>>>>> diff --git a/arch/arm/dts/spider-mk1-evk.dts
>> b/arch/arm/dts/spider-
>>>>>> mk1-
>>>>>>>>>> evk.dts new file mode 100644 index
>> 000000000000..b8081cb85bf8
>>>>>>>>>>> --- /dev/null
>>>>>>>>>>> +++ b/arch/arm/dts/spider-mk1-evk.dts
>>>>>>>>>>> @@ -0,0 +1,10 @@
>>>>>>>>>>> +// SPDX-License-Identifier: GPL-2.0 OR X11
>>>>>>>>>>> +
>>>>>>>>>>> +/dts-v1/;
>>>>>>>>>>> +
>>>>>>>>>>> +#include "spider-mk1.dtsi"
>>>>>>>>>>> +
>>>>>>>>>>> +/ {
>>>>>>>>>>> + model = "Pliops Spider MK-I EVK";
>>>>>>>>>>> + compatible = "pliops,spider-mk1-evk"; };
>>>>>>>>>>> diff --git a/arch/arm/dts/spider-mk1.dtsi b/arch/arm/dts/spider-
>>>>>> mk1.dtsi
>>>>>>>>>> new file mode 100644 index 000000000000..d4613848169d
>>>>>>>>>>> --- /dev/null
>>>>>>>>>>> +++ b/arch/arm/dts/spider-mk1.dtsi
>>>>>>>>>>> @@ -0,0 +1,46 @@
>>>>>>>>>>> +// SPDX-License-Identifier: GPL-2.0 OR X11
>>>>>>>>>>> +
>>>>>>>>>>> +/ {
>>>>>>>>>>> + #address-cells = <2>;
>>>>>>>>>>> + #size-cells = <2>;
>>>>>>>>>>> +
>>>>>>>>>>> + chosen {
>>>>>>>>>>> + stdout-path = &uart0;
>>>>>>>>>>> + };
>>>>>>>>>>> +
>>>>>>>>>>> + aliases {
>>>>>>>>>>> + serial0 = &uart0;
>>>>>>>>>>> + };
>>>>>>>>>>> +
>>>>>>>>>>> + cpus {
>>>>>>>>>>> + #address-cells = <1>;
>>>>>>>>>>> + #size-cells = <0>;
>>>>>>>>>>> +
>>>>>>>>>>> + cpu0: cpu@0 {
>>>>>>>>>>> + device_type = "cpu";
>>>>>>>>>>> + compatible = "arm,cortex-a53";
>>>>>>>>>>> + reg = <0x0>;
>>>>>>>>>>> + };
>>>>>>>>>>> + };
>>>>>>>>>>> +
>>>>>>>>>>> + memory@1000000 {
>>>>>>>>>>> + reg = <0x0 0x1000000 0x0 0x400000>; /* 128M */
>>>>>>>>>>> + device_type = "memory";
>>>>>>>>>>> + };
>>>>>>>>>>> +
>>>>>>>>>>> + soc {
>>>>>>>>>>> + #address-cells = <2>;
>>>>>>>>>>> + #size-cells = <2>;
>>>>>>>>>>> + ranges;
>>>>>>>>>>> +
>>>>>>>>>>> + sram@c000000000 {
>>>>>>>>>>> + compatible = "mmio-sram";
>>>>>>>>>>> + reg = <0xc0 0x0 0x0 0x400000>;
>>>>>>>>>>> + };
>>>>>>>>>>> +
>>>>>>>>>>> + uart0: serial@d000307000 {
>>>>>>>>>>> + compatible = "pliops,spider-uart";
>>>>>>>>>>> + reg = <0xd0 0x307000 0 0x1000>;
>>>>>>>>>>> + };
>>>>>>>>>>> + };
>>>>>>>>>>> +};
>>>>>>>>>>> diff --git a/arch/arm/mach-spider/Kconfig b/arch/arm/mach-
>>>>>>>> spider/Kconfig
>>>>>>>>>> new file mode 100644 index 000000000000..6d2f888a5fd8
>>>>>>>>>>> --- /dev/null
>>>>>>>>>>> +++ b/arch/arm/mach-spider/Kconfig
>>>>>>>>>>> @@ -0,0 +1,16 @@
>>>>>>>>>>> +# SPDX-License-Identifier: GPL-2.0-only
>>>>>>>>>>> +
>>>>>>>>>>> +if ARCH_SPIDER
>>>>>>>>>>> +
>>>>>>>>>>> +config ARCH_SPIDER_MK1
>>>>>>>>>>> + bool
>>>>>>>>>>> + select CPU_V8
>>>>>>>>>>> + help
>>>>>>>>>>> + The first Cortex-A53-based SoC of the spider family.
>>>>>>>>>>> + This symbol is invisble and select by boards
>>>>>>>>>>> +
>>>>>>>>>>> +config MACH_SPIDER_MK1_EVK
>>>>>>>>>>> + bool "Pliops Spider Reference Design Board"
>>>>>>>>>>> + select ARCH_SPIDER_MK1
>>>>>>>>>>> +
>>>>>>>>>>> +endif
>>>>>>>>>>> diff --git a/arch/arm/mach-spider/Makefile b/arch/arm/mach-
>>>>>>>>>> spider/Makefile new file mode 100644 index
>>>>>>>> 000000000000..b08c4a93ca27
>>>>>>>>>>> --- /dev/null
>>>>>>>>>>> +++ b/arch/arm/mach-spider/Makefile
>>>>>>>>>>> @@ -0,0 +1 @@
>>>>>>>>>>> +lwl-y += lowlevel.o
>>>>>>>>>>> diff --git a/arch/arm/mach-spider/lowlevel.c b/arch/arm/mach-
>>>>>>>>>> spider/lowlevel.c new file mode 100644 index
>>>>>>>>>> 000000000000..5d62ef0f39e5
>>>>>>>>>>> --- /dev/null
>>>>>>>>>>> +++ b/arch/arm/mach-spider/lowlevel.c
>>>>>>>>>>> @@ -0,0 +1,14 @@
>>>>>>>>>>> +// SPDX-License-Identifier: GPL-2.0+
>>>>>>>>>>> +
>>>>>>>>>>> +#include <linux/types.h>
>>>>>>>>>>> +#include <mach/spider/lowlevel.h>
>>>>>>>>>>> +#include <asm/barebox-arm-head.h>
>>>>>>>>>>> +
>>>>>>>>>>> +void spider_lowlevel_init(void)
>>>>>>>>>>> +{
>>>>>>>>>>> + arm_cpu_lowlevel_init();
>>>>>>>>>>> + /*
>>>>>>>>>>> + * not yet relocated, only do writel/readl for stuff that's
>>>>>>>>>>> + * critical to run early. No global variables allowed.
>>>>>>>>>>> + */
>>>>>>>>>>> +}
>>>>>>>>>>> diff --git a/images/Makefile b/images/Makefile index
>>>>>>>>>> c93f9e268978..97521e713228 100644
>>>>>>>>>>> --- a/images/Makefile
>>>>>>>>>>> +++ b/images/Makefile
>>>>>>>>>>> @@ -150,6 +150,7 @@ include $(srctree)/images/Makefile.mxs
>>>>>> include
>>>>>>>>>> $(srctree)/images/Makefile.omap3 include
>>>>>>>>>> $(srctree)/images/Makefile.rockchip
>>>>>>>>>>> include $(srctree)/images/Makefile.socfpga
>>>>>>>>>>> +include $(srctree)/images/Makefile.spider
>>>>>>>>>>> include $(srctree)/images/Makefile.stm32mp
>>>>>>>>>>> include $(srctree)/images/Makefile.tegra include
>>>>>>>>>> $(srctree)/images/Makefile.versatile
>>>>>>>>>>> diff --git a/images/Makefile.spider b/images/Makefile.spider new
>> file
>>>>>>>> mode
>>>>>>>>>> 100644 index 000000000000..c32f2762df04
>>>>>>>>>>> --- /dev/null
>>>>>>>>>>> +++ b/images/Makefile.spider
>>>>>>>>>>> @@ -0,0 +1,5 @@
>>>>>>>>>>> +# SPDX-License-Identifier: GPL-2.0-only
>>>>>>>>>>> +
>>>>>>>>>>> +pblb-$(CONFIG_MACH_SPIDER_MK1_EVK) +=
>>>> start_spider_mk1_evk
>>>>>>>>>>> +FILE_barebox-spider-mk1-evk.img = start_spider_mk1_evk.pblb
>>>>>>>>>>> +image-$(CONFIG_MACH_SPIDER_MK1_EVK) += barebox-spider-
>>>> mk1-
>>>>>>>>>> evk.img
>>>>>>>>>>> diff --git a/include/mach/spider/lowlevel.h
>>>>>>>>>> b/include/mach/spider/lowlevel.h new file mode 100644 index
>>>>>>>>>> 000000000000..6e0ce1c77f7e
>>>>>>>>>>> --- /dev/null
>>>>>>>>>>> +++ b/include/mach/spider/lowlevel.h
>>>>>>>>>>> @@ -0,0 +1,7 @@
>>>>>>>>>>> +/* SPDX-License-Identifier: GPL-2.0+ */ #ifndef
>> __MACH_SPIDER_H_
>>>>>>>>>>> +#define __MACH_SPIDER_H_
>>>>>>>>>>> +
>>>>>>>>>>> +void spider_lowlevel_init(void);
>>>>>>>>>>> +
>>>>>>>>>>> +#endif
>>>>>>>>>>> --
>>>>>>>>>>> 2.38.4
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Pengutronix e.K. | |
>>>>>>>>>> Steuerwalder Str. 21 | http://www.pengutronix.de/ |
>>>>>>>>>> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0
>>>> |
>>>>>>>>>> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-
>>>> 5555
>>>>>> |
>>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Pengutronix e.K. | |
>>>>>>>> Steuerwalder Str. 21 | http://www.pengutronix.de/ |
>>>>>>>> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0
>> |
>>>>>>>> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-
>> 5555
>>>> |
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Pengutronix e.K. | |
>>>>>> Steuerwalder Str. 21 | http://www.pengutronix.de/ |
>>>>>> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
>>>>>> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555
>> |
>>>>>
>>>>
>>>> --
>>>> Pengutronix e.K. | |
>>>> Steuerwalder Str. 21 | http://www.pengutronix.de/ |
>>>> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
>>>> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
>>>
>>
>> --
>> Pengutronix e.K. | |
>> Steuerwalder Str. 21 | http://www.pengutronix.de/ |
>> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
>> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
>
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply [flat|nested] 40+ messages in thread
* RE: [PATCH v2] Porting barebox to a new SoC
2023-06-01 12:35 ` Ahmad Fatoum
@ 2023-06-06 12:54 ` Lior Weintraub
2023-06-06 14:34 ` Ahmad Fatoum
0 siblings, 1 reply; 40+ messages in thread
From: Lior Weintraub @ 2023-06-06 12:54 UTC (permalink / raw)
To: Ahmad Fatoum, Ahmad Fatoum, barebox
Hello Ahmad,
I managed to build a bl31.bin file from TF-A.
This is just a preliminary implementation (basically all functions I had to implement are empty) so I'm hoping it will allow running a bare minimum initial Linux kernel.
I tried to follow how imx8mq-bl31.bin was added into barebox and I think I got it right.
I have several indications that the BL31 is behaving as expected.
The initial implementation (without BL31) was running PBL from SRAM (address 0xC0_0000_0000),
decompressed barebox into DRAM (@ 0x07E0_0000) and jumped to barebox.
From ARM registers inspection we can see that we are @ EL3
Now with the inclusion of BL31, it starts @ SRAM (as before) but then test that we are in EL3 and if so,
copy full image (PBL+Barebox) into DRAM address 0x0800_0000,
copy BL31.bin into DRAM address 0x1000_0000 and jumps there.
The execution of BL31 does its thing and then sets execution level to EL2 and jumps to DRAM address 0x0800_0000 (hard coded address we used on BL31 TF-A compilation).
We now see the PBL starts running again (now from DRAM), skips the BL31 loading (because it sees that we are not in EL3) and continue as before.
PBL decompressed barebox into DRAM address 0x07E0_0000 and jump to barebox.
From ARM registers inspection we can see that we are @ EL2
Few questions:
1. Any comments or thoughts about the above flow?
2. Are we ready now to try loading kernel and rootfs? If so how?
3. Is it OK (or even recommended) to change BL31 so that it will enter EL1 instead of EL2 (as we do not plan to use virtualization).
Thanks again for your kind support,
Cheers,
Lior.
> -----Original Message-----
> From: Ahmad Fatoum <a.fatoum@pengutronix.de>
> Sent: Thursday, June 1, 2023 3:36 PM
> To: Lior Weintraub <liorw@pliops.com>; Ahmad Fatoum <ahmad@a3f.at>;
> barebox@lists.infradead.org
> Subject: Re: [PATCH v2] Porting barebox to a new SoC
>
> CAUTION: External Sender
>
> Hello Lior,
>
> On 01.06.23 13:45, Lior Weintraub wrote:
> > Hello Ahmad,
> >
> > Very interesting stuff.
> >
> > We actually did started TF-A integration few months ago and tested it on the
> QEMU running ARM virt machine.
> > The TF-A compilation didn't include BL31 image (probably this explains the
> "ERROR: BL2: Failed to load image id 3").
>
> I wouldn't recommend using TF-A as BL2. I am quite content with how
> it's done on NXP's i.MX SoCs, which is the flow I described at the
> end of my last mail. Instead of loading a FIP, TF-A would just
> return to DRAM (or maintain LR on TF-A entry and return to it).
>
> > For this code to run we used the following QEMU command:
> >
> > qemu-system-aarch64 -nographic -machine virt,secure=on -cpu cortex-
> a53,rvbar=0x0000000000 \
> > -smp 1 -m 1024 -bios bl1.bin -d unimp -semihosting-config
> enable=on,target=native \
> > -monitor telnet:localhost:1235,server,nowait -gdb tcp::1236
> >
> > Output:
> > NOTICE: bl1_early_platform_set
> > NOTICE: Booting Trusted Firmware
> > NOTICE: BL1: v2.7(debug):831de6588
> > NOTICE: BL1: Built : 12:40:08, May 28 2023
> > INFO: BL1: RAM 0xe0ee000 - 0xe0f6000
> > INFO: BL1: cortex_a53: CPU workaround for 835769 was applied
> > INFO: BL1: cortex_a53: CPU workaround for 843419 was applied
> > INFO: BL1: cortex_a53: CPU workaround for 855873 was applied
> > INFO: BL1: cortex_a53: CPU workaround for 1530924 was applied
> > INFO: BL1: Loading BL2
> > WARNING: Firmware Image Package header check failed.
> > INFO: Loading image id=1 at address 0xe07b000
> > INFO: Image id=1 loaded: 0xe07b000 - 0xe081201
> > NOTICE: BL1: Booting BL2
> > INFO: Entry point address = 0xe07b000
> > INFO: SPSR = 0x3c5
> > NOTICE: BL2: v2.7(debug):831de6588
> > NOTICE: BL2: Built : 12:40:08, May 28 2023
> > INFO: BL2: Doing platform setup
> > INFO: BL2: Loading image id 3
> > WARNING: Firmware Image Package header check failed.
> > WARNING: Failed to obtain reference to image id=3 (-2)
> > ERROR: BL2: Failed to load image id 3 (-2)
> >
> > When we tried to modify the TF-A code to use our SoC (e.g. change the start
> address to 0xC0_0400_0000 and use UART on 0xD0_0030_7000) it crashed
> with seg. Fault.
>
> Try building your BL31 as position-independent executable. The code doing
> fixed text area may be hardcoded to 32-bit. See here for an example
> of turning on PIE:
>
> https://ddec1-0-en-
> ctp.trendmicro.com:443/wis/clicktime/v1/query?url=https%3a%2f%2freview
> .trustedfirmware.org%2fc%2fTF%2dA%2ftrusted%2dfirmware%2da%2f%2b
> %2f16370&umid=0b12ecfc-4ee1-4f0b-90e0-
> 54ceaf590ca1&auth=860a7ebb9feba264acc79b6e38eb59582349362c-
> c3cc24ae937d0a564120b663c7b93f60c48f01b5
>
> > We didn't continue with this development effort and decided we will write
> our own BootROM as BL1
>
> Ye, I don't think TF-A is a good candidate for a BL1 (are there even
> other users that user TF-A that way?).
>
> > and use that to load u-boot or barebox
>
> That's ok. You just need BL31 to provide you runtime services (or maintain
> your
> Linux SoC support patches for ever).
>
> > Now I understand we better go back and study how to port TF-A to our SoC.
>
> :)
>
> Cheers,
> Ahmad
>
> >
> > Cheers,
> > Lior.
> >
> >
> >> -----Original Message-----
> >> From: Ahmad Fatoum <a.fatoum@pengutronix.de>
> >> Sent: Thursday, June 1, 2023 12:29 PM
> >> To: Lior Weintraub <liorw@pliops.com>; Ahmad Fatoum <ahmad@a3f.at>;
> >> barebox@lists.infradead.org
> >> Subject: Re: [PATCH v2] Porting barebox to a new SoC
> >>
> >> CAUTION: External Sender
> >>
> >> Hello Lior,
> >>
> >> On 01.06.23 10:54, Lior Weintraub wrote:
> >>> Hi Ahmad,
> >>>
> >>> Thanks again for your great support and the patch.
> >>> I've checked it and it works perfectly!
> >>> The UART issue was solved after fixing the device tree per your
> >> recommendations.
> >>> Now I can write into barbox terminal :-)
> >>
> >> Nice!
> >>
> >>> When I type "cpuinfo" on the terminal I am getting:
> >>> implementer: ARM
> >>> architecture: v8
> >>> core: Cortex-A53 r0p4
> >>> exception level: 3
> >>> cache: no cache
> >>> Control register: P D Z DT IT U XP
> >>
> >> FYI, barebox next (or maybe master?) branch adds mmuinfo command to
> >> arm64.
> >> You can use that to check if a specific address is cached or not.
> >>
> >>> Notice that it say "no cache".
> >>> I tried to add cache to cpu0 but it didn't help.
> >>>
> >>> .
> >>> .
> >>> d-cache-size = <0x8000>;
> >>> d-cache-line-size = <64>;
> >>> d-cache-sets = <128>; // 32KiB(size)/64(line-size)=512ways/4-way set
> >>> i-cache-size = <0x8000>;
> >>> i-cache-line-size = <64>;
> >>> i-cache-sets = <256>; // 32KiB(size)/64(line-size)=512ways/2-way set
> >>> next-level-cache = <&l2>;
> >>> };
> >>>
> >>> l2: l2-cache0 {
> >>> compatible = "cache";
> >>> cache-unified;
> >>> cache-size = <0x80000>;
> >>> cache-line-size = <64>;
> >>> cache-sets = <512>; // 512KiB(size)/64(line-size)=8192ways/16-way set
> >>> cache-level = <2>;
> >>> }
> >>
> >> barebox doesn't consume these nodes. What may be happening is that
> >> cpuinfo
> >> was written with the assumption that barebox executes at EL2 or EL1, so
> >> executing it at EL3 may end up accessing the wrong MSRs. Feel free to send
> >> a patch against arch/arm/cpu/cpuinfo.c, so it uses the correct register for
> >> EL3. current_el() will tell you which EL you are at.
> >>
> >>> Regarding Linux kernel:
> >>> This would be the next step but I assume that it would be a bit more
> >> complicated.
> >>
> >> Linux ARM64 Maintainers mandate that platforms implement the PSCI
> >> protocol.
> >> In your case with single core that means providing reset and poweroff
> >> handlers
> >> that the kernel can invoke via secure monitor call.
> >>
> >> barebox can consume psci: CONFIG_ARM_PSCI_CLIENT,
> CONFIG_CMD_SMC,
> >> but what
> >> you're missing is the provider side. barebox as PSCI provider is implemented
> >> only for a single ARM32 SoC, the i.MX7. All supported ARM64 platforms
> use
> >> TF-A as BL31 with the exception of Layerscape (which uses PPA, an NXP
> BL31
> >> implementation).
> >>
> >> What does this mean for you?
> >>
> >> 1) Either add your SoC to TF-A
> >> 2) Extend PSCI implementation in barebox for ARM64.
> >>
> >> While I think it would be cool to have barebox provide all of BL2, BL31 and
> >> BL32, I think you are better advised to use TF-A, because that's what most
> >> other ARM Silicon Vendors use. That means less effort for you and easier
> >> maintenance as you benefit from fixes done for other SoCs using the same
> >> IPs. barebox certainly benefits from being able to focus on being a
> bootloader
> >> and leaving the errata workarounds, GIC init stuff and runtime services
> >> to TF-A.
> >>
> >> The boot flow would then be:
> >>
> >> - barebox PBL runs as BL2 in SRAM and sets up DRAM
> >> - barebox PBL executes BL31 (TF-A) which was compiled into PBL
> >> - TF-A installs secure monitor and returns control to DRAM in EL2
> >> - barebox resumes execution in EL2 as BL33
> >> - Linux is invoked in EL2 and can communicate with secure monitor.
> >>
> >> You may find this talk interesting:
> >> https://fosdem.org/2023/schedule/event/uboot_psci/
> >> Even if I disagree a bit with the takeaway.
> >>
> >>> I guess we will have to integrate the interrupt controlled (GIC-600) into
> >> QEMU and into the device tree for it to work.
> >>> Is that a valid assumption?
> >>
> >> I never had to add a new SoC to Linux, so I can't give any better
> >> suggestions than Yes. Where you're going, you'll need interrupts.
> >>
> >> Godspeed and keep me posted :)
> >> Ahmad
> >>
> >>>
> >>> Thanks,
> >>> Lior.
> >>>
> >>>
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: Ahmad Fatoum <a.fatoum@pengutronix.de>
> >>>> Sent: Wednesday, May 31, 2023 8:55 PM
> >>>> To: Lior Weintraub <liorw@pliops.com>; Ahmad Fatoum
> <ahmad@a3f.at>;
> >>>> barebox@lists.infradead.org
> >>>> Subject: Re: [PATCH v2] Porting barebox to a new SoC
> >>>>
> >>>> CAUTION: External Sender
> >>>>
> >>>> Hi Lior,
> >>>>
> >>>> On 31.05.23 18:13, Lior Weintraub wrote:
> >>>>> Hi Ahmad,
> >>>>>
> >>>>> Using end of SRAM as PBL stack is currently not working because we
> need
> >>>> 40bit address (0xC0_0020_0000).
> >>>>> This needs a fix to ENTRY_FUNCTION_WITHSTACK macro.
> >>>>
> >>>> Ah, right. I just sent an (untested) patch. Would be cool if you could
> >>>> try it out.
> >>>>
> >>>>> I tried just to change const u32 __stack_top = (stack_top); to const u64
> >>>> __stack_top = (stack_top); but there were linking errors caused by:
> >>>>> ASSERT(. - __pbl_board_stack_top <= 8, "Only One PBL per Image
> >> allowed")
> >>>>
> >>>> The easy way would have been using a __attribute__((naked)) function,
> >> but
> >>>> those are only supported for arm32, not arm64. The alternative is thus
> >>>> writing the entry point in assembly and to make board authors life easier
> >>>> the linker script ensures that the stack setup entry point is invoked prior
> >>>> to the board entry.
> >>>>
> >>>>> Regarding the arm timer:
> >>>>> Adding the timer entry to DT solved the issue.
> >>>>>
> >>>>> Regarding the UART:
> >>>>> Indeed CONFIG_SERIAL_AMBA_PL011 was set on spider_defconfig
> (also
> >>>> verified it generated the correct entry on .config).
> >>>>> I also noticed that if I remove the putc_ll implementation there is no Tx
> at
> >> all
> >>>> from Barebox.
> >>>>
> >>>> I've led you astray. Indeed:
> >>>>
> >>>>>>> of_platform_bus_create() - skipping /soc, no compatible prop
> >>>>
> >>>> points at the issue.
> >>>>
> >>>> Try adding into /soc
> >>>>
> >>>> compatible = "simple,bus";
> >>>> ranges;
> >>>> dma-ranges;
> >>>>
> >>>> This matches /soc with the simple bus driver which just instantiates
> devices
> >>>> for the
> >>>> contained children. Those in turn should be matched by the drivers.
> >>>>
> >>>> The ranges stuff just tells that memory and SoC peripherals exist in the
> >> same
> >>>> address space.
> >>>>
> >>>> When it probes you may need to describe the clock in the DT. Eventually,
> >> you
> >>>> will
> >>>> want to have a clock driver for your hardware (good news: barebox and
> >> Linux
> >>>> have
> >>>> basically the same API, so you only need to write it once). But for now,
> you
> >>>> can
> >>>> fake it using fixed-clock in the DT. Take a look at:
> >>>>
> >>>> snps,dw-apb-uart in arch/riscv/dts/jh7100.dtsi and compare with
> >>>> dts/src/arm/imx28.dtsi
> >>>> to see how to map that to PL011.
> >>>>
> >>>>> Could it be a hint?
> >>>>
> >>>> DEBUG_LL bridges the gap until a driver registers a console that's
> enabled. If
> >>>> this
> >>>> never happens, you are left with a non-interactive shell.
> >>>>
> >>>> Cheers,
> >>>> Ahmad
> >>>>
> >>>>>
> >>>>> Thanks,
> >>>>> Lior.
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: Ahmad Fatoum <a.fatoum@pengutronix.de>
> >>>>>> Sent: Wednesday, May 31, 2023 11:40 AM
> >>>>>> To: Lior Weintraub <liorw@pliops.com>; Ahmad Fatoum
> >> <ahmad@a3f.at>;
> >>>>>> barebox@lists.infradead.org
> >>>>>> Subject: Re: [PATCH v2] Porting barebox to a new SoC
> >>>>>>
> >>>>>> CAUTION: External Sender
> >>>>>>
> >>>>>> Hi Lior,
> >>>>>>
> >>>>>> On 31.05.23 10:05, Lior Weintraub wrote:
> >>>>>>> Hi Ahmad,
> >>>>>>>
> >>>>>>> Thanks again for your prompt reply and accurate tips!
> >>>>>>> Took the following changes:
> >>>>>>> 1. Increasing the DRAM size to 128MB (let barebox start from 0).
> >>>>>>> 2. Set PBL stack to offset 2MB from DRAM
> >>>>>>
> >>>>>> Just use end of SRAM, so you are completely independent of DRAM
> >>>>>> until you call barebox_arm_entry.
> >>>>>>
> >>>>>>> 3. Fix the device tree "memory" entry to have 128MB.
> >>>>>>
> >>>>>> (y)
> >>>>>>
> >>>>>>> 4. Load barebox-spider-mk1-evk.img to SRAM and run from there.
> >>>>>>>
> >>>>>>> Now I can see the following logs:
> >>>>>>> uncompress.c: memory at 0x00000000, size 0x08000000
> >>>>>>> uncompress.c: uncompressing barebox binary at
> 0x000000c0000021c0
> >>>>>> (size 0x0001e3a4) to 0x07e00000 (uncompressed size: 0x000390d0)
> >>>>>>> uncompress.c: jumping to uncompressed image at
> >>>> 0x0000000007e00000
> >>>>>>> start.c: memory at 0x00000000, size 0x08000000
> >>>>>>> start.c: found DTB in boarddata, copying to 0x07dffcc0
> >>>>>>> start.c: initializing malloc pool at 0x079ffcc0 (size 0x00400000)
> >>>>>>> start.c: starting barebox...
> >>>>>>> initcall-> command_slice_init+0x0/0x3c
> >>>>>>> initcall-> globalvar_init+0x0/0x80
> >>>>>>> register_device: global
> >>>>>>> register_device: nv
> >>>>>>> initcall-> platform_init+0x0/0x1c
> >>>>>>> register_device: platform
> >>>>>>> initcall-> amba_bus_init+0x0/0x1c
> >>>>>>> register_device: amba
> >>>>>>> initcall-> spi_bus_init+0x0/0x1c
> >>>>>>> register_device: spi
> >>>>>>> initcall-> gpio_desc_alloc+0x0/0x24
> >>>>>>> initcall-> fs_bus_init+0x0/0x1c
> >>>>>>> register_device: fs
> >>>>>>> initcall-> aarch64_init_vectors+0x0/0x50
> >>>>>>> initcall-> gpio_gate_clock_driver_register+0x0/0x1c
> >>>>>>> register_driver: gpio-gate-clock
> >>>>>>> initcall-> of_arm_init+0x0/0x5c
> >>>>>>> start.c: barebox_arm_boot_dtb: using barebox_boarddata
> >>>>>>> using boarddata provided DTB
> >>>>>>> adding DT alias:serial0: stem=serial id=0
> >> node=/soc/serial@d000307000
> >>>>>>> register_device: machine
> >>>>>>> of_platform_bus_create() - skipping /chosen, no compatible prop
> >>>>>>> of_platform_bus_create() - skipping /aliases, no compatible prop
> >>>>>>> of_platform_bus_create() - skipping /cpus, no compatible prop
> >>>>>>> of_platform_bus_create() - skipping /memory@0, no compatible
> prop
> >>>>>>> of_platform_bus_create() - skipping /soc, no compatible prop
> >>>>>>> initcall-> register_autoboot_vars+0x0/0x70
> >>>>>>> initcall-> arm_arch_timer_driver_register+0x0/0x1c
> >>>>>>> register_driver: arm-architected-timer
> >>>>>>> initcall-> of_timer_init+0x0/0x20
> >>>>>>> initcall-> init_fs+0x0/0x3c
> >>>>>>> initcall-> pl011_driver_register+0x0/0x1c
> >>>>>>> register_driver: uart-pl011
> >>>>>>> initcall-> of_stdoutpath_init+0x0/0x28
> >>>>>>> initcall-> of_probe_memory+0x0/0x60
> >>>>>>> __request_region ok: 0x00000000:0x07ffffff flags=0x0
> >>>>>>> initcall-> __bare_init_end+0x0/0x6c
> >>>>>>> register_device: mem0
> >>>>>>> initcall-> of_reserved_mem_walk+0x0/0x1ac
> >>>>>>> initcall-> mem_malloc_resource+0x0/0xa8
> >>>>>>> __request_region ok: 0x079ffcc0:0x07dffcbf flags=0x200
> >>>>>>> __request_region ok: 0x07e00000:0x07e2aeff flags=0x200
> >>>>>>> __request_region ok: 0x07e2af00:0x07e390cf flags=0x200
> >>>>>>> __request_region ok: 0x07e390d0:0x07e3adaf flags=0x200
> >>>>>>> initcall-> bootsource_init+0x0/0x40
> >>>>>>> initcall-> ramfs_init+0x0/0x1c
> >>>>>>> register_driver: ramfs
> >>>>>>> initcall-> devfs_init+0x0/0x1c
> >>>>>>> register_driver: devfs
> >>>>>>> initcall-> arm_request_stack+0x0/0x398
> >>>>>>> __request_region ok: 0x07ff0000:0x07ff7fff flags=0x200
> >>>>>>> initcall-> mount_root+0x0/0x7c
> >>>>>>> mount: none on / type ramfs, options=
> >>>>>>> register_device: ramfs0
> >>>>>>> probe-> ramfs0
> >>>>>>> mount: none on /dev type devfs, options=
> >>>>>>> register_device: devfs0
> >>>>>>> probe-> devfs0
> >>>>>>> initcall-> binfmt_sh_init+0x0/0x1c
> >>>>>>> initcall-> binfmt_uimage_init+0x0/0x1c
> >>>>>>> initcall-> console_common_init+0x0/0x48
> >>>>>>> initcall-> of_kernel_init+0x0/0x28
> >>>>>>> initcall-> console_ctrlc_init+0x0/0x30
> >>>>>>> initcall-> mem_init+0x0/0x90
> >>>>>>> register_device: mem1
> >>>>>>> register_driver: mem
> >>>>>>> probe-> mem0
> >>>>>>> probe-> mem1
> >>>>>>> initcall-> of_partition_init+0x0/0x48
> >>>>>>> initcall-> prng_init+0x0/0x40
> >>>>>>> initcall-> null_init+0x0/0x40
> >>>>>>> initcall-> full_init+0x0/0x40
> >>>>>>> initcall-> zero_init+0x0/0x40
> >>>>>>> initcall-> spider_board_driver_register+0x0/0x1c
> >>>>>>> register_driver: board-spider
> >>>>>>> probe-> machine
> >>>>>>> initcall-> barebox_memory_areas_init+0x0/0x40
> >>>>>>> __request_region ok: 0x07dffcc0:0x07dfffce flags=0x200
> >>>>>>> initcall-> barebox_of_populate+0x0/0x28
> >>>>>>> initcall-> of_register_memory_fixup+0x0/0x20
> >>>>>>> initcall-> dummy_csrc_warn+0x0/0x44
> >>>>>>> WARNING: Warning: Using dummy clocksource
> >>>>>>
> >>>>>> Add a arm,armv8-timer node into your SoC device tree.
> >>>>>> This lets barebox and Linux know that you have the ARM
> >>>>>> architected timer available. Without that, you'll notice
> >>>>>> that timeouts are wrong.
> >>>>>>
> >>>>>>> initcall-> bootm_init+0x0/0xf4
> >>>>>>> initcall-> init_command_list+0x0/0x40
> >>>>>>> register command bootm
> >>>>>>> register command cat
> >>>>>>> register command cd
> >>>>>>> register command clear
> >>>>>>> register command cp
> >>>>>>> register command cpuinfo
> >>>>>>> register command devinfo
> >>>>>>> register command drvinfo
> >>>>>>> register command echo
> >>>>>>> register command exit
> >>>>>>> register command false
> >>>>>>> register command help
> >>>>>>> register command ?
> >>>>>>> register command ll
> >>>>>>> register command ls
> >>>>>>> register command md
> >>>>>>> register command memcmp
> >>>>>>> register command memcpy
> >>>>>>> register command memset
> >>>>>>> register command mkdir
> >>>>>>> register command mount
> >>>>>>> register command mw
> >>>>>>> register command pwd
> >>>>>>> register command rm
> >>>>>>> register command rmdir
> >>>>>>> register command setenv
> >>>>>>> register command sh
> >>>>>>> register command source
> >>>>>>> register command .
> >>>>>>> register command test
> >>>>>>> register command [
> >>>>>>> register command true
> >>>>>>> register command :
> >>>>>>> register command umount
> >>>>>>> register command version
> >>>>>>> initcall-> display_meminfo+0x0/0xa8
> >>>>>>> barebox code: 0x7e00000 -> 0x7e2aeff
> >>>>>>> bss segment: 0x7e390d0 -> 0x7e3adaf
> >>>>>>> malloc space: 0x079ffcc0 -> 0x07dffcbf (size 4 MiB)
> >>>>>>> initcall-> of_register_bootargs_fixup+0x0/0x3c
> >>>>>>> initcall-> device_probe_deferred+0x0/0x14c
> >>>>>>> initcall-> of_init_hostname+0x0/0x28
> >>>>>>> initcall-> aarch64_register_image_handler+0x0/0x2c
> >>>>>>> initcall-> load_environment+0x0/0x4c
> >>>>>>> loading defaultenv
> >>>>>>> environment load /dev/env0: No such file or directory
> >>>>>>> Maybe you have to create the partition.
> >>>>>>> initcalls done
> >>>>>>>
> >>>>>>> Hit any to stop autoboot: 0
> >>>>>>> boot: No such file or directory
> >>>>>>> barebox:/
> >>>>>>>
> >>>>>>>
> >>>>>>> Few questions:
> >>>>>>> 1. The serial input doesn't work. i.e. I cannot type anything hence
> >> cannot
> >>>>>> interact with barebox terminal.
> >>>>>>
> >>>>>> DEBUG_LL only does otuput. For input, you will want to load the
> driver.
> >>>>>> Do you have CONFIG_SERIAL_AMBA_PL011 enabled?
> >>>>>>
> >>>>>>> Does it require GIC and setting interrupts for it to work?
> >>>>>>
> >>>>>> No interrupts needed. barebox runs with interrupts disabled and
> >>>> everything
> >>>>>> is done cooperatively.
> >>>>>>
> >>>>>>> 2. What does "of_platform_bus_create() - skipping" means? Do I
> need
> >> to
> >>>> fix
> >>>>>> that?
> >>>>>>
> >>>>>> That's normal debugging output. Some device tree nodes are busses,
> >> which
> >>>>>> have
> >>>>>> children. These entries are skipped because they have no compatible.
> >> This is
> >>>>>> expected. I'd suggest you remove your VERBOSED_DEBUG define, so
> you
> >>>> are
> >>>>>> not
> >>>>>> spammed by too much debugging output.
> >>>>>>
> >>>>>>> 3. Looks like I am still missing some stuff (rootfs? Environment?
> >>>> Mounting?
> >>>>>> Partitions?)
> >>>>>>
> >>>>>> Take multi_v8_defconfig, open menuconfig and enable your SoC and
> use
> >>>> that.
> >>>>>> That will be quicker than enabling everything yourself. If it doesn't
> work
> >>>>>> out of the box, try imx_v8_defconfig.
> >>>>>>
> >>>>>> Once you get around to upstreaming your SoC, I'd suggest you just
> add it
> >>>>>> to multi_v8_defconfig. Not all ARMv8 SoCs are supported there, but
> >> those
> >>>>>> that are make development easier, because we don't need to build as
> >> many
> >>>>>> different configs..
> >>>>>>
> >>>>>> Cheers,
> >>>>>> Ahmad
> >>>>>>
> >>>>>>>
> >>>>>>> Thanks,
> >>>>>>> Have a great day,
> >>>>>>> Lior.
> >>>>>>>
> >>>>>>>
> >>>>>>>> -----Original Message-----
> >>>>>>>> From: Ahmad Fatoum <a.fatoum@pengutronix.de>
> >>>>>>>> Sent: Wednesday, May 31, 2023 9:11 AM
> >>>>>>>> To: Lior Weintraub <liorw@pliops.com>; Ahmad Fatoum
> >>>> <ahmad@a3f.at>;
> >>>>>>>> barebox@lists.infradead.org
> >>>>>>>> Subject: Re: [PATCH v2] Porting barebox to a new SoC
> >>>>>>>>
> >>>>>>>> CAUTION: External Sender
> >>>>>>>>
> >>>>>>>> Hi Lior,
> >>>>>>>>
> >>>>>>>> On 30.05.23 22:10, Lior Weintraub wrote:
> >>>>>>>>> Hello Ahmad,
> >>>>>>>>>
> >>>>>>>>> Thanks again for your kind support!
> >>>>>>>>> Your comments helped me progress and the current situation is as
> >>>>>> follows:
> >>>>>>>>> Our QEMU Spider machine is running a BL1.elf file using the
> following
> >>>>>>>> command:
> >>>>>>>>> QEMU_AUDIO_DRV=none qemu-system-aarch64 -M spider-soc -
> >> smp 1
> >>>> -
> >>>>>> m
> >>>>>>>> 128M -nographic \
> >>>>>>>>> -device loader,file=BL1.elf -cpu cortex-
> a53,rvbar=0xC004000000 \
> >>>>>>>>> -d unimp -semihosting-config enable=on,target=native \
> >>>>>>>>> -monitor telnet:localhost:1235,server,nowait \
> >>>>>>>>> -gdb tcp::1236
> >>>>>>>>>
> >>>>>>>>> The BL1.elf is our BootROM application that runs from ROM
> address
> >>>>>>>> 0xC004000000.
> >>>>>>>>> Just for debugging purpose we've increased the ROM size so it can
> >>>> include
> >>>>>>>> the images/barebox-spider-mk1-evk.img (as a const array).
> >>>>>>>>> BL1 then copy it (using memcpy) to address 0 and jumps there for
> >>>>>>>> execution.
> >>>>>>>>
> >>>>>>>> Sounds ok.
> >>>>>>>>
> >>>>>>>>> On the real ASIC this address will be the DRAM and indeed will need
> >> to
> >>>> be
> >>>>>>>> initialized before the copy but here on QEMU it is not required.
> >>>>>>>>
> >>>>>>>> I see. You could still have your bootrom move barebox into SRAM
> and
> >>>> then
> >>>>>>>>
> >>>>>>>> barebox_arm_entry(DRAM_ADDR, SZ_128M,
> >>>>>> __dtb_spider_mk1_evk_start);
> >>>>>>>>
> >>>>>>>> To have PBL extract barebox to DRAM. Even if you don't need need
> >>>> DRAM
> >>>>>>>> setup in QEMU, the flow would be similar to what you will have on
> >> actual
> >>>>>>>> silicon.
> >>>>>>>>
> >>>>>>>>> The lowlevel.c of spider-evk was modified to use DRAM_ADDR
> >>>> 0x400000
> >>>>>>>> (4MB from start) and MY_STACK_TOP was set to 0x8000000
> (128M).
> >>>>>>>>
> >>>>>>>> That's not needed. While you don't have control where barebox PBL
> >> will
> >>>> be
> >>>>>>>> located
> >>>>>>>> (depends on BootROM), barebox will extract itself to the end of
> DRAM
> >>>>>>>> without
> >>>>>>>> overwriting itself, so you can just use DRAM_ADDR 0 normally.
> >>>> Eventually,
> >>>>>>>> stack
> >>>>>>>> top should go into SRAM, but anywhere that works is ok.
> >>>>>>>>
> >>>>>>>>> In addition, I implemented putc_ll (currently hard-coded in
> >>>>>>>> include/debug_ll.h) and opened log level to VERBOSE_DEBUG
> >> (currently
> >>>>>> just
> >>>>>>>> hard-coded in printk.h).
> >>>>>>>>
> >>>>>>>> There's CONFIG_DEBUG_PBL you can enable to get all these
> messages
> >> by
> >>>>>>>> default.
> >>>>>>>>
> >>>>>>>>> I see the following (which makes sense) logs on QEMU terminal:
> >>>>>>>>> uncompress.c: memory at 0x00400000, size 0x00200000
> >>>>>>>>> uncompress.c: uncompressing barebox binary at
> >>>> 0x0000000000002200
> >>>>>>>> (size 0x0001d3b2) to 0x00400000 (uncompressed size:
> 0x000373d0)
> >>>>>>>>
> >>>>>>>> Why pass only 2M to barebox_arm_entry? While this need not be
> the
> >>>>>> whole
> >>>>>>>> of RAM, this
> >>>>>>>> initial memory is what barebox will use for itself including its final
> stack
> >>>> and
> >>>>>>>> malloc area. barebox will also not place itself into the last 1M AFAIK,
> so
> >>>> 2M
> >>>>>>>> may not work ok. You should use the minimum possible RAM here
> or
> >> if
> >>>> you
> >>>>>>>> can detect
> >>>>>>>> in PBL how much RAM you have or just the whole RAM bank. I am
> not
> >>>> sure
> >>>>>>>> anything lower
> >>>>>>>> than SZ_4M would work ok. (Note this is DRAM size, not SRAM.
> >> barebox
> >>>>>> PBL
> >>>>>>>> is fine being
> >>>>>>>> called from 64K SRAMs, it just needs DRAM to extract to).
> >>>>>>>>
> >>>>>>>>> I then connect with aarch64-none-elf-gdb, load the barebox
> symbols
> >>>> (to
> >>>>>>>> 0x400000) and check the current execution state (program counter
> >> and
> >>>>>>>> stack).
> >>>>>>>>> Looks like the code is stuck on function register_autoboot_vars:
> >>>>>>>>> sp 0x5f7e60 0x5f7e60
> >>>>>>>>> pc 0x401264 0x401264 <register_autoboot_vars+24>
> >>>>>>>>>
> >>>>>>>>> Few observations:
> >>>>>>>>> 1. The PBL was using stack top located on 0x8000000 (which is
> >>>>>>>> MY_STACK_TOP). Found it be causing a breakpoint on the PBL.
> >>>>>>>>> 2. Barebox uses a stack top on 0x600000 which is probably
> calculated
> >>>>>> from
> >>>>>>>> my new DRAM_ADDR and SZ_2M given to the function call:
> >>>>>>>>> barebox_arm_entry(DRAM_ADDR, SZ_2M,
> >>>>>> __dtb_spider_mk1_evk_start);
> >>>>>>>>>
> >>>>>>>>> This is great! I am starting to find my way.
> >>>>>>>>
> >>>>>>>> :) Ye, the ENTRY_FUNCTION_WITHSTACK is only when the BootROM
> >>>>>> doesn't
> >>>>>>>> enter
> >>>>>>>> with a valid stack pointer. It's overwritten as soon as barebox is told
> >>>>>>>> about the initial memory layout (with barebox_arm_entry).
> >>>>>>>>
> >>>>>>>>> When the barebox execution didn't print anything to the terminal I
> >>>>>>>> remembered that we used a place holder on the dtsi for the uart.
> >>>>>>>>> So now I changed it to:
> >>>>>>>>> uart0: serial@d000307000 {
> >>>>>>>>> compatible = "arm,pl011", "arm,primecell";
> >>>>>>>>> reg = <0xd0 0x307000 0 0x1000>;
> >>>>>>>>> }
> >>>>>>>>> (Our QEMU UART is currently using pl011 device.)
> >>>>>>>>
> >>>>>>>> Looks ok. Don't forget to enable the driver (via make menuconfig).
> >>>>>>>>
> >>>>>>>>> After some time (trying to debug by enabling MMU but then
> reverted
> >>>> the
> >>>>>>>> code back), I got to a point that when I try to run again I am getting
> an
> >>>>>>>> exception.
> >>>>>>>>> I can swear all code changes were reverted back to the point where
> I
> >>>> saw
> >>>>>> the
> >>>>>>>> barebox stuck on register_autoboot_vars but now it just cases an
> >>>>>> exception.
> >>>>>>>>> The exception vector code is located on our ROM (part of BL1 code)
> >> and
> >>>>>> the
> >>>>>>>> logs shows that the link register has the value 0x401218 which
> suggest
> >>>> the
> >>>>>>>> following code:
> >>>>>>>>> 0000000000001200 <load_environment>:
> >>>>>>>>> 1200: a9be7bfd stp x29, x30, [sp, #-32]!
> >>>>>>>>> 1204: 910003fd mov x29, sp
> >>>>>>>>> 1208: a90153f3 stp x19, x20, [sp, #16]
> >>>>>>>>> 120c: 94000a07 bl 3a28 <default_environment_path_get>
> >>>>>>>>> 1210: d00000f3 adrp x19, 1f000 <do_cpuinfo+0x1f0>
> >>>>>>>>> 1214: 912a7273 add x19, x19, #0xa9c
> >>>>>>>>> 1218: aa0003f4 mov x20, x0
> >>>>>>>>>
> >>>>>>>>> Any ideas or suggestions how to proceed with the debugging?
> >>>>>>>>
> >>>>>>>> You shouldn't need to touch the MMU code. If your initial memory
> >> setup
> >>>>>>>> is wonky, you may end up overwriting stuff. Try again with bigger
> >>>> memory.
> >>>>>>>>
> >>>>>>>>> BTW, to answer your questions:
> >>>>>>>>> The SRAM of 4MB is the only one we have because we assumed it
> is
> >>>> only
> >>>>>> for
> >>>>>>>> BootROM to load a PBL
> >>>>>>>>
> >>>>>>>> Ok. Sometimes there are SRAMs for use with DMA. I asked, because
> a
> >>>>>> SRAM
> >>>>>>>> in the first 4M
> >>>>>>>> would lend itself nicely as stack, but if there is none, we can adjust
> >>>>>>>> ENTRY_FUNCTION_WITHSTACK to accept a 64-bit parameter.
> >>>>>>>>
> >>>>>>>> Cheers,
> >>>>>>>> Ahmad
> >>>>>>>>
> >>>>>>>>> Thank you very much,
> >>>>>>>>> Cheers,
> >>>>>>>>> Lior.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> -----Original Message-----
> >>>>>>>>>> From: Ahmad Fatoum <a.fatoum@pengutronix.de>
> >>>>>>>>>> Sent: Monday, May 29, 2023 10:03 PM
> >>>>>>>>>> To: Lior Weintraub <liorw@pliops.com>; Ahmad Fatoum
> >>>>>> <ahmad@a3f.at>;
> >>>>>>>>>> barebox@lists.infradead.org
> >>>>>>>>>> Subject: Re: [PATCH v2] Porting barebox to a new SoC
> >>>>>>>>>>
> >>>>>>>>>> CAUTION: External Sender
> >>>>>>>>>>
> >>>>>>>>>> Hello Lior,
> >>>>>>>>>>
> >>>>>>>>>> On 29.05.23 15:34, Lior Weintraub wrote:
> >>>>>>>>>>> Hi Ahmad,
> >>>>>>>>>>>
> >>>>>>>>>>> I have revised the addresses and used DRAM address @ 0
> instead:
> >>>>>>>>>>> #define UARTBASE (0xD000307000)
> >>>>>>>>>>> #define DRAM_ADDR (0x00000000)
> >>>>>>>>>>> #define MY_STACK_TOP (0x00000000 + SZ_2M) // Set the
> stack
> >>>> 2MB
> >>>>>>>> from
> >>>>>>>>>> DRAM start
> >>>>>>>>>>
> >>>>>>>>>> Is DRAM configured by the time barebox runs? If not, you should
> >> keep
> >>>>>>>> stack
> >>>>>>>>>> top
> >>>>>>>>>> in SRAM, until you have setup memory in prebootloader (PBL). Is
> >> the
> >>>> 4M
> >>>>>>>>>> SRAM
> >>>>>>>>>> the only on-chip SRAM you have?
> >>>>>>>>>>
> >>>>>>>>>>> static inline void spider_serial_putc(void *base, int c)
> >>>>>>>>>>> {
> >>>>>>>>>>> *((volatile unsigned *)base) = c;
> >>>>>>>>>>
> >>>>>>>>>> There's a helper for that: writel(c, base); In barebox, it's equivalent
> >>>>>>>>>> to the volatile access, but in Linux it involves a write memory
> barrier.
> >>>>>>>>>> We try to write code in barebox, so it's easily reusable in Linux
> (and
> >>>>>>>>>> the other way round).
> >>>>>>>>>>
> >>>>>>>>>>> }
> >>>>>>>>>>>
> >>>>>>>>>>> I will try to test it on QEMU using an initial QEMU machine we
> >> made
> >>>> for
> >>>>>>>>>> Spider.
> >>>>>>>>>>> In this machine we only have 3 memory regions and a PL011
> UART:
> >>>>>>>>>>> spider_soc_memories soc_memories[] = {
> >>>>>>>>>>> {.name = "SPIDER_GPRAM", .add = 0xC000000000ULL, .size =
> 4
> >> *
> >>>>>> MiB},
> >>>>>>>>>>> {.name = "SPIDER_ROM", .add = 0xC004000000ULL, .size =
> >> 128 *
> >>>>>>>> KiB},
> >>>>>>>>>>> {.name = "SPIDER_DRAM", .add = 0x0000000000ULL, .size =
> 1
> >> *
> >>>>>> GiB},
> >>>>>>>>>>> };
> >>>>>>>>>>>
> >>>>>>>>>>> This special QEMU machine can run our BL1 code from "ROM"
> >>>> address
> >>>>>>>> (we
> >>>>>>>>>> set the RVBAR to point there).
> >>>>>>>>>>> So my idea is to test the barebox image by the following steps:
> >>>>>>>>>>> 1. Modify the QEMU code to have a "ROM" with the size of
> 128M.
> >>>>>>>>>>> 2. Compile our BL1 code to include the barebox.bin as a const
> >> array,
> >>>>>> copy
> >>>>>>>> it
> >>>>>>>>>> to "DRAM" @ address 0 and jump there.
> >>>>>>>>>>
> >>>>>>>>>> Why not map QEMU -bios option to SRAM? (Or DRAM directly, if
> it
> >>>>>> needs
> >>>>>>>> no
> >>>>>>>>>> special setup from
> >>>>>>>>>> barebox side).
> >>>>>>>>>>
> >>>>>>>>>>> For this to work I wanted to understand how to call (i.e. what
> >>>>>> arguments
> >>>>>>>> to
> >>>>>>>>>> pass) to barebox.
> >>>>>>>>>>
> >>>>>>>>>> barebox doesn't expect any arguments, because most BootROMs
> >>>> don't
> >>>>>>>> pass
> >>>>>>>>>> anything useful.
> >>>>>>>>>> Some pass information about bootsource though, so that's why
> the
> >>>>>>>>>> ENTRY_FUNCTION has
> >>>>>>>>>> r0, r1 and r2 as parameters, but you need not use them.
> >>>>>>>>>>
> >>>>>>>>>>> So I checked the barebox.map and found the function "start" on
> >>>>>> address
> >>>>>>>> 0.
> >>>>>>>>>>
> >>>>>>>>>> You may know that Linux on some platforms comes with a
> >>>> decompressor
> >>>>>>>> that
> >>>>>>>>>> is glued to the
> >>>>>>>>>> front of the kernel image and extracts the compressed kernel
> image.
> >>>>>>>> barebox
> >>>>>>>>>> has the same
> >>>>>>>>>> concept. The prebootloader is uncompressed and runs (starting
> >> from
> >>>>>>>>>> ENTRY_FUNCTION) and
> >>>>>>>>>> then does some early setup (e.g. enable clocks, configure PMIC,
> >> setup
> >>>>>>>> DRAM,
> >>>>>>>>>> load secure
> >>>>>>>>>> monitor (BL31), ...etc.) and then it decompresses barebox proper
> >> into
> >>>>>>>> DRAM.
> >>>>>>>>>>
> >>>>>>>>>> barebox.bin <- barebox proper. You don't usually need that.
> >>>>>>>>>> barebox.elf <- ELF binary for the above (for gdb)
> >>>>>>>>>> barebox.map <- map file of the above
> >>>>>>>>>>
> >>>>>>>>>> images/barebox-spider-mk1-evk.img <- complete barebox image
> >> (PBL
> >>>> +
> >>>>>>>>>> barebox proper)
> >>>>>>>>>> images/start_spider_mk1_evk.pbl <- ELF image for the above
> >>>>>>>>>> images/start_spider_mk1_evk.pbl.map <- map file of the above
> >>>>>>>>>>
> >>>>>>>>>> If you want to follow barbeox from the start, begin at
> >>>>>>>> start_spider_mk1_evk.
> >>>>>>>>>>
> >>>>>>>>>>> Then I went to arch/arm/cpu/start.c and realized that the code is
> >>>>>> compiled
> >>>>>>>>>> with CONFIG_PBL_IMAGE.
> >>>>>>>>>>> In that case I assume I need to pass 3 arguments and use this
> >>>> function
> >>>>>>>>>> prototype:
> >>>>>>>>>>> void start(unsigned long membase, unsigned long memsize, void
> >>>>>>>>>> *boarddata);
> >>>>>>>>>>
> >>>>>>>>>> barebox prebootloader takes care of this, so you don't need to do
> >>>>>> anything.
> >>>>>>>>>>
> >>>>>>>>>>> Few questions:
> >>>>>>>>>>> 1. Will that call work:
> >>>>>>>>>>> typedef void (*barebox_start)(unsigned long , unsigned long ,
> >> void
> >>>> *);
> >>>>>>>>>>> #define DRAM_START (0)
> >>>>>>>>>>> barebox_start p_barebox = (barebox_start)DRAM_START;
> >>>>>>>>>>> p_barebox(DRAM_START, DRAM_START+SZ_2M, (void
> >>>>>>>>>> *)(DRAM_START+SZ_4M));
> >>>>>>>>>>> This assumes that my BL1 code also copied the device tree
> >>>> (barebox-
> >>>>>> dt-
> >>>>>>>>>> 2nd.img? start_dt_2nd.pblb? start_spider_mk1_evk.pblb?)
> >>>>>>>>>>
> >>>>>>>>>> The device tree is built into the PBL and passed to barebox proper.
> >> This
> >>>>>>>>>> allows us to use the same barebox proper binary and link it with a
> >>>>>> different
> >>>>>>>>>> prebootloader for each SoC/board, all in the same build.
> >>>>>>>>>>
> >>>>>>>>>> barebox-dt-2nd.img is a special image that looks exactly like a
> Linux
> >>>>>> kernel:
> >>>>>>>>>>
> >>>>>>>>>> images/barebox-dt-2nd.img: Linux kernel ARM64 boot
> executable
> >>>>>> Image,
> >>>>>>>>>> little-endian, 4K pages
> >>>>>>>>>>
> >>>>>>>>>> and can thus be used for booting for easy chainloading from other
> >>>>>>>>>> bootloaders or for running
> >>>>>>>>>> with QEMU -kernel. You shouldn't need it right now.
> >>>>>>>>>>
> >>>>>>>>>>> 2. Do I want to have my code compiled with
> CONFIG_PBL_IMAGE?
> >>>>>>>>>>> If I understand correctly, it means that my code will provide a
> PBL
> >>>>>> (a.k.a
> >>>>>>>>>> BL2) which will set the DRAM and STACK among other things
> >> (MMU?).
> >>>>>>>>>>
> >>>>>>>>>> The patch I sent already builds a PBL. You will need to fill out
> >>>>>>>>>> start_spider_mk1_evk
> >>>>>>>>>> to do all the other early initialization you need. Then you call
> >>>>>>>>>> barebox_arm_entry
> >>>>>>>>>> with device tree and memory size and it will take care to do stack
> >> setup
> >>>> in
> >>>>>>>> new
> >>>>>>>>>> memory region, MMU setup (if enabled) and chainloading
> barebox
> >>>>>> proper.
> >>>>>>>>>>
> >>>>>>>>>> Note that PBL isn't necessary BL2. You can chainload barebox
> from
> >>>> within
> >>>>>>>>>> barebox (i.e.
> >>>>>>>>>> in EL2 or EL1), which is useful for debugging. You will thus often
> find
> >>>> PBL
> >>>>>>>> code
> >>>>>>>>>> that
> >>>>>>>>>> does
> >>>>>>>>>>
> >>>>>>>>>> if (current_el() == 3) {
> >>>>>>>>>> /* Do BL2 setup */
> >>>>>>>>>> chainload();
> >>>>>>>>>> __builtin_unreachable();
> >>>>>>>>>> }
> >>>>>>>>>>
> >>>>>>>>>> barebox_arm_entry(...)
> >>>>>>>>>>
> >>>>>>>>>> See for example arch/arm/boards/innocomm-imx8mm-
> >>>> wb15/lowlevel.c
> >>>>>>>>>>
> >>>>>>>>>> to see a real-world example of another Cortex-A53.
> >>>>>>>>>>
> >>>>>>>>>>> In that case I assume it is OK.
> >>>>>>>>>>> 3. If I try to remove it by having CONFIG_PBL_IMAGE=n on
> >>>>>>>> spider_defconfig
> >>>>>>>>>> this doesn't do anything
> >>>>>>>>>>> The build (make spider_defconfig) ignores it and say that " No
> >>>> change
> >>>>>> to
> >>>>>>>>>> .config ".
> >>>>>>>>>>
> >>>>>>>>>> Another symbol forces it to be enabled. If you are curious, run
> make
> >>>>>>>>>> menuconfig
> >>>>>>>>>> and then search (/) for the symbol and it will list, whether it's
> >> enabled
> >>>>>> and
> >>>>>>>>>> why:
> >>>>>>>>>>
> >>>>>>>>>> Selected by [y]:
> >>>>>>>>>> - PBL_MULTI_IMAGES [=y] && HAVE_PBL_MULTI_IMAGES [=y]
> >>>>>>>>>>
> >>>>>>>>>> I'd suggest you avoid modifying the .config file manually. always
> use
> >>>>>>>>>> menuconfig.
> >>>>>>>>>>
> >>>>>>>>>>> 4. I also tried to understand how to implement PUTC_LL but not
> >> sure
> >>>> I
> >>>>>>>>>> understand.
> >>>>>>>>>>> 4.1 When I set "CONFIG_DEBUG_LL=y" on spider_defconfig it is
> >>>> again
> >>>>>>>> not
> >>>>>>>>>> written to .config and I get " No change to .config " message.
> >>>>>>>>>>
> >>>>>>>>>> You must:
> >>>>>>>>>>
> >>>>>>>>>> - select HAS_DEBUG_LL from MACH_SPIDER
> >>>>>>>>>> - Add your arch to arch/arm/include/asm/debug_ll.h
> >>>>>>>>>> - Then implement PUTC_LL in e.g. mach/spider/debug_ll.h
> >>>>>>>>>>
> >>>>>>>>>>> 4.2 Do I need to have my own debug_ll.h file?
> >>>>>>>>>>
> >>>>>>>>>> Yes. See above.
> >>>>>>>>>>
> >>>>>>>>>>> 5. When I make changes to spider_defconfig and try to
> regenerate
> >>>> the
> >>>>>>>>>> .config and I get " No change to .config " message, does it mean
> that
> >>>>>> those
> >>>>>>>>>> macros are "hidden" symbols like you said about the
> >>>> CONFIG_CPU_V8?
> >>>>>>>>>>
> >>>>>>>>>> Yes. Just check menuconfig to see how symbols relate to each
> other.
> >>>>>>>>>> This is 1:1 like it's in Linux, so it'll come in handy when you do
> >>>>>>>>>> the kernel port too ;)
> >>>>>>>>>>
> >>>>>>>>>>> Apologize for so many questions :-)
> >>>>>>>>>>
> >>>>>>>>>> No problem. Looking forward to your patches ;)
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Cheers,
> >>>>>>>>>> Ahmad
> >>>>>>>>>>
> >>>>>>>>>>> Cheers,
> >>>>>>>>>>> Lior.
> >>>>>>>>>>>
> >>>>>>>>>>> -----Original Message-----
> >>>>>>>>>>> From: Lior Weintraub
> >>>>>>>>>>> Sent: Sunday, May 28, 2023 11:16 PM
> >>>>>>>>>>> To: Ahmad Fatoum <ahmad@a3f.at>;
> barebox@lists.infradead.org
> >>>>>>>>>>> Subject: RE: [PATCH v2] Porting barebox to a new SoC
> >>>>>>>>>>>
> >>>>>>>>>>> Hi Ahmad,
> >>>>>>>>>>>
> >>>>>>>>>>> Thank you so much for your kind support!
> >>>>>>>>>>>
> >>>>>>>>>>> Indeed we also have a 16GB DRAM that starts from address 0
> >>>> (though
> >>>>>>>>>> currently we don't have the controller settings (under
> >> development)).
> >>>>>>>>>>>
> >>>>>>>>>>> I also wrote the BootROM (BL1) for this SoC (128KB ROM @
> >> address
> >>>>>>>>>> 0xC004000000).
> >>>>>>>>>>> I understand now that it would be best for me to develop BL2
> that
> >>>> will
> >>>>>> run
> >>>>>>>>>> from our SRAM.
> >>>>>>>>>>>
> >>>>>>>>>>> As this BL2 code is bare-metal I have no problem or limitations
> with
> >>>> the
> >>>>>> 40
> >>>>>>>>>> bit addresses.
> >>>>>>>>>>> The BL2 code will initialize the DRAM controller and then copy
> >>>> Barebox
> >>>>>>>> image
> >>>>>>>>>> from NOR Flash to address 0 of the DRAM.
> >>>>>>>>>>> Our NOR Flash is 128MB in size and it is accessed via QSPI
> >> controller.
> >>>>>>>>>>>
> >>>>>>>>>>> I tried applying your suggested patch but got an error while
> doing
> >> so:
> >>>>>>>>>>> $git apply 0002-Ahmad.patch
> >>>>>>>>>>> 0002-Ahmad.patch:115: trailing whitespace.
> >>>>>>>>>>> .of_compatible = spider_board_of_match, };
> >>>>>>>>>>> error: corrupt patch at line 117
> >>>>>>>>>>>
> >>>>>>>>>>> After some digging I found that my Outlook probably messed
> with
> >>>> the
> >>>>>>>> patch
> >>>>>>>>>> format (even though I am using text only and no HTML format).
> >>>>>>>>>>> When I went to the web and copied the patch from there
> (mailing
> >> list
> >>>>>>>>>> archive) it was working well (i.e. no compilation error).
> >>>>>>>>>>>
> >>>>>>>>>>> Cheers,
> >>>>>>>>>>> Lior.
> >>>>>>>>>>>
> >>>>>>>>>>> -----Original Message-----
> >>>>>>>>>>> From: Ahmad Fatoum <ahmad@a3f.at>
> >>>>>>>>>>> Sent: Sunday, May 28, 2023 6:38 PM
> >>>>>>>>>>> To: barebox@lists.infradead.org
> >>>>>>>>>>> Cc: Lior Weintraub <liorw@pliops.com>
> >>>>>>>>>>> Subject: [PATCH v2] Porting barebox to a new SoC
> >>>>>>>>>>>
> >>>>>>>>>>> CAUTION: External Sender
> >>>>>>>>>>>
> >>>>>>>>>>> From: Lior Weintraub <liorw@pliops.com>
> >>>>>>>>>>>
> >>>>>>>>>>> Hi,
> >>>>>>>>>>>
> >>>>>>>>>>> I tried to follow the porting guide on https://ddec1-0-en-
> >>>>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>
> >>
> ctp.trendmicro.com:443/wis/clicktime/v1/query?url=https%3a%2f%2fwww.
> >>>>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>
> >>
> barebox.org%2fdoc%2flatest%2fdevel%2fporting.html%23&umid=60097eda
> >>>>>>>>>> -f136-45a1-9c8e-
> >>>>>>>>>>
> >>>> cf6a76e45cf8&auth=860a7ebb9feba264acc79b6e38eb59582349362c-
> >>>>>>>>>> 480ae23736add41c88ab8d30c090a75517ca7f9e but couldn't
> >> follow
> >>>>>> the
> >>>>>>>>>> instructions.
> >>>>>>>>>>> I would like to port barebox to a new SoC (which is not a
> derivative
> >> of
> >>>>>> any
> >>>>>>>>>> known SoC).
> >>>>>>>>>>> It has the following:
> >>>>>>>>>>> * Single Cortex A53
> >>>>>>>>>>> * SRAM (4MB) located on address 0xC000000000
> >>>>>>>>>>>
> >>>>>>>>>>> The below patch shows my initial test to try and have a starting
> >> point.
> >>>>>>>>>>> I am setting env variables:
> >>>>>>>>>>> export ARCH=arm64
> >>>>>>>>>>> export CROSS_COMPILE=/home/pliops/workspace/ARM/arm-
> >> gnu-
> >>>>>>>>>> toolchain/bin/aarch64-none-elf-
> >>>>>>>>>>>
> >>>>>>>>>>> Then I build with:
> >>>>>>>>>>> make spider_defconfig && make
> >>>>>>>>>>>
> >>>>>>>>>>> This gives an error:
> >>>>>>>>>>> aarch64-none-elf-gcc: error: unrecognized argument in option '-
> >>>>>>>> mabi=apcs-
> >>>>>>>>>> gnu'
> >>>>>>>>>>> aarch64-none-elf-gcc: note: valid arguments to '-mabi=' are:
> ilp32
> >>>> lp64
> >>>>>>>>>>> aarch64-none-elf-gcc: error: unrecognized command-line option
> '-
> >>>>>> msoft-
> >>>>>>>>>> float'
> >>>>>>>>>>> aarch64-none-elf-gcc: error: unrecognized command-line option
> '-
> >>>> mno-
> >>>>>>>>>> unaligned-access'
> >>>>>>>>>>> /home/pliops/workspace/simplest-linux-
> >>>>>>>>>> demo/barebox/scripts/Makefile.build:140: recipe for target
> >>>>>>>>>> 'scripts/mod/empty.o' failed
> >>>>>>>>>>> make[2]: *** [scripts/mod/empty.o] Error 1
> >>>>>>>>>>>
> >>>>>>>>>>> Not sure why the compiler flags get -mabi=apcs-gnu when I
> >> explicitly
> >>>> set
> >>>>>>>>>> CONFIG_CPU_V8 and the arch/arm/Makefile has:
> >>>>>>>>>>> ifeq ($(CONFIG_CPU_V8), y)
> >>>>>>>>>>> CFLAGS_ABI :=-mabi=lp64
> >>>>>>>>>>>
> >>>>>>>>>>> The changes I did:
> >>>>>>>>>>> >From 848b5f9b18bb1bb96d197cbc1b368ee0a729d581 Mon
> >> Sep
> >>>> 17
> >>>>>>>>>> 00:00:00 2001
> >>>>>>>>>>> ---
> >>>>>>>>>>> arch/arm/Kconfig | 13 ++++++++
> >>>>>>>>>>> arch/arm/Makefile | 1 +
> >>>>>>>>>>> arch/arm/boards/Makefile | 1 +
> >>>>>>>>>>> arch/arm/boards/spider-evk/Makefile | 4 +++
> >>>>>>>>>>> arch/arm/boards/spider-evk/board.c | 26 +++++++++++++++
> >>>>>>>>>>> arch/arm/boards/spider-evk/lowlevel.c | 30
> +++++++++++++++++
> >>>>>>>>>>> arch/arm/configs/spider_defconfig | 8 +++++
> >>>>>>>>>>> arch/arm/dts/Makefile | 1 +
> >>>>>>>>>>> arch/arm/dts/spider-mk1-evk.dts | 10 ++++++
> >>>>>>>>>>> arch/arm/dts/spider-mk1.dtsi | 46
> >>>>>> +++++++++++++++++++++++++++
> >>>>>>>>>>> arch/arm/mach-spider/Kconfig | 16 ++++++++++
> >>>>>>>>>>> arch/arm/mach-spider/Makefile | 1 +
> >>>>>>>>>>> arch/arm/mach-spider/lowlevel.c | 14 ++++++++
> >>>>>>>>>>> images/Makefile | 1 +
> >>>>>>>>>>> images/Makefile.spider | 5 +++
> >>>>>>>>>>> include/mach/spider/lowlevel.h | 7 ++++
> >>>>>>>>>>> 16 files changed, 184 insertions(+)
> >>>>>>>>>>> create mode 100644 arch/arm/boards/spider-evk/Makefile
> >>>>>>>>>>> create mode 100644 arch/arm/boards/spider-evk/board.c
> >>>>>>>>>>> create mode 100644 arch/arm/boards/spider-evk/lowlevel.c
> >>>>>>>>>>> create mode 100644 arch/arm/configs/spider_defconfig create
> >>>> mode
> >>>>>>>>>> 100644 arch/arm/dts/spider-mk1-evk.dts create mode 100644
> >>>>>>>>>> arch/arm/dts/spider-mk1.dtsi create mode 100644
> >> arch/arm/mach-
> >>>>>>>>>> spider/Kconfig create mode 100644 arch/arm/mach-
> >> spider/Makefile
> >>>>>>>> create
> >>>>>>>>>> mode 100644 arch/arm/mach-spider/lowlevel.c create mode
> >> 100644
> >>>>>>>>>> images/Makefile.spider create mode 100644
> >>>>>>>> include/mach/spider/lowlevel.h
> >>>>>>>>>>>
> >>>>>>>>>>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index
> >>>>>>>>>> e76ee0f6dfe1..e5dcf128447e 100644
> >>>>>>>>>>> --- a/arch/arm/Kconfig
> >>>>>>>>>>> +++ b/arch/arm/Kconfig
> >>>>>>>>>>> @@ -255,6 +255,18 @@ config ARCH_ROCKCHIP
> >>>>>>>>>>> select HAS_DEBUG_LL
> >>>>>>>>>>> imply GPIO_ROCKCHIP
> >>>>>>>>>>>
> >>>>>>>>>>> +config ARCH_SPIDER
> >>>>>>>>>>> + bool "Pliops Spider based"
> >>>>>>>>>>> + depends on 64BIT
> >>>>>>>>>>> + depends on ARCH_MULTIARCH
> >>>>>>>>>>> + select GPIOLIB
> >>>>>>>>>>> + select HAVE_PBL_MULTI_IMAGES
> >>>>>>>>>>> + select COMMON_CLK
> >>>>>>>>>>> + select CLKDEV_LOOKUP
> >>>>>>>>>>> + select COMMON_CLK_OF_PROVIDER
> >>>>>>>>>>> + select OFTREE
> >>>>>>>>>>> + select OFDEVICE
> >>>>>>>>>>> +
> >>>>>>>>>>> config ARCH_STM32MP
> >>>>>>>>>>> bool "STMicroelectronics STM32MP"
> >>>>>>>>>>> depends on 32BIT
> >>>>>>>>>>> @@ -331,6 +343,7 @@ source "arch/arm/mach-omap/Kconfig"
> >>>>>>>>>>> source "arch/arm/mach-pxa/Kconfig"
> >>>>>>>>>>> source "arch/arm/mach-rockchip/Kconfig"
> >>>>>>>>>>> source "arch/arm/mach-socfpga/Kconfig"
> >>>>>>>>>>> +source "arch/arm/mach-spider/Kconfig"
> >>>>>>>>>>> source "arch/arm/mach-stm32mp/Kconfig"
> >>>>>>>>>>> source "arch/arm/mach-versatile/Kconfig"
> >>>>>>>>>>> source "arch/arm/mach-vexpress/Kconfig"
> >>>>>>>>>>> diff --git a/arch/arm/Makefile b/arch/arm/Makefile index
> >>>>>>>>>> 35ebc70f44e2..4c63dfee48f4 100644
> >>>>>>>>>>> --- a/arch/arm/Makefile
> >>>>>>>>>>> +++ b/arch/arm/Makefile
> >>>>>>>>>>> @@ -101,6 +101,7 @@ machine-$(CONFIG_ARCH_MXS) +=
> >> mxs
> >>>>>>>>>>> machine-$(CONFIG_ARCH_MVEBU) += mvebu
> >>>>>>>>>>> machine-$(CONFIG_ARCH_NOMADIK) += nomadik
> >>>>>>>>>>> machine-$(CONFIG_ARCH_OMAP) += omap
> >>>>>>>>>>> +machine-$(CONFIG_ARCH_SPIDER) += spider
> >>>>>>>>>>> machine-$(CONFIG_ARCH_PXA) += pxa
> >>>>>>>>>>> machine-$(CONFIG_ARCH_ROCKCHIP) += rockchip
> >>>>>>>>>>> machine-$(CONFIG_ARCH_SAMSUNG) += samsung
> >>>>>>>>>>> diff --git a/arch/arm/boards/Makefile
> >> b/arch/arm/boards/Makefile
> >>>>>> index
> >>>>>>>>>> 2877debad535..6fe0a90c81ea 100644
> >>>>>>>>>>> --- a/arch/arm/boards/Makefile
> >>>>>>>>>>> +++ b/arch/arm/boards/Makefile
> >>>>>>>>>>> @@ -135,6 +135,7 @@ obj-
> >>>>>>>>>> $(CONFIG_MACH_SOCFPGA_TERASIC_DE10_NANO) +=
> terasic-
> >>>>>> de10-
> >>>>>>>>>> nano/
> >>>>>>>>>>> obj-$(CONFIG_MACH_SOCFPGA_TERASIC_SOCKIT) +=
> terasic-
> >>>>>> sockit/
> >>>>>>>>>>> obj-$(CONFIG_MACH_SOLIDRUN_CUBOX) += solidrun-
> >> cubox/
> >>>>>>>>>>> obj-$(CONFIG_MACH_SOLIDRUN_MICROSOM) +=
> solidrun-
> >>>>>>>>>> microsom/
> >>>>>>>>>>> +obj-$(CONFIG_MACH_SPIDER_MK1_EVK) += spider-evk/
> >>>>>>>>>>> obj-$(CONFIG_MACH_STM32MP15XX_DKX) +=
> >>>> stm32mp15xx-
> >>>>>>>> dkx/
> >>>>>>>>>>> obj-$(CONFIG_MACH_STM32MP13XX_DK) +=
> >> stm32mp13xx-
> >>>>>> dk/
> >>>>>>>>>>> obj-$(CONFIG_MACH_LXA_MC1) += lxa-mc1/
> >>>>>>>>>>> diff --git a/arch/arm/boards/spider-evk/Makefile
> >>>>>>>>>> b/arch/arm/boards/spider-evk/Makefile
> >>>>>>>>>>> new file mode 100644
> >>>>>>>>>>> index 000000000000..da63d2625f7a
> >>>>>>>>>>> --- /dev/null
> >>>>>>>>>>> +++ b/arch/arm/boards/spider-evk/Makefile
> >>>>>>>>>>> @@ -0,0 +1,4 @@
> >>>>>>>>>>> +# SPDX-License-Identifier: GPL-2.0-only
> >>>>>>>>>>> +
> >>>>>>>>>>> +obj-y += board.o
> >>>>>>>>>>> +lwl-y += lowlevel.o
> >>>>>>>>>>> diff --git a/arch/arm/boards/spider-evk/board.c
> >>>>>>>> b/arch/arm/boards/spider-
> >>>>>>>>>> evk/board.c
> >>>>>>>>>>> new file mode 100644
> >>>>>>>>>>> index 000000000000..3920e83b457d
> >>>>>>>>>>> --- /dev/null
> >>>>>>>>>>> +++ b/arch/arm/boards/spider-evk/board.c
> >>>>>>>>>>> @@ -0,0 +1,26 @@
> >>>>>>>>>>> +#include <bbu.h>
> >>>>>>>>>>> +#include <boot.h>
> >>>>>>>>>>> +#include <bootm.h>
> >>>>>>>>>>> +#include <common.h>
> >>>>>>>>>>> +#include <deep-probe.h>
> >>>>>>>>>>> +#include <environment.h>
> >>>>>>>>>>> +#include <fcntl.h>
> >>>>>>>>>>> +#include <globalvar.h>
> >>>>>>>>>>> +
> >>>>>>>>>>> +static int spider_board_probe(struct device *dev) {
> >>>>>>>>>>> + /* Do some board-specific setup */
> >>>>>>>>>>> + return 0;
> >>>>>>>>>>> +}
> >>>>>>>>>>> +
> >>>>>>>>>>> +static const struct of_device_id spider_board_of_match[] = {
> >>>>>>>>>>> + { .compatible = "pliops,spider-mk1-evk" },
> >>>>>>>>>>> + { /* sentinel */ },
> >>>>>>>>>>> +};
> >>>>>>>>>>> +
> >>>>>>>>>>> +static struct driver spider_board_driver = {
> >>>>>>>>>>> + .name = "board-spider",
> >>>>>>>>>>> + .probe = spider_board_probe,
> >>>>>>>>>>> + .of_compatible = spider_board_of_match, };
> >>>>>>>>>>> +device_platform_driver(spider_board_driver);
> >>>>>>>>>>> diff --git a/arch/arm/boards/spider-evk/lowlevel.c
> >>>>>>>>>> b/arch/arm/boards/spider-evk/lowlevel.c
> >>>>>>>>>>> new file mode 100644
> >>>>>>>>>>> index 000000000000..e36fcde4208e
> >>>>>>>>>>> --- /dev/null
> >>>>>>>>>>> +++ b/arch/arm/boards/spider-evk/lowlevel.c
> >>>>>>>>>>> @@ -0,0 +1,30 @@
> >>>>>>>>>>> +#include <common.h>
> >>>>>>>>>>> +#include <asm/barebox-arm.h>
> >>>>>>>>>>> +#include <mach/spider/lowlevel.h>
> >>>>>>>>>>> +
> >>>>>>>>>>> +#define BASE_ADDR (0xD000307000)
> >>>>>>>>>>> +#define GPRAM_ADDR (0xC000000000)
> >>>>>>>>>>> +#define MY_STACK_TOP (0xC000000000 + SZ_2M) // Set the
> >> stack
> >>>>>>>> 2MB
> >>>>>>>>>> from GPRAM start (excatly in the middle)
> >>>>>>>>>>> +static inline void spider_serial_putc(void *base, int c) {
> >>>>>>>>>>> +// if (!(readl(base + UCR1) & UCR1_UARTEN))
> >>>>>>>>>>> +// return;
> >>>>>>>>>>> +//
> >>>>>>>>>>> +// while (!(readl(base + USR2) & USR2_TXDC));
> >>>>>>>>>>> +//
> >>>>>>>>>>> +// writel(c, base + URTX0);
> >>>>>>>>>>> +}
> >>>>>>>>>>> +
> >>>>>>>>>>> +ENTRY_FUNCTION_WITHSTACK(start_spider_mk1_evk,
> >>>>>> MY_STACK_TOP,
> >>>>>>>>>> r0, r1,
> >>>>>>>>>>> +r2) {
> >>>>>>>>>>> + extern char __dtb_spider_mk1_evk_start[];
> >>>>>>>>>>> +
> >>>>>>>>>>> + spider_lowlevel_init();
> >>>>>>>>>>> +
> >>>>>>>>>>> + relocate_to_current_adr();
> >>>>>>>>>>> + setup_c();
> >>>>>>>>>>> +
> >>>>>>>>>>> + pbl_set_putc(spider_serial_putc, (void *)BASE_ADDR);
> >>>>>>>>>>> +
> >>>>>>>>>>> + barebox_arm_entry(GPRAM_ADDR, SZ_2M,
> >>>>>>>>>>> +__dtb_spider_mk1_evk_start); }
> >>>>>>>>>>> diff --git a/arch/arm/configs/spider_defconfig
> >>>>>>>>>> b/arch/arm/configs/spider_defconfig
> >>>>>>>>>>> new file mode 100644
> >>>>>>>>>>> index 000000000000..c91bb889d97f
> >>>>>>>>>>> --- /dev/null
> >>>>>>>>>>> +++ b/arch/arm/configs/spider_defconfig
> >>>>>>>>>>> @@ -0,0 +1,8 @@
> >>>>>>>>>>> +CONFIG_ARCH_SPIDER=y
> >>>>>>>>>>> +CONFIG_MACH_SPIDER_MK1_EVK=y
> >>>>>>>>>>> +CONFIG_BOARD_ARM_GENERIC_DT=y
> >>>>>>>>>>> +CONFIG_MALLOC_TLSF=y
> >>>>>>>>>>> +CONFIG_KALLSYMS=y
> >>>>>>>>>>> +CONFIG_RELOCATABLE=y
> >>>>>>>>>>> +CONFIG_CONSOLE_ALLOW_COLOR=y
> >>>>>>>>>>> +CONFIG_PBL_CONSOLE=y
> >>>>>>>>>>> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index
> >>>>>>>>>> 98f4c4e0194b..94b304d4878f 100644
> >>>>>>>>>>> --- a/arch/arm/dts/Makefile
> >>>>>>>>>>> +++ b/arch/arm/dts/Makefile
> >>>>>>>>>>> @@ -134,6 +134,7 @@ lwl-
> $(CONFIG_MACH_SOLIDRUN_CUBOX)
> >>>> +=
> >>>>>>>> dove-
> >>>>>>>>>> cubox-bb.dtb.o
> >>>>>>>>>>> lwl-$(CONFIG_MACH_SOLIDRUN_MICROSOM) += imx6dl-
> >>>>>>>>>> hummingboard.dtb.o imx6q-hummingboard.dtb.o \
> >>>>>>>>>>> imx6dl-hummingboard2.dtb.o imx6q-
> >>>>>>>>>> hummingboard2.dtb.o \
> >>>>>>>>>>> imx6q-h100.dtb.o
> >>>>>>>>>>> +lwl-$(CONFIG_MACH_SPIDER_MK1_EVK) += spider-mk1-
> >> evk.dtb.o
> >>>>>>>>>>> lwl-$(CONFIG_MACH_SKOV_IMX6) += imx6s-skov-imx6.dtb.o
> >>>> imx6dl-
> >>>>>>>> skov-
> >>>>>>>>>> imx6.dtb.o imx6q-skov-imx6.dtb.o
> >>>>>>>>>>> lwl-$(CONFIG_MACH_SKOV_ARM9CPU) += at91-skov-
> >>>> arm9cpu.dtb.o
> >>>>>>>>>>> lwl-$(CONFIG_MACH_SEEED_ODYSSEY) += stm32mp157c-
> >>>>>> odyssey.dtb.o
> >>>>>>>>>> diff --git a/arch/arm/dts/spider-mk1-evk.dts
> >> b/arch/arm/dts/spider-
> >>>>>> mk1-
> >>>>>>>>>> evk.dts new file mode 100644 index
> >> 000000000000..b8081cb85bf8
> >>>>>>>>>>> --- /dev/null
> >>>>>>>>>>> +++ b/arch/arm/dts/spider-mk1-evk.dts
> >>>>>>>>>>> @@ -0,0 +1,10 @@
> >>>>>>>>>>> +// SPDX-License-Identifier: GPL-2.0 OR X11
> >>>>>>>>>>> +
> >>>>>>>>>>> +/dts-v1/;
> >>>>>>>>>>> +
> >>>>>>>>>>> +#include "spider-mk1.dtsi"
> >>>>>>>>>>> +
> >>>>>>>>>>> +/ {
> >>>>>>>>>>> + model = "Pliops Spider MK-I EVK";
> >>>>>>>>>>> + compatible = "pliops,spider-mk1-evk"; };
> >>>>>>>>>>> diff --git a/arch/arm/dts/spider-mk1.dtsi
> b/arch/arm/dts/spider-
> >>>>>> mk1.dtsi
> >>>>>>>>>> new file mode 100644 index 000000000000..d4613848169d
> >>>>>>>>>>> --- /dev/null
> >>>>>>>>>>> +++ b/arch/arm/dts/spider-mk1.dtsi
> >>>>>>>>>>> @@ -0,0 +1,46 @@
> >>>>>>>>>>> +// SPDX-License-Identifier: GPL-2.0 OR X11
> >>>>>>>>>>> +
> >>>>>>>>>>> +/ {
> >>>>>>>>>>> + #address-cells = <2>;
> >>>>>>>>>>> + #size-cells = <2>;
> >>>>>>>>>>> +
> >>>>>>>>>>> + chosen {
> >>>>>>>>>>> + stdout-path = &uart0;
> >>>>>>>>>>> + };
> >>>>>>>>>>> +
> >>>>>>>>>>> + aliases {
> >>>>>>>>>>> + serial0 = &uart0;
> >>>>>>>>>>> + };
> >>>>>>>>>>> +
> >>>>>>>>>>> + cpus {
> >>>>>>>>>>> + #address-cells = <1>;
> >>>>>>>>>>> + #size-cells = <0>;
> >>>>>>>>>>> +
> >>>>>>>>>>> + cpu0: cpu@0 {
> >>>>>>>>>>> + device_type = "cpu";
> >>>>>>>>>>> + compatible = "arm,cortex-a53";
> >>>>>>>>>>> + reg = <0x0>;
> >>>>>>>>>>> + };
> >>>>>>>>>>> + };
> >>>>>>>>>>> +
> >>>>>>>>>>> + memory@1000000 {
> >>>>>>>>>>> + reg = <0x0 0x1000000 0x0 0x400000>; /* 128M */
> >>>>>>>>>>> + device_type = "memory";
> >>>>>>>>>>> + };
> >>>>>>>>>>> +
> >>>>>>>>>>> + soc {
> >>>>>>>>>>> + #address-cells = <2>;
> >>>>>>>>>>> + #size-cells = <2>;
> >>>>>>>>>>> + ranges;
> >>>>>>>>>>> +
> >>>>>>>>>>> + sram@c000000000 {
> >>>>>>>>>>> + compatible = "mmio-sram";
> >>>>>>>>>>> + reg = <0xc0 0x0 0x0 0x400000>;
> >>>>>>>>>>> + };
> >>>>>>>>>>> +
> >>>>>>>>>>> + uart0: serial@d000307000 {
> >>>>>>>>>>> + compatible = "pliops,spider-uart";
> >>>>>>>>>>> + reg = <0xd0 0x307000 0 0x1000>;
> >>>>>>>>>>> + };
> >>>>>>>>>>> + };
> >>>>>>>>>>> +};
> >>>>>>>>>>> diff --git a/arch/arm/mach-spider/Kconfig b/arch/arm/mach-
> >>>>>>>> spider/Kconfig
> >>>>>>>>>> new file mode 100644 index 000000000000..6d2f888a5fd8
> >>>>>>>>>>> --- /dev/null
> >>>>>>>>>>> +++ b/arch/arm/mach-spider/Kconfig
> >>>>>>>>>>> @@ -0,0 +1,16 @@
> >>>>>>>>>>> +# SPDX-License-Identifier: GPL-2.0-only
> >>>>>>>>>>> +
> >>>>>>>>>>> +if ARCH_SPIDER
> >>>>>>>>>>> +
> >>>>>>>>>>> +config ARCH_SPIDER_MK1
> >>>>>>>>>>> + bool
> >>>>>>>>>>> + select CPU_V8
> >>>>>>>>>>> + help
> >>>>>>>>>>> + The first Cortex-A53-based SoC of the spider family.
> >>>>>>>>>>> + This symbol is invisble and select by boards
> >>>>>>>>>>> +
> >>>>>>>>>>> +config MACH_SPIDER_MK1_EVK
> >>>>>>>>>>> + bool "Pliops Spider Reference Design Board"
> >>>>>>>>>>> + select ARCH_SPIDER_MK1
> >>>>>>>>>>> +
> >>>>>>>>>>> +endif
> >>>>>>>>>>> diff --git a/arch/arm/mach-spider/Makefile b/arch/arm/mach-
> >>>>>>>>>> spider/Makefile new file mode 100644 index
> >>>>>>>> 000000000000..b08c4a93ca27
> >>>>>>>>>>> --- /dev/null
> >>>>>>>>>>> +++ b/arch/arm/mach-spider/Makefile
> >>>>>>>>>>> @@ -0,0 +1 @@
> >>>>>>>>>>> +lwl-y += lowlevel.o
> >>>>>>>>>>> diff --git a/arch/arm/mach-spider/lowlevel.c b/arch/arm/mach-
> >>>>>>>>>> spider/lowlevel.c new file mode 100644 index
> >>>>>>>>>> 000000000000..5d62ef0f39e5
> >>>>>>>>>>> --- /dev/null
> >>>>>>>>>>> +++ b/arch/arm/mach-spider/lowlevel.c
> >>>>>>>>>>> @@ -0,0 +1,14 @@
> >>>>>>>>>>> +// SPDX-License-Identifier: GPL-2.0+
> >>>>>>>>>>> +
> >>>>>>>>>>> +#include <linux/types.h>
> >>>>>>>>>>> +#include <mach/spider/lowlevel.h>
> >>>>>>>>>>> +#include <asm/barebox-arm-head.h>
> >>>>>>>>>>> +
> >>>>>>>>>>> +void spider_lowlevel_init(void)
> >>>>>>>>>>> +{
> >>>>>>>>>>> + arm_cpu_lowlevel_init();
> >>>>>>>>>>> + /*
> >>>>>>>>>>> + * not yet relocated, only do writel/readl for stuff that's
> >>>>>>>>>>> + * critical to run early. No global variables allowed.
> >>>>>>>>>>> + */
> >>>>>>>>>>> +}
> >>>>>>>>>>> diff --git a/images/Makefile b/images/Makefile index
> >>>>>>>>>> c93f9e268978..97521e713228 100644
> >>>>>>>>>>> --- a/images/Makefile
> >>>>>>>>>>> +++ b/images/Makefile
> >>>>>>>>>>> @@ -150,6 +150,7 @@ include $(srctree)/images/Makefile.mxs
> >>>>>> include
> >>>>>>>>>> $(srctree)/images/Makefile.omap3 include
> >>>>>>>>>> $(srctree)/images/Makefile.rockchip
> >>>>>>>>>>> include $(srctree)/images/Makefile.socfpga
> >>>>>>>>>>> +include $(srctree)/images/Makefile.spider
> >>>>>>>>>>> include $(srctree)/images/Makefile.stm32mp
> >>>>>>>>>>> include $(srctree)/images/Makefile.tegra include
> >>>>>>>>>> $(srctree)/images/Makefile.versatile
> >>>>>>>>>>> diff --git a/images/Makefile.spider b/images/Makefile.spider
> new
> >> file
> >>>>>>>> mode
> >>>>>>>>>> 100644 index 000000000000..c32f2762df04
> >>>>>>>>>>> --- /dev/null
> >>>>>>>>>>> +++ b/images/Makefile.spider
> >>>>>>>>>>> @@ -0,0 +1,5 @@
> >>>>>>>>>>> +# SPDX-License-Identifier: GPL-2.0-only
> >>>>>>>>>>> +
> >>>>>>>>>>> +pblb-$(CONFIG_MACH_SPIDER_MK1_EVK) +=
> >>>> start_spider_mk1_evk
> >>>>>>>>>>> +FILE_barebox-spider-mk1-evk.img =
> start_spider_mk1_evk.pblb
> >>>>>>>>>>> +image-$(CONFIG_MACH_SPIDER_MK1_EVK) += barebox-
> spider-
> >>>> mk1-
> >>>>>>>>>> evk.img
> >>>>>>>>>>> diff --git a/include/mach/spider/lowlevel.h
> >>>>>>>>>> b/include/mach/spider/lowlevel.h new file mode 100644 index
> >>>>>>>>>> 000000000000..6e0ce1c77f7e
> >>>>>>>>>>> --- /dev/null
> >>>>>>>>>>> +++ b/include/mach/spider/lowlevel.h
> >>>>>>>>>>> @@ -0,0 +1,7 @@
> >>>>>>>>>>> +/* SPDX-License-Identifier: GPL-2.0+ */ #ifndef
> >> __MACH_SPIDER_H_
> >>>>>>>>>>> +#define __MACH_SPIDER_H_
> >>>>>>>>>>> +
> >>>>>>>>>>> +void spider_lowlevel_init(void);
> >>>>>>>>>>> +
> >>>>>>>>>>> +#endif
> >>>>>>>>>>> --
> >>>>>>>>>>> 2.38.4
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> --
> >>>>>>>>>> Pengutronix e.K. | |
> >>>>>>>>>> Steuerwalder Str. 21 | http://www.pengutronix.de/ |
> >>>>>>>>>> 31137 Hildesheim, Germany | Phone: +49-5121-
> 206917-0
> >>>> |
> >>>>>>>>>> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-
> 206917-
> >>>> 5555
> >>>>>> |
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> --
> >>>>>>>> Pengutronix e.K. | |
> >>>>>>>> Steuerwalder Str. 21 | http://www.pengutronix.de/ |
> >>>>>>>> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0
> >> |
> >>>>>>>> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-
> >> 5555
> >>>> |
> >>>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> Pengutronix e.K. | |
> >>>>>> Steuerwalder Str. 21 | http://www.pengutronix.de/ |
> >>>>>> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0
> |
> >>>>>> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-
> 5555
> >> |
> >>>>>
> >>>>
> >>>> --
> >>>> Pengutronix e.K. | |
> >>>> Steuerwalder Str. 21 | http://www.pengutronix.de/ |
> >>>> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
> >>>> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555
> |
> >>>
> >>
> >> --
> >> Pengutronix e.K. | |
> >> Steuerwalder Str. 21 | http://www.pengutronix.de/ |
> >> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
> >> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
> >
>
> --
> Pengutronix e.K. | |
> Steuerwalder Str. 21 | http://www.pengutronix.de/ |
> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [PATCH v2] Porting barebox to a new SoC
2023-06-06 12:54 ` Lior Weintraub
@ 2023-06-06 14:34 ` Ahmad Fatoum
2023-06-12 9:27 ` Lior Weintraub
0 siblings, 1 reply; 40+ messages in thread
From: Ahmad Fatoum @ 2023-06-06 14:34 UTC (permalink / raw)
To: Lior Weintraub, Ahmad Fatoum, barebox
Hello Lior,
On 06.06.23 14:54, Lior Weintraub wrote:
> Hello Ahmad,
>
> I managed to build a bl31.bin file from TF-A.
> This is just a preliminary implementation (basically all functions I had to implement are empty) so I'm hoping it will allow running a bare minimum initial Linux kernel.
As long as the TF-A implements the informational parts (e.g. PSCI_VERSION),
I think that should be ok.
> I tried to follow how imx8mq-bl31.bin was added into barebox and I think I got it right.
> I have several indications that the BL31 is behaving as expected.
Nice. A simple sanity check would be to implement SYSTEM_RESET and call it from
barebox using the PSCI client reset driver.
> The initial implementation (without BL31) was running PBL from SRAM (address 0xC0_0000_0000),
> decompressed barebox into DRAM (@ 0x07E0_0000) and jumped to barebox.
> From ARM registers inspection we can see that we are @ EL3
>
> Now with the inclusion of BL31, it starts @ SRAM (as before) but then test that we are in EL3 and if so,
> copy full image (PBL+Barebox) into DRAM address 0x0800_0000,
Sounds good.
> copy BL31.bin into DRAM address 0x1000_0000 and jumps there.
You can do that, but keep in mind that BL31 will always be invoked at EL3,
so you'll want to use hardware mechanisms to ensure that you can't
just overwrite it from lower exception levels.
If you have a DDR firewall, you could place it into DDR, but I'd suggest
just keeping it in SRAM. That way you only need to configure your address
space controller so SRAM is secure-world only. This also simplifies later
logic, because you no longer need to mark the DDR region where TF-A is as
reserved. (If you don't do that, you risk Linux accessing it, which can lead
to crashes).
> The execution of BL31 does its thing and then sets execution level to EL2 and jumps to DRAM address 0x0800_0000 (hard coded address we used on BL31 TF-A compilation).
That's fine. I'd just jump to address 0 though if that's the start of your DRAM.
> We now see the PBL starts running again (now from DRAM), skips the BL31 loading (because it sees that we are not in EL3) and continue as before.
Sounds good.
> PBL decompressed barebox into DRAM address 0x07E0_0000 and jump to barebox.
Sounds even better.
> From ARM registers inspection we can see that we are @ EL2
Nice. :-)
> Few questions:
> 1. Any comments or thoughts about the above flow?
See above, but sounds good overall.
> 2. Are we ready now to try loading kernel and rootfs? If so how?
Did you already flesh out your DT? It needs to contain GIC, timer
and arm,psci-1.0 at the very least. Then you need a boot medium.
If it's something like eMMC, you can configure QEMU to provide
a memory-mapped SD/MMC controller and enable the driver for that
in barebox. If it's something more esoteric, you can just use
virtio block or cfi-flash, both of which are supported in barebox
and QEMU and are in used with the default QEMU virt machine.
Assuming you have a file system in a virtio block device and you
have enabled it on QEMU side with virtio-mmio transport and
barebox has the relevant virtio-mmio node in its device tree,
you can then boot with:
global.linux.bootargs.earlycon=earlycon
bootm -o /mnt/virtioblk0.0/boot/mydevicetree.dtb \
-r /mnt/virtioblk0.0/boot/myinitrd.img
/mnt/virtioblk0.0/boot/mykernel.gz
(Don't forget to add stdout-path = &uart to your DT, so kernel can
find the console to use with earlycon)
If you aren't familiar with virtioblk or cfi-flash try building barebox
for multi_v8_defconfig and then start it in QEMU to play around with it:
qemu-system-aarch64 -M virt,highmem=off -cpu cortex-a57 -m 1024M -kernel build/images/barebox-dt-2nd.img \
-serial mon:stdio -trace file=/dev/null -nographic
> 3. Is it OK (or even recommended) to change BL31 so that it will enter EL1 instead of EL2 (as we do not plan to use virtualization).
Always enter kernel at EL2. Let Linux worry about going from EL2 to EL1
> Thanks again for your kind support,
> Cheers,
> Lior.
Cheers,
Ahmad
>
>
>> -----Original Message-----
>> From: Ahmad Fatoum <a.fatoum@pengutronix.de>
>> Sent: Thursday, June 1, 2023 3:36 PM
>> To: Lior Weintraub <liorw@pliops.com>; Ahmad Fatoum <ahmad@a3f.at>;
>> barebox@lists.infradead.org
>> Subject: Re: [PATCH v2] Porting barebox to a new SoC
>>
>> CAUTION: External Sender
>>
>> Hello Lior,
>>
>> On 01.06.23 13:45, Lior Weintraub wrote:
>>> Hello Ahmad,
>>>
>>> Very interesting stuff.
>>>
>>> We actually did started TF-A integration few months ago and tested it on the
>> QEMU running ARM virt machine.
>>> The TF-A compilation didn't include BL31 image (probably this explains the
>> "ERROR: BL2: Failed to load image id 3").
>>
>> I wouldn't recommend using TF-A as BL2. I am quite content with how
>> it's done on NXP's i.MX SoCs, which is the flow I described at the
>> end of my last mail. Instead of loading a FIP, TF-A would just
>> return to DRAM (or maintain LR on TF-A entry and return to it).
>>
>>> For this code to run we used the following QEMU command:
>>>
>>> qemu-system-aarch64 -nographic -machine virt,secure=on -cpu cortex-
>> a53,rvbar=0x0000000000 \
>>> -smp 1 -m 1024 -bios bl1.bin -d unimp -semihosting-config
>> enable=on,target=native \
>>> -monitor telnet:localhost:1235,server,nowait -gdb tcp::1236
>>>
>>> Output:
>>> NOTICE: bl1_early_platform_set
>>> NOTICE: Booting Trusted Firmware
>>> NOTICE: BL1: v2.7(debug):831de6588
>>> NOTICE: BL1: Built : 12:40:08, May 28 2023
>>> INFO: BL1: RAM 0xe0ee000 - 0xe0f6000
>>> INFO: BL1: cortex_a53: CPU workaround for 835769 was applied
>>> INFO: BL1: cortex_a53: CPU workaround for 843419 was applied
>>> INFO: BL1: cortex_a53: CPU workaround for 855873 was applied
>>> INFO: BL1: cortex_a53: CPU workaround for 1530924 was applied
>>> INFO: BL1: Loading BL2
>>> WARNING: Firmware Image Package header check failed.
>>> INFO: Loading image id=1 at address 0xe07b000
>>> INFO: Image id=1 loaded: 0xe07b000 - 0xe081201
>>> NOTICE: BL1: Booting BL2
>>> INFO: Entry point address = 0xe07b000
>>> INFO: SPSR = 0x3c5
>>> NOTICE: BL2: v2.7(debug):831de6588
>>> NOTICE: BL2: Built : 12:40:08, May 28 2023
>>> INFO: BL2: Doing platform setup
>>> INFO: BL2: Loading image id 3
>>> WARNING: Firmware Image Package header check failed.
>>> WARNING: Failed to obtain reference to image id=3 (-2)
>>> ERROR: BL2: Failed to load image id 3 (-2)
>>>
>>> When we tried to modify the TF-A code to use our SoC (e.g. change the start
>> address to 0xC0_0400_0000 and use UART on 0xD0_0030_7000) it crashed
>> with seg. Fault.
>>
>> Try building your BL31 as position-independent executable. The code doing
>> fixed text area may be hardcoded to 32-bit. See here for an example
>> of turning on PIE:
>>
>> https://ddec1-0-en-
>> ctp.trendmicro.com:443/wis/clicktime/v1/query?url=https%3a%2f%2freview
>> .trustedfirmware.org%2fc%2fTF%2dA%2ftrusted%2dfirmware%2da%2f%2b
>> %2f16370&umid=0b12ecfc-4ee1-4f0b-90e0-
>> 54ceaf590ca1&auth=860a7ebb9feba264acc79b6e38eb59582349362c-
>> c3cc24ae937d0a564120b663c7b93f60c48f01b5
>>
>>> We didn't continue with this development effort and decided we will write
>> our own BootROM as BL1
>>
>> Ye, I don't think TF-A is a good candidate for a BL1 (are there even
>> other users that user TF-A that way?).
>>
>>> and use that to load u-boot or barebox
>>
>> That's ok. You just need BL31 to provide you runtime services (or maintain
>> your
>> Linux SoC support patches for ever).
>>
>>> Now I understand we better go back and study how to port TF-A to our SoC.
>>
>> :)
>>
>> Cheers,
>> Ahmad
>>
>>>
>>> Cheers,
>>> Lior.
>>>
>>>
>>>> -----Original Message-----
>>>> From: Ahmad Fatoum <a.fatoum@pengutronix.de>
>>>> Sent: Thursday, June 1, 2023 12:29 PM
>>>> To: Lior Weintraub <liorw@pliops.com>; Ahmad Fatoum <ahmad@a3f.at>;
>>>> barebox@lists.infradead.org
>>>> Subject: Re: [PATCH v2] Porting barebox to a new SoC
>>>>
>>>> CAUTION: External Sender
>>>>
>>>> Hello Lior,
>>>>
>>>> On 01.06.23 10:54, Lior Weintraub wrote:
>>>>> Hi Ahmad,
>>>>>
>>>>> Thanks again for your great support and the patch.
>>>>> I've checked it and it works perfectly!
>>>>> The UART issue was solved after fixing the device tree per your
>>>> recommendations.
>>>>> Now I can write into barbox terminal :-)
>>>>
>>>> Nice!
>>>>
>>>>> When I type "cpuinfo" on the terminal I am getting:
>>>>> implementer: ARM
>>>>> architecture: v8
>>>>> core: Cortex-A53 r0p4
>>>>> exception level: 3
>>>>> cache: no cache
>>>>> Control register: P D Z DT IT U XP
>>>>
>>>> FYI, barebox next (or maybe master?) branch adds mmuinfo command to
>>>> arm64.
>>>> You can use that to check if a specific address is cached or not.
>>>>
>>>>> Notice that it say "no cache".
>>>>> I tried to add cache to cpu0 but it didn't help.
>>>>>
>>>>> .
>>>>> .
>>>>> d-cache-size = <0x8000>;
>>>>> d-cache-line-size = <64>;
>>>>> d-cache-sets = <128>; // 32KiB(size)/64(line-size)=512ways/4-way set
>>>>> i-cache-size = <0x8000>;
>>>>> i-cache-line-size = <64>;
>>>>> i-cache-sets = <256>; // 32KiB(size)/64(line-size)=512ways/2-way set
>>>>> next-level-cache = <&l2>;
>>>>> };
>>>>>
>>>>> l2: l2-cache0 {
>>>>> compatible = "cache";
>>>>> cache-unified;
>>>>> cache-size = <0x80000>;
>>>>> cache-line-size = <64>;
>>>>> cache-sets = <512>; // 512KiB(size)/64(line-size)=8192ways/16-way set
>>>>> cache-level = <2>;
>>>>> }
>>>>
>>>> barebox doesn't consume these nodes. What may be happening is that
>>>> cpuinfo
>>>> was written with the assumption that barebox executes at EL2 or EL1, so
>>>> executing it at EL3 may end up accessing the wrong MSRs. Feel free to send
>>>> a patch against arch/arm/cpu/cpuinfo.c, so it uses the correct register for
>>>> EL3. current_el() will tell you which EL you are at.
>>>>
>>>>> Regarding Linux kernel:
>>>>> This would be the next step but I assume that it would be a bit more
>>>> complicated.
>>>>
>>>> Linux ARM64 Maintainers mandate that platforms implement the PSCI
>>>> protocol.
>>>> In your case with single core that means providing reset and poweroff
>>>> handlers
>>>> that the kernel can invoke via secure monitor call.
>>>>
>>>> barebox can consume psci: CONFIG_ARM_PSCI_CLIENT,
>> CONFIG_CMD_SMC,
>>>> but what
>>>> you're missing is the provider side. barebox as PSCI provider is implemented
>>>> only for a single ARM32 SoC, the i.MX7. All supported ARM64 platforms
>> use
>>>> TF-A as BL31 with the exception of Layerscape (which uses PPA, an NXP
>> BL31
>>>> implementation).
>>>>
>>>> What does this mean for you?
>>>>
>>>> 1) Either add your SoC to TF-A
>>>> 2) Extend PSCI implementation in barebox for ARM64.
>>>>
>>>> While I think it would be cool to have barebox provide all of BL2, BL31 and
>>>> BL32, I think you are better advised to use TF-A, because that's what most
>>>> other ARM Silicon Vendors use. That means less effort for you and easier
>>>> maintenance as you benefit from fixes done for other SoCs using the same
>>>> IPs. barebox certainly benefits from being able to focus on being a
>> bootloader
>>>> and leaving the errata workarounds, GIC init stuff and runtime services
>>>> to TF-A.
>>>>
>>>> The boot flow would then be:
>>>>
>>>> - barebox PBL runs as BL2 in SRAM and sets up DRAM
>>>> - barebox PBL executes BL31 (TF-A) which was compiled into PBL
>>>> - TF-A installs secure monitor and returns control to DRAM in EL2
>>>> - barebox resumes execution in EL2 as BL33
>>>> - Linux is invoked in EL2 and can communicate with secure monitor.
>>>>
>>>> You may find this talk interesting:
>>>> https://fosdem.org/2023/schedule/event/uboot_psci/
>>>> Even if I disagree a bit with the takeaway.
>>>>
>>>>> I guess we will have to integrate the interrupt controlled (GIC-600) into
>>>> QEMU and into the device tree for it to work.
>>>>> Is that a valid assumption?
>>>>
>>>> I never had to add a new SoC to Linux, so I can't give any better
>>>> suggestions than Yes. Where you're going, you'll need interrupts.
>>>>
>>>> Godspeed and keep me posted :)
>>>> Ahmad
>>>>
>>>>>
>>>>> Thanks,
>>>>> Lior.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Ahmad Fatoum <a.fatoum@pengutronix.de>
>>>>>> Sent: Wednesday, May 31, 2023 8:55 PM
>>>>>> To: Lior Weintraub <liorw@pliops.com>; Ahmad Fatoum
>> <ahmad@a3f.at>;
>>>>>> barebox@lists.infradead.org
>>>>>> Subject: Re: [PATCH v2] Porting barebox to a new SoC
>>>>>>
>>>>>> CAUTION: External Sender
>>>>>>
>>>>>> Hi Lior,
>>>>>>
>>>>>> On 31.05.23 18:13, Lior Weintraub wrote:
>>>>>>> Hi Ahmad,
>>>>>>>
>>>>>>> Using end of SRAM as PBL stack is currently not working because we
>> need
>>>>>> 40bit address (0xC0_0020_0000).
>>>>>>> This needs a fix to ENTRY_FUNCTION_WITHSTACK macro.
>>>>>>
>>>>>> Ah, right. I just sent an (untested) patch. Would be cool if you could
>>>>>> try it out.
>>>>>>
>>>>>>> I tried just to change const u32 __stack_top = (stack_top); to const u64
>>>>>> __stack_top = (stack_top); but there were linking errors caused by:
>>>>>>> ASSERT(. - __pbl_board_stack_top <= 8, "Only One PBL per Image
>>>> allowed")
>>>>>>
>>>>>> The easy way would have been using a __attribute__((naked)) function,
>>>> but
>>>>>> those are only supported for arm32, not arm64. The alternative is thus
>>>>>> writing the entry point in assembly and to make board authors life easier
>>>>>> the linker script ensures that the stack setup entry point is invoked prior
>>>>>> to the board entry.
>>>>>>
>>>>>>> Regarding the arm timer:
>>>>>>> Adding the timer entry to DT solved the issue.
>>>>>>>
>>>>>>> Regarding the UART:
>>>>>>> Indeed CONFIG_SERIAL_AMBA_PL011 was set on spider_defconfig
>> (also
>>>>>> verified it generated the correct entry on .config).
>>>>>>> I also noticed that if I remove the putc_ll implementation there is no Tx
>> at
>>>> all
>>>>>> from Barebox.
>>>>>>
>>>>>> I've led you astray. Indeed:
>>>>>>
>>>>>>>>> of_platform_bus_create() - skipping /soc, no compatible prop
>>>>>>
>>>>>> points at the issue.
>>>>>>
>>>>>> Try adding into /soc
>>>>>>
>>>>>> compatible = "simple,bus";
>>>>>> ranges;
>>>>>> dma-ranges;
>>>>>>
>>>>>> This matches /soc with the simple bus driver which just instantiates
>> devices
>>>>>> for the
>>>>>> contained children. Those in turn should be matched by the drivers.
>>>>>>
>>>>>> The ranges stuff just tells that memory and SoC peripherals exist in the
>>>> same
>>>>>> address space.
>>>>>>
>>>>>> When it probes you may need to describe the clock in the DT. Eventually,
>>>> you
>>>>>> will
>>>>>> want to have a clock driver for your hardware (good news: barebox and
>>>> Linux
>>>>>> have
>>>>>> basically the same API, so you only need to write it once). But for now,
>> you
>>>>>> can
>>>>>> fake it using fixed-clock in the DT. Take a look at:
>>>>>>
>>>>>> snps,dw-apb-uart in arch/riscv/dts/jh7100.dtsi and compare with
>>>>>> dts/src/arm/imx28.dtsi
>>>>>> to see how to map that to PL011.
>>>>>>
>>>>>>> Could it be a hint?
>>>>>>
>>>>>> DEBUG_LL bridges the gap until a driver registers a console that's
>> enabled. If
>>>>>> this
>>>>>> never happens, you are left with a non-interactive shell.
>>>>>>
>>>>>> Cheers,
>>>>>> Ahmad
>>>>>>
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Lior.
>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Ahmad Fatoum <a.fatoum@pengutronix.de>
>>>>>>>> Sent: Wednesday, May 31, 2023 11:40 AM
>>>>>>>> To: Lior Weintraub <liorw@pliops.com>; Ahmad Fatoum
>>>> <ahmad@a3f.at>;
>>>>>>>> barebox@lists.infradead.org
>>>>>>>> Subject: Re: [PATCH v2] Porting barebox to a new SoC
>>>>>>>>
>>>>>>>> CAUTION: External Sender
>>>>>>>>
>>>>>>>> Hi Lior,
>>>>>>>>
>>>>>>>> On 31.05.23 10:05, Lior Weintraub wrote:
>>>>>>>>> Hi Ahmad,
>>>>>>>>>
>>>>>>>>> Thanks again for your prompt reply and accurate tips!
>>>>>>>>> Took the following changes:
>>>>>>>>> 1. Increasing the DRAM size to 128MB (let barebox start from 0).
>>>>>>>>> 2. Set PBL stack to offset 2MB from DRAM
>>>>>>>>
>>>>>>>> Just use end of SRAM, so you are completely independent of DRAM
>>>>>>>> until you call barebox_arm_entry.
>>>>>>>>
>>>>>>>>> 3. Fix the device tree "memory" entry to have 128MB.
>>>>>>>>
>>>>>>>> (y)
>>>>>>>>
>>>>>>>>> 4. Load barebox-spider-mk1-evk.img to SRAM and run from there.
>>>>>>>>>
>>>>>>>>> Now I can see the following logs:
>>>>>>>>> uncompress.c: memory at 0x00000000, size 0x08000000
>>>>>>>>> uncompress.c: uncompressing barebox binary at
>> 0x000000c0000021c0
>>>>>>>> (size 0x0001e3a4) to 0x07e00000 (uncompressed size: 0x000390d0)
>>>>>>>>> uncompress.c: jumping to uncompressed image at
>>>>>> 0x0000000007e00000
>>>>>>>>> start.c: memory at 0x00000000, size 0x08000000
>>>>>>>>> start.c: found DTB in boarddata, copying to 0x07dffcc0
>>>>>>>>> start.c: initializing malloc pool at 0x079ffcc0 (size 0x00400000)
>>>>>>>>> start.c: starting barebox...
>>>>>>>>> initcall-> command_slice_init+0x0/0x3c
>>>>>>>>> initcall-> globalvar_init+0x0/0x80
>>>>>>>>> register_device: global
>>>>>>>>> register_device: nv
>>>>>>>>> initcall-> platform_init+0x0/0x1c
>>>>>>>>> register_device: platform
>>>>>>>>> initcall-> amba_bus_init+0x0/0x1c
>>>>>>>>> register_device: amba
>>>>>>>>> initcall-> spi_bus_init+0x0/0x1c
>>>>>>>>> register_device: spi
>>>>>>>>> initcall-> gpio_desc_alloc+0x0/0x24
>>>>>>>>> initcall-> fs_bus_init+0x0/0x1c
>>>>>>>>> register_device: fs
>>>>>>>>> initcall-> aarch64_init_vectors+0x0/0x50
>>>>>>>>> initcall-> gpio_gate_clock_driver_register+0x0/0x1c
>>>>>>>>> register_driver: gpio-gate-clock
>>>>>>>>> initcall-> of_arm_init+0x0/0x5c
>>>>>>>>> start.c: barebox_arm_boot_dtb: using barebox_boarddata
>>>>>>>>> using boarddata provided DTB
>>>>>>>>> adding DT alias:serial0: stem=serial id=0
>>>> node=/soc/serial@d000307000
>>>>>>>>> register_device: machine
>>>>>>>>> of_platform_bus_create() - skipping /chosen, no compatible prop
>>>>>>>>> of_platform_bus_create() - skipping /aliases, no compatible prop
>>>>>>>>> of_platform_bus_create() - skipping /cpus, no compatible prop
>>>>>>>>> of_platform_bus_create() - skipping /memory@0, no compatible
>> prop
>>>>>>>>> of_platform_bus_create() - skipping /soc, no compatible prop
>>>>>>>>> initcall-> register_autoboot_vars+0x0/0x70
>>>>>>>>> initcall-> arm_arch_timer_driver_register+0x0/0x1c
>>>>>>>>> register_driver: arm-architected-timer
>>>>>>>>> initcall-> of_timer_init+0x0/0x20
>>>>>>>>> initcall-> init_fs+0x0/0x3c
>>>>>>>>> initcall-> pl011_driver_register+0x0/0x1c
>>>>>>>>> register_driver: uart-pl011
>>>>>>>>> initcall-> of_stdoutpath_init+0x0/0x28
>>>>>>>>> initcall-> of_probe_memory+0x0/0x60
>>>>>>>>> __request_region ok: 0x00000000:0x07ffffff flags=0x0
>>>>>>>>> initcall-> __bare_init_end+0x0/0x6c
>>>>>>>>> register_device: mem0
>>>>>>>>> initcall-> of_reserved_mem_walk+0x0/0x1ac
>>>>>>>>> initcall-> mem_malloc_resource+0x0/0xa8
>>>>>>>>> __request_region ok: 0x079ffcc0:0x07dffcbf flags=0x200
>>>>>>>>> __request_region ok: 0x07e00000:0x07e2aeff flags=0x200
>>>>>>>>> __request_region ok: 0x07e2af00:0x07e390cf flags=0x200
>>>>>>>>> __request_region ok: 0x07e390d0:0x07e3adaf flags=0x200
>>>>>>>>> initcall-> bootsource_init+0x0/0x40
>>>>>>>>> initcall-> ramfs_init+0x0/0x1c
>>>>>>>>> register_driver: ramfs
>>>>>>>>> initcall-> devfs_init+0x0/0x1c
>>>>>>>>> register_driver: devfs
>>>>>>>>> initcall-> arm_request_stack+0x0/0x398
>>>>>>>>> __request_region ok: 0x07ff0000:0x07ff7fff flags=0x200
>>>>>>>>> initcall-> mount_root+0x0/0x7c
>>>>>>>>> mount: none on / type ramfs, options=
>>>>>>>>> register_device: ramfs0
>>>>>>>>> probe-> ramfs0
>>>>>>>>> mount: none on /dev type devfs, options=
>>>>>>>>> register_device: devfs0
>>>>>>>>> probe-> devfs0
>>>>>>>>> initcall-> binfmt_sh_init+0x0/0x1c
>>>>>>>>> initcall-> binfmt_uimage_init+0x0/0x1c
>>>>>>>>> initcall-> console_common_init+0x0/0x48
>>>>>>>>> initcall-> of_kernel_init+0x0/0x28
>>>>>>>>> initcall-> console_ctrlc_init+0x0/0x30
>>>>>>>>> initcall-> mem_init+0x0/0x90
>>>>>>>>> register_device: mem1
>>>>>>>>> register_driver: mem
>>>>>>>>> probe-> mem0
>>>>>>>>> probe-> mem1
>>>>>>>>> initcall-> of_partition_init+0x0/0x48
>>>>>>>>> initcall-> prng_init+0x0/0x40
>>>>>>>>> initcall-> null_init+0x0/0x40
>>>>>>>>> initcall-> full_init+0x0/0x40
>>>>>>>>> initcall-> zero_init+0x0/0x40
>>>>>>>>> initcall-> spider_board_driver_register+0x0/0x1c
>>>>>>>>> register_driver: board-spider
>>>>>>>>> probe-> machine
>>>>>>>>> initcall-> barebox_memory_areas_init+0x0/0x40
>>>>>>>>> __request_region ok: 0x07dffcc0:0x07dfffce flags=0x200
>>>>>>>>> initcall-> barebox_of_populate+0x0/0x28
>>>>>>>>> initcall-> of_register_memory_fixup+0x0/0x20
>>>>>>>>> initcall-> dummy_csrc_warn+0x0/0x44
>>>>>>>>> WARNING: Warning: Using dummy clocksource
>>>>>>>>
>>>>>>>> Add a arm,armv8-timer node into your SoC device tree.
>>>>>>>> This lets barebox and Linux know that you have the ARM
>>>>>>>> architected timer available. Without that, you'll notice
>>>>>>>> that timeouts are wrong.
>>>>>>>>
>>>>>>>>> initcall-> bootm_init+0x0/0xf4
>>>>>>>>> initcall-> init_command_list+0x0/0x40
>>>>>>>>> register command bootm
>>>>>>>>> register command cat
>>>>>>>>> register command cd
>>>>>>>>> register command clear
>>>>>>>>> register command cp
>>>>>>>>> register command cpuinfo
>>>>>>>>> register command devinfo
>>>>>>>>> register command drvinfo
>>>>>>>>> register command echo
>>>>>>>>> register command exit
>>>>>>>>> register command false
>>>>>>>>> register command help
>>>>>>>>> register command ?
>>>>>>>>> register command ll
>>>>>>>>> register command ls
>>>>>>>>> register command md
>>>>>>>>> register command memcmp
>>>>>>>>> register command memcpy
>>>>>>>>> register command memset
>>>>>>>>> register command mkdir
>>>>>>>>> register command mount
>>>>>>>>> register command mw
>>>>>>>>> register command pwd
>>>>>>>>> register command rm
>>>>>>>>> register command rmdir
>>>>>>>>> register command setenv
>>>>>>>>> register command sh
>>>>>>>>> register command source
>>>>>>>>> register command .
>>>>>>>>> register command test
>>>>>>>>> register command [
>>>>>>>>> register command true
>>>>>>>>> register command :
>>>>>>>>> register command umount
>>>>>>>>> register command version
>>>>>>>>> initcall-> display_meminfo+0x0/0xa8
>>>>>>>>> barebox code: 0x7e00000 -> 0x7e2aeff
>>>>>>>>> bss segment: 0x7e390d0 -> 0x7e3adaf
>>>>>>>>> malloc space: 0x079ffcc0 -> 0x07dffcbf (size 4 MiB)
>>>>>>>>> initcall-> of_register_bootargs_fixup+0x0/0x3c
>>>>>>>>> initcall-> device_probe_deferred+0x0/0x14c
>>>>>>>>> initcall-> of_init_hostname+0x0/0x28
>>>>>>>>> initcall-> aarch64_register_image_handler+0x0/0x2c
>>>>>>>>> initcall-> load_environment+0x0/0x4c
>>>>>>>>> loading defaultenv
>>>>>>>>> environment load /dev/env0: No such file or directory
>>>>>>>>> Maybe you have to create the partition.
>>>>>>>>> initcalls done
>>>>>>>>>
>>>>>>>>> Hit any to stop autoboot: 0
>>>>>>>>> boot: No such file or directory
>>>>>>>>> barebox:/
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Few questions:
>>>>>>>>> 1. The serial input doesn't work. i.e. I cannot type anything hence
>>>> cannot
>>>>>>>> interact with barebox terminal.
>>>>>>>>
>>>>>>>> DEBUG_LL only does otuput. For input, you will want to load the
>> driver.
>>>>>>>> Do you have CONFIG_SERIAL_AMBA_PL011 enabled?
>>>>>>>>
>>>>>>>>> Does it require GIC and setting interrupts for it to work?
>>>>>>>>
>>>>>>>> No interrupts needed. barebox runs with interrupts disabled and
>>>>>> everything
>>>>>>>> is done cooperatively.
>>>>>>>>
>>>>>>>>> 2. What does "of_platform_bus_create() - skipping" means? Do I
>> need
>>>> to
>>>>>> fix
>>>>>>>> that?
>>>>>>>>
>>>>>>>> That's normal debugging output. Some device tree nodes are busses,
>>>> which
>>>>>>>> have
>>>>>>>> children. These entries are skipped because they have no compatible.
>>>> This is
>>>>>>>> expected. I'd suggest you remove your VERBOSED_DEBUG define, so
>> you
>>>>>> are
>>>>>>>> not
>>>>>>>> spammed by too much debugging output.
>>>>>>>>
>>>>>>>>> 3. Looks like I am still missing some stuff (rootfs? Environment?
>>>>>> Mounting?
>>>>>>>> Partitions?)
>>>>>>>>
>>>>>>>> Take multi_v8_defconfig, open menuconfig and enable your SoC and
>> use
>>>>>> that.
>>>>>>>> That will be quicker than enabling everything yourself. If it doesn't
>> work
>>>>>>>> out of the box, try imx_v8_defconfig.
>>>>>>>>
>>>>>>>> Once you get around to upstreaming your SoC, I'd suggest you just
>> add it
>>>>>>>> to multi_v8_defconfig. Not all ARMv8 SoCs are supported there, but
>>>> those
>>>>>>>> that are make development easier, because we don't need to build as
>>>> many
>>>>>>>> different configs..
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Ahmad
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Have a great day,
>>>>>>>>> Lior.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: Ahmad Fatoum <a.fatoum@pengutronix.de>
>>>>>>>>>> Sent: Wednesday, May 31, 2023 9:11 AM
>>>>>>>>>> To: Lior Weintraub <liorw@pliops.com>; Ahmad Fatoum
>>>>>> <ahmad@a3f.at>;
>>>>>>>>>> barebox@lists.infradead.org
>>>>>>>>>> Subject: Re: [PATCH v2] Porting barebox to a new SoC
>>>>>>>>>>
>>>>>>>>>> CAUTION: External Sender
>>>>>>>>>>
>>>>>>>>>> Hi Lior,
>>>>>>>>>>
>>>>>>>>>> On 30.05.23 22:10, Lior Weintraub wrote:
>>>>>>>>>>> Hello Ahmad,
>>>>>>>>>>>
>>>>>>>>>>> Thanks again for your kind support!
>>>>>>>>>>> Your comments helped me progress and the current situation is as
>>>>>>>> follows:
>>>>>>>>>>> Our QEMU Spider machine is running a BL1.elf file using the
>> following
>>>>>>>>>> command:
>>>>>>>>>>> QEMU_AUDIO_DRV=none qemu-system-aarch64 -M spider-soc -
>>>> smp 1
>>>>>> -
>>>>>>>> m
>>>>>>>>>> 128M -nographic \
>>>>>>>>>>> -device loader,file=BL1.elf -cpu cortex-
>> a53,rvbar=0xC004000000 \
>>>>>>>>>>> -d unimp -semihosting-config enable=on,target=native \
>>>>>>>>>>> -monitor telnet:localhost:1235,server,nowait \
>>>>>>>>>>> -gdb tcp::1236
>>>>>>>>>>>
>>>>>>>>>>> The BL1.elf is our BootROM application that runs from ROM
>> address
>>>>>>>>>> 0xC004000000.
>>>>>>>>>>> Just for debugging purpose we've increased the ROM size so it can
>>>>>> include
>>>>>>>>>> the images/barebox-spider-mk1-evk.img (as a const array).
>>>>>>>>>>> BL1 then copy it (using memcpy) to address 0 and jumps there for
>>>>>>>>>> execution.
>>>>>>>>>>
>>>>>>>>>> Sounds ok.
>>>>>>>>>>
>>>>>>>>>>> On the real ASIC this address will be the DRAM and indeed will need
>>>> to
>>>>>> be
>>>>>>>>>> initialized before the copy but here on QEMU it is not required.
>>>>>>>>>>
>>>>>>>>>> I see. You could still have your bootrom move barebox into SRAM
>> and
>>>>>> then
>>>>>>>>>>
>>>>>>>>>> barebox_arm_entry(DRAM_ADDR, SZ_128M,
>>>>>>>> __dtb_spider_mk1_evk_start);
>>>>>>>>>>
>>>>>>>>>> To have PBL extract barebox to DRAM. Even if you don't need need
>>>>>> DRAM
>>>>>>>>>> setup in QEMU, the flow would be similar to what you will have on
>>>> actual
>>>>>>>>>> silicon.
>>>>>>>>>>
>>>>>>>>>>> The lowlevel.c of spider-evk was modified to use DRAM_ADDR
>>>>>> 0x400000
>>>>>>>>>> (4MB from start) and MY_STACK_TOP was set to 0x8000000
>> (128M).
>>>>>>>>>>
>>>>>>>>>> That's not needed. While you don't have control where barebox PBL
>>>> will
>>>>>> be
>>>>>>>>>> located
>>>>>>>>>> (depends on BootROM), barebox will extract itself to the end of
>> DRAM
>>>>>>>>>> without
>>>>>>>>>> overwriting itself, so you can just use DRAM_ADDR 0 normally.
>>>>>> Eventually,
>>>>>>>>>> stack
>>>>>>>>>> top should go into SRAM, but anywhere that works is ok.
>>>>>>>>>>
>>>>>>>>>>> In addition, I implemented putc_ll (currently hard-coded in
>>>>>>>>>> include/debug_ll.h) and opened log level to VERBOSE_DEBUG
>>>> (currently
>>>>>>>> just
>>>>>>>>>> hard-coded in printk.h).
>>>>>>>>>>
>>>>>>>>>> There's CONFIG_DEBUG_PBL you can enable to get all these
>> messages
>>>> by
>>>>>>>>>> default.
>>>>>>>>>>
>>>>>>>>>>> I see the following (which makes sense) logs on QEMU terminal:
>>>>>>>>>>> uncompress.c: memory at 0x00400000, size 0x00200000
>>>>>>>>>>> uncompress.c: uncompressing barebox binary at
>>>>>> 0x0000000000002200
>>>>>>>>>> (size 0x0001d3b2) to 0x00400000 (uncompressed size:
>> 0x000373d0)
>>>>>>>>>>
>>>>>>>>>> Why pass only 2M to barebox_arm_entry? While this need not be
>> the
>>>>>>>> whole
>>>>>>>>>> of RAM, this
>>>>>>>>>> initial memory is what barebox will use for itself including its final
>> stack
>>>>>> and
>>>>>>>>>> malloc area. barebox will also not place itself into the last 1M AFAIK,
>> so
>>>>>> 2M
>>>>>>>>>> may not work ok. You should use the minimum possible RAM here
>> or
>>>> if
>>>>>> you
>>>>>>>>>> can detect
>>>>>>>>>> in PBL how much RAM you have or just the whole RAM bank. I am
>> not
>>>>>> sure
>>>>>>>>>> anything lower
>>>>>>>>>> than SZ_4M would work ok. (Note this is DRAM size, not SRAM.
>>>> barebox
>>>>>>>> PBL
>>>>>>>>>> is fine being
>>>>>>>>>> called from 64K SRAMs, it just needs DRAM to extract to).
>>>>>>>>>>
>>>>>>>>>>> I then connect with aarch64-none-elf-gdb, load the barebox
>> symbols
>>>>>> (to
>>>>>>>>>> 0x400000) and check the current execution state (program counter
>>>> and
>>>>>>>>>> stack).
>>>>>>>>>>> Looks like the code is stuck on function register_autoboot_vars:
>>>>>>>>>>> sp 0x5f7e60 0x5f7e60
>>>>>>>>>>> pc 0x401264 0x401264 <register_autoboot_vars+24>
>>>>>>>>>>>
>>>>>>>>>>> Few observations:
>>>>>>>>>>> 1. The PBL was using stack top located on 0x8000000 (which is
>>>>>>>>>> MY_STACK_TOP). Found it be causing a breakpoint on the PBL.
>>>>>>>>>>> 2. Barebox uses a stack top on 0x600000 which is probably
>> calculated
>>>>>>>> from
>>>>>>>>>> my new DRAM_ADDR and SZ_2M given to the function call:
>>>>>>>>>>> barebox_arm_entry(DRAM_ADDR, SZ_2M,
>>>>>>>> __dtb_spider_mk1_evk_start);
>>>>>>>>>>>
>>>>>>>>>>> This is great! I am starting to find my way.
>>>>>>>>>>
>>>>>>>>>> :) Ye, the ENTRY_FUNCTION_WITHSTACK is only when the BootROM
>>>>>>>> doesn't
>>>>>>>>>> enter
>>>>>>>>>> with a valid stack pointer. It's overwritten as soon as barebox is told
>>>>>>>>>> about the initial memory layout (with barebox_arm_entry).
>>>>>>>>>>
>>>>>>>>>>> When the barebox execution didn't print anything to the terminal I
>>>>>>>>>> remembered that we used a place holder on the dtsi for the uart.
>>>>>>>>>>> So now I changed it to:
>>>>>>>>>>> uart0: serial@d000307000 {
>>>>>>>>>>> compatible = "arm,pl011", "arm,primecell";
>>>>>>>>>>> reg = <0xd0 0x307000 0 0x1000>;
>>>>>>>>>>> }
>>>>>>>>>>> (Our QEMU UART is currently using pl011 device.)
>>>>>>>>>>
>>>>>>>>>> Looks ok. Don't forget to enable the driver (via make menuconfig).
>>>>>>>>>>
>>>>>>>>>>> After some time (trying to debug by enabling MMU but then
>> reverted
>>>>>> the
>>>>>>>>>> code back), I got to a point that when I try to run again I am getting
>> an
>>>>>>>>>> exception.
>>>>>>>>>>> I can swear all code changes were reverted back to the point where
>> I
>>>>>> saw
>>>>>>>> the
>>>>>>>>>> barebox stuck on register_autoboot_vars but now it just cases an
>>>>>>>> exception.
>>>>>>>>>>> The exception vector code is located on our ROM (part of BL1 code)
>>>> and
>>>>>>>> the
>>>>>>>>>> logs shows that the link register has the value 0x401218 which
>> suggest
>>>>>> the
>>>>>>>>>> following code:
>>>>>>>>>>> 0000000000001200 <load_environment>:
>>>>>>>>>>> 1200: a9be7bfd stp x29, x30, [sp, #-32]!
>>>>>>>>>>> 1204: 910003fd mov x29, sp
>>>>>>>>>>> 1208: a90153f3 stp x19, x20, [sp, #16]
>>>>>>>>>>> 120c: 94000a07 bl 3a28 <default_environment_path_get>
>>>>>>>>>>> 1210: d00000f3 adrp x19, 1f000 <do_cpuinfo+0x1f0>
>>>>>>>>>>> 1214: 912a7273 add x19, x19, #0xa9c
>>>>>>>>>>> 1218: aa0003f4 mov x20, x0
>>>>>>>>>>>
>>>>>>>>>>> Any ideas or suggestions how to proceed with the debugging?
>>>>>>>>>>
>>>>>>>>>> You shouldn't need to touch the MMU code. If your initial memory
>>>> setup
>>>>>>>>>> is wonky, you may end up overwriting stuff. Try again with bigger
>>>>>> memory.
>>>>>>>>>>
>>>>>>>>>>> BTW, to answer your questions:
>>>>>>>>>>> The SRAM of 4MB is the only one we have because we assumed it
>> is
>>>>>> only
>>>>>>>> for
>>>>>>>>>> BootROM to load a PBL
>>>>>>>>>>
>>>>>>>>>> Ok. Sometimes there are SRAMs for use with DMA. I asked, because
>> a
>>>>>>>> SRAM
>>>>>>>>>> in the first 4M
>>>>>>>>>> would lend itself nicely as stack, but if there is none, we can adjust
>>>>>>>>>> ENTRY_FUNCTION_WITHSTACK to accept a 64-bit parameter.
>>>>>>>>>>
>>>>>>>>>> Cheers,
>>>>>>>>>> Ahmad
>>>>>>>>>>
>>>>>>>>>>> Thank you very much,
>>>>>>>>>>> Cheers,
>>>>>>>>>>> Lior.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>> From: Ahmad Fatoum <a.fatoum@pengutronix.de>
>>>>>>>>>>>> Sent: Monday, May 29, 2023 10:03 PM
>>>>>>>>>>>> To: Lior Weintraub <liorw@pliops.com>; Ahmad Fatoum
>>>>>>>> <ahmad@a3f.at>;
>>>>>>>>>>>> barebox@lists.infradead.org
>>>>>>>>>>>> Subject: Re: [PATCH v2] Porting barebox to a new SoC
>>>>>>>>>>>>
>>>>>>>>>>>> CAUTION: External Sender
>>>>>>>>>>>>
>>>>>>>>>>>> Hello Lior,
>>>>>>>>>>>>
>>>>>>>>>>>> On 29.05.23 15:34, Lior Weintraub wrote:
>>>>>>>>>>>>> Hi Ahmad,
>>>>>>>>>>>>>
>>>>>>>>>>>>> I have revised the addresses and used DRAM address @ 0
>> instead:
>>>>>>>>>>>>> #define UARTBASE (0xD000307000)
>>>>>>>>>>>>> #define DRAM_ADDR (0x00000000)
>>>>>>>>>>>>> #define MY_STACK_TOP (0x00000000 + SZ_2M) // Set the
>> stack
>>>>>> 2MB
>>>>>>>>>> from
>>>>>>>>>>>> DRAM start
>>>>>>>>>>>>
>>>>>>>>>>>> Is DRAM configured by the time barebox runs? If not, you should
>>>> keep
>>>>>>>>>> stack
>>>>>>>>>>>> top
>>>>>>>>>>>> in SRAM, until you have setup memory in prebootloader (PBL). Is
>>>> the
>>>>>> 4M
>>>>>>>>>>>> SRAM
>>>>>>>>>>>> the only on-chip SRAM you have?
>>>>>>>>>>>>
>>>>>>>>>>>>> static inline void spider_serial_putc(void *base, int c)
>>>>>>>>>>>>> {
>>>>>>>>>>>>> *((volatile unsigned *)base) = c;
>>>>>>>>>>>>
>>>>>>>>>>>> There's a helper for that: writel(c, base); In barebox, it's equivalent
>>>>>>>>>>>> to the volatile access, but in Linux it involves a write memory
>> barrier.
>>>>>>>>>>>> We try to write code in barebox, so it's easily reusable in Linux
>> (and
>>>>>>>>>>>> the other way round).
>>>>>>>>>>>>
>>>>>>>>>>>>> }
>>>>>>>>>>>>>
>>>>>>>>>>>>> I will try to test it on QEMU using an initial QEMU machine we
>>>> made
>>>>>> for
>>>>>>>>>>>> Spider.
>>>>>>>>>>>>> In this machine we only have 3 memory regions and a PL011
>> UART:
>>>>>>>>>>>>> spider_soc_memories soc_memories[] = {
>>>>>>>>>>>>> {.name = "SPIDER_GPRAM", .add = 0xC000000000ULL, .size =
>> 4
>>>> *
>>>>>>>> MiB},
>>>>>>>>>>>>> {.name = "SPIDER_ROM", .add = 0xC004000000ULL, .size =
>>>> 128 *
>>>>>>>>>> KiB},
>>>>>>>>>>>>> {.name = "SPIDER_DRAM", .add = 0x0000000000ULL, .size =
>> 1
>>>> *
>>>>>>>> GiB},
>>>>>>>>>>>>> };
>>>>>>>>>>>>>
>>>>>>>>>>>>> This special QEMU machine can run our BL1 code from "ROM"
>>>>>> address
>>>>>>>>>> (we
>>>>>>>>>>>> set the RVBAR to point there).
>>>>>>>>>>>>> So my idea is to test the barebox image by the following steps:
>>>>>>>>>>>>> 1. Modify the QEMU code to have a "ROM" with the size of
>> 128M.
>>>>>>>>>>>>> 2. Compile our BL1 code to include the barebox.bin as a const
>>>> array,
>>>>>>>> copy
>>>>>>>>>> it
>>>>>>>>>>>> to "DRAM" @ address 0 and jump there.
>>>>>>>>>>>>
>>>>>>>>>>>> Why not map QEMU -bios option to SRAM? (Or DRAM directly, if
>> it
>>>>>>>> needs
>>>>>>>>>> no
>>>>>>>>>>>> special setup from
>>>>>>>>>>>> barebox side).
>>>>>>>>>>>>
>>>>>>>>>>>>> For this to work I wanted to understand how to call (i.e. what
>>>>>>>> arguments
>>>>>>>>>> to
>>>>>>>>>>>> pass) to barebox.
>>>>>>>>>>>>
>>>>>>>>>>>> barebox doesn't expect any arguments, because most BootROMs
>>>>>> don't
>>>>>>>>>> pass
>>>>>>>>>>>> anything useful.
>>>>>>>>>>>> Some pass information about bootsource though, so that's why
>> the
>>>>>>>>>>>> ENTRY_FUNCTION has
>>>>>>>>>>>> r0, r1 and r2 as parameters, but you need not use them.
>>>>>>>>>>>>
>>>>>>>>>>>>> So I checked the barebox.map and found the function "start" on
>>>>>>>> address
>>>>>>>>>> 0.
>>>>>>>>>>>>
>>>>>>>>>>>> You may know that Linux on some platforms comes with a
>>>>>> decompressor
>>>>>>>>>> that
>>>>>>>>>>>> is glued to the
>>>>>>>>>>>> front of the kernel image and extracts the compressed kernel
>> image.
>>>>>>>>>> barebox
>>>>>>>>>>>> has the same
>>>>>>>>>>>> concept. The prebootloader is uncompressed and runs (starting
>>>> from
>>>>>>>>>>>> ENTRY_FUNCTION) and
>>>>>>>>>>>> then does some early setup (e.g. enable clocks, configure PMIC,
>>>> setup
>>>>>>>>>> DRAM,
>>>>>>>>>>>> load secure
>>>>>>>>>>>> monitor (BL31), ...etc.) and then it decompresses barebox proper
>>>> into
>>>>>>>>>> DRAM.
>>>>>>>>>>>>
>>>>>>>>>>>> barebox.bin <- barebox proper. You don't usually need that.
>>>>>>>>>>>> barebox.elf <- ELF binary for the above (for gdb)
>>>>>>>>>>>> barebox.map <- map file of the above
>>>>>>>>>>>>
>>>>>>>>>>>> images/barebox-spider-mk1-evk.img <- complete barebox image
>>>> (PBL
>>>>>> +
>>>>>>>>>>>> barebox proper)
>>>>>>>>>>>> images/start_spider_mk1_evk.pbl <- ELF image for the above
>>>>>>>>>>>> images/start_spider_mk1_evk.pbl.map <- map file of the above
>>>>>>>>>>>>
>>>>>>>>>>>> If you want to follow barbeox from the start, begin at
>>>>>>>>>> start_spider_mk1_evk.
>>>>>>>>>>>>
>>>>>>>>>>>>> Then I went to arch/arm/cpu/start.c and realized that the code is
>>>>>>>> compiled
>>>>>>>>>>>> with CONFIG_PBL_IMAGE.
>>>>>>>>>>>>> In that case I assume I need to pass 3 arguments and use this
>>>>>> function
>>>>>>>>>>>> prototype:
>>>>>>>>>>>>> void start(unsigned long membase, unsigned long memsize, void
>>>>>>>>>>>> *boarddata);
>>>>>>>>>>>>
>>>>>>>>>>>> barebox prebootloader takes care of this, so you don't need to do
>>>>>>>> anything.
>>>>>>>>>>>>
>>>>>>>>>>>>> Few questions:
>>>>>>>>>>>>> 1. Will that call work:
>>>>>>>>>>>>> typedef void (*barebox_start)(unsigned long , unsigned long ,
>>>> void
>>>>>> *);
>>>>>>>>>>>>> #define DRAM_START (0)
>>>>>>>>>>>>> barebox_start p_barebox = (barebox_start)DRAM_START;
>>>>>>>>>>>>> p_barebox(DRAM_START, DRAM_START+SZ_2M, (void
>>>>>>>>>>>> *)(DRAM_START+SZ_4M));
>>>>>>>>>>>>> This assumes that my BL1 code also copied the device tree
>>>>>> (barebox-
>>>>>>>> dt-
>>>>>>>>>>>> 2nd.img? start_dt_2nd.pblb? start_spider_mk1_evk.pblb?)
>>>>>>>>>>>>
>>>>>>>>>>>> The device tree is built into the PBL and passed to barebox proper.
>>>> This
>>>>>>>>>>>> allows us to use the same barebox proper binary and link it with a
>>>>>>>> different
>>>>>>>>>>>> prebootloader for each SoC/board, all in the same build.
>>>>>>>>>>>>
>>>>>>>>>>>> barebox-dt-2nd.img is a special image that looks exactly like a
>> Linux
>>>>>>>> kernel:
>>>>>>>>>>>>
>>>>>>>>>>>> images/barebox-dt-2nd.img: Linux kernel ARM64 boot
>> executable
>>>>>>>> Image,
>>>>>>>>>>>> little-endian, 4K pages
>>>>>>>>>>>>
>>>>>>>>>>>> and can thus be used for booting for easy chainloading from other
>>>>>>>>>>>> bootloaders or for running
>>>>>>>>>>>> with QEMU -kernel. You shouldn't need it right now.
>>>>>>>>>>>>
>>>>>>>>>>>>> 2. Do I want to have my code compiled with
>> CONFIG_PBL_IMAGE?
>>>>>>>>>>>>> If I understand correctly, it means that my code will provide a
>> PBL
>>>>>>>> (a.k.a
>>>>>>>>>>>> BL2) which will set the DRAM and STACK among other things
>>>> (MMU?).
>>>>>>>>>>>>
>>>>>>>>>>>> The patch I sent already builds a PBL. You will need to fill out
>>>>>>>>>>>> start_spider_mk1_evk
>>>>>>>>>>>> to do all the other early initialization you need. Then you call
>>>>>>>>>>>> barebox_arm_entry
>>>>>>>>>>>> with device tree and memory size and it will take care to do stack
>>>> setup
>>>>>> in
>>>>>>>>>> new
>>>>>>>>>>>> memory region, MMU setup (if enabled) and chainloading
>> barebox
>>>>>>>> proper.
>>>>>>>>>>>>
>>>>>>>>>>>> Note that PBL isn't necessary BL2. You can chainload barebox
>> from
>>>>>> within
>>>>>>>>>>>> barebox (i.e.
>>>>>>>>>>>> in EL2 or EL1), which is useful for debugging. You will thus often
>> find
>>>>>> PBL
>>>>>>>>>> code
>>>>>>>>>>>> that
>>>>>>>>>>>> does
>>>>>>>>>>>>
>>>>>>>>>>>> if (current_el() == 3) {
>>>>>>>>>>>> /* Do BL2 setup */
>>>>>>>>>>>> chainload();
>>>>>>>>>>>> __builtin_unreachable();
>>>>>>>>>>>> }
>>>>>>>>>>>>
>>>>>>>>>>>> barebox_arm_entry(...)
>>>>>>>>>>>>
>>>>>>>>>>>> See for example arch/arm/boards/innocomm-imx8mm-
>>>>>> wb15/lowlevel.c
>>>>>>>>>>>>
>>>>>>>>>>>> to see a real-world example of another Cortex-A53.
>>>>>>>>>>>>
>>>>>>>>>>>>> In that case I assume it is OK.
>>>>>>>>>>>>> 3. If I try to remove it by having CONFIG_PBL_IMAGE=n on
>>>>>>>>>> spider_defconfig
>>>>>>>>>>>> this doesn't do anything
>>>>>>>>>>>>> The build (make spider_defconfig) ignores it and say that " No
>>>>>> change
>>>>>>>> to
>>>>>>>>>>>> .config ".
>>>>>>>>>>>>
>>>>>>>>>>>> Another symbol forces it to be enabled. If you are curious, run
>> make
>>>>>>>>>>>> menuconfig
>>>>>>>>>>>> and then search (/) for the symbol and it will list, whether it's
>>>> enabled
>>>>>>>> and
>>>>>>>>>>>> why:
>>>>>>>>>>>>
>>>>>>>>>>>> Selected by [y]:
>>>>>>>>>>>> - PBL_MULTI_IMAGES [=y] && HAVE_PBL_MULTI_IMAGES [=y]
>>>>>>>>>>>>
>>>>>>>>>>>> I'd suggest you avoid modifying the .config file manually. always
>> use
>>>>>>>>>>>> menuconfig.
>>>>>>>>>>>>
>>>>>>>>>>>>> 4. I also tried to understand how to implement PUTC_LL but not
>>>> sure
>>>>>> I
>>>>>>>>>>>> understand.
>>>>>>>>>>>>> 4.1 When I set "CONFIG_DEBUG_LL=y" on spider_defconfig it is
>>>>>> again
>>>>>>>>>> not
>>>>>>>>>>>> written to .config and I get " No change to .config " message.
>>>>>>>>>>>>
>>>>>>>>>>>> You must:
>>>>>>>>>>>>
>>>>>>>>>>>> - select HAS_DEBUG_LL from MACH_SPIDER
>>>>>>>>>>>> - Add your arch to arch/arm/include/asm/debug_ll.h
>>>>>>>>>>>> - Then implement PUTC_LL in e.g. mach/spider/debug_ll.h
>>>>>>>>>>>>
>>>>>>>>>>>>> 4.2 Do I need to have my own debug_ll.h file?
>>>>>>>>>>>>
>>>>>>>>>>>> Yes. See above.
>>>>>>>>>>>>
>>>>>>>>>>>>> 5. When I make changes to spider_defconfig and try to
>> regenerate
>>>>>> the
>>>>>>>>>>>> .config and I get " No change to .config " message, does it mean
>> that
>>>>>>>> those
>>>>>>>>>>>> macros are "hidden" symbols like you said about the
>>>>>> CONFIG_CPU_V8?
>>>>>>>>>>>>
>>>>>>>>>>>> Yes. Just check menuconfig to see how symbols relate to each
>> other.
>>>>>>>>>>>> This is 1:1 like it's in Linux, so it'll come in handy when you do
>>>>>>>>>>>> the kernel port too ;)
>>>>>>>>>>>>
>>>>>>>>>>>>> Apologize for so many questions :-)
>>>>>>>>>>>>
>>>>>>>>>>>> No problem. Looking forward to your patches ;)
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Cheers,
>>>>>>>>>>>> Ahmad
>>>>>>>>>>>>
>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>> Lior.
>>>>>>>>>>>>>
>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>> From: Lior Weintraub
>>>>>>>>>>>>> Sent: Sunday, May 28, 2023 11:16 PM
>>>>>>>>>>>>> To: Ahmad Fatoum <ahmad@a3f.at>;
>> barebox@lists.infradead.org
>>>>>>>>>>>>> Subject: RE: [PATCH v2] Porting barebox to a new SoC
>>>>>>>>>>>>>
>>>>>>>>>>>>> Hi Ahmad,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thank you so much for your kind support!
>>>>>>>>>>>>>
>>>>>>>>>>>>> Indeed we also have a 16GB DRAM that starts from address 0
>>>>>> (though
>>>>>>>>>>>> currently we don't have the controller settings (under
>>>> development)).
>>>>>>>>>>>>>
>>>>>>>>>>>>> I also wrote the BootROM (BL1) for this SoC (128KB ROM @
>>>> address
>>>>>>>>>>>> 0xC004000000).
>>>>>>>>>>>>> I understand now that it would be best for me to develop BL2
>> that
>>>>>> will
>>>>>>>> run
>>>>>>>>>>>> from our SRAM.
>>>>>>>>>>>>>
>>>>>>>>>>>>> As this BL2 code is bare-metal I have no problem or limitations
>> with
>>>>>> the
>>>>>>>> 40
>>>>>>>>>>>> bit addresses.
>>>>>>>>>>>>> The BL2 code will initialize the DRAM controller and then copy
>>>>>> Barebox
>>>>>>>>>> image
>>>>>>>>>>>> from NOR Flash to address 0 of the DRAM.
>>>>>>>>>>>>> Our NOR Flash is 128MB in size and it is accessed via QSPI
>>>> controller.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I tried applying your suggested patch but got an error while
>> doing
>>>> so:
>>>>>>>>>>>>> $git apply 0002-Ahmad.patch
>>>>>>>>>>>>> 0002-Ahmad.patch:115: trailing whitespace.
>>>>>>>>>>>>> .of_compatible = spider_board_of_match, };
>>>>>>>>>>>>> error: corrupt patch at line 117
>>>>>>>>>>>>>
>>>>>>>>>>>>> After some digging I found that my Outlook probably messed
>> with
>>>>>> the
>>>>>>>>>> patch
>>>>>>>>>>>> format (even though I am using text only and no HTML format).
>>>>>>>>>>>>> When I went to the web and copied the patch from there
>> (mailing
>>>> list
>>>>>>>>>>>> archive) it was working well (i.e. no compilation error).
>>>>>>>>>>>>>
>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>> Lior.
>>>>>>>>>>>>>
>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>> From: Ahmad Fatoum <ahmad@a3f.at>
>>>>>>>>>>>>> Sent: Sunday, May 28, 2023 6:38 PM
>>>>>>>>>>>>> To: barebox@lists.infradead.org
>>>>>>>>>>>>> Cc: Lior Weintraub <liorw@pliops.com>
>>>>>>>>>>>>> Subject: [PATCH v2] Porting barebox to a new SoC
>>>>>>>>>>>>>
>>>>>>>>>>>>> CAUTION: External Sender
>>>>>>>>>>>>>
>>>>>>>>>>>>> From: Lior Weintraub <liorw@pliops.com>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>
>>>>>>>>>>>>> I tried to follow the porting guide on https://ddec1-0-en-
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>> ctp.trendmicro.com:443/wis/clicktime/v1/query?url=https%3a%2f%2fwww.
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>> barebox.org%2fdoc%2flatest%2fdevel%2fporting.html%23&umid=60097eda
>>>>>>>>>>>> -f136-45a1-9c8e-
>>>>>>>>>>>>
>>>>>> cf6a76e45cf8&auth=860a7ebb9feba264acc79b6e38eb59582349362c-
>>>>>>>>>>>> 480ae23736add41c88ab8d30c090a75517ca7f9e but couldn't
>>>> follow
>>>>>>>> the
>>>>>>>>>>>> instructions.
>>>>>>>>>>>>> I would like to port barebox to a new SoC (which is not a
>> derivative
>>>> of
>>>>>>>> any
>>>>>>>>>>>> known SoC).
>>>>>>>>>>>>> It has the following:
>>>>>>>>>>>>> * Single Cortex A53
>>>>>>>>>>>>> * SRAM (4MB) located on address 0xC000000000
>>>>>>>>>>>>>
>>>>>>>>>>>>> The below patch shows my initial test to try and have a starting
>>>> point.
>>>>>>>>>>>>> I am setting env variables:
>>>>>>>>>>>>> export ARCH=arm64
>>>>>>>>>>>>> export CROSS_COMPILE=/home/pliops/workspace/ARM/arm-
>>>> gnu-
>>>>>>>>>>>> toolchain/bin/aarch64-none-elf-
>>>>>>>>>>>>>
>>>>>>>>>>>>> Then I build with:
>>>>>>>>>>>>> make spider_defconfig && make
>>>>>>>>>>>>>
>>>>>>>>>>>>> This gives an error:
>>>>>>>>>>>>> aarch64-none-elf-gcc: error: unrecognized argument in option '-
>>>>>>>>>> mabi=apcs-
>>>>>>>>>>>> gnu'
>>>>>>>>>>>>> aarch64-none-elf-gcc: note: valid arguments to '-mabi=' are:
>> ilp32
>>>>>> lp64
>>>>>>>>>>>>> aarch64-none-elf-gcc: error: unrecognized command-line option
>> '-
>>>>>>>> msoft-
>>>>>>>>>>>> float'
>>>>>>>>>>>>> aarch64-none-elf-gcc: error: unrecognized command-line option
>> '-
>>>>>> mno-
>>>>>>>>>>>> unaligned-access'
>>>>>>>>>>>>> /home/pliops/workspace/simplest-linux-
>>>>>>>>>>>> demo/barebox/scripts/Makefile.build:140: recipe for target
>>>>>>>>>>>> 'scripts/mod/empty.o' failed
>>>>>>>>>>>>> make[2]: *** [scripts/mod/empty.o] Error 1
>>>>>>>>>>>>>
>>>>>>>>>>>>> Not sure why the compiler flags get -mabi=apcs-gnu when I
>>>> explicitly
>>>>>> set
>>>>>>>>>>>> CONFIG_CPU_V8 and the arch/arm/Makefile has:
>>>>>>>>>>>>> ifeq ($(CONFIG_CPU_V8), y)
>>>>>>>>>>>>> CFLAGS_ABI :=-mabi=lp64
>>>>>>>>>>>>>
>>>>>>>>>>>>> The changes I did:
>>>>>>>>>>>>> >From 848b5f9b18bb1bb96d197cbc1b368ee0a729d581 Mon
>>>> Sep
>>>>>> 17
>>>>>>>>>>>> 00:00:00 2001
>>>>>>>>>>>>> ---
>>>>>>>>>>>>> arch/arm/Kconfig | 13 ++++++++
>>>>>>>>>>>>> arch/arm/Makefile | 1 +
>>>>>>>>>>>>> arch/arm/boards/Makefile | 1 +
>>>>>>>>>>>>> arch/arm/boards/spider-evk/Makefile | 4 +++
>>>>>>>>>>>>> arch/arm/boards/spider-evk/board.c | 26 +++++++++++++++
>>>>>>>>>>>>> arch/arm/boards/spider-evk/lowlevel.c | 30
>> +++++++++++++++++
>>>>>>>>>>>>> arch/arm/configs/spider_defconfig | 8 +++++
>>>>>>>>>>>>> arch/arm/dts/Makefile | 1 +
>>>>>>>>>>>>> arch/arm/dts/spider-mk1-evk.dts | 10 ++++++
>>>>>>>>>>>>> arch/arm/dts/spider-mk1.dtsi | 46
>>>>>>>> +++++++++++++++++++++++++++
>>>>>>>>>>>>> arch/arm/mach-spider/Kconfig | 16 ++++++++++
>>>>>>>>>>>>> arch/arm/mach-spider/Makefile | 1 +
>>>>>>>>>>>>> arch/arm/mach-spider/lowlevel.c | 14 ++++++++
>>>>>>>>>>>>> images/Makefile | 1 +
>>>>>>>>>>>>> images/Makefile.spider | 5 +++
>>>>>>>>>>>>> include/mach/spider/lowlevel.h | 7 ++++
>>>>>>>>>>>>> 16 files changed, 184 insertions(+)
>>>>>>>>>>>>> create mode 100644 arch/arm/boards/spider-evk/Makefile
>>>>>>>>>>>>> create mode 100644 arch/arm/boards/spider-evk/board.c
>>>>>>>>>>>>> create mode 100644 arch/arm/boards/spider-evk/lowlevel.c
>>>>>>>>>>>>> create mode 100644 arch/arm/configs/spider_defconfig create
>>>>>> mode
>>>>>>>>>>>> 100644 arch/arm/dts/spider-mk1-evk.dts create mode 100644
>>>>>>>>>>>> arch/arm/dts/spider-mk1.dtsi create mode 100644
>>>> arch/arm/mach-
>>>>>>>>>>>> spider/Kconfig create mode 100644 arch/arm/mach-
>>>> spider/Makefile
>>>>>>>>>> create
>>>>>>>>>>>> mode 100644 arch/arm/mach-spider/lowlevel.c create mode
>>>> 100644
>>>>>>>>>>>> images/Makefile.spider create mode 100644
>>>>>>>>>> include/mach/spider/lowlevel.h
>>>>>>>>>>>>>
>>>>>>>>>>>>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index
>>>>>>>>>>>> e76ee0f6dfe1..e5dcf128447e 100644
>>>>>>>>>>>>> --- a/arch/arm/Kconfig
>>>>>>>>>>>>> +++ b/arch/arm/Kconfig
>>>>>>>>>>>>> @@ -255,6 +255,18 @@ config ARCH_ROCKCHIP
>>>>>>>>>>>>> select HAS_DEBUG_LL
>>>>>>>>>>>>> imply GPIO_ROCKCHIP
>>>>>>>>>>>>>
>>>>>>>>>>>>> +config ARCH_SPIDER
>>>>>>>>>>>>> + bool "Pliops Spider based"
>>>>>>>>>>>>> + depends on 64BIT
>>>>>>>>>>>>> + depends on ARCH_MULTIARCH
>>>>>>>>>>>>> + select GPIOLIB
>>>>>>>>>>>>> + select HAVE_PBL_MULTI_IMAGES
>>>>>>>>>>>>> + select COMMON_CLK
>>>>>>>>>>>>> + select CLKDEV_LOOKUP
>>>>>>>>>>>>> + select COMMON_CLK_OF_PROVIDER
>>>>>>>>>>>>> + select OFTREE
>>>>>>>>>>>>> + select OFDEVICE
>>>>>>>>>>>>> +
>>>>>>>>>>>>> config ARCH_STM32MP
>>>>>>>>>>>>> bool "STMicroelectronics STM32MP"
>>>>>>>>>>>>> depends on 32BIT
>>>>>>>>>>>>> @@ -331,6 +343,7 @@ source "arch/arm/mach-omap/Kconfig"
>>>>>>>>>>>>> source "arch/arm/mach-pxa/Kconfig"
>>>>>>>>>>>>> source "arch/arm/mach-rockchip/Kconfig"
>>>>>>>>>>>>> source "arch/arm/mach-socfpga/Kconfig"
>>>>>>>>>>>>> +source "arch/arm/mach-spider/Kconfig"
>>>>>>>>>>>>> source "arch/arm/mach-stm32mp/Kconfig"
>>>>>>>>>>>>> source "arch/arm/mach-versatile/Kconfig"
>>>>>>>>>>>>> source "arch/arm/mach-vexpress/Kconfig"
>>>>>>>>>>>>> diff --git a/arch/arm/Makefile b/arch/arm/Makefile index
>>>>>>>>>>>> 35ebc70f44e2..4c63dfee48f4 100644
>>>>>>>>>>>>> --- a/arch/arm/Makefile
>>>>>>>>>>>>> +++ b/arch/arm/Makefile
>>>>>>>>>>>>> @@ -101,6 +101,7 @@ machine-$(CONFIG_ARCH_MXS) +=
>>>> mxs
>>>>>>>>>>>>> machine-$(CONFIG_ARCH_MVEBU) += mvebu
>>>>>>>>>>>>> machine-$(CONFIG_ARCH_NOMADIK) += nomadik
>>>>>>>>>>>>> machine-$(CONFIG_ARCH_OMAP) += omap
>>>>>>>>>>>>> +machine-$(CONFIG_ARCH_SPIDER) += spider
>>>>>>>>>>>>> machine-$(CONFIG_ARCH_PXA) += pxa
>>>>>>>>>>>>> machine-$(CONFIG_ARCH_ROCKCHIP) += rockchip
>>>>>>>>>>>>> machine-$(CONFIG_ARCH_SAMSUNG) += samsung
>>>>>>>>>>>>> diff --git a/arch/arm/boards/Makefile
>>>> b/arch/arm/boards/Makefile
>>>>>>>> index
>>>>>>>>>>>> 2877debad535..6fe0a90c81ea 100644
>>>>>>>>>>>>> --- a/arch/arm/boards/Makefile
>>>>>>>>>>>>> +++ b/arch/arm/boards/Makefile
>>>>>>>>>>>>> @@ -135,6 +135,7 @@ obj-
>>>>>>>>>>>> $(CONFIG_MACH_SOCFPGA_TERASIC_DE10_NANO) +=
>> terasic-
>>>>>>>> de10-
>>>>>>>>>>>> nano/
>>>>>>>>>>>>> obj-$(CONFIG_MACH_SOCFPGA_TERASIC_SOCKIT) +=
>> terasic-
>>>>>>>> sockit/
>>>>>>>>>>>>> obj-$(CONFIG_MACH_SOLIDRUN_CUBOX) += solidrun-
>>>> cubox/
>>>>>>>>>>>>> obj-$(CONFIG_MACH_SOLIDRUN_MICROSOM) +=
>> solidrun-
>>>>>>>>>>>> microsom/
>>>>>>>>>>>>> +obj-$(CONFIG_MACH_SPIDER_MK1_EVK) += spider-evk/
>>>>>>>>>>>>> obj-$(CONFIG_MACH_STM32MP15XX_DKX) +=
>>>>>> stm32mp15xx-
>>>>>>>>>> dkx/
>>>>>>>>>>>>> obj-$(CONFIG_MACH_STM32MP13XX_DK) +=
>>>> stm32mp13xx-
>>>>>>>> dk/
>>>>>>>>>>>>> obj-$(CONFIG_MACH_LXA_MC1) += lxa-mc1/
>>>>>>>>>>>>> diff --git a/arch/arm/boards/spider-evk/Makefile
>>>>>>>>>>>> b/arch/arm/boards/spider-evk/Makefile
>>>>>>>>>>>>> new file mode 100644
>>>>>>>>>>>>> index 000000000000..da63d2625f7a
>>>>>>>>>>>>> --- /dev/null
>>>>>>>>>>>>> +++ b/arch/arm/boards/spider-evk/Makefile
>>>>>>>>>>>>> @@ -0,0 +1,4 @@
>>>>>>>>>>>>> +# SPDX-License-Identifier: GPL-2.0-only
>>>>>>>>>>>>> +
>>>>>>>>>>>>> +obj-y += board.o
>>>>>>>>>>>>> +lwl-y += lowlevel.o
>>>>>>>>>>>>> diff --git a/arch/arm/boards/spider-evk/board.c
>>>>>>>>>> b/arch/arm/boards/spider-
>>>>>>>>>>>> evk/board.c
>>>>>>>>>>>>> new file mode 100644
>>>>>>>>>>>>> index 000000000000..3920e83b457d
>>>>>>>>>>>>> --- /dev/null
>>>>>>>>>>>>> +++ b/arch/arm/boards/spider-evk/board.c
>>>>>>>>>>>>> @@ -0,0 +1,26 @@
>>>>>>>>>>>>> +#include <bbu.h>
>>>>>>>>>>>>> +#include <boot.h>
>>>>>>>>>>>>> +#include <bootm.h>
>>>>>>>>>>>>> +#include <common.h>
>>>>>>>>>>>>> +#include <deep-probe.h>
>>>>>>>>>>>>> +#include <environment.h>
>>>>>>>>>>>>> +#include <fcntl.h>
>>>>>>>>>>>>> +#include <globalvar.h>
>>>>>>>>>>>>> +
>>>>>>>>>>>>> +static int spider_board_probe(struct device *dev) {
>>>>>>>>>>>>> + /* Do some board-specific setup */
>>>>>>>>>>>>> + return 0;
>>>>>>>>>>>>> +}
>>>>>>>>>>>>> +
>>>>>>>>>>>>> +static const struct of_device_id spider_board_of_match[] = {
>>>>>>>>>>>>> + { .compatible = "pliops,spider-mk1-evk" },
>>>>>>>>>>>>> + { /* sentinel */ },
>>>>>>>>>>>>> +};
>>>>>>>>>>>>> +
>>>>>>>>>>>>> +static struct driver spider_board_driver = {
>>>>>>>>>>>>> + .name = "board-spider",
>>>>>>>>>>>>> + .probe = spider_board_probe,
>>>>>>>>>>>>> + .of_compatible = spider_board_of_match, };
>>>>>>>>>>>>> +device_platform_driver(spider_board_driver);
>>>>>>>>>>>>> diff --git a/arch/arm/boards/spider-evk/lowlevel.c
>>>>>>>>>>>> b/arch/arm/boards/spider-evk/lowlevel.c
>>>>>>>>>>>>> new file mode 100644
>>>>>>>>>>>>> index 000000000000..e36fcde4208e
>>>>>>>>>>>>> --- /dev/null
>>>>>>>>>>>>> +++ b/arch/arm/boards/spider-evk/lowlevel.c
>>>>>>>>>>>>> @@ -0,0 +1,30 @@
>>>>>>>>>>>>> +#include <common.h>
>>>>>>>>>>>>> +#include <asm/barebox-arm.h>
>>>>>>>>>>>>> +#include <mach/spider/lowlevel.h>
>>>>>>>>>>>>> +
>>>>>>>>>>>>> +#define BASE_ADDR (0xD000307000)
>>>>>>>>>>>>> +#define GPRAM_ADDR (0xC000000000)
>>>>>>>>>>>>> +#define MY_STACK_TOP (0xC000000000 + SZ_2M) // Set the
>>>> stack
>>>>>>>>>> 2MB
>>>>>>>>>>>> from GPRAM start (excatly in the middle)
>>>>>>>>>>>>> +static inline void spider_serial_putc(void *base, int c) {
>>>>>>>>>>>>> +// if (!(readl(base + UCR1) & UCR1_UARTEN))
>>>>>>>>>>>>> +// return;
>>>>>>>>>>>>> +//
>>>>>>>>>>>>> +// while (!(readl(base + USR2) & USR2_TXDC));
>>>>>>>>>>>>> +//
>>>>>>>>>>>>> +// writel(c, base + URTX0);
>>>>>>>>>>>>> +}
>>>>>>>>>>>>> +
>>>>>>>>>>>>> +ENTRY_FUNCTION_WITHSTACK(start_spider_mk1_evk,
>>>>>>>> MY_STACK_TOP,
>>>>>>>>>>>> r0, r1,
>>>>>>>>>>>>> +r2) {
>>>>>>>>>>>>> + extern char __dtb_spider_mk1_evk_start[];
>>>>>>>>>>>>> +
>>>>>>>>>>>>> + spider_lowlevel_init();
>>>>>>>>>>>>> +
>>>>>>>>>>>>> + relocate_to_current_adr();
>>>>>>>>>>>>> + setup_c();
>>>>>>>>>>>>> +
>>>>>>>>>>>>> + pbl_set_putc(spider_serial_putc, (void *)BASE_ADDR);
>>>>>>>>>>>>> +
>>>>>>>>>>>>> + barebox_arm_entry(GPRAM_ADDR, SZ_2M,
>>>>>>>>>>>>> +__dtb_spider_mk1_evk_start); }
>>>>>>>>>>>>> diff --git a/arch/arm/configs/spider_defconfig
>>>>>>>>>>>> b/arch/arm/configs/spider_defconfig
>>>>>>>>>>>>> new file mode 100644
>>>>>>>>>>>>> index 000000000000..c91bb889d97f
>>>>>>>>>>>>> --- /dev/null
>>>>>>>>>>>>> +++ b/arch/arm/configs/spider_defconfig
>>>>>>>>>>>>> @@ -0,0 +1,8 @@
>>>>>>>>>>>>> +CONFIG_ARCH_SPIDER=y
>>>>>>>>>>>>> +CONFIG_MACH_SPIDER_MK1_EVK=y
>>>>>>>>>>>>> +CONFIG_BOARD_ARM_GENERIC_DT=y
>>>>>>>>>>>>> +CONFIG_MALLOC_TLSF=y
>>>>>>>>>>>>> +CONFIG_KALLSYMS=y
>>>>>>>>>>>>> +CONFIG_RELOCATABLE=y
>>>>>>>>>>>>> +CONFIG_CONSOLE_ALLOW_COLOR=y
>>>>>>>>>>>>> +CONFIG_PBL_CONSOLE=y
>>>>>>>>>>>>> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
>> index
>>>>>>>>>>>> 98f4c4e0194b..94b304d4878f 100644
>>>>>>>>>>>>> --- a/arch/arm/dts/Makefile
>>>>>>>>>>>>> +++ b/arch/arm/dts/Makefile
>>>>>>>>>>>>> @@ -134,6 +134,7 @@ lwl-
>> $(CONFIG_MACH_SOLIDRUN_CUBOX)
>>>>>> +=
>>>>>>>>>> dove-
>>>>>>>>>>>> cubox-bb.dtb.o
>>>>>>>>>>>>> lwl-$(CONFIG_MACH_SOLIDRUN_MICROSOM) += imx6dl-
>>>>>>>>>>>> hummingboard.dtb.o imx6q-hummingboard.dtb.o \
>>>>>>>>>>>>> imx6dl-hummingboard2.dtb.o imx6q-
>>>>>>>>>>>> hummingboard2.dtb.o \
>>>>>>>>>>>>> imx6q-h100.dtb.o
>>>>>>>>>>>>> +lwl-$(CONFIG_MACH_SPIDER_MK1_EVK) += spider-mk1-
>>>> evk.dtb.o
>>>>>>>>>>>>> lwl-$(CONFIG_MACH_SKOV_IMX6) += imx6s-skov-imx6.dtb.o
>>>>>> imx6dl-
>>>>>>>>>> skov-
>>>>>>>>>>>> imx6.dtb.o imx6q-skov-imx6.dtb.o
>>>>>>>>>>>>> lwl-$(CONFIG_MACH_SKOV_ARM9CPU) += at91-skov-
>>>>>> arm9cpu.dtb.o
>>>>>>>>>>>>> lwl-$(CONFIG_MACH_SEEED_ODYSSEY) += stm32mp157c-
>>>>>>>> odyssey.dtb.o
>>>>>>>>>>>> diff --git a/arch/arm/dts/spider-mk1-evk.dts
>>>> b/arch/arm/dts/spider-
>>>>>>>> mk1-
>>>>>>>>>>>> evk.dts new file mode 100644 index
>>>> 000000000000..b8081cb85bf8
>>>>>>>>>>>>> --- /dev/null
>>>>>>>>>>>>> +++ b/arch/arm/dts/spider-mk1-evk.dts
>>>>>>>>>>>>> @@ -0,0 +1,10 @@
>>>>>>>>>>>>> +// SPDX-License-Identifier: GPL-2.0 OR X11
>>>>>>>>>>>>> +
>>>>>>>>>>>>> +/dts-v1/;
>>>>>>>>>>>>> +
>>>>>>>>>>>>> +#include "spider-mk1.dtsi"
>>>>>>>>>>>>> +
>>>>>>>>>>>>> +/ {
>>>>>>>>>>>>> + model = "Pliops Spider MK-I EVK";
>>>>>>>>>>>>> + compatible = "pliops,spider-mk1-evk"; };
>>>>>>>>>>>>> diff --git a/arch/arm/dts/spider-mk1.dtsi
>> b/arch/arm/dts/spider-
>>>>>>>> mk1.dtsi
>>>>>>>>>>>> new file mode 100644 index 000000000000..d4613848169d
>>>>>>>>>>>>> --- /dev/null
>>>>>>>>>>>>> +++ b/arch/arm/dts/spider-mk1.dtsi
>>>>>>>>>>>>> @@ -0,0 +1,46 @@
>>>>>>>>>>>>> +// SPDX-License-Identifier: GPL-2.0 OR X11
>>>>>>>>>>>>> +
>>>>>>>>>>>>> +/ {
>>>>>>>>>>>>> + #address-cells = <2>;
>>>>>>>>>>>>> + #size-cells = <2>;
>>>>>>>>>>>>> +
>>>>>>>>>>>>> + chosen {
>>>>>>>>>>>>> + stdout-path = &uart0;
>>>>>>>>>>>>> + };
>>>>>>>>>>>>> +
>>>>>>>>>>>>> + aliases {
>>>>>>>>>>>>> + serial0 = &uart0;
>>>>>>>>>>>>> + };
>>>>>>>>>>>>> +
>>>>>>>>>>>>> + cpus {
>>>>>>>>>>>>> + #address-cells = <1>;
>>>>>>>>>>>>> + #size-cells = <0>;
>>>>>>>>>>>>> +
>>>>>>>>>>>>> + cpu0: cpu@0 {
>>>>>>>>>>>>> + device_type = "cpu";
>>>>>>>>>>>>> + compatible = "arm,cortex-a53";
>>>>>>>>>>>>> + reg = <0x0>;
>>>>>>>>>>>>> + };
>>>>>>>>>>>>> + };
>>>>>>>>>>>>> +
>>>>>>>>>>>>> + memory@1000000 {
>>>>>>>>>>>>> + reg = <0x0 0x1000000 0x0 0x400000>; /* 128M */
>>>>>>>>>>>>> + device_type = "memory";
>>>>>>>>>>>>> + };
>>>>>>>>>>>>> +
>>>>>>>>>>>>> + soc {
>>>>>>>>>>>>> + #address-cells = <2>;
>>>>>>>>>>>>> + #size-cells = <2>;
>>>>>>>>>>>>> + ranges;
>>>>>>>>>>>>> +
>>>>>>>>>>>>> + sram@c000000000 {
>>>>>>>>>>>>> + compatible = "mmio-sram";
>>>>>>>>>>>>> + reg = <0xc0 0x0 0x0 0x400000>;
>>>>>>>>>>>>> + };
>>>>>>>>>>>>> +
>>>>>>>>>>>>> + uart0: serial@d000307000 {
>>>>>>>>>>>>> + compatible = "pliops,spider-uart";
>>>>>>>>>>>>> + reg = <0xd0 0x307000 0 0x1000>;
>>>>>>>>>>>>> + };
>>>>>>>>>>>>> + };
>>>>>>>>>>>>> +};
>>>>>>>>>>>>> diff --git a/arch/arm/mach-spider/Kconfig b/arch/arm/mach-
>>>>>>>>>> spider/Kconfig
>>>>>>>>>>>> new file mode 100644 index 000000000000..6d2f888a5fd8
>>>>>>>>>>>>> --- /dev/null
>>>>>>>>>>>>> +++ b/arch/arm/mach-spider/Kconfig
>>>>>>>>>>>>> @@ -0,0 +1,16 @@
>>>>>>>>>>>>> +# SPDX-License-Identifier: GPL-2.0-only
>>>>>>>>>>>>> +
>>>>>>>>>>>>> +if ARCH_SPIDER
>>>>>>>>>>>>> +
>>>>>>>>>>>>> +config ARCH_SPIDER_MK1
>>>>>>>>>>>>> + bool
>>>>>>>>>>>>> + select CPU_V8
>>>>>>>>>>>>> + help
>>>>>>>>>>>>> + The first Cortex-A53-based SoC of the spider family.
>>>>>>>>>>>>> + This symbol is invisble and select by boards
>>>>>>>>>>>>> +
>>>>>>>>>>>>> +config MACH_SPIDER_MK1_EVK
>>>>>>>>>>>>> + bool "Pliops Spider Reference Design Board"
>>>>>>>>>>>>> + select ARCH_SPIDER_MK1
>>>>>>>>>>>>> +
>>>>>>>>>>>>> +endif
>>>>>>>>>>>>> diff --git a/arch/arm/mach-spider/Makefile b/arch/arm/mach-
>>>>>>>>>>>> spider/Makefile new file mode 100644 index
>>>>>>>>>> 000000000000..b08c4a93ca27
>>>>>>>>>>>>> --- /dev/null
>>>>>>>>>>>>> +++ b/arch/arm/mach-spider/Makefile
>>>>>>>>>>>>> @@ -0,0 +1 @@
>>>>>>>>>>>>> +lwl-y += lowlevel.o
>>>>>>>>>>>>> diff --git a/arch/arm/mach-spider/lowlevel.c b/arch/arm/mach-
>>>>>>>>>>>> spider/lowlevel.c new file mode 100644 index
>>>>>>>>>>>> 000000000000..5d62ef0f39e5
>>>>>>>>>>>>> --- /dev/null
>>>>>>>>>>>>> +++ b/arch/arm/mach-spider/lowlevel.c
>>>>>>>>>>>>> @@ -0,0 +1,14 @@
>>>>>>>>>>>>> +// SPDX-License-Identifier: GPL-2.0+
>>>>>>>>>>>>> +
>>>>>>>>>>>>> +#include <linux/types.h>
>>>>>>>>>>>>> +#include <mach/spider/lowlevel.h>
>>>>>>>>>>>>> +#include <asm/barebox-arm-head.h>
>>>>>>>>>>>>> +
>>>>>>>>>>>>> +void spider_lowlevel_init(void)
>>>>>>>>>>>>> +{
>>>>>>>>>>>>> + arm_cpu_lowlevel_init();
>>>>>>>>>>>>> + /*
>>>>>>>>>>>>> + * not yet relocated, only do writel/readl for stuff that's
>>>>>>>>>>>>> + * critical to run early. No global variables allowed.
>>>>>>>>>>>>> + */
>>>>>>>>>>>>> +}
>>>>>>>>>>>>> diff --git a/images/Makefile b/images/Makefile index
>>>>>>>>>>>> c93f9e268978..97521e713228 100644
>>>>>>>>>>>>> --- a/images/Makefile
>>>>>>>>>>>>> +++ b/images/Makefile
>>>>>>>>>>>>> @@ -150,6 +150,7 @@ include $(srctree)/images/Makefile.mxs
>>>>>>>> include
>>>>>>>>>>>> $(srctree)/images/Makefile.omap3 include
>>>>>>>>>>>> $(srctree)/images/Makefile.rockchip
>>>>>>>>>>>>> include $(srctree)/images/Makefile.socfpga
>>>>>>>>>>>>> +include $(srctree)/images/Makefile.spider
>>>>>>>>>>>>> include $(srctree)/images/Makefile.stm32mp
>>>>>>>>>>>>> include $(srctree)/images/Makefile.tegra include
>>>>>>>>>>>> $(srctree)/images/Makefile.versatile
>>>>>>>>>>>>> diff --git a/images/Makefile.spider b/images/Makefile.spider
>> new
>>>> file
>>>>>>>>>> mode
>>>>>>>>>>>> 100644 index 000000000000..c32f2762df04
>>>>>>>>>>>>> --- /dev/null
>>>>>>>>>>>>> +++ b/images/Makefile.spider
>>>>>>>>>>>>> @@ -0,0 +1,5 @@
>>>>>>>>>>>>> +# SPDX-License-Identifier: GPL-2.0-only
>>>>>>>>>>>>> +
>>>>>>>>>>>>> +pblb-$(CONFIG_MACH_SPIDER_MK1_EVK) +=
>>>>>> start_spider_mk1_evk
>>>>>>>>>>>>> +FILE_barebox-spider-mk1-evk.img =
>> start_spider_mk1_evk.pblb
>>>>>>>>>>>>> +image-$(CONFIG_MACH_SPIDER_MK1_EVK) += barebox-
>> spider-
>>>>>> mk1-
>>>>>>>>>>>> evk.img
>>>>>>>>>>>>> diff --git a/include/mach/spider/lowlevel.h
>>>>>>>>>>>> b/include/mach/spider/lowlevel.h new file mode 100644 index
>>>>>>>>>>>> 000000000000..6e0ce1c77f7e
>>>>>>>>>>>>> --- /dev/null
>>>>>>>>>>>>> +++ b/include/mach/spider/lowlevel.h
>>>>>>>>>>>>> @@ -0,0 +1,7 @@
>>>>>>>>>>>>> +/* SPDX-License-Identifier: GPL-2.0+ */ #ifndef
>>>> __MACH_SPIDER_H_
>>>>>>>>>>>>> +#define __MACH_SPIDER_H_
>>>>>>>>>>>>> +
>>>>>>>>>>>>> +void spider_lowlevel_init(void);
>>>>>>>>>>>>> +
>>>>>>>>>>>>> +#endif
>>>>>>>>>>>>> --
>>>>>>>>>>>>> 2.38.4
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Pengutronix e.K. | |
>>>>>>>>>>>> Steuerwalder Str. 21 | http://www.pengutronix.de/ |
>>>>>>>>>>>> 31137 Hildesheim, Germany | Phone: +49-5121-
>> 206917-0
>>>>>> |
>>>>>>>>>>>> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-
>> 206917-
>>>>>> 5555
>>>>>>>> |
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Pengutronix e.K. | |
>>>>>>>>>> Steuerwalder Str. 21 | http://www.pengutronix.de/ |
>>>>>>>>>> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0
>>>> |
>>>>>>>>>> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-
>>>> 5555
>>>>>> |
>>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Pengutronix e.K. | |
>>>>>>>> Steuerwalder Str. 21 | http://www.pengutronix.de/ |
>>>>>>>> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0
>> |
>>>>>>>> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-
>> 5555
>>>> |
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Pengutronix e.K. | |
>>>>>> Steuerwalder Str. 21 | http://www.pengutronix.de/ |
>>>>>> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
>>>>>> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555
>> |
>>>>>
>>>>
>>>> --
>>>> Pengutronix e.K. | |
>>>> Steuerwalder Str. 21 | http://www.pengutronix.de/ |
>>>> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
>>>> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
>>>
>>
>> --
>> Pengutronix e.K. | |
>> Steuerwalder Str. 21 | http://www.pengutronix.de/ |
>> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
>> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
>
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply [flat|nested] 40+ messages in thread
* RE: [PATCH v2] Porting barebox to a new SoC
2023-06-06 14:34 ` Ahmad Fatoum
@ 2023-06-12 9:27 ` Lior Weintraub
2023-06-12 12:28 ` Ahmad Fatoum
0 siblings, 1 reply; 40+ messages in thread
From: Lior Weintraub @ 2023-06-12 9:27 UTC (permalink / raw)
To: Ahmad Fatoum, Ahmad Fatoum, barebox
Hi Ahmad,
Regarding the rootfs and Linux run question:
Our board doesn't include eMMC\SD card.
We only have our NOR Flash to store the binaries and our BL1 code will make sure to copy those blobs into DRAM.
The use of QEMU needs to be as simple as possible so no hidden virtio drivers and such because we would like to simulate the real HW flow.
Our DTS file now includes the GIC, timer and arm,psci-1.0.
We have an initial build of Linux kernel Image (using buildroot) and a rootfs.cpio.xz.
I assume we can somehow reserve a portion of the DRAM to store those binaries and let barebox boot this Linux.
Can you please advise how to make it work?
Thanks again for your kind support,
Cheers,
Lior.
> -----Original Message-----
> From: Ahmad Fatoum <a.fatoum@pengutronix.de>
> Sent: Tuesday, June 6, 2023 5:35 PM
> To: Lior Weintraub <liorw@pliops.com>; Ahmad Fatoum <ahmad@a3f.at>;
> barebox@lists.infradead.org
> Subject: Re: [PATCH v2] Porting barebox to a new SoC
>
> CAUTION: External Sender
>
> Hello Lior,
>
> On 06.06.23 14:54, Lior Weintraub wrote:
> > Hello Ahmad,
> >
> > I managed to build a bl31.bin file from TF-A.
> > This is just a preliminary implementation (basically all functions I had to
> implement are empty) so I'm hoping it will allow running a bare minimum
> initial Linux kernel.
>
> As long as the TF-A implements the informational parts (e.g. PSCI_VERSION),
> I think that should be ok.
>
> > I tried to follow how imx8mq-bl31.bin was added into barebox and I think I
> got it right.
> > I have several indications that the BL31 is behaving as expected.
>
> Nice. A simple sanity check would be to implement SYSTEM_RESET and call it
> from
> barebox using the PSCI client reset driver.
>
> > The initial implementation (without BL31) was running PBL from SRAM
> (address 0xC0_0000_0000),
> > decompressed barebox into DRAM (@ 0x07E0_0000) and jumped to
> barebox.
> > From ARM registers inspection we can see that we are @ EL3
> >
> > Now with the inclusion of BL31, it starts @ SRAM (as before) but then test
> that we are in EL3 and if so,
> > copy full image (PBL+Barebox) into DRAM address 0x0800_0000,
>
> Sounds good.
>
> > copy BL31.bin into DRAM address 0x1000_0000 and jumps there.
>
> You can do that, but keep in mind that BL31 will always be invoked at EL3,
> so you'll want to use hardware mechanisms to ensure that you can't
> just overwrite it from lower exception levels.
>
> If you have a DDR firewall, you could place it into DDR, but I'd suggest
> just keeping it in SRAM. That way you only need to configure your address
> space controller so SRAM is secure-world only. This also simplifies later
> logic, because you no longer need to mark the DDR region where TF-A is as
> reserved. (If you don't do that, you risk Linux accessing it, which can lead
> to crashes).
>
> > The execution of BL31 does its thing and then sets execution level to EL2 and
> jumps to DRAM address 0x0800_0000 (hard coded address we used on BL31
> TF-A compilation).
>
> That's fine. I'd just jump to address 0 though if that's the start of your DRAM.
>
> > We now see the PBL starts running again (now from DRAM), skips the BL31
> loading (because it sees that we are not in EL3) and continue as before.
>
> Sounds good.
>
> > PBL decompressed barebox into DRAM address 0x07E0_0000 and jump to
> barebox.
>
> Sounds even better.
>
> > From ARM registers inspection we can see that we are @ EL2
>
> Nice. :-)
>
> > Few questions:
> > 1. Any comments or thoughts about the above flow?
>
> See above, but sounds good overall.
>
> > 2. Are we ready now to try loading kernel and rootfs? If so how?
>
> Did you already flesh out your DT? It needs to contain GIC, timer
> and arm,psci-1.0 at the very least. Then you need a boot medium.
>
> If it's something like eMMC, you can configure QEMU to provide
> a memory-mapped SD/MMC controller and enable the driver for that
> in barebox. If it's something more esoteric, you can just use
> virtio block or cfi-flash, both of which are supported in barebox
> and QEMU and are in used with the default QEMU virt machine.
>
> Assuming you have a file system in a virtio block device and you
> have enabled it on QEMU side with virtio-mmio transport and
> barebox has the relevant virtio-mmio node in its device tree,
> you can then boot with:
>
> global.linux.bootargs.earlycon=earlycon
> bootm -o /mnt/virtioblk0.0/boot/mydevicetree.dtb \
> -r /mnt/virtioblk0.0/boot/myinitrd.img
> /mnt/virtioblk0.0/boot/mykernel.gz
>
> (Don't forget to add stdout-path = &uart to your DT, so kernel can
> find the console to use with earlycon)
>
> If you aren't familiar with virtioblk or cfi-flash try building barebox
> for multi_v8_defconfig and then start it in QEMU to play around with it:
>
> qemu-system-aarch64 -M virt,highmem=off -cpu cortex-a57 -m 1024M -
> kernel build/images/barebox-dt-2nd.img \
> -serial mon:stdio -trace file=/dev/null -nographic
>
> > 3. Is it OK (or even recommended) to change BL31 so that it will enter EL1
> instead of EL2 (as we do not plan to use virtualization).
>
> Always enter kernel at EL2. Let Linux worry about going from EL2 to EL1
>
> > Thanks again for your kind support,
> > Cheers,
> > Lior.
>
> Cheers,
> Ahmad
>
> >
> >
> >> -----Original Message-----
> >> From: Ahmad Fatoum <a.fatoum@pengutronix.de>
> >> Sent: Thursday, June 1, 2023 3:36 PM
> >> To: Lior Weintraub <liorw@pliops.com>; Ahmad Fatoum <ahmad@a3f.at>;
> >> barebox@lists.infradead.org
> >> Subject: Re: [PATCH v2] Porting barebox to a new SoC
> >>
> >> CAUTION: External Sender
> >>
> >> Hello Lior,
> >>
> >> On 01.06.23 13:45, Lior Weintraub wrote:
> >>> Hello Ahmad,
> >>>
> >>> Very interesting stuff.
> >>>
> >>> We actually did started TF-A integration few months ago and tested it on
> the
> >> QEMU running ARM virt machine.
> >>> The TF-A compilation didn't include BL31 image (probably this explains the
> >> "ERROR: BL2: Failed to load image id 3").
> >>
> >> I wouldn't recommend using TF-A as BL2. I am quite content with how
> >> it's done on NXP's i.MX SoCs, which is the flow I described at the
> >> end of my last mail. Instead of loading a FIP, TF-A would just
> >> return to DRAM (or maintain LR on TF-A entry and return to it).
> >>
> >>> For this code to run we used the following QEMU command:
> >>>
> >>> qemu-system-aarch64 -nographic -machine virt,secure=on -cpu cortex-
> >> a53,rvbar=0x0000000000 \
> >>> -smp 1 -m 1024 -bios bl1.bin -d unimp -semihosting-config
> >> enable=on,target=native \
> >>> -monitor telnet:localhost:1235,server,nowait -gdb tcp::1236
> >>>
> >>> Output:
> >>> NOTICE: bl1_early_platform_set
> >>> NOTICE: Booting Trusted Firmware
> >>> NOTICE: BL1: v2.7(debug):831de6588
> >>> NOTICE: BL1: Built : 12:40:08, May 28 2023
> >>> INFO: BL1: RAM 0xe0ee000 - 0xe0f6000
> >>> INFO: BL1: cortex_a53: CPU workaround for 835769 was applied
> >>> INFO: BL1: cortex_a53: CPU workaround for 843419 was applied
> >>> INFO: BL1: cortex_a53: CPU workaround for 855873 was applied
> >>> INFO: BL1: cortex_a53: CPU workaround for 1530924 was applied
> >>> INFO: BL1: Loading BL2
> >>> WARNING: Firmware Image Package header check failed.
> >>> INFO: Loading image id=1 at address 0xe07b000
> >>> INFO: Image id=1 loaded: 0xe07b000 - 0xe081201
> >>> NOTICE: BL1: Booting BL2
> >>> INFO: Entry point address = 0xe07b000
> >>> INFO: SPSR = 0x3c5
> >>> NOTICE: BL2: v2.7(debug):831de6588
> >>> NOTICE: BL2: Built : 12:40:08, May 28 2023
> >>> INFO: BL2: Doing platform setup
> >>> INFO: BL2: Loading image id 3
> >>> WARNING: Firmware Image Package header check failed.
> >>> WARNING: Failed to obtain reference to image id=3 (-2)
> >>> ERROR: BL2: Failed to load image id 3 (-2)
> >>>
> >>> When we tried to modify the TF-A code to use our SoC (e.g. change the
> start
> >> address to 0xC0_0400_0000 and use UART on 0xD0_0030_7000) it
> crashed
> >> with seg. Fault.
> >>
> >> Try building your BL31 as position-independent executable. The code doing
> >> fixed text area may be hardcoded to 32-bit. See here for an example
> >> of turning on PIE:
> >>
> >> https://ddec1-0-en-
> >>
> ctp.trendmicro.com:443/wis/clicktime/v1/query?url=https%3a%2f%2freview
> >>
> .trustedfirmware.org%2fc%2fTF%2dA%2ftrusted%2dfirmware%2da%2f%2b
> >> %2f16370&umid=0b12ecfc-4ee1-4f0b-90e0-
> >> 54ceaf590ca1&auth=860a7ebb9feba264acc79b6e38eb59582349362c-
> >> c3cc24ae937d0a564120b663c7b93f60c48f01b5
> >>
> >>> We didn't continue with this development effort and decided we will write
> >> our own BootROM as BL1
> >>
> >> Ye, I don't think TF-A is a good candidate for a BL1 (are there even
> >> other users that user TF-A that way?).
> >>
> >>> and use that to load u-boot or barebox
> >>
> >> That's ok. You just need BL31 to provide you runtime services (or maintain
> >> your
> >> Linux SoC support patches for ever).
> >>
> >>> Now I understand we better go back and study how to port TF-A to our
> SoC.
> >>
> >> :)
> >>
> >> Cheers,
> >> Ahmad
> >>
> >>>
> >>> Cheers,
> >>> Lior.
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: Ahmad Fatoum <a.fatoum@pengutronix.de>
> >>>> Sent: Thursday, June 1, 2023 12:29 PM
> >>>> To: Lior Weintraub <liorw@pliops.com>; Ahmad Fatoum
> <ahmad@a3f.at>;
> >>>> barebox@lists.infradead.org
> >>>> Subject: Re: [PATCH v2] Porting barebox to a new SoC
> >>>>
> >>>> CAUTION: External Sender
> >>>>
> >>>> Hello Lior,
> >>>>
> >>>> On 01.06.23 10:54, Lior Weintraub wrote:
> >>>>> Hi Ahmad,
> >>>>>
> >>>>> Thanks again for your great support and the patch.
> >>>>> I've checked it and it works perfectly!
> >>>>> The UART issue was solved after fixing the device tree per your
> >>>> recommendations.
> >>>>> Now I can write into barbox terminal :-)
> >>>>
> >>>> Nice!
> >>>>
> >>>>> When I type "cpuinfo" on the terminal I am getting:
> >>>>> implementer: ARM
> >>>>> architecture: v8
> >>>>> core: Cortex-A53 r0p4
> >>>>> exception level: 3
> >>>>> cache: no cache
> >>>>> Control register: P D Z DT IT U XP
> >>>>
> >>>> FYI, barebox next (or maybe master?) branch adds mmuinfo command
> to
> >>>> arm64.
> >>>> You can use that to check if a specific address is cached or not.
> >>>>
> >>>>> Notice that it say "no cache".
> >>>>> I tried to add cache to cpu0 but it didn't help.
> >>>>>
> >>>>> .
> >>>>> .
> >>>>> d-cache-size = <0x8000>;
> >>>>> d-cache-line-size = <64>;
> >>>>> d-cache-sets = <128>; // 32KiB(size)/64(line-size)=512ways/4-way set
> >>>>> i-cache-size = <0x8000>;
> >>>>> i-cache-line-size = <64>;
> >>>>> i-cache-sets = <256>; // 32KiB(size)/64(line-size)=512ways/2-way set
> >>>>> next-level-cache = <&l2>;
> >>>>> };
> >>>>>
> >>>>> l2: l2-cache0 {
> >>>>> compatible = "cache";
> >>>>> cache-unified;
> >>>>> cache-size = <0x80000>;
> >>>>> cache-line-size = <64>;
> >>>>> cache-sets = <512>; // 512KiB(size)/64(line-size)=8192ways/16-way
> set
> >>>>> cache-level = <2>;
> >>>>> }
> >>>>
> >>>> barebox doesn't consume these nodes. What may be happening is that
> >>>> cpuinfo
> >>>> was written with the assumption that barebox executes at EL2 or EL1, so
> >>>> executing it at EL3 may end up accessing the wrong MSRs. Feel free to
> send
> >>>> a patch against arch/arm/cpu/cpuinfo.c, so it uses the correct register for
> >>>> EL3. current_el() will tell you which EL you are at.
> >>>>
> >>>>> Regarding Linux kernel:
> >>>>> This would be the next step but I assume that it would be a bit more
> >>>> complicated.
> >>>>
> >>>> Linux ARM64 Maintainers mandate that platforms implement the PSCI
> >>>> protocol.
> >>>> In your case with single core that means providing reset and poweroff
> >>>> handlers
> >>>> that the kernel can invoke via secure monitor call.
> >>>>
> >>>> barebox can consume psci: CONFIG_ARM_PSCI_CLIENT,
> >> CONFIG_CMD_SMC,
> >>>> but what
> >>>> you're missing is the provider side. barebox as PSCI provider is
> implemented
> >>>> only for a single ARM32 SoC, the i.MX7. All supported ARM64 platforms
> >> use
> >>>> TF-A as BL31 with the exception of Layerscape (which uses PPA, an NXP
> >> BL31
> >>>> implementation).
> >>>>
> >>>> What does this mean for you?
> >>>>
> >>>> 1) Either add your SoC to TF-A
> >>>> 2) Extend PSCI implementation in barebox for ARM64.
> >>>>
> >>>> While I think it would be cool to have barebox provide all of BL2, BL31
> and
> >>>> BL32, I think you are better advised to use TF-A, because that's what
> most
> >>>> other ARM Silicon Vendors use. That means less effort for you and easier
> >>>> maintenance as you benefit from fixes done for other SoCs using the
> same
> >>>> IPs. barebox certainly benefits from being able to focus on being a
> >> bootloader
> >>>> and leaving the errata workarounds, GIC init stuff and runtime services
> >>>> to TF-A.
> >>>>
> >>>> The boot flow would then be:
> >>>>
> >>>> - barebox PBL runs as BL2 in SRAM and sets up DRAM
> >>>> - barebox PBL executes BL31 (TF-A) which was compiled into PBL
> >>>> - TF-A installs secure monitor and returns control to DRAM in EL2
> >>>> - barebox resumes execution in EL2 as BL33
> >>>> - Linux is invoked in EL2 and can communicate with secure monitor.
> >>>>
> >>>> You may find this talk interesting:
> >>>> https://fosdem.org/2023/schedule/event/uboot_psci/
> >>>> Even if I disagree a bit with the takeaway.
> >>>>
> >>>>> I guess we will have to integrate the interrupt controlled (GIC-600) into
> >>>> QEMU and into the device tree for it to work.
> >>>>> Is that a valid assumption?
> >>>>
> >>>> I never had to add a new SoC to Linux, so I can't give any better
> >>>> suggestions than Yes. Where you're going, you'll need interrupts.
> >>>>
> >>>> Godspeed and keep me posted :)
> >>>> Ahmad
> >>>>
> >>>>>
> >>>>> Thanks,
> >>>>> Lior.
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: Ahmad Fatoum <a.fatoum@pengutronix.de>
> >>>>>> Sent: Wednesday, May 31, 2023 8:55 PM
> >>>>>> To: Lior Weintraub <liorw@pliops.com>; Ahmad Fatoum
> >> <ahmad@a3f.at>;
> >>>>>> barebox@lists.infradead.org
> >>>>>> Subject: Re: [PATCH v2] Porting barebox to a new SoC
> >>>>>>
> >>>>>> CAUTION: External Sender
> >>>>>>
> >>>>>> Hi Lior,
> >>>>>>
> >>>>>> On 31.05.23 18:13, Lior Weintraub wrote:
> >>>>>>> Hi Ahmad,
> >>>>>>>
> >>>>>>> Using end of SRAM as PBL stack is currently not working because we
> >> need
> >>>>>> 40bit address (0xC0_0020_0000).
> >>>>>>> This needs a fix to ENTRY_FUNCTION_WITHSTACK macro.
> >>>>>>
> >>>>>> Ah, right. I just sent an (untested) patch. Would be cool if you could
> >>>>>> try it out.
> >>>>>>
> >>>>>>> I tried just to change const u32 __stack_top = (stack_top); to const
> u64
> >>>>>> __stack_top = (stack_top); but there were linking errors caused by:
> >>>>>>> ASSERT(. - __pbl_board_stack_top <= 8, "Only One PBL per Image
> >>>> allowed")
> >>>>>>
> >>>>>> The easy way would have been using a __attribute__((naked))
> function,
> >>>> but
> >>>>>> those are only supported for arm32, not arm64. The alternative is thus
> >>>>>> writing the entry point in assembly and to make board authors life
> easier
> >>>>>> the linker script ensures that the stack setup entry point is invoked
> prior
> >>>>>> to the board entry.
> >>>>>>
> >>>>>>> Regarding the arm timer:
> >>>>>>> Adding the timer entry to DT solved the issue.
> >>>>>>>
> >>>>>>> Regarding the UART:
> >>>>>>> Indeed CONFIG_SERIAL_AMBA_PL011 was set on spider_defconfig
> >> (also
> >>>>>> verified it generated the correct entry on .config).
> >>>>>>> I also noticed that if I remove the putc_ll implementation there is no
> Tx
> >> at
> >>>> all
> >>>>>> from Barebox.
> >>>>>>
> >>>>>> I've led you astray. Indeed:
> >>>>>>
> >>>>>>>>> of_platform_bus_create() - skipping /soc, no compatible prop
> >>>>>>
> >>>>>> points at the issue.
> >>>>>>
> >>>>>> Try adding into /soc
> >>>>>>
> >>>>>> compatible = "simple,bus";
> >>>>>> ranges;
> >>>>>> dma-ranges;
> >>>>>>
> >>>>>> This matches /soc with the simple bus driver which just instantiates
> >> devices
> >>>>>> for the
> >>>>>> contained children. Those in turn should be matched by the drivers.
> >>>>>>
> >>>>>> The ranges stuff just tells that memory and SoC peripherals exist in the
> >>>> same
> >>>>>> address space.
> >>>>>>
> >>>>>> When it probes you may need to describe the clock in the DT.
> Eventually,
> >>>> you
> >>>>>> will
> >>>>>> want to have a clock driver for your hardware (good news: barebox
> and
> >>>> Linux
> >>>>>> have
> >>>>>> basically the same API, so you only need to write it once). But for now,
> >> you
> >>>>>> can
> >>>>>> fake it using fixed-clock in the DT. Take a look at:
> >>>>>>
> >>>>>> snps,dw-apb-uart in arch/riscv/dts/jh7100.dtsi and compare with
> >>>>>> dts/src/arm/imx28.dtsi
> >>>>>> to see how to map that to PL011.
> >>>>>>
> >>>>>>> Could it be a hint?
> >>>>>>
> >>>>>> DEBUG_LL bridges the gap until a driver registers a console that's
> >> enabled. If
> >>>>>> this
> >>>>>> never happens, you are left with a non-interactive shell.
> >>>>>>
> >>>>>> Cheers,
> >>>>>> Ahmad
> >>>>>>
> >>>>>>>
> >>>>>>> Thanks,
> >>>>>>> Lior.
> >>>>>>>
> >>>>>>>> -----Original Message-----
> >>>>>>>> From: Ahmad Fatoum <a.fatoum@pengutronix.de>
> >>>>>>>> Sent: Wednesday, May 31, 2023 11:40 AM
> >>>>>>>> To: Lior Weintraub <liorw@pliops.com>; Ahmad Fatoum
> >>>> <ahmad@a3f.at>;
> >>>>>>>> barebox@lists.infradead.org
> >>>>>>>> Subject: Re: [PATCH v2] Porting barebox to a new SoC
> >>>>>>>>
> >>>>>>>> CAUTION: External Sender
> >>>>>>>>
> >>>>>>>> Hi Lior,
> >>>>>>>>
> >>>>>>>> On 31.05.23 10:05, Lior Weintraub wrote:
> >>>>>>>>> Hi Ahmad,
> >>>>>>>>>
> >>>>>>>>> Thanks again for your prompt reply and accurate tips!
> >>>>>>>>> Took the following changes:
> >>>>>>>>> 1. Increasing the DRAM size to 128MB (let barebox start from 0).
> >>>>>>>>> 2. Set PBL stack to offset 2MB from DRAM
> >>>>>>>>
> >>>>>>>> Just use end of SRAM, so you are completely independent of DRAM
> >>>>>>>> until you call barebox_arm_entry.
> >>>>>>>>
> >>>>>>>>> 3. Fix the device tree "memory" entry to have 128MB.
> >>>>>>>>
> >>>>>>>> (y)
> >>>>>>>>
> >>>>>>>>> 4. Load barebox-spider-mk1-evk.img to SRAM and run from there.
> >>>>>>>>>
> >>>>>>>>> Now I can see the following logs:
> >>>>>>>>> uncompress.c: memory at 0x00000000, size 0x08000000
> >>>>>>>>> uncompress.c: uncompressing barebox binary at
> >> 0x000000c0000021c0
> >>>>>>>> (size 0x0001e3a4) to 0x07e00000 (uncompressed size:
> 0x000390d0)
> >>>>>>>>> uncompress.c: jumping to uncompressed image at
> >>>>>> 0x0000000007e00000
> >>>>>>>>> start.c: memory at 0x00000000, size 0x08000000
> >>>>>>>>> start.c: found DTB in boarddata, copying to 0x07dffcc0
> >>>>>>>>> start.c: initializing malloc pool at 0x079ffcc0 (size 0x00400000)
> >>>>>>>>> start.c: starting barebox...
> >>>>>>>>> initcall-> command_slice_init+0x0/0x3c
> >>>>>>>>> initcall-> globalvar_init+0x0/0x80
> >>>>>>>>> register_device: global
> >>>>>>>>> register_device: nv
> >>>>>>>>> initcall-> platform_init+0x0/0x1c
> >>>>>>>>> register_device: platform
> >>>>>>>>> initcall-> amba_bus_init+0x0/0x1c
> >>>>>>>>> register_device: amba
> >>>>>>>>> initcall-> spi_bus_init+0x0/0x1c
> >>>>>>>>> register_device: spi
> >>>>>>>>> initcall-> gpio_desc_alloc+0x0/0x24
> >>>>>>>>> initcall-> fs_bus_init+0x0/0x1c
> >>>>>>>>> register_device: fs
> >>>>>>>>> initcall-> aarch64_init_vectors+0x0/0x50
> >>>>>>>>> initcall-> gpio_gate_clock_driver_register+0x0/0x1c
> >>>>>>>>> register_driver: gpio-gate-clock
> >>>>>>>>> initcall-> of_arm_init+0x0/0x5c
> >>>>>>>>> start.c: barebox_arm_boot_dtb: using barebox_boarddata
> >>>>>>>>> using boarddata provided DTB
> >>>>>>>>> adding DT alias:serial0: stem=serial id=0
> >>>> node=/soc/serial@d000307000
> >>>>>>>>> register_device: machine
> >>>>>>>>> of_platform_bus_create() - skipping /chosen, no compatible prop
> >>>>>>>>> of_platform_bus_create() - skipping /aliases, no compatible prop
> >>>>>>>>> of_platform_bus_create() - skipping /cpus, no compatible prop
> >>>>>>>>> of_platform_bus_create() - skipping /memory@0, no compatible
> >> prop
> >>>>>>>>> of_platform_bus_create() - skipping /soc, no compatible prop
> >>>>>>>>> initcall-> register_autoboot_vars+0x0/0x70
> >>>>>>>>> initcall-> arm_arch_timer_driver_register+0x0/0x1c
> >>>>>>>>> register_driver: arm-architected-timer
> >>>>>>>>> initcall-> of_timer_init+0x0/0x20
> >>>>>>>>> initcall-> init_fs+0x0/0x3c
> >>>>>>>>> initcall-> pl011_driver_register+0x0/0x1c
> >>>>>>>>> register_driver: uart-pl011
> >>>>>>>>> initcall-> of_stdoutpath_init+0x0/0x28
> >>>>>>>>> initcall-> of_probe_memory+0x0/0x60
> >>>>>>>>> __request_region ok: 0x00000000:0x07ffffff flags=0x0
> >>>>>>>>> initcall-> __bare_init_end+0x0/0x6c
> >>>>>>>>> register_device: mem0
> >>>>>>>>> initcall-> of_reserved_mem_walk+0x0/0x1ac
> >>>>>>>>> initcall-> mem_malloc_resource+0x0/0xa8
> >>>>>>>>> __request_region ok: 0x079ffcc0:0x07dffcbf flags=0x200
> >>>>>>>>> __request_region ok: 0x07e00000:0x07e2aeff flags=0x200
> >>>>>>>>> __request_region ok: 0x07e2af00:0x07e390cf flags=0x200
> >>>>>>>>> __request_region ok: 0x07e390d0:0x07e3adaf flags=0x200
> >>>>>>>>> initcall-> bootsource_init+0x0/0x40
> >>>>>>>>> initcall-> ramfs_init+0x0/0x1c
> >>>>>>>>> register_driver: ramfs
> >>>>>>>>> initcall-> devfs_init+0x0/0x1c
> >>>>>>>>> register_driver: devfs
> >>>>>>>>> initcall-> arm_request_stack+0x0/0x398
> >>>>>>>>> __request_region ok: 0x07ff0000:0x07ff7fff flags=0x200
> >>>>>>>>> initcall-> mount_root+0x0/0x7c
> >>>>>>>>> mount: none on / type ramfs, options=
> >>>>>>>>> register_device: ramfs0
> >>>>>>>>> probe-> ramfs0
> >>>>>>>>> mount: none on /dev type devfs, options=
> >>>>>>>>> register_device: devfs0
> >>>>>>>>> probe-> devfs0
> >>>>>>>>> initcall-> binfmt_sh_init+0x0/0x1c
> >>>>>>>>> initcall-> binfmt_uimage_init+0x0/0x1c
> >>>>>>>>> initcall-> console_common_init+0x0/0x48
> >>>>>>>>> initcall-> of_kernel_init+0x0/0x28
> >>>>>>>>> initcall-> console_ctrlc_init+0x0/0x30
> >>>>>>>>> initcall-> mem_init+0x0/0x90
> >>>>>>>>> register_device: mem1
> >>>>>>>>> register_driver: mem
> >>>>>>>>> probe-> mem0
> >>>>>>>>> probe-> mem1
> >>>>>>>>> initcall-> of_partition_init+0x0/0x48
> >>>>>>>>> initcall-> prng_init+0x0/0x40
> >>>>>>>>> initcall-> null_init+0x0/0x40
> >>>>>>>>> initcall-> full_init+0x0/0x40
> >>>>>>>>> initcall-> zero_init+0x0/0x40
> >>>>>>>>> initcall-> spider_board_driver_register+0x0/0x1c
> >>>>>>>>> register_driver: board-spider
> >>>>>>>>> probe-> machine
> >>>>>>>>> initcall-> barebox_memory_areas_init+0x0/0x40
> >>>>>>>>> __request_region ok: 0x07dffcc0:0x07dfffce flags=0x200
> >>>>>>>>> initcall-> barebox_of_populate+0x0/0x28
> >>>>>>>>> initcall-> of_register_memory_fixup+0x0/0x20
> >>>>>>>>> initcall-> dummy_csrc_warn+0x0/0x44
> >>>>>>>>> WARNING: Warning: Using dummy clocksource
> >>>>>>>>
> >>>>>>>> Add a arm,armv8-timer node into your SoC device tree.
> >>>>>>>> This lets barebox and Linux know that you have the ARM
> >>>>>>>> architected timer available. Without that, you'll notice
> >>>>>>>> that timeouts are wrong.
> >>>>>>>>
> >>>>>>>>> initcall-> bootm_init+0x0/0xf4
> >>>>>>>>> initcall-> init_command_list+0x0/0x40
> >>>>>>>>> register command bootm
> >>>>>>>>> register command cat
> >>>>>>>>> register command cd
> >>>>>>>>> register command clear
> >>>>>>>>> register command cp
> >>>>>>>>> register command cpuinfo
> >>>>>>>>> register command devinfo
> >>>>>>>>> register command drvinfo
> >>>>>>>>> register command echo
> >>>>>>>>> register command exit
> >>>>>>>>> register command false
> >>>>>>>>> register command help
> >>>>>>>>> register command ?
> >>>>>>>>> register command ll
> >>>>>>>>> register command ls
> >>>>>>>>> register command md
> >>>>>>>>> register command memcmp
> >>>>>>>>> register command memcpy
> >>>>>>>>> register command memset
> >>>>>>>>> register command mkdir
> >>>>>>>>> register command mount
> >>>>>>>>> register command mw
> >>>>>>>>> register command pwd
> >>>>>>>>> register command rm
> >>>>>>>>> register command rmdir
> >>>>>>>>> register command setenv
> >>>>>>>>> register command sh
> >>>>>>>>> register command source
> >>>>>>>>> register command .
> >>>>>>>>> register command test
> >>>>>>>>> register command [
> >>>>>>>>> register command true
> >>>>>>>>> register command :
> >>>>>>>>> register command umount
> >>>>>>>>> register command version
> >>>>>>>>> initcall-> display_meminfo+0x0/0xa8
> >>>>>>>>> barebox code: 0x7e00000 -> 0x7e2aeff
> >>>>>>>>> bss segment: 0x7e390d0 -> 0x7e3adaf
> >>>>>>>>> malloc space: 0x079ffcc0 -> 0x07dffcbf (size 4 MiB)
> >>>>>>>>> initcall-> of_register_bootargs_fixup+0x0/0x3c
> >>>>>>>>> initcall-> device_probe_deferred+0x0/0x14c
> >>>>>>>>> initcall-> of_init_hostname+0x0/0x28
> >>>>>>>>> initcall-> aarch64_register_image_handler+0x0/0x2c
> >>>>>>>>> initcall-> load_environment+0x0/0x4c
> >>>>>>>>> loading defaultenv
> >>>>>>>>> environment load /dev/env0: No such file or directory
> >>>>>>>>> Maybe you have to create the partition.
> >>>>>>>>> initcalls done
> >>>>>>>>>
> >>>>>>>>> Hit any to stop autoboot: 0
> >>>>>>>>> boot: No such file or directory
> >>>>>>>>> barebox:/
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Few questions:
> >>>>>>>>> 1. The serial input doesn't work. i.e. I cannot type anything hence
> >>>> cannot
> >>>>>>>> interact with barebox terminal.
> >>>>>>>>
> >>>>>>>> DEBUG_LL only does otuput. For input, you will want to load the
> >> driver.
> >>>>>>>> Do you have CONFIG_SERIAL_AMBA_PL011 enabled?
> >>>>>>>>
> >>>>>>>>> Does it require GIC and setting interrupts for it to work?
> >>>>>>>>
> >>>>>>>> No interrupts needed. barebox runs with interrupts disabled and
> >>>>>> everything
> >>>>>>>> is done cooperatively.
> >>>>>>>>
> >>>>>>>>> 2. What does "of_platform_bus_create() - skipping" means? Do I
> >> need
> >>>> to
> >>>>>> fix
> >>>>>>>> that?
> >>>>>>>>
> >>>>>>>> That's normal debugging output. Some device tree nodes are
> busses,
> >>>> which
> >>>>>>>> have
> >>>>>>>> children. These entries are skipped because they have no
> compatible.
> >>>> This is
> >>>>>>>> expected. I'd suggest you remove your VERBOSED_DEBUG define, so
> >> you
> >>>>>> are
> >>>>>>>> not
> >>>>>>>> spammed by too much debugging output.
> >>>>>>>>
> >>>>>>>>> 3. Looks like I am still missing some stuff (rootfs? Environment?
> >>>>>> Mounting?
> >>>>>>>> Partitions?)
> >>>>>>>>
> >>>>>>>> Take multi_v8_defconfig, open menuconfig and enable your SoC
> and
> >> use
> >>>>>> that.
> >>>>>>>> That will be quicker than enabling everything yourself. If it doesn't
> >> work
> >>>>>>>> out of the box, try imx_v8_defconfig.
> >>>>>>>>
> >>>>>>>> Once you get around to upstreaming your SoC, I'd suggest you just
> >> add it
> >>>>>>>> to multi_v8_defconfig. Not all ARMv8 SoCs are supported there, but
> >>>> those
> >>>>>>>> that are make development easier, because we don't need to build
> as
> >>>> many
> >>>>>>>> different configs..
> >>>>>>>>
> >>>>>>>> Cheers,
> >>>>>>>> Ahmad
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Thanks,
> >>>>>>>>> Have a great day,
> >>>>>>>>> Lior.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> -----Original Message-----
> >>>>>>>>>> From: Ahmad Fatoum <a.fatoum@pengutronix.de>
> >>>>>>>>>> Sent: Wednesday, May 31, 2023 9:11 AM
> >>>>>>>>>> To: Lior Weintraub <liorw@pliops.com>; Ahmad Fatoum
> >>>>>> <ahmad@a3f.at>;
> >>>>>>>>>> barebox@lists.infradead.org
> >>>>>>>>>> Subject: Re: [PATCH v2] Porting barebox to a new SoC
> >>>>>>>>>>
> >>>>>>>>>> CAUTION: External Sender
> >>>>>>>>>>
> >>>>>>>>>> Hi Lior,
> >>>>>>>>>>
> >>>>>>>>>> On 30.05.23 22:10, Lior Weintraub wrote:
> >>>>>>>>>>> Hello Ahmad,
> >>>>>>>>>>>
> >>>>>>>>>>> Thanks again for your kind support!
> >>>>>>>>>>> Your comments helped me progress and the current situation is
> as
> >>>>>>>> follows:
> >>>>>>>>>>> Our QEMU Spider machine is running a BL1.elf file using the
> >> following
> >>>>>>>>>> command:
> >>>>>>>>>>> QEMU_AUDIO_DRV=none qemu-system-aarch64 -M spider-soc
> -
> >>>> smp 1
> >>>>>> -
> >>>>>>>> m
> >>>>>>>>>> 128M -nographic \
> >>>>>>>>>>> -device loader,file=BL1.elf -cpu cortex-
> >> a53,rvbar=0xC004000000 \
> >>>>>>>>>>> -d unimp -semihosting-config enable=on,target=native \
> >>>>>>>>>>> -monitor telnet:localhost:1235,server,nowait \
> >>>>>>>>>>> -gdb tcp::1236
> >>>>>>>>>>>
> >>>>>>>>>>> The BL1.elf is our BootROM application that runs from ROM
> >> address
> >>>>>>>>>> 0xC004000000.
> >>>>>>>>>>> Just for debugging purpose we've increased the ROM size so it
> can
> >>>>>> include
> >>>>>>>>>> the images/barebox-spider-mk1-evk.img (as a const array).
> >>>>>>>>>>> BL1 then copy it (using memcpy) to address 0 and jumps there
> for
> >>>>>>>>>> execution.
> >>>>>>>>>>
> >>>>>>>>>> Sounds ok.
> >>>>>>>>>>
> >>>>>>>>>>> On the real ASIC this address will be the DRAM and indeed will
> need
> >>>> to
> >>>>>> be
> >>>>>>>>>> initialized before the copy but here on QEMU it is not required.
> >>>>>>>>>>
> >>>>>>>>>> I see. You could still have your bootrom move barebox into SRAM
> >> and
> >>>>>> then
> >>>>>>>>>>
> >>>>>>>>>> barebox_arm_entry(DRAM_ADDR, SZ_128M,
> >>>>>>>> __dtb_spider_mk1_evk_start);
> >>>>>>>>>>
> >>>>>>>>>> To have PBL extract barebox to DRAM. Even if you don't need
> need
> >>>>>> DRAM
> >>>>>>>>>> setup in QEMU, the flow would be similar to what you will have
> on
> >>>> actual
> >>>>>>>>>> silicon.
> >>>>>>>>>>
> >>>>>>>>>>> The lowlevel.c of spider-evk was modified to use DRAM_ADDR
> >>>>>> 0x400000
> >>>>>>>>>> (4MB from start) and MY_STACK_TOP was set to 0x8000000
> >> (128M).
> >>>>>>>>>>
> >>>>>>>>>> That's not needed. While you don't have control where barebox
> PBL
> >>>> will
> >>>>>> be
> >>>>>>>>>> located
> >>>>>>>>>> (depends on BootROM), barebox will extract itself to the end of
> >> DRAM
> >>>>>>>>>> without
> >>>>>>>>>> overwriting itself, so you can just use DRAM_ADDR 0 normally.
> >>>>>> Eventually,
> >>>>>>>>>> stack
> >>>>>>>>>> top should go into SRAM, but anywhere that works is ok.
> >>>>>>>>>>
> >>>>>>>>>>> In addition, I implemented putc_ll (currently hard-coded in
> >>>>>>>>>> include/debug_ll.h) and opened log level to VERBOSE_DEBUG
> >>>> (currently
> >>>>>>>> just
> >>>>>>>>>> hard-coded in printk.h).
> >>>>>>>>>>
> >>>>>>>>>> There's CONFIG_DEBUG_PBL you can enable to get all these
> >> messages
> >>>> by
> >>>>>>>>>> default.
> >>>>>>>>>>
> >>>>>>>>>>> I see the following (which makes sense) logs on QEMU terminal:
> >>>>>>>>>>> uncompress.c: memory at 0x00400000, size 0x00200000
> >>>>>>>>>>> uncompress.c: uncompressing barebox binary at
> >>>>>> 0x0000000000002200
> >>>>>>>>>> (size 0x0001d3b2) to 0x00400000 (uncompressed size:
> >> 0x000373d0)
> >>>>>>>>>>
> >>>>>>>>>> Why pass only 2M to barebox_arm_entry? While this need not be
> >> the
> >>>>>>>> whole
> >>>>>>>>>> of RAM, this
> >>>>>>>>>> initial memory is what barebox will use for itself including its final
> >> stack
> >>>>>> and
> >>>>>>>>>> malloc area. barebox will also not place itself into the last 1M
> AFAIK,
> >> so
> >>>>>> 2M
> >>>>>>>>>> may not work ok. You should use the minimum possible RAM
> here
> >> or
> >>>> if
> >>>>>> you
> >>>>>>>>>> can detect
> >>>>>>>>>> in PBL how much RAM you have or just the whole RAM bank. I
> am
> >> not
> >>>>>> sure
> >>>>>>>>>> anything lower
> >>>>>>>>>> than SZ_4M would work ok. (Note this is DRAM size, not SRAM.
> >>>> barebox
> >>>>>>>> PBL
> >>>>>>>>>> is fine being
> >>>>>>>>>> called from 64K SRAMs, it just needs DRAM to extract to).
> >>>>>>>>>>
> >>>>>>>>>>> I then connect with aarch64-none-elf-gdb, load the barebox
> >> symbols
> >>>>>> (to
> >>>>>>>>>> 0x400000) and check the current execution state (program
> counter
> >>>> and
> >>>>>>>>>> stack).
> >>>>>>>>>>> Looks like the code is stuck on function register_autoboot_vars:
> >>>>>>>>>>> sp 0x5f7e60 0x5f7e60
> >>>>>>>>>>> pc 0x401264 0x401264
> <register_autoboot_vars+24>
> >>>>>>>>>>>
> >>>>>>>>>>> Few observations:
> >>>>>>>>>>> 1. The PBL was using stack top located on 0x8000000 (which is
> >>>>>>>>>> MY_STACK_TOP). Found it be causing a breakpoint on the PBL.
> >>>>>>>>>>> 2. Barebox uses a stack top on 0x600000 which is probably
> >> calculated
> >>>>>>>> from
> >>>>>>>>>> my new DRAM_ADDR and SZ_2M given to the function call:
> >>>>>>>>>>> barebox_arm_entry(DRAM_ADDR, SZ_2M,
> >>>>>>>> __dtb_spider_mk1_evk_start);
> >>>>>>>>>>>
> >>>>>>>>>>> This is great! I am starting to find my way.
> >>>>>>>>>>
> >>>>>>>>>> :) Ye, the ENTRY_FUNCTION_WITHSTACK is only when the
> BootROM
> >>>>>>>> doesn't
> >>>>>>>>>> enter
> >>>>>>>>>> with a valid stack pointer. It's overwritten as soon as barebox is
> told
> >>>>>>>>>> about the initial memory layout (with barebox_arm_entry).
> >>>>>>>>>>
> >>>>>>>>>>> When the barebox execution didn't print anything to the terminal
> I
> >>>>>>>>>> remembered that we used a place holder on the dtsi for the uart.
> >>>>>>>>>>> So now I changed it to:
> >>>>>>>>>>> uart0: serial@d000307000 {
> >>>>>>>>>>> compatible = "arm,pl011", "arm,primecell";
> >>>>>>>>>>> reg = <0xd0 0x307000 0 0x1000>;
> >>>>>>>>>>> }
> >>>>>>>>>>> (Our QEMU UART is currently using pl011 device.)
> >>>>>>>>>>
> >>>>>>>>>> Looks ok. Don't forget to enable the driver (via make
> menuconfig).
> >>>>>>>>>>
> >>>>>>>>>>> After some time (trying to debug by enabling MMU but then
> >> reverted
> >>>>>> the
> >>>>>>>>>> code back), I got to a point that when I try to run again I am
> getting
> >> an
> >>>>>>>>>> exception.
> >>>>>>>>>>> I can swear all code changes were reverted back to the point
> where
> >> I
> >>>>>> saw
> >>>>>>>> the
> >>>>>>>>>> barebox stuck on register_autoboot_vars but now it just cases an
> >>>>>>>> exception.
> >>>>>>>>>>> The exception vector code is located on our ROM (part of BL1
> code)
> >>>> and
> >>>>>>>> the
> >>>>>>>>>> logs shows that the link register has the value 0x401218 which
> >> suggest
> >>>>>> the
> >>>>>>>>>> following code:
> >>>>>>>>>>> 0000000000001200 <load_environment>:
> >>>>>>>>>>> 1200: a9be7bfd stp x29, x30, [sp, #-32]!
> >>>>>>>>>>> 1204: 910003fd mov x29, sp
> >>>>>>>>>>> 1208: a90153f3 stp x19, x20, [sp, #16]
> >>>>>>>>>>> 120c: 94000a07 bl 3a28 <default_environment_path_get>
> >>>>>>>>>>> 1210: d00000f3 adrp x19, 1f000 <do_cpuinfo+0x1f0>
> >>>>>>>>>>> 1214: 912a7273 add x19, x19, #0xa9c
> >>>>>>>>>>> 1218: aa0003f4 mov x20, x0
> >>>>>>>>>>>
> >>>>>>>>>>> Any ideas or suggestions how to proceed with the debugging?
> >>>>>>>>>>
> >>>>>>>>>> You shouldn't need to touch the MMU code. If your initial
> memory
> >>>> setup
> >>>>>>>>>> is wonky, you may end up overwriting stuff. Try again with bigger
> >>>>>> memory.
> >>>>>>>>>>
> >>>>>>>>>>> BTW, to answer your questions:
> >>>>>>>>>>> The SRAM of 4MB is the only one we have because we assumed
> it
> >> is
> >>>>>> only
> >>>>>>>> for
> >>>>>>>>>> BootROM to load a PBL
> >>>>>>>>>>
> >>>>>>>>>> Ok. Sometimes there are SRAMs for use with DMA. I asked,
> because
> >> a
> >>>>>>>> SRAM
> >>>>>>>>>> in the first 4M
> >>>>>>>>>> would lend itself nicely as stack, but if there is none, we can adjust
> >>>>>>>>>> ENTRY_FUNCTION_WITHSTACK to accept a 64-bit parameter.
> >>>>>>>>>>
> >>>>>>>>>> Cheers,
> >>>>>>>>>> Ahmad
> >>>>>>>>>>
> >>>>>>>>>>> Thank you very much,
> >>>>>>>>>>> Cheers,
> >>>>>>>>>>> Lior.
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>> -----Original Message-----
> >>>>>>>>>>>> From: Ahmad Fatoum <a.fatoum@pengutronix.de>
> >>>>>>>>>>>> Sent: Monday, May 29, 2023 10:03 PM
> >>>>>>>>>>>> To: Lior Weintraub <liorw@pliops.com>; Ahmad Fatoum
> >>>>>>>> <ahmad@a3f.at>;
> >>>>>>>>>>>> barebox@lists.infradead.org
> >>>>>>>>>>>> Subject: Re: [PATCH v2] Porting barebox to a new SoC
> >>>>>>>>>>>>
> >>>>>>>>>>>> CAUTION: External Sender
> >>>>>>>>>>>>
> >>>>>>>>>>>> Hello Lior,
> >>>>>>>>>>>>
> >>>>>>>>>>>> On 29.05.23 15:34, Lior Weintraub wrote:
> >>>>>>>>>>>>> Hi Ahmad,
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> I have revised the addresses and used DRAM address @ 0
> >> instead:
> >>>>>>>>>>>>> #define UARTBASE (0xD000307000)
> >>>>>>>>>>>>> #define DRAM_ADDR (0x00000000)
> >>>>>>>>>>>>> #define MY_STACK_TOP (0x00000000 + SZ_2M) // Set the
> >> stack
> >>>>>> 2MB
> >>>>>>>>>> from
> >>>>>>>>>>>> DRAM start
> >>>>>>>>>>>>
> >>>>>>>>>>>> Is DRAM configured by the time barebox runs? If not, you
> should
> >>>> keep
> >>>>>>>>>> stack
> >>>>>>>>>>>> top
> >>>>>>>>>>>> in SRAM, until you have setup memory in prebootloader (PBL).
> Is
> >>>> the
> >>>>>> 4M
> >>>>>>>>>>>> SRAM
> >>>>>>>>>>>> the only on-chip SRAM you have?
> >>>>>>>>>>>>
> >>>>>>>>>>>>> static inline void spider_serial_putc(void *base, int c)
> >>>>>>>>>>>>> {
> >>>>>>>>>>>>> *((volatile unsigned *)base) = c;
> >>>>>>>>>>>>
> >>>>>>>>>>>> There's a helper for that: writel(c, base); In barebox, it's
> equivalent
> >>>>>>>>>>>> to the volatile access, but in Linux it involves a write memory
> >> barrier.
> >>>>>>>>>>>> We try to write code in barebox, so it's easily reusable in Linux
> >> (and
> >>>>>>>>>>>> the other way round).
> >>>>>>>>>>>>
> >>>>>>>>>>>>> }
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> I will try to test it on QEMU using an initial QEMU machine we
> >>>> made
> >>>>>> for
> >>>>>>>>>>>> Spider.
> >>>>>>>>>>>>> In this machine we only have 3 memory regions and a PL011
> >> UART:
> >>>>>>>>>>>>> spider_soc_memories soc_memories[] = {
> >>>>>>>>>>>>> {.name = "SPIDER_GPRAM", .add = 0xC000000000ULL,
> .size =
> >> 4
> >>>> *
> >>>>>>>> MiB},
> >>>>>>>>>>>>> {.name = "SPIDER_ROM", .add = 0xC004000000ULL, .size
> =
> >>>> 128 *
> >>>>>>>>>> KiB},
> >>>>>>>>>>>>> {.name = "SPIDER_DRAM", .add = 0x0000000000ULL, .size
> =
> >> 1
> >>>> *
> >>>>>>>> GiB},
> >>>>>>>>>>>>> };
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> This special QEMU machine can run our BL1 code from "ROM"
> >>>>>> address
> >>>>>>>>>> (we
> >>>>>>>>>>>> set the RVBAR to point there).
> >>>>>>>>>>>>> So my idea is to test the barebox image by the following steps:
> >>>>>>>>>>>>> 1. Modify the QEMU code to have a "ROM" with the size of
> >> 128M.
> >>>>>>>>>>>>> 2. Compile our BL1 code to include the barebox.bin as a const
> >>>> array,
> >>>>>>>> copy
> >>>>>>>>>> it
> >>>>>>>>>>>> to "DRAM" @ address 0 and jump there.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Why not map QEMU -bios option to SRAM? (Or DRAM directly,
> if
> >> it
> >>>>>>>> needs
> >>>>>>>>>> no
> >>>>>>>>>>>> special setup from
> >>>>>>>>>>>> barebox side).
> >>>>>>>>>>>>
> >>>>>>>>>>>>> For this to work I wanted to understand how to call (i.e. what
> >>>>>>>> arguments
> >>>>>>>>>> to
> >>>>>>>>>>>> pass) to barebox.
> >>>>>>>>>>>>
> >>>>>>>>>>>> barebox doesn't expect any arguments, because most
> BootROMs
> >>>>>> don't
> >>>>>>>>>> pass
> >>>>>>>>>>>> anything useful.
> >>>>>>>>>>>> Some pass information about bootsource though, so that's
> why
> >> the
> >>>>>>>>>>>> ENTRY_FUNCTION has
> >>>>>>>>>>>> r0, r1 and r2 as parameters, but you need not use them.
> >>>>>>>>>>>>
> >>>>>>>>>>>>> So I checked the barebox.map and found the function "start"
> on
> >>>>>>>> address
> >>>>>>>>>> 0.
> >>>>>>>>>>>>
> >>>>>>>>>>>> You may know that Linux on some platforms comes with a
> >>>>>> decompressor
> >>>>>>>>>> that
> >>>>>>>>>>>> is glued to the
> >>>>>>>>>>>> front of the kernel image and extracts the compressed kernel
> >> image.
> >>>>>>>>>> barebox
> >>>>>>>>>>>> has the same
> >>>>>>>>>>>> concept. The prebootloader is uncompressed and runs (starting
> >>>> from
> >>>>>>>>>>>> ENTRY_FUNCTION) and
> >>>>>>>>>>>> then does some early setup (e.g. enable clocks, configure PMIC,
> >>>> setup
> >>>>>>>>>> DRAM,
> >>>>>>>>>>>> load secure
> >>>>>>>>>>>> monitor (BL31), ...etc.) and then it decompresses barebox
> proper
> >>>> into
> >>>>>>>>>> DRAM.
> >>>>>>>>>>>>
> >>>>>>>>>>>> barebox.bin <- barebox proper. You don't usually need that.
> >>>>>>>>>>>> barebox.elf <- ELF binary for the above (for gdb)
> >>>>>>>>>>>> barebox.map <- map file of the above
> >>>>>>>>>>>>
> >>>>>>>>>>>> images/barebox-spider-mk1-evk.img <- complete barebox
> image
> >>>> (PBL
> >>>>>> +
> >>>>>>>>>>>> barebox proper)
> >>>>>>>>>>>> images/start_spider_mk1_evk.pbl <- ELF image for the above
> >>>>>>>>>>>> images/start_spider_mk1_evk.pbl.map <- map file of the above
> >>>>>>>>>>>>
> >>>>>>>>>>>> If you want to follow barbeox from the start, begin at
> >>>>>>>>>> start_spider_mk1_evk.
> >>>>>>>>>>>>
> >>>>>>>>>>>>> Then I went to arch/arm/cpu/start.c and realized that the code
> is
> >>>>>>>> compiled
> >>>>>>>>>>>> with CONFIG_PBL_IMAGE.
> >>>>>>>>>>>>> In that case I assume I need to pass 3 arguments and use this
> >>>>>> function
> >>>>>>>>>>>> prototype:
> >>>>>>>>>>>>> void start(unsigned long membase, unsigned long memsize,
> void
> >>>>>>>>>>>> *boarddata);
> >>>>>>>>>>>>
> >>>>>>>>>>>> barebox prebootloader takes care of this, so you don't need to
> do
> >>>>>>>> anything.
> >>>>>>>>>>>>
> >>>>>>>>>>>>> Few questions:
> >>>>>>>>>>>>> 1. Will that call work:
> >>>>>>>>>>>>> typedef void (*barebox_start)(unsigned long , unsigned long
> ,
> >>>> void
> >>>>>> *);
> >>>>>>>>>>>>> #define DRAM_START (0)
> >>>>>>>>>>>>> barebox_start p_barebox = (barebox_start)DRAM_START;
> >>>>>>>>>>>>> p_barebox(DRAM_START, DRAM_START+SZ_2M, (void
> >>>>>>>>>>>> *)(DRAM_START+SZ_4M));
> >>>>>>>>>>>>> This assumes that my BL1 code also copied the device tree
> >>>>>> (barebox-
> >>>>>>>> dt-
> >>>>>>>>>>>> 2nd.img? start_dt_2nd.pblb? start_spider_mk1_evk.pblb?)
> >>>>>>>>>>>>
> >>>>>>>>>>>> The device tree is built into the PBL and passed to barebox
> proper.
> >>>> This
> >>>>>>>>>>>> allows us to use the same barebox proper binary and link it with
> a
> >>>>>>>> different
> >>>>>>>>>>>> prebootloader for each SoC/board, all in the same build.
> >>>>>>>>>>>>
> >>>>>>>>>>>> barebox-dt-2nd.img is a special image that looks exactly like a
> >> Linux
> >>>>>>>> kernel:
> >>>>>>>>>>>>
> >>>>>>>>>>>> images/barebox-dt-2nd.img: Linux kernel ARM64 boot
> >> executable
> >>>>>>>> Image,
> >>>>>>>>>>>> little-endian, 4K pages
> >>>>>>>>>>>>
> >>>>>>>>>>>> and can thus be used for booting for easy chainloading from
> other
> >>>>>>>>>>>> bootloaders or for running
> >>>>>>>>>>>> with QEMU -kernel. You shouldn't need it right now.
> >>>>>>>>>>>>
> >>>>>>>>>>>>> 2. Do I want to have my code compiled with
> >> CONFIG_PBL_IMAGE?
> >>>>>>>>>>>>> If I understand correctly, it means that my code will provide
> a
> >> PBL
> >>>>>>>> (a.k.a
> >>>>>>>>>>>> BL2) which will set the DRAM and STACK among other things
> >>>> (MMU?).
> >>>>>>>>>>>>
> >>>>>>>>>>>> The patch I sent already builds a PBL. You will need to fill out
> >>>>>>>>>>>> start_spider_mk1_evk
> >>>>>>>>>>>> to do all the other early initialization you need. Then you call
> >>>>>>>>>>>> barebox_arm_entry
> >>>>>>>>>>>> with device tree and memory size and it will take care to do
> stack
> >>>> setup
> >>>>>> in
> >>>>>>>>>> new
> >>>>>>>>>>>> memory region, MMU setup (if enabled) and chainloading
> >> barebox
> >>>>>>>> proper.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Note that PBL isn't necessary BL2. You can chainload barebox
> >> from
> >>>>>> within
> >>>>>>>>>>>> barebox (i.e.
> >>>>>>>>>>>> in EL2 or EL1), which is useful for debugging. You will thus often
> >> find
> >>>>>> PBL
> >>>>>>>>>> code
> >>>>>>>>>>>> that
> >>>>>>>>>>>> does
> >>>>>>>>>>>>
> >>>>>>>>>>>> if (current_el() == 3) {
> >>>>>>>>>>>> /* Do BL2 setup */
> >>>>>>>>>>>> chainload();
> >>>>>>>>>>>> __builtin_unreachable();
> >>>>>>>>>>>> }
> >>>>>>>>>>>>
> >>>>>>>>>>>> barebox_arm_entry(...)
> >>>>>>>>>>>>
> >>>>>>>>>>>> See for example arch/arm/boards/innocomm-imx8mm-
> >>>>>> wb15/lowlevel.c
> >>>>>>>>>>>>
> >>>>>>>>>>>> to see a real-world example of another Cortex-A53.
> >>>>>>>>>>>>
> >>>>>>>>>>>>> In that case I assume it is OK.
> >>>>>>>>>>>>> 3. If I try to remove it by having CONFIG_PBL_IMAGE=n on
> >>>>>>>>>> spider_defconfig
> >>>>>>>>>>>> this doesn't do anything
> >>>>>>>>>>>>> The build (make spider_defconfig) ignores it and say that "
> No
> >>>>>> change
> >>>>>>>> to
> >>>>>>>>>>>> .config ".
> >>>>>>>>>>>>
> >>>>>>>>>>>> Another symbol forces it to be enabled. If you are curious, run
> >> make
> >>>>>>>>>>>> menuconfig
> >>>>>>>>>>>> and then search (/) for the symbol and it will list, whether it's
> >>>> enabled
> >>>>>>>> and
> >>>>>>>>>>>> why:
> >>>>>>>>>>>>
> >>>>>>>>>>>> Selected by [y]:
> >>>>>>>>>>>> - PBL_MULTI_IMAGES [=y] && HAVE_PBL_MULTI_IMAGES
> [=y]
> >>>>>>>>>>>>
> >>>>>>>>>>>> I'd suggest you avoid modifying the .config file manually.
> always
> >> use
> >>>>>>>>>>>> menuconfig.
> >>>>>>>>>>>>
> >>>>>>>>>>>>> 4. I also tried to understand how to implement PUTC_LL but
> not
> >>>> sure
> >>>>>> I
> >>>>>>>>>>>> understand.
> >>>>>>>>>>>>> 4.1 When I set "CONFIG_DEBUG_LL=y" on spider_defconfig it
> is
> >>>>>> again
> >>>>>>>>>> not
> >>>>>>>>>>>> written to .config and I get " No change to .config " message.
> >>>>>>>>>>>>
> >>>>>>>>>>>> You must:
> >>>>>>>>>>>>
> >>>>>>>>>>>> - select HAS_DEBUG_LL from MACH_SPIDER
> >>>>>>>>>>>> - Add your arch to arch/arm/include/asm/debug_ll.h
> >>>>>>>>>>>> - Then implement PUTC_LL in e.g. mach/spider/debug_ll.h
> >>>>>>>>>>>>
> >>>>>>>>>>>>> 4.2 Do I need to have my own debug_ll.h file?
> >>>>>>>>>>>>
> >>>>>>>>>>>> Yes. See above.
> >>>>>>>>>>>>
> >>>>>>>>>>>>> 5. When I make changes to spider_defconfig and try to
> >> regenerate
> >>>>>> the
> >>>>>>>>>>>> .config and I get " No change to .config " message, does it mean
> >> that
> >>>>>>>> those
> >>>>>>>>>>>> macros are "hidden" symbols like you said about the
> >>>>>> CONFIG_CPU_V8?
> >>>>>>>>>>>>
> >>>>>>>>>>>> Yes. Just check menuconfig to see how symbols relate to each
> >> other.
> >>>>>>>>>>>> This is 1:1 like it's in Linux, so it'll come in handy when you do
> >>>>>>>>>>>> the kernel port too ;)
> >>>>>>>>>>>>
> >>>>>>>>>>>>> Apologize for so many questions :-)
> >>>>>>>>>>>>
> >>>>>>>>>>>> No problem. Looking forward to your patches ;)
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> Cheers,
> >>>>>>>>>>>> Ahmad
> >>>>>>>>>>>>
> >>>>>>>>>>>>> Cheers,
> >>>>>>>>>>>>> Lior.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> -----Original Message-----
> >>>>>>>>>>>>> From: Lior Weintraub
> >>>>>>>>>>>>> Sent: Sunday, May 28, 2023 11:16 PM
> >>>>>>>>>>>>> To: Ahmad Fatoum <ahmad@a3f.at>;
> >> barebox@lists.infradead.org
> >>>>>>>>>>>>> Subject: RE: [PATCH v2] Porting barebox to a new SoC
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Hi Ahmad,
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Thank you so much for your kind support!
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Indeed we also have a 16GB DRAM that starts from address 0
> >>>>>> (though
> >>>>>>>>>>>> currently we don't have the controller settings (under
> >>>> development)).
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> I also wrote the BootROM (BL1) for this SoC (128KB ROM @
> >>>> address
> >>>>>>>>>>>> 0xC004000000).
> >>>>>>>>>>>>> I understand now that it would be best for me to develop BL2
> >> that
> >>>>>> will
> >>>>>>>> run
> >>>>>>>>>>>> from our SRAM.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> As this BL2 code is bare-metal I have no problem or limitations
> >> with
> >>>>>> the
> >>>>>>>> 40
> >>>>>>>>>>>> bit addresses.
> >>>>>>>>>>>>> The BL2 code will initialize the DRAM controller and then copy
> >>>>>> Barebox
> >>>>>>>>>> image
> >>>>>>>>>>>> from NOR Flash to address 0 of the DRAM.
> >>>>>>>>>>>>> Our NOR Flash is 128MB in size and it is accessed via QSPI
> >>>> controller.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> I tried applying your suggested patch but got an error while
> >> doing
> >>>> so:
> >>>>>>>>>>>>> $git apply 0002-Ahmad.patch
> >>>>>>>>>>>>> 0002-Ahmad.patch:115: trailing whitespace.
> >>>>>>>>>>>>> .of_compatible = spider_board_of_match, };
> >>>>>>>>>>>>> error: corrupt patch at line 117
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> After some digging I found that my Outlook probably messed
> >> with
> >>>>>> the
> >>>>>>>>>> patch
> >>>>>>>>>>>> format (even though I am using text only and no HTML format).
> >>>>>>>>>>>>> When I went to the web and copied the patch from there
> >> (mailing
> >>>> list
> >>>>>>>>>>>> archive) it was working well (i.e. no compilation error).
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Cheers,
> >>>>>>>>>>>>> Lior.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> -----Original Message-----
> >>>>>>>>>>>>> From: Ahmad Fatoum <ahmad@a3f.at>
> >>>>>>>>>>>>> Sent: Sunday, May 28, 2023 6:38 PM
> >>>>>>>>>>>>> To: barebox@lists.infradead.org
> >>>>>>>>>>>>> Cc: Lior Weintraub <liorw@pliops.com>
> >>>>>>>>>>>>> Subject: [PATCH v2] Porting barebox to a new SoC
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> CAUTION: External Sender
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> From: Lior Weintraub <liorw@pliops.com>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Hi,
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> I tried to follow the porting guide on https://ddec1-0-en-
> >>>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>
> >>
> ctp.trendmicro.com:443/wis/clicktime/v1/query?url=https%3a%2f%2fwww.
> >>>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>
> >>
> barebox.org%2fdoc%2flatest%2fdevel%2fporting.html%23&umid=60097eda
> >>>>>>>>>>>> -f136-45a1-9c8e-
> >>>>>>>>>>>>
> >>>>>>
> cf6a76e45cf8&auth=860a7ebb9feba264acc79b6e38eb59582349362c-
> >>>>>>>>>>>> 480ae23736add41c88ab8d30c090a75517ca7f9e but couldn't
> >>>> follow
> >>>>>>>> the
> >>>>>>>>>>>> instructions.
> >>>>>>>>>>>>> I would like to port barebox to a new SoC (which is not a
> >> derivative
> >>>> of
> >>>>>>>> any
> >>>>>>>>>>>> known SoC).
> >>>>>>>>>>>>> It has the following:
> >>>>>>>>>>>>> * Single Cortex A53
> >>>>>>>>>>>>> * SRAM (4MB) located on address 0xC000000000
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> The below patch shows my initial test to try and have a
> starting
> >>>> point.
> >>>>>>>>>>>>> I am setting env variables:
> >>>>>>>>>>>>> export ARCH=arm64
> >>>>>>>>>>>>> export
> CROSS_COMPILE=/home/pliops/workspace/ARM/arm-
> >>>> gnu-
> >>>>>>>>>>>> toolchain/bin/aarch64-none-elf-
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Then I build with:
> >>>>>>>>>>>>> make spider_defconfig && make
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> This gives an error:
> >>>>>>>>>>>>> aarch64-none-elf-gcc: error: unrecognized argument in option
> '-
> >>>>>>>>>> mabi=apcs-
> >>>>>>>>>>>> gnu'
> >>>>>>>>>>>>> aarch64-none-elf-gcc: note: valid arguments to '-mabi=' are:
> >> ilp32
> >>>>>> lp64
> >>>>>>>>>>>>> aarch64-none-elf-gcc: error: unrecognized command-line
> option
> >> '-
> >>>>>>>> msoft-
> >>>>>>>>>>>> float'
> >>>>>>>>>>>>> aarch64-none-elf-gcc: error: unrecognized command-line
> option
> >> '-
> >>>>>> mno-
> >>>>>>>>>>>> unaligned-access'
> >>>>>>>>>>>>> /home/pliops/workspace/simplest-linux-
> >>>>>>>>>>>> demo/barebox/scripts/Makefile.build:140: recipe for target
> >>>>>>>>>>>> 'scripts/mod/empty.o' failed
> >>>>>>>>>>>>> make[2]: *** [scripts/mod/empty.o] Error 1
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Not sure why the compiler flags get -mabi=apcs-gnu when I
> >>>> explicitly
> >>>>>> set
> >>>>>>>>>>>> CONFIG_CPU_V8 and the arch/arm/Makefile has:
> >>>>>>>>>>>>> ifeq ($(CONFIG_CPU_V8), y)
> >>>>>>>>>>>>> CFLAGS_ABI :=-mabi=lp64
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> The changes I did:
> >>>>>>>>>>>>> >From 848b5f9b18bb1bb96d197cbc1b368ee0a729d581
> Mon
> >>>> Sep
> >>>>>> 17
> >>>>>>>>>>>> 00:00:00 2001
> >>>>>>>>>>>>> ---
> >>>>>>>>>>>>> arch/arm/Kconfig | 13 ++++++++
> >>>>>>>>>>>>> arch/arm/Makefile | 1 +
> >>>>>>>>>>>>> arch/arm/boards/Makefile | 1 +
> >>>>>>>>>>>>> arch/arm/boards/spider-evk/Makefile | 4 +++
> >>>>>>>>>>>>> arch/arm/boards/spider-evk/board.c | 26 +++++++++++++++
> >>>>>>>>>>>>> arch/arm/boards/spider-evk/lowlevel.c | 30
> >> +++++++++++++++++
> >>>>>>>>>>>>> arch/arm/configs/spider_defconfig | 8 +++++
> >>>>>>>>>>>>> arch/arm/dts/Makefile | 1 +
> >>>>>>>>>>>>> arch/arm/dts/spider-mk1-evk.dts | 10 ++++++
> >>>>>>>>>>>>> arch/arm/dts/spider-mk1.dtsi | 46
> >>>>>>>> +++++++++++++++++++++++++++
> >>>>>>>>>>>>> arch/arm/mach-spider/Kconfig | 16 ++++++++++
> >>>>>>>>>>>>> arch/arm/mach-spider/Makefile | 1 +
> >>>>>>>>>>>>> arch/arm/mach-spider/lowlevel.c | 14 ++++++++
> >>>>>>>>>>>>> images/Makefile | 1 +
> >>>>>>>>>>>>> images/Makefile.spider | 5 +++
> >>>>>>>>>>>>> include/mach/spider/lowlevel.h | 7 ++++
> >>>>>>>>>>>>> 16 files changed, 184 insertions(+)
> >>>>>>>>>>>>> create mode 100644 arch/arm/boards/spider-evk/Makefile
> >>>>>>>>>>>>> create mode 100644 arch/arm/boards/spider-evk/board.c
> >>>>>>>>>>>>> create mode 100644 arch/arm/boards/spider-evk/lowlevel.c
> >>>>>>>>>>>>> create mode 100644 arch/arm/configs/spider_defconfig
> create
> >>>>>> mode
> >>>>>>>>>>>> 100644 arch/arm/dts/spider-mk1-evk.dts create mode
> 100644
> >>>>>>>>>>>> arch/arm/dts/spider-mk1.dtsi create mode 100644
> >>>> arch/arm/mach-
> >>>>>>>>>>>> spider/Kconfig create mode 100644 arch/arm/mach-
> >>>> spider/Makefile
> >>>>>>>>>> create
> >>>>>>>>>>>> mode 100644 arch/arm/mach-spider/lowlevel.c create mode
> >>>> 100644
> >>>>>>>>>>>> images/Makefile.spider create mode 100644
> >>>>>>>>>> include/mach/spider/lowlevel.h
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index
> >>>>>>>>>>>> e76ee0f6dfe1..e5dcf128447e 100644
> >>>>>>>>>>>>> --- a/arch/arm/Kconfig
> >>>>>>>>>>>>> +++ b/arch/arm/Kconfig
> >>>>>>>>>>>>> @@ -255,6 +255,18 @@ config ARCH_ROCKCHIP
> >>>>>>>>>>>>> select HAS_DEBUG_LL
> >>>>>>>>>>>>> imply GPIO_ROCKCHIP
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> +config ARCH_SPIDER
> >>>>>>>>>>>>> + bool "Pliops Spider based"
> >>>>>>>>>>>>> + depends on 64BIT
> >>>>>>>>>>>>> + depends on ARCH_MULTIARCH
> >>>>>>>>>>>>> + select GPIOLIB
> >>>>>>>>>>>>> + select HAVE_PBL_MULTI_IMAGES
> >>>>>>>>>>>>> + select COMMON_CLK
> >>>>>>>>>>>>> + select CLKDEV_LOOKUP
> >>>>>>>>>>>>> + select COMMON_CLK_OF_PROVIDER
> >>>>>>>>>>>>> + select OFTREE
> >>>>>>>>>>>>> + select OFDEVICE
> >>>>>>>>>>>>> +
> >>>>>>>>>>>>> config ARCH_STM32MP
> >>>>>>>>>>>>> bool "STMicroelectronics STM32MP"
> >>>>>>>>>>>>> depends on 32BIT
> >>>>>>>>>>>>> @@ -331,6 +343,7 @@ source "arch/arm/mach-
> omap/Kconfig"
> >>>>>>>>>>>>> source "arch/arm/mach-pxa/Kconfig"
> >>>>>>>>>>>>> source "arch/arm/mach-rockchip/Kconfig"
> >>>>>>>>>>>>> source "arch/arm/mach-socfpga/Kconfig"
> >>>>>>>>>>>>> +source "arch/arm/mach-spider/Kconfig"
> >>>>>>>>>>>>> source "arch/arm/mach-stm32mp/Kconfig"
> >>>>>>>>>>>>> source "arch/arm/mach-versatile/Kconfig"
> >>>>>>>>>>>>> source "arch/arm/mach-vexpress/Kconfig"
> >>>>>>>>>>>>> diff --git a/arch/arm/Makefile b/arch/arm/Makefile index
> >>>>>>>>>>>> 35ebc70f44e2..4c63dfee48f4 100644
> >>>>>>>>>>>>> --- a/arch/arm/Makefile
> >>>>>>>>>>>>> +++ b/arch/arm/Makefile
> >>>>>>>>>>>>> @@ -101,6 +101,7 @@ machine-$(CONFIG_ARCH_MXS)
> +=
> >>>> mxs
> >>>>>>>>>>>>> machine-$(CONFIG_ARCH_MVEBU) += mvebu
> >>>>>>>>>>>>> machine-$(CONFIG_ARCH_NOMADIK) += nomadik
> >>>>>>>>>>>>> machine-$(CONFIG_ARCH_OMAP) += omap
> >>>>>>>>>>>>> +machine-$(CONFIG_ARCH_SPIDER) += spider
> >>>>>>>>>>>>> machine-$(CONFIG_ARCH_PXA) += pxa
> >>>>>>>>>>>>> machine-$(CONFIG_ARCH_ROCKCHIP) += rockchip
> >>>>>>>>>>>>> machine-$(CONFIG_ARCH_SAMSUNG) += samsung
> >>>>>>>>>>>>> diff --git a/arch/arm/boards/Makefile
> >>>> b/arch/arm/boards/Makefile
> >>>>>>>> index
> >>>>>>>>>>>> 2877debad535..6fe0a90c81ea 100644
> >>>>>>>>>>>>> --- a/arch/arm/boards/Makefile
> >>>>>>>>>>>>> +++ b/arch/arm/boards/Makefile
> >>>>>>>>>>>>> @@ -135,6 +135,7 @@ obj-
> >>>>>>>>>>>> $(CONFIG_MACH_SOCFPGA_TERASIC_DE10_NANO) +=
> >> terasic-
> >>>>>>>> de10-
> >>>>>>>>>>>> nano/
> >>>>>>>>>>>>> obj-$(CONFIG_MACH_SOCFPGA_TERASIC_SOCKIT) +=
> >> terasic-
> >>>>>>>> sockit/
> >>>>>>>>>>>>> obj-$(CONFIG_MACH_SOLIDRUN_CUBOX) += solidrun-
> >>>> cubox/
> >>>>>>>>>>>>> obj-$(CONFIG_MACH_SOLIDRUN_MICROSOM) +=
> >> solidrun-
> >>>>>>>>>>>> microsom/
> >>>>>>>>>>>>> +obj-$(CONFIG_MACH_SPIDER_MK1_EVK) += spider-
> evk/
> >>>>>>>>>>>>> obj-$(CONFIG_MACH_STM32MP15XX_DKX) +=
> >>>>>> stm32mp15xx-
> >>>>>>>>>> dkx/
> >>>>>>>>>>>>> obj-$(CONFIG_MACH_STM32MP13XX_DK) +=
> >>>> stm32mp13xx-
> >>>>>>>> dk/
> >>>>>>>>>>>>> obj-$(CONFIG_MACH_LXA_MC1) += lxa-mc1/
> >>>>>>>>>>>>> diff --git a/arch/arm/boards/spider-evk/Makefile
> >>>>>>>>>>>> b/arch/arm/boards/spider-evk/Makefile
> >>>>>>>>>>>>> new file mode 100644
> >>>>>>>>>>>>> index 000000000000..da63d2625f7a
> >>>>>>>>>>>>> --- /dev/null
> >>>>>>>>>>>>> +++ b/arch/arm/boards/spider-evk/Makefile
> >>>>>>>>>>>>> @@ -0,0 +1,4 @@
> >>>>>>>>>>>>> +# SPDX-License-Identifier: GPL-2.0-only
> >>>>>>>>>>>>> +
> >>>>>>>>>>>>> +obj-y += board.o
> >>>>>>>>>>>>> +lwl-y += lowlevel.o
> >>>>>>>>>>>>> diff --git a/arch/arm/boards/spider-evk/board.c
> >>>>>>>>>> b/arch/arm/boards/spider-
> >>>>>>>>>>>> evk/board.c
> >>>>>>>>>>>>> new file mode 100644
> >>>>>>>>>>>>> index 000000000000..3920e83b457d
> >>>>>>>>>>>>> --- /dev/null
> >>>>>>>>>>>>> +++ b/arch/arm/boards/spider-evk/board.c
> >>>>>>>>>>>>> @@ -0,0 +1,26 @@
> >>>>>>>>>>>>> +#include <bbu.h>
> >>>>>>>>>>>>> +#include <boot.h>
> >>>>>>>>>>>>> +#include <bootm.h>
> >>>>>>>>>>>>> +#include <common.h>
> >>>>>>>>>>>>> +#include <deep-probe.h>
> >>>>>>>>>>>>> +#include <environment.h>
> >>>>>>>>>>>>> +#include <fcntl.h>
> >>>>>>>>>>>>> +#include <globalvar.h>
> >>>>>>>>>>>>> +
> >>>>>>>>>>>>> +static int spider_board_probe(struct device *dev) {
> >>>>>>>>>>>>> + /* Do some board-specific setup */
> >>>>>>>>>>>>> + return 0;
> >>>>>>>>>>>>> +}
> >>>>>>>>>>>>> +
> >>>>>>>>>>>>> +static const struct of_device_id spider_board_of_match[] = {
> >>>>>>>>>>>>> + { .compatible = "pliops,spider-mk1-evk" },
> >>>>>>>>>>>>> + { /* sentinel */ },
> >>>>>>>>>>>>> +};
> >>>>>>>>>>>>> +
> >>>>>>>>>>>>> +static struct driver spider_board_driver = {
> >>>>>>>>>>>>> + .name = "board-spider",
> >>>>>>>>>>>>> + .probe = spider_board_probe,
> >>>>>>>>>>>>> + .of_compatible = spider_board_of_match, };
> >>>>>>>>>>>>> +device_platform_driver(spider_board_driver);
> >>>>>>>>>>>>> diff --git a/arch/arm/boards/spider-evk/lowlevel.c
> >>>>>>>>>>>> b/arch/arm/boards/spider-evk/lowlevel.c
> >>>>>>>>>>>>> new file mode 100644
> >>>>>>>>>>>>> index 000000000000..e36fcde4208e
> >>>>>>>>>>>>> --- /dev/null
> >>>>>>>>>>>>> +++ b/arch/arm/boards/spider-evk/lowlevel.c
> >>>>>>>>>>>>> @@ -0,0 +1,30 @@
> >>>>>>>>>>>>> +#include <common.h>
> >>>>>>>>>>>>> +#include <asm/barebox-arm.h>
> >>>>>>>>>>>>> +#include <mach/spider/lowlevel.h>
> >>>>>>>>>>>>> +
> >>>>>>>>>>>>> +#define BASE_ADDR (0xD000307000)
> >>>>>>>>>>>>> +#define GPRAM_ADDR (0xC000000000)
> >>>>>>>>>>>>> +#define MY_STACK_TOP (0xC000000000 + SZ_2M) // Set
> the
> >>>> stack
> >>>>>>>>>> 2MB
> >>>>>>>>>>>> from GPRAM start (excatly in the middle)
> >>>>>>>>>>>>> +static inline void spider_serial_putc(void *base, int c) {
> >>>>>>>>>>>>> +// if (!(readl(base + UCR1) & UCR1_UARTEN))
> >>>>>>>>>>>>> +// return;
> >>>>>>>>>>>>> +//
> >>>>>>>>>>>>> +// while (!(readl(base + USR2) & USR2_TXDC));
> >>>>>>>>>>>>> +//
> >>>>>>>>>>>>> +// writel(c, base + URTX0);
> >>>>>>>>>>>>> +}
> >>>>>>>>>>>>> +
> >>>>>>>>>>>>> +ENTRY_FUNCTION_WITHSTACK(start_spider_mk1_evk,
> >>>>>>>> MY_STACK_TOP,
> >>>>>>>>>>>> r0, r1,
> >>>>>>>>>>>>> +r2) {
> >>>>>>>>>>>>> + extern char __dtb_spider_mk1_evk_start[];
> >>>>>>>>>>>>> +
> >>>>>>>>>>>>> + spider_lowlevel_init();
> >>>>>>>>>>>>> +
> >>>>>>>>>>>>> + relocate_to_current_adr();
> >>>>>>>>>>>>> + setup_c();
> >>>>>>>>>>>>> +
> >>>>>>>>>>>>> + pbl_set_putc(spider_serial_putc, (void *)BASE_ADDR);
> >>>>>>>>>>>>> +
> >>>>>>>>>>>>> + barebox_arm_entry(GPRAM_ADDR, SZ_2M,
> >>>>>>>>>>>>> +__dtb_spider_mk1_evk_start); }
> >>>>>>>>>>>>> diff --git a/arch/arm/configs/spider_defconfig
> >>>>>>>>>>>> b/arch/arm/configs/spider_defconfig
> >>>>>>>>>>>>> new file mode 100644
> >>>>>>>>>>>>> index 000000000000..c91bb889d97f
> >>>>>>>>>>>>> --- /dev/null
> >>>>>>>>>>>>> +++ b/arch/arm/configs/spider_defconfig
> >>>>>>>>>>>>> @@ -0,0 +1,8 @@
> >>>>>>>>>>>>> +CONFIG_ARCH_SPIDER=y
> >>>>>>>>>>>>> +CONFIG_MACH_SPIDER_MK1_EVK=y
> >>>>>>>>>>>>> +CONFIG_BOARD_ARM_GENERIC_DT=y
> >>>>>>>>>>>>> +CONFIG_MALLOC_TLSF=y
> >>>>>>>>>>>>> +CONFIG_KALLSYMS=y
> >>>>>>>>>>>>> +CONFIG_RELOCATABLE=y
> >>>>>>>>>>>>> +CONFIG_CONSOLE_ALLOW_COLOR=y
> >>>>>>>>>>>>> +CONFIG_PBL_CONSOLE=y
> >>>>>>>>>>>>> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> >> index
> >>>>>>>>>>>> 98f4c4e0194b..94b304d4878f 100644
> >>>>>>>>>>>>> --- a/arch/arm/dts/Makefile
> >>>>>>>>>>>>> +++ b/arch/arm/dts/Makefile
> >>>>>>>>>>>>> @@ -134,6 +134,7 @@ lwl-
> >> $(CONFIG_MACH_SOLIDRUN_CUBOX)
> >>>>>> +=
> >>>>>>>>>> dove-
> >>>>>>>>>>>> cubox-bb.dtb.o
> >>>>>>>>>>>>> lwl-$(CONFIG_MACH_SOLIDRUN_MICROSOM) += imx6dl-
> >>>>>>>>>>>> hummingboard.dtb.o imx6q-hummingboard.dtb.o \
> >>>>>>>>>>>>> imx6dl-hummingboard2.dtb.o imx6q-
> >>>>>>>>>>>> hummingboard2.dtb.o \
> >>>>>>>>>>>>> imx6q-h100.dtb.o
> >>>>>>>>>>>>> +lwl-$(CONFIG_MACH_SPIDER_MK1_EVK) += spider-mk1-
> >>>> evk.dtb.o
> >>>>>>>>>>>>> lwl-$(CONFIG_MACH_SKOV_IMX6) += imx6s-skov-
> imx6.dtb.o
> >>>>>> imx6dl-
> >>>>>>>>>> skov-
> >>>>>>>>>>>> imx6.dtb.o imx6q-skov-imx6.dtb.o
> >>>>>>>>>>>>> lwl-$(CONFIG_MACH_SKOV_ARM9CPU) += at91-skov-
> >>>>>> arm9cpu.dtb.o
> >>>>>>>>>>>>> lwl-$(CONFIG_MACH_SEEED_ODYSSEY) += stm32mp157c-
> >>>>>>>> odyssey.dtb.o
> >>>>>>>>>>>> diff --git a/arch/arm/dts/spider-mk1-evk.dts
> >>>> b/arch/arm/dts/spider-
> >>>>>>>> mk1-
> >>>>>>>>>>>> evk.dts new file mode 100644 index
> >>>> 000000000000..b8081cb85bf8
> >>>>>>>>>>>>> --- /dev/null
> >>>>>>>>>>>>> +++ b/arch/arm/dts/spider-mk1-evk.dts
> >>>>>>>>>>>>> @@ -0,0 +1,10 @@
> >>>>>>>>>>>>> +// SPDX-License-Identifier: GPL-2.0 OR X11
> >>>>>>>>>>>>> +
> >>>>>>>>>>>>> +/dts-v1/;
> >>>>>>>>>>>>> +
> >>>>>>>>>>>>> +#include "spider-mk1.dtsi"
> >>>>>>>>>>>>> +
> >>>>>>>>>>>>> +/ {
> >>>>>>>>>>>>> + model = "Pliops Spider MK-I EVK";
> >>>>>>>>>>>>> + compatible = "pliops,spider-mk1-evk"; };
> >>>>>>>>>>>>> diff --git a/arch/arm/dts/spider-mk1.dtsi
> >> b/arch/arm/dts/spider-
> >>>>>>>> mk1.dtsi
> >>>>>>>>>>>> new file mode 100644 index 000000000000..d4613848169d
> >>>>>>>>>>>>> --- /dev/null
> >>>>>>>>>>>>> +++ b/arch/arm/dts/spider-mk1.dtsi
> >>>>>>>>>>>>> @@ -0,0 +1,46 @@
> >>>>>>>>>>>>> +// SPDX-License-Identifier: GPL-2.0 OR X11
> >>>>>>>>>>>>> +
> >>>>>>>>>>>>> +/ {
> >>>>>>>>>>>>> + #address-cells = <2>;
> >>>>>>>>>>>>> + #size-cells = <2>;
> >>>>>>>>>>>>> +
> >>>>>>>>>>>>> + chosen {
> >>>>>>>>>>>>> + stdout-path = &uart0;
> >>>>>>>>>>>>> + };
> >>>>>>>>>>>>> +
> >>>>>>>>>>>>> + aliases {
> >>>>>>>>>>>>> + serial0 = &uart0;
> >>>>>>>>>>>>> + };
> >>>>>>>>>>>>> +
> >>>>>>>>>>>>> + cpus {
> >>>>>>>>>>>>> + #address-cells = <1>;
> >>>>>>>>>>>>> + #size-cells = <0>;
> >>>>>>>>>>>>> +
> >>>>>>>>>>>>> + cpu0: cpu@0 {
> >>>>>>>>>>>>> + device_type = "cpu";
> >>>>>>>>>>>>> + compatible = "arm,cortex-a53";
> >>>>>>>>>>>>> + reg = <0x0>;
> >>>>>>>>>>>>> + };
> >>>>>>>>>>>>> + };
> >>>>>>>>>>>>> +
> >>>>>>>>>>>>> + memory@1000000 {
> >>>>>>>>>>>>> + reg = <0x0 0x1000000 0x0 0x400000>; /* 128M */
> >>>>>>>>>>>>> + device_type = "memory";
> >>>>>>>>>>>>> + };
> >>>>>>>>>>>>> +
> >>>>>>>>>>>>> + soc {
> >>>>>>>>>>>>> + #address-cells = <2>;
> >>>>>>>>>>>>> + #size-cells = <2>;
> >>>>>>>>>>>>> + ranges;
> >>>>>>>>>>>>> +
> >>>>>>>>>>>>> + sram@c000000000 {
> >>>>>>>>>>>>> + compatible = "mmio-sram";
> >>>>>>>>>>>>> + reg = <0xc0 0x0 0x0 0x400000>;
> >>>>>>>>>>>>> + };
> >>>>>>>>>>>>> +
> >>>>>>>>>>>>> + uart0: serial@d000307000 {
> >>>>>>>>>>>>> + compatible = "pliops,spider-uart";
> >>>>>>>>>>>>> + reg = <0xd0 0x307000 0 0x1000>;
> >>>>>>>>>>>>> + };
> >>>>>>>>>>>>> + };
> >>>>>>>>>>>>> +};
> >>>>>>>>>>>>> diff --git a/arch/arm/mach-spider/Kconfig b/arch/arm/mach-
> >>>>>>>>>> spider/Kconfig
> >>>>>>>>>>>> new file mode 100644 index 000000000000..6d2f888a5fd8
> >>>>>>>>>>>>> --- /dev/null
> >>>>>>>>>>>>> +++ b/arch/arm/mach-spider/Kconfig
> >>>>>>>>>>>>> @@ -0,0 +1,16 @@
> >>>>>>>>>>>>> +# SPDX-License-Identifier: GPL-2.0-only
> >>>>>>>>>>>>> +
> >>>>>>>>>>>>> +if ARCH_SPIDER
> >>>>>>>>>>>>> +
> >>>>>>>>>>>>> +config ARCH_SPIDER_MK1
> >>>>>>>>>>>>> + bool
> >>>>>>>>>>>>> + select CPU_V8
> >>>>>>>>>>>>> + help
> >>>>>>>>>>>>> + The first Cortex-A53-based SoC of the spider family.
> >>>>>>>>>>>>> + This symbol is invisble and select by boards
> >>>>>>>>>>>>> +
> >>>>>>>>>>>>> +config MACH_SPIDER_MK1_EVK
> >>>>>>>>>>>>> + bool "Pliops Spider Reference Design Board"
> >>>>>>>>>>>>> + select ARCH_SPIDER_MK1
> >>>>>>>>>>>>> +
> >>>>>>>>>>>>> +endif
> >>>>>>>>>>>>> diff --git a/arch/arm/mach-spider/Makefile b/arch/arm/mach-
> >>>>>>>>>>>> spider/Makefile new file mode 100644 index
> >>>>>>>>>> 000000000000..b08c4a93ca27
> >>>>>>>>>>>>> --- /dev/null
> >>>>>>>>>>>>> +++ b/arch/arm/mach-spider/Makefile
> >>>>>>>>>>>>> @@ -0,0 +1 @@
> >>>>>>>>>>>>> +lwl-y += lowlevel.o
> >>>>>>>>>>>>> diff --git a/arch/arm/mach-spider/lowlevel.c
> b/arch/arm/mach-
> >>>>>>>>>>>> spider/lowlevel.c new file mode 100644 index
> >>>>>>>>>>>> 000000000000..5d62ef0f39e5
> >>>>>>>>>>>>> --- /dev/null
> >>>>>>>>>>>>> +++ b/arch/arm/mach-spider/lowlevel.c
> >>>>>>>>>>>>> @@ -0,0 +1,14 @@
> >>>>>>>>>>>>> +// SPDX-License-Identifier: GPL-2.0+
> >>>>>>>>>>>>> +
> >>>>>>>>>>>>> +#include <linux/types.h>
> >>>>>>>>>>>>> +#include <mach/spider/lowlevel.h>
> >>>>>>>>>>>>> +#include <asm/barebox-arm-head.h>
> >>>>>>>>>>>>> +
> >>>>>>>>>>>>> +void spider_lowlevel_init(void)
> >>>>>>>>>>>>> +{
> >>>>>>>>>>>>> + arm_cpu_lowlevel_init();
> >>>>>>>>>>>>> + /*
> >>>>>>>>>>>>> + * not yet relocated, only do writel/readl for stuff that's
> >>>>>>>>>>>>> + * critical to run early. No global variables allowed.
> >>>>>>>>>>>>> + */
> >>>>>>>>>>>>> +}
> >>>>>>>>>>>>> diff --git a/images/Makefile b/images/Makefile index
> >>>>>>>>>>>> c93f9e268978..97521e713228 100644
> >>>>>>>>>>>>> --- a/images/Makefile
> >>>>>>>>>>>>> +++ b/images/Makefile
> >>>>>>>>>>>>> @@ -150,6 +150,7 @@ include
> $(srctree)/images/Makefile.mxs
> >>>>>>>> include
> >>>>>>>>>>>> $(srctree)/images/Makefile.omap3 include
> >>>>>>>>>>>> $(srctree)/images/Makefile.rockchip
> >>>>>>>>>>>>> include $(srctree)/images/Makefile.socfpga
> >>>>>>>>>>>>> +include $(srctree)/images/Makefile.spider
> >>>>>>>>>>>>> include $(srctree)/images/Makefile.stm32mp
> >>>>>>>>>>>>> include $(srctree)/images/Makefile.tegra include
> >>>>>>>>>>>> $(srctree)/images/Makefile.versatile
> >>>>>>>>>>>>> diff --git a/images/Makefile.spider b/images/Makefile.spider
> >> new
> >>>> file
> >>>>>>>>>> mode
> >>>>>>>>>>>> 100644 index 000000000000..c32f2762df04
> >>>>>>>>>>>>> --- /dev/null
> >>>>>>>>>>>>> +++ b/images/Makefile.spider
> >>>>>>>>>>>>> @@ -0,0 +1,5 @@
> >>>>>>>>>>>>> +# SPDX-License-Identifier: GPL-2.0-only
> >>>>>>>>>>>>> +
> >>>>>>>>>>>>> +pblb-$(CONFIG_MACH_SPIDER_MK1_EVK) +=
> >>>>>> start_spider_mk1_evk
> >>>>>>>>>>>>> +FILE_barebox-spider-mk1-evk.img =
> >> start_spider_mk1_evk.pblb
> >>>>>>>>>>>>> +image-$(CONFIG_MACH_SPIDER_MK1_EVK) += barebox-
> >> spider-
> >>>>>> mk1-
> >>>>>>>>>>>> evk.img
> >>>>>>>>>>>>> diff --git a/include/mach/spider/lowlevel.h
> >>>>>>>>>>>> b/include/mach/spider/lowlevel.h new file mode 100644 index
> >>>>>>>>>>>> 000000000000..6e0ce1c77f7e
> >>>>>>>>>>>>> --- /dev/null
> >>>>>>>>>>>>> +++ b/include/mach/spider/lowlevel.h
> >>>>>>>>>>>>> @@ -0,0 +1,7 @@
> >>>>>>>>>>>>> +/* SPDX-License-Identifier: GPL-2.0+ */ #ifndef
> >>>> __MACH_SPIDER_H_
> >>>>>>>>>>>>> +#define __MACH_SPIDER_H_
> >>>>>>>>>>>>> +
> >>>>>>>>>>>>> +void spider_lowlevel_init(void);
> >>>>>>>>>>>>> +
> >>>>>>>>>>>>> +#endif
> >>>>>>>>>>>>> --
> >>>>>>>>>>>>> 2.38.4
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> --
> >>>>>>>>>>>> Pengutronix e.K. | |
> >>>>>>>>>>>> Steuerwalder Str. 21 | http://www.pengutronix.de/
> |
> >>>>>>>>>>>> 31137 Hildesheim, Germany | Phone: +49-5121-
> >> 206917-0
> >>>>>> |
> >>>>>>>>>>>> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-
> >> 206917-
> >>>>>> 5555
> >>>>>>>> |
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> --
> >>>>>>>>>> Pengutronix e.K. | |
> >>>>>>>>>> Steuerwalder Str. 21 | http://www.pengutronix.de/ |
> >>>>>>>>>> 31137 Hildesheim, Germany | Phone: +49-5121-
> 206917-0
> >>>> |
> >>>>>>>>>> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-
> 206917-
> >>>> 5555
> >>>>>> |
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> --
> >>>>>>>> Pengutronix e.K. | |
> >>>>>>>> Steuerwalder Str. 21 | http://www.pengutronix.de/ |
> >>>>>>>> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0
> >> |
> >>>>>>>> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-
> >> 5555
> >>>> |
> >>>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> Pengutronix e.K. | |
> >>>>>> Steuerwalder Str. 21 | http://www.pengutronix.de/ |
> >>>>>> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0
> |
> >>>>>> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-
> 5555
> >> |
> >>>>>
> >>>>
> >>>> --
> >>>> Pengutronix e.K. | |
> >>>> Steuerwalder Str. 21 | http://www.pengutronix.de/ |
> >>>> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
> >>>> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555
> |
> >>>
> >>
> >> --
> >> Pengutronix e.K. | |
> >> Steuerwalder Str. 21 | http://www.pengutronix.de/ |
> >> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
> >> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
> >
>
> --
> Pengutronix e.K. | |
> Steuerwalder Str. 21 | http://www.pengutronix.de/ |
> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [PATCH v2] Porting barebox to a new SoC
2023-06-12 9:27 ` Lior Weintraub
@ 2023-06-12 12:28 ` Ahmad Fatoum
2023-06-12 14:59 ` Lior Weintraub
0 siblings, 1 reply; 40+ messages in thread
From: Ahmad Fatoum @ 2023-06-12 12:28 UTC (permalink / raw)
To: Lior Weintraub, Ahmad Fatoum, barebox
Hello Lior,
On 12.06.23 11:27, Lior Weintraub wrote:
> Hi Ahmad,
>
> Regarding the rootfs and Linux run question:
> Our board doesn't include eMMC\SD card.
> We only have our NOR Flash to store the binaries and our BL1 code will make sure to copy those blobs into DRAM.
How could BL1 copy artifacts in DRAM when BL2 first needs to set up DRAM?
> The use of QEMU needs to be as simple as possible so no hidden virtio drivers and such because we would like to simulate the real HW flow.
cfi-flash is just memory-mapped flash, which is the next simplest thing
after BL1 copies stuff into (limited-to-4M) on-chip SRAM.
> Our DTS file now includes the GIC, timer and arm,psci-1.0.
> We have an initial build of Linux kernel Image (using buildroot) and a rootfs.cpio.xz.
> I assume we can somehow reserve a portion of the DRAM to store those binaries and let barebox boot this Linux.
You can make this work, but this is not how your actual system will
look like and trying to make this work is harder than it needs to be.
Just add a cfi-flash that corresponds to the Linux/rootfs flash in
your actual system, then boot with bootm (type help bootm for info
on how to use it). You don't need to hardcode the load addresses,
barebox will determine them automatically.
> Can you please advise how to make it work?
For completion's sake, if you have 64M of RAM that's preloaded with
boot images:
- Remove the 64M from the barebox /memory node. You can use a different
DT for kernel, but if you have memory that barebox shouldn't override,
you need to tell it that.
- Add a mtd-rom node that describes these 64M that you have. You can
add partitions for the region used for kernel and oftree
- boot with bootm -o /dev/mtdrom0.oftree -r /dev/mtdrom0.initrd \
/dev/mtdrom0.kernel
That's admittedly cumbersome, but necessary, so barebox knows what memory
it may use for itself and what memory may be used for boot.
Correct solution is to use cfi-flash or similar.
Cheers,
Ahmad
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply [flat|nested] 40+ messages in thread
* RE: [PATCH v2] Porting barebox to a new SoC
2023-06-12 12:28 ` Ahmad Fatoum
@ 2023-06-12 14:59 ` Lior Weintraub
2023-06-12 15:07 ` Ahmad Fatoum
0 siblings, 1 reply; 40+ messages in thread
From: Lior Weintraub @ 2023-06-12 14:59 UTC (permalink / raw)
To: Ahmad Fatoum, Ahmad Fatoum, barebox
Hello Ahmad,
Just for simple simulations we make the ROM size 192MB so it can include all needed artifacts.
When we get this simple system to work we will move the relevant parts to BL2.
DRAM is also simulated now as SRAM so we are not worried about initializations.
So if I understand correctly, we can decide that address 0x10000000 will be reserved for "flash" and add the following node:
flash@0 {
compatible = "mtd-rom";
probe-type = "map_rom";
reg = <0x10000000 0x10000000>;
bank-width = <4>;
device-width = <1>;
#address-cells = <1>;
#size-cells = <1>;
kernel@0 {
label = "kernel";
reg = <0x0 0x01000000>;
};
rootfs@1000000 {
label = "rootfs";
reg = <0x01000000 0x00800000>;
};
};
When I use this node on our DT I see the following devinfo:
barebox:/ devinfo
`-- global
`-- nv
`-- platform
`-- machine
`-- psci.of
`-- 1000000010000000.flash@0.of
`-- soc.of
`-- c000000000.sram@c000000000.of
`-- soc:pmu.of
`-- soc:timer.of
`-- e000000000.interrupt-controller@E000000000.of
`-- mem0
`-- 0x00000000-0x0fffffff ( 256 MiB): /dev/ram0
`-- mem1
`-- 0x00000000-0xffffffffffffffff ( 0 Bytes): /dev/mem
`-- amba
`-- d000307000.serial@d000307000.of
`-- cs0
`-- 0x00000000-0xffffffffffffffff ( 0 Bytes): /dev/cs0
`-- spi
`-- fs
`-- ramfs0
`-- devfs0
`-- pstore0
Not sure how to proceed from here...
Cheers,
Lior.
> -----Original Message-----
> From: Ahmad Fatoum <a.fatoum@pengutronix.de>
> Sent: Monday, June 12, 2023 3:29 PM
> To: Lior Weintraub <liorw@pliops.com>; Ahmad Fatoum <ahmad@a3f.at>;
> barebox@lists.infradead.org
> Subject: Re: [PATCH v2] Porting barebox to a new SoC
>
> CAUTION: External Sender
>
> Hello Lior,
>
> On 12.06.23 11:27, Lior Weintraub wrote:
> > Hi Ahmad,
> >
> > Regarding the rootfs and Linux run question:
> > Our board doesn't include eMMC\SD card.
> > We only have our NOR Flash to store the binaries and our BL1 code will make
> sure to copy those blobs into DRAM.
>
> How could BL1 copy artifacts in DRAM when BL2 first needs to set up DRAM?
>
> > The use of QEMU needs to be as simple as possible so no hidden virtio
> drivers and such because we would like to simulate the real HW flow.
>
> cfi-flash is just memory-mapped flash, which is the next simplest thing
> after BL1 copies stuff into (limited-to-4M) on-chip SRAM.
>
> > Our DTS file now includes the GIC, timer and arm,psci-1.0.
> > We have an initial build of Linux kernel Image (using buildroot) and a
> rootfs.cpio.xz.
> > I assume we can somehow reserve a portion of the DRAM to store those
> binaries and let barebox boot this Linux.
>
> You can make this work, but this is not how your actual system will
> look like and trying to make this work is harder than it needs to be.
>
> Just add a cfi-flash that corresponds to the Linux/rootfs flash in
> your actual system, then boot with bootm (type help bootm for info
> on how to use it). You don't need to hardcode the load addresses,
> barebox will determine them automatically.
>
> > Can you please advise how to make it work?
>
> For completion's sake, if you have 64M of RAM that's preloaded with
> boot images:
>
> - Remove the 64M from the barebox /memory node. You can use a different
> DT for kernel, but if you have memory that barebox shouldn't override,
> you need to tell it that.
>
> - Add a mtd-rom node that describes these 64M that you have. You can
> add partitions for the region used for kernel and oftree
>
> - boot with bootm -o /dev/mtdrom0.oftree -r /dev/mtdrom0.initrd \
> /dev/mtdrom0.kernel
>
> That's admittedly cumbersome, but necessary, so barebox knows what
> memory
> it may use for itself and what memory may be used for boot.
>
> Correct solution is to use cfi-flash or similar.
>
> Cheers,
> Ahmad
> --
> Pengutronix e.K. | |
> Steuerwalder Str. 21 | http://www.pengutronix.de/ |
> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [PATCH v2] Porting barebox to a new SoC
2023-06-12 14:59 ` Lior Weintraub
@ 2023-06-12 15:07 ` Ahmad Fatoum
2023-06-13 12:39 ` Lior Weintraub
0 siblings, 1 reply; 40+ messages in thread
From: Ahmad Fatoum @ 2023-06-12 15:07 UTC (permalink / raw)
To: Lior Weintraub, Ahmad Fatoum, barebox
Hi,
On 12.06.23 16:59, Lior Weintraub wrote:
> Hello Ahmad,
>
> Just for simple simulations we make the ROM size 192MB so it can include all needed artifacts.
I am not convinced that this is much of a simplification over having
your Qemu machine provide cfi-flash.
> When we get this simple system to work we will move the relevant parts to BL2.
Ok.
> DRAM is also simulated now as SRAM so we are not worried about initializations.
>
> So if I understand correctly, we can decide that address 0x10000000 will be reserved for "flash" and add the following node:
> flash@0 {
flash@10000000, but that's just for informational purposes.
> compatible = "mtd-rom";
> probe-type = "map_rom";
> reg = <0x10000000 0x10000000>;
> bank-width = <4>;
> device-width = <1>;
>
> #address-cells = <1>;
> #size-cells = <1>;
> kernel@0 {
> label = "kernel";
> reg = <0x0 0x01000000>;
> };
> rootfs@1000000 {
> label = "rootfs";
> reg = <0x01000000 0x00800000>;
> };
> };
>
> When I use this node on our DT I see the following devinfo:
> barebox:/ devinfo
> `-- global
> `-- nv
> `-- platform
> `-- machine
> `-- psci.of
> `-- 1000000010000000.flash@0.of
As you can see the address is wrong. That's because you have
#address-cells = <2>;
#size-cells = <2>;
Yet, you wrote reg as if it was <1>/<1>. Change it to
reg = <0x0 0x10000000 0x0 0x10000000>;
Remember all device tree integers are 32-bit big endian.
> `-- soc.of
> `-- c000000000.sram@c000000000.of
> `-- soc:pmu.of
> `-- soc:timer.of
> `-- e000000000.interrupt-controller@E000000000.of
> `-- mem0
> `-- 0x00000000-0x0fffffff ( 256 MiB): /dev/ram0
> `-- mem1
> `-- 0x00000000-0xffffffffffffffff ( 0 Bytes): /dev/mem
> `-- amba
> `-- d000307000.serial@d000307000.of
> `-- cs0
> `-- 0x00000000-0xffffffffffffffff ( 0 Bytes): /dev/cs0
> `-- spi
> `-- fs
> `-- ramfs0
> `-- devfs0
> `-- pstore0
>
> Not sure how to proceed from here...
Type drvinfo command to see what drivers are bound to what devices.
If you see no driver bound to your flash device, then maybe you need
to enable the correct driver, that would be CONFIG_MTD_MTDRAM (which
handles both read-only and read-write memory mapped MTD).
Cheers,
Ahmad
> Cheers,
> Lior.
>
>> -----Original Message-----
>> From: Ahmad Fatoum <a.fatoum@pengutronix.de>
>> Sent: Monday, June 12, 2023 3:29 PM
>> To: Lior Weintraub <liorw@pliops.com>; Ahmad Fatoum <ahmad@a3f.at>;
>> barebox@lists.infradead.org
>> Subject: Re: [PATCH v2] Porting barebox to a new SoC
>>
>> CAUTION: External Sender
>>
>> Hello Lior,
>>
>> On 12.06.23 11:27, Lior Weintraub wrote:
>>> Hi Ahmad,
>>>
>>> Regarding the rootfs and Linux run question:
>>> Our board doesn't include eMMC\SD card.
>>> We only have our NOR Flash to store the binaries and our BL1 code will make
>> sure to copy those blobs into DRAM.
>>
>> How could BL1 copy artifacts in DRAM when BL2 first needs to set up DRAM?
>>
>>> The use of QEMU needs to be as simple as possible so no hidden virtio
>> drivers and such because we would like to simulate the real HW flow.
>>
>> cfi-flash is just memory-mapped flash, which is the next simplest thing
>> after BL1 copies stuff into (limited-to-4M) on-chip SRAM.
>>
>>> Our DTS file now includes the GIC, timer and arm,psci-1.0.
>>> We have an initial build of Linux kernel Image (using buildroot) and a
>> rootfs.cpio.xz.
>>> I assume we can somehow reserve a portion of the DRAM to store those
>> binaries and let barebox boot this Linux.
>>
>> You can make this work, but this is not how your actual system will
>> look like and trying to make this work is harder than it needs to be.
>>
>> Just add a cfi-flash that corresponds to the Linux/rootfs flash in
>> your actual system, then boot with bootm (type help bootm for info
>> on how to use it). You don't need to hardcode the load addresses,
>> barebox will determine them automatically.
>>
>>> Can you please advise how to make it work?
>>
>> For completion's sake, if you have 64M of RAM that's preloaded with
>> boot images:
>>
>> - Remove the 64M from the barebox /memory node. You can use a different
>> DT for kernel, but if you have memory that barebox shouldn't override,
>> you need to tell it that.
>>
>> - Add a mtd-rom node that describes these 64M that you have. You can
>> add partitions for the region used for kernel and oftree
>>
>> - boot with bootm -o /dev/mtdrom0.oftree -r /dev/mtdrom0.initrd \
>> /dev/mtdrom0.kernel
>>
>> That's admittedly cumbersome, but necessary, so barebox knows what
>> memory
>> it may use for itself and what memory may be used for boot.
>>
>> Correct solution is to use cfi-flash or similar.
>>
>> Cheers,
>> Ahmad
>> --
>> Pengutronix e.K. | |
>> Steuerwalder Str. 21 | http://www.pengutronix.de/ |
>> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
>> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
>
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply [flat|nested] 40+ messages in thread
* RE: [PATCH v2] Porting barebox to a new SoC
2023-06-12 15:07 ` Ahmad Fatoum
@ 2023-06-13 12:39 ` Lior Weintraub
2023-06-13 12:50 ` Ahmad Fatoum
0 siblings, 1 reply; 40+ messages in thread
From: Lior Weintraub @ 2023-06-13 12:39 UTC (permalink / raw)
To: Ahmad Fatoum, Ahmad Fatoum, barebox
Hi Ahmad,
As usual, your comments are spot on :-)
After fixing the DT, devinfo command shows correct flash node:
`-- 20000000.flash@0.of
`-- mtdrom0
`-- 0x00000000-0x0fffffff ( 256 MiB): /dev/mtdrom0
`-- mtdrom0.kernel
`-- 0x00000000-0x00ff7fff ( 16 MiB): /dev/mtdrom0.kernel
`-- mtdrom0.oftree
`-- 0x00000000-0x00007fff ( 32 KiB): /dev/mtdrom0.oftree
`-- mtdrom0.rootfs
`-- 0x00000000-0x007fffff ( 8 MiB): /dev/mtdrom0.rootfs
As can be seen above, we chose to map this "flash" node on DRAM address 0x20000000 (offset 512MB).
The BL1 code correctly copy the 3 artifacts into those location (verified the content via "md -l -s /dev/mtdrom0.kernel").
Running "drvinfo" shows:
mtdram
20000000.flash@0.of
Now when I try to run "bootm -o /dev/mtdrom0.oftree -r /dev/mtdrom0.rootfs /dev/mtdrom0.kernel" I am getting this error:
barebox:/ bootm -o /dev/mtdrom0.oftree -r /dev/mtdrom0.rootfs /dev/mtdrom0.kernel
getopt: optindex: 1 nonopts: 0 optind: 1
getopt: optindex: 1 nonopts: 0 optind: 3
getopt: optindex: 1 nonopts: 0 optind: 5
mtdrom0.kernel: read ofs: 0x00000000 count: 0x00001000
Loading ARM aarch64 Linux image '/dev/mtdrom0.kernel'
header 00000000: 4d 5a 40 fa 3f 1a 23 14 00 00 00 00 00 00 00 00 MZ@.?.#.........
header 00000010: 00 00 b3 00 00 00 00 00 0a 00 00 00 00 00 00 00 ................
header 00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
header 00000030: 00 00 00 00 00 00 00 00 41 52 4d 64 40 00 00 00 ........ARMd@...
header 00000040: 50 45 00 00 64 aa 02 00 00 00 00 00 00 00 00 00 PE..d...........
booti: Kernel to be loaded to 8000000+b30000
__request_region ok: 0x08000000:0x0801ffff flags=0x200
mtdrom0.kernel: read ofs: 0x00000000 count: 0x00020000
__request_region ok: 0x08000000:0x0803ffff flags=0x200
mtdrom0.kernel: read ofs: 0x00020000 count: 0x00020000
.
.
mtdrom0.kernel: read ofs: 0x00fe0000 count: 0x00018000
__request_region ok: 0x08000000:0x08ff7fff flags=0x200
mtdrom0.rootfs: read ofs: 0x00000000 count: 0x00000800
__request_region: 0x08b30000:0x08b4ffff (image) conflicts with 0x08000000:0x08ff7fff (image)
unable to request SDRAM 0x08b30000-0x08b4ffff
handler failed with: Out of memory
Appreciate your advice,
Cheers,
Lior.
> -----Original Message-----
> From: Ahmad Fatoum <a.fatoum@pengutronix.de>
> Sent: Monday, June 12, 2023 6:08 PM
> To: Lior Weintraub <liorw@pliops.com>; Ahmad Fatoum <ahmad@a3f.at>;
> barebox@lists.infradead.org
> Subject: Re: [PATCH v2] Porting barebox to a new SoC
>
> CAUTION: External Sender
>
> Hi,
>
> On 12.06.23 16:59, Lior Weintraub wrote:
> > Hello Ahmad,
> >
> > Just for simple simulations we make the ROM size 192MB so it can include all
> needed artifacts.
>
> I am not convinced that this is much of a simplification over having
> your Qemu machine provide cfi-flash.
>
> > When we get this simple system to work we will move the relevant parts to
> BL2.
>
> Ok.
>
> > DRAM is also simulated now as SRAM so we are not worried about
> initializations.
> >
> > So if I understand correctly, we can decide that address 0x10000000 will be
> reserved for "flash" and add the following node:
> > flash@0 {
>
> flash@10000000, but that's just for informational purposes.
>
> > compatible = "mtd-rom";
> > probe-type = "map_rom";
> > reg = <0x10000000 0x10000000>;
> > bank-width = <4>;
> > device-width = <1>;
> >
> > #address-cells = <1>;
> > #size-cells = <1>;
> > kernel@0 {
> > label = "kernel";
> > reg = <0x0 0x01000000>;
> > };
> > rootfs@1000000 {
> > label = "rootfs";
> > reg = <0x01000000 0x00800000>;
> > };
> > };
> >
> > When I use this node on our DT I see the following devinfo:
> > barebox:/ devinfo
> > `-- global
> > `-- nv
> > `-- platform
> > `-- machine
> > `-- psci.of
> > `-- 1000000010000000.flash@0.of
>
> As you can see the address is wrong. That's because you have
> #address-cells = <2>;
> #size-cells = <2>;
>
> Yet, you wrote reg as if it was <1>/<1>. Change it to
>
> reg = <0x0 0x10000000 0x0 0x10000000>;
>
> Remember all device tree integers are 32-bit big endian.
>
> > `-- soc.of
> > `-- c000000000.sram@c000000000.of
> > `-- soc:pmu.of
> > `-- soc:timer.of
> > `-- e000000000.interrupt-controller@E000000000.of
> > `-- mem0
> > `-- 0x00000000-0x0fffffff ( 256 MiB): /dev/ram0
> > `-- mem1
> > `-- 0x00000000-0xffffffffffffffff ( 0 Bytes): /dev/mem
> > `-- amba
> > `-- d000307000.serial@d000307000.of
> > `-- cs0
> > `-- 0x00000000-0xffffffffffffffff ( 0 Bytes): /dev/cs0
> > `-- spi
> > `-- fs
> > `-- ramfs0
> > `-- devfs0
> > `-- pstore0
> >
> > Not sure how to proceed from here...
>
> Type drvinfo command to see what drivers are bound to what devices.
> If you see no driver bound to your flash device, then maybe you need
> to enable the correct driver, that would be CONFIG_MTD_MTDRAM (which
> handles both read-only and read-write memory mapped MTD).
>
> Cheers,
> Ahmad
>
> > Cheers,
> > Lior.
> >
> >> -----Original Message-----
> >> From: Ahmad Fatoum <a.fatoum@pengutronix.de>
> >> Sent: Monday, June 12, 2023 3:29 PM
> >> To: Lior Weintraub <liorw@pliops.com>; Ahmad Fatoum <ahmad@a3f.at>;
> >> barebox@lists.infradead.org
> >> Subject: Re: [PATCH v2] Porting barebox to a new SoC
> >>
> >> CAUTION: External Sender
> >>
> >> Hello Lior,
> >>
> >> On 12.06.23 11:27, Lior Weintraub wrote:
> >>> Hi Ahmad,
> >>>
> >>> Regarding the rootfs and Linux run question:
> >>> Our board doesn't include eMMC\SD card.
> >>> We only have our NOR Flash to store the binaries and our BL1 code will
> make
> >> sure to copy those blobs into DRAM.
> >>
> >> How could BL1 copy artifacts in DRAM when BL2 first needs to set up
> DRAM?
> >>
> >>> The use of QEMU needs to be as simple as possible so no hidden virtio
> >> drivers and such because we would like to simulate the real HW flow.
> >>
> >> cfi-flash is just memory-mapped flash, which is the next simplest thing
> >> after BL1 copies stuff into (limited-to-4M) on-chip SRAM.
> >>
> >>> Our DTS file now includes the GIC, timer and arm,psci-1.0.
> >>> We have an initial build of Linux kernel Image (using buildroot) and a
> >> rootfs.cpio.xz.
> >>> I assume we can somehow reserve a portion of the DRAM to store those
> >> binaries and let barebox boot this Linux.
> >>
> >> You can make this work, but this is not how your actual system will
> >> look like and trying to make this work is harder than it needs to be.
> >>
> >> Just add a cfi-flash that corresponds to the Linux/rootfs flash in
> >> your actual system, then boot with bootm (type help bootm for info
> >> on how to use it). You don't need to hardcode the load addresses,
> >> barebox will determine them automatically.
> >>
> >>> Can you please advise how to make it work?
> >>
> >> For completion's sake, if you have 64M of RAM that's preloaded with
> >> boot images:
> >>
> >> - Remove the 64M from the barebox /memory node. You can use a
> different
> >> DT for kernel, but if you have memory that barebox shouldn't override,
> >> you need to tell it that.
> >>
> >> - Add a mtd-rom node that describes these 64M that you have. You can
> >> add partitions for the region used for kernel and oftree
> >>
> >> - boot with bootm -o /dev/mtdrom0.oftree -r /dev/mtdrom0.initrd \
> >> /dev/mtdrom0.kernel
> >>
> >> That's admittedly cumbersome, but necessary, so barebox knows what
> >> memory
> >> it may use for itself and what memory may be used for boot.
> >>
> >> Correct solution is to use cfi-flash or similar.
> >>
> >> Cheers,
> >> Ahmad
> >> --
> >> Pengutronix e.K. | |
> >> Steuerwalder Str. 21 | http://www.pengutronix.de/ |
> >> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
> >> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
> >
>
> --
> Pengutronix e.K. | |
> Steuerwalder Str. 21 | http://www.pengutronix.de/ |
> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [PATCH v2] Porting barebox to a new SoC
2023-06-13 12:39 ` Lior Weintraub
@ 2023-06-13 12:50 ` Ahmad Fatoum
2023-06-13 13:27 ` Lior Weintraub
0 siblings, 1 reply; 40+ messages in thread
From: Ahmad Fatoum @ 2023-06-13 12:50 UTC (permalink / raw)
To: Lior Weintraub, Ahmad Fatoum, barebox
On 13.06.23 14:39, Lior Weintraub wrote:
> Hi Ahmad,
>
> As usual, your comments are spot on :-)
>
> After fixing the DT, devinfo command shows correct flash node:
> `-- 20000000.flash@0.of
> `-- mtdrom0
> `-- 0x00000000-0x0fffffff ( 256 MiB): /dev/mtdrom0
> `-- mtdrom0.kernel
> `-- 0x00000000-0x00ff7fff ( 16 MiB): /dev/mtdrom0.kernel
> `-- mtdrom0.oftree
> `-- 0x00000000-0x00007fff ( 32 KiB): /dev/mtdrom0.oftree
> `-- mtdrom0.rootfs
> `-- 0x00000000-0x007fffff ( 8 MiB): /dev/mtdrom0.rootfs
>
> As can be seen above, we chose to map this "flash" node on DRAM address 0x20000000 (offset 512MB).
> The BL1 code correctly copy the 3 artifacts into those location (verified the content via "md -l -s /dev/mtdrom0.kernel").
> Running "drvinfo" shows:
> mtdram
> 20000000.flash@0.of
>
> Now when I try to run "bootm -o /dev/mtdrom0.oftree -r /dev/mtdrom0.rootfs /dev/mtdrom0.kernel" I am getting this error:
>
> barebox:/ bootm -o /dev/mtdrom0.oftree -r /dev/mtdrom0.rootfs /dev/mtdrom0.kernel
> getopt: optindex: 1 nonopts: 0 optind: 1
> getopt: optindex: 1 nonopts: 0 optind: 3
> getopt: optindex: 1 nonopts: 0 optind: 5
> mtdrom0.kernel: read ofs: 0x00000000 count: 0x00001000
>
> Loading ARM aarch64 Linux image '/dev/mtdrom0.kernel'
> header 00000000: 4d 5a 40 fa 3f 1a 23 14 00 00 00 00 00 00 00 00 MZ@.?.#.........
> header 00000010: 00 00 b3 00 00 00 00 00 0a 00 00 00 00 00 00 00 ................
> header 00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> header 00000030: 00 00 00 00 00 00 00 00 41 52 4d 64 40 00 00 00 ........ARMd@...
> header 00000040: 50 45 00 00 64 aa 02 00 00 00 00 00 00 00 00 00 PE..d...........
> booti: Kernel to be loaded to 8000000+b30000
Kernel image is relocatable and ARM64 header in hexdump says that
load offset is zero. Yet, barebox wants to load your image to
8000000, which is already reserved.
What's the output of the iomem command before and after the failed
boot attempt?
> __request_region ok: 0x08000000:0x0801ffff flags=0x200
> mtdrom0.kernel: read ofs: 0x00000000 count: 0x00020000
> __request_region ok: 0x08000000:0x0803ffff flags=0x200
> mtdrom0.kernel: read ofs: 0x00020000 count: 0x00020000
> .
> .
> mtdrom0.kernel: read ofs: 0x00fe0000 count: 0x00018000
> __request_region ok: 0x08000000:0x08ff7fff flags=0x200
> mtdrom0.rootfs: read ofs: 0x00000000 count: 0x00000800
> __request_region: 0x08b30000:0x08b4ffff (image) conflicts with 0x08000000:0x08ff7fff (image)
> unable to request SDRAM 0x08b30000-0x08b4ffff
> handler failed with: Out of memory
Just to be sure: You don't set global.bootm.image.loadaddr, right?
Cheers,
Ahmad
>
> Appreciate your advice,
> Cheers,
> Lior.
>
>
>> -----Original Message-----
>> From: Ahmad Fatoum <a.fatoum@pengutronix.de>
>> Sent: Monday, June 12, 2023 6:08 PM
>> To: Lior Weintraub <liorw@pliops.com>; Ahmad Fatoum <ahmad@a3f.at>;
>> barebox@lists.infradead.org
>> Subject: Re: [PATCH v2] Porting barebox to a new SoC
>>
>> CAUTION: External Sender
>>
>> Hi,
>>
>> On 12.06.23 16:59, Lior Weintraub wrote:
>>> Hello Ahmad,
>>>
>>> Just for simple simulations we make the ROM size 192MB so it can include all
>> needed artifacts.
>>
>> I am not convinced that this is much of a simplification over having
>> your Qemu machine provide cfi-flash.
>>
>>> When we get this simple system to work we will move the relevant parts to
>> BL2.
>>
>> Ok.
>>
>>> DRAM is also simulated now as SRAM so we are not worried about
>> initializations.
>>>
>>> So if I understand correctly, we can decide that address 0x10000000 will be
>> reserved for "flash" and add the following node:
>>> flash@0 {
>>
>> flash@10000000, but that's just for informational purposes.
>>
>>> compatible = "mtd-rom";
>>> probe-type = "map_rom";
>>> reg = <0x10000000 0x10000000>;
>>> bank-width = <4>;
>>> device-width = <1>;
>>>
>>> #address-cells = <1>;
>>> #size-cells = <1>;
>>> kernel@0 {
>>> label = "kernel";
>>> reg = <0x0 0x01000000>;
>>> };
>>> rootfs@1000000 {
>>> label = "rootfs";
>>> reg = <0x01000000 0x00800000>;
>>> };
>>> };
>>>
>>> When I use this node on our DT I see the following devinfo:
>>> barebox:/ devinfo
>>> `-- global
>>> `-- nv
>>> `-- platform
>>> `-- machine
>>> `-- psci.of
>>> `-- 1000000010000000.flash@0.of
>>
>> As you can see the address is wrong. That's because you have
>> #address-cells = <2>;
>> #size-cells = <2>;
>>
>> Yet, you wrote reg as if it was <1>/<1>. Change it to
>>
>> reg = <0x0 0x10000000 0x0 0x10000000>;
>>
>> Remember all device tree integers are 32-bit big endian.
>>
>>> `-- soc.of
>>> `-- c000000000.sram@c000000000.of
>>> `-- soc:pmu.of
>>> `-- soc:timer.of
>>> `-- e000000000.interrupt-controller@E000000000.of
>>> `-- mem0
>>> `-- 0x00000000-0x0fffffff ( 256 MiB): /dev/ram0
>>> `-- mem1
>>> `-- 0x00000000-0xffffffffffffffff ( 0 Bytes): /dev/mem
>>> `-- amba
>>> `-- d000307000.serial@d000307000.of
>>> `-- cs0
>>> `-- 0x00000000-0xffffffffffffffff ( 0 Bytes): /dev/cs0
>>> `-- spi
>>> `-- fs
>>> `-- ramfs0
>>> `-- devfs0
>>> `-- pstore0
>>>
>>> Not sure how to proceed from here...
>>
>> Type drvinfo command to see what drivers are bound to what devices.
>> If you see no driver bound to your flash device, then maybe you need
>> to enable the correct driver, that would be CONFIG_MTD_MTDRAM (which
>> handles both read-only and read-write memory mapped MTD).
>>
>> Cheers,
>> Ahmad
>>
>>> Cheers,
>>> Lior.
>>>
>>>> -----Original Message-----
>>>> From: Ahmad Fatoum <a.fatoum@pengutronix.de>
>>>> Sent: Monday, June 12, 2023 3:29 PM
>>>> To: Lior Weintraub <liorw@pliops.com>; Ahmad Fatoum <ahmad@a3f.at>;
>>>> barebox@lists.infradead.org
>>>> Subject: Re: [PATCH v2] Porting barebox to a new SoC
>>>>
>>>> CAUTION: External Sender
>>>>
>>>> Hello Lior,
>>>>
>>>> On 12.06.23 11:27, Lior Weintraub wrote:
>>>>> Hi Ahmad,
>>>>>
>>>>> Regarding the rootfs and Linux run question:
>>>>> Our board doesn't include eMMC\SD card.
>>>>> We only have our NOR Flash to store the binaries and our BL1 code will
>> make
>>>> sure to copy those blobs into DRAM.
>>>>
>>>> How could BL1 copy artifacts in DRAM when BL2 first needs to set up
>> DRAM?
>>>>
>>>>> The use of QEMU needs to be as simple as possible so no hidden virtio
>>>> drivers and such because we would like to simulate the real HW flow.
>>>>
>>>> cfi-flash is just memory-mapped flash, which is the next simplest thing
>>>> after BL1 copies stuff into (limited-to-4M) on-chip SRAM.
>>>>
>>>>> Our DTS file now includes the GIC, timer and arm,psci-1.0.
>>>>> We have an initial build of Linux kernel Image (using buildroot) and a
>>>> rootfs.cpio.xz.
>>>>> I assume we can somehow reserve a portion of the DRAM to store those
>>>> binaries and let barebox boot this Linux.
>>>>
>>>> You can make this work, but this is not how your actual system will
>>>> look like and trying to make this work is harder than it needs to be.
>>>>
>>>> Just add a cfi-flash that corresponds to the Linux/rootfs flash in
>>>> your actual system, then boot with bootm (type help bootm for info
>>>> on how to use it). You don't need to hardcode the load addresses,
>>>> barebox will determine them automatically.
>>>>
>>>>> Can you please advise how to make it work?
>>>>
>>>> For completion's sake, if you have 64M of RAM that's preloaded with
>>>> boot images:
>>>>
>>>> - Remove the 64M from the barebox /memory node. You can use a
>> different
>>>> DT for kernel, but if you have memory that barebox shouldn't override,
>>>> you need to tell it that.
>>>>
>>>> - Add a mtd-rom node that describes these 64M that you have. You can
>>>> add partitions for the region used for kernel and oftree
>>>>
>>>> - boot with bootm -o /dev/mtdrom0.oftree -r /dev/mtdrom0.initrd \
>>>> /dev/mtdrom0.kernel
>>>>
>>>> That's admittedly cumbersome, but necessary, so barebox knows what
>>>> memory
>>>> it may use for itself and what memory may be used for boot.
>>>>
>>>> Correct solution is to use cfi-flash or similar.
>>>>
>>>> Cheers,
>>>> Ahmad
>>>> --
>>>> Pengutronix e.K. | |
>>>> Steuerwalder Str. 21 | http://www.pengutronix.de/ |
>>>> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
>>>> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
>>>
>>
>> --
>> Pengutronix e.K. | |
>> Steuerwalder Str. 21 | http://www.pengutronix.de/ |
>> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
>> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
>
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply [flat|nested] 40+ messages in thread
* RE: [PATCH v2] Porting barebox to a new SoC
2023-06-13 12:50 ` Ahmad Fatoum
@ 2023-06-13 13:27 ` Lior Weintraub
2023-06-14 6:42 ` Lior Weintraub
0 siblings, 1 reply; 40+ messages in thread
From: Lior Weintraub @ 2023-06-13 13:27 UTC (permalink / raw)
To: Ahmad Fatoum, Ahmad Fatoum, barebox
Hi Ahmad,
I also thought that load address was suspicious (0x8000000) but then I saw the following comment on nxp_imx8mq_evk_start:
/*
* On completion the TF-A will jump to MX8MQ_ATF_BL33_BASE_ADDR
* in EL2. Copy the image there, but replace the PBL part of
* that image with ourselves. On a high assurance boot only the
* currently running code is validated and contains the checksum
* for the piggy data, so we need to ensure that we are running
* the same code in DRAM.
*/
Our code was based on this function and as a result it copies the barebox image into address 0x8000000 (which is our settings of ATF_BL33_BASE_ADDR).
The fact that Linux image is also copied there seemed reasonable (I might be wrong here) because once loading is done and we jump to Linux there is no need for barebox code anymore.
In any case, at that time when I thought it was wrong I also tried to run the bootm command with "-a 0" but I got exactly the same error:
barebox:/ bootm -o /dev/mtdrom0.oftree -r /dev/mtdrom0.rootfs -a 0 /dev/mtdrom0.kernel
getopt: optindex: 1 nonopts: 0 optind: 1
getopt: optindex: 1 nonopts: 0 optind: 3
getopt: optindex: 1 nonopts: 0 optind: 5
getopt: optindex: 1 nonopts: 0 optind: 7
mtdrom0.kernel: read ofs: 0x00000000 count: 0x00001000
Loading ARM aarch64 Linux image '/dev/mtdrom0.kernel'
header 00000000: 4d 5a 40 fa 3f 1a 23 14 00 00 00 00 00 00 00 00 MZ@.?.#.........
header 00000010: 00 00 b3 00 00 00 00 00 0a 00 00 00 00 00 00 00 ................
header 00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
header 00000030: 00 00 00 00 00 00 00 00 41 52 4d 64 40 00 00 00 ........ARMd@...
header 00000040: 50 45 00 00 64 aa 02 00 00 00 00 00 00 00 00 00 PE..d...........
booti: Kernel to be loaded to 0+b30000
__request_region ok: 0x00000000:0x0001ffff flags=0x200
mtdrom0.kernel: read ofs: 0x00000000 count: 0x00020000
__request_region ok: 0x00000000:0x0003ffff flags=0x200
mtdrom0.kernel: read ofs: 0x00020000 count: 0x00020000
__request_region ok: 0x00000000:0x0005ffff flags=0x200
.
.
mtdrom0.kernel: read ofs: 0x00fe0000 count: 0x00018000
__request_region ok: 0x00000000:0x00ff7fff flags=0x200
mtdrom0.rootfs: read ofs: 0x00000000 count: 0x00000800
__request_region: 0x00b30000:0x00b4ffff (image) conflicts with 0x00000000:0x00ff7fff (image)
unable to request SDRAM 0x00b30000-0x00b4ffff
handler failed with: Out of memory
The iomem before:
barebox:/ iomem
0x0000000000000000 - 0xffffffffffffffff (size 0x0000000000000000) iomem
0x0000000000000000 - 0x000000001fffffff (size 0x0000000020000000) ram0
0x00000000079fef00 - 0x0000000007dfeeff (size 0x0000000000400000) malloc space
0x0000000007dfef00 - 0x0000000007dfffd1 (size 0x00000000000010d2) board data
0x0000000007e00000 - 0x0000000007e3d95f (size 0x000000000003d960) barebox
0x0000000007e3d960 - 0x0000000007e50bb7 (size 0x0000000000013258) barebox data
0x0000000007e50bb8 - 0x0000000007e53b3f (size 0x0000000000002f88) bss
0x0000000007ff0000 - 0x0000000007ff7fff (size 0x0000000000008000) stack
0x0000000020000000 - 0x000000002fffffff (size 0x0000000010000000) 20000000.flash@0.of
0x000000d000307000 - 0x000000d000307fff (size 0x0000000000001000) amba
After:
barebox:/ iomem
0x0000000000000000 - 0xffffffffffffffff (size 0x0000000000000000) iomem
0x0000000000000000 - 0x000000001fffffff (size 0x0000000020000000) ram0
0x00000000079fef00 - 0x0000000007dfeeff (size 0x0000000000400000) malloc space
0x0000000007dfef00 - 0x0000000007dfffd1 (size 0x00000000000010d2) board data
0x0000000007e00000 - 0x0000000007e3d95f (size 0x000000000003d960) barebox
0x0000000007e3d960 - 0x0000000007e50bb7 (size 0x0000000000013258) barebox data
0x0000000007e50bb8 - 0x0000000007e53b3f (size 0x0000000000002f88) bss
0x0000000007ff0000 - 0x0000000007ff7fff (size 0x0000000000008000) stack
0x0000000020000000 - 0x000000002fffffff (size 0x0000000010000000) 20000000.flash@0.of
0x000000d000307000 - 0x000000d000307fff (size 0x0000000000001000) amba
I did not set global.bootm.image.loadaddr
Speaking of env, the last few lines on the barebox terminal are:
initcall-> load_environment+0x0/0x4c
loading defaultenv
environment load /dev/env0: No such file or directory
Maybe you have to create the partition.
initcalls done
When I run "printenv" I am getting:
barebox:/ printenv
locals:
globals:
bootsource=unknown
bootsource_instance=unknown
PATH=/env/bin
Hope this info can help.
Cheers,
Lior.
> -----Original Message-----
> From: Ahmad Fatoum <a.fatoum@pengutronix.de>
> Sent: Tuesday, June 13, 2023 3:51 PM
> To: Lior Weintraub <liorw@pliops.com>; Ahmad Fatoum <ahmad@a3f.at>;
> barebox@lists.infradead.org
> Subject: Re: [PATCH v2] Porting barebox to a new SoC
>
> CAUTION: External Sender
>
> On 13.06.23 14:39, Lior Weintraub wrote:
> > Hi Ahmad,
> >
> > As usual, your comments are spot on :-)
> >
> > After fixing the DT, devinfo command shows correct flash node:
> > `-- 20000000.flash@0.of
> > `-- mtdrom0
> > `-- 0x00000000-0x0fffffff ( 256 MiB): /dev/mtdrom0
> > `-- mtdrom0.kernel
> > `-- 0x00000000-0x00ff7fff ( 16 MiB): /dev/mtdrom0.kernel
> > `-- mtdrom0.oftree
> > `-- 0x00000000-0x00007fff ( 32 KiB): /dev/mtdrom0.oftree
> > `-- mtdrom0.rootfs
> > `-- 0x00000000-0x007fffff ( 8 MiB): /dev/mtdrom0.rootfs
> >
> > As can be seen above, we chose to map this "flash" node on DRAM address
> 0x20000000 (offset 512MB).
> > The BL1 code correctly copy the 3 artifacts into those location (verified the
> content via "md -l -s /dev/mtdrom0.kernel").
> > Running "drvinfo" shows:
> > mtdram
> > 20000000.flash@0.of
> >
> > Now when I try to run "bootm -o /dev/mtdrom0.oftree -r
> /dev/mtdrom0.rootfs /dev/mtdrom0.kernel" I am getting this error:
> >
> > barebox:/ bootm -o /dev/mtdrom0.oftree -r /dev/mtdrom0.rootfs
> /dev/mtdrom0.kernel
> > getopt: optindex: 1 nonopts: 0 optind: 1
> > getopt: optindex: 1 nonopts: 0 optind: 3
> > getopt: optindex: 1 nonopts: 0 optind: 5
> > mtdrom0.kernel: read ofs: 0x00000000 count: 0x00001000
> >
> > Loading ARM aarch64 Linux image '/dev/mtdrom0.kernel'
> > header 00000000: 4d 5a 40 fa 3f 1a 23 14 00 00 00 00 00 00 00 00
> MZ@.?.#.........
> > header 00000010: 00 00 b3 00 00 00 00 00 0a 00 00 00 00 00 00 00
> ................
> > header 00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> ................
> > header 00000030: 00 00 00 00 00 00 00 00 41 52 4d 64 40 00 00 00
> ........ARMd@...
> > header 00000040: 50 45 00 00 64 aa 02 00 00 00 00 00 00 00 00 00
> PE..d...........
> > booti: Kernel to be loaded to 8000000+b30000
>
> Kernel image is relocatable and ARM64 header in hexdump says that
> load offset is zero. Yet, barebox wants to load your image to
> 8000000, which is already reserved.
>
> What's the output of the iomem command before and after the failed
> boot attempt?
>
> > __request_region ok: 0x08000000:0x0801ffff flags=0x200
> > mtdrom0.kernel: read ofs: 0x00000000 count: 0x00020000
> > __request_region ok: 0x08000000:0x0803ffff flags=0x200
> > mtdrom0.kernel: read ofs: 0x00020000 count: 0x00020000
> > .
> > .
> > mtdrom0.kernel: read ofs: 0x00fe0000 count: 0x00018000
> > __request_region ok: 0x08000000:0x08ff7fff flags=0x200
> > mtdrom0.rootfs: read ofs: 0x00000000 count: 0x00000800
> > __request_region: 0x08b30000:0x08b4ffff (image) conflicts with
> 0x08000000:0x08ff7fff (image)
> > unable to request SDRAM 0x08b30000-0x08b4ffff
> > handler failed with: Out of memory
>
> Just to be sure: You don't set global.bootm.image.loadaddr, right?
>
> Cheers,
> Ahmad
>
> >
> > Appreciate your advice,
> > Cheers,
> > Lior.
> >
> >
> >> -----Original Message-----
> >> From: Ahmad Fatoum <a.fatoum@pengutronix.de>
> >> Sent: Monday, June 12, 2023 6:08 PM
> >> To: Lior Weintraub <liorw@pliops.com>; Ahmad Fatoum <ahmad@a3f.at>;
> >> barebox@lists.infradead.org
> >> Subject: Re: [PATCH v2] Porting barebox to a new SoC
> >>
> >> CAUTION: External Sender
> >>
> >> Hi,
> >>
> >> On 12.06.23 16:59, Lior Weintraub wrote:
> >>> Hello Ahmad,
> >>>
> >>> Just for simple simulations we make the ROM size 192MB so it can include
> all
> >> needed artifacts.
> >>
> >> I am not convinced that this is much of a simplification over having
> >> your Qemu machine provide cfi-flash.
> >>
> >>> When we get this simple system to work we will move the relevant parts
> to
> >> BL2.
> >>
> >> Ok.
> >>
> >>> DRAM is also simulated now as SRAM so we are not worried about
> >> initializations.
> >>>
> >>> So if I understand correctly, we can decide that address 0x10000000 will
> be
> >> reserved for "flash" and add the following node:
> >>> flash@0 {
> >>
> >> flash@10000000, but that's just for informational purposes.
> >>
> >>> compatible = "mtd-rom";
> >>> probe-type = "map_rom";
> >>> reg = <0x10000000 0x10000000>;
> >>> bank-width = <4>;
> >>> device-width = <1>;
> >>>
> >>> #address-cells = <1>;
> >>> #size-cells = <1>;
> >>> kernel@0 {
> >>> label = "kernel";
> >>> reg = <0x0 0x01000000>;
> >>> };
> >>> rootfs@1000000 {
> >>> label = "rootfs";
> >>> reg = <0x01000000 0x00800000>;
> >>> };
> >>> };
> >>>
> >>> When I use this node on our DT I see the following devinfo:
> >>> barebox:/ devinfo
> >>> `-- global
> >>> `-- nv
> >>> `-- platform
> >>> `-- machine
> >>> `-- psci.of
> >>> `-- 1000000010000000.flash@0.of
> >>
> >> As you can see the address is wrong. That's because you have
> >> #address-cells = <2>;
> >> #size-cells = <2>;
> >>
> >> Yet, you wrote reg as if it was <1>/<1>. Change it to
> >>
> >> reg = <0x0 0x10000000 0x0 0x10000000>;
> >>
> >> Remember all device tree integers are 32-bit big endian.
> >>
> >>> `-- soc.of
> >>> `-- c000000000.sram@c000000000.of
> >>> `-- soc:pmu.of
> >>> `-- soc:timer.of
> >>> `-- e000000000.interrupt-controller@E000000000.of
> >>> `-- mem0
> >>> `-- 0x00000000-0x0fffffff ( 256 MiB): /dev/ram0
> >>> `-- mem1
> >>> `-- 0x00000000-0xffffffffffffffff ( 0 Bytes): /dev/mem
> >>> `-- amba
> >>> `-- d000307000.serial@d000307000.of
> >>> `-- cs0
> >>> `-- 0x00000000-0xffffffffffffffff ( 0 Bytes): /dev/cs0
> >>> `-- spi
> >>> `-- fs
> >>> `-- ramfs0
> >>> `-- devfs0
> >>> `-- pstore0
> >>>
> >>> Not sure how to proceed from here...
> >>
> >> Type drvinfo command to see what drivers are bound to what devices.
> >> If you see no driver bound to your flash device, then maybe you need
> >> to enable the correct driver, that would be CONFIG_MTD_MTDRAM (which
> >> handles both read-only and read-write memory mapped MTD).
> >>
> >> Cheers,
> >> Ahmad
> >>
> >>> Cheers,
> >>> Lior.
> >>>
> >>>> -----Original Message-----
> >>>> From: Ahmad Fatoum <a.fatoum@pengutronix.de>
> >>>> Sent: Monday, June 12, 2023 3:29 PM
> >>>> To: Lior Weintraub <liorw@pliops.com>; Ahmad Fatoum
> <ahmad@a3f.at>;
> >>>> barebox@lists.infradead.org
> >>>> Subject: Re: [PATCH v2] Porting barebox to a new SoC
> >>>>
> >>>> CAUTION: External Sender
> >>>>
> >>>> Hello Lior,
> >>>>
> >>>> On 12.06.23 11:27, Lior Weintraub wrote:
> >>>>> Hi Ahmad,
> >>>>>
> >>>>> Regarding the rootfs and Linux run question:
> >>>>> Our board doesn't include eMMC\SD card.
> >>>>> We only have our NOR Flash to store the binaries and our BL1 code will
> >> make
> >>>> sure to copy those blobs into DRAM.
> >>>>
> >>>> How could BL1 copy artifacts in DRAM when BL2 first needs to set up
> >> DRAM?
> >>>>
> >>>>> The use of QEMU needs to be as simple as possible so no hidden virtio
> >>>> drivers and such because we would like to simulate the real HW flow.
> >>>>
> >>>> cfi-flash is just memory-mapped flash, which is the next simplest thing
> >>>> after BL1 copies stuff into (limited-to-4M) on-chip SRAM.
> >>>>
> >>>>> Our DTS file now includes the GIC, timer and arm,psci-1.0.
> >>>>> We have an initial build of Linux kernel Image (using buildroot) and a
> >>>> rootfs.cpio.xz.
> >>>>> I assume we can somehow reserve a portion of the DRAM to store
> those
> >>>> binaries and let barebox boot this Linux.
> >>>>
> >>>> You can make this work, but this is not how your actual system will
> >>>> look like and trying to make this work is harder than it needs to be.
> >>>>
> >>>> Just add a cfi-flash that corresponds to the Linux/rootfs flash in
> >>>> your actual system, then boot with bootm (type help bootm for info
> >>>> on how to use it). You don't need to hardcode the load addresses,
> >>>> barebox will determine them automatically.
> >>>>
> >>>>> Can you please advise how to make it work?
> >>>>
> >>>> For completion's sake, if you have 64M of RAM that's preloaded with
> >>>> boot images:
> >>>>
> >>>> - Remove the 64M from the barebox /memory node. You can use a
> >> different
> >>>> DT for kernel, but if you have memory that barebox shouldn't override,
> >>>> you need to tell it that.
> >>>>
> >>>> - Add a mtd-rom node that describes these 64M that you have. You can
> >>>> add partitions for the region used for kernel and oftree
> >>>>
> >>>> - boot with bootm -o /dev/mtdrom0.oftree -r /dev/mtdrom0.initrd \
> >>>> /dev/mtdrom0.kernel
> >>>>
> >>>> That's admittedly cumbersome, but necessary, so barebox knows what
> >>>> memory
> >>>> it may use for itself and what memory may be used for boot.
> >>>>
> >>>> Correct solution is to use cfi-flash or similar.
> >>>>
> >>>> Cheers,
> >>>> Ahmad
> >>>> --
> >>>> Pengutronix e.K. | |
> >>>> Steuerwalder Str. 21 | http://www.pengutronix.de/ |
> >>>> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
> >>>> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555
> |
> >>>
> >>
> >> --
> >> Pengutronix e.K. | |
> >> Steuerwalder Str. 21 | http://www.pengutronix.de/ |
> >> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
> >> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
> >
>
> --
> Pengutronix e.K. | |
> Steuerwalder Str. 21 | http://www.pengutronix.de/ |
> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply [flat|nested] 40+ messages in thread
* RE: [PATCH v2] Porting barebox to a new SoC
2023-06-13 13:27 ` Lior Weintraub
@ 2023-06-14 6:42 ` Lior Weintraub
2023-06-16 16:20 ` Ahmad Fatoum
0 siblings, 1 reply; 40+ messages in thread
From: Lior Weintraub @ 2023-06-14 6:42 UTC (permalink / raw)
To: Ahmad Fatoum, Ahmad Fatoum, barebox
Hi Ahmad,
Looks like I found the issue :-)
When I declared the flash@0 node I used about 16MB for the kernel partition even though currently my kernel image is around 11MB:
flash@0 {
compatible = "mtd-rom";
probe-type = "map_rom";
reg = <0x0 0x20000000 0x0 0x10000000>; /* Offset 512MB, size 256MB */
bank-width = <4>;
device-width = <1>;
#address-cells = <1>;
#size-cells = <1>;
kernel@0 { /* 16MB (minus 32KB) */
label = "kernel";
//reg = <0x0 0x00FF8000>; // This line caused the error
reg = <0x0 0x00b30000>;
};
oftree@00FF8000 { /* 32KB for DTB image */
label = "oftree";
reg = <0x00FF8000 0x00008000>;
};
rootfs@1000000 { /* Offset 512MB+16MB with size 8MB */
label = "rootfs";
reg = <0x01000000 0x00800000>;
};
};
From the error message I saw that barebox tried to place the rootfs on address 0xb30000 and that conflicted with the kernel:
mtdrom0.kernel: read ofs: 0x00fe0000 count: 0x00018000
__request_region ok: 0x00000000:0x00ff7fff flags=0x200
mtdrom0.rootfs: read ofs: 0x00000000 count: 0x00000800
__request_region: 0x00b30000:0x00b4ffff (image) conflicts with 0x00000000:0x00ff7fff (image)
So I changed the kernel@0 node and used size 0x00b30000 and now kernel starts running.
The kernel is producing all kinds of errors but at least it's a start :-)
The errors are now related to pieces of HW that we didn't implement on QEMU so it is understandable.
How can we control where the rootfs is copied to?
Thanks again for your kind advise and patience.
Cheers,
Lior.
> -----Original Message-----
> From: Lior Weintraub
> Sent: Tuesday, June 13, 2023 4:28 PM
> To: Ahmad Fatoum <a.fatoum@pengutronix.de>; Ahmad Fatoum
> <ahmad@a3f.at>; barebox@lists.infradead.org
> Subject: RE: [PATCH v2] Porting barebox to a new SoC
>
> Hi Ahmad,
>
> I also thought that load address was suspicious (0x8000000) but then I saw
> the following comment on nxp_imx8mq_evk_start:
> /*
> * On completion the TF-A will jump to
> MX8MQ_ATF_BL33_BASE_ADDR
> * in EL2. Copy the image there, but replace the PBL part of
> * that image with ourselves. On a high assurance boot only
> the
> * currently running code is validated and contains the
> checksum
> * for the piggy data, so we need to ensure that we are
> running
> * the same code in DRAM.
> */
> Our code was based on this function and as a result it copies the barebox
> image into address 0x8000000 (which is our settings of
> ATF_BL33_BASE_ADDR).
> The fact that Linux image is also copied there seemed reasonable (I might be
> wrong here) because once loading is done and we jump to Linux there is no
> need for barebox code anymore.
>
> In any case, at that time when I thought it was wrong I also tried to run the
> bootm command with "-a 0" but I got exactly the same error:
> barebox:/ bootm -o /dev/mtdrom0.oftree -r /dev/mtdrom0.rootfs -a 0
> /dev/mtdrom0.kernel
> getopt: optindex: 1 nonopts: 0 optind: 1
> getopt: optindex: 1 nonopts: 0 optind: 3
> getopt: optindex: 1 nonopts: 0 optind: 5
> getopt: optindex: 1 nonopts: 0 optind: 7
> mtdrom0.kernel: read ofs: 0x00000000 count: 0x00001000
>
> Loading ARM aarch64 Linux image '/dev/mtdrom0.kernel'
> header 00000000: 4d 5a 40 fa 3f 1a 23 14 00 00 00 00 00 00 00 00
> MZ@.?.#.........
> header 00000010: 00 00 b3 00 00 00 00 00 0a 00 00 00 00 00 00 00
> ................
> header 00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> ................
> header 00000030: 00 00 00 00 00 00 00 00 41 52 4d 64 40 00 00 00
> ........ARMd@...
> header 00000040: 50 45 00 00 64 aa 02 00 00 00 00 00 00 00 00 00
> PE..d...........
> booti: Kernel to be loaded to 0+b30000
> __request_region ok: 0x00000000:0x0001ffff flags=0x200
> mtdrom0.kernel: read ofs: 0x00000000 count: 0x00020000
> __request_region ok: 0x00000000:0x0003ffff flags=0x200
> mtdrom0.kernel: read ofs: 0x00020000 count: 0x00020000
> __request_region ok: 0x00000000:0x0005ffff flags=0x200
> .
> .
> mtdrom0.kernel: read ofs: 0x00fe0000 count: 0x00018000
> __request_region ok: 0x00000000:0x00ff7fff flags=0x200
> mtdrom0.rootfs: read ofs: 0x00000000 count: 0x00000800
> __request_region: 0x00b30000:0x00b4ffff (image) conflicts with
> 0x00000000:0x00ff7fff (image)
> unable to request SDRAM 0x00b30000-0x00b4ffff
> handler failed with: Out of memory
>
>
> The iomem before:
> barebox:/ iomem
> 0x0000000000000000 - 0xffffffffffffffff (size 0x0000000000000000) iomem
> 0x0000000000000000 - 0x000000001fffffff (size 0x0000000020000000)
> ram0
> 0x00000000079fef00 - 0x0000000007dfeeff (size 0x0000000000400000)
> malloc space
> 0x0000000007dfef00 - 0x0000000007dfffd1 (size 0x00000000000010d2)
> board data
> 0x0000000007e00000 - 0x0000000007e3d95f (size
> 0x000000000003d960) barebox
> 0x0000000007e3d960 - 0x0000000007e50bb7 (size
> 0x0000000000013258) barebox data
> 0x0000000007e50bb8 - 0x0000000007e53b3f (size
> 0x0000000000002f88) bss
> 0x0000000007ff0000 - 0x0000000007ff7fff (size 0x0000000000008000)
> stack
> 0x0000000020000000 - 0x000000002fffffff (size 0x0000000010000000)
> 20000000.flash@0.of
> 0x000000d000307000 - 0x000000d000307fff (size
> 0x0000000000001000) amba
>
> After:
> barebox:/ iomem
> 0x0000000000000000 - 0xffffffffffffffff (size 0x0000000000000000) iomem
> 0x0000000000000000 - 0x000000001fffffff (size 0x0000000020000000)
> ram0
> 0x00000000079fef00 - 0x0000000007dfeeff (size 0x0000000000400000)
> malloc space
> 0x0000000007dfef00 - 0x0000000007dfffd1 (size 0x00000000000010d2)
> board data
> 0x0000000007e00000 - 0x0000000007e3d95f (size
> 0x000000000003d960) barebox
> 0x0000000007e3d960 - 0x0000000007e50bb7 (size
> 0x0000000000013258) barebox data
> 0x0000000007e50bb8 - 0x0000000007e53b3f (size
> 0x0000000000002f88) bss
> 0x0000000007ff0000 - 0x0000000007ff7fff (size 0x0000000000008000)
> stack
> 0x0000000020000000 - 0x000000002fffffff (size 0x0000000010000000)
> 20000000.flash@0.of
> 0x000000d000307000 - 0x000000d000307fff (size
> 0x0000000000001000) amba
>
> I did not set global.bootm.image.loadaddr
> Speaking of env, the last few lines on the barebox terminal are:
> initcall-> load_environment+0x0/0x4c
> loading defaultenv
> environment load /dev/env0: No such file or directory
> Maybe you have to create the partition.
> initcalls done
>
> When I run "printenv" I am getting:
> barebox:/ printenv
> locals:
> globals:
> bootsource=unknown
> bootsource_instance=unknown
> PATH=/env/bin
>
> Hope this info can help.
> Cheers,
> Lior.
>
>
> > -----Original Message-----
> > From: Ahmad Fatoum <a.fatoum@pengutronix.de>
> > Sent: Tuesday, June 13, 2023 3:51 PM
> > To: Lior Weintraub <liorw@pliops.com>; Ahmad Fatoum <ahmad@a3f.at>;
> > barebox@lists.infradead.org
> > Subject: Re: [PATCH v2] Porting barebox to a new SoC
> >
> > CAUTION: External Sender
> >
> > On 13.06.23 14:39, Lior Weintraub wrote:
> > > Hi Ahmad,
> > >
> > > As usual, your comments are spot on :-)
> > >
> > > After fixing the DT, devinfo command shows correct flash node:
> > > `-- 20000000.flash@0.of
> > > `-- mtdrom0
> > > `-- 0x00000000-0x0fffffff ( 256 MiB): /dev/mtdrom0
> > > `-- mtdrom0.kernel
> > > `-- 0x00000000-0x00ff7fff ( 16 MiB): /dev/mtdrom0.kernel
> > > `-- mtdrom0.oftree
> > > `-- 0x00000000-0x00007fff ( 32 KiB): /dev/mtdrom0.oftree
> > > `-- mtdrom0.rootfs
> > > `-- 0x00000000-0x007fffff ( 8 MiB): /dev/mtdrom0.rootfs
> > >
> > > As can be seen above, we chose to map this "flash" node on DRAM
> address
> > 0x20000000 (offset 512MB).
> > > The BL1 code correctly copy the 3 artifacts into those location (verified the
> > content via "md -l -s /dev/mtdrom0.kernel").
> > > Running "drvinfo" shows:
> > > mtdram
> > > 20000000.flash@0.of
> > >
> > > Now when I try to run "bootm -o /dev/mtdrom0.oftree -r
> > /dev/mtdrom0.rootfs /dev/mtdrom0.kernel" I am getting this error:
> > >
> > > barebox:/ bootm -o /dev/mtdrom0.oftree -r /dev/mtdrom0.rootfs
> > /dev/mtdrom0.kernel
> > > getopt: optindex: 1 nonopts: 0 optind: 1
> > > getopt: optindex: 1 nonopts: 0 optind: 3
> > > getopt: optindex: 1 nonopts: 0 optind: 5
> > > mtdrom0.kernel: read ofs: 0x00000000 count: 0x00001000
> > >
> > > Loading ARM aarch64 Linux image '/dev/mtdrom0.kernel'
> > > header 00000000: 4d 5a 40 fa 3f 1a 23 14 00 00 00 00 00 00 00 00
> > MZ@.?.#.........
> > > header 00000010: 00 00 b3 00 00 00 00 00 0a 00 00 00 00 00 00 00
> > ................
> > > header 00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > ................
> > > header 00000030: 00 00 00 00 00 00 00 00 41 52 4d 64 40 00 00 00
> > ........ARMd@...
> > > header 00000040: 50 45 00 00 64 aa 02 00 00 00 00 00 00 00 00 00
> > PE..d...........
> > > booti: Kernel to be loaded to 8000000+b30000
> >
> > Kernel image is relocatable and ARM64 header in hexdump says that
> > load offset is zero. Yet, barebox wants to load your image to
> > 8000000, which is already reserved.
> >
> > What's the output of the iomem command before and after the failed
> > boot attempt?
> >
> > > __request_region ok: 0x08000000:0x0801ffff flags=0x200
> > > mtdrom0.kernel: read ofs: 0x00000000 count: 0x00020000
> > > __request_region ok: 0x08000000:0x0803ffff flags=0x200
> > > mtdrom0.kernel: read ofs: 0x00020000 count: 0x00020000
> > > .
> > > .
> > > mtdrom0.kernel: read ofs: 0x00fe0000 count: 0x00018000
> > > __request_region ok: 0x08000000:0x08ff7fff flags=0x200
> > > mtdrom0.rootfs: read ofs: 0x00000000 count: 0x00000800
> > > __request_region: 0x08b30000:0x08b4ffff (image) conflicts with
> > 0x08000000:0x08ff7fff (image)
> > > unable to request SDRAM 0x08b30000-0x08b4ffff
> > > handler failed with: Out of memory
> >
> > Just to be sure: You don't set global.bootm.image.loadaddr, right?
> >
> > Cheers,
> > Ahmad
> >
> > >
> > > Appreciate your advice,
> > > Cheers,
> > > Lior.
> > >
> > >
> > >> -----Original Message-----
> > >> From: Ahmad Fatoum <a.fatoum@pengutronix.de>
> > >> Sent: Monday, June 12, 2023 6:08 PM
> > >> To: Lior Weintraub <liorw@pliops.com>; Ahmad Fatoum
> <ahmad@a3f.at>;
> > >> barebox@lists.infradead.org
> > >> Subject: Re: [PATCH v2] Porting barebox to a new SoC
> > >>
> > >> CAUTION: External Sender
> > >>
> > >> Hi,
> > >>
> > >> On 12.06.23 16:59, Lior Weintraub wrote:
> > >>> Hello Ahmad,
> > >>>
> > >>> Just for simple simulations we make the ROM size 192MB so it can
> include
> > all
> > >> needed artifacts.
> > >>
> > >> I am not convinced that this is much of a simplification over having
> > >> your Qemu machine provide cfi-flash.
> > >>
> > >>> When we get this simple system to work we will move the relevant parts
> > to
> > >> BL2.
> > >>
> > >> Ok.
> > >>
> > >>> DRAM is also simulated now as SRAM so we are not worried about
> > >> initializations.
> > >>>
> > >>> So if I understand correctly, we can decide that address 0x10000000 will
> > be
> > >> reserved for "flash" and add the following node:
> > >>> flash@0 {
> > >>
> > >> flash@10000000, but that's just for informational purposes.
> > >>
> > >>> compatible = "mtd-rom";
> > >>> probe-type = "map_rom";
> > >>> reg = <0x10000000 0x10000000>;
> > >>> bank-width = <4>;
> > >>> device-width = <1>;
> > >>>
> > >>> #address-cells = <1>;
> > >>> #size-cells = <1>;
> > >>> kernel@0 {
> > >>> label = "kernel";
> > >>> reg = <0x0 0x01000000>;
> > >>> };
> > >>> rootfs@1000000 {
> > >>> label = "rootfs";
> > >>> reg = <0x01000000 0x00800000>;
> > >>> };
> > >>> };
> > >>>
> > >>> When I use this node on our DT I see the following devinfo:
> > >>> barebox:/ devinfo
> > >>> `-- global
> > >>> `-- nv
> > >>> `-- platform
> > >>> `-- machine
> > >>> `-- psci.of
> > >>> `-- 1000000010000000.flash@0.of
> > >>
> > >> As you can see the address is wrong. That's because you have
> > >> #address-cells = <2>;
> > >> #size-cells = <2>;
> > >>
> > >> Yet, you wrote reg as if it was <1>/<1>. Change it to
> > >>
> > >> reg = <0x0 0x10000000 0x0 0x10000000>;
> > >>
> > >> Remember all device tree integers are 32-bit big endian.
> > >>
> > >>> `-- soc.of
> > >>> `-- c000000000.sram@c000000000.of
> > >>> `-- soc:pmu.of
> > >>> `-- soc:timer.of
> > >>> `-- e000000000.interrupt-controller@E000000000.of
> > >>> `-- mem0
> > >>> `-- 0x00000000-0x0fffffff ( 256 MiB): /dev/ram0
> > >>> `-- mem1
> > >>> `-- 0x00000000-0xffffffffffffffff ( 0 Bytes): /dev/mem
> > >>> `-- amba
> > >>> `-- d000307000.serial@d000307000.of
> > >>> `-- cs0
> > >>> `-- 0x00000000-0xffffffffffffffff ( 0 Bytes): /dev/cs0
> > >>> `-- spi
> > >>> `-- fs
> > >>> `-- ramfs0
> > >>> `-- devfs0
> > >>> `-- pstore0
> > >>>
> > >>> Not sure how to proceed from here...
> > >>
> > >> Type drvinfo command to see what drivers are bound to what devices.
> > >> If you see no driver bound to your flash device, then maybe you need
> > >> to enable the correct driver, that would be CONFIG_MTD_MTDRAM
> (which
> > >> handles both read-only and read-write memory mapped MTD).
> > >>
> > >> Cheers,
> > >> Ahmad
> > >>
> > >>> Cheers,
> > >>> Lior.
> > >>>
> > >>>> -----Original Message-----
> > >>>> From: Ahmad Fatoum <a.fatoum@pengutronix.de>
> > >>>> Sent: Monday, June 12, 2023 3:29 PM
> > >>>> To: Lior Weintraub <liorw@pliops.com>; Ahmad Fatoum
> > <ahmad@a3f.at>;
> > >>>> barebox@lists.infradead.org
> > >>>> Subject: Re: [PATCH v2] Porting barebox to a new SoC
> > >>>>
> > >>>> CAUTION: External Sender
> > >>>>
> > >>>> Hello Lior,
> > >>>>
> > >>>> On 12.06.23 11:27, Lior Weintraub wrote:
> > >>>>> Hi Ahmad,
> > >>>>>
> > >>>>> Regarding the rootfs and Linux run question:
> > >>>>> Our board doesn't include eMMC\SD card.
> > >>>>> We only have our NOR Flash to store the binaries and our BL1 code
> will
> > >> make
> > >>>> sure to copy those blobs into DRAM.
> > >>>>
> > >>>> How could BL1 copy artifacts in DRAM when BL2 first needs to set up
> > >> DRAM?
> > >>>>
> > >>>>> The use of QEMU needs to be as simple as possible so no hidden virtio
> > >>>> drivers and such because we would like to simulate the real HW flow.
> > >>>>
> > >>>> cfi-flash is just memory-mapped flash, which is the next simplest thing
> > >>>> after BL1 copies stuff into (limited-to-4M) on-chip SRAM.
> > >>>>
> > >>>>> Our DTS file now includes the GIC, timer and arm,psci-1.0.
> > >>>>> We have an initial build of Linux kernel Image (using buildroot) and a
> > >>>> rootfs.cpio.xz.
> > >>>>> I assume we can somehow reserve a portion of the DRAM to store
> > those
> > >>>> binaries and let barebox boot this Linux.
> > >>>>
> > >>>> You can make this work, but this is not how your actual system will
> > >>>> look like and trying to make this work is harder than it needs to be.
> > >>>>
> > >>>> Just add a cfi-flash that corresponds to the Linux/rootfs flash in
> > >>>> your actual system, then boot with bootm (type help bootm for info
> > >>>> on how to use it). You don't need to hardcode the load addresses,
> > >>>> barebox will determine them automatically.
> > >>>>
> > >>>>> Can you please advise how to make it work?
> > >>>>
> > >>>> For completion's sake, if you have 64M of RAM that's preloaded with
> > >>>> boot images:
> > >>>>
> > >>>> - Remove the 64M from the barebox /memory node. You can use a
> > >> different
> > >>>> DT for kernel, but if you have memory that barebox shouldn't
> override,
> > >>>> you need to tell it that.
> > >>>>
> > >>>> - Add a mtd-rom node that describes these 64M that you have. You
> can
> > >>>> add partitions for the region used for kernel and oftree
> > >>>>
> > >>>> - boot with bootm -o /dev/mtdrom0.oftree -r /dev/mtdrom0.initrd \
> > >>>> /dev/mtdrom0.kernel
> > >>>>
> > >>>> That's admittedly cumbersome, but necessary, so barebox knows what
> > >>>> memory
> > >>>> it may use for itself and what memory may be used for boot.
> > >>>>
> > >>>> Correct solution is to use cfi-flash or similar.
> > >>>>
> > >>>> Cheers,
> > >>>> Ahmad
> > >>>> --
> > >>>> Pengutronix e.K. | |
> > >>>> Steuerwalder Str. 21 | http://www.pengutronix.de/ |
> > >>>> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
> > >>>> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-
> 5555
> > |
> > >>>
> > >>
> > >> --
> > >> Pengutronix e.K. | |
> > >> Steuerwalder Str. 21 | http://www.pengutronix.de/ |
> > >> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
> > >> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555
> |
> > >
> >
> > --
> > Pengutronix e.K. | |
> > Steuerwalder Str. 21 | http://www.pengutronix.de/ |
> > 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
> > Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [PATCH v2] Porting barebox to a new SoC
2023-06-14 6:42 ` Lior Weintraub
@ 2023-06-16 16:20 ` Ahmad Fatoum
2023-06-19 6:40 ` Lior Weintraub
0 siblings, 1 reply; 40+ messages in thread
From: Ahmad Fatoum @ 2023-06-16 16:20 UTC (permalink / raw)
To: Lior Weintraub, Ahmad Fatoum, barebox
Hello Lior,
On 14.06.23 08:42, Lior Weintraub wrote:
> Hi Ahmad,
>
> Looks like I found the issue :-)
>
> When I declared the flash@0 node I used about 16MB for the kernel partition even though currently my kernel image is around 11MB:
> flash@0 {
> compatible = "mtd-rom";
> probe-type = "map_rom";
> reg = <0x0 0x20000000 0x0 0x10000000>; /* Offset 512MB, size 256MB */
> bank-width = <4>;
> device-width = <1>;
>
> #address-cells = <1>;
> #size-cells = <1>;
> kernel@0 { /* 16MB (minus 32KB) */
> label = "kernel";
> //reg = <0x0 0x00FF8000>; // This line caused the error
> reg = <0x0 0x00b30000>;
> };
> oftree@00FF8000 { /* 32KB for DTB image */
> label = "oftree";
> reg = <0x00FF8000 0x00008000>;
> };
> rootfs@1000000 { /* Offset 512MB+16MB with size 8MB */
> label = "rootfs";
> reg = <0x01000000 0x00800000>;
> };
> };
>
> From the error message I saw that barebox tried to place the rootfs on address 0xb30000 and that conflicted with the kernel:
> mtdrom0.kernel: read ofs: 0x00fe0000 count: 0x00018000
> __request_region ok: 0x00000000:0x00ff7fff flags=0x200
> mtdrom0.rootfs: read ofs: 0x00000000 count: 0x00000800
> __request_region: 0x00b30000:0x00b4ffff (image) conflicts with 0x00000000:0x00ff7fff (image)
This error message still doesn't make sense to me. No idea why this conflicts.
I see now though that I made this more complicated that it needs be. Please
scratch all that, remove the mtd-rom and revert the /memory node to encompass
all memory. Then you can at runtime, just create the partitions with the addpart
command (see help addpart for info). Then you can boot normally.
>
> So I changed the kernel@0 node and used size 0x00b30000 and now kernel starts running.
> The kernel is producing all kinds of errors but at least it's a start :-)
> The errors are now related to pieces of HW that we didn't implement on QEMU so it is understandable.
>
> How can we control where the rootfs is copied to?
Normally, global.bootm.initrd.loadaddr, but you shouldn't need to do
that. Try it with addpart and let me know.
Cheers,
Ahmad
>
> Thanks again for your kind advise and patience.
> Cheers,
> Lior.
>
>> -----Original Message-----
>> From: Lior Weintraub
>> Sent: Tuesday, June 13, 2023 4:28 PM
>> To: Ahmad Fatoum <a.fatoum@pengutronix.de>; Ahmad Fatoum
>> <ahmad@a3f.at>; barebox@lists.infradead.org
>> Subject: RE: [PATCH v2] Porting barebox to a new SoC
>>
>> Hi Ahmad,
>>
>> I also thought that load address was suspicious (0x8000000) but then I saw
>> the following comment on nxp_imx8mq_evk_start:
>> /*
>> * On completion the TF-A will jump to
>> MX8MQ_ATF_BL33_BASE_ADDR
>> * in EL2. Copy the image there, but replace the PBL part of
>> * that image with ourselves. On a high assurance boot only
>> the
>> * currently running code is validated and contains the
>> checksum
>> * for the piggy data, so we need to ensure that we are
>> running
>> * the same code in DRAM.
>> */
>> Our code was based on this function and as a result it copies the barebox
>> image into address 0x8000000 (which is our settings of
>> ATF_BL33_BASE_ADDR).
>> The fact that Linux image is also copied there seemed reasonable (I might be
>> wrong here) because once loading is done and we jump to Linux there is no
>> need for barebox code anymore.
>>
>> In any case, at that time when I thought it was wrong I also tried to run the
>> bootm command with "-a 0" but I got exactly the same error:
>> barebox:/ bootm -o /dev/mtdrom0.oftree -r /dev/mtdrom0.rootfs -a 0
>> /dev/mtdrom0.kernel
>> getopt: optindex: 1 nonopts: 0 optind: 1
>> getopt: optindex: 1 nonopts: 0 optind: 3
>> getopt: optindex: 1 nonopts: 0 optind: 5
>> getopt: optindex: 1 nonopts: 0 optind: 7
>> mtdrom0.kernel: read ofs: 0x00000000 count: 0x00001000
>>
>> Loading ARM aarch64 Linux image '/dev/mtdrom0.kernel'
>> header 00000000: 4d 5a 40 fa 3f 1a 23 14 00 00 00 00 00 00 00 00
>> MZ@.?.#.........
>> header 00000010: 00 00 b3 00 00 00 00 00 0a 00 00 00 00 00 00 00
>> ................
>> header 00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>> ................
>> header 00000030: 00 00 00 00 00 00 00 00 41 52 4d 64 40 00 00 00
>> ........ARMd@...
>> header 00000040: 50 45 00 00 64 aa 02 00 00 00 00 00 00 00 00 00
>> PE..d...........
>> booti: Kernel to be loaded to 0+b30000
>> __request_region ok: 0x00000000:0x0001ffff flags=0x200
>> mtdrom0.kernel: read ofs: 0x00000000 count: 0x00020000
>> __request_region ok: 0x00000000:0x0003ffff flags=0x200
>> mtdrom0.kernel: read ofs: 0x00020000 count: 0x00020000
>> __request_region ok: 0x00000000:0x0005ffff flags=0x200
>> .
>> .
>> mtdrom0.kernel: read ofs: 0x00fe0000 count: 0x00018000
>> __request_region ok: 0x00000000:0x00ff7fff flags=0x200
>> mtdrom0.rootfs: read ofs: 0x00000000 count: 0x00000800
>> __request_region: 0x00b30000:0x00b4ffff (image) conflicts with
>> 0x00000000:0x00ff7fff (image)
>> unable to request SDRAM 0x00b30000-0x00b4ffff
>> handler failed with: Out of memory
>>
>>
>> The iomem before:
>> barebox:/ iomem
>> 0x0000000000000000 - 0xffffffffffffffff (size 0x0000000000000000) iomem
>> 0x0000000000000000 - 0x000000001fffffff (size 0x0000000020000000)
>> ram0
>> 0x00000000079fef00 - 0x0000000007dfeeff (size 0x0000000000400000)
>> malloc space
>> 0x0000000007dfef00 - 0x0000000007dfffd1 (size 0x00000000000010d2)
>> board data
>> 0x0000000007e00000 - 0x0000000007e3d95f (size
>> 0x000000000003d960) barebox
>> 0x0000000007e3d960 - 0x0000000007e50bb7 (size
>> 0x0000000000013258) barebox data
>> 0x0000000007e50bb8 - 0x0000000007e53b3f (size
>> 0x0000000000002f88) bss
>> 0x0000000007ff0000 - 0x0000000007ff7fff (size 0x0000000000008000)
>> stack
>> 0x0000000020000000 - 0x000000002fffffff (size 0x0000000010000000)
>> 20000000.flash@0.of
>> 0x000000d000307000 - 0x000000d000307fff (size
>> 0x0000000000001000) amba
>>
>> After:
>> barebox:/ iomem
>> 0x0000000000000000 - 0xffffffffffffffff (size 0x0000000000000000) iomem
>> 0x0000000000000000 - 0x000000001fffffff (size 0x0000000020000000)
>> ram0
>> 0x00000000079fef00 - 0x0000000007dfeeff (size 0x0000000000400000)
>> malloc space
>> 0x0000000007dfef00 - 0x0000000007dfffd1 (size 0x00000000000010d2)
>> board data
>> 0x0000000007e00000 - 0x0000000007e3d95f (size
>> 0x000000000003d960) barebox
>> 0x0000000007e3d960 - 0x0000000007e50bb7 (size
>> 0x0000000000013258) barebox data
>> 0x0000000007e50bb8 - 0x0000000007e53b3f (size
>> 0x0000000000002f88) bss
>> 0x0000000007ff0000 - 0x0000000007ff7fff (size 0x0000000000008000)
>> stack
>> 0x0000000020000000 - 0x000000002fffffff (size 0x0000000010000000)
>> 20000000.flash@0.of
>> 0x000000d000307000 - 0x000000d000307fff (size
>> 0x0000000000001000) amba
>>
>> I did not set global.bootm.image.loadaddr
>> Speaking of env, the last few lines on the barebox terminal are:
>> initcall-> load_environment+0x0/0x4c
>> loading defaultenv
>> environment load /dev/env0: No such file or directory
>> Maybe you have to create the partition.
>> initcalls done
>>
>> When I run "printenv" I am getting:
>> barebox:/ printenv
>> locals:
>> globals:
>> bootsource=unknown
>> bootsource_instance=unknown
>> PATH=/env/bin
>>
>> Hope this info can help.
>> Cheers,
>> Lior.
>>
>>
>>> -----Original Message-----
>>> From: Ahmad Fatoum <a.fatoum@pengutronix.de>
>>> Sent: Tuesday, June 13, 2023 3:51 PM
>>> To: Lior Weintraub <liorw@pliops.com>; Ahmad Fatoum <ahmad@a3f.at>;
>>> barebox@lists.infradead.org
>>> Subject: Re: [PATCH v2] Porting barebox to a new SoC
>>>
>>> CAUTION: External Sender
>>>
>>> On 13.06.23 14:39, Lior Weintraub wrote:
>>>> Hi Ahmad,
>>>>
>>>> As usual, your comments are spot on :-)
>>>>
>>>> After fixing the DT, devinfo command shows correct flash node:
>>>> `-- 20000000.flash@0.of
>>>> `-- mtdrom0
>>>> `-- 0x00000000-0x0fffffff ( 256 MiB): /dev/mtdrom0
>>>> `-- mtdrom0.kernel
>>>> `-- 0x00000000-0x00ff7fff ( 16 MiB): /dev/mtdrom0.kernel
>>>> `-- mtdrom0.oftree
>>>> `-- 0x00000000-0x00007fff ( 32 KiB): /dev/mtdrom0.oftree
>>>> `-- mtdrom0.rootfs
>>>> `-- 0x00000000-0x007fffff ( 8 MiB): /dev/mtdrom0.rootfs
>>>>
>>>> As can be seen above, we chose to map this "flash" node on DRAM
>> address
>>> 0x20000000 (offset 512MB).
>>>> The BL1 code correctly copy the 3 artifacts into those location (verified the
>>> content via "md -l -s /dev/mtdrom0.kernel").
>>>> Running "drvinfo" shows:
>>>> mtdram
>>>> 20000000.flash@0.of
>>>>
>>>> Now when I try to run "bootm -o /dev/mtdrom0.oftree -r
>>> /dev/mtdrom0.rootfs /dev/mtdrom0.kernel" I am getting this error:
>>>>
>>>> barebox:/ bootm -o /dev/mtdrom0.oftree -r /dev/mtdrom0.rootfs
>>> /dev/mtdrom0.kernel
>>>> getopt: optindex: 1 nonopts: 0 optind: 1
>>>> getopt: optindex: 1 nonopts: 0 optind: 3
>>>> getopt: optindex: 1 nonopts: 0 optind: 5
>>>> mtdrom0.kernel: read ofs: 0x00000000 count: 0x00001000
>>>>
>>>> Loading ARM aarch64 Linux image '/dev/mtdrom0.kernel'
>>>> header 00000000: 4d 5a 40 fa 3f 1a 23 14 00 00 00 00 00 00 00 00
>>> MZ@.?.#.........
>>>> header 00000010: 00 00 b3 00 00 00 00 00 0a 00 00 00 00 00 00 00
>>> ................
>>>> header 00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>>> ................
>>>> header 00000030: 00 00 00 00 00 00 00 00 41 52 4d 64 40 00 00 00
>>> ........ARMd@...
>>>> header 00000040: 50 45 00 00 64 aa 02 00 00 00 00 00 00 00 00 00
>>> PE..d...........
>>>> booti: Kernel to be loaded to 8000000+b30000
>>>
>>> Kernel image is relocatable and ARM64 header in hexdump says that
>>> load offset is zero. Yet, barebox wants to load your image to
>>> 8000000, which is already reserved.
>>>
>>> What's the output of the iomem command before and after the failed
>>> boot attempt?
>>>
>>>> __request_region ok: 0x08000000:0x0801ffff flags=0x200
>>>> mtdrom0.kernel: read ofs: 0x00000000 count: 0x00020000
>>>> __request_region ok: 0x08000000:0x0803ffff flags=0x200
>>>> mtdrom0.kernel: read ofs: 0x00020000 count: 0x00020000
>>>> .
>>>> .
>>>> mtdrom0.kernel: read ofs: 0x00fe0000 count: 0x00018000
>>>> __request_region ok: 0x08000000:0x08ff7fff flags=0x200
>>>> mtdrom0.rootfs: read ofs: 0x00000000 count: 0x00000800
>>>> __request_region: 0x08b30000:0x08b4ffff (image) conflicts with
>>> 0x08000000:0x08ff7fff (image)
>>>> unable to request SDRAM 0x08b30000-0x08b4ffff
>>>> handler failed with: Out of memory
>>>
>>> Just to be sure: You don't set global.bootm.image.loadaddr, right?
>>>
>>> Cheers,
>>> Ahmad
>>>
>>>>
>>>> Appreciate your advice,
>>>> Cheers,
>>>> Lior.
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: Ahmad Fatoum <a.fatoum@pengutronix.de>
>>>>> Sent: Monday, June 12, 2023 6:08 PM
>>>>> To: Lior Weintraub <liorw@pliops.com>; Ahmad Fatoum
>> <ahmad@a3f.at>;
>>>>> barebox@lists.infradead.org
>>>>> Subject: Re: [PATCH v2] Porting barebox to a new SoC
>>>>>
>>>>> CAUTION: External Sender
>>>>>
>>>>> Hi,
>>>>>
>>>>> On 12.06.23 16:59, Lior Weintraub wrote:
>>>>>> Hello Ahmad,
>>>>>>
>>>>>> Just for simple simulations we make the ROM size 192MB so it can
>> include
>>> all
>>>>> needed artifacts.
>>>>>
>>>>> I am not convinced that this is much of a simplification over having
>>>>> your Qemu machine provide cfi-flash.
>>>>>
>>>>>> When we get this simple system to work we will move the relevant parts
>>> to
>>>>> BL2.
>>>>>
>>>>> Ok.
>>>>>
>>>>>> DRAM is also simulated now as SRAM so we are not worried about
>>>>> initializations.
>>>>>>
>>>>>> So if I understand correctly, we can decide that address 0x10000000 will
>>> be
>>>>> reserved for "flash" and add the following node:
>>>>>> flash@0 {
>>>>>
>>>>> flash@10000000, but that's just for informational purposes.
>>>>>
>>>>>> compatible = "mtd-rom";
>>>>>> probe-type = "map_rom";
>>>>>> reg = <0x10000000 0x10000000>;
>>>>>> bank-width = <4>;
>>>>>> device-width = <1>;
>>>>>>
>>>>>> #address-cells = <1>;
>>>>>> #size-cells = <1>;
>>>>>> kernel@0 {
>>>>>> label = "kernel";
>>>>>> reg = <0x0 0x01000000>;
>>>>>> };
>>>>>> rootfs@1000000 {
>>>>>> label = "rootfs";
>>>>>> reg = <0x01000000 0x00800000>;
>>>>>> };
>>>>>> };
>>>>>>
>>>>>> When I use this node on our DT I see the following devinfo:
>>>>>> barebox:/ devinfo
>>>>>> `-- global
>>>>>> `-- nv
>>>>>> `-- platform
>>>>>> `-- machine
>>>>>> `-- psci.of
>>>>>> `-- 1000000010000000.flash@0.of
>>>>>
>>>>> As you can see the address is wrong. That's because you have
>>>>> #address-cells = <2>;
>>>>> #size-cells = <2>;
>>>>>
>>>>> Yet, you wrote reg as if it was <1>/<1>. Change it to
>>>>>
>>>>> reg = <0x0 0x10000000 0x0 0x10000000>;
>>>>>
>>>>> Remember all device tree integers are 32-bit big endian.
>>>>>
>>>>>> `-- soc.of
>>>>>> `-- c000000000.sram@c000000000.of
>>>>>> `-- soc:pmu.of
>>>>>> `-- soc:timer.of
>>>>>> `-- e000000000.interrupt-controller@E000000000.of
>>>>>> `-- mem0
>>>>>> `-- 0x00000000-0x0fffffff ( 256 MiB): /dev/ram0
>>>>>> `-- mem1
>>>>>> `-- 0x00000000-0xffffffffffffffff ( 0 Bytes): /dev/mem
>>>>>> `-- amba
>>>>>> `-- d000307000.serial@d000307000.of
>>>>>> `-- cs0
>>>>>> `-- 0x00000000-0xffffffffffffffff ( 0 Bytes): /dev/cs0
>>>>>> `-- spi
>>>>>> `-- fs
>>>>>> `-- ramfs0
>>>>>> `-- devfs0
>>>>>> `-- pstore0
>>>>>>
>>>>>> Not sure how to proceed from here...
>>>>>
>>>>> Type drvinfo command to see what drivers are bound to what devices.
>>>>> If you see no driver bound to your flash device, then maybe you need
>>>>> to enable the correct driver, that would be CONFIG_MTD_MTDRAM
>> (which
>>>>> handles both read-only and read-write memory mapped MTD).
>>>>>
>>>>> Cheers,
>>>>> Ahmad
>>>>>
>>>>>> Cheers,
>>>>>> Lior.
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Ahmad Fatoum <a.fatoum@pengutronix.de>
>>>>>>> Sent: Monday, June 12, 2023 3:29 PM
>>>>>>> To: Lior Weintraub <liorw@pliops.com>; Ahmad Fatoum
>>> <ahmad@a3f.at>;
>>>>>>> barebox@lists.infradead.org
>>>>>>> Subject: Re: [PATCH v2] Porting barebox to a new SoC
>>>>>>>
>>>>>>> CAUTION: External Sender
>>>>>>>
>>>>>>> Hello Lior,
>>>>>>>
>>>>>>> On 12.06.23 11:27, Lior Weintraub wrote:
>>>>>>>> Hi Ahmad,
>>>>>>>>
>>>>>>>> Regarding the rootfs and Linux run question:
>>>>>>>> Our board doesn't include eMMC\SD card.
>>>>>>>> We only have our NOR Flash to store the binaries and our BL1 code
>> will
>>>>> make
>>>>>>> sure to copy those blobs into DRAM.
>>>>>>>
>>>>>>> How could BL1 copy artifacts in DRAM when BL2 first needs to set up
>>>>> DRAM?
>>>>>>>
>>>>>>>> The use of QEMU needs to be as simple as possible so no hidden virtio
>>>>>>> drivers and such because we would like to simulate the real HW flow.
>>>>>>>
>>>>>>> cfi-flash is just memory-mapped flash, which is the next simplest thing
>>>>>>> after BL1 copies stuff into (limited-to-4M) on-chip SRAM.
>>>>>>>
>>>>>>>> Our DTS file now includes the GIC, timer and arm,psci-1.0.
>>>>>>>> We have an initial build of Linux kernel Image (using buildroot) and a
>>>>>>> rootfs.cpio.xz.
>>>>>>>> I assume we can somehow reserve a portion of the DRAM to store
>>> those
>>>>>>> binaries and let barebox boot this Linux.
>>>>>>>
>>>>>>> You can make this work, but this is not how your actual system will
>>>>>>> look like and trying to make this work is harder than it needs to be.
>>>>>>>
>>>>>>> Just add a cfi-flash that corresponds to the Linux/rootfs flash in
>>>>>>> your actual system, then boot with bootm (type help bootm for info
>>>>>>> on how to use it). You don't need to hardcode the load addresses,
>>>>>>> barebox will determine them automatically.
>>>>>>>
>>>>>>>> Can you please advise how to make it work?
>>>>>>>
>>>>>>> For completion's sake, if you have 64M of RAM that's preloaded with
>>>>>>> boot images:
>>>>>>>
>>>>>>> - Remove the 64M from the barebox /memory node. You can use a
>>>>> different
>>>>>>> DT for kernel, but if you have memory that barebox shouldn't
>> override,
>>>>>>> you need to tell it that.
>>>>>>>
>>>>>>> - Add a mtd-rom node that describes these 64M that you have. You
>> can
>>>>>>> add partitions for the region used for kernel and oftree
>>>>>>>
>>>>>>> - boot with bootm -o /dev/mtdrom0.oftree -r /dev/mtdrom0.initrd \
>>>>>>> /dev/mtdrom0.kernel
>>>>>>>
>>>>>>> That's admittedly cumbersome, but necessary, so barebox knows what
>>>>>>> memory
>>>>>>> it may use for itself and what memory may be used for boot.
>>>>>>>
>>>>>>> Correct solution is to use cfi-flash or similar.
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Ahmad
>>>>>>> --
>>>>>>> Pengutronix e.K. | |
>>>>>>> Steuerwalder Str. 21 | http://www.pengutronix.de/ |
>>>>>>> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
>>>>>>> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-
>> 5555
>>> |
>>>>>>
>>>>>
>>>>> --
>>>>> Pengutronix e.K. | |
>>>>> Steuerwalder Str. 21 | http://www.pengutronix.de/ |
>>>>> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
>>>>> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555
>> |
>>>>
>>>
>>> --
>>> Pengutronix e.K. | |
>>> Steuerwalder Str. 21 | http://www.pengutronix.de/ |
>>> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
>>> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
>
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply [flat|nested] 40+ messages in thread
* RE: [PATCH v2] Porting barebox to a new SoC
2023-06-16 16:20 ` Ahmad Fatoum
@ 2023-06-19 6:40 ` Lior Weintraub
2023-06-19 15:22 ` Ahmad Fatoum
0 siblings, 1 reply; 40+ messages in thread
From: Lior Weintraub @ 2023-06-19 6:40 UTC (permalink / raw)
To: Ahmad Fatoum, Ahmad Fatoum, barebox
Hello Ahmad,
Thanks again for your great tips.
Using the addpart command seems to work and give same results as the pre-partitioned flash node on the DT.
When I deleted the whole flash node and extended the memory node to include all 768MB the following commands worked on barebox:
addpart /dev/ram0 "512M@0(dram512),0xB30000@0x20000000(kernel),0x8000@0x20FF8000(oftree),0x800000@0x21000000(rootfs),-"
After that, checking the devinfo gave:
`-- mem0
`-- 0x00000000-0x2fffffff ( 768 MiB): /dev/ram0
`-- 0x00000000-0x1fffffff ( 512 MiB): /dev/ram0.dram512
`-- 0x20000000-0x20b2ffff ( 11.2 MiB): /dev/ram0.kernel
`-- 0x20ff8000-0x20ffffff ( 32 KiB): /dev/ram0.oftree
`-- 0x21000000-0x217fffff ( 8 MiB): /dev/ram0.rootfs
`-- 0x21800000-0x2fffffff ( 232 MiB): /dev/
Now running the bootm:
bootm -o /dev/ram0.oftree -r /dev/ram0.rootfs -a 0 /dev/ram0.kernel
The Linux kernel starts running but has issues (still probably missing parts on my QEMU machine).
Notice that I had to set the "kernel" partition to size 0xB30000 because otherwise it gave me the same error of "conflict":
__request_region ok: 0x00000000:0x00ffffff flags=0x200
__request_region ok: 0x00000000:0x00ff7fff flags=0x200
__request_region: 0x00b30000:0x00b4ffff (image) conflicts with 0x00000000:0x00ff7fff (image)
unable to request SDRAM 0x00b30000-0x00b4ffff
handler failed with: Out of memory
Could it be somehow related to the way I build the kernel?
Cheers,
Lior.
> -----Original Message-----
> From: Ahmad Fatoum <a.fatoum@pengutronix.de>
> Sent: Friday, June 16, 2023 7:21 PM
> To: Lior Weintraub <liorw@pliops.com>; Ahmad Fatoum <ahmad@a3f.at>;
> barebox@lists.infradead.org
> Subject: Re: [PATCH v2] Porting barebox to a new SoC
>
> CAUTION: External Sender
>
> Hello Lior,
>
> On 14.06.23 08:42, Lior Weintraub wrote:
> > Hi Ahmad,
> >
> > Looks like I found the issue :-)
> >
> > When I declared the flash@0 node I used about 16MB for the kernel
> partition even though currently my kernel image is around 11MB:
> > flash@0 {
> > compatible = "mtd-rom";
> > probe-type = "map_rom";
> > reg = <0x0 0x20000000 0x0 0x10000000>; /* Offset 512MB, size 256MB
> */
> > bank-width = <4>;
> > device-width = <1>;
> >
> > #address-cells = <1>;
> > #size-cells = <1>;
> > kernel@0 { /* 16MB (minus 32KB) */
> > label = "kernel";
> > //reg = <0x0 0x00FF8000>; // This line caused the error
> > reg = <0x0 0x00b30000>;
> > };
> > oftree@00FF8000 { /* 32KB for DTB image */
> > label = "oftree";
> > reg = <0x00FF8000 0x00008000>;
> > };
> > rootfs@1000000 { /* Offset 512MB+16MB with size 8MB */
> > label = "rootfs";
> > reg = <0x01000000 0x00800000>;
> > };
> > };
> >
> > From the error message I saw that barebox tried to place the rootfs on
> address 0xb30000 and that conflicted with the kernel:
> > mtdrom0.kernel: read ofs: 0x00fe0000 count: 0x00018000
> > __request_region ok: 0x00000000:0x00ff7fff flags=0x200
> > mtdrom0.rootfs: read ofs: 0x00000000 count: 0x00000800
> > __request_region: 0x00b30000:0x00b4ffff (image) conflicts with
> 0x00000000:0x00ff7fff (image)
>
> This error message still doesn't make sense to me. No idea why this conflicts.
> I see now though that I made this more complicated that it needs be. Please
> scratch all that, remove the mtd-rom and revert the /memory node to
> encompass
> all memory. Then you can at runtime, just create the partitions with the
> addpart
> command (see help addpart for info). Then you can boot normally.
>
> >
> > So I changed the kernel@0 node and used size 0x00b30000 and now kernel
> starts running.
> > The kernel is producing all kinds of errors but at least it's a start :-)
> > The errors are now related to pieces of HW that we didn't implement on
> QEMU so it is understandable.
> >
> > How can we control where the rootfs is copied to?
>
> Normally, global.bootm.initrd.loadaddr, but you shouldn't need to do
> that. Try it with addpart and let me know.
>
> Cheers,
> Ahmad
>
> >
> > Thanks again for your kind advise and patience.
> > Cheers,
> > Lior.
> >
> >> -----Original Message-----
> >> From: Lior Weintraub
> >> Sent: Tuesday, June 13, 2023 4:28 PM
> >> To: Ahmad Fatoum <a.fatoum@pengutronix.de>; Ahmad Fatoum
> >> <ahmad@a3f.at>; barebox@lists.infradead.org
> >> Subject: RE: [PATCH v2] Porting barebox to a new SoC
> >>
> >> Hi Ahmad,
> >>
> >> I also thought that load address was suspicious (0x8000000) but then I
> saw
> >> the following comment on nxp_imx8mq_evk_start:
> >> /*
> >> * On completion the TF-A will jump to
> >> MX8MQ_ATF_BL33_BASE_ADDR
> >> * in EL2. Copy the image there, but replace the PBL part of
> >> * that image with ourselves. On a high assurance boot only
> >> the
> >> * currently running code is validated and contains the
> >> checksum
> >> * for the piggy data, so we need to ensure that we are
> >> running
> >> * the same code in DRAM.
> >> */
> >> Our code was based on this function and as a result it copies the barebox
> >> image into address 0x8000000 (which is our settings of
> >> ATF_BL33_BASE_ADDR).
> >> The fact that Linux image is also copied there seemed reasonable (I might be
> >> wrong here) because once loading is done and we jump to Linux there is no
> >> need for barebox code anymore.
> >>
> >> In any case, at that time when I thought it was wrong I also tried to run the
> >> bootm command with "-a 0" but I got exactly the same error:
> >> barebox:/ bootm -o /dev/mtdrom0.oftree -r /dev/mtdrom0.rootfs -a 0
> >> /dev/mtdrom0.kernel
> >> getopt: optindex: 1 nonopts: 0 optind: 1
> >> getopt: optindex: 1 nonopts: 0 optind: 3
> >> getopt: optindex: 1 nonopts: 0 optind: 5
> >> getopt: optindex: 1 nonopts: 0 optind: 7
> >> mtdrom0.kernel: read ofs: 0x00000000 count: 0x00001000
> >>
> >> Loading ARM aarch64 Linux image '/dev/mtdrom0.kernel'
> >> header 00000000: 4d 5a 40 fa 3f 1a 23 14 00 00 00 00 00 00 00 00
> >> MZ@.?.#.........
> >> header 00000010: 00 00 b3 00 00 00 00 00 0a 00 00 00 00 00 00 00
> >> ................
> >> header 00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> >> ................
> >> header 00000030: 00 00 00 00 00 00 00 00 41 52 4d 64 40 00 00 00
> >> ........ARMd@...
> >> header 00000040: 50 45 00 00 64 aa 02 00 00 00 00 00 00 00 00 00
> >> PE..d...........
> >> booti: Kernel to be loaded to 0+b30000
> >> __request_region ok: 0x00000000:0x0001ffff flags=0x200
> >> mtdrom0.kernel: read ofs: 0x00000000 count: 0x00020000
> >> __request_region ok: 0x00000000:0x0003ffff flags=0x200
> >> mtdrom0.kernel: read ofs: 0x00020000 count: 0x00020000
> >> __request_region ok: 0x00000000:0x0005ffff flags=0x200
> >> .
> >> .
> >> mtdrom0.kernel: read ofs: 0x00fe0000 count: 0x00018000
> >> __request_region ok: 0x00000000:0x00ff7fff flags=0x200
> >> mtdrom0.rootfs: read ofs: 0x00000000 count: 0x00000800
> >> __request_region: 0x00b30000:0x00b4ffff (image) conflicts with
> >> 0x00000000:0x00ff7fff (image)
> >> unable to request SDRAM 0x00b30000-0x00b4ffff
> >> handler failed with: Out of memory
> >>
> >>
> >> The iomem before:
> >> barebox:/ iomem
> >> 0x0000000000000000 - 0xffffffffffffffff (size 0x0000000000000000)
> iomem
> >> 0x0000000000000000 - 0x000000001fffffff (size
> 0x0000000020000000)
> >> ram0
> >> 0x00000000079fef00 - 0x0000000007dfeeff (size
> 0x0000000000400000)
> >> malloc space
> >> 0x0000000007dfef00 - 0x0000000007dfffd1 (size
> 0x00000000000010d2)
> >> board data
> >> 0x0000000007e00000 - 0x0000000007e3d95f (size
> >> 0x000000000003d960) barebox
> >> 0x0000000007e3d960 - 0x0000000007e50bb7 (size
> >> 0x0000000000013258) barebox data
> >> 0x0000000007e50bb8 - 0x0000000007e53b3f (size
> >> 0x0000000000002f88) bss
> >> 0x0000000007ff0000 - 0x0000000007ff7fff (size
> 0x0000000000008000)
> >> stack
> >> 0x0000000020000000 - 0x000000002fffffff (size
> 0x0000000010000000)
> >> 20000000.flash@0.of
> >> 0x000000d000307000 - 0x000000d000307fff (size
> >> 0x0000000000001000) amba
> >>
> >> After:
> >> barebox:/ iomem
> >> 0x0000000000000000 - 0xffffffffffffffff (size 0x0000000000000000)
> iomem
> >> 0x0000000000000000 - 0x000000001fffffff (size
> 0x0000000020000000)
> >> ram0
> >> 0x00000000079fef00 - 0x0000000007dfeeff (size
> 0x0000000000400000)
> >> malloc space
> >> 0x0000000007dfef00 - 0x0000000007dfffd1 (size
> 0x00000000000010d2)
> >> board data
> >> 0x0000000007e00000 - 0x0000000007e3d95f (size
> >> 0x000000000003d960) barebox
> >> 0x0000000007e3d960 - 0x0000000007e50bb7 (size
> >> 0x0000000000013258) barebox data
> >> 0x0000000007e50bb8 - 0x0000000007e53b3f (size
> >> 0x0000000000002f88) bss
> >> 0x0000000007ff0000 - 0x0000000007ff7fff (size
> 0x0000000000008000)
> >> stack
> >> 0x0000000020000000 - 0x000000002fffffff (size
> 0x0000000010000000)
> >> 20000000.flash@0.of
> >> 0x000000d000307000 - 0x000000d000307fff (size
> >> 0x0000000000001000) amba
> >>
> >> I did not set global.bootm.image.loadaddr
> >> Speaking of env, the last few lines on the barebox terminal are:
> >> initcall-> load_environment+0x0/0x4c
> >> loading defaultenv
> >> environment load /dev/env0: No such file or directory
> >> Maybe you have to create the partition.
> >> initcalls done
> >>
> >> When I run "printenv" I am getting:
> >> barebox:/ printenv
> >> locals:
> >> globals:
> >> bootsource=unknown
> >> bootsource_instance=unknown
> >> PATH=/env/bin
> >>
> >> Hope this info can help.
> >> Cheers,
> >> Lior.
> >>
> >>
> >>> -----Original Message-----
> >>> From: Ahmad Fatoum <a.fatoum@pengutronix.de>
> >>> Sent: Tuesday, June 13, 2023 3:51 PM
> >>> To: Lior Weintraub <liorw@pliops.com>; Ahmad Fatoum
> <ahmad@a3f.at>;
> >>> barebox@lists.infradead.org
> >>> Subject: Re: [PATCH v2] Porting barebox to a new SoC
> >>>
> >>> CAUTION: External Sender
> >>>
> >>> On 13.06.23 14:39, Lior Weintraub wrote:
> >>>> Hi Ahmad,
> >>>>
> >>>> As usual, your comments are spot on :-)
> >>>>
> >>>> After fixing the DT, devinfo command shows correct flash node:
> >>>> `-- 20000000.flash@0.of
> >>>> `-- mtdrom0
> >>>> `-- 0x00000000-0x0fffffff ( 256 MiB): /dev/mtdrom0
> >>>> `-- mtdrom0.kernel
> >>>> `-- 0x00000000-0x00ff7fff ( 16 MiB): /dev/mtdrom0.kernel
> >>>> `-- mtdrom0.oftree
> >>>> `-- 0x00000000-0x00007fff ( 32 KiB): /dev/mtdrom0.oftree
> >>>> `-- mtdrom0.rootfs
> >>>> `-- 0x00000000-0x007fffff ( 8 MiB): /dev/mtdrom0.rootfs
> >>>>
> >>>> As can be seen above, we chose to map this "flash" node on DRAM
> >> address
> >>> 0x20000000 (offset 512MB).
> >>>> The BL1 code correctly copy the 3 artifacts into those location (verified
> the
> >>> content via "md -l -s /dev/mtdrom0.kernel").
> >>>> Running "drvinfo" shows:
> >>>> mtdram
> >>>> 20000000.flash@0.of
> >>>>
> >>>> Now when I try to run "bootm -o /dev/mtdrom0.oftree -r
> >>> /dev/mtdrom0.rootfs /dev/mtdrom0.kernel" I am getting this error:
> >>>>
> >>>> barebox:/ bootm -o /dev/mtdrom0.oftree -r /dev/mtdrom0.rootfs
> >>> /dev/mtdrom0.kernel
> >>>> getopt: optindex: 1 nonopts: 0 optind: 1
> >>>> getopt: optindex: 1 nonopts: 0 optind: 3
> >>>> getopt: optindex: 1 nonopts: 0 optind: 5
> >>>> mtdrom0.kernel: read ofs: 0x00000000 count: 0x00001000
> >>>>
> >>>> Loading ARM aarch64 Linux image '/dev/mtdrom0.kernel'
> >>>> header 00000000: 4d 5a 40 fa 3f 1a 23 14 00 00 00 00 00 00 00 00
> >>> MZ@.?.#.........
> >>>> header 00000010: 00 00 b3 00 00 00 00 00 0a 00 00 00 00 00 00 00
> >>> ................
> >>>> header 00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> >>> ................
> >>>> header 00000030: 00 00 00 00 00 00 00 00 41 52 4d 64 40 00 00 00
> >>> ........ARMd@...
> >>>> header 00000040: 50 45 00 00 64 aa 02 00 00 00 00 00 00 00 00 00
> >>> PE..d...........
> >>>> booti: Kernel to be loaded to 8000000+b30000
> >>>
> >>> Kernel image is relocatable and ARM64 header in hexdump says that
> >>> load offset is zero. Yet, barebox wants to load your image to
> >>> 8000000, which is already reserved.
> >>>
> >>> What's the output of the iomem command before and after the failed
> >>> boot attempt?
> >>>
> >>>> __request_region ok: 0x08000000:0x0801ffff flags=0x200
> >>>> mtdrom0.kernel: read ofs: 0x00000000 count: 0x00020000
> >>>> __request_region ok: 0x08000000:0x0803ffff flags=0x200
> >>>> mtdrom0.kernel: read ofs: 0x00020000 count: 0x00020000
> >>>> .
> >>>> .
> >>>> mtdrom0.kernel: read ofs: 0x00fe0000 count: 0x00018000
> >>>> __request_region ok: 0x08000000:0x08ff7fff flags=0x200
> >>>> mtdrom0.rootfs: read ofs: 0x00000000 count: 0x00000800
> >>>> __request_region: 0x08b30000:0x08b4ffff (image) conflicts with
> >>> 0x08000000:0x08ff7fff (image)
> >>>> unable to request SDRAM 0x08b30000-0x08b4ffff
> >>>> handler failed with: Out of memory
> >>>
> >>> Just to be sure: You don't set global.bootm.image.loadaddr, right?
> >>>
> >>> Cheers,
> >>> Ahmad
> >>>
> >>>>
> >>>> Appreciate your advice,
> >>>> Cheers,
> >>>> Lior.
> >>>>
> >>>>
> >>>>> -----Original Message-----
> >>>>> From: Ahmad Fatoum <a.fatoum@pengutronix.de>
> >>>>> Sent: Monday, June 12, 2023 6:08 PM
> >>>>> To: Lior Weintraub <liorw@pliops.com>; Ahmad Fatoum
> >> <ahmad@a3f.at>;
> >>>>> barebox@lists.infradead.org
> >>>>> Subject: Re: [PATCH v2] Porting barebox to a new SoC
> >>>>>
> >>>>> CAUTION: External Sender
> >>>>>
> >>>>> Hi,
> >>>>>
> >>>>> On 12.06.23 16:59, Lior Weintraub wrote:
> >>>>>> Hello Ahmad,
> >>>>>>
> >>>>>> Just for simple simulations we make the ROM size 192MB so it can
> >> include
> >>> all
> >>>>> needed artifacts.
> >>>>>
> >>>>> I am not convinced that this is much of a simplification over having
> >>>>> your Qemu machine provide cfi-flash.
> >>>>>
> >>>>>> When we get this simple system to work we will move the relevant
> parts
> >>> to
> >>>>> BL2.
> >>>>>
> >>>>> Ok.
> >>>>>
> >>>>>> DRAM is also simulated now as SRAM so we are not worried about
> >>>>> initializations.
> >>>>>>
> >>>>>> So if I understand correctly, we can decide that address 0x10000000
> will
> >>> be
> >>>>> reserved for "flash" and add the following node:
> >>>>>> flash@0 {
> >>>>>
> >>>>> flash@10000000, but that's just for informational purposes.
> >>>>>
> >>>>>> compatible = "mtd-rom";
> >>>>>> probe-type = "map_rom";
> >>>>>> reg = <0x10000000 0x10000000>;
> >>>>>> bank-width = <4>;
> >>>>>> device-width = <1>;
> >>>>>>
> >>>>>> #address-cells = <1>;
> >>>>>> #size-cells = <1>;
> >>>>>> kernel@0 {
> >>>>>> label = "kernel";
> >>>>>> reg = <0x0 0x01000000>;
> >>>>>> };
> >>>>>> rootfs@1000000 {
> >>>>>> label = "rootfs";
> >>>>>> reg = <0x01000000 0x00800000>;
> >>>>>> };
> >>>>>> };
> >>>>>>
> >>>>>> When I use this node on our DT I see the following devinfo:
> >>>>>> barebox:/ devinfo
> >>>>>> `-- global
> >>>>>> `-- nv
> >>>>>> `-- platform
> >>>>>> `-- machine
> >>>>>> `-- psci.of
> >>>>>> `-- 1000000010000000.flash@0.of
> >>>>>
> >>>>> As you can see the address is wrong. That's because you have
> >>>>> #address-cells = <2>;
> >>>>> #size-cells = <2>;
> >>>>>
> >>>>> Yet, you wrote reg as if it was <1>/<1>. Change it to
> >>>>>
> >>>>> reg = <0x0 0x10000000 0x0 0x10000000>;
> >>>>>
> >>>>> Remember all device tree integers are 32-bit big endian.
> >>>>>
> >>>>>> `-- soc.of
> >>>>>> `-- c000000000.sram@c000000000.of
> >>>>>> `-- soc:pmu.of
> >>>>>> `-- soc:timer.of
> >>>>>> `-- e000000000.interrupt-controller@E000000000.of
> >>>>>> `-- mem0
> >>>>>> `-- 0x00000000-0x0fffffff ( 256 MiB): /dev/ram0
> >>>>>> `-- mem1
> >>>>>> `-- 0x00000000-0xffffffffffffffff ( 0 Bytes): /dev/mem
> >>>>>> `-- amba
> >>>>>> `-- d000307000.serial@d000307000.of
> >>>>>> `-- cs0
> >>>>>> `-- 0x00000000-0xffffffffffffffff ( 0 Bytes): /dev/cs0
> >>>>>> `-- spi
> >>>>>> `-- fs
> >>>>>> `-- ramfs0
> >>>>>> `-- devfs0
> >>>>>> `-- pstore0
> >>>>>>
> >>>>>> Not sure how to proceed from here...
> >>>>>
> >>>>> Type drvinfo command to see what drivers are bound to what devices.
> >>>>> If you see no driver bound to your flash device, then maybe you need
> >>>>> to enable the correct driver, that would be CONFIG_MTD_MTDRAM
> >> (which
> >>>>> handles both read-only and read-write memory mapped MTD).
> >>>>>
> >>>>> Cheers,
> >>>>> Ahmad
> >>>>>
> >>>>>> Cheers,
> >>>>>> Lior.
> >>>>>>
> >>>>>>> -----Original Message-----
> >>>>>>> From: Ahmad Fatoum <a.fatoum@pengutronix.de>
> >>>>>>> Sent: Monday, June 12, 2023 3:29 PM
> >>>>>>> To: Lior Weintraub <liorw@pliops.com>; Ahmad Fatoum
> >>> <ahmad@a3f.at>;
> >>>>>>> barebox@lists.infradead.org
> >>>>>>> Subject: Re: [PATCH v2] Porting barebox to a new SoC
> >>>>>>>
> >>>>>>> CAUTION: External Sender
> >>>>>>>
> >>>>>>> Hello Lior,
> >>>>>>>
> >>>>>>> On 12.06.23 11:27, Lior Weintraub wrote:
> >>>>>>>> Hi Ahmad,
> >>>>>>>>
> >>>>>>>> Regarding the rootfs and Linux run question:
> >>>>>>>> Our board doesn't include eMMC\SD card.
> >>>>>>>> We only have our NOR Flash to store the binaries and our BL1 code
> >> will
> >>>>> make
> >>>>>>> sure to copy those blobs into DRAM.
> >>>>>>>
> >>>>>>> How could BL1 copy artifacts in DRAM when BL2 first needs to set up
> >>>>> DRAM?
> >>>>>>>
> >>>>>>>> The use of QEMU needs to be as simple as possible so no hidden
> virtio
> >>>>>>> drivers and such because we would like to simulate the real HW flow.
> >>>>>>>
> >>>>>>> cfi-flash is just memory-mapped flash, which is the next simplest
> thing
> >>>>>>> after BL1 copies stuff into (limited-to-4M) on-chip SRAM.
> >>>>>>>
> >>>>>>>> Our DTS file now includes the GIC, timer and arm,psci-1.0.
> >>>>>>>> We have an initial build of Linux kernel Image (using buildroot) and a
> >>>>>>> rootfs.cpio.xz.
> >>>>>>>> I assume we can somehow reserve a portion of the DRAM to store
> >>> those
> >>>>>>> binaries and let barebox boot this Linux.
> >>>>>>>
> >>>>>>> You can make this work, but this is not how your actual system will
> >>>>>>> look like and trying to make this work is harder than it needs to be.
> >>>>>>>
> >>>>>>> Just add a cfi-flash that corresponds to the Linux/rootfs flash in
> >>>>>>> your actual system, then boot with bootm (type help bootm for info
> >>>>>>> on how to use it). You don't need to hardcode the load addresses,
> >>>>>>> barebox will determine them automatically.
> >>>>>>>
> >>>>>>>> Can you please advise how to make it work?
> >>>>>>>
> >>>>>>> For completion's sake, if you have 64M of RAM that's preloaded with
> >>>>>>> boot images:
> >>>>>>>
> >>>>>>> - Remove the 64M from the barebox /memory node. You can use a
> >>>>> different
> >>>>>>> DT for kernel, but if you have memory that barebox shouldn't
> >> override,
> >>>>>>> you need to tell it that.
> >>>>>>>
> >>>>>>> - Add a mtd-rom node that describes these 64M that you have. You
> >> can
> >>>>>>> add partitions for the region used for kernel and oftree
> >>>>>>>
> >>>>>>> - boot with bootm -o /dev/mtdrom0.oftree -r /dev/mtdrom0.initrd
> \
> >>>>>>> /dev/mtdrom0.kernel
> >>>>>>>
> >>>>>>> That's admittedly cumbersome, but necessary, so barebox knows
> what
> >>>>>>> memory
> >>>>>>> it may use for itself and what memory may be used for boot.
> >>>>>>>
> >>>>>>> Correct solution is to use cfi-flash or similar.
> >>>>>>>
> >>>>>>> Cheers,
> >>>>>>> Ahmad
> >>>>>>> --
> >>>>>>> Pengutronix e.K. | |
> >>>>>>> Steuerwalder Str. 21 | http://www.pengutronix.de/ |
> >>>>>>> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0
> |
> >>>>>>> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-
> >> 5555
> >>> |
> >>>>>>
> >>>>>
> >>>>> --
> >>>>> Pengutronix e.K. | |
> >>>>> Steuerwalder Str. 21 | http://www.pengutronix.de/ |
> >>>>> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
> >>>>> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-
> 5555
> >> |
> >>>>
> >>>
> >>> --
> >>> Pengutronix e.K. | |
> >>> Steuerwalder Str. 21 | http://www.pengutronix.de/ |
> >>> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
> >>> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
> >
>
> --
> Pengutronix e.K. | |
> Steuerwalder Str. 21 | http://www.pengutronix.de/ |
> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [PATCH v2] Porting barebox to a new SoC
2023-06-19 6:40 ` Lior Weintraub
@ 2023-06-19 15:22 ` Ahmad Fatoum
2023-06-25 20:33 ` Lior Weintraub
0 siblings, 1 reply; 40+ messages in thread
From: Ahmad Fatoum @ 2023-06-19 15:22 UTC (permalink / raw)
To: Lior Weintraub, Ahmad Fatoum, barebox
On 19.06.23 08:40, Lior Weintraub wrote:
> Hello Ahmad,
>
> Thanks again for your great tips.
> Using the addpart command seems to work and give same results as the pre-partitioned flash node on the DT.
> When I deleted the whole flash node and extended the memory node to include all 768MB the following commands worked on barebox:
> addpart /dev/ram0 "512M@0(dram512),0xB30000@0x20000000(kernel),0x8000@0x20FF8000(oftree),0x800000@0x21000000(rootfs),-"
> After that, checking the devinfo gave:
> `-- mem0
> `-- 0x00000000-0x2fffffff ( 768 MiB): /dev/ram0
> `-- 0x00000000-0x1fffffff ( 512 MiB): /dev/ram0.dram512
> `-- 0x20000000-0x20b2ffff ( 11.2 MiB): /dev/ram0.kernel
> `-- 0x20ff8000-0x20ffffff ( 32 KiB): /dev/ram0.oftree
> `-- 0x21000000-0x217fffff ( 8 MiB): /dev/ram0.rootfs
> `-- 0x21800000-0x2fffffff ( 232 MiB): /dev/
> Now running the bootm:
> bootm -o /dev/ram0.oftree -r /dev/ram0.rootfs -a 0 /dev/ram0.kernel
>
> The Linux kernel starts running but has issues (still probably missing parts on my QEMU machine).
>
> Notice that I had to set the "kernel" partition to size 0xB30000 because otherwise it gave me the same error of "conflict":
> __request_region ok: 0x00000000:0x00ffffff flags=0x200
> __request_region ok: 0x00000000:0x00ff7fff flags=0x200
> __request_region: 0x00b30000:0x00b4ffff (image) conflicts with 0x00000000:0x00ff7fff (image)
> unable to request SDRAM 0x00b30000-0x00b4ffff
> handler failed with: Out of memory
>
> Could it be somehow related to the way I build the kernel?
Can you reproduce this with normal qemu aarch64 virt machine?
Cheers,
Ahmad
> Cheers,
> Lior.
>
>
>> -----Original Message-----
>> From: Ahmad Fatoum <a.fatoum@pengutronix.de>
>> Sent: Friday, June 16, 2023 7:21 PM
>> To: Lior Weintraub <liorw@pliops.com>; Ahmad Fatoum <ahmad@a3f.at>;
>> barebox@lists.infradead.org
>> Subject: Re: [PATCH v2] Porting barebox to a new SoC
>>
>> CAUTION: External Sender
>>
>> Hello Lior,
>>
>> On 14.06.23 08:42, Lior Weintraub wrote:
>>> Hi Ahmad,
>>>
>>> Looks like I found the issue :-)
>>>
>>> When I declared the flash@0 node I used about 16MB for the kernel
>> partition even though currently my kernel image is around 11MB:
>>> flash@0 {
>>> compatible = "mtd-rom";
>>> probe-type = "map_rom";
>>> reg = <0x0 0x20000000 0x0 0x10000000>; /* Offset 512MB, size 256MB
>> */
>>> bank-width = <4>;
>>> device-width = <1>;
>>>
>>> #address-cells = <1>;
>>> #size-cells = <1>;
>>> kernel@0 { /* 16MB (minus 32KB) */
>>> label = "kernel";
>>> //reg = <0x0 0x00FF8000>; // This line caused the error
>>> reg = <0x0 0x00b30000>;
>>> };
>>> oftree@00FF8000 { /* 32KB for DTB image */
>>> label = "oftree";
>>> reg = <0x00FF8000 0x00008000>;
>>> };
>>> rootfs@1000000 { /* Offset 512MB+16MB with size 8MB */
>>> label = "rootfs";
>>> reg = <0x01000000 0x00800000>;
>>> };
>>> };
>>>
>>> From the error message I saw that barebox tried to place the rootfs on
>> address 0xb30000 and that conflicted with the kernel:
>>> mtdrom0.kernel: read ofs: 0x00fe0000 count: 0x00018000
>>> __request_region ok: 0x00000000:0x00ff7fff flags=0x200
>>> mtdrom0.rootfs: read ofs: 0x00000000 count: 0x00000800
>>> __request_region: 0x00b30000:0x00b4ffff (image) conflicts with
>> 0x00000000:0x00ff7fff (image)
>>
>> This error message still doesn't make sense to me. No idea why this conflicts.
>> I see now though that I made this more complicated that it needs be. Please
>> scratch all that, remove the mtd-rom and revert the /memory node to
>> encompass
>> all memory. Then you can at runtime, just create the partitions with the
>> addpart
>> command (see help addpart for info). Then you can boot normally.
>>
>>>
>>> So I changed the kernel@0 node and used size 0x00b30000 and now kernel
>> starts running.
>>> The kernel is producing all kinds of errors but at least it's a start :-)
>>> The errors are now related to pieces of HW that we didn't implement on
>> QEMU so it is understandable.
>>>
>>> How can we control where the rootfs is copied to?
>>
>> Normally, global.bootm.initrd.loadaddr, but you shouldn't need to do
>> that. Try it with addpart and let me know.
>>
>> Cheers,
>> Ahmad
>>
>>>
>>> Thanks again for your kind advise and patience.
>>> Cheers,
>>> Lior.
>>>
>>>> -----Original Message-----
>>>> From: Lior Weintraub
>>>> Sent: Tuesday, June 13, 2023 4:28 PM
>>>> To: Ahmad Fatoum <a.fatoum@pengutronix.de>; Ahmad Fatoum
>>>> <ahmad@a3f.at>; barebox@lists.infradead.org
>>>> Subject: RE: [PATCH v2] Porting barebox to a new SoC
>>>>
>>>> Hi Ahmad,
>>>>
>>>> I also thought that load address was suspicious (0x8000000) but then I
>> saw
>>>> the following comment on nxp_imx8mq_evk_start:
>>>> /*
>>>> * On completion the TF-A will jump to
>>>> MX8MQ_ATF_BL33_BASE_ADDR
>>>> * in EL2. Copy the image there, but replace the PBL part of
>>>> * that image with ourselves. On a high assurance boot only
>>>> the
>>>> * currently running code is validated and contains the
>>>> checksum
>>>> * for the piggy data, so we need to ensure that we are
>>>> running
>>>> * the same code in DRAM.
>>>> */
>>>> Our code was based on this function and as a result it copies the barebox
>>>> image into address 0x8000000 (which is our settings of
>>>> ATF_BL33_BASE_ADDR).
>>>> The fact that Linux image is also copied there seemed reasonable (I might be
>>>> wrong here) because once loading is done and we jump to Linux there is no
>>>> need for barebox code anymore.
>>>>
>>>> In any case, at that time when I thought it was wrong I also tried to run the
>>>> bootm command with "-a 0" but I got exactly the same error:
>>>> barebox:/ bootm -o /dev/mtdrom0.oftree -r /dev/mtdrom0.rootfs -a 0
>>>> /dev/mtdrom0.kernel
>>>> getopt: optindex: 1 nonopts: 0 optind: 1
>>>> getopt: optindex: 1 nonopts: 0 optind: 3
>>>> getopt: optindex: 1 nonopts: 0 optind: 5
>>>> getopt: optindex: 1 nonopts: 0 optind: 7
>>>> mtdrom0.kernel: read ofs: 0x00000000 count: 0x00001000
>>>>
>>>> Loading ARM aarch64 Linux image '/dev/mtdrom0.kernel'
>>>> header 00000000: 4d 5a 40 fa 3f 1a 23 14 00 00 00 00 00 00 00 00
>>>> MZ@.?.#.........
>>>> header 00000010: 00 00 b3 00 00 00 00 00 0a 00 00 00 00 00 00 00
>>>> ................
>>>> header 00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>>>> ................
>>>> header 00000030: 00 00 00 00 00 00 00 00 41 52 4d 64 40 00 00 00
>>>> ........ARMd@...
>>>> header 00000040: 50 45 00 00 64 aa 02 00 00 00 00 00 00 00 00 00
>>>> PE..d...........
>>>> booti: Kernel to be loaded to 0+b30000
>>>> __request_region ok: 0x00000000:0x0001ffff flags=0x200
>>>> mtdrom0.kernel: read ofs: 0x00000000 count: 0x00020000
>>>> __request_region ok: 0x00000000:0x0003ffff flags=0x200
>>>> mtdrom0.kernel: read ofs: 0x00020000 count: 0x00020000
>>>> __request_region ok: 0x00000000:0x0005ffff flags=0x200
>>>> .
>>>> .
>>>> mtdrom0.kernel: read ofs: 0x00fe0000 count: 0x00018000
>>>> __request_region ok: 0x00000000:0x00ff7fff flags=0x200
>>>> mtdrom0.rootfs: read ofs: 0x00000000 count: 0x00000800
>>>> __request_region: 0x00b30000:0x00b4ffff (image) conflicts with
>>>> 0x00000000:0x00ff7fff (image)
>>>> unable to request SDRAM 0x00b30000-0x00b4ffff
>>>> handler failed with: Out of memory
>>>>
>>>>
>>>> The iomem before:
>>>> barebox:/ iomem
>>>> 0x0000000000000000 - 0xffffffffffffffff (size 0x0000000000000000)
>> iomem
>>>> 0x0000000000000000 - 0x000000001fffffff (size
>> 0x0000000020000000)
>>>> ram0
>>>> 0x00000000079fef00 - 0x0000000007dfeeff (size
>> 0x0000000000400000)
>>>> malloc space
>>>> 0x0000000007dfef00 - 0x0000000007dfffd1 (size
>> 0x00000000000010d2)
>>>> board data
>>>> 0x0000000007e00000 - 0x0000000007e3d95f (size
>>>> 0x000000000003d960) barebox
>>>> 0x0000000007e3d960 - 0x0000000007e50bb7 (size
>>>> 0x0000000000013258) barebox data
>>>> 0x0000000007e50bb8 - 0x0000000007e53b3f (size
>>>> 0x0000000000002f88) bss
>>>> 0x0000000007ff0000 - 0x0000000007ff7fff (size
>> 0x0000000000008000)
>>>> stack
>>>> 0x0000000020000000 - 0x000000002fffffff (size
>> 0x0000000010000000)
>>>> 20000000.flash@0.of
>>>> 0x000000d000307000 - 0x000000d000307fff (size
>>>> 0x0000000000001000) amba
>>>>
>>>> After:
>>>> barebox:/ iomem
>>>> 0x0000000000000000 - 0xffffffffffffffff (size 0x0000000000000000)
>> iomem
>>>> 0x0000000000000000 - 0x000000001fffffff (size
>> 0x0000000020000000)
>>>> ram0
>>>> 0x00000000079fef00 - 0x0000000007dfeeff (size
>> 0x0000000000400000)
>>>> malloc space
>>>> 0x0000000007dfef00 - 0x0000000007dfffd1 (size
>> 0x00000000000010d2)
>>>> board data
>>>> 0x0000000007e00000 - 0x0000000007e3d95f (size
>>>> 0x000000000003d960) barebox
>>>> 0x0000000007e3d960 - 0x0000000007e50bb7 (size
>>>> 0x0000000000013258) barebox data
>>>> 0x0000000007e50bb8 - 0x0000000007e53b3f (size
>>>> 0x0000000000002f88) bss
>>>> 0x0000000007ff0000 - 0x0000000007ff7fff (size
>> 0x0000000000008000)
>>>> stack
>>>> 0x0000000020000000 - 0x000000002fffffff (size
>> 0x0000000010000000)
>>>> 20000000.flash@0.of
>>>> 0x000000d000307000 - 0x000000d000307fff (size
>>>> 0x0000000000001000) amba
>>>>
>>>> I did not set global.bootm.image.loadaddr
>>>> Speaking of env, the last few lines on the barebox terminal are:
>>>> initcall-> load_environment+0x0/0x4c
>>>> loading defaultenv
>>>> environment load /dev/env0: No such file or directory
>>>> Maybe you have to create the partition.
>>>> initcalls done
>>>>
>>>> When I run "printenv" I am getting:
>>>> barebox:/ printenv
>>>> locals:
>>>> globals:
>>>> bootsource=unknown
>>>> bootsource_instance=unknown
>>>> PATH=/env/bin
>>>>
>>>> Hope this info can help.
>>>> Cheers,
>>>> Lior.
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: Ahmad Fatoum <a.fatoum@pengutronix.de>
>>>>> Sent: Tuesday, June 13, 2023 3:51 PM
>>>>> To: Lior Weintraub <liorw@pliops.com>; Ahmad Fatoum
>> <ahmad@a3f.at>;
>>>>> barebox@lists.infradead.org
>>>>> Subject: Re: [PATCH v2] Porting barebox to a new SoC
>>>>>
>>>>> CAUTION: External Sender
>>>>>
>>>>> On 13.06.23 14:39, Lior Weintraub wrote:
>>>>>> Hi Ahmad,
>>>>>>
>>>>>> As usual, your comments are spot on :-)
>>>>>>
>>>>>> After fixing the DT, devinfo command shows correct flash node:
>>>>>> `-- 20000000.flash@0.of
>>>>>> `-- mtdrom0
>>>>>> `-- 0x00000000-0x0fffffff ( 256 MiB): /dev/mtdrom0
>>>>>> `-- mtdrom0.kernel
>>>>>> `-- 0x00000000-0x00ff7fff ( 16 MiB): /dev/mtdrom0.kernel
>>>>>> `-- mtdrom0.oftree
>>>>>> `-- 0x00000000-0x00007fff ( 32 KiB): /dev/mtdrom0.oftree
>>>>>> `-- mtdrom0.rootfs
>>>>>> `-- 0x00000000-0x007fffff ( 8 MiB): /dev/mtdrom0.rootfs
>>>>>>
>>>>>> As can be seen above, we chose to map this "flash" node on DRAM
>>>> address
>>>>> 0x20000000 (offset 512MB).
>>>>>> The BL1 code correctly copy the 3 artifacts into those location (verified
>> the
>>>>> content via "md -l -s /dev/mtdrom0.kernel").
>>>>>> Running "drvinfo" shows:
>>>>>> mtdram
>>>>>> 20000000.flash@0.of
>>>>>>
>>>>>> Now when I try to run "bootm -o /dev/mtdrom0.oftree -r
>>>>> /dev/mtdrom0.rootfs /dev/mtdrom0.kernel" I am getting this error:
>>>>>>
>>>>>> barebox:/ bootm -o /dev/mtdrom0.oftree -r /dev/mtdrom0.rootfs
>>>>> /dev/mtdrom0.kernel
>>>>>> getopt: optindex: 1 nonopts: 0 optind: 1
>>>>>> getopt: optindex: 1 nonopts: 0 optind: 3
>>>>>> getopt: optindex: 1 nonopts: 0 optind: 5
>>>>>> mtdrom0.kernel: read ofs: 0x00000000 count: 0x00001000
>>>>>>
>>>>>> Loading ARM aarch64 Linux image '/dev/mtdrom0.kernel'
>>>>>> header 00000000: 4d 5a 40 fa 3f 1a 23 14 00 00 00 00 00 00 00 00
>>>>> MZ@.?.#.........
>>>>>> header 00000010: 00 00 b3 00 00 00 00 00 0a 00 00 00 00 00 00 00
>>>>> ................
>>>>>> header 00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>>>>> ................
>>>>>> header 00000030: 00 00 00 00 00 00 00 00 41 52 4d 64 40 00 00 00
>>>>> ........ARMd@...
>>>>>> header 00000040: 50 45 00 00 64 aa 02 00 00 00 00 00 00 00 00 00
>>>>> PE..d...........
>>>>>> booti: Kernel to be loaded to 8000000+b30000
>>>>>
>>>>> Kernel image is relocatable and ARM64 header in hexdump says that
>>>>> load offset is zero. Yet, barebox wants to load your image to
>>>>> 8000000, which is already reserved.
>>>>>
>>>>> What's the output of the iomem command before and after the failed
>>>>> boot attempt?
>>>>>
>>>>>> __request_region ok: 0x08000000:0x0801ffff flags=0x200
>>>>>> mtdrom0.kernel: read ofs: 0x00000000 count: 0x00020000
>>>>>> __request_region ok: 0x08000000:0x0803ffff flags=0x200
>>>>>> mtdrom0.kernel: read ofs: 0x00020000 count: 0x00020000
>>>>>> .
>>>>>> .
>>>>>> mtdrom0.kernel: read ofs: 0x00fe0000 count: 0x00018000
>>>>>> __request_region ok: 0x08000000:0x08ff7fff flags=0x200
>>>>>> mtdrom0.rootfs: read ofs: 0x00000000 count: 0x00000800
>>>>>> __request_region: 0x08b30000:0x08b4ffff (image) conflicts with
>>>>> 0x08000000:0x08ff7fff (image)
>>>>>> unable to request SDRAM 0x08b30000-0x08b4ffff
>>>>>> handler failed with: Out of memory
>>>>>
>>>>> Just to be sure: You don't set global.bootm.image.loadaddr, right?
>>>>>
>>>>> Cheers,
>>>>> Ahmad
>>>>>
>>>>>>
>>>>>> Appreciate your advice,
>>>>>> Cheers,
>>>>>> Lior.
>>>>>>
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Ahmad Fatoum <a.fatoum@pengutronix.de>
>>>>>>> Sent: Monday, June 12, 2023 6:08 PM
>>>>>>> To: Lior Weintraub <liorw@pliops.com>; Ahmad Fatoum
>>>> <ahmad@a3f.at>;
>>>>>>> barebox@lists.infradead.org
>>>>>>> Subject: Re: [PATCH v2] Porting barebox to a new SoC
>>>>>>>
>>>>>>> CAUTION: External Sender
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> On 12.06.23 16:59, Lior Weintraub wrote:
>>>>>>>> Hello Ahmad,
>>>>>>>>
>>>>>>>> Just for simple simulations we make the ROM size 192MB so it can
>>>> include
>>>>> all
>>>>>>> needed artifacts.
>>>>>>>
>>>>>>> I am not convinced that this is much of a simplification over having
>>>>>>> your Qemu machine provide cfi-flash.
>>>>>>>
>>>>>>>> When we get this simple system to work we will move the relevant
>> parts
>>>>> to
>>>>>>> BL2.
>>>>>>>
>>>>>>> Ok.
>>>>>>>
>>>>>>>> DRAM is also simulated now as SRAM so we are not worried about
>>>>>>> initializations.
>>>>>>>>
>>>>>>>> So if I understand correctly, we can decide that address 0x10000000
>> will
>>>>> be
>>>>>>> reserved for "flash" and add the following node:
>>>>>>>> flash@0 {
>>>>>>>
>>>>>>> flash@10000000, but that's just for informational purposes.
>>>>>>>
>>>>>>>> compatible = "mtd-rom";
>>>>>>>> probe-type = "map_rom";
>>>>>>>> reg = <0x10000000 0x10000000>;
>>>>>>>> bank-width = <4>;
>>>>>>>> device-width = <1>;
>>>>>>>>
>>>>>>>> #address-cells = <1>;
>>>>>>>> #size-cells = <1>;
>>>>>>>> kernel@0 {
>>>>>>>> label = "kernel";
>>>>>>>> reg = <0x0 0x01000000>;
>>>>>>>> };
>>>>>>>> rootfs@1000000 {
>>>>>>>> label = "rootfs";
>>>>>>>> reg = <0x01000000 0x00800000>;
>>>>>>>> };
>>>>>>>> };
>>>>>>>>
>>>>>>>> When I use this node on our DT I see the following devinfo:
>>>>>>>> barebox:/ devinfo
>>>>>>>> `-- global
>>>>>>>> `-- nv
>>>>>>>> `-- platform
>>>>>>>> `-- machine
>>>>>>>> `-- psci.of
>>>>>>>> `-- 1000000010000000.flash@0.of
>>>>>>>
>>>>>>> As you can see the address is wrong. That's because you have
>>>>>>> #address-cells = <2>;
>>>>>>> #size-cells = <2>;
>>>>>>>
>>>>>>> Yet, you wrote reg as if it was <1>/<1>. Change it to
>>>>>>>
>>>>>>> reg = <0x0 0x10000000 0x0 0x10000000>;
>>>>>>>
>>>>>>> Remember all device tree integers are 32-bit big endian.
>>>>>>>
>>>>>>>> `-- soc.of
>>>>>>>> `-- c000000000.sram@c000000000.of
>>>>>>>> `-- soc:pmu.of
>>>>>>>> `-- soc:timer.of
>>>>>>>> `-- e000000000.interrupt-controller@E000000000.of
>>>>>>>> `-- mem0
>>>>>>>> `-- 0x00000000-0x0fffffff ( 256 MiB): /dev/ram0
>>>>>>>> `-- mem1
>>>>>>>> `-- 0x00000000-0xffffffffffffffff ( 0 Bytes): /dev/mem
>>>>>>>> `-- amba
>>>>>>>> `-- d000307000.serial@d000307000.of
>>>>>>>> `-- cs0
>>>>>>>> `-- 0x00000000-0xffffffffffffffff ( 0 Bytes): /dev/cs0
>>>>>>>> `-- spi
>>>>>>>> `-- fs
>>>>>>>> `-- ramfs0
>>>>>>>> `-- devfs0
>>>>>>>> `-- pstore0
>>>>>>>>
>>>>>>>> Not sure how to proceed from here...
>>>>>>>
>>>>>>> Type drvinfo command to see what drivers are bound to what devices.
>>>>>>> If you see no driver bound to your flash device, then maybe you need
>>>>>>> to enable the correct driver, that would be CONFIG_MTD_MTDRAM
>>>> (which
>>>>>>> handles both read-only and read-write memory mapped MTD).
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Ahmad
>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Lior.
>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Ahmad Fatoum <a.fatoum@pengutronix.de>
>>>>>>>>> Sent: Monday, June 12, 2023 3:29 PM
>>>>>>>>> To: Lior Weintraub <liorw@pliops.com>; Ahmad Fatoum
>>>>> <ahmad@a3f.at>;
>>>>>>>>> barebox@lists.infradead.org
>>>>>>>>> Subject: Re: [PATCH v2] Porting barebox to a new SoC
>>>>>>>>>
>>>>>>>>> CAUTION: External Sender
>>>>>>>>>
>>>>>>>>> Hello Lior,
>>>>>>>>>
>>>>>>>>> On 12.06.23 11:27, Lior Weintraub wrote:
>>>>>>>>>> Hi Ahmad,
>>>>>>>>>>
>>>>>>>>>> Regarding the rootfs and Linux run question:
>>>>>>>>>> Our board doesn't include eMMC\SD card.
>>>>>>>>>> We only have our NOR Flash to store the binaries and our BL1 code
>>>> will
>>>>>>> make
>>>>>>>>> sure to copy those blobs into DRAM.
>>>>>>>>>
>>>>>>>>> How could BL1 copy artifacts in DRAM when BL2 first needs to set up
>>>>>>> DRAM?
>>>>>>>>>
>>>>>>>>>> The use of QEMU needs to be as simple as possible so no hidden
>> virtio
>>>>>>>>> drivers and such because we would like to simulate the real HW flow.
>>>>>>>>>
>>>>>>>>> cfi-flash is just memory-mapped flash, which is the next simplest
>> thing
>>>>>>>>> after BL1 copies stuff into (limited-to-4M) on-chip SRAM.
>>>>>>>>>
>>>>>>>>>> Our DTS file now includes the GIC, timer and arm,psci-1.0.
>>>>>>>>>> We have an initial build of Linux kernel Image (using buildroot) and a
>>>>>>>>> rootfs.cpio.xz.
>>>>>>>>>> I assume we can somehow reserve a portion of the DRAM to store
>>>>> those
>>>>>>>>> binaries and let barebox boot this Linux.
>>>>>>>>>
>>>>>>>>> You can make this work, but this is not how your actual system will
>>>>>>>>> look like and trying to make this work is harder than it needs to be.
>>>>>>>>>
>>>>>>>>> Just add a cfi-flash that corresponds to the Linux/rootfs flash in
>>>>>>>>> your actual system, then boot with bootm (type help bootm for info
>>>>>>>>> on how to use it). You don't need to hardcode the load addresses,
>>>>>>>>> barebox will determine them automatically.
>>>>>>>>>
>>>>>>>>>> Can you please advise how to make it work?
>>>>>>>>>
>>>>>>>>> For completion's sake, if you have 64M of RAM that's preloaded with
>>>>>>>>> boot images:
>>>>>>>>>
>>>>>>>>> - Remove the 64M from the barebox /memory node. You can use a
>>>>>>> different
>>>>>>>>> DT for kernel, but if you have memory that barebox shouldn't
>>>> override,
>>>>>>>>> you need to tell it that.
>>>>>>>>>
>>>>>>>>> - Add a mtd-rom node that describes these 64M that you have. You
>>>> can
>>>>>>>>> add partitions for the region used for kernel and oftree
>>>>>>>>>
>>>>>>>>> - boot with bootm -o /dev/mtdrom0.oftree -r /dev/mtdrom0.initrd
>> \
>>>>>>>>> /dev/mtdrom0.kernel
>>>>>>>>>
>>>>>>>>> That's admittedly cumbersome, but necessary, so barebox knows
>> what
>>>>>>>>> memory
>>>>>>>>> it may use for itself and what memory may be used for boot.
>>>>>>>>>
>>>>>>>>> Correct solution is to use cfi-flash or similar.
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>> Ahmad
>>>>>>>>> --
>>>>>>>>> Pengutronix e.K. | |
>>>>>>>>> Steuerwalder Str. 21 | http://www.pengutronix.de/ |
>>>>>>>>> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0
>> |
>>>>>>>>> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-
>>>> 5555
>>>>> |
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Pengutronix e.K. | |
>>>>>>> Steuerwalder Str. 21 | http://www.pengutronix.de/ |
>>>>>>> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
>>>>>>> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-
>> 5555
>>>> |
>>>>>>
>>>>>
>>>>> --
>>>>> Pengutronix e.K. | |
>>>>> Steuerwalder Str. 21 | http://www.pengutronix.de/ |
>>>>> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
>>>>> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
>>>
>>
>> --
>> Pengutronix e.K. | |
>> Steuerwalder Str. 21 | http://www.pengutronix.de/ |
>> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
>> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
>
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply [flat|nested] 40+ messages in thread
* RE: [PATCH v2] Porting barebox to a new SoC
2023-06-19 15:22 ` Ahmad Fatoum
@ 2023-06-25 20:33 ` Lior Weintraub
2023-06-30 5:52 ` Ahmad Fatoum
0 siblings, 1 reply; 40+ messages in thread
From: Lior Weintraub @ 2023-06-25 20:33 UTC (permalink / raw)
To: Ahmad Fatoum, Ahmad Fatoum, barebox
Hello Ahmad,
I failed to reproduce this issue on virt because the addresses and peripherals on virt machine are different and it is difficult to change our code to match that.
If you think this is critical I will make extra effort to make it work.
AFAIU, this suggestion was made to debug the "conflict" issue.
Currently the workaround I am using is just to set the size of the kernel partition to match the exact size of the "Image" file.
The other issue I am facing is that Kernel seems stuck on cpu_do_idle and there is no login prompt from the kernel.
As you recall, I am running on a custom QEMU that tries to emulate our platform.
I suspect that I did something wrong with the GICv3 and Timers connectivity.
The code I used was based on examples I saw on sbsa-ref.c and virt.c.
In addition, I declared the GICv3 and timers on our device tree.
I running QEMU with "-d int" so I am also getting trace of exceptions and interrupts.
The kernel log until it is getting stuck is:
Loaded initrd unknown '/dev/ram0.rootfs'
initrd is at 0x0000000008cb0000-0x00000000094affff
Loading devicetree from '/dev/ram0.oftree'
__request_region ok: 0x094b0000:0x094b15e4 flags=0x200
commandline: <NULL>
Loaded kernel to 0x08000000, devicetree at 0x094b0000
exitcall-> nv_exit+0x0/0x30
exitcall-> devices_shutdown+0x0/0xbc
remove-> machine
remove-> mem1
remove-> mem0
remove-> pstore0
remove-> devfs0
remove-> ramfs0
remove-> d000307000.serial@d000307000.of
remove-> soc:timer.of
exitcall-> arch_shutdown+0x0/0x14
Exception return from AArch64 EL2 to AArch64 EL1 PC 0x893e098
Taking exception 11 [Hypervisor Call] on CPU 0
...from EL1 to EL2
...with ESR 0x16/0x5a000000
...with ELR 0xffffffc00801c988
...to EL2 PC 0x875d400 PSTATE 0x3c9
Exception return from AArch64 EL2 to AArch64 EL1 PC 0xffffffc00801c988
Taking exception 13 [Secure Monitor Call] on CPU 0
...from EL1 to EL3
...with ESR 0x17/0x5e000000
...with ELR 0xffffffc00802112c
...to EL3 PC 0x10005400 PSTATE 0x3cd
Exception return from AArch64 EL3 to AArch64 EL1 PC 0xffffffc00802112c
Taking exception 13 [Secure Monitor Call] on CPU 0
...from EL1 to EL3
...with ESR 0x17/0x5e000000
...with ELR 0xffffffc00802112c
...to EL3 PC 0x10005400 PSTATE 0x3cd
Exception return from AArch64 EL3 to AArch64 EL1 PC 0xffffffc00802112c
Taking exception 13 [Secure Monitor Call] on CPU 0
...from EL1 to EL3
...with ESR 0x17/0x5e000000
...with ELR 0xffffffc00802112c
...to EL3 PC 0x10005400 PSTATE 0x3cd
Exception return from AArch64 EL3 to AArch64 EL1 PC 0xffffffc00802112c
Taking exception 13 [Secure Monitor Call] on CPU 0
...from EL1 to EL3
...with ESR 0x17/0x5e000000
...with ELR 0xffffffc00802112c
...to EL3 PC 0x10005400 PSTATE 0x3cd
Exception return from AArch64 EL3 to AArch64 EL1 PC 0xffffffc00802112c
Taking exception 13 [Secure Monitor Call] on CPU 0
...from EL1 to EL3
...with ESR 0x17/0x5e000000
...with ELR 0xffffffc00897a1ac
...to EL3 PC 0x10005400 PSTATE 0x3cd
Exception return from AArch64 EL3 to AArch64 EL1 PC 0xffffffc00897a1ac
Taking exception 13 [Secure Monitor Call] on CPU 0
...from EL1 to EL3
...with ESR 0x17/0x5e000000
...with ELR 0xffffffc00897a230
...to EL3 PC 0x10005400 PSTATE 0x3cd
Exception return from AArch64 EL3 to AArch64 EL1 PC 0xffffffc00897a230
Taking exception 13 [Secure Monitor Call] on CPU 0
...from EL1 to EL3
...with ESR 0x17/0x5e000000
...with ELR 0xffffffc00802112c
...to EL3 PC 0x10005400 PSTATE 0x3cd
Exception return from AArch64 EL3 to AArch64 EL1 PC 0xffffffc00802112c
Taking exception 13 [Secure Monitor Call] on CPU 0
...from EL1 to EL3
...with ESR 0x17/0x5e000000
...with ELR 0xffffffc00802112c
...to EL3 PC 0x10005400 PSTATE 0x3cd
Exception return from AArch64 EL3 to AArch64 EL1 PC 0xffffffc00802112c
Taking exception 13 [Secure Monitor Call] on CPU 0
...from EL1 to EL3
...with ESR 0x17/0x5e000000
...with ELR 0xffffffc00802112c
...to EL3 PC 0x10005400 PSTATE 0x3cd
Exception return from AArch64 EL3 to AArch64 EL1 PC 0xffffffc00802112c
Taking exception 13 [Secure Monitor Call] on CPU 0
...from EL1 to EL3
...with ESR 0x17/0x5e000000
...with ELR 0xffffffc008021640
...to EL3 PC 0x10005400 PSTATE 0x3cd
Exception return from AArch64 EL3 to AArch64 EL1 PC 0xffffffc008021640
Pliops Kernel
Booting Linux on physical CPU 0x0000000000 [0x410fd034]
Linux version 6.4.0-rc7 (pliops@dev-liorw) (aarch64-buildroot-linux-gnu-gcc.br_real (Buildroot 2023.02.1-95-g8391404e23) 11.3.0, GNU ld (GNU Binutils) 2.38) #11 SMP Sun Jun 25 22:03:04 IDT 2023
Machine model: Pliops Spider MK-I EVK
efi: UEFI not found.
Zone ranges:
DMA [mem 0x0000000000000000-0x000000002fffffff]
DMA32 empty
Normal empty
Movable zone start for each node
Early memory node ranges
node 0: [mem 0x0000000000000000-0x000000002fffffff]
Initmem setup node 0 [mem 0x0000000000000000-0x000000002fffffff]
psci: probing for conduit method from DT.
psci: PSCIv1.1 detected in firmware.
psci: Using standard PSCI v0.2 function IDs
psci: MIGRATE_INFO_TYPE not supported.
psci: SMC Calling Convention v1.2
percpu: Embedded 26 pages/cpu s67752 r8192 d30552 u106496
Detected VIPT I-cache on CPU0
CPU features: detected: GIC system register CPU interface
CPU features: detected: ARM erratum 843419
CPU features: detected: ARM erratum 845719
alternatives: applying boot alternatives
Kernel command line: cpuidle.off=1
Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes, linear)
Inode-cache hash table entries: 65536 (order: 7, 524288 bytes, linear)
Built 1 zonelists, mobility grouping on. Total pages: 193536
mem auto-init: stack:off, heap alloc:off, heap free:off
Memory: 749712K/786432K available (7488K kernel code, 1300K rwdata, 1892K rodata, 1664K init, 427K bss, 36720K reserved, 0K cma-reserved)
SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
trace event string verifier disabled
rcu: Hierarchical RCU implementation.
rcu: RCU event tracing is enabled.
rcu: RCU restricting CPUs from NR_CPUS=256 to nr_cpu_ids=1.
rcu: RCU calculated value of scheduler-enlistment delay is 25 jiffies.
rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=1
NR_IRQS: 64, nr_irqs: 64, preallocated irqs: 0
GICv3: GIC: Using split EOI/Deactivate mode
GICv3: 64 SPIs implemented
GICv3: 0 Extended SPIs implemented
Root IRQ handler: gic_handle_irq
GICv3: GICv3 features: 16 PPIs
GICv3: CPU0: found redistributor 0 region 0:0x000000e000060000
ITS [mem 0xe000040000-0xe00005ffff]
ITS@0x000000e000040000: allocated 8192 Devices @a0000 (indirect, esz 8, psz 64K, shr 1)
ITS@0x000000e000040000: allocated 8192 Interrupt Collections @b0000 (flat, esz 8, psz 64K, shr 1)
GICv3: using LPI property table @0x00000000000c0000
GICv3: CPU0: using allocated LPI pending table @0x00000000000d0000
rcu: srcu_init: Setting srcu_struct sizes based on contention.
arch_timer: cp15 timer(s) running at 62.50MHz (phys).
clocksource: arch_sys_counter: mask: 0x1ffffffffffffff max_cycles: 0x1cd42e208c, max_idle_ns: 881590405314 ns
sched_clock: 57 bits at 63MHz, resolution 16ns, wraps every 4398046511096ns
Console: colour dummy device 80x25
printk: console [tty0] enabled
Calibrating delay loop (skipped), value calculated using timer frequency.. 125.00 BogoMIPS (lpj=250000)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 2048 (order: 2, 16384 bytes, linear)
Mountpoint-cache hash table entries: 2048 (order: 2, 16384 bytes, linear)
rcu: Hierarchical SRCU implementation.
rcu: Max phase no-delay instances is 1000.
Platform MSI: gic-its@E000040000 domain created
PCI/MSI: /soc/interrupt-controller@E000000000/gic-its@E000040000 domain created
EFI services will not be available.
smp: Bringing up secondary CPUs ...
smp: Brought up 1 node, 1 CPU
SMP: Total of 1 processors activated.
CPU features: detected: 32-bit EL0 Support
CPU features: detected: CRC32 instructions
CPU: All CPU(s) started at EL2
alternatives: applying system-wide alternatives
devtmpfs: initialized
clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns
futex hash table entries: 256 (order: 2, 16384 bytes, linear)
DMI not present or invalid.
NET: Registered PF_NETLINK/PF_ROUTE protocol family
DMA: preallocated 128 KiB GFP_KERNEL pool for atomic allocations
DMA: preallocated 128 KiB GFP_KERNEL|GFP_DMA pool for atomic allocations
DMA: preallocated 128 KiB GFP_KERNEL|GFP_DMA32 pool for atomic allocations
hw-breakpoint: found 6 breakpoint and 4 watchpoint registers.
ASID allocator initialised with 65536 entries
Serial: AMBA PL011 UART driver
d000307000.serial: ttyAMA0 at MMIO 0xd000307000 (irq = 14, base_baud = 0) is a PL011 rev1
printk: console [ttyAMA0] enabled
iommu: Default domain type: Translated
iommu: DMA domain TLB invalidation policy: strict mode
SCSI subsystem initialized
pps_core: LinuxPPS API ver. 1 registered
pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
PTP clock support registered
mctp: management component transport protocol core
NET: Registered PF_MCTP protocol family
vgaarb: loaded
clocksource: Switched to clocksource arch_sys_counter
NET: Registered PF_INET protocol family
IP idents hash table entries: 16384 (order: 5, 131072 bytes, linear)
tcp_listen_portaddr_hash hash table entries: 512 (order: 1, 8192 bytes, linear)
Table-perturb hash table entries: 65536 (order: 6, 262144 bytes, linear)
TCP established hash table entries: 8192 (order: 4, 65536 bytes, linear)
TCP bind hash table entries: 8192 (order: 6, 262144 bytes, linear)
TCP: Hash tables configured (established 8192 bind 8192)
UDP hash table entries: 512 (order: 2, 16384 bytes, linear)
UDP-Lite hash table entries: 512 (order: 2, 16384 bytes, linear)
NET: Registered PF_UNIX/PF_LOCAL protocol family
PCI: CLS 0 bytes, default 64
workingset: timestamp_bits=46 max_order=18 bucket_order=0
fuse: init (API version 7.38)
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 249)
io scheduler mq-deadline registered
io scheduler kyber registered
Unpacking initramfs...
Freeing initrd memory: 8192K
SMCCC: SOC_ID: ARCH_SOC_ID not implemented, skipping ....
hw perfevents: enabled with armv8_cortex_a53 PMU driver, 7 counters available
NET: Registered PF_INET6 protocol family
Segment Routing with IPv6
In-situ OAM (IOAM) with IPv6
sit: IPv6, IPv4 and MPLS over IPv4 tunneling driver
NET: Registered PF_PACKET protocol family
NET: Registered PF_KEY protocol family
NET: Registered PF_VSOCK protocol family
registered taskstats version 1
clk: Disabling unused clocks
Freeing unused kernel memory: 1664K
Your advise is much appreciated,
Cheers,
Lior.
> -----Original Message-----
> From: Ahmad Fatoum <a.fatoum@pengutronix.de>
> Sent: Monday, June 19, 2023 6:23 PM
> To: Lior Weintraub <liorw@pliops.com>; Ahmad Fatoum <ahmad@a3f.at>;
> barebox@lists.infradead.org
> Subject: Re: [PATCH v2] Porting barebox to a new SoC
>
> CAUTION: External Sender
>
> On 19.06.23 08:40, Lior Weintraub wrote:
> > Hello Ahmad,
> >
> > Thanks again for your great tips.
> > Using the addpart command seems to work and give same results as the
> pre-partitioned flash node on the DT.
> > When I deleted the whole flash node and extended the memory node to
> include all 768MB the following commands worked on barebox:
> > addpart /dev/ram0
> "512M@0(dram512),0xB30000@0x20000000(kernel),0x8000@0x20FF800
> 0(oftree),0x800000@0x21000000(rootfs),-"
> > After that, checking the devinfo gave:
> > `-- mem0
> > `-- 0x00000000-0x2fffffff ( 768 MiB): /dev/ram0
> > `-- 0x00000000-0x1fffffff ( 512 MiB): /dev/ram0.dram512
> > `-- 0x20000000-0x20b2ffff ( 11.2 MiB): /dev/ram0.kernel
> > `-- 0x20ff8000-0x20ffffff ( 32 KiB): /dev/ram0.oftree
> > `-- 0x21000000-0x217fffff ( 8 MiB): /dev/ram0.rootfs
> > `-- 0x21800000-0x2fffffff ( 232 MiB): /dev/
> > Now running the bootm:
> > bootm -o /dev/ram0.oftree -r /dev/ram0.rootfs -a 0 /dev/ram0.kernel
> >
> > The Linux kernel starts running but has issues (still probably missing parts on
> my QEMU machine).
> >
> > Notice that I had to set the "kernel" partition to size 0xB30000 because
> otherwise it gave me the same error of "conflict":
> > __request_region ok: 0x00000000:0x00ffffff flags=0x200
> > __request_region ok: 0x00000000:0x00ff7fff flags=0x200
> > __request_region: 0x00b30000:0x00b4ffff (image) conflicts with
> 0x00000000:0x00ff7fff (image)
> > unable to request SDRAM 0x00b30000-0x00b4ffff
> > handler failed with: Out of memory
> >
> > Could it be somehow related to the way I build the kernel?
>
> Can you reproduce this with normal qemu aarch64 virt machine?
>
> Cheers,
> Ahmad
>
> > Cheers,
> > Lior.
> >
> >
> >> -----Original Message-----
> >> From: Ahmad Fatoum <a.fatoum@pengutronix.de>
> >> Sent: Friday, June 16, 2023 7:21 PM
> >> To: Lior Weintraub <liorw@pliops.com>; Ahmad Fatoum <ahmad@a3f.at>;
> >> barebox@lists.infradead.org
> >> Subject: Re: [PATCH v2] Porting barebox to a new SoC
> >>
> >> CAUTION: External Sender
> >>
> >> Hello Lior,
> >>
> >> On 14.06.23 08:42, Lior Weintraub wrote:
> >>> Hi Ahmad,
> >>>
> >>> Looks like I found the issue :-)
> >>>
> >>> When I declared the flash@0 node I used about 16MB for the kernel
> >> partition even though currently my kernel image is around 11MB:
> >>> flash@0 {
> >>> compatible = "mtd-rom";
> >>> probe-type = "map_rom";
> >>> reg = <0x0 0x20000000 0x0 0x10000000>; /* Offset 512MB, size
> 256MB
> >> */
> >>> bank-width = <4>;
> >>> device-width = <1>;
> >>>
> >>> #address-cells = <1>;
> >>> #size-cells = <1>;
> >>> kernel@0 { /* 16MB (minus 32KB) */
> >>> label = "kernel";
> >>> //reg = <0x0 0x00FF8000>; // This line caused the error
> >>> reg = <0x0 0x00b30000>;
> >>> };
> >>> oftree@00FF8000 { /* 32KB for DTB image */
> >>> label = "oftree";
> >>> reg = <0x00FF8000 0x00008000>;
> >>> };
> >>> rootfs@1000000 { /* Offset 512MB+16MB with size 8MB */
> >>> label = "rootfs";
> >>> reg = <0x01000000 0x00800000>;
> >>> };
> >>> };
> >>>
> >>> From the error message I saw that barebox tried to place the rootfs on
> >> address 0xb30000 and that conflicted with the kernel:
> >>> mtdrom0.kernel: read ofs: 0x00fe0000 count: 0x00018000
> >>> __request_region ok: 0x00000000:0x00ff7fff flags=0x200
> >>> mtdrom0.rootfs: read ofs: 0x00000000 count: 0x00000800
> >>> __request_region: 0x00b30000:0x00b4ffff (image) conflicts with
> >> 0x00000000:0x00ff7fff (image)
> >>
> >> This error message still doesn't make sense to me. No idea why this
> conflicts.
> >> I see now though that I made this more complicated that it needs be. Please
> >> scratch all that, remove the mtd-rom and revert the /memory node to
> >> encompass
> >> all memory. Then you can at runtime, just create the partitions with the
> >> addpart
> >> command (see help addpart for info). Then you can boot normally.
> >>
> >>>
> >>> So I changed the kernel@0 node and used size 0x00b30000 and now
> kernel
> >> starts running.
> >>> The kernel is producing all kinds of errors but at least it's a start :-)
> >>> The errors are now related to pieces of HW that we didn't implement on
> >> QEMU so it is understandable.
> >>>
> >>> How can we control where the rootfs is copied to?
> >>
> >> Normally, global.bootm.initrd.loadaddr, but you shouldn't need to do
> >> that. Try it with addpart and let me know.
> >>
> >> Cheers,
> >> Ahmad
> >>
> >>>
> >>> Thanks again for your kind advise and patience.
> >>> Cheers,
> >>> Lior.
> >>>
> >>>> -----Original Message-----
> >>>> From: Lior Weintraub
> >>>> Sent: Tuesday, June 13, 2023 4:28 PM
> >>>> To: Ahmad Fatoum <a.fatoum@pengutronix.de>; Ahmad Fatoum
> >>>> <ahmad@a3f.at>; barebox@lists.infradead.org
> >>>> Subject: RE: [PATCH v2] Porting barebox to a new SoC
> >>>>
> >>>> Hi Ahmad,
> >>>>
> >>>> I also thought that load address was suspicious (0x8000000) but then I
> >> saw
> >>>> the following comment on nxp_imx8mq_evk_start:
> >>>> /*
> >>>> * On completion the TF-A will jump to
> >>>> MX8MQ_ATF_BL33_BASE_ADDR
> >>>> * in EL2. Copy the image there, but replace the PBL part of
> >>>> * that image with ourselves. On a high assurance boot only
> >>>> the
> >>>> * currently running code is validated and contains the
> >>>> checksum
> >>>> * for the piggy data, so we need to ensure that we are
> >>>> running
> >>>> * the same code in DRAM.
> >>>> */
> >>>> Our code was based on this function and as a result it copies the barebox
> >>>> image into address 0x8000000 (which is our settings of
> >>>> ATF_BL33_BASE_ADDR).
> >>>> The fact that Linux image is also copied there seemed reasonable (I might
> be
> >>>> wrong here) because once loading is done and we jump to Linux there is
> no
> >>>> need for barebox code anymore.
> >>>>
> >>>> In any case, at that time when I thought it was wrong I also tried to run
> the
> >>>> bootm command with "-a 0" but I got exactly the same error:
> >>>> barebox:/ bootm -o /dev/mtdrom0.oftree -r /dev/mtdrom0.rootfs -a 0
> >>>> /dev/mtdrom0.kernel
> >>>> getopt: optindex: 1 nonopts: 0 optind: 1
> >>>> getopt: optindex: 1 nonopts: 0 optind: 3
> >>>> getopt: optindex: 1 nonopts: 0 optind: 5
> >>>> getopt: optindex: 1 nonopts: 0 optind: 7
> >>>> mtdrom0.kernel: read ofs: 0x00000000 count: 0x00001000
> >>>>
> >>>> Loading ARM aarch64 Linux image '/dev/mtdrom0.kernel'
> >>>> header 00000000: 4d 5a 40 fa 3f 1a 23 14 00 00 00 00 00 00 00 00
> >>>> MZ@.?.#.........
> >>>> header 00000010: 00 00 b3 00 00 00 00 00 0a 00 00 00 00 00 00 00
> >>>> ................
> >>>> header 00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> >>>> ................
> >>>> header 00000030: 00 00 00 00 00 00 00 00 41 52 4d 64 40 00 00 00
> >>>> ........ARMd@...
> >>>> header 00000040: 50 45 00 00 64 aa 02 00 00 00 00 00 00 00 00 00
> >>>> PE..d...........
> >>>> booti: Kernel to be loaded to 0+b30000
> >>>> __request_region ok: 0x00000000:0x0001ffff flags=0x200
> >>>> mtdrom0.kernel: read ofs: 0x00000000 count: 0x00020000
> >>>> __request_region ok: 0x00000000:0x0003ffff flags=0x200
> >>>> mtdrom0.kernel: read ofs: 0x00020000 count: 0x00020000
> >>>> __request_region ok: 0x00000000:0x0005ffff flags=0x200
> >>>> .
> >>>> .
> >>>> mtdrom0.kernel: read ofs: 0x00fe0000 count: 0x00018000
> >>>> __request_region ok: 0x00000000:0x00ff7fff flags=0x200
> >>>> mtdrom0.rootfs: read ofs: 0x00000000 count: 0x00000800
> >>>> __request_region: 0x00b30000:0x00b4ffff (image) conflicts with
> >>>> 0x00000000:0x00ff7fff (image)
> >>>> unable to request SDRAM 0x00b30000-0x00b4ffff
> >>>> handler failed with: Out of memory
> >>>>
> >>>>
> >>>> The iomem before:
> >>>> barebox:/ iomem
> >>>> 0x0000000000000000 - 0xffffffffffffffff (size 0x0000000000000000)
> >> iomem
> >>>> 0x0000000000000000 - 0x000000001fffffff (size
> >> 0x0000000020000000)
> >>>> ram0
> >>>> 0x00000000079fef00 - 0x0000000007dfeeff (size
> >> 0x0000000000400000)
> >>>> malloc space
> >>>> 0x0000000007dfef00 - 0x0000000007dfffd1 (size
> >> 0x00000000000010d2)
> >>>> board data
> >>>> 0x0000000007e00000 - 0x0000000007e3d95f (size
> >>>> 0x000000000003d960) barebox
> >>>> 0x0000000007e3d960 - 0x0000000007e50bb7 (size
> >>>> 0x0000000000013258) barebox data
> >>>> 0x0000000007e50bb8 - 0x0000000007e53b3f (size
> >>>> 0x0000000000002f88) bss
> >>>> 0x0000000007ff0000 - 0x0000000007ff7fff (size
> >> 0x0000000000008000)
> >>>> stack
> >>>> 0x0000000020000000 - 0x000000002fffffff (size
> >> 0x0000000010000000)
> >>>> 20000000.flash@0.of
> >>>> 0x000000d000307000 - 0x000000d000307fff (size
> >>>> 0x0000000000001000) amba
> >>>>
> >>>> After:
> >>>> barebox:/ iomem
> >>>> 0x0000000000000000 - 0xffffffffffffffff (size 0x0000000000000000)
> >> iomem
> >>>> 0x0000000000000000 - 0x000000001fffffff (size
> >> 0x0000000020000000)
> >>>> ram0
> >>>> 0x00000000079fef00 - 0x0000000007dfeeff (size
> >> 0x0000000000400000)
> >>>> malloc space
> >>>> 0x0000000007dfef00 - 0x0000000007dfffd1 (size
> >> 0x00000000000010d2)
> >>>> board data
> >>>> 0x0000000007e00000 - 0x0000000007e3d95f (size
> >>>> 0x000000000003d960) barebox
> >>>> 0x0000000007e3d960 - 0x0000000007e50bb7 (size
> >>>> 0x0000000000013258) barebox data
> >>>> 0x0000000007e50bb8 - 0x0000000007e53b3f (size
> >>>> 0x0000000000002f88) bss
> >>>> 0x0000000007ff0000 - 0x0000000007ff7fff (size
> >> 0x0000000000008000)
> >>>> stack
> >>>> 0x0000000020000000 - 0x000000002fffffff (size
> >> 0x0000000010000000)
> >>>> 20000000.flash@0.of
> >>>> 0x000000d000307000 - 0x000000d000307fff (size
> >>>> 0x0000000000001000) amba
> >>>>
> >>>> I did not set global.bootm.image.loadaddr
> >>>> Speaking of env, the last few lines on the barebox terminal are:
> >>>> initcall-> load_environment+0x0/0x4c
> >>>> loading defaultenv
> >>>> environment load /dev/env0: No such file or directory
> >>>> Maybe you have to create the partition.
> >>>> initcalls done
> >>>>
> >>>> When I run "printenv" I am getting:
> >>>> barebox:/ printenv
> >>>> locals:
> >>>> globals:
> >>>> bootsource=unknown
> >>>> bootsource_instance=unknown
> >>>> PATH=/env/bin
> >>>>
> >>>> Hope this info can help.
> >>>> Cheers,
> >>>> Lior.
> >>>>
> >>>>
> >>>>> -----Original Message-----
> >>>>> From: Ahmad Fatoum <a.fatoum@pengutronix.de>
> >>>>> Sent: Tuesday, June 13, 2023 3:51 PM
> >>>>> To: Lior Weintraub <liorw@pliops.com>; Ahmad Fatoum
> >> <ahmad@a3f.at>;
> >>>>> barebox@lists.infradead.org
> >>>>> Subject: Re: [PATCH v2] Porting barebox to a new SoC
> >>>>>
> >>>>> CAUTION: External Sender
> >>>>>
> >>>>> On 13.06.23 14:39, Lior Weintraub wrote:
> >>>>>> Hi Ahmad,
> >>>>>>
> >>>>>> As usual, your comments are spot on :-)
> >>>>>>
> >>>>>> After fixing the DT, devinfo command shows correct flash node:
> >>>>>> `-- 20000000.flash@0.of
> >>>>>> `-- mtdrom0
> >>>>>> `-- 0x00000000-0x0fffffff ( 256 MiB): /dev/mtdrom0
> >>>>>> `-- mtdrom0.kernel
> >>>>>> `-- 0x00000000-0x00ff7fff ( 16 MiB): /dev/mtdrom0.kernel
> >>>>>> `-- mtdrom0.oftree
> >>>>>> `-- 0x00000000-0x00007fff ( 32 KiB): /dev/mtdrom0.oftree
> >>>>>> `-- mtdrom0.rootfs
> >>>>>> `-- 0x00000000-0x007fffff ( 8 MiB): /dev/mtdrom0.rootfs
> >>>>>>
> >>>>>> As can be seen above, we chose to map this "flash" node on DRAM
> >>>> address
> >>>>> 0x20000000 (offset 512MB).
> >>>>>> The BL1 code correctly copy the 3 artifacts into those location (verified
> >> the
> >>>>> content via "md -l -s /dev/mtdrom0.kernel").
> >>>>>> Running "drvinfo" shows:
> >>>>>> mtdram
> >>>>>> 20000000.flash@0.of
> >>>>>>
> >>>>>> Now when I try to run "bootm -o /dev/mtdrom0.oftree -r
> >>>>> /dev/mtdrom0.rootfs /dev/mtdrom0.kernel" I am getting this error:
> >>>>>>
> >>>>>> barebox:/ bootm -o /dev/mtdrom0.oftree -r /dev/mtdrom0.rootfs
> >>>>> /dev/mtdrom0.kernel
> >>>>>> getopt: optindex: 1 nonopts: 0 optind: 1
> >>>>>> getopt: optindex: 1 nonopts: 0 optind: 3
> >>>>>> getopt: optindex: 1 nonopts: 0 optind: 5
> >>>>>> mtdrom0.kernel: read ofs: 0x00000000 count: 0x00001000
> >>>>>>
> >>>>>> Loading ARM aarch64 Linux image '/dev/mtdrom0.kernel'
> >>>>>> header 00000000: 4d 5a 40 fa 3f 1a 23 14 00 00 00 00 00 00 00 00
> >>>>> MZ@.?.#.........
> >>>>>> header 00000010: 00 00 b3 00 00 00 00 00 0a 00 00 00 00 00 00 00
> >>>>> ................
> >>>>>> header 00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> >>>>> ................
> >>>>>> header 00000030: 00 00 00 00 00 00 00 00 41 52 4d 64 40 00 00 00
> >>>>> ........ARMd@...
> >>>>>> header 00000040: 50 45 00 00 64 aa 02 00 00 00 00 00 00 00 00 00
> >>>>> PE..d...........
> >>>>>> booti: Kernel to be loaded to 8000000+b30000
> >>>>>
> >>>>> Kernel image is relocatable and ARM64 header in hexdump says that
> >>>>> load offset is zero. Yet, barebox wants to load your image to
> >>>>> 8000000, which is already reserved.
> >>>>>
> >>>>> What's the output of the iomem command before and after the failed
> >>>>> boot attempt?
> >>>>>
> >>>>>> __request_region ok: 0x08000000:0x0801ffff flags=0x200
> >>>>>> mtdrom0.kernel: read ofs: 0x00000000 count: 0x00020000
> >>>>>> __request_region ok: 0x08000000:0x0803ffff flags=0x200
> >>>>>> mtdrom0.kernel: read ofs: 0x00020000 count: 0x00020000
> >>>>>> .
> >>>>>> .
> >>>>>> mtdrom0.kernel: read ofs: 0x00fe0000 count: 0x00018000
> >>>>>> __request_region ok: 0x08000000:0x08ff7fff flags=0x200
> >>>>>> mtdrom0.rootfs: read ofs: 0x00000000 count: 0x00000800
> >>>>>> __request_region: 0x08b30000:0x08b4ffff (image) conflicts with
> >>>>> 0x08000000:0x08ff7fff (image)
> >>>>>> unable to request SDRAM 0x08b30000-0x08b4ffff
> >>>>>> handler failed with: Out of memory
> >>>>>
> >>>>> Just to be sure: You don't set global.bootm.image.loadaddr, right?
> >>>>>
> >>>>> Cheers,
> >>>>> Ahmad
> >>>>>
> >>>>>>
> >>>>>> Appreciate your advice,
> >>>>>> Cheers,
> >>>>>> Lior.
> >>>>>>
> >>>>>>
> >>>>>>> -----Original Message-----
> >>>>>>> From: Ahmad Fatoum <a.fatoum@pengutronix.de>
> >>>>>>> Sent: Monday, June 12, 2023 6:08 PM
> >>>>>>> To: Lior Weintraub <liorw@pliops.com>; Ahmad Fatoum
> >>>> <ahmad@a3f.at>;
> >>>>>>> barebox@lists.infradead.org
> >>>>>>> Subject: Re: [PATCH v2] Porting barebox to a new SoC
> >>>>>>>
> >>>>>>> CAUTION: External Sender
> >>>>>>>
> >>>>>>> Hi,
> >>>>>>>
> >>>>>>> On 12.06.23 16:59, Lior Weintraub wrote:
> >>>>>>>> Hello Ahmad,
> >>>>>>>>
> >>>>>>>> Just for simple simulations we make the ROM size 192MB so it can
> >>>> include
> >>>>> all
> >>>>>>> needed artifacts.
> >>>>>>>
> >>>>>>> I am not convinced that this is much of a simplification over having
> >>>>>>> your Qemu machine provide cfi-flash.
> >>>>>>>
> >>>>>>>> When we get this simple system to work we will move the relevant
> >> parts
> >>>>> to
> >>>>>>> BL2.
> >>>>>>>
> >>>>>>> Ok.
> >>>>>>>
> >>>>>>>> DRAM is also simulated now as SRAM so we are not worried about
> >>>>>>> initializations.
> >>>>>>>>
> >>>>>>>> So if I understand correctly, we can decide that address 0x10000000
> >> will
> >>>>> be
> >>>>>>> reserved for "flash" and add the following node:
> >>>>>>>> flash@0 {
> >>>>>>>
> >>>>>>> flash@10000000, but that's just for informational purposes.
> >>>>>>>
> >>>>>>>> compatible = "mtd-rom";
> >>>>>>>> probe-type = "map_rom";
> >>>>>>>> reg = <0x10000000 0x10000000>;
> >>>>>>>> bank-width = <4>;
> >>>>>>>> device-width = <1>;
> >>>>>>>>
> >>>>>>>> #address-cells = <1>;
> >>>>>>>> #size-cells = <1>;
> >>>>>>>> kernel@0 {
> >>>>>>>> label = "kernel";
> >>>>>>>> reg = <0x0 0x01000000>;
> >>>>>>>> };
> >>>>>>>> rootfs@1000000 {
> >>>>>>>> label = "rootfs";
> >>>>>>>> reg = <0x01000000 0x00800000>;
> >>>>>>>> };
> >>>>>>>> };
> >>>>>>>>
> >>>>>>>> When I use this node on our DT I see the following devinfo:
> >>>>>>>> barebox:/ devinfo
> >>>>>>>> `-- global
> >>>>>>>> `-- nv
> >>>>>>>> `-- platform
> >>>>>>>> `-- machine
> >>>>>>>> `-- psci.of
> >>>>>>>> `-- 1000000010000000.flash@0.of
> >>>>>>>
> >>>>>>> As you can see the address is wrong. That's because you have
> >>>>>>> #address-cells = <2>;
> >>>>>>> #size-cells = <2>;
> >>>>>>>
> >>>>>>> Yet, you wrote reg as if it was <1>/<1>. Change it to
> >>>>>>>
> >>>>>>> reg = <0x0 0x10000000 0x0 0x10000000>;
> >>>>>>>
> >>>>>>> Remember all device tree integers are 32-bit big endian.
> >>>>>>>
> >>>>>>>> `-- soc.of
> >>>>>>>> `-- c000000000.sram@c000000000.of
> >>>>>>>> `-- soc:pmu.of
> >>>>>>>> `-- soc:timer.of
> >>>>>>>> `-- e000000000.interrupt-controller@E000000000.of
> >>>>>>>> `-- mem0
> >>>>>>>> `-- 0x00000000-0x0fffffff ( 256 MiB): /dev/ram0
> >>>>>>>> `-- mem1
> >>>>>>>> `-- 0x00000000-0xffffffffffffffff ( 0 Bytes): /dev/mem
> >>>>>>>> `-- amba
> >>>>>>>> `-- d000307000.serial@d000307000.of
> >>>>>>>> `-- cs0
> >>>>>>>> `-- 0x00000000-0xffffffffffffffff ( 0 Bytes): /dev/cs0
> >>>>>>>> `-- spi
> >>>>>>>> `-- fs
> >>>>>>>> `-- ramfs0
> >>>>>>>> `-- devfs0
> >>>>>>>> `-- pstore0
> >>>>>>>>
> >>>>>>>> Not sure how to proceed from here...
> >>>>>>>
> >>>>>>> Type drvinfo command to see what drivers are bound to what
> devices.
> >>>>>>> If you see no driver bound to your flash device, then maybe you need
> >>>>>>> to enable the correct driver, that would be CONFIG_MTD_MTDRAM
> >>>> (which
> >>>>>>> handles both read-only and read-write memory mapped MTD).
> >>>>>>>
> >>>>>>> Cheers,
> >>>>>>> Ahmad
> >>>>>>>
> >>>>>>>> Cheers,
> >>>>>>>> Lior.
> >>>>>>>>
> >>>>>>>>> -----Original Message-----
> >>>>>>>>> From: Ahmad Fatoum <a.fatoum@pengutronix.de>
> >>>>>>>>> Sent: Monday, June 12, 2023 3:29 PM
> >>>>>>>>> To: Lior Weintraub <liorw@pliops.com>; Ahmad Fatoum
> >>>>> <ahmad@a3f.at>;
> >>>>>>>>> barebox@lists.infradead.org
> >>>>>>>>> Subject: Re: [PATCH v2] Porting barebox to a new SoC
> >>>>>>>>>
> >>>>>>>>> CAUTION: External Sender
> >>>>>>>>>
> >>>>>>>>> Hello Lior,
> >>>>>>>>>
> >>>>>>>>> On 12.06.23 11:27, Lior Weintraub wrote:
> >>>>>>>>>> Hi Ahmad,
> >>>>>>>>>>
> >>>>>>>>>> Regarding the rootfs and Linux run question:
> >>>>>>>>>> Our board doesn't include eMMC\SD card.
> >>>>>>>>>> We only have our NOR Flash to store the binaries and our BL1
> code
> >>>> will
> >>>>>>> make
> >>>>>>>>> sure to copy those blobs into DRAM.
> >>>>>>>>>
> >>>>>>>>> How could BL1 copy artifacts in DRAM when BL2 first needs to set
> up
> >>>>>>> DRAM?
> >>>>>>>>>
> >>>>>>>>>> The use of QEMU needs to be as simple as possible so no hidden
> >> virtio
> >>>>>>>>> drivers and such because we would like to simulate the real HW
> flow.
> >>>>>>>>>
> >>>>>>>>> cfi-flash is just memory-mapped flash, which is the next simplest
> >> thing
> >>>>>>>>> after BL1 copies stuff into (limited-to-4M) on-chip SRAM.
> >>>>>>>>>
> >>>>>>>>>> Our DTS file now includes the GIC, timer and arm,psci-1.0.
> >>>>>>>>>> We have an initial build of Linux kernel Image (using buildroot)
> and a
> >>>>>>>>> rootfs.cpio.xz.
> >>>>>>>>>> I assume we can somehow reserve a portion of the DRAM to store
> >>>>> those
> >>>>>>>>> binaries and let barebox boot this Linux.
> >>>>>>>>>
> >>>>>>>>> You can make this work, but this is not how your actual system will
> >>>>>>>>> look like and trying to make this work is harder than it needs to be.
> >>>>>>>>>
> >>>>>>>>> Just add a cfi-flash that corresponds to the Linux/rootfs flash in
> >>>>>>>>> your actual system, then boot with bootm (type help bootm for
> info
> >>>>>>>>> on how to use it). You don't need to hardcode the load addresses,
> >>>>>>>>> barebox will determine them automatically.
> >>>>>>>>>
> >>>>>>>>>> Can you please advise how to make it work?
> >>>>>>>>>
> >>>>>>>>> For completion's sake, if you have 64M of RAM that's preloaded
> with
> >>>>>>>>> boot images:
> >>>>>>>>>
> >>>>>>>>> - Remove the 64M from the barebox /memory node. You can use
> a
> >>>>>>> different
> >>>>>>>>> DT for kernel, but if you have memory that barebox shouldn't
> >>>> override,
> >>>>>>>>> you need to tell it that.
> >>>>>>>>>
> >>>>>>>>> - Add a mtd-rom node that describes these 64M that you have.
> You
> >>>> can
> >>>>>>>>> add partitions for the region used for kernel and oftree
> >>>>>>>>>
> >>>>>>>>> - boot with bootm -o /dev/mtdrom0.oftree -r
> /dev/mtdrom0.initrd
> >> \
> >>>>>>>>> /dev/mtdrom0.kernel
> >>>>>>>>>
> >>>>>>>>> That's admittedly cumbersome, but necessary, so barebox knows
> >> what
> >>>>>>>>> memory
> >>>>>>>>> it may use for itself and what memory may be used for boot.
> >>>>>>>>>
> >>>>>>>>> Correct solution is to use cfi-flash or similar.
> >>>>>>>>>
> >>>>>>>>> Cheers,
> >>>>>>>>> Ahmad
> >>>>>>>>> --
> >>>>>>>>> Pengutronix e.K. | |
> >>>>>>>>> Steuerwalder Str. 21 | http://www.pengutronix.de/ |
> >>>>>>>>> 31137 Hildesheim, Germany | Phone: +49-5121-206917-
> 0
> >> |
> >>>>>>>>> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-
> >>>> 5555
> >>>>> |
> >>>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> Pengutronix e.K. | |
> >>>>>>> Steuerwalder Str. 21 | http://www.pengutronix.de/ |
> >>>>>>> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0
> |
> >>>>>>> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-
> >> 5555
> >>>> |
> >>>>>>
> >>>>>
> >>>>> --
> >>>>> Pengutronix e.K. | |
> >>>>> Steuerwalder Str. 21 | http://www.pengutronix.de/ |
> >>>>> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
> >>>>> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-
> 5555 |
> >>>
> >>
> >> --
> >> Pengutronix e.K. | |
> >> Steuerwalder Str. 21 | http://www.pengutronix.de/ |
> >> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
> >> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
> >
>
> --
> Pengutronix e.K. | |
> Steuerwalder Str. 21 | http://www.pengutronix.de/ |
> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [PATCH v2] Porting barebox to a new SoC
2023-06-25 20:33 ` Lior Weintraub
@ 2023-06-30 5:52 ` Ahmad Fatoum
2023-08-03 11:17 ` Lior Weintraub
0 siblings, 1 reply; 40+ messages in thread
From: Ahmad Fatoum @ 2023-06-30 5:52 UTC (permalink / raw)
To: Lior Weintraub, Ahmad Fatoum, barebox
Hi Lior,
On 25.06.23 22:33, Lior Weintraub wrote:
> Hello Ahmad,
[Sorry for the delay, we're at EOSS 2023 currently]
> I failed to reproduce this issue on virt because the addresses and peripherals on virt machine are different and it is difficult to change our code to match that.
> If you think this is critical I will make extra effort to make it work.
> AFAIU, this suggestion was made to debug the "conflict" issue.
It's not critical, but I'd have liked to understand this, so I can check
if it's perhaps a barebox bug.
> Currently the workaround I am using is just to set the size of the kernel partition to match the exact size of the "Image" file.
>
> The other issue I am facing is that Kernel seems stuck on cpu_do_idle and there is no login prompt from the kernel.
Does it call into PSCI during idle?
> As you recall, I am running on a custom QEMU that tries to emulate our platform.
> I suspect that I did something wrong with the GICv3 and Timers connectivity.
> The code I used was based on examples I saw on sbsa-ref.c and virt.c.
> In addition, I declared the GICv3 and timers on our device tree.
>
> I running QEMU with "-d int" so I am also getting trace of exceptions and interrupts.
Nice. Didn't know about this option.
[snip]
> Exception return from AArch64 EL3 to AArch64 EL1 PC 0xffffffc00802112c
> Taking exception 13 [Secure Monitor Call] on CPU 0
> ...from EL1 to EL3
> ...with ESR 0x17/0x5e000000
> ...with ELR 0xffffffc008021640
> ...to EL3 PC 0x10005400 PSTATE 0x3cd
> Exception return from AArch64 EL3 to AArch64 EL1 PC 0xffffffc008021640
Looks fine so far? Doesn't look like it's hanging in EL1.
[snip]
> Segment Routing with IPv6
> In-situ OAM (IOAM) with IPv6
> sit: IPv6, IPv4 and MPLS over IPv4 tunneling driver
> NET: Registered PF_PACKET protocol family
> NET: Registered PF_KEY protocol family
> NET: Registered PF_VSOCK protocol family
> registered taskstats version 1
> clk: Disabling unused clocks
> Freeing unused kernel memory: 1664K
Not sure. Normally, I'd try again with pd_ignore_unused clk_ignore_unused in the
kernel arguments, but I think you define no clocks or power domains yet in the DT?
You can try again with kernel command line option initcall_debug and see what the
initcall is that is getting stuck. If nothing helps, maybe attach a hardware debugger?
Cheers,
Ahmad
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply [flat|nested] 40+ messages in thread
* RE: [PATCH v2] Porting barebox to a new SoC
2023-06-30 5:52 ` Ahmad Fatoum
@ 2023-08-03 11:17 ` Lior Weintraub
2023-08-22 8:00 ` Ahmad Fatoum
0 siblings, 1 reply; 40+ messages in thread
From: Lior Weintraub @ 2023-08-03 11:17 UTC (permalink / raw)
To: Ahmad Fatoum; +Cc: Ahmad Fatoum, barebox
Hi Ahmad,
Hope you had a great time on EOSS 2023 :-)
Quick recap and additional info on the current issue:
1.
The spider-soc QEMU with the additional GICv3 and Timers was tested with a bare-metal code and proved to be OK.
This bare-metal code sets the A53 timers and GICv3 to handle interrupts on various execution levels as well as various security levels:
EL1_NS_PHYSICAL_TIMER set as GROUP1_NON_SECURE
EL1_SCR_PHYSICAL_TIMER set as GROUP1_SECURE
EL2_PHYSICAL_TIMER set as GROUP1_SECURE
VIRTUAL_TIMER set as GROUP1_NON_SECURE
2.
The kernel we build with Buildroot runs OK on virt QEMU but gets stuck in the middle when we use our spider-soc QEMU.
There are few differences between those runs:
a.
The virt QEMU is executed with -kernel switch and hence the QEMU itself implements the "bootloader" and prepares the DT given to the Kernel.
When the Kernel starts on this platforms it starts at EL1.
b.
The spider-soc QEMU is executed with -device loader,file=spider-soc-bl1.elf
Just for easy execution and testing, this executable includes all the needed binaries (as const data blobs) and it copies the binaries into correct locations before jumping to Barebox execution.
The list of binaries includes the barebox, kernel, dt, and rootfs.
As you recall, BL31 is compiled via Trusted-Firmware-A and has all it's functions as empty stubs because we currently don't care about CPU power states.
The prove that BL31 is executed correctly is that Barebox now runs at EL2.
At that point the Linux kernel is starting and as I mentioned gets stuck in the middle (cpu_do_idle function. more details to follow).
Debugging the kernel with GDB revealed few differences:
1. When running with Barebox, the kernel starts at EL2 and at some point moves to EL1.
Not sure if that has some impact on the following issue but thought it is worth mentioning.
(We get a "CPU: All CPU(s) started at EL2" trace)
Another difference that might be related to this execution level is that timers setting shows that it uses the physical timer (as oppose to virt QEMU run that uses the virtual timer):
The spider-soc QEMU Timers dump:
CNTFRQ_EL0 = 0x3b9aca0
CNTP_CTL_EL0 = 0x5
CNTV_CTL_EL0 = 0x0
CNTP_TVAL_EL0 = 0xff1f2ad5
CNTP_CVAL_EL0 = 0xac5c3240
CNTV_TVAL_EL0 = 0x52c2d916
CNTV_CVAL_EL0 = 0x0
The virt QEMU Timers dump:
CNTFRQ_EL0 = 0x3b9aca0
CNTP_CTL_EL0 = 0x0
CNTV_CTL_EL0 = 0x5
CNTP_TVAL_EL0 = 0xb8394fbc
CNTP_CVAL_EL0 = 0x0
CNTV_TVAL_EL0 = 0xffd18e39
CNTV_CVAL_EL0 = 0x479858aa
2. When running with Barebox, the kernel fails to correctly set the GICv3 registers.
So in other words, there are no timer events and hence the scheduler is not running.
The code get stuck on cpu_do_idle but we also found that the RCU cb_list is not empty (probably explains why scheduler haven't started (just a guess)).
We placed a breakpoint just before calling wait_for_completion (from function rcu_barrier on kernel/rcu/tree.c) and found:
bt
#0 rcu_barrier () at kernel/rcu/tree.c:4064
#1 0xffffffc08059e1b4 in mark_readonly () at init/main.c:1789
#2 kernel_init (unused=<optimized out>) at init/main.c:1838
#3 0xffffffc080015e48 in ret_from_fork () at arch/arm64/kernel/entry.S:853
At that point rcu_state.barrier_cpu_count.counter is 1 (as oppose to virt QEMU where it is 0 at that point)
If we place the breakpoint a bit earlier in this rcu_barrier function (just before the for_each_possible_cpu loop) and run few more steps (to get the rdp) we see that rdp->cblist.len is 0x268 (616):
p/x rdp->cblist
$1 = {head = 0xffffffc0808f06d0, tails = {0xffffff802fe55a78, 0xffffff802fe55a78, 0xffffff802fe55a78, 0xffffff80001c22c8}, gp_seq = {0x0, 0x0, 0x0, 0x0}, len = 0x268, seglen = {0x0, 0x0, 0x0, 0x268}, flags = 0x1}
When we compare that with virt QEMU we see that the rdp->cblist.len is 0 there.
IMHO, this all is a result of the GICv3 settings that were not applied properly.
As a result there are no timer interrupts.
Further debugging on the GICv3 settings showed that the code (function gic_cpu_init on drivers/irqchip/irq-gic-v3.c) tries to write 0xffffffff to GICR_IGROUPR0 (Configure SGIs/PPIs as non-secure Group-1) but when we try to read it back we get all zeros.
Dumping GICv3 settings after the call to init_IRQ:
Showing only the differences:
Spider-SoC QEMU virt QEMU
GICD_CTLR = 0x00000012 0x00000053
GICD_TYPER = 0x037a0402 0x037a0007
GICR0_IGROUPR0 = 0x00000000 0xffffffff
GICR0_ISENABLER0 = 0x00000000 0x0000007f
GICR0_ICENABLER0 = 0x00000000 0x0000007f
GICR0_ICFGR0 = 0x00000000 0xaaaaaaaa
Any thoughts?
As always, your support is much appreciated!
Cheers,
Lior.
> -----Original Message-----
> From: Ahmad Fatoum <a.fatoum@pengutronix.de>
> Sent: Friday, June 30, 2023 8:53 AM
> To: Lior Weintraub <liorw@pliops.com>; Ahmad Fatoum <ahmad@a3f.at>;
> barebox@lists.infradead.org
> Subject: Re: [PATCH v2] Porting barebox to a new SoC
>
> CAUTION: External Sender
>
> Hi Lior,
>
> On 25.06.23 22:33, Lior Weintraub wrote:
> > Hello Ahmad,
>
> [Sorry for the delay, we're at EOSS 2023 currently]
>
> > I failed to reproduce this issue on virt because the addresses and peripherals
> on virt machine are different and it is difficult to change our code to match
> that.
> > If you think this is critical I will make extra effort to make it work.
> > AFAIU, this suggestion was made to debug the "conflict" issue.
>
> It's not critical, but I'd have liked to understand this, so I can check
> if it's perhaps a barebox bug.
>
> > Currently the workaround I am using is just to set the size of the kernel
> partition to match the exact size of the "Image" file.
> >
> > The other issue I am facing is that Kernel seems stuck on cpu_do_idle and
> there is no login prompt from the kernel.
>
> Does it call into PSCI during idle?
>
> > As you recall, I am running on a custom QEMU that tries to emulate our
> platform.
> > I suspect that I did something wrong with the GICv3 and Timers connectivity.
> > The code I used was based on examples I saw on sbsa-ref.c and virt.c.
> > In addition, I declared the GICv3 and timers on our device tree.
> >
> > I running QEMU with "-d int" so I am also getting trace of exceptions and
> interrupts.
>
> Nice. Didn't know about this option.
>
> [snip]
>
> > Exception return from AArch64 EL3 to AArch64 EL1 PC 0xffffffc00802112c
> > Taking exception 13 [Secure Monitor Call] on CPU 0
> > ...from EL1 to EL3
> > ...with ESR 0x17/0x5e000000
> > ...with ELR 0xffffffc008021640
> > ...to EL3 PC 0x10005400 PSTATE 0x3cd
> > Exception return from AArch64 EL3 to AArch64 EL1 PC 0xffffffc008021640
>
> Looks fine so far? Doesn't look like it's hanging in EL1.
>
> [snip]
>
> > Segment Routing with IPv6
> > In-situ OAM (IOAM) with IPv6
> > sit: IPv6, IPv4 and MPLS over IPv4 tunneling driver
> > NET: Registered PF_PACKET protocol family
> > NET: Registered PF_KEY protocol family
> > NET: Registered PF_VSOCK protocol family
> > registered taskstats version 1
> > clk: Disabling unused clocks
> > Freeing unused kernel memory: 1664K
>
> Not sure. Normally, I'd try again with pd_ignore_unused clk_ignore_unused in
> the
> kernel arguments, but I think you define no clocks or power domains yet in
> the DT?
>
> You can try again with kernel command line option initcall_debug and see
> what the
> initcall is that is getting stuck. If nothing helps, maybe attach a hardware
> debugger?
>
> Cheers,
> Ahmad
>
> --
> Pengutronix e.K. | |
> Steuerwalder Str. 21 | http://www.pengutronix.de/ |
> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [PATCH v2] Porting barebox to a new SoC
2023-08-03 11:17 ` Lior Weintraub
@ 2023-08-22 8:00 ` Ahmad Fatoum
2023-08-22 8:48 ` Lior Weintraub
0 siblings, 1 reply; 40+ messages in thread
From: Ahmad Fatoum @ 2023-08-22 8:00 UTC (permalink / raw)
To: Lior Weintraub; +Cc: Ahmad Fatoum, barebox
Hello Lior,
On 03.08.23 13:17, Lior Weintraub wrote:
> Hi Ahmad,
>
> Hope you had a great time on EOSS 2023 :-)
Thanks and sorry for the late answer.
> Quick recap and additional info on the current issue:
>
> 1.
> The spider-soc QEMU with the additional GICv3 and Timers was tested with a bare-metal code and proved to be OK.
> This bare-metal code sets the A53 timers and GICv3 to handle interrupts on various execution levels as well as various security levels:
> EL1_NS_PHYSICAL_TIMER set as GROUP1_NON_SECURE
> EL1_SCR_PHYSICAL_TIMER set as GROUP1_SECURE
> EL2_PHYSICAL_TIMER set as GROUP1_SECURE
> VIRTUAL_TIMER set as GROUP1_NON_SECURE
ok.
> 2.
> The kernel we build with Buildroot runs OK on virt QEMU but gets stuck in the middle when we use our spider-soc QEMU.
> There are few differences between those runs:
> a.
> The virt QEMU is executed with -kernel switch and hence the QEMU itself implements the "bootloader" and prepares the DT given to the Kernel.
> When the Kernel starts on this platforms it starts at EL1.
This can be influenced e.g. on Virt with -M virt,virtualization=on, I think.
> b.
> The spider-soc QEMU is executed with -device loader,file=spider-soc-bl1.elf
> Just for easy execution and testing, this executable includes all the needed binaries (as const data blobs) and it copies the binaries into correct locations before jumping to Barebox execution.
> The list of binaries includes the barebox, kernel, dt, and rootfs.
> As you recall, BL31 is compiled via Trusted-Firmware-A and has all it's functions as empty stubs because we currently don't care about CPU power states.
> The prove that BL31 is executed correctly is that Barebox now runs at EL2.
Good.
> At that point the Linux kernel is starting and as I mentioned gets stuck in the middle (cpu_do_idle function. more details to follow).
>
> Debugging the kernel with GDB revealed few differences:
> 1. When running with Barebox, the kernel starts at EL2 and at some point moves to EL1.
> Not sure if that has some impact on the following issue but thought it is worth mentioning.
> (We get a "CPU: All CPU(s) started at EL2" trace)
I get the same on an i.MX8M as well (multi-core Cortex-A53 SoC).
> Another difference that might be related to this execution level is that timers setting shows that it uses the physical timer (as oppose to virt QEMU run that uses the virtual timer):
> The spider-soc QEMU Timers dump:
> CNTFRQ_EL0 = 0x3b9aca0
> CNTP_CTL_EL0 = 0x5
> CNTV_CTL_EL0 = 0x0
> CNTP_TVAL_EL0 = 0xff1f2ad5
> CNTP_CVAL_EL0 = 0xac5c3240
> CNTV_TVAL_EL0 = 0x52c2d916
> CNTV_CVAL_EL0 = 0x0
>
> The virt QEMU Timers dump:
> CNTFRQ_EL0 = 0x3b9aca0
> CNTP_CTL_EL0 = 0x0
> CNTV_CTL_EL0 = 0x5
> CNTP_TVAL_EL0 = 0xb8394fbc
> CNTP_CVAL_EL0 = 0x0
> CNTV_TVAL_EL0 = 0xffd18e39
> CNTV_CVAL_EL0 = 0x479858aa
>
> 2. When running with Barebox, the kernel fails to correctly set the GICv3 registers.
> So in other words, there are no timer events and hence the scheduler is not running.
> The code get stuck on cpu_do_idle but we also found that the RCU cb_list is not empty (probably explains why scheduler haven't started (just a guess)).
> We placed a breakpoint just before calling wait_for_completion (from function rcu_barrier on kernel/rcu/tree.c) and found:
> bt
> #0 rcu_barrier () at kernel/rcu/tree.c:4064
> #1 0xffffffc08059e1b4 in mark_readonly () at init/main.c:1789
> #2 kernel_init (unused=<optimized out>) at init/main.c:1838
> #3 0xffffffc080015e48 in ret_from_fork () at arch/arm64/kernel/entry.S:853
>
> At that point rcu_state.barrier_cpu_count.counter is 1 (as oppose to virt QEMU where it is 0 at that point)
> If we place the breakpoint a bit earlier in this rcu_barrier function (just before the for_each_possible_cpu loop) and run few more steps (to get the rdp) we see that rdp->cblist.len is 0x268 (616):
> p/x rdp->cblist
> $1 = {head = 0xffffffc0808f06d0, tails = {0xffffff802fe55a78, 0xffffff802fe55a78, 0xffffff802fe55a78, 0xffffff80001c22c8}, gp_seq = {0x0, 0x0, 0x0, 0x0}, len = 0x268, seglen = {0x0, 0x0, 0x0, 0x268}, flags = 0x1}
>
> When we compare that with virt QEMU we see that the rdp->cblist.len is 0 there.
>
> IMHO, this all is a result of the GICv3 settings that were not applied properly.
> As a result there are no timer interrupts.
>
> Further debugging on the GICv3 settings showed that the code (function gic_cpu_init on drivers/irqchip/irq-gic-v3.c) tries to write 0xffffffff to GICR_IGROUPR0 (Configure SGIs/PPIs as non-secure Group-1) but when we try to read it back we get all zeros.
> Dumping GICv3 settings after the call to init_IRQ:
> Showing only the differences:
> Spider-SoC QEMU virt QEMU
> GICD_CTLR = 0x00000012 0x00000053
> GICD_TYPER = 0x037a0402 0x037a0007
> GICR0_IGROUPR0 = 0x00000000 0xffffffff
> GICR0_ISENABLER0 = 0x00000000 0x0000007f
> GICR0_ICENABLER0 = 0x00000000 0x0000007f
> GICR0_ICFGR0 = 0x00000000 0xaaaaaaaa
>
> Any thoughts?
> As always, your support is much appreciated!
Sorry to disappoint, but I have no hands-on experience with the GIC.
My guess would be that you are missing initialization in the TF-A...
Cheers,
Ahmad
>
> Cheers,
> Lior.
>
>
>> -----Original Message-----
>> From: Ahmad Fatoum <a.fatoum@pengutronix.de>
>> Sent: Friday, June 30, 2023 8:53 AM
>> To: Lior Weintraub <liorw@pliops.com>; Ahmad Fatoum <ahmad@a3f.at>;
>> barebox@lists.infradead.org
>> Subject: Re: [PATCH v2] Porting barebox to a new SoC
>>
>> CAUTION: External Sender
>>
>> Hi Lior,
>>
>> On 25.06.23 22:33, Lior Weintraub wrote:
>>> Hello Ahmad,
>>
>> [Sorry for the delay, we're at EOSS 2023 currently]
>>
>>> I failed to reproduce this issue on virt because the addresses and peripherals
>> on virt machine are different and it is difficult to change our code to match
>> that.
>>> If you think this is critical I will make extra effort to make it work.
>>> AFAIU, this suggestion was made to debug the "conflict" issue.
>>
>> It's not critical, but I'd have liked to understand this, so I can check
>> if it's perhaps a barebox bug.
>>
>>> Currently the workaround I am using is just to set the size of the kernel
>> partition to match the exact size of the "Image" file.
>>>
>>> The other issue I am facing is that Kernel seems stuck on cpu_do_idle and
>> there is no login prompt from the kernel.
>>
>> Does it call into PSCI during idle?
>>
>>> As you recall, I am running on a custom QEMU that tries to emulate our
>> platform.
>>> I suspect that I did something wrong with the GICv3 and Timers connectivity.
>>> The code I used was based on examples I saw on sbsa-ref.c and virt.c.
>>> In addition, I declared the GICv3 and timers on our device tree.
>>>
>>> I running QEMU with "-d int" so I am also getting trace of exceptions and
>> interrupts.
>>
>> Nice. Didn't know about this option.
>>
>> [snip]
>>
>>> Exception return from AArch64 EL3 to AArch64 EL1 PC 0xffffffc00802112c
>>> Taking exception 13 [Secure Monitor Call] on CPU 0
>>> ...from EL1 to EL3
>>> ...with ESR 0x17/0x5e000000
>>> ...with ELR 0xffffffc008021640
>>> ...to EL3 PC 0x10005400 PSTATE 0x3cd
>>> Exception return from AArch64 EL3 to AArch64 EL1 PC 0xffffffc008021640
>>
>> Looks fine so far? Doesn't look like it's hanging in EL1.
>>
>> [snip]
>>
>>> Segment Routing with IPv6
>>> In-situ OAM (IOAM) with IPv6
>>> sit: IPv6, IPv4 and MPLS over IPv4 tunneling driver
>>> NET: Registered PF_PACKET protocol family
>>> NET: Registered PF_KEY protocol family
>>> NET: Registered PF_VSOCK protocol family
>>> registered taskstats version 1
>>> clk: Disabling unused clocks
>>> Freeing unused kernel memory: 1664K
>>
>> Not sure. Normally, I'd try again with pd_ignore_unused clk_ignore_unused in
>> the
>> kernel arguments, but I think you define no clocks or power domains yet in
>> the DT?
>>
>> You can try again with kernel command line option initcall_debug and see
>> what the
>> initcall is that is getting stuck. If nothing helps, maybe attach a hardware
>> debugger?
>>
>> Cheers,
>> Ahmad
>>
>> --
>> Pengutronix e.K. | |
>> Steuerwalder Str. 21 | http://www.pengutronix.de/ |
>> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
>> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
>
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply [flat|nested] 40+ messages in thread
* RE: [PATCH v2] Porting barebox to a new SoC
2023-08-22 8:00 ` Ahmad Fatoum
@ 2023-08-22 8:48 ` Lior Weintraub
2023-09-07 8:32 ` Ahmad Fatoum
0 siblings, 1 reply; 40+ messages in thread
From: Lior Weintraub @ 2023-08-22 8:48 UTC (permalink / raw)
To: Ahmad Fatoum; +Cc: Ahmad Fatoum, barebox
Thanks Ahmad, I Will try to post same question on Linux mailing list.
> -----Original Message-----
> From: Ahmad Fatoum <a.fatoum@pengutronix.de>
> Sent: Tuesday, August 22, 2023 11:01 AM
> To: Lior Weintraub <liorw@pliops.com>
> Cc: Ahmad Fatoum <ahmad@a3f.at>; barebox@lists.infradead.org
> Subject: Re: [PATCH v2] Porting barebox to a new SoC
>
> CAUTION: External Sender
>
> Hello Lior,
>
> On 03.08.23 13:17, Lior Weintraub wrote:
> > Hi Ahmad,
> >
> > Hope you had a great time on EOSS 2023 :-)
>
> Thanks and sorry for the late answer.
>
> > Quick recap and additional info on the current issue:
> >
> > 1.
> > The spider-soc QEMU with the additional GICv3 and Timers was tested with
> a bare-metal code and proved to be OK.
> > This bare-metal code sets the A53 timers and GICv3 to handle interrupts on
> various execution levels as well as various security levels:
> > EL1_NS_PHYSICAL_TIMER set as GROUP1_NON_SECURE
> > EL1_SCR_PHYSICAL_TIMER set as GROUP1_SECURE
> > EL2_PHYSICAL_TIMER set as GROUP1_SECURE
> > VIRTUAL_TIMER set as GROUP1_NON_SECURE
>
> ok.
>
> > 2.
> > The kernel we build with Buildroot runs OK on virt QEMU but gets stuck in
> the middle when we use our spider-soc QEMU.
> > There are few differences between those runs:
> > a.
> > The virt QEMU is executed with -kernel switch and hence the QEMU itself
> implements the "bootloader" and prepares the DT given to the Kernel.
> > When the Kernel starts on this platforms it starts at EL1.
>
> This can be influenced e.g. on Virt with -M virt,virtualization=on, I think.
>
> > b.
> > The spider-soc QEMU is executed with -device loader,file=spider-soc-bl1.elf
> > Just for easy execution and testing, this executable includes all the needed
> binaries (as const data blobs) and it copies the binaries into correct locations
> before jumping to Barebox execution.
> > The list of binaries includes the barebox, kernel, dt, and rootfs.
> > As you recall, BL31 is compiled via Trusted-Firmware-A and has all it's
> functions as empty stubs because we currently don't care about CPU power
> states.
> > The prove that BL31 is executed correctly is that Barebox now runs at EL2.
>
> Good.
>
> > At that point the Linux kernel is starting and as I mentioned gets stuck in the
> middle (cpu_do_idle function. more details to follow).
> >
> > Debugging the kernel with GDB revealed few differences:
> > 1. When running with Barebox, the kernel starts at EL2 and at some point
> moves to EL1.
> > Not sure if that has some impact on the following issue but thought it is
> worth mentioning.
> > (We get a "CPU: All CPU(s) started at EL2" trace)
>
> I get the same on an i.MX8M as well (multi-core Cortex-A53 SoC).
>
> > Another difference that might be related to this execution level is that timers
> setting shows that it uses the physical timer (as oppose to virt QEMU run that
> uses the virtual timer):
> > The spider-soc QEMU Timers dump:
> > CNTFRQ_EL0 = 0x3b9aca0
> > CNTP_CTL_EL0 = 0x5
> > CNTV_CTL_EL0 = 0x0
> > CNTP_TVAL_EL0 = 0xff1f2ad5
> > CNTP_CVAL_EL0 = 0xac5c3240
> > CNTV_TVAL_EL0 = 0x52c2d916
> > CNTV_CVAL_EL0 = 0x0
> >
> > The virt QEMU Timers dump:
> > CNTFRQ_EL0 = 0x3b9aca0
> > CNTP_CTL_EL0 = 0x0
> > CNTV_CTL_EL0 = 0x5
> > CNTP_TVAL_EL0 = 0xb8394fbc
> > CNTP_CVAL_EL0 = 0x0
> > CNTV_TVAL_EL0 = 0xffd18e39
> > CNTV_CVAL_EL0 = 0x479858aa
> >
> > 2. When running with Barebox, the kernel fails to correctly set the GICv3
> registers.
> > So in other words, there are no timer events and hence the scheduler is not
> running.
> > The code get stuck on cpu_do_idle but we also found that the RCU cb_list is
> not empty (probably explains why scheduler haven't started (just a guess)).
> > We placed a breakpoint just before calling wait_for_completion (from
> function rcu_barrier on kernel/rcu/tree.c) and found:
> > bt
> > #0 rcu_barrier () at kernel/rcu/tree.c:4064
> > #1 0xffffffc08059e1b4 in mark_readonly () at init/main.c:1789
> > #2 kernel_init (unused=<optimized out>) at init/main.c:1838
> > #3 0xffffffc080015e48 in ret_from_fork () at
> arch/arm64/kernel/entry.S:853
> >
> > At that point rcu_state.barrier_cpu_count.counter is 1 (as oppose to virt
> QEMU where it is 0 at that point)
> > If we place the breakpoint a bit earlier in this rcu_barrier function (just
> before the for_each_possible_cpu loop) and run few more steps (to get the
> rdp) we see that rdp->cblist.len is 0x268 (616):
> > p/x rdp->cblist
> > $1 = {head = 0xffffffc0808f06d0, tails = {0xffffff802fe55a78,
> 0xffffff802fe55a78, 0xffffff802fe55a78, 0xffffff80001c22c8}, gp_seq = {0x0,
> 0x0, 0x0, 0x0}, len = 0x268, seglen = {0x0, 0x0, 0x0, 0x268}, flags = 0x1}
> >
> > When we compare that with virt QEMU we see that the rdp->cblist.len is 0
> there.
> >
> > IMHO, this all is a result of the GICv3 settings that were not applied properly.
> > As a result there are no timer interrupts.
> >
> > Further debugging on the GICv3 settings showed that the code (function
> gic_cpu_init on drivers/irqchip/irq-gic-v3.c) tries to write 0xffffffff to
> GICR_IGROUPR0 (Configure SGIs/PPIs as non-secure Group-1) but when we
> try to read it back we get all zeros.
> > Dumping GICv3 settings after the call to init_IRQ:
> > Showing only the differences:
> > Spider-SoC QEMU virt QEMU
> > GICD_CTLR = 0x00000012 0x00000053
> > GICD_TYPER = 0x037a0402 0x037a0007
> > GICR0_IGROUPR0 = 0x00000000 0xffffffff
> > GICR0_ISENABLER0 = 0x00000000 0x0000007f
> > GICR0_ICENABLER0 = 0x00000000 0x0000007f
> > GICR0_ICFGR0 = 0x00000000 0xaaaaaaaa
> >
> > Any thoughts?
> > As always, your support is much appreciated!
>
> Sorry to disappoint, but I have no hands-on experience with the GIC.
> My guess would be that you are missing initialization in the TF-A...
>
> Cheers,
> Ahmad
>
> >
> > Cheers,
> > Lior.
> >
> >
> >> -----Original Message-----
> >> From: Ahmad Fatoum <a.fatoum@pengutronix.de>
> >> Sent: Friday, June 30, 2023 8:53 AM
> >> To: Lior Weintraub <liorw@pliops.com>; Ahmad Fatoum <ahmad@a3f.at>;
> >> barebox@lists.infradead.org
> >> Subject: Re: [PATCH v2] Porting barebox to a new SoC
> >>
> >> CAUTION: External Sender
> >>
> >> Hi Lior,
> >>
> >> On 25.06.23 22:33, Lior Weintraub wrote:
> >>> Hello Ahmad,
> >>
> >> [Sorry for the delay, we're at EOSS 2023 currently]
> >>
> >>> I failed to reproduce this issue on virt because the addresses and
> peripherals
> >> on virt machine are different and it is difficult to change our code to match
> >> that.
> >>> If you think this is critical I will make extra effort to make it work.
> >>> AFAIU, this suggestion was made to debug the "conflict" issue.
> >>
> >> It's not critical, but I'd have liked to understand this, so I can check
> >> if it's perhaps a barebox bug.
> >>
> >>> Currently the workaround I am using is just to set the size of the kernel
> >> partition to match the exact size of the "Image" file.
> >>>
> >>> The other issue I am facing is that Kernel seems stuck on cpu_do_idle and
> >> there is no login prompt from the kernel.
> >>
> >> Does it call into PSCI during idle?
> >>
> >>> As you recall, I am running on a custom QEMU that tries to emulate our
> >> platform.
> >>> I suspect that I did something wrong with the GICv3 and Timers
> connectivity.
> >>> The code I used was based on examples I saw on sbsa-ref.c and virt.c.
> >>> In addition, I declared the GICv3 and timers on our device tree.
> >>>
> >>> I running QEMU with "-d int" so I am also getting trace of exceptions and
> >> interrupts.
> >>
> >> Nice. Didn't know about this option.
> >>
> >> [snip]
> >>
> >>> Exception return from AArch64 EL3 to AArch64 EL1 PC
> 0xffffffc00802112c
> >>> Taking exception 13 [Secure Monitor Call] on CPU 0
> >>> ...from EL1 to EL3
> >>> ...with ESR 0x17/0x5e000000
> >>> ...with ELR 0xffffffc008021640
> >>> ...to EL3 PC 0x10005400 PSTATE 0x3cd
> >>> Exception return from AArch64 EL3 to AArch64 EL1 PC
> 0xffffffc008021640
> >>
> >> Looks fine so far? Doesn't look like it's hanging in EL1.
> >>
> >> [snip]
> >>
> >>> Segment Routing with IPv6
> >>> In-situ OAM (IOAM) with IPv6
> >>> sit: IPv6, IPv4 and MPLS over IPv4 tunneling driver
> >>> NET: Registered PF_PACKET protocol family
> >>> NET: Registered PF_KEY protocol family
> >>> NET: Registered PF_VSOCK protocol family
> >>> registered taskstats version 1
> >>> clk: Disabling unused clocks
> >>> Freeing unused kernel memory: 1664K
> >>
> >> Not sure. Normally, I'd try again with pd_ignore_unused clk_ignore_unused
> in
> >> the
> >> kernel arguments, but I think you define no clocks or power domains yet in
> >> the DT?
> >>
> >> You can try again with kernel command line option initcall_debug and see
> >> what the
> >> initcall is that is getting stuck. If nothing helps, maybe attach a hardware
> >> debugger?
> >>
> >> Cheers,
> >> Ahmad
> >>
> >> --
> >> Pengutronix e.K. | |
> >> Steuerwalder Str. 21 | http://secure-
> web.cisco.com/1RKlXzLFuAdOeswlWvHRCbVHHvoQssFo7iVFqyvv8Yn0sP-
> MsWtfVRf2HW_4AXhQNuR5kNBuKLHNWkQfzg5qQhZ2AYhdNYqrfmNM7Isb
> bDhybYe7C21TIR6Du5pxC7TSTbhhg4oBK3J9y2XyMtJNhBKeliNv2I5G4mlnB_
> 57ph9x9tlPHstmZ8SL22VzM9RxLoj-5LddbVSsB69VGG-
> O3Hw57EyoSFWKWmjNjOHDmuU1R3SwOX2tkDMmiLPauqbBc-
> FP9cAFpclCgrOIJu2Jfef0-
> sVV346BmbxC1SOFAKCI/http%3A%2F%2Fwww.pengutronix.de%2F |
> >> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
> >> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
> >
>
> --
> Pengutronix e.K. | |
> Steuerwalder Str. 21 | http://secure-
> web.cisco.com/1RKlXzLFuAdOeswlWvHRCbVHHvoQssFo7iVFqyvv8Yn0sP-
> MsWtfVRf2HW_4AXhQNuR5kNBuKLHNWkQfzg5qQhZ2AYhdNYqrfmNM7Isb
> bDhybYe7C21TIR6Du5pxC7TSTbhhg4oBK3J9y2XyMtJNhBKeliNv2I5G4mlnB_
> 57ph9x9tlPHstmZ8SL22VzM9RxLoj-5LddbVSsB69VGG-
> O3Hw57EyoSFWKWmjNjOHDmuU1R3SwOX2tkDMmiLPauqbBc-
> FP9cAFpclCgrOIJu2Jfef0-
> sVV346BmbxC1SOFAKCI/http%3A%2F%2Fwww.pengutronix.de%2F |
> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
>
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [PATCH v2] Porting barebox to a new SoC
2023-08-22 8:48 ` Lior Weintraub
@ 2023-09-07 8:32 ` Ahmad Fatoum
2023-09-07 9:07 ` Lior Weintraub
0 siblings, 1 reply; 40+ messages in thread
From: Ahmad Fatoum @ 2023-09-07 8:32 UTC (permalink / raw)
To: Lior Weintraub; +Cc: Ahmad Fatoum, barebox
Hello Lior,
On 22.08.23 10:48, Lior Weintraub wrote:
> Thanks Ahmad, I Will try to post same question on Linux mailing list.
I am curious to follow the discussion. Did you already post somewhere?
I can't find a recent mail on lore.kernel.org.
Feel free to Cc me when you post.
Cheers,
Ahmad
>
>> -----Original Message-----
>> From: Ahmad Fatoum <a.fatoum@pengutronix.de>
>> Sent: Tuesday, August 22, 2023 11:01 AM
>> To: Lior Weintraub <liorw@pliops.com>
>> Cc: Ahmad Fatoum <ahmad@a3f.at>; barebox@lists.infradead.org
>> Subject: Re: [PATCH v2] Porting barebox to a new SoC
>>
>> CAUTION: External Sender
>>
>> Hello Lior,
>>
>> On 03.08.23 13:17, Lior Weintraub wrote:
>>> Hi Ahmad,
>>>
>>> Hope you had a great time on EOSS 2023 :-)
>>
>> Thanks and sorry for the late answer.
>>
>>> Quick recap and additional info on the current issue:
>>>
>>> 1.
>>> The spider-soc QEMU with the additional GICv3 and Timers was tested with
>> a bare-metal code and proved to be OK.
>>> This bare-metal code sets the A53 timers and GICv3 to handle interrupts on
>> various execution levels as well as various security levels:
>>> EL1_NS_PHYSICAL_TIMER set as GROUP1_NON_SECURE
>>> EL1_SCR_PHYSICAL_TIMER set as GROUP1_SECURE
>>> EL2_PHYSICAL_TIMER set as GROUP1_SECURE
>>> VIRTUAL_TIMER set as GROUP1_NON_SECURE
>>
>> ok.
>>
>>> 2.
>>> The kernel we build with Buildroot runs OK on virt QEMU but gets stuck in
>> the middle when we use our spider-soc QEMU.
>>> There are few differences between those runs:
>>> a.
>>> The virt QEMU is executed with -kernel switch and hence the QEMU itself
>> implements the "bootloader" and prepares the DT given to the Kernel.
>>> When the Kernel starts on this platforms it starts at EL1.
>>
>> This can be influenced e.g. on Virt with -M virt,virtualization=on, I think.
>>
>>> b.
>>> The spider-soc QEMU is executed with -device loader,file=spider-soc-bl1.elf
>>> Just for easy execution and testing, this executable includes all the needed
>> binaries (as const data blobs) and it copies the binaries into correct locations
>> before jumping to Barebox execution.
>>> The list of binaries includes the barebox, kernel, dt, and rootfs.
>>> As you recall, BL31 is compiled via Trusted-Firmware-A and has all it's
>> functions as empty stubs because we currently don't care about CPU power
>> states.
>>> The prove that BL31 is executed correctly is that Barebox now runs at EL2.
>>
>> Good.
>>
>>> At that point the Linux kernel is starting and as I mentioned gets stuck in the
>> middle (cpu_do_idle function. more details to follow).
>>>
>>> Debugging the kernel with GDB revealed few differences:
>>> 1. When running with Barebox, the kernel starts at EL2 and at some point
>> moves to EL1.
>>> Not sure if that has some impact on the following issue but thought it is
>> worth mentioning.
>>> (We get a "CPU: All CPU(s) started at EL2" trace)
>>
>> I get the same on an i.MX8M as well (multi-core Cortex-A53 SoC).
>>
>>> Another difference that might be related to this execution level is that timers
>> setting shows that it uses the physical timer (as oppose to virt QEMU run that
>> uses the virtual timer):
>>> The spider-soc QEMU Timers dump:
>>> CNTFRQ_EL0 = 0x3b9aca0
>>> CNTP_CTL_EL0 = 0x5
>>> CNTV_CTL_EL0 = 0x0
>>> CNTP_TVAL_EL0 = 0xff1f2ad5
>>> CNTP_CVAL_EL0 = 0xac5c3240
>>> CNTV_TVAL_EL0 = 0x52c2d916
>>> CNTV_CVAL_EL0 = 0x0
>>>
>>> The virt QEMU Timers dump:
>>> CNTFRQ_EL0 = 0x3b9aca0
>>> CNTP_CTL_EL0 = 0x0
>>> CNTV_CTL_EL0 = 0x5
>>> CNTP_TVAL_EL0 = 0xb8394fbc
>>> CNTP_CVAL_EL0 = 0x0
>>> CNTV_TVAL_EL0 = 0xffd18e39
>>> CNTV_CVAL_EL0 = 0x479858aa
>>>
>>> 2. When running with Barebox, the kernel fails to correctly set the GICv3
>> registers.
>>> So in other words, there are no timer events and hence the scheduler is not
>> running.
>>> The code get stuck on cpu_do_idle but we also found that the RCU cb_list is
>> not empty (probably explains why scheduler haven't started (just a guess)).
>>> We placed a breakpoint just before calling wait_for_completion (from
>> function rcu_barrier on kernel/rcu/tree.c) and found:
>>> bt
>>> #0 rcu_barrier () at kernel/rcu/tree.c:4064
>>> #1 0xffffffc08059e1b4 in mark_readonly () at init/main.c:1789
>>> #2 kernel_init (unused=<optimized out>) at init/main.c:1838
>>> #3 0xffffffc080015e48 in ret_from_fork () at
>> arch/arm64/kernel/entry.S:853
>>>
>>> At that point rcu_state.barrier_cpu_count.counter is 1 (as oppose to virt
>> QEMU where it is 0 at that point)
>>> If we place the breakpoint a bit earlier in this rcu_barrier function (just
>> before the for_each_possible_cpu loop) and run few more steps (to get the
>> rdp) we see that rdp->cblist.len is 0x268 (616):
>>> p/x rdp->cblist
>>> $1 = {head = 0xffffffc0808f06d0, tails = {0xffffff802fe55a78,
>> 0xffffff802fe55a78, 0xffffff802fe55a78, 0xffffff80001c22c8}, gp_seq = {0x0,
>> 0x0, 0x0, 0x0}, len = 0x268, seglen = {0x0, 0x0, 0x0, 0x268}, flags = 0x1}
>>>
>>> When we compare that with virt QEMU we see that the rdp->cblist.len is 0
>> there.
>>>
>>> IMHO, this all is a result of the GICv3 settings that were not applied properly.
>>> As a result there are no timer interrupts.
>>>
>>> Further debugging on the GICv3 settings showed that the code (function
>> gic_cpu_init on drivers/irqchip/irq-gic-v3.c) tries to write 0xffffffff to
>> GICR_IGROUPR0 (Configure SGIs/PPIs as non-secure Group-1) but when we
>> try to read it back we get all zeros.
>>> Dumping GICv3 settings after the call to init_IRQ:
>>> Showing only the differences:
>>> Spider-SoC QEMU virt QEMU
>>> GICD_CTLR = 0x00000012 0x00000053
>>> GICD_TYPER = 0x037a0402 0x037a0007
>>> GICR0_IGROUPR0 = 0x00000000 0xffffffff
>>> GICR0_ISENABLER0 = 0x00000000 0x0000007f
>>> GICR0_ICENABLER0 = 0x00000000 0x0000007f
>>> GICR0_ICFGR0 = 0x00000000 0xaaaaaaaa
>>>
>>> Any thoughts?
>>> As always, your support is much appreciated!
>>
>> Sorry to disappoint, but I have no hands-on experience with the GIC.
>> My guess would be that you are missing initialization in the TF-A...
>>
>> Cheers,
>> Ahmad
>>
>>>
>>> Cheers,
>>> Lior.
>>>
>>>
>>>> -----Original Message-----
>>>> From: Ahmad Fatoum <a.fatoum@pengutronix.de>
>>>> Sent: Friday, June 30, 2023 8:53 AM
>>>> To: Lior Weintraub <liorw@pliops.com>; Ahmad Fatoum <ahmad@a3f.at>;
>>>> barebox@lists.infradead.org
>>>> Subject: Re: [PATCH v2] Porting barebox to a new SoC
>>>>
>>>> CAUTION: External Sender
>>>>
>>>> Hi Lior,
>>>>
>>>> On 25.06.23 22:33, Lior Weintraub wrote:
>>>>> Hello Ahmad,
>>>>
>>>> [Sorry for the delay, we're at EOSS 2023 currently]
>>>>
>>>>> I failed to reproduce this issue on virt because the addresses and
>> peripherals
>>>> on virt machine are different and it is difficult to change our code to match
>>>> that.
>>>>> If you think this is critical I will make extra effort to make it work.
>>>>> AFAIU, this suggestion was made to debug the "conflict" issue.
>>>>
>>>> It's not critical, but I'd have liked to understand this, so I can check
>>>> if it's perhaps a barebox bug.
>>>>
>>>>> Currently the workaround I am using is just to set the size of the kernel
>>>> partition to match the exact size of the "Image" file.
>>>>>
>>>>> The other issue I am facing is that Kernel seems stuck on cpu_do_idle and
>>>> there is no login prompt from the kernel.
>>>>
>>>> Does it call into PSCI during idle?
>>>>
>>>>> As you recall, I am running on a custom QEMU that tries to emulate our
>>>> platform.
>>>>> I suspect that I did something wrong with the GICv3 and Timers
>> connectivity.
>>>>> The code I used was based on examples I saw on sbsa-ref.c and virt.c.
>>>>> In addition, I declared the GICv3 and timers on our device tree.
>>>>>
>>>>> I running QEMU with "-d int" so I am also getting trace of exceptions and
>>>> interrupts.
>>>>
>>>> Nice. Didn't know about this option.
>>>>
>>>> [snip]
>>>>
>>>>> Exception return from AArch64 EL3 to AArch64 EL1 PC
>> 0xffffffc00802112c
>>>>> Taking exception 13 [Secure Monitor Call] on CPU 0
>>>>> ...from EL1 to EL3
>>>>> ...with ESR 0x17/0x5e000000
>>>>> ...with ELR 0xffffffc008021640
>>>>> ...to EL3 PC 0x10005400 PSTATE 0x3cd
>>>>> Exception return from AArch64 EL3 to AArch64 EL1 PC
>> 0xffffffc008021640
>>>>
>>>> Looks fine so far? Doesn't look like it's hanging in EL1.
>>>>
>>>> [snip]
>>>>
>>>>> Segment Routing with IPv6
>>>>> In-situ OAM (IOAM) with IPv6
>>>>> sit: IPv6, IPv4 and MPLS over IPv4 tunneling driver
>>>>> NET: Registered PF_PACKET protocol family
>>>>> NET: Registered PF_KEY protocol family
>>>>> NET: Registered PF_VSOCK protocol family
>>>>> registered taskstats version 1
>>>>> clk: Disabling unused clocks
>>>>> Freeing unused kernel memory: 1664K
>>>>
>>>> Not sure. Normally, I'd try again with pd_ignore_unused clk_ignore_unused
>> in
>>>> the
>>>> kernel arguments, but I think you define no clocks or power domains yet in
>>>> the DT?
>>>>
>>>> You can try again with kernel command line option initcall_debug and see
>>>> what the
>>>> initcall is that is getting stuck. If nothing helps, maybe attach a hardware
>>>> debugger?
>>>>
>>>> Cheers,
>>>> Ahmad
>>>>
>>>> --
>>>> Pengutronix e.K. | |
>>>> Steuerwalder Str. 21 | http://secure-
>> web.cisco.com/1RKlXzLFuAdOeswlWvHRCbVHHvoQssFo7iVFqyvv8Yn0sP-
>> MsWtfVRf2HW_4AXhQNuR5kNBuKLHNWkQfzg5qQhZ2AYhdNYqrfmNM7Isb
>> bDhybYe7C21TIR6Du5pxC7TSTbhhg4oBK3J9y2XyMtJNhBKeliNv2I5G4mlnB_
>> 57ph9x9tlPHstmZ8SL22VzM9RxLoj-5LddbVSsB69VGG-
>> O3Hw57EyoSFWKWmjNjOHDmuU1R3SwOX2tkDMmiLPauqbBc-
>> FP9cAFpclCgrOIJu2Jfef0-
>> sVV346BmbxC1SOFAKCI/http%3A%2F%2Fwww.pengutronix.de%2F |
>>>> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
>>>> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
>>>
>>
>> --
>> Pengutronix e.K. | |
>> Steuerwalder Str. 21 | http://secure-
>> web.cisco.com/1RKlXzLFuAdOeswlWvHRCbVHHvoQssFo7iVFqyvv8Yn0sP-
>> MsWtfVRf2HW_4AXhQNuR5kNBuKLHNWkQfzg5qQhZ2AYhdNYqrfmNM7Isb
>> bDhybYe7C21TIR6Du5pxC7TSTbhhg4oBK3J9y2XyMtJNhBKeliNv2I5G4mlnB_
>> 57ph9x9tlPHstmZ8SL22VzM9RxLoj-5LddbVSsB69VGG-
>> O3Hw57EyoSFWKWmjNjOHDmuU1R3SwOX2tkDMmiLPauqbBc-
>> FP9cAFpclCgrOIJu2Jfef0-
>> sVV346BmbxC1SOFAKCI/http%3A%2F%2Fwww.pengutronix.de%2F |
>> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
>> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
>>
>
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply [flat|nested] 40+ messages in thread
* RE: [PATCH v2] Porting barebox to a new SoC
2023-09-07 8:32 ` Ahmad Fatoum
@ 2023-09-07 9:07 ` Lior Weintraub
2023-09-07 9:35 ` Ahmad Fatoum
0 siblings, 1 reply; 40+ messages in thread
From: Lior Weintraub @ 2023-09-07 9:07 UTC (permalink / raw)
To: Ahmad Fatoum; +Cc: Ahmad Fatoum, barebox
Hi Ahmad,
I haven't posted a question yet. Will CC you when doing so.
In the meantime, I am trying to find the root cause on my own (with lower priority).
Found and fixed 2 potential issues but those didn't solve the stuck:
1. Linux default configure 39 VA bits. Changed it now to 48.
2. Our DT had declared the following memory section:
memory@0 {
device_type = "memory";
reg = < 0x00 0x00000000 0x0 0x30000000 /* 512M + 256M*/
0xC0 0x00000000 0x0 0x00400000 >; /* 4M */
};
Then I saw on Linux prints:
Early memory node ranges
node 0: [mem 0x0000000000000000-0x000000002fffffff]
node 0: [mem 0x000000c000000000-0x000000c0003fffff]
Initmem setup node 0 [mem 0x0000000000000000-0x000000c0003fffff]
That looked suspicious as node 0 took the whole range without considering the gap.
Maybe it is harmless but in any case we've removed the SRAM 4MB part because anyway the Linux will have nothing to do with it as it will only use the DRAM resources.
The new print looks now:
Movable zone start for each node
Early memory node ranges
node 0: [mem 0x0000000000000000-0x000000002fffffff]
Initmem setup node 0 [mem 0x0000000000000000-0x000000002fffffff]
I am looking for ways to debug the MMU settings that Linux is using because I suspect that the writes to the GICv3 are not mapped correctly.
Thought maybe the fact that our GIC is located on 0xE0_0000_0000 causes a bug.
Changed it's address on the QEMU and DT to be 0x00_E000_0000 but this didn't help.
Tried to print MMU mapping but as you probably know it's hard to do while MMU is enabled :-)
Tried to comment out the MMU enable code but that also caused a crash because Linux tried to access the VA.
Tried to use the Linux function __virt_to_phys in order to see which PA is used when the GICv3 is accessed using the following code:
uint64_t dist_base_phys_add = __virt_to_phys(gic_data.dist_base);
uint64_t redist_base_phys_add = __virt_to_phys(gic_data.redist_regions[0].redist_base);
pr_info("dist_base_phys_add = 0x%llx\n",dist_base_phys_add);
pr_info("redist_base_phys_add = 0x%llx\n",redist_base_phys_add);
It printed out strange addresses:
GICv3: dist_base_phys_add = 0x8aa0000
GICv3: redist_base_phys_add = 0x8ac0000
Saw there is an option to enable CONFIG_DEBUG_VIRTUAL and this showed an error message when I used the __virt_to_phys function:
------------[ cut here ]------------
virt_to_phys used for non-linear address: (____ptrval____) (0xffff800080aa0000)
WARNING: CPU: 0 PID: 0 at arch/arm64/mm/physaddr.c:12 __virt_to_phys+0x54/0x70
Modules linked in:
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.5.0 #86
Hardware name: Pliops Spider MK-I EVK (DT)
pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : __virt_to_phys+0x54/0x70
lr : __virt_to_phys+0x54/0x70
sp : ffff8000808f3de0
x29: ffff8000808f3de0 x28: 0000000008759074 x27: 0000000007a30dd8
x26: ffff8000807b5008 x25: 0000000000000019 x24: ffff8000809cc398
x23: ffff800080aa0000 x22: ffff8000809cc018 x21: ffff800080ac0000
x20: ffff8000806dfff0 x19: ffff800080aa0000 x18: ffffffffffffffff
x17: ffff000000089400 x16: ffff000000089200 x15: ffff8001008f373d
x14: 0000000000000001 x13: ffff8000808f3740 x12: ffff8000808f36d0
x11: ffff8000808f36c8 x10: 000000000000000a x9 : ffff8000808f3650
x8 : ffff80008090af28 x7 : ffff8000808f3c00 x6 : 000000000000000c
x5 : 0000000000000037 x4 : 0000000000000000 x3 : 0000000000000000
x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff8000808fd0c0
Call trace:
__virt_to_phys+0x54/0x70
dump_gic_regs+0x40/0x168
start_kernel+0x260/0x5cc
__primary_switched+0xb4/0xbc
---[ end trace 0000000000000000 ]---
So as you can see, I am trying to guess my way :-).
Not really know what I am doing but I think that is the best way to learn.
Cheers,
Lior.
> -----Original Message-----
> From: Ahmad Fatoum <a.fatoum@pengutronix.de>
> Sent: Thursday, September 7, 2023 11:33 AM
> To: Lior Weintraub <liorw@pliops.com>
> Cc: Ahmad Fatoum <ahmad@a3f.at>; barebox@lists.infradead.org
> Subject: Re: [PATCH v2] Porting barebox to a new SoC
>
> CAUTION: External Sender
>
> Hello Lior,
>
> On 22.08.23 10:48, Lior Weintraub wrote:
> > Thanks Ahmad, I Will try to post same question on Linux mailing list.
>
> I am curious to follow the discussion. Did you already post somewhere?
> I can't find a recent mail on lore.kernel.org.
>
> Feel free to Cc me when you post.
>
> Cheers,
> Ahmad
>
> >
> >> -----Original Message-----
> >> From: Ahmad Fatoum <a.fatoum@pengutronix.de>
> >> Sent: Tuesday, August 22, 2023 11:01 AM
> >> To: Lior Weintraub <liorw@pliops.com>
> >> Cc: Ahmad Fatoum <ahmad@a3f.at>; barebox@lists.infradead.org
> >> Subject: Re: [PATCH v2] Porting barebox to a new SoC
> >>
> >> CAUTION: External Sender
> >>
> >> Hello Lior,
> >>
> >> On 03.08.23 13:17, Lior Weintraub wrote:
> >>> Hi Ahmad,
> >>>
> >>> Hope you had a great time on EOSS 2023 :-)
> >>
> >> Thanks and sorry for the late answer.
> >>
> >>> Quick recap and additional info on the current issue:
> >>>
> >>> 1.
> >>> The spider-soc QEMU with the additional GICv3 and Timers was tested
> with
> >> a bare-metal code and proved to be OK.
> >>> This bare-metal code sets the A53 timers and GICv3 to handle interrupts
> on
> >> various execution levels as well as various security levels:
> >>> EL1_NS_PHYSICAL_TIMER set as GROUP1_NON_SECURE
> >>> EL1_SCR_PHYSICAL_TIMER set as GROUP1_SECURE
> >>> EL2_PHYSICAL_TIMER set as GROUP1_SECURE
> >>> VIRTUAL_TIMER set as GROUP1_NON_SECURE
> >>
> >> ok.
> >>
> >>> 2.
> >>> The kernel we build with Buildroot runs OK on virt QEMU but gets stuck in
> >> the middle when we use our spider-soc QEMU.
> >>> There are few differences between those runs:
> >>> a.
> >>> The virt QEMU is executed with -kernel switch and hence the QEMU itself
> >> implements the "bootloader" and prepares the DT given to the Kernel.
> >>> When the Kernel starts on this platforms it starts at EL1.
> >>
> >> This can be influenced e.g. on Virt with -M virt,virtualization=on, I think.
> >>
> >>> b.
> >>> The spider-soc QEMU is executed with -device loader,file=spider-soc-
> bl1.elf
> >>> Just for easy execution and testing, this executable includes all the needed
> >> binaries (as const data blobs) and it copies the binaries into correct
> locations
> >> before jumping to Barebox execution.
> >>> The list of binaries includes the barebox, kernel, dt, and rootfs.
> >>> As you recall, BL31 is compiled via Trusted-Firmware-A and has all it's
> >> functions as empty stubs because we currently don't care about CPU
> power
> >> states.
> >>> The prove that BL31 is executed correctly is that Barebox now runs at EL2.
> >>
> >> Good.
> >>
> >>> At that point the Linux kernel is starting and as I mentioned gets stuck in
> the
> >> middle (cpu_do_idle function. more details to follow).
> >>>
> >>> Debugging the kernel with GDB revealed few differences:
> >>> 1. When running with Barebox, the kernel starts at EL2 and at some point
> >> moves to EL1.
> >>> Not sure if that has some impact on the following issue but thought it is
> >> worth mentioning.
> >>> (We get a "CPU: All CPU(s) started at EL2" trace)
> >>
> >> I get the same on an i.MX8M as well (multi-core Cortex-A53 SoC).
> >>
> >>> Another difference that might be related to this execution level is that
> timers
> >> setting shows that it uses the physical timer (as oppose to virt QEMU run
> that
> >> uses the virtual timer):
> >>> The spider-soc QEMU Timers dump:
> >>> CNTFRQ_EL0 = 0x3b9aca0
> >>> CNTP_CTL_EL0 = 0x5
> >>> CNTV_CTL_EL0 = 0x0
> >>> CNTP_TVAL_EL0 = 0xff1f2ad5
> >>> CNTP_CVAL_EL0 = 0xac5c3240
> >>> CNTV_TVAL_EL0 = 0x52c2d916
> >>> CNTV_CVAL_EL0 = 0x0
> >>>
> >>> The virt QEMU Timers dump:
> >>> CNTFRQ_EL0 = 0x3b9aca0
> >>> CNTP_CTL_EL0 = 0x0
> >>> CNTV_CTL_EL0 = 0x5
> >>> CNTP_TVAL_EL0 = 0xb8394fbc
> >>> CNTP_CVAL_EL0 = 0x0
> >>> CNTV_TVAL_EL0 = 0xffd18e39
> >>> CNTV_CVAL_EL0 = 0x479858aa
> >>>
> >>> 2. When running with Barebox, the kernel fails to correctly set the GICv3
> >> registers.
> >>> So in other words, there are no timer events and hence the scheduler is
> not
> >> running.
> >>> The code get stuck on cpu_do_idle but we also found that the RCU cb_list
> is
> >> not empty (probably explains why scheduler haven't started (just a guess)).
> >>> We placed a breakpoint just before calling wait_for_completion (from
> >> function rcu_barrier on kernel/rcu/tree.c) and found:
> >>> bt
> >>> #0 rcu_barrier () at kernel/rcu/tree.c:4064
> >>> #1 0xffffffc08059e1b4 in mark_readonly () at init/main.c:1789
> >>> #2 kernel_init (unused=<optimized out>) at init/main.c:1838
> >>> #3 0xffffffc080015e48 in ret_from_fork () at
> >> arch/arm64/kernel/entry.S:853
> >>>
> >>> At that point rcu_state.barrier_cpu_count.counter is 1 (as oppose to virt
> >> QEMU where it is 0 at that point)
> >>> If we place the breakpoint a bit earlier in this rcu_barrier function (just
> >> before the for_each_possible_cpu loop) and run few more steps (to get the
> >> rdp) we see that rdp->cblist.len is 0x268 (616):
> >>> p/x rdp->cblist
> >>> $1 = {head = 0xffffffc0808f06d0, tails = {0xffffff802fe55a78,
> >> 0xffffff802fe55a78, 0xffffff802fe55a78, 0xffffff80001c22c8}, gp_seq =
> {0x0,
> >> 0x0, 0x0, 0x0}, len = 0x268, seglen = {0x0, 0x0, 0x0, 0x268}, flags = 0x1}
> >>>
> >>> When we compare that with virt QEMU we see that the rdp->cblist.len is 0
> >> there.
> >>>
> >>> IMHO, this all is a result of the GICv3 settings that were not applied
> properly.
> >>> As a result there are no timer interrupts.
> >>>
> >>> Further debugging on the GICv3 settings showed that the code (function
> >> gic_cpu_init on drivers/irqchip/irq-gic-v3.c) tries to write 0xffffffff to
> >> GICR_IGROUPR0 (Configure SGIs/PPIs as non-secure Group-1) but when
> we
> >> try to read it back we get all zeros.
> >>> Dumping GICv3 settings after the call to init_IRQ:
> >>> Showing only the differences:
> >>> Spider-SoC QEMU virt QEMU
> >>> GICD_CTLR = 0x00000012 0x00000053
> >>> GICD_TYPER = 0x037a0402 0x037a0007
> >>> GICR0_IGROUPR0 = 0x00000000 0xffffffff
> >>> GICR0_ISENABLER0 = 0x00000000 0x0000007f
> >>> GICR0_ICENABLER0 = 0x00000000 0x0000007f
> >>> GICR0_ICFGR0 = 0x00000000 0xaaaaaaaa
> >>>
> >>> Any thoughts?
> >>> As always, your support is much appreciated!
> >>
> >> Sorry to disappoint, but I have no hands-on experience with the GIC.
> >> My guess would be that you are missing initialization in the TF-A...
> >>
> >> Cheers,
> >> Ahmad
> >>
> >>>
> >>> Cheers,
> >>> Lior.
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: Ahmad Fatoum <a.fatoum@pengutronix.de>
> >>>> Sent: Friday, June 30, 2023 8:53 AM
> >>>> To: Lior Weintraub <liorw@pliops.com>; Ahmad Fatoum
> <ahmad@a3f.at>;
> >>>> barebox@lists.infradead.org
> >>>> Subject: Re: [PATCH v2] Porting barebox to a new SoC
> >>>>
> >>>> CAUTION: External Sender
> >>>>
> >>>> Hi Lior,
> >>>>
> >>>> On 25.06.23 22:33, Lior Weintraub wrote:
> >>>>> Hello Ahmad,
> >>>>
> >>>> [Sorry for the delay, we're at EOSS 2023 currently]
> >>>>
> >>>>> I failed to reproduce this issue on virt because the addresses and
> >> peripherals
> >>>> on virt machine are different and it is difficult to change our code to
> match
> >>>> that.
> >>>>> If you think this is critical I will make extra effort to make it work.
> >>>>> AFAIU, this suggestion was made to debug the "conflict" issue.
> >>>>
> >>>> It's not critical, but I'd have liked to understand this, so I can check
> >>>> if it's perhaps a barebox bug.
> >>>>
> >>>>> Currently the workaround I am using is just to set the size of the kernel
> >>>> partition to match the exact size of the "Image" file.
> >>>>>
> >>>>> The other issue I am facing is that Kernel seems stuck on cpu_do_idle
> and
> >>>> there is no login prompt from the kernel.
> >>>>
> >>>> Does it call into PSCI during idle?
> >>>>
> >>>>> As you recall, I am running on a custom QEMU that tries to emulate our
> >>>> platform.
> >>>>> I suspect that I did something wrong with the GICv3 and Timers
> >> connectivity.
> >>>>> The code I used was based on examples I saw on sbsa-ref.c and virt.c.
> >>>>> In addition, I declared the GICv3 and timers on our device tree.
> >>>>>
> >>>>> I running QEMU with "-d int" so I am also getting trace of exceptions
> and
> >>>> interrupts.
> >>>>
> >>>> Nice. Didn't know about this option.
> >>>>
> >>>> [snip]
> >>>>
> >>>>> Exception return from AArch64 EL3 to AArch64 EL1 PC
> >> 0xffffffc00802112c
> >>>>> Taking exception 13 [Secure Monitor Call] on CPU 0
> >>>>> ...from EL1 to EL3
> >>>>> ...with ESR 0x17/0x5e000000
> >>>>> ...with ELR 0xffffffc008021640
> >>>>> ...to EL3 PC 0x10005400 PSTATE 0x3cd
> >>>>> Exception return from AArch64 EL3 to AArch64 EL1 PC
> >> 0xffffffc008021640
> >>>>
> >>>> Looks fine so far? Doesn't look like it's hanging in EL1.
> >>>>
> >>>> [snip]
> >>>>
> >>>>> Segment Routing with IPv6
> >>>>> In-situ OAM (IOAM) with IPv6
> >>>>> sit: IPv6, IPv4 and MPLS over IPv4 tunneling driver
> >>>>> NET: Registered PF_PACKET protocol family
> >>>>> NET: Registered PF_KEY protocol family
> >>>>> NET: Registered PF_VSOCK protocol family
> >>>>> registered taskstats version 1
> >>>>> clk: Disabling unused clocks
> >>>>> Freeing unused kernel memory: 1664K
> >>>>
> >>>> Not sure. Normally, I'd try again with pd_ignore_unused
> clk_ignore_unused
> >> in
> >>>> the
> >>>> kernel arguments, but I think you define no clocks or power domains yet
> in
> >>>> the DT?
> >>>>
> >>>> You can try again with kernel command line option initcall_debug and see
> >>>> what the
> >>>> initcall is that is getting stuck. If nothing helps, maybe attach a hardware
> >>>> debugger?
> >>>>
> >>>> Cheers,
> >>>> Ahmad
> >>>>
> >>>> --
> >>>> Pengutronix e.K. | |
> >>>> Steuerwalder Str. 21 | http://secure-
> >> web.cisco.com/1RKlXzLFuAdOeswlWvHRCbVHHvoQssFo7iVFqyvv8Yn0sP-
> >>
> MsWtfVRf2HW_4AXhQNuR5kNBuKLHNWkQfzg5qQhZ2AYhdNYqrfmNM7Isb
> >>
> bDhybYe7C21TIR6Du5pxC7TSTbhhg4oBK3J9y2XyMtJNhBKeliNv2I5G4mlnB_
> >> 57ph9x9tlPHstmZ8SL22VzM9RxLoj-5LddbVSsB69VGG-
> >> O3Hw57EyoSFWKWmjNjOHDmuU1R3SwOX2tkDMmiLPauqbBc-
> >> FP9cAFpclCgrOIJu2Jfef0-
> >> sVV346BmbxC1SOFAKCI/http%3A%2F%2Fwww.pengutronix.de%2F |
> >>>> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
> >>>> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555
> |
> >>>
> >>
> >> --
> >> Pengutronix e.K. | |
> >> Steuerwalder Str. 21 | http://secure-
> >> web.cisco.com/1RKlXzLFuAdOeswlWvHRCbVHHvoQssFo7iVFqyvv8Yn0sP-
> >>
> MsWtfVRf2HW_4AXhQNuR5kNBuKLHNWkQfzg5qQhZ2AYhdNYqrfmNM7Isb
> >>
> bDhybYe7C21TIR6Du5pxC7TSTbhhg4oBK3J9y2XyMtJNhBKeliNv2I5G4mlnB_
> >> 57ph9x9tlPHstmZ8SL22VzM9RxLoj-5LddbVSsB69VGG-
> >> O3Hw57EyoSFWKWmjNjOHDmuU1R3SwOX2tkDMmiLPauqbBc-
> >> FP9cAFpclCgrOIJu2Jfef0-
> >> sVV346BmbxC1SOFAKCI/http%3A%2F%2Fwww.pengutronix.de%2F |
> >> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
> >> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
> >>
> >
>
> --
> Pengutronix e.K. | |
> Steuerwalder Str. 21 | http://secure-
> web.cisco.com/1O045o8i98buUBxhuX2t0uvDEzdfDsOOkHXvhw2zsg2diNV8f
> 8EZlM9mT9OrlFXuemhHKlD1F1skaFD_YT4n5EVauPPAxrSX4Pme-
> 1mIgrvUKeAVbZgzovldl0j6jKR2UYKcIgVEIcq1Jov13he3WdyUVs3XVXgcZUZM
> vdWOLX-
> voqQDAMDQcE6r2o_g4m7dbPaKNXliQFWT8yA6bGwtu8N2WM9GIADqK2Z_
> bICwvebcAHRze2ZNScbJ7p3i_8pZj05GbgDCoHNiHHXcOxapGVvFdPXldfl6Al_8
> XSVqUw5zEYqsyIn6t8meRIBU3_8e_/http%3A%2F%2Fwww.pengutronix.de
> %2F |
> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
>
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [PATCH v2] Porting barebox to a new SoC
2023-09-07 9:07 ` Lior Weintraub
@ 2023-09-07 9:35 ` Ahmad Fatoum
2023-09-07 11:02 ` Lior Weintraub
2023-09-12 6:04 ` Lior Weintraub
0 siblings, 2 replies; 40+ messages in thread
From: Ahmad Fatoum @ 2023-09-07 9:35 UTC (permalink / raw)
To: Lior Weintraub; +Cc: Ahmad Fatoum, barebox
Hello Lior,
On 07.09.23 11:07, Lior Weintraub wrote:
> Hi Ahmad,
>
> I haven't posted a question yet. Will CC you when doing so.
> In the meantime, I am trying to find the root cause on my own (with lower priority).
> Found and fixed 2 potential issues but those didn't solve the stuck:
> 1. Linux default configure 39 VA bits. Changed it now to 48.
> 2. Our DT had declared the following memory section:
> memory@0 {
> device_type = "memory";
> reg = < 0x00 0x00000000 0x0 0x30000000 /* 512M + 256M*/
> 0xC0 0x00000000 0x0 0x00400000 >; /* 4M */
I don't think that's correct. If you have multiple memory banks, you should
have multiple memory@ nodes.
> };
> Then I saw on Linux prints:
> Early memory node ranges
> node 0: [mem 0x0000000000000000-0x000000002fffffff]
> node 0: [mem 0x000000c000000000-0x000000c0003fffff]
> Initmem setup node 0 [mem 0x0000000000000000-0x000000c0003fffff]
>
> That looked suspicious as node 0 took the whole range without considering the gap.
> Maybe it is harmless but in any case we've removed the SRAM 4MB part because anyway the Linux will have nothing to do with it as it will only use the DRAM resources.
Generally, you shouldn't describe SRAM as /memory, especially if TF-A is sitting there
as you risk Linux clobbering it. There's a mmio-sram binding, which you can use
if you want to give drivers access to SRAM (e.g. for faster DMA), but you shouldn't
register it as general-purpose /memory.
> The new print looks now:
> Movable zone start for each node
> Early memory node ranges
> node 0: [mem 0x0000000000000000-0x000000002fffffff]
> Initmem setup node 0 [mem 0x0000000000000000-0x000000002fffffff]
That looks better, yes. I assume you load Linux to some address at the
beginning of this region? SZ_2M?
> I am looking for ways to debug the MMU settings that Linux is using because I suspect that the writes to the GICv3 are not mapped correctly.
> Thought maybe the fact that our GIC is located on 0xE0_0000_0000 causes a bug.
> Changed it's address on the QEMU and DT to be 0x00_E000_0000 but this didn't help.
>
> Tried to print MMU mapping but as you probably know it's hard to do while MMU is enabled :-)
There's kernel_page_tables in debugfs. I know you don't reach that far, but maybe
you can hack something together using an intermediate function to dump what's
relevant to you.
> Tried to comment out the MMU enable code but that also caused a crash because Linux tried to access the VA.
> Tried to use the Linux function __virt_to_phys in order to see which PA is used when the GICv3 is accessed using the following code:
> uint64_t dist_base_phys_add = __virt_to_phys(gic_data.dist_base);
> uint64_t redist_base_phys_add = __virt_to_phys(gic_data.redist_regions[0].redist_base);
> pr_info("dist_base_phys_add = 0x%llx\n",dist_base_phys_add);
> pr_info("redist_base_phys_add = 0x%llx\n",redist_base_phys_add);
>
> It printed out strange addresses:
> GICv3: dist_base_phys_add = 0x8aa0000
> GICv3: redist_base_phys_add = 0x8ac0000
The PA should be returned by of_iomap and passed to io_remap. Do you suspect
something changes its value?
> Saw there is an option to enable CONFIG_DEBUG_VIRTUAL and this showed an error message when I used the __virt_to_phys function:
> ------------[ cut here ]------------
> virt_to_phys used for non-linear address: (____ptrval____) (0xffff800080aa0000)
> WARNING: CPU: 0 PID: 0 at arch/arm64/mm/physaddr.c:12 __virt_to_phys+0x54/0x70
> Modules linked in:
> CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.5.0 #86
> Hardware name: Pliops Spider MK-I EVK (DT)
> pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> pc : __virt_to_phys+0x54/0x70
> lr : __virt_to_phys+0x54/0x70
> sp : ffff8000808f3de0
> x29: ffff8000808f3de0 x28: 0000000008759074 x27: 0000000007a30dd8
> x26: ffff8000807b5008 x25: 0000000000000019 x24: ffff8000809cc398
> x23: ffff800080aa0000 x22: ffff8000809cc018 x21: ffff800080ac0000
> x20: ffff8000806dfff0 x19: ffff800080aa0000 x18: ffffffffffffffff
> x17: ffff000000089400 x16: ffff000000089200 x15: ffff8001008f373d
> x14: 0000000000000001 x13: ffff8000808f3740 x12: ffff8000808f36d0
> x11: ffff8000808f36c8 x10: 000000000000000a x9 : ffff8000808f3650
> x8 : ffff80008090af28 x7 : ffff8000808f3c00 x6 : 000000000000000c
> x5 : 0000000000000037 x4 : 0000000000000000 x3 : 0000000000000000
> x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff8000808fd0c0
> Call trace:
> __virt_to_phys+0x54/0x70
> dump_gic_regs+0x40/0x168
> start_kernel+0x260/0x5cc
> __primary_switched+0xb4/0xbc
> ---[ end trace 0000000000000000 ]---
Ye, I don't think virt_to_phys is meant to be used for arbitrary addresses.
> So as you can see, I am trying to guess my way :-).
> Not really know what I am doing but I think that is the best way to learn.
That for sure. Good luck and keep me posted. :)
Cheers,
Ahmad
>
> Cheers,
> Lior.
>
>> -----Original Message-----
>> From: Ahmad Fatoum <a.fatoum@pengutronix.de>
>> Sent: Thursday, September 7, 2023 11:33 AM
>> To: Lior Weintraub <liorw@pliops.com>
>> Cc: Ahmad Fatoum <ahmad@a3f.at>; barebox@lists.infradead.org
>> Subject: Re: [PATCH v2] Porting barebox to a new SoC
>>
>> CAUTION: External Sender
>>
>> Hello Lior,
>>
>> On 22.08.23 10:48, Lior Weintraub wrote:
>>> Thanks Ahmad, I Will try to post same question on Linux mailing list.
>>
>> I am curious to follow the discussion. Did you already post somewhere?
>> I can't find a recent mail on lore.kernel.org.
>>
>> Feel free to Cc me when you post.
>>
>> Cheers,
>> Ahmad
>>
>>>
>>>> -----Original Message-----
>>>> From: Ahmad Fatoum <a.fatoum@pengutronix.de>
>>>> Sent: Tuesday, August 22, 2023 11:01 AM
>>>> To: Lior Weintraub <liorw@pliops.com>
>>>> Cc: Ahmad Fatoum <ahmad@a3f.at>; barebox@lists.infradead.org
>>>> Subject: Re: [PATCH v2] Porting barebox to a new SoC
>>>>
>>>> CAUTION: External Sender
>>>>
>>>> Hello Lior,
>>>>
>>>> On 03.08.23 13:17, Lior Weintraub wrote:
>>>>> Hi Ahmad,
>>>>>
>>>>> Hope you had a great time on EOSS 2023 :-)
>>>>
>>>> Thanks and sorry for the late answer.
>>>>
>>>>> Quick recap and additional info on the current issue:
>>>>>
>>>>> 1.
>>>>> The spider-soc QEMU with the additional GICv3 and Timers was tested
>> with
>>>> a bare-metal code and proved to be OK.
>>>>> This bare-metal code sets the A53 timers and GICv3 to handle interrupts
>> on
>>>> various execution levels as well as various security levels:
>>>>> EL1_NS_PHYSICAL_TIMER set as GROUP1_NON_SECURE
>>>>> EL1_SCR_PHYSICAL_TIMER set as GROUP1_SECURE
>>>>> EL2_PHYSICAL_TIMER set as GROUP1_SECURE
>>>>> VIRTUAL_TIMER set as GROUP1_NON_SECURE
>>>>
>>>> ok.
>>>>
>>>>> 2.
>>>>> The kernel we build with Buildroot runs OK on virt QEMU but gets stuck in
>>>> the middle when we use our spider-soc QEMU.
>>>>> There are few differences between those runs:
>>>>> a.
>>>>> The virt QEMU is executed with -kernel switch and hence the QEMU itself
>>>> implements the "bootloader" and prepares the DT given to the Kernel.
>>>>> When the Kernel starts on this platforms it starts at EL1.
>>>>
>>>> This can be influenced e.g. on Virt with -M virt,virtualization=on, I think.
>>>>
>>>>> b.
>>>>> The spider-soc QEMU is executed with -device loader,file=spider-soc-
>> bl1.elf
>>>>> Just for easy execution and testing, this executable includes all the needed
>>>> binaries (as const data blobs) and it copies the binaries into correct
>> locations
>>>> before jumping to Barebox execution.
>>>>> The list of binaries includes the barebox, kernel, dt, and rootfs.
>>>>> As you recall, BL31 is compiled via Trusted-Firmware-A and has all it's
>>>> functions as empty stubs because we currently don't care about CPU
>> power
>>>> states.
>>>>> The prove that BL31 is executed correctly is that Barebox now runs at EL2.
>>>>
>>>> Good.
>>>>
>>>>> At that point the Linux kernel is starting and as I mentioned gets stuck in
>> the
>>>> middle (cpu_do_idle function. more details to follow).
>>>>>
>>>>> Debugging the kernel with GDB revealed few differences:
>>>>> 1. When running with Barebox, the kernel starts at EL2 and at some point
>>>> moves to EL1.
>>>>> Not sure if that has some impact on the following issue but thought it is
>>>> worth mentioning.
>>>>> (We get a "CPU: All CPU(s) started at EL2" trace)
>>>>
>>>> I get the same on an i.MX8M as well (multi-core Cortex-A53 SoC).
>>>>
>>>>> Another difference that might be related to this execution level is that
>> timers
>>>> setting shows that it uses the physical timer (as oppose to virt QEMU run
>> that
>>>> uses the virtual timer):
>>>>> The spider-soc QEMU Timers dump:
>>>>> CNTFRQ_EL0 = 0x3b9aca0
>>>>> CNTP_CTL_EL0 = 0x5
>>>>> CNTV_CTL_EL0 = 0x0
>>>>> CNTP_TVAL_EL0 = 0xff1f2ad5
>>>>> CNTP_CVAL_EL0 = 0xac5c3240
>>>>> CNTV_TVAL_EL0 = 0x52c2d916
>>>>> CNTV_CVAL_EL0 = 0x0
>>>>>
>>>>> The virt QEMU Timers dump:
>>>>> CNTFRQ_EL0 = 0x3b9aca0
>>>>> CNTP_CTL_EL0 = 0x0
>>>>> CNTV_CTL_EL0 = 0x5
>>>>> CNTP_TVAL_EL0 = 0xb8394fbc
>>>>> CNTP_CVAL_EL0 = 0x0
>>>>> CNTV_TVAL_EL0 = 0xffd18e39
>>>>> CNTV_CVAL_EL0 = 0x479858aa
>>>>>
>>>>> 2. When running with Barebox, the kernel fails to correctly set the GICv3
>>>> registers.
>>>>> So in other words, there are no timer events and hence the scheduler is
>> not
>>>> running.
>>>>> The code get stuck on cpu_do_idle but we also found that the RCU cb_list
>> is
>>>> not empty (probably explains why scheduler haven't started (just a guess)).
>>>>> We placed a breakpoint just before calling wait_for_completion (from
>>>> function rcu_barrier on kernel/rcu/tree.c) and found:
>>>>> bt
>>>>> #0 rcu_barrier () at kernel/rcu/tree.c:4064
>>>>> #1 0xffffffc08059e1b4 in mark_readonly () at init/main.c:1789
>>>>> #2 kernel_init (unused=<optimized out>) at init/main.c:1838
>>>>> #3 0xffffffc080015e48 in ret_from_fork () at
>>>> arch/arm64/kernel/entry.S:853
>>>>>
>>>>> At that point rcu_state.barrier_cpu_count.counter is 1 (as oppose to virt
>>>> QEMU where it is 0 at that point)
>>>>> If we place the breakpoint a bit earlier in this rcu_barrier function (just
>>>> before the for_each_possible_cpu loop) and run few more steps (to get the
>>>> rdp) we see that rdp->cblist.len is 0x268 (616):
>>>>> p/x rdp->cblist
>>>>> $1 = {head = 0xffffffc0808f06d0, tails = {0xffffff802fe55a78,
>>>> 0xffffff802fe55a78, 0xffffff802fe55a78, 0xffffff80001c22c8}, gp_seq =
>> {0x0,
>>>> 0x0, 0x0, 0x0}, len = 0x268, seglen = {0x0, 0x0, 0x0, 0x268}, flags = 0x1}
>>>>>
>>>>> When we compare that with virt QEMU we see that the rdp->cblist.len is 0
>>>> there.
>>>>>
>>>>> IMHO, this all is a result of the GICv3 settings that were not applied
>> properly.
>>>>> As a result there are no timer interrupts.
>>>>>
>>>>> Further debugging on the GICv3 settings showed that the code (function
>>>> gic_cpu_init on drivers/irqchip/irq-gic-v3.c) tries to write 0xffffffff to
>>>> GICR_IGROUPR0 (Configure SGIs/PPIs as non-secure Group-1) but when
>> we
>>>> try to read it back we get all zeros.
>>>>> Dumping GICv3 settings after the call to init_IRQ:
>>>>> Showing only the differences:
>>>>> Spider-SoC QEMU virt QEMU
>>>>> GICD_CTLR = 0x00000012 0x00000053
>>>>> GICD_TYPER = 0x037a0402 0x037a0007
>>>>> GICR0_IGROUPR0 = 0x00000000 0xffffffff
>>>>> GICR0_ISENABLER0 = 0x00000000 0x0000007f
>>>>> GICR0_ICENABLER0 = 0x00000000 0x0000007f
>>>>> GICR0_ICFGR0 = 0x00000000 0xaaaaaaaa
>>>>>
>>>>> Any thoughts?
>>>>> As always, your support is much appreciated!
>>>>
>>>> Sorry to disappoint, but I have no hands-on experience with the GIC.
>>>> My guess would be that you are missing initialization in the TF-A...
>>>>
>>>> Cheers,
>>>> Ahmad
>>>>
>>>>>
>>>>> Cheers,
>>>>> Lior.
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Ahmad Fatoum <a.fatoum@pengutronix.de>
>>>>>> Sent: Friday, June 30, 2023 8:53 AM
>>>>>> To: Lior Weintraub <liorw@pliops.com>; Ahmad Fatoum
>> <ahmad@a3f.at>;
>>>>>> barebox@lists.infradead.org
>>>>>> Subject: Re: [PATCH v2] Porting barebox to a new SoC
>>>>>>
>>>>>> CAUTION: External Sender
>>>>>>
>>>>>> Hi Lior,
>>>>>>
>>>>>> On 25.06.23 22:33, Lior Weintraub wrote:
>>>>>>> Hello Ahmad,
>>>>>>
>>>>>> [Sorry for the delay, we're at EOSS 2023 currently]
>>>>>>
>>>>>>> I failed to reproduce this issue on virt because the addresses and
>>>> peripherals
>>>>>> on virt machine are different and it is difficult to change our code to
>> match
>>>>>> that.
>>>>>>> If you think this is critical I will make extra effort to make it work.
>>>>>>> AFAIU, this suggestion was made to debug the "conflict" issue.
>>>>>>
>>>>>> It's not critical, but I'd have liked to understand this, so I can check
>>>>>> if it's perhaps a barebox bug.
>>>>>>
>>>>>>> Currently the workaround I am using is just to set the size of the kernel
>>>>>> partition to match the exact size of the "Image" file.
>>>>>>>
>>>>>>> The other issue I am facing is that Kernel seems stuck on cpu_do_idle
>> and
>>>>>> there is no login prompt from the kernel.
>>>>>>
>>>>>> Does it call into PSCI during idle?
>>>>>>
>>>>>>> As you recall, I am running on a custom QEMU that tries to emulate our
>>>>>> platform.
>>>>>>> I suspect that I did something wrong with the GICv3 and Timers
>>>> connectivity.
>>>>>>> The code I used was based on examples I saw on sbsa-ref.c and virt.c.
>>>>>>> In addition, I declared the GICv3 and timers on our device tree.
>>>>>>>
>>>>>>> I running QEMU with "-d int" so I am also getting trace of exceptions
>> and
>>>>>> interrupts.
>>>>>>
>>>>>> Nice. Didn't know about this option.
>>>>>>
>>>>>> [snip]
>>>>>>
>>>>>>> Exception return from AArch64 EL3 to AArch64 EL1 PC
>>>> 0xffffffc00802112c
>>>>>>> Taking exception 13 [Secure Monitor Call] on CPU 0
>>>>>>> ...from EL1 to EL3
>>>>>>> ...with ESR 0x17/0x5e000000
>>>>>>> ...with ELR 0xffffffc008021640
>>>>>>> ...to EL3 PC 0x10005400 PSTATE 0x3cd
>>>>>>> Exception return from AArch64 EL3 to AArch64 EL1 PC
>>>> 0xffffffc008021640
>>>>>>
>>>>>> Looks fine so far? Doesn't look like it's hanging in EL1.
>>>>>>
>>>>>> [snip]
>>>>>>
>>>>>>> Segment Routing with IPv6
>>>>>>> In-situ OAM (IOAM) with IPv6
>>>>>>> sit: IPv6, IPv4 and MPLS over IPv4 tunneling driver
>>>>>>> NET: Registered PF_PACKET protocol family
>>>>>>> NET: Registered PF_KEY protocol family
>>>>>>> NET: Registered PF_VSOCK protocol family
>>>>>>> registered taskstats version 1
>>>>>>> clk: Disabling unused clocks
>>>>>>> Freeing unused kernel memory: 1664K
>>>>>>
>>>>>> Not sure. Normally, I'd try again with pd_ignore_unused
>> clk_ignore_unused
>>>> in
>>>>>> the
>>>>>> kernel arguments, but I think you define no clocks or power domains yet
>> in
>>>>>> the DT?
>>>>>>
>>>>>> You can try again with kernel command line option initcall_debug and see
>>>>>> what the
>>>>>> initcall is that is getting stuck. If nothing helps, maybe attach a hardware
>>>>>> debugger?
>>>>>>
>>>>>> Cheers,
>>>>>> Ahmad
>>>>>>
>>>>>> --
>>>>>> Pengutronix e.K. | |
>>>>>> Steuerwalder Str. 21 | http://secure-
>>>> web.cisco.com/1RKlXzLFuAdOeswlWvHRCbVHHvoQssFo7iVFqyvv8Yn0sP-
>>>>
>> MsWtfVRf2HW_4AXhQNuR5kNBuKLHNWkQfzg5qQhZ2AYhdNYqrfmNM7Isb
>>>>
>> bDhybYe7C21TIR6Du5pxC7TSTbhhg4oBK3J9y2XyMtJNhBKeliNv2I5G4mlnB_
>>>> 57ph9x9tlPHstmZ8SL22VzM9RxLoj-5LddbVSsB69VGG-
>>>> O3Hw57EyoSFWKWmjNjOHDmuU1R3SwOX2tkDMmiLPauqbBc-
>>>> FP9cAFpclCgrOIJu2Jfef0-
>>>> sVV346BmbxC1SOFAKCI/http%3A%2F%2Fwww.pengutronix.de%2F |
>>>>>> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
>>>>>> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555
>> |
>>>>>
>>>>
>>>> --
>>>> Pengutronix e.K. | |
>>>> Steuerwalder Str. 21 | http://secure-
>>>> web.cisco.com/1RKlXzLFuAdOeswlWvHRCbVHHvoQssFo7iVFqyvv8Yn0sP-
>>>>
>> MsWtfVRf2HW_4AXhQNuR5kNBuKLHNWkQfzg5qQhZ2AYhdNYqrfmNM7Isb
>>>>
>> bDhybYe7C21TIR6Du5pxC7TSTbhhg4oBK3J9y2XyMtJNhBKeliNv2I5G4mlnB_
>>>> 57ph9x9tlPHstmZ8SL22VzM9RxLoj-5LddbVSsB69VGG-
>>>> O3Hw57EyoSFWKWmjNjOHDmuU1R3SwOX2tkDMmiLPauqbBc-
>>>> FP9cAFpclCgrOIJu2Jfef0-
>>>> sVV346BmbxC1SOFAKCI/http%3A%2F%2Fwww.pengutronix.de%2F |
>>>> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
>>>> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
>>>>
>>>
>>
>> --
>> Pengutronix e.K. | |
>> Steuerwalder Str. 21 | http://secure-
>> web.cisco.com/1O045o8i98buUBxhuX2t0uvDEzdfDsOOkHXvhw2zsg2diNV8f
>> 8EZlM9mT9OrlFXuemhHKlD1F1skaFD_YT4n5EVauPPAxrSX4Pme-
>> 1mIgrvUKeAVbZgzovldl0j6jKR2UYKcIgVEIcq1Jov13he3WdyUVs3XVXgcZUZM
>> vdWOLX-
>> voqQDAMDQcE6r2o_g4m7dbPaKNXliQFWT8yA6bGwtu8N2WM9GIADqK2Z_
>> bICwvebcAHRze2ZNScbJ7p3i_8pZj05GbgDCoHNiHHXcOxapGVvFdPXldfl6Al_8
>> XSVqUw5zEYqsyIn6t8meRIBU3_8e_/http%3A%2F%2Fwww.pengutronix.de
>> %2F |
>> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
>> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
>>
>
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply [flat|nested] 40+ messages in thread
* RE: [PATCH v2] Porting barebox to a new SoC
2023-09-07 9:35 ` Ahmad Fatoum
@ 2023-09-07 11:02 ` Lior Weintraub
2023-09-12 6:04 ` Lior Weintraub
1 sibling, 0 replies; 40+ messages in thread
From: Lior Weintraub @ 2023-09-07 11:02 UTC (permalink / raw)
To: Ahmad Fatoum; +Cc: Ahmad Fatoum, barebox
Hello Ahmad,
Thanks for the tips!
Currently the Linux image is loaded into 128MB offset:
booti: Kernel to be loaded to 8000000+a90000
Loaded kernel to 0x08000000, devicetree at 0x09290000
.
.
Not sure how to use of_iomap and/or io_remap to convert VA back to PA.
The reason I suspect there is an issue there is because we added a gic_dump_regs function.
This function gets the VA which supposed to points to the GIC and then we dump few relevant registers.
In order to get the VA for the 2 GIC blocks (dist and redist) we used:
gic_data.dist_base
gic_data.redist_regions[0].redist_base
(Saw that irq-gic-v3.c uses that global data structure to perform the gic configuration).
When we dump the writes from a qemu-virt is looks OK (i.e. values written to the GIC block are read correctly)
When we dump the writes from a qemu-spider it seems that the writes were not getting into the GIC.
As you recall, the qemu-spider implementation was tested on bare-metal code where we access the GIC using PA.
It proved to be working (just a simple timers setting that trigger a GIC interrupts on various EL).
I even managed to use GDB to step into the gic_cpu_init function (on irq-gic-v3.c).
Placed a breakpoint just before this function exit and then opened another terminal connecting to QEMU monitor (using telnet localhost 1235).
From the QEMU monitor prompt, read GIC registers (using the PA) and proved that they were not written.
I think that the GIC section on the DT is correct because when we read the gic_data.dist_phys_base it gives the correct address (0xE0_0000_0000).
The GIC node on our DT looks as follows:
gic: interrupt-controller@E000000000 {
compatible = "arm,gic-600", "arm,gic-v3";
#interrupt-cells = <3>;
#address-cells = <2>;
#size-cells = <2>;
ranges;
/* Identifies the node as an interrupt controller */
interrupt-controller;
reg = <0xE0 0 0 0x10000>, /* GICD */
<0xE0 0x60000 0 0x20000>; /* GICR */
interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>;
its: gic-its@E000040000 {
compatible = "arm,gic-v3-its";
msi-controller;
#msi-cells = <1>;
reg = <0xE0 0x40000 0x0 0x20000>; // GITS
};
};
Thanks again for your great support,
Cheers,
Lior.
> -----Original Message-----
> From: Ahmad Fatoum <a.fatoum@pengutronix.de>
> Sent: Thursday, September 7, 2023 12:36 PM
> To: Lior Weintraub <liorw@pliops.com>
> Cc: Ahmad Fatoum <ahmad@a3f.at>; barebox@lists.infradead.org
> Subject: Re: [PATCH v2] Porting barebox to a new SoC
>
> CAUTION: External Sender
>
> Hello Lior,
>
> On 07.09.23 11:07, Lior Weintraub wrote:
> > Hi Ahmad,
> >
> > I haven't posted a question yet. Will CC you when doing so.
> > In the meantime, I am trying to find the root cause on my own (with lower
> priority).
> > Found and fixed 2 potential issues but those didn't solve the stuck:
> > 1. Linux default configure 39 VA bits. Changed it now to 48.
> > 2. Our DT had declared the following memory section:
> > memory@0 {
> > device_type = "memory";
> > reg = < 0x00 0x00000000 0x0 0x30000000 /* 512M + 256M*/
> > 0xC0 0x00000000 0x0 0x00400000 >; /* 4M */
>
> I don't think that's correct. If you have multiple memory banks, you should
> have multiple memory@ nodes.
>
> > };
> > Then I saw on Linux prints:
> > Early memory node ranges
> > node 0: [mem 0x0000000000000000-0x000000002fffffff]
> > node 0: [mem 0x000000c000000000-0x000000c0003fffff]
> > Initmem setup node 0 [mem 0x0000000000000000-0x000000c0003fffff]
> >
> > That looked suspicious as node 0 took the whole range without considering
> the gap.
> > Maybe it is harmless but in any case we've removed the SRAM 4MB part
> because anyway the Linux will have nothing to do with it as it will only use the
> DRAM resources.
>
> Generally, you shouldn't describe SRAM as /memory, especially if TF-A is
> sitting there
> as you risk Linux clobbering it. There's a mmio-sram binding, which you can
> use
> if you want to give drivers access to SRAM (e.g. for faster DMA), but you
> shouldn't
> register it as general-purpose /memory.
>
> > The new print looks now:
> > Movable zone start for each node
> > Early memory node ranges
> > node 0: [mem 0x0000000000000000-0x000000002fffffff]
> > Initmem setup node 0 [mem 0x0000000000000000-0x000000002fffffff]
>
> That looks better, yes. I assume you load Linux to some address at the
> beginning of this region? SZ_2M?
>
>
> > I am looking for ways to debug the MMU settings that Linux is using because
> I suspect that the writes to the GICv3 are not mapped correctly.
> > Thought maybe the fact that our GIC is located on 0xE0_0000_0000 causes
> a bug.
> > Changed it's address on the QEMU and DT to be 0x00_E000_0000 but this
> didn't help.
> >
> > Tried to print MMU mapping but as you probably know it's hard to do while
> MMU is enabled :-)
>
> There's kernel_page_tables in debugfs. I know you don't reach that far, but
> maybe
> you can hack something together using an intermediate function to dump
> what's
> relevant to you.
>
> > Tried to comment out the MMU enable code but that also caused a crash
> because Linux tried to access the VA.
> > Tried to use the Linux function __virt_to_phys in order to see which PA is
> used when the GICv3 is accessed using the following code:
> > uint64_t dist_base_phys_add = __virt_to_phys(gic_data.dist_base);
> > uint64_t redist_base_phys_add =
> __virt_to_phys(gic_data.redist_regions[0].redist_base);
> > pr_info("dist_base_phys_add = 0x%llx\n",dist_base_phys_add);
> > pr_info("redist_base_phys_add = 0x%llx\n",redist_base_phys_add);
> >
> > It printed out strange addresses:
> > GICv3: dist_base_phys_add = 0x8aa0000
> > GICv3: redist_base_phys_add = 0x8ac0000
>
> The PA should be returned by of_iomap and passed to io_remap. Do you
> suspect
> something changes its value?
>
>
> > Saw there is an option to enable CONFIG_DEBUG_VIRTUAL and this showed
> an error message when I used the __virt_to_phys function:
> > ------------[ cut here ]------------
> > virt_to_phys used for non-linear address: (____ptrval____)
> (0xffff800080aa0000)
> > WARNING: CPU: 0 PID: 0 at arch/arm64/mm/physaddr.c:12
> __virt_to_phys+0x54/0x70
> > Modules linked in:
> > CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.5.0 #86
> > Hardware name: Pliops Spider MK-I EVK (DT)
> > pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> > pc : __virt_to_phys+0x54/0x70
> > lr : __virt_to_phys+0x54/0x70
> > sp : ffff8000808f3de0
> > x29: ffff8000808f3de0 x28: 0000000008759074 x27: 0000000007a30dd8
> > x26: ffff8000807b5008 x25: 0000000000000019 x24: ffff8000809cc398
> > x23: ffff800080aa0000 x22: ffff8000809cc018 x21: ffff800080ac0000
> > x20: ffff8000806dfff0 x19: ffff800080aa0000 x18: ffffffffffffffff
> > x17: ffff000000089400 x16: ffff000000089200 x15: ffff8001008f373d
> > x14: 0000000000000001 x13: ffff8000808f3740 x12: ffff8000808f36d0
> > x11: ffff8000808f36c8 x10: 000000000000000a x9 : ffff8000808f3650
> > x8 : ffff80008090af28 x7 : ffff8000808f3c00 x6 : 000000000000000c
> > x5 : 0000000000000037 x4 : 0000000000000000 x3 :
> 0000000000000000
> > x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff8000808fd0c0
> > Call trace:
> > __virt_to_phys+0x54/0x70
> > dump_gic_regs+0x40/0x168
> > start_kernel+0x260/0x5cc
> > __primary_switched+0xb4/0xbc
> > ---[ end trace 0000000000000000 ]---
>
> Ye, I don't think virt_to_phys is meant to be used for arbitrary addresses.
>
> > So as you can see, I am trying to guess my way :-).
> > Not really know what I am doing but I think that is the best way to learn.
>
> That for sure. Good luck and keep me posted. :)
>
> Cheers,
> Ahmad
>
> >
> > Cheers,
> > Lior.
> >
> >> -----Original Message-----
> >> From: Ahmad Fatoum <a.fatoum@pengutronix.de>
> >> Sent: Thursday, September 7, 2023 11:33 AM
> >> To: Lior Weintraub <liorw@pliops.com>
> >> Cc: Ahmad Fatoum <ahmad@a3f.at>; barebox@lists.infradead.org
> >> Subject: Re: [PATCH v2] Porting barebox to a new SoC
> >>
> >> CAUTION: External Sender
> >>
> >> Hello Lior,
> >>
> >> On 22.08.23 10:48, Lior Weintraub wrote:
> >>> Thanks Ahmad, I Will try to post same question on Linux mailing list.
> >>
> >> I am curious to follow the discussion. Did you already post somewhere?
> >> I can't find a recent mail on lore.kernel.org.
> >>
> >> Feel free to Cc me when you post.
> >>
> >> Cheers,
> >> Ahmad
> >>
> >>>
> >>>> -----Original Message-----
> >>>> From: Ahmad Fatoum <a.fatoum@pengutronix.de>
> >>>> Sent: Tuesday, August 22, 2023 11:01 AM
> >>>> To: Lior Weintraub <liorw@pliops.com>
> >>>> Cc: Ahmad Fatoum <ahmad@a3f.at>; barebox@lists.infradead.org
> >>>> Subject: Re: [PATCH v2] Porting barebox to a new SoC
> >>>>
> >>>> CAUTION: External Sender
> >>>>
> >>>> Hello Lior,
> >>>>
> >>>> On 03.08.23 13:17, Lior Weintraub wrote:
> >>>>> Hi Ahmad,
> >>>>>
> >>>>> Hope you had a great time on EOSS 2023 :-)
> >>>>
> >>>> Thanks and sorry for the late answer.
> >>>>
> >>>>> Quick recap and additional info on the current issue:
> >>>>>
> >>>>> 1.
> >>>>> The spider-soc QEMU with the additional GICv3 and Timers was tested
> >> with
> >>>> a bare-metal code and proved to be OK.
> >>>>> This bare-metal code sets the A53 timers and GICv3 to handle interrupts
> >> on
> >>>> various execution levels as well as various security levels:
> >>>>> EL1_NS_PHYSICAL_TIMER set as GROUP1_NON_SECURE
> >>>>> EL1_SCR_PHYSICAL_TIMER set as GROUP1_SECURE
> >>>>> EL2_PHYSICAL_TIMER set as GROUP1_SECURE
> >>>>> VIRTUAL_TIMER set as GROUP1_NON_SECURE
> >>>>
> >>>> ok.
> >>>>
> >>>>> 2.
> >>>>> The kernel we build with Buildroot runs OK on virt QEMU but gets stuck
> in
> >>>> the middle when we use our spider-soc QEMU.
> >>>>> There are few differences between those runs:
> >>>>> a.
> >>>>> The virt QEMU is executed with -kernel switch and hence the QEMU
> itself
> >>>> implements the "bootloader" and prepares the DT given to the Kernel.
> >>>>> When the Kernel starts on this platforms it starts at EL1.
> >>>>
> >>>> This can be influenced e.g. on Virt with -M virt,virtualization=on, I think.
> >>>>
> >>>>> b.
> >>>>> The spider-soc QEMU is executed with -device loader,file=spider-soc-
> >> bl1.elf
> >>>>> Just for easy execution and testing, this executable includes all the
> needed
> >>>> binaries (as const data blobs) and it copies the binaries into correct
> >> locations
> >>>> before jumping to Barebox execution.
> >>>>> The list of binaries includes the barebox, kernel, dt, and rootfs.
> >>>>> As you recall, BL31 is compiled via Trusted-Firmware-A and has all it's
> >>>> functions as empty stubs because we currently don't care about CPU
> >> power
> >>>> states.
> >>>>> The prove that BL31 is executed correctly is that Barebox now runs at
> EL2.
> >>>>
> >>>> Good.
> >>>>
> >>>>> At that point the Linux kernel is starting and as I mentioned gets stuck in
> >> the
> >>>> middle (cpu_do_idle function. more details to follow).
> >>>>>
> >>>>> Debugging the kernel with GDB revealed few differences:
> >>>>> 1. When running with Barebox, the kernel starts at EL2 and at some
> point
> >>>> moves to EL1.
> >>>>> Not sure if that has some impact on the following issue but thought it is
> >>>> worth mentioning.
> >>>>> (We get a "CPU: All CPU(s) started at EL2" trace)
> >>>>
> >>>> I get the same on an i.MX8M as well (multi-core Cortex-A53 SoC).
> >>>>
> >>>>> Another difference that might be related to this execution level is that
> >> timers
> >>>> setting shows that it uses the physical timer (as oppose to virt QEMU run
> >> that
> >>>> uses the virtual timer):
> >>>>> The spider-soc QEMU Timers dump:
> >>>>> CNTFRQ_EL0 = 0x3b9aca0
> >>>>> CNTP_CTL_EL0 = 0x5
> >>>>> CNTV_CTL_EL0 = 0x0
> >>>>> CNTP_TVAL_EL0 = 0xff1f2ad5
> >>>>> CNTP_CVAL_EL0 = 0xac5c3240
> >>>>> CNTV_TVAL_EL0 = 0x52c2d916
> >>>>> CNTV_CVAL_EL0 = 0x0
> >>>>>
> >>>>> The virt QEMU Timers dump:
> >>>>> CNTFRQ_EL0 = 0x3b9aca0
> >>>>> CNTP_CTL_EL0 = 0x0
> >>>>> CNTV_CTL_EL0 = 0x5
> >>>>> CNTP_TVAL_EL0 = 0xb8394fbc
> >>>>> CNTP_CVAL_EL0 = 0x0
> >>>>> CNTV_TVAL_EL0 = 0xffd18e39
> >>>>> CNTV_CVAL_EL0 = 0x479858aa
> >>>>>
> >>>>> 2. When running with Barebox, the kernel fails to correctly set the GICv3
> >>>> registers.
> >>>>> So in other words, there are no timer events and hence the scheduler is
> >> not
> >>>> running.
> >>>>> The code get stuck on cpu_do_idle but we also found that the RCU
> cb_list
> >> is
> >>>> not empty (probably explains why scheduler haven't started (just a
> guess)).
> >>>>> We placed a breakpoint just before calling wait_for_completion (from
> >>>> function rcu_barrier on kernel/rcu/tree.c) and found:
> >>>>> bt
> >>>>> #0 rcu_barrier () at kernel/rcu/tree.c:4064
> >>>>> #1 0xffffffc08059e1b4 in mark_readonly () at init/main.c:1789
> >>>>> #2 kernel_init (unused=<optimized out>) at init/main.c:1838
> >>>>> #3 0xffffffc080015e48 in ret_from_fork () at
> >>>> arch/arm64/kernel/entry.S:853
> >>>>>
> >>>>> At that point rcu_state.barrier_cpu_count.counter is 1 (as oppose to
> virt
> >>>> QEMU where it is 0 at that point)
> >>>>> If we place the breakpoint a bit earlier in this rcu_barrier function (just
> >>>> before the for_each_possible_cpu loop) and run few more steps (to get
> the
> >>>> rdp) we see that rdp->cblist.len is 0x268 (616):
> >>>>> p/x rdp->cblist
> >>>>> $1 = {head = 0xffffffc0808f06d0, tails = {0xffffff802fe55a78,
> >>>> 0xffffff802fe55a78, 0xffffff802fe55a78, 0xffffff80001c22c8}, gp_seq =
> >> {0x0,
> >>>> 0x0, 0x0, 0x0}, len = 0x268, seglen = {0x0, 0x0, 0x0, 0x268}, flags = 0x1}
> >>>>>
> >>>>> When we compare that with virt QEMU we see that the rdp->cblist.len
> is 0
> >>>> there.
> >>>>>
> >>>>> IMHO, this all is a result of the GICv3 settings that were not applied
> >> properly.
> >>>>> As a result there are no timer interrupts.
> >>>>>
> >>>>> Further debugging on the GICv3 settings showed that the code
> (function
> >>>> gic_cpu_init on drivers/irqchip/irq-gic-v3.c) tries to write 0xffffffff to
> >>>> GICR_IGROUPR0 (Configure SGIs/PPIs as non-secure Group-1) but when
> >> we
> >>>> try to read it back we get all zeros.
> >>>>> Dumping GICv3 settings after the call to init_IRQ:
> >>>>> Showing only the differences:
> >>>>> Spider-SoC QEMU virt QEMU
> >>>>> GICD_CTLR = 0x00000012 0x00000053
> >>>>> GICD_TYPER = 0x037a0402 0x037a0007
> >>>>> GICR0_IGROUPR0 = 0x00000000 0xffffffff
> >>>>> GICR0_ISENABLER0 = 0x00000000 0x0000007f
> >>>>> GICR0_ICENABLER0 = 0x00000000 0x0000007f
> >>>>> GICR0_ICFGR0 = 0x00000000 0xaaaaaaaa
> >>>>>
> >>>>> Any thoughts?
> >>>>> As always, your support is much appreciated!
> >>>>
> >>>> Sorry to disappoint, but I have no hands-on experience with the GIC.
> >>>> My guess would be that you are missing initialization in the TF-A...
> >>>>
> >>>> Cheers,
> >>>> Ahmad
> >>>>
> >>>>>
> >>>>> Cheers,
> >>>>> Lior.
> >>>>>
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: Ahmad Fatoum <a.fatoum@pengutronix.de>
> >>>>>> Sent: Friday, June 30, 2023 8:53 AM
> >>>>>> To: Lior Weintraub <liorw@pliops.com>; Ahmad Fatoum
> >> <ahmad@a3f.at>;
> >>>>>> barebox@lists.infradead.org
> >>>>>> Subject: Re: [PATCH v2] Porting barebox to a new SoC
> >>>>>>
> >>>>>> CAUTION: External Sender
> >>>>>>
> >>>>>> Hi Lior,
> >>>>>>
> >>>>>> On 25.06.23 22:33, Lior Weintraub wrote:
> >>>>>>> Hello Ahmad,
> >>>>>>
> >>>>>> [Sorry for the delay, we're at EOSS 2023 currently]
> >>>>>>
> >>>>>>> I failed to reproduce this issue on virt because the addresses and
> >>>> peripherals
> >>>>>> on virt machine are different and it is difficult to change our code to
> >> match
> >>>>>> that.
> >>>>>>> If you think this is critical I will make extra effort to make it work.
> >>>>>>> AFAIU, this suggestion was made to debug the "conflict" issue.
> >>>>>>
> >>>>>> It's not critical, but I'd have liked to understand this, so I can check
> >>>>>> if it's perhaps a barebox bug.
> >>>>>>
> >>>>>>> Currently the workaround I am using is just to set the size of the
> kernel
> >>>>>> partition to match the exact size of the "Image" file.
> >>>>>>>
> >>>>>>> The other issue I am facing is that Kernel seems stuck on cpu_do_idle
> >> and
> >>>>>> there is no login prompt from the kernel.
> >>>>>>
> >>>>>> Does it call into PSCI during idle?
> >>>>>>
> >>>>>>> As you recall, I am running on a custom QEMU that tries to emulate
> our
> >>>>>> platform.
> >>>>>>> I suspect that I did something wrong with the GICv3 and Timers
> >>>> connectivity.
> >>>>>>> The code I used was based on examples I saw on sbsa-ref.c and virt.c.
> >>>>>>> In addition, I declared the GICv3 and timers on our device tree.
> >>>>>>>
> >>>>>>> I running QEMU with "-d int" so I am also getting trace of exceptions
> >> and
> >>>>>> interrupts.
> >>>>>>
> >>>>>> Nice. Didn't know about this option.
> >>>>>>
> >>>>>> [snip]
> >>>>>>
> >>>>>>> Exception return from AArch64 EL3 to AArch64 EL1 PC
> >>>> 0xffffffc00802112c
> >>>>>>> Taking exception 13 [Secure Monitor Call] on CPU 0
> >>>>>>> ...from EL1 to EL3
> >>>>>>> ...with ESR 0x17/0x5e000000
> >>>>>>> ...with ELR 0xffffffc008021640
> >>>>>>> ...to EL3 PC 0x10005400 PSTATE 0x3cd
> >>>>>>> Exception return from AArch64 EL3 to AArch64 EL1 PC
> >>>> 0xffffffc008021640
> >>>>>>
> >>>>>> Looks fine so far? Doesn't look like it's hanging in EL1.
> >>>>>>
> >>>>>> [snip]
> >>>>>>
> >>>>>>> Segment Routing with IPv6
> >>>>>>> In-situ OAM (IOAM) with IPv6
> >>>>>>> sit: IPv6, IPv4 and MPLS over IPv4 tunneling driver
> >>>>>>> NET: Registered PF_PACKET protocol family
> >>>>>>> NET: Registered PF_KEY protocol family
> >>>>>>> NET: Registered PF_VSOCK protocol family
> >>>>>>> registered taskstats version 1
> >>>>>>> clk: Disabling unused clocks
> >>>>>>> Freeing unused kernel memory: 1664K
> >>>>>>
> >>>>>> Not sure. Normally, I'd try again with pd_ignore_unused
> >> clk_ignore_unused
> >>>> in
> >>>>>> the
> >>>>>> kernel arguments, but I think you define no clocks or power domains
> yet
> >> in
> >>>>>> the DT?
> >>>>>>
> >>>>>> You can try again with kernel command line option initcall_debug and
> see
> >>>>>> what the
> >>>>>> initcall is that is getting stuck. If nothing helps, maybe attach a
> hardware
> >>>>>> debugger?
> >>>>>>
> >>>>>> Cheers,
> >>>>>> Ahmad
> >>>>>>
> >>>>>> --
> >>>>>> Pengutronix e.K. | |
> >>>>>> Steuerwalder Str. 21 | http://secure-
> >>>>
> web.cisco.com/1RKlXzLFuAdOeswlWvHRCbVHHvoQssFo7iVFqyvv8Yn0sP-
> >>>>
> >>
> MsWtfVRf2HW_4AXhQNuR5kNBuKLHNWkQfzg5qQhZ2AYhdNYqrfmNM7Isb
> >>>>
> >>
> bDhybYe7C21TIR6Du5pxC7TSTbhhg4oBK3J9y2XyMtJNhBKeliNv2I5G4mlnB_
> >>>> 57ph9x9tlPHstmZ8SL22VzM9RxLoj-5LddbVSsB69VGG-
> >>>> O3Hw57EyoSFWKWmjNjOHDmuU1R3SwOX2tkDMmiLPauqbBc-
> >>>> FP9cAFpclCgrOIJu2Jfef0-
> >>>> sVV346BmbxC1SOFAKCI/http%3A%2F%2Fwww.pengutronix.de%2F |
> >>>>>> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0
> |
> >>>>>> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-
> 5555
> >> |
> >>>>>
> >>>>
> >>>> --
> >>>> Pengutronix e.K. | |
> >>>> Steuerwalder Str. 21 | http://secure-
> >>>>
> web.cisco.com/1RKlXzLFuAdOeswlWvHRCbVHHvoQssFo7iVFqyvv8Yn0sP-
> >>>>
> >>
> MsWtfVRf2HW_4AXhQNuR5kNBuKLHNWkQfzg5qQhZ2AYhdNYqrfmNM7Isb
> >>>>
> >>
> bDhybYe7C21TIR6Du5pxC7TSTbhhg4oBK3J9y2XyMtJNhBKeliNv2I5G4mlnB_
> >>>> 57ph9x9tlPHstmZ8SL22VzM9RxLoj-5LddbVSsB69VGG-
> >>>> O3Hw57EyoSFWKWmjNjOHDmuU1R3SwOX2tkDMmiLPauqbBc-
> >>>> FP9cAFpclCgrOIJu2Jfef0-
> >>>> sVV346BmbxC1SOFAKCI/http%3A%2F%2Fwww.pengutronix.de%2F |
> >>>> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
> >>>> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555
> |
> >>>>
> >>>
> >>
> >> --
> >> Pengutronix e.K. | |
> >> Steuerwalder Str. 21 | http://secure-
> >>
> web.cisco.com/1O045o8i98buUBxhuX2t0uvDEzdfDsOOkHXvhw2zsg2diNV8f
> >> 8EZlM9mT9OrlFXuemhHKlD1F1skaFD_YT4n5EVauPPAxrSX4Pme-
> >>
> 1mIgrvUKeAVbZgzovldl0j6jKR2UYKcIgVEIcq1Jov13he3WdyUVs3XVXgcZUZM
> >> vdWOLX-
> >>
> voqQDAMDQcE6r2o_g4m7dbPaKNXliQFWT8yA6bGwtu8N2WM9GIADqK2Z_
> >>
> bICwvebcAHRze2ZNScbJ7p3i_8pZj05GbgDCoHNiHHXcOxapGVvFdPXldfl6Al_8
> >>
> XSVqUw5zEYqsyIn6t8meRIBU3_8e_/http%3A%2F%2Fwww.pengutronix.de
> >> %2F |
> >> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
> >> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
> >>
> >
>
> --
> Pengutronix e.K. | |
> Steuerwalder Str. 21 | http://secure-
> web.cisco.com/1afoFuFC3rpiLUQlbUrABGUc9nbtrJEQNAxBKml71H86dBKnb
> YKJO3jZccgayiJmX8aQx4TKbf_sgV4fViIXIr3lxe2jeWKr3cK7EIwIb2eHDv_hMwr
> f0Y3BW5NZTHxftUPSJGz5HN7kuASMWPuKjQrSe_qGFrhV_5nNC_2Nnp2CPK
> amM9K1N-
> YvvKcQq002UT10rL5x1wKosDOZjKM_N28w2ocRP5UpRV2339nJtan1G7k1n
> QWlfFFAgVp-
> asmqiZnMU0_E1rSBPIBT7N9fCtg5A7sHGln7Ux1Huxxdpb0ukPOZtiawk0bLLX
> Y5jRf40/http%3A%2F%2Fwww.pengutronix.de%2F |
> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
>
^ permalink raw reply [flat|nested] 40+ messages in thread
* RE: [PATCH v2] Porting barebox to a new SoC
2023-09-07 9:35 ` Ahmad Fatoum
2023-09-07 11:02 ` Lior Weintraub
@ 2023-09-12 6:04 ` Lior Weintraub
1 sibling, 0 replies; 40+ messages in thread
From: Lior Weintraub @ 2023-09-12 6:04 UTC (permalink / raw)
To: Ahmad Fatoum; +Cc: Ahmad Fatoum, barebox
Hello Ahmad,
I am happy to share with your that the issue was resolved.
All because of 1 bit on the GIC Distributer Control register which allow non-secure to config the GIC.
From the GIC-600 manual:
----------------------------------------------------------------------------------------------------------------------------------------
Setting the Disable Security (DS) bit to 1 in the GICD_CTLR register removes the security support of
the GIC-600. It can be set by Secure software during the boot sequence or configured to be always set
when you configure the design using the parameter ds_value. When the system has no concept of
security, you must set GICD_CTLR.DS to allow access to important registers.
If you run software without security awareness on a system that supports security, the Secure boot code
can set DS before switching to a Non-secure Exception level to run the software. This enables you to
program the GIC-600 from any Exception level and use two interrupt groups, Group 0 and Group 1, so
that interrupts can target both the FIQ and IRQ handlers on a core.
----------------------------------------------------------------------------------------------------------------------------------------
I wonder if I can suggest a patch to Linux kernel that will check this bit and report some kind of error message to the user.
This kind of error message could have saved me a lot of time.
I was under the impression that I don't need to know about GIC configuration because Linux has a driver for it.
Cheers,
Lior.
> -----Original Message-----
> From: Ahmad Fatoum <a.fatoum@pengutronix.de>
> Sent: Thursday, September 7, 2023 12:36 PM
> To: Lior Weintraub <liorw@pliops.com>
> Cc: Ahmad Fatoum <ahmad@a3f.at>; barebox@lists.infradead.org
> Subject: Re: [PATCH v2] Porting barebox to a new SoC
>
> CAUTION: External Sender
>
> Hello Lior,
>
> On 07.09.23 11:07, Lior Weintraub wrote:
> > Hi Ahmad,
> >
> > I haven't posted a question yet. Will CC you when doing so.
> > In the meantime, I am trying to find the root cause on my own (with lower
> priority).
> > Found and fixed 2 potential issues but those didn't solve the stuck:
> > 1. Linux default configure 39 VA bits. Changed it now to 48.
> > 2. Our DT had declared the following memory section:
> > memory@0 {
> > device_type = "memory";
> > reg = < 0x00 0x00000000 0x0 0x30000000 /* 512M + 256M*/
> > 0xC0 0x00000000 0x0 0x00400000 >; /* 4M */
>
> I don't think that's correct. If you have multiple memory banks, you should
> have multiple memory@ nodes.
>
> > };
> > Then I saw on Linux prints:
> > Early memory node ranges
> > node 0: [mem 0x0000000000000000-0x000000002fffffff]
> > node 0: [mem 0x000000c000000000-0x000000c0003fffff]
> > Initmem setup node 0 [mem 0x0000000000000000-0x000000c0003fffff]
> >
> > That looked suspicious as node 0 took the whole range without considering
> the gap.
> > Maybe it is harmless but in any case we've removed the SRAM 4MB part
> because anyway the Linux will have nothing to do with it as it will only use the
> DRAM resources.
>
> Generally, you shouldn't describe SRAM as /memory, especially if TF-A is
> sitting there
> as you risk Linux clobbering it. There's a mmio-sram binding, which you can
> use
> if you want to give drivers access to SRAM (e.g. for faster DMA), but you
> shouldn't
> register it as general-purpose /memory.
>
> > The new print looks now:
> > Movable zone start for each node
> > Early memory node ranges
> > node 0: [mem 0x0000000000000000-0x000000002fffffff]
> > Initmem setup node 0 [mem 0x0000000000000000-0x000000002fffffff]
>
> That looks better, yes. I assume you load Linux to some address at the
> beginning of this region? SZ_2M?
>
>
> > I am looking for ways to debug the MMU settings that Linux is using because
> I suspect that the writes to the GICv3 are not mapped correctly.
> > Thought maybe the fact that our GIC is located on 0xE0_0000_0000 causes
> a bug.
> > Changed it's address on the QEMU and DT to be 0x00_E000_0000 but this
> didn't help.
> >
> > Tried to print MMU mapping but as you probably know it's hard to do while
> MMU is enabled :-)
>
> There's kernel_page_tables in debugfs. I know you don't reach that far, but
> maybe
> you can hack something together using an intermediate function to dump
> what's
> relevant to you.
>
> > Tried to comment out the MMU enable code but that also caused a crash
> because Linux tried to access the VA.
> > Tried to use the Linux function __virt_to_phys in order to see which PA is
> used when the GICv3 is accessed using the following code:
> > uint64_t dist_base_phys_add = __virt_to_phys(gic_data.dist_base);
> > uint64_t redist_base_phys_add =
> __virt_to_phys(gic_data.redist_regions[0].redist_base);
> > pr_info("dist_base_phys_add = 0x%llx\n",dist_base_phys_add);
> > pr_info("redist_base_phys_add = 0x%llx\n",redist_base_phys_add);
> >
> > It printed out strange addresses:
> > GICv3: dist_base_phys_add = 0x8aa0000
> > GICv3: redist_base_phys_add = 0x8ac0000
>
> The PA should be returned by of_iomap and passed to io_remap. Do you
> suspect
> something changes its value?
>
>
> > Saw there is an option to enable CONFIG_DEBUG_VIRTUAL and this showed
> an error message when I used the __virt_to_phys function:
> > ------------[ cut here ]------------
> > virt_to_phys used for non-linear address: (____ptrval____)
> (0xffff800080aa0000)
> > WARNING: CPU: 0 PID: 0 at arch/arm64/mm/physaddr.c:12
> __virt_to_phys+0x54/0x70
> > Modules linked in:
> > CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.5.0 #86
> > Hardware name: Pliops Spider MK-I EVK (DT)
> > pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> > pc : __virt_to_phys+0x54/0x70
> > lr : __virt_to_phys+0x54/0x70
> > sp : ffff8000808f3de0
> > x29: ffff8000808f3de0 x28: 0000000008759074 x27: 0000000007a30dd8
> > x26: ffff8000807b5008 x25: 0000000000000019 x24: ffff8000809cc398
> > x23: ffff800080aa0000 x22: ffff8000809cc018 x21: ffff800080ac0000
> > x20: ffff8000806dfff0 x19: ffff800080aa0000 x18: ffffffffffffffff
> > x17: ffff000000089400 x16: ffff000000089200 x15: ffff8001008f373d
> > x14: 0000000000000001 x13: ffff8000808f3740 x12: ffff8000808f36d0
> > x11: ffff8000808f36c8 x10: 000000000000000a x9 : ffff8000808f3650
> > x8 : ffff80008090af28 x7 : ffff8000808f3c00 x6 : 000000000000000c
> > x5 : 0000000000000037 x4 : 0000000000000000 x3 :
> 0000000000000000
> > x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff8000808fd0c0
> > Call trace:
> > __virt_to_phys+0x54/0x70
> > dump_gic_regs+0x40/0x168
> > start_kernel+0x260/0x5cc
> > __primary_switched+0xb4/0xbc
> > ---[ end trace 0000000000000000 ]---
>
> Ye, I don't think virt_to_phys is meant to be used for arbitrary addresses.
>
> > So as you can see, I am trying to guess my way :-).
> > Not really know what I am doing but I think that is the best way to learn.
>
> That for sure. Good luck and keep me posted. :)
>
> Cheers,
> Ahmad
>
> >
> > Cheers,
> > Lior.
> >
> >> -----Original Message-----
> >> From: Ahmad Fatoum <a.fatoum@pengutronix.de>
> >> Sent: Thursday, September 7, 2023 11:33 AM
> >> To: Lior Weintraub <liorw@pliops.com>
> >> Cc: Ahmad Fatoum <ahmad@a3f.at>; barebox@lists.infradead.org
> >> Subject: Re: [PATCH v2] Porting barebox to a new SoC
> >>
> >> CAUTION: External Sender
> >>
> >> Hello Lior,
> >>
> >> On 22.08.23 10:48, Lior Weintraub wrote:
> >>> Thanks Ahmad, I Will try to post same question on Linux mailing list.
> >>
> >> I am curious to follow the discussion. Did you already post somewhere?
> >> I can't find a recent mail on lore.kernel.org.
> >>
> >> Feel free to Cc me when you post.
> >>
> >> Cheers,
> >> Ahmad
> >>
> >>>
> >>>> -----Original Message-----
> >>>> From: Ahmad Fatoum <a.fatoum@pengutronix.de>
> >>>> Sent: Tuesday, August 22, 2023 11:01 AM
> >>>> To: Lior Weintraub <liorw@pliops.com>
> >>>> Cc: Ahmad Fatoum <ahmad@a3f.at>; barebox@lists.infradead.org
> >>>> Subject: Re: [PATCH v2] Porting barebox to a new SoC
> >>>>
> >>>> CAUTION: External Sender
> >>>>
> >>>> Hello Lior,
> >>>>
> >>>> On 03.08.23 13:17, Lior Weintraub wrote:
> >>>>> Hi Ahmad,
> >>>>>
> >>>>> Hope you had a great time on EOSS 2023 :-)
> >>>>
> >>>> Thanks and sorry for the late answer.
> >>>>
> >>>>> Quick recap and additional info on the current issue:
> >>>>>
> >>>>> 1.
> >>>>> The spider-soc QEMU with the additional GICv3 and Timers was tested
> >> with
> >>>> a bare-metal code and proved to be OK.
> >>>>> This bare-metal code sets the A53 timers and GICv3 to handle interrupts
> >> on
> >>>> various execution levels as well as various security levels:
> >>>>> EL1_NS_PHYSICAL_TIMER set as GROUP1_NON_SECURE
> >>>>> EL1_SCR_PHYSICAL_TIMER set as GROUP1_SECURE
> >>>>> EL2_PHYSICAL_TIMER set as GROUP1_SECURE
> >>>>> VIRTUAL_TIMER set as GROUP1_NON_SECURE
> >>>>
> >>>> ok.
> >>>>
> >>>>> 2.
> >>>>> The kernel we build with Buildroot runs OK on virt QEMU but gets stuck
> in
> >>>> the middle when we use our spider-soc QEMU.
> >>>>> There are few differences between those runs:
> >>>>> a.
> >>>>> The virt QEMU is executed with -kernel switch and hence the QEMU
> itself
> >>>> implements the "bootloader" and prepares the DT given to the Kernel.
> >>>>> When the Kernel starts on this platforms it starts at EL1.
> >>>>
> >>>> This can be influenced e.g. on Virt with -M virt,virtualization=on, I think.
> >>>>
> >>>>> b.
> >>>>> The spider-soc QEMU is executed with -device loader,file=spider-soc-
> >> bl1.elf
> >>>>> Just for easy execution and testing, this executable includes all the
> needed
> >>>> binaries (as const data blobs) and it copies the binaries into correct
> >> locations
> >>>> before jumping to Barebox execution.
> >>>>> The list of binaries includes the barebox, kernel, dt, and rootfs.
> >>>>> As you recall, BL31 is compiled via Trusted-Firmware-A and has all it's
> >>>> functions as empty stubs because we currently don't care about CPU
> >> power
> >>>> states.
> >>>>> The prove that BL31 is executed correctly is that Barebox now runs at
> EL2.
> >>>>
> >>>> Good.
> >>>>
> >>>>> At that point the Linux kernel is starting and as I mentioned gets stuck in
> >> the
> >>>> middle (cpu_do_idle function. more details to follow).
> >>>>>
> >>>>> Debugging the kernel with GDB revealed few differences:
> >>>>> 1. When running with Barebox, the kernel starts at EL2 and at some
> point
> >>>> moves to EL1.
> >>>>> Not sure if that has some impact on the following issue but thought it is
> >>>> worth mentioning.
> >>>>> (We get a "CPU: All CPU(s) started at EL2" trace)
> >>>>
> >>>> I get the same on an i.MX8M as well (multi-core Cortex-A53 SoC).
> >>>>
> >>>>> Another difference that might be related to this execution level is that
> >> timers
> >>>> setting shows that it uses the physical timer (as oppose to virt QEMU run
> >> that
> >>>> uses the virtual timer):
> >>>>> The spider-soc QEMU Timers dump:
> >>>>> CNTFRQ_EL0 = 0x3b9aca0
> >>>>> CNTP_CTL_EL0 = 0x5
> >>>>> CNTV_CTL_EL0 = 0x0
> >>>>> CNTP_TVAL_EL0 = 0xff1f2ad5
> >>>>> CNTP_CVAL_EL0 = 0xac5c3240
> >>>>> CNTV_TVAL_EL0 = 0x52c2d916
> >>>>> CNTV_CVAL_EL0 = 0x0
> >>>>>
> >>>>> The virt QEMU Timers dump:
> >>>>> CNTFRQ_EL0 = 0x3b9aca0
> >>>>> CNTP_CTL_EL0 = 0x0
> >>>>> CNTV_CTL_EL0 = 0x5
> >>>>> CNTP_TVAL_EL0 = 0xb8394fbc
> >>>>> CNTP_CVAL_EL0 = 0x0
> >>>>> CNTV_TVAL_EL0 = 0xffd18e39
> >>>>> CNTV_CVAL_EL0 = 0x479858aa
> >>>>>
> >>>>> 2. When running with Barebox, the kernel fails to correctly set the GICv3
> >>>> registers.
> >>>>> So in other words, there are no timer events and hence the scheduler is
> >> not
> >>>> running.
> >>>>> The code get stuck on cpu_do_idle but we also found that the RCU
> cb_list
> >> is
> >>>> not empty (probably explains why scheduler haven't started (just a
> guess)).
> >>>>> We placed a breakpoint just before calling wait_for_completion (from
> >>>> function rcu_barrier on kernel/rcu/tree.c) and found:
> >>>>> bt
> >>>>> #0 rcu_barrier () at kernel/rcu/tree.c:4064
> >>>>> #1 0xffffffc08059e1b4 in mark_readonly () at init/main.c:1789
> >>>>> #2 kernel_init (unused=<optimized out>) at init/main.c:1838
> >>>>> #3 0xffffffc080015e48 in ret_from_fork () at
> >>>> arch/arm64/kernel/entry.S:853
> >>>>>
> >>>>> At that point rcu_state.barrier_cpu_count.counter is 1 (as oppose to
> virt
> >>>> QEMU where it is 0 at that point)
> >>>>> If we place the breakpoint a bit earlier in this rcu_barrier function (just
> >>>> before the for_each_possible_cpu loop) and run few more steps (to get
> the
> >>>> rdp) we see that rdp->cblist.len is 0x268 (616):
> >>>>> p/x rdp->cblist
> >>>>> $1 = {head = 0xffffffc0808f06d0, tails = {0xffffff802fe55a78,
> >>>> 0xffffff802fe55a78, 0xffffff802fe55a78, 0xffffff80001c22c8}, gp_seq =
> >> {0x0,
> >>>> 0x0, 0x0, 0x0}, len = 0x268, seglen = {0x0, 0x0, 0x0, 0x268}, flags = 0x1}
> >>>>>
> >>>>> When we compare that with virt QEMU we see that the rdp->cblist.len
> is 0
> >>>> there.
> >>>>>
> >>>>> IMHO, this all is a result of the GICv3 settings that were not applied
> >> properly.
> >>>>> As a result there are no timer interrupts.
> >>>>>
> >>>>> Further debugging on the GICv3 settings showed that the code
> (function
> >>>> gic_cpu_init on drivers/irqchip/irq-gic-v3.c) tries to write 0xffffffff to
> >>>> GICR_IGROUPR0 (Configure SGIs/PPIs as non-secure Group-1) but when
> >> we
> >>>> try to read it back we get all zeros.
> >>>>> Dumping GICv3 settings after the call to init_IRQ:
> >>>>> Showing only the differences:
> >>>>> Spider-SoC QEMU virt QEMU
> >>>>> GICD_CTLR = 0x00000012 0x00000053
> >>>>> GICD_TYPER = 0x037a0402 0x037a0007
> >>>>> GICR0_IGROUPR0 = 0x00000000 0xffffffff
> >>>>> GICR0_ISENABLER0 = 0x00000000 0x0000007f
> >>>>> GICR0_ICENABLER0 = 0x00000000 0x0000007f
> >>>>> GICR0_ICFGR0 = 0x00000000 0xaaaaaaaa
> >>>>>
> >>>>> Any thoughts?
> >>>>> As always, your support is much appreciated!
> >>>>
> >>>> Sorry to disappoint, but I have no hands-on experience with the GIC.
> >>>> My guess would be that you are missing initialization in the TF-A...
> >>>>
> >>>> Cheers,
> >>>> Ahmad
> >>>>
> >>>>>
> >>>>> Cheers,
> >>>>> Lior.
> >>>>>
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: Ahmad Fatoum <a.fatoum@pengutronix.de>
> >>>>>> Sent: Friday, June 30, 2023 8:53 AM
> >>>>>> To: Lior Weintraub <liorw@pliops.com>; Ahmad Fatoum
> >> <ahmad@a3f.at>;
> >>>>>> barebox@lists.infradead.org
> >>>>>> Subject: Re: [PATCH v2] Porting barebox to a new SoC
> >>>>>>
> >>>>>> CAUTION: External Sender
> >>>>>>
> >>>>>> Hi Lior,
> >>>>>>
> >>>>>> On 25.06.23 22:33, Lior Weintraub wrote:
> >>>>>>> Hello Ahmad,
> >>>>>>
> >>>>>> [Sorry for the delay, we're at EOSS 2023 currently]
> >>>>>>
> >>>>>>> I failed to reproduce this issue on virt because the addresses and
> >>>> peripherals
> >>>>>> on virt machine are different and it is difficult to change our code to
> >> match
> >>>>>> that.
> >>>>>>> If you think this is critical I will make extra effort to make it work.
> >>>>>>> AFAIU, this suggestion was made to debug the "conflict" issue.
> >>>>>>
> >>>>>> It's not critical, but I'd have liked to understand this, so I can check
> >>>>>> if it's perhaps a barebox bug.
> >>>>>>
> >>>>>>> Currently the workaround I am using is just to set the size of the
> kernel
> >>>>>> partition to match the exact size of the "Image" file.
> >>>>>>>
> >>>>>>> The other issue I am facing is that Kernel seems stuck on cpu_do_idle
> >> and
> >>>>>> there is no login prompt from the kernel.
> >>>>>>
> >>>>>> Does it call into PSCI during idle?
> >>>>>>
> >>>>>>> As you recall, I am running on a custom QEMU that tries to emulate
> our
> >>>>>> platform.
> >>>>>>> I suspect that I did something wrong with the GICv3 and Timers
> >>>> connectivity.
> >>>>>>> The code I used was based on examples I saw on sbsa-ref.c and virt.c.
> >>>>>>> In addition, I declared the GICv3 and timers on our device tree.
> >>>>>>>
> >>>>>>> I running QEMU with "-d int" so I am also getting trace of exceptions
> >> and
> >>>>>> interrupts.
> >>>>>>
> >>>>>> Nice. Didn't know about this option.
> >>>>>>
> >>>>>> [snip]
> >>>>>>
> >>>>>>> Exception return from AArch64 EL3 to AArch64 EL1 PC
> >>>> 0xffffffc00802112c
> >>>>>>> Taking exception 13 [Secure Monitor Call] on CPU 0
> >>>>>>> ...from EL1 to EL3
> >>>>>>> ...with ESR 0x17/0x5e000000
> >>>>>>> ...with ELR 0xffffffc008021640
> >>>>>>> ...to EL3 PC 0x10005400 PSTATE 0x3cd
> >>>>>>> Exception return from AArch64 EL3 to AArch64 EL1 PC
> >>>> 0xffffffc008021640
> >>>>>>
> >>>>>> Looks fine so far? Doesn't look like it's hanging in EL1.
> >>>>>>
> >>>>>> [snip]
> >>>>>>
> >>>>>>> Segment Routing with IPv6
> >>>>>>> In-situ OAM (IOAM) with IPv6
> >>>>>>> sit: IPv6, IPv4 and MPLS over IPv4 tunneling driver
> >>>>>>> NET: Registered PF_PACKET protocol family
> >>>>>>> NET: Registered PF_KEY protocol family
> >>>>>>> NET: Registered PF_VSOCK protocol family
> >>>>>>> registered taskstats version 1
> >>>>>>> clk: Disabling unused clocks
> >>>>>>> Freeing unused kernel memory: 1664K
> >>>>>>
> >>>>>> Not sure. Normally, I'd try again with pd_ignore_unused
> >> clk_ignore_unused
> >>>> in
> >>>>>> the
> >>>>>> kernel arguments, but I think you define no clocks or power domains
> yet
> >> in
> >>>>>> the DT?
> >>>>>>
> >>>>>> You can try again with kernel command line option initcall_debug and
> see
> >>>>>> what the
> >>>>>> initcall is that is getting stuck. If nothing helps, maybe attach a
> hardware
> >>>>>> debugger?
> >>>>>>
> >>>>>> Cheers,
> >>>>>> Ahmad
> >>>>>>
> >>>>>> --
> >>>>>> Pengutronix e.K. | |
> >>>>>> Steuerwalder Str. 21 | http://secure-
> >>>>
> web.cisco.com/1RKlXzLFuAdOeswlWvHRCbVHHvoQssFo7iVFqyvv8Yn0sP-
> >>>>
> >>
> MsWtfVRf2HW_4AXhQNuR5kNBuKLHNWkQfzg5qQhZ2AYhdNYqrfmNM7Isb
> >>>>
> >>
> bDhybYe7C21TIR6Du5pxC7TSTbhhg4oBK3J9y2XyMtJNhBKeliNv2I5G4mlnB_
> >>>> 57ph9x9tlPHstmZ8SL22VzM9RxLoj-5LddbVSsB69VGG-
> >>>> O3Hw57EyoSFWKWmjNjOHDmuU1R3SwOX2tkDMmiLPauqbBc-
> >>>> FP9cAFpclCgrOIJu2Jfef0-
> >>>> sVV346BmbxC1SOFAKCI/http%3A%2F%2Fwww.pengutronix.de%2F |
> >>>>>> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0
> |
> >>>>>> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-
> 5555
> >> |
> >>>>>
> >>>>
> >>>> --
> >>>> Pengutronix e.K. | |
> >>>> Steuerwalder Str. 21 | http://secure-
> >>>>
> web.cisco.com/1RKlXzLFuAdOeswlWvHRCbVHHvoQssFo7iVFqyvv8Yn0sP-
> >>>>
> >>
> MsWtfVRf2HW_4AXhQNuR5kNBuKLHNWkQfzg5qQhZ2AYhdNYqrfmNM7Isb
> >>>>
> >>
> bDhybYe7C21TIR6Du5pxC7TSTbhhg4oBK3J9y2XyMtJNhBKeliNv2I5G4mlnB_
> >>>> 57ph9x9tlPHstmZ8SL22VzM9RxLoj-5LddbVSsB69VGG-
> >>>> O3Hw57EyoSFWKWmjNjOHDmuU1R3SwOX2tkDMmiLPauqbBc-
> >>>> FP9cAFpclCgrOIJu2Jfef0-
> >>>> sVV346BmbxC1SOFAKCI/http%3A%2F%2Fwww.pengutronix.de%2F |
> >>>> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
> >>>> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555
> |
> >>>>
> >>>
> >>
> >> --
> >> Pengutronix e.K. | |
> >> Steuerwalder Str. 21 | http://secure-
> >>
> web.cisco.com/1O045o8i98buUBxhuX2t0uvDEzdfDsOOkHXvhw2zsg2diNV8f
> >> 8EZlM9mT9OrlFXuemhHKlD1F1skaFD_YT4n5EVauPPAxrSX4Pme-
> >>
> 1mIgrvUKeAVbZgzovldl0j6jKR2UYKcIgVEIcq1Jov13he3WdyUVs3XVXgcZUZM
> >> vdWOLX-
> >>
> voqQDAMDQcE6r2o_g4m7dbPaKNXliQFWT8yA6bGwtu8N2WM9GIADqK2Z_
> >>
> bICwvebcAHRze2ZNScbJ7p3i_8pZj05GbgDCoHNiHHXcOxapGVvFdPXldfl6Al_8
> >>
> XSVqUw5zEYqsyIn6t8meRIBU3_8e_/http%3A%2F%2Fwww.pengutronix.de
> >> %2F |
> >> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
> >> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
> >>
> >
>
> --
> Pengutronix e.K. | |
> Steuerwalder Str. 21 | http://secure-
> web.cisco.com/1afoFuFC3rpiLUQlbUrABGUc9nbtrJEQNAxBKml71H86dBKnb
> YKJO3jZccgayiJmX8aQx4TKbf_sgV4fViIXIr3lxe2jeWKr3cK7EIwIb2eHDv_hMwr
> f0Y3BW5NZTHxftUPSJGz5HN7kuASMWPuKjQrSe_qGFrhV_5nNC_2Nnp2CPK
> amM9K1N-
> YvvKcQq002UT10rL5x1wKosDOZjKM_N28w2ocRP5UpRV2339nJtan1G7k1n
> QWlfFFAgVp-
> asmqiZnMU0_E1rSBPIBT7N9fCtg5A7sHGln7Ux1Huxxdpb0ukPOZtiawk0bLLX
> Y5jRf40/http%3A%2F%2Fwww.pengutronix.de%2F |
> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
>
^ permalink raw reply [flat|nested] 40+ messages in thread
end of thread, other threads:[~2023-09-12 6:06 UTC | newest]
Thread overview: 40+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-05-28 13:04 Porting barebox to a new SoC Lior Weintraub
2023-05-28 15:35 ` Ahmad Fatoum
2023-05-28 15:37 ` [PATCH v2] " Ahmad Fatoum
2023-05-28 20:15 ` Lior Weintraub
2023-05-29 13:34 ` Lior Weintraub
2023-05-29 19:03 ` Ahmad Fatoum
2023-05-30 20:10 ` Lior Weintraub
2023-05-31 6:10 ` Ahmad Fatoum
2023-05-31 8:05 ` Lior Weintraub
2023-05-31 8:40 ` Ahmad Fatoum
2023-05-31 16:13 ` Lior Weintraub
2023-05-31 17:55 ` Ahmad Fatoum
2023-05-31 17:59 ` Ahmad Fatoum
2023-06-01 8:54 ` Lior Weintraub
2023-06-01 9:29 ` Ahmad Fatoum
2023-06-01 11:45 ` Lior Weintraub
2023-06-01 12:35 ` Ahmad Fatoum
2023-06-06 12:54 ` Lior Weintraub
2023-06-06 14:34 ` Ahmad Fatoum
2023-06-12 9:27 ` Lior Weintraub
2023-06-12 12:28 ` Ahmad Fatoum
2023-06-12 14:59 ` Lior Weintraub
2023-06-12 15:07 ` Ahmad Fatoum
2023-06-13 12:39 ` Lior Weintraub
2023-06-13 12:50 ` Ahmad Fatoum
2023-06-13 13:27 ` Lior Weintraub
2023-06-14 6:42 ` Lior Weintraub
2023-06-16 16:20 ` Ahmad Fatoum
2023-06-19 6:40 ` Lior Weintraub
2023-06-19 15:22 ` Ahmad Fatoum
2023-06-25 20:33 ` Lior Weintraub
2023-06-30 5:52 ` Ahmad Fatoum
2023-08-03 11:17 ` Lior Weintraub
2023-08-22 8:00 ` Ahmad Fatoum
2023-08-22 8:48 ` Lior Weintraub
2023-09-07 8:32 ` Ahmad Fatoum
2023-09-07 9:07 ` Lior Weintraub
2023-09-07 9:35 ` Ahmad Fatoum
2023-09-07 11:02 ` Lior Weintraub
2023-09-12 6:04 ` Lior Weintraub
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox