[PATCH v1 0/4] ARM: boards: add support for Samsung Galaxy S8 and S20 5G

[PATCH v1 0/4] ARM: boards: add support for Samsung Galaxy S8 and S20 5G

[Ivaylo Ivanov]

Hey folks,

This patchset focuses on adding support for S8 and S20. It's designed to allow
adding support for new exynos devices easy, with the primary differentiating
factor being the device tree. Currently, the same built barebox-exynos.img
can be booted on both S20 and S8 without any changes in the code, as it can
dynamically recognize what device it's booting on based on the tree provided
at x0 from the previous bootloader (s-boot).

On these devices, barebox will be used as a shim after the stock bootloader
(s-boot), replacing the linux kernel image in the boot.img.

Please read the patch commit messages, I've tried to describe everything
well enough. Thanks!

Best regards,
Ivaylo

Ivaylo Ivanov (4):
  video: simplefb-client: switch to dev_get_resource
  clocksource: arm_architected_timer: support clock-frequency
  ARM: boards: add support for Samsung Galaxy S8 (dreamlte)
  ARM: boards: add support for Samsung Galaxy S20 5G (x1s)

 arch/arm/Kconfig                            |  5 ++
 arch/arm/boards/Makefile                    |  1 +
 arch/arm/boards/samsung-exynos/Makefile     |  4 +
 arch/arm/boards/samsung-exynos/board.c      | 66 +++++++++++++++++
 arch/arm/boards/samsung-exynos/lowlevel.c   | 81 +++++++++++++++++++++
 arch/arm/dts/Makefile                       |  2 +
 arch/arm/dts/exynos8895-dreamlte.dts        | 13 ++++
 arch/arm/dts/exynos990-x1s.dts              | 13 ++++
 arch/arm/mach-samsung/Kconfig               | 13 ++++
 drivers/clocksource/arm_architected_timer.c | 11 ++-
 drivers/video/simplefb-client.c             |  5 +-
 images/Makefile                             |  1 +
 images/Makefile.exynos                      |  8 ++
 13 files changed, 219 insertions(+), 4 deletions(-)
 create mode 100644 arch/arm/boards/samsung-exynos/Makefile
 create mode 100644 arch/arm/boards/samsung-exynos/board.c
 create mode 100644 arch/arm/boards/samsung-exynos/lowlevel.c
 create mode 100644 arch/arm/dts/exynos8895-dreamlte.dts
 create mode 100644 arch/arm/dts/exynos990-x1s.dts
 create mode 100644 arch/arm/mach-samsung/Kconfig
 create mode 100644 images/Makefile.exynos

-- 
2.43.0

[PATCH v1 1/4] video: simplefb-client: switch to dev_get_resource

[Ivaylo Ivanov]

Since the framebuffer memory resource resides in ram, it has already
been requested and mapped, so only get the resource to avoid
requesting a busy resource. This is also the approach for linux.

While at it, use IOMEM for mem->start and drop an unnecessary newline.

Signed-off-by: Ivaylo Ivanov <ivo.ivanov.ivanov1@gmail.com>
---
 drivers/video/simplefb-client.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/video/simplefb-client.c b/drivers/video/simplefb-client.c
index dafec617..41ad8ffa 100644
--- a/drivers/video/simplefb-client.c
+++ b/drivers/video/simplefb-client.c
@@ -96,7 +96,7 @@ static int simplefb_probe(struct device *dev)
 	if (ret)
 		return ret;
 
-	mem = dev_request_mem_resource(dev, 0);
+	mem = dev_get_resource(dev, IORESOURCE_MEM, 0);
 	if (IS_ERR(mem)) {
 		dev_err(dev, "No memory resource\n");
 		return PTR_ERR(mem);
@@ -116,10 +116,9 @@ static int simplefb_probe(struct device *dev)
 	info->blue = params.format->blue;
 	info->transp = params.format->transp;
 
-	info->screen_base = (void *)mem->start;
+	info->screen_base = IOMEM(mem->start);
 	info->screen_size = resource_size(mem);
 
-
 	info->fbops = &simplefb_ops;
 
 	info->dev.parent = dev;
-- 
2.43.0

Re: [PATCH v1 1/4] video: simplefb-client: switch to dev_get_resource

[Ahmad Fatoum]

Hi Ivaylo,

thanks for your patch.

On 7/29/25 22:36, Ivaylo Ivanov wrote:
> Since the framebuffer memory resource resides in ram, it has already
> been requested and mapped, so only get the resource to avoid
> requesting a busy resource. This is also the approach for linux.

even if it's regular RAM (as opposed to video memory) we aren't
guaranteed, it's mapped suitably.

I think a remap of the region to writecombine is in order here. It
probably works right now, because we flush caches before shutting down
the MMU, but if you were to run fbtest, I'd expect that you will see
artifacts due to some pixels remaining in dirty cache line.

> While at it, use IOMEM for mem->start and drop an unnecessary newline.
> 
> Signed-off-by: Ivaylo Ivanov <ivo.ivanov.ivanov1@gmail.com>

Patch is correct, except for that aspect of the commit message:

Reviewed-by: Ahmad Fatoum <a.fatoum@pengutronix.de>

Thanks,
Ahmad

> ---
>  drivers/video/simplefb-client.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/video/simplefb-client.c b/drivers/video/simplefb-client.c
> index dafec617..41ad8ffa 100644
> --- a/drivers/video/simplefb-client.c
> +++ b/drivers/video/simplefb-client.c
> @@ -96,7 +96,7 @@ static int simplefb_probe(struct device *dev)
>  	if (ret)
>  		return ret;
>  
> -	mem = dev_request_mem_resource(dev, 0);
> +	mem = dev_get_resource(dev, IORESOURCE_MEM, 0);
>  	if (IS_ERR(mem)) {
>  		dev_err(dev, "No memory resource\n");
>  		return PTR_ERR(mem);
> @@ -116,10 +116,9 @@ static int simplefb_probe(struct device *dev)
>  	info->blue = params.format->blue;
>  	info->transp = params.format->transp;
>  
> -	info->screen_base = (void *)mem->start;
> +	info->screen_base = IOMEM(mem->start);
>  	info->screen_size = resource_size(mem);
>  
> -
>  	info->fbops = &simplefb_ops;
>  
>  	info->dev.parent = dev;

-- 
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 |

Re: [PATCH v1 1/4] video: simplefb-client: switch to dev_get_resource

[Ivaylo Ivanov]

On 7/30/25 11:11, Ahmad Fatoum wrote:
> Hi Ivaylo,
>
> thanks for your patch.
>
> On 7/29/25 22:36, Ivaylo Ivanov wrote:
>> Since the framebuffer memory resource resides in ram, it has already
>> been requested and mapped, so only get the resource to avoid
>> requesting a busy resource. This is also the approach for linux.
> even if it's regular RAM (as opposed to video memory) we aren't
> guaranteed, it's mapped suitably.

In my case at least, the mainline device tree covers all of dram -
(0x80000000 + n GB)

>
> I think a remap of the region to writecombine is in order here. It
> probably works right now, because we flush caches before shutting down
> the MMU, but if you were to run fbtest, I'd expect that you will see
> artifacts due to some pixels remaining in dirty cache line.

So you suggest remapping it, like ipufb for example?

    fbi->info.screen_base = dma_alloc_writecombine(DMA_DEVICE_BROKEN,
                           info->line_length * info->yres,
                           DMA_ADDRESS_BROKEN);
>
>> While at it, use IOMEM for mem->start and drop an unnecessary newline.
>>
>> Signed-off-by: Ivaylo Ivanov <ivo.ivanov.ivanov1@gmail.com>
> Patch is correct, except for that aspect of the commit message:

I don't get it, do I have to change the commit message only, or
code logic too?

Thanks and best regards,
Ivaylo

>
> Reviewed-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
>
> Thanks,
> Ahmad
>
>> ---
>>  drivers/video/simplefb-client.c | 5 ++---
>>  1 file changed, 2 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/video/simplefb-client.c b/drivers/video/simplefb-client.c
>> index dafec617..41ad8ffa 100644
>> --- a/drivers/video/simplefb-client.c
>> +++ b/drivers/video/simplefb-client.c
>> @@ -96,7 +96,7 @@ static int simplefb_probe(struct device *dev)
>>  	if (ret)
>>  		return ret;
>>  
>> -	mem = dev_request_mem_resource(dev, 0);
>> +	mem = dev_get_resource(dev, IORESOURCE_MEM, 0);
>>  	if (IS_ERR(mem)) {
>>  		dev_err(dev, "No memory resource\n");
>>  		return PTR_ERR(mem);
>> @@ -116,10 +116,9 @@ static int simplefb_probe(struct device *dev)
>>  	info->blue = params.format->blue;
>>  	info->transp = params.format->transp;
>>  
>> -	info->screen_base = (void *)mem->start;
>> +	info->screen_base = IOMEM(mem->start);
>>  	info->screen_size = resource_size(mem);
>>  
>> -
>>  	info->fbops = &simplefb_ops;
>>  
>>  	info->dev.parent = dev;

Re: [PATCH v1 1/4] video: simplefb-client: switch to dev_get_resource

[Ahmad Fatoum]

Hello Ivaylo,

On 7/30/25 13:28, Ivaylo Ivanov wrote:
> On 7/30/25 11:11, Ahmad Fatoum wrote:
>> Hi Ivaylo,
>>
>> thanks for your patch.
>>
>> On 7/29/25 22:36, Ivaylo Ivanov wrote:
>>> Since the framebuffer memory resource resides in ram, it has already
>>> been requested and mapped, so only get the resource to avoid
>>> requesting a busy resource. This is also the approach for linux.
>> even if it's regular RAM (as opposed to video memory) we aren't
>> guaranteed, it's mapped suitably.
> 
> In my case at least, the mainline device tree covers all of dram -
> (0x80000000 + n GB)
> 
>>
>> I think a remap of the region to writecombine is in order here. It
>> probably works right now, because we flush caches before shutting down
>> the MMU, but if you were to run fbtest, I'd expect that you will see
>> artifacts due to some pixels remaining in dirty cache line.
> 
> So you suggest remapping it, like ipufb for example?
> 
>     fbi->info.screen_base = dma_alloc_writecombine(DMA_DEVICE_BROKEN,
>                            info->line_length * info->yres,
>                            DMA_ADDRESS_BROKEN);

Except for dma_alloc_writecombine allocating a new buffer instead of
remapping an existing region. See the patch I just Cc'd you on.

>>> While at it, use IOMEM for mem->start and drop an unnecessary newline.
>>>
>>> Signed-off-by: Ivaylo Ivanov <ivo.ivanov.ivanov1@gmail.com>
>> Patch is correct, except for that aspect of the commit message:
> 
> I don't get it, do I have to change the commit message only, or
> code logic too?

Just correct the commit message: s/Since/If/.

The writecombine thing is a separate issue.

Cheers,
Ahmad

> 
> Thanks and best regards,
> Ivaylo
> 
>>
>> Reviewed-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
>>
>> Thanks,
>> Ahmad
>>
>>> ---
>>>  drivers/video/simplefb-client.c | 5 ++---
>>>  1 file changed, 2 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/video/simplefb-client.c b/drivers/video/simplefb-client.c
>>> index dafec617..41ad8ffa 100644
>>> --- a/drivers/video/simplefb-client.c
>>> +++ b/drivers/video/simplefb-client.c
>>> @@ -96,7 +96,7 @@ static int simplefb_probe(struct device *dev)
>>>  	if (ret)
>>>  		return ret;
>>>  
>>> -	mem = dev_request_mem_resource(dev, 0);
>>> +	mem = dev_get_resource(dev, IORESOURCE_MEM, 0);
>>>  	if (IS_ERR(mem)) {
>>>  		dev_err(dev, "No memory resource\n");
>>>  		return PTR_ERR(mem);
>>> @@ -116,10 +116,9 @@ static int simplefb_probe(struct device *dev)
>>>  	info->blue = params.format->blue;
>>>  	info->transp = params.format->transp;
>>>  
>>> -	info->screen_base = (void *)mem->start;
>>> +	info->screen_base = IOMEM(mem->start);
>>>  	info->screen_size = resource_size(mem);
>>>  
>>> -
>>>  	info->fbops = &simplefb_ops;
>>>  
>>>  	info->dev.parent = dev;
> 
> 

-- 
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 |

[PATCH v1 2/4] clocksource: arm_architected_timer: support clock-frequency

[Ivaylo Ivanov]

Some platforms, like the Samsung Galaxy S8, leave CNTFRQ_EL0 unset in
the previous stage bootloader. Therefore reading it causes a hang and
the boot proccess is halted.

Since on such retail devices there is no way to set it without replacing
the entire boot chain, allow setting a value from clock-frequency
whenever it's passed.

Signed-off-by: Ivaylo Ivanov <ivo.ivanov.ivanov1@gmail.com>
---
 drivers/clocksource/arm_architected_timer.c | 11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/clocksource/arm_architected_timer.c b/drivers/clocksource/arm_architected_timer.c
index 9a1f2d2b..daced94c 100644
--- a/drivers/clocksource/arm_architected_timer.c
+++ b/drivers/clocksource/arm_architected_timer.c
@@ -24,7 +24,16 @@ static struct clocksource cs = {
 
 static int arm_arch_timer_probe(struct device *dev)
 {
-	cs.mult = clocksource_hz2mult(get_cntfrq(), cs.shift);
+	u32 cntfrq;
+	int ret;
+
+	/* Some platforms don't set CNTFRQ_EL0 before barebox */
+	ret = of_property_read_u32(dev->of_node, "clock-frequency", &cntfrq);
+
+	if (ret)
+		cntfrq = get_cntfrq();
+
+	cs.mult = clocksource_hz2mult(cntfrq, cs.shift);
 
 	return init_clock(&cs);
 }
-- 
2.43.0

Re: [PATCH v1 2/4] clocksource: arm_architected_timer: support clock-frequency

[Ahmad Fatoum]

On 7/29/25 22:36, Ivaylo Ivanov wrote:
> Some platforms, like the Samsung Galaxy S8, leave CNTFRQ_EL0 unset in
> the previous stage bootloader. Therefore reading it causes a hang and
> the boot proccess is halted.
> 
> Since on such retail devices there is no way to set it without replacing
> the entire boot chain, allow setting a value from clock-frequency
> whenever it's passed.
> 
> Signed-off-by: Ivaylo Ivanov <ivo.ivanov.ivanov1@gmail.com>

Reviewed-by: Ahmad Fatoum <a.fatoum@pengutronix.de>

Linux does this too, so I think regressions are unlikely.

Cheers,
Ahmad

> ---
>  drivers/clocksource/arm_architected_timer.c | 11 ++++++++++-
>  1 file changed, 10 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/clocksource/arm_architected_timer.c b/drivers/clocksource/arm_architected_timer.c
> index 9a1f2d2b..daced94c 100644
> --- a/drivers/clocksource/arm_architected_timer.c
> +++ b/drivers/clocksource/arm_architected_timer.c
> @@ -24,7 +24,16 @@ static struct clocksource cs = {
>  
>  static int arm_arch_timer_probe(struct device *dev)
>  {
> -	cs.mult = clocksource_hz2mult(get_cntfrq(), cs.shift);
> +	u32 cntfrq;
> +	int ret;
> +
> +	/* Some platforms don't set CNTFRQ_EL0 before barebox */
> +	ret = of_property_read_u32(dev->of_node, "clock-frequency", &cntfrq);
> +
> +	if (ret)
> +		cntfrq = get_cntfrq();
> +
> +	cs.mult = clocksource_hz2mult(cntfrq, cs.shift);
>  
>  	return init_clock(&cs);
>  }

-- 
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 |

Re: (subset) [PATCH v1 2/4] clocksource: arm_architected_timer: support clock-frequency

[Sascha Hauer]

On Tue, 29 Jul 2025 23:36:57 +0300, Ivaylo Ivanov wrote:
> Some platforms, like the Samsung Galaxy S8, leave CNTFRQ_EL0 unset in
> the previous stage bootloader. Therefore reading it causes a hang and
> the boot proccess is halted.
> 
> Since on such retail devices there is no way to set it without replacing
> the entire boot chain, allow setting a value from clock-frequency
> whenever it's passed.
> 
> [...]

Applied, thanks!

[2/4] clocksource: arm_architected_timer: support clock-frequency
      https://git.pengutronix.de/cgit/barebox/commit/?id=fe12afd07328 (link may not be stable)

Best regards,
-- 
Sascha Hauer <s.hauer@pengutronix.de>

[PATCH v1 3/4] ARM: boards: add support for Samsung Galaxy S8 (dreamlte)

[Ivaylo Ivanov]

Phones utilizing an exynos SoC boot android with samsung's proprietary
bootloader, called s-boot (s-lk on newer devices). However, not only is
it closed source, it also enforces some limitations that prevent us from
booting mainline linux cleanly on them, such as an applied overlay device
tree, disabled framebuffer refreshing, misaligned kernel image at boot.
Therefore, having another stage bootloader, loaded as a linux kernel
image by s-boot, is best.

Add support for Samsung Galaxy S8, utilizing the exynos 8895 SoC. Support
is modelled to be as reusable on other devices as possible, requiring
only a minimal set of changes to boot - a barebox device tree, which in
this case is basically imported torvalds tree for dreamlte, that is then
matched from the downstream device tree, provided by s-boot at x0.

For some reason, on certain devices the stack set up by the previous
bootloader is not enough. Since the idea of this board support is to be
as generic as possible, setting a fixed stack top via
ENTRY_FUNCTION_WITHSTACK does not make sense, due to different exynos
devices having different memory layouts - exynos8895's dram starts at
0x80000000, whereas exynos7870's starts at 0x40000000. Instead, set the
SP as early as possible in the entry C function by taking the memory base
from the downstream fdt + (SZ_8M - SZ_64K).

Barebox has to be packaged as an android boot image:

mkbootimg --kernel images/barebox-exynos.img \
--ramdisk ramdisk.bin \
--dt stock.dtb
--cmdline "buildvariant=eng" \
--base 0x10000000 \
--kernel_offset 0x00008000 \
--ramdisk_offset 0x01000000 \
--second_offset 0x00f00000 \
--tags_offset 0x00000100 \
--os_version 9.0.0 \
--os_patch_level 2019-10 \
--pagesize 2048 \
--hash sha1 \
--output boot.img

And then flashed to the boot partition:

heimdall flash --BOOT boot.img

Currently, only a minimal set of features work. An image can be booted by
barebox by configuring barebox to jump to the address where ramdisk gets
loaded by s-boot, and packaging that payload as a ramdisk with mkbootimg.

Signed-off-by: Ivaylo Ivanov <ivo.ivanov.ivanov1@gmail.com>
---
 arch/arm/Kconfig                          |  5 ++
 arch/arm/boards/Makefile                  |  1 +
 arch/arm/boards/samsung-exynos/Makefile   |  4 ++
 arch/arm/boards/samsung-exynos/board.c    | 63 ++++++++++++++++++
 arch/arm/boards/samsung-exynos/lowlevel.c | 78 +++++++++++++++++++++++
 arch/arm/dts/Makefile                     |  1 +
 arch/arm/dts/exynos8895-dreamlte.dts      | 13 ++++
 arch/arm/mach-samsung/Kconfig             | 13 ++++
 images/Makefile                           |  1 +
 images/Makefile.exynos                    |  8 +++
 10 files changed, 187 insertions(+)
 create mode 100644 arch/arm/boards/samsung-exynos/Makefile
 create mode 100644 arch/arm/boards/samsung-exynos/board.c
 create mode 100644 arch/arm/boards/samsung-exynos/lowlevel.c
 create mode 100644 arch/arm/dts/exynos8895-dreamlte.dts
 create mode 100644 arch/arm/mach-samsung/Kconfig
 create mode 100644 images/Makefile.exynos

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 7a395270..095f189f 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -212,6 +212,10 @@ config ARCH_ROCKCHIP
 	select HAS_DEBUG_LL
 	imply GPIO_ROCKCHIP
 
+config ARCH_SAMSUNG
+	bool "ARM Exynos boards"
+	depends on ARCH_MULTIARCH
+
 config ARCH_STM32MP
 	bool "STMicroelectronics STM32MP"
 	depends on 32BIT
@@ -268,6 +272,7 @@ source "arch/arm/mach-k3/Kconfig"
 source "arch/arm/mach-omap/Kconfig"
 source "arch/arm/mach-pxa/Kconfig"
 source "arch/arm/mach-rockchip/Kconfig"
+source "arch/arm/mach-samsung/Kconfig"
 source "arch/arm/mach-socfpga/Kconfig"
 source "arch/arm/mach-sunxi/Kconfig"
 source "arch/arm/mach-stm32mp/Kconfig"
diff --git a/arch/arm/boards/Makefile b/arch/arm/boards/Makefile
index ac1fa74d..ff2efe04 100644
--- a/arch/arm/boards/Makefile
+++ b/arch/arm/boards/Makefile
@@ -30,6 +30,7 @@ obj-$(CONFIG_MACH_CHUMBY)			+= chumby_falconwing/
 obj-$(CONFIG_MACH_CLEP7212)			+= clep7212/
 obj-$(CONFIG_MACH_DFI_FS700_M60)		+= dfi-fs700-m60/
 obj-$(CONFIG_MACH_DIGI_CCIMX6ULSBCPRO)		+= digi-ccimx6ulsom/
+obj-$(CONFIG_MACH_EXYNOS)			+= samsung-exynos/
 obj-$(CONFIG_MACH_DUCKBILL)			+= duckbill/
 obj-$(CONFIG_MACH_DSS11)			+= dss11/
 obj-$(CONFIG_MACH_EFIKA_MX_SMARTBOOK)		+= efika-mx-smartbook/
diff --git a/arch/arm/boards/samsung-exynos/Makefile b/arch/arm/boards/samsung-exynos/Makefile
new file mode 100644
index 00000000..da63d262
--- /dev/null
+++ b/arch/arm/boards/samsung-exynos/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/samsung-exynos/board.c b/arch/arm/boards/samsung-exynos/board.c
new file mode 100644
index 00000000..25e4add6
--- /dev/null
+++ b/arch/arm/boards/samsung-exynos/board.c
@@ -0,0 +1,63 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright (C) 2025 Ivaylo Ivanov <ivo.ivanov.ivanov1@gmail.com>
+ */
+#include <common.h>
+#include <init.h>
+#include <of.h>
+#include <deep-probe.h>
+#include <asm/memory.h>
+#include <linux/sizes.h>
+#include <asm/system.h>
+#include <of_address.h>
+
+#define MACHINE "samsung-exynos"
+
+#define HW_SW_TRIG_CONTROL	0x70
+#define TRIG_AUTO_MASK_EN	BIT(12)
+#define SW_TRIG_EN		BIT(8)
+#define HW_TRIG_EN		BIT(0)
+
+static int exynos_postcore_init(void)
+{
+	void __iomem *decon0_base;
+
+	/*
+	 * Devices past galaxy S7 keep framebuffer refreshing disabled after
+	 * s-boot. Set the required bit so we can have output. This should
+	 * ideally be dropped from board files once we have a decon driver.
+	 */
+	if (of_machine_is_compatible("samsung,exynos8895"))
+		decon0_base = IOMEM(0x12860000);
+	else
+		return 0;
+
+	writel(TRIG_AUTO_MASK_EN | SW_TRIG_EN | HW_TRIG_EN,
+	       decon0_base + HW_SW_TRIG_CONTROL);
+
+	return 0;
+}
+coredevice_initcall(exynos_postcore_init);
+
+static inline int exynos_init(struct device *dev)
+{
+	barebox_set_model("ARM SAMSUNG " MACHINE);
+	barebox_set_hostname(MACHINE);
+
+	return 0;
+}
+
+static const struct of_device_id exynos_of_match[] = {
+	{ .compatible = "samsung,dreamlte" },
+	{ /* Sentinel */},
+};
+
+MODULE_DEVICE_TABLE(of, exynos_of_match);
+
+static struct driver exynos_board_driver = {
+	.name = "board-exynos",
+	.probe = exynos_init,
+	.of_compatible = exynos_of_match,
+};
+
+postcore_platform_driver(exynos_board_driver);
diff --git a/arch/arm/boards/samsung-exynos/lowlevel.c b/arch/arm/boards/samsung-exynos/lowlevel.c
new file mode 100644
index 00000000..9c4a0297
--- /dev/null
+++ b/arch/arm/boards/samsung-exynos/lowlevel.c
@@ -0,0 +1,78 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright (C) 2025 Ivaylo Ivanov <ivo.ivanov.ivanov1@gmail.com>
+ */
+#include <common.h>
+#include <pbl.h>
+#include <linux/sizes.h>
+#include <asm/barebox-arm-head.h>
+#include <asm/barebox-arm.h>
+#include <asm/sections.h>
+#include <asm/cache.h>
+#include <asm/mmu.h>
+
+extern char __dtb_exynos8895_dreamlte_start[];
+
+static bool is_compat(const void *fdt, const char *prefix)
+{
+	int node, len;
+	const char *compat;
+
+	node = fdt_path_offset(fdt, "/");
+	if (node < 0)
+		return false;
+
+	compat = fdt_getprop(fdt, node, "model", &len);
+	if (!compat)
+		return false;
+
+	while (*prefix) {
+		if (*compat++ != *prefix++)
+			return false;
+	}
+	return true;
+}
+
+static noinline void exynos_continue(void *downstream_fdt)
+{
+	void *fdt;
+	unsigned long membase, memsize;
+	char *__dtb_start;
+
+	/* select device tree dynamically */
+	if (is_compat(downstream_fdt, "Samsung DREAMLTE")) {
+		__dtb_start = __dtb_exynos8895_dreamlte_start;
+	} else {
+		/* we didn't match any device */
+		return;
+	}
+	fdt = __dtb_start + get_runtime_offset();
+	fdt_find_mem(fdt, &membase, &memsize);
+
+	barebox_arm_entry(membase, memsize, fdt);
+}
+
+ENTRY_FUNCTION(start_exynos, x0, x1, x2)
+{
+	void *downstream_fdt = (void *)x0;
+	unsigned long mem_base, mem_size;
+
+	if (!downstream_fdt || fdt_check_header(downstream_fdt))
+		return;
+
+	/*
+	 * The previous bootloader has a stack set up, but it seems to not be
+	 * enough as we can't get past the relocation on some devices. Set up
+	 * a stack determined by the memory node from the downstream fdt.
+	 */
+	fdt_find_mem(downstream_fdt, &mem_base, &mem_size);
+	asm volatile("mov sp, %0" : : "r"(mem_base + SZ_8M - SZ_64K));
+
+	arm_cpu_lowlevel_init();
+
+	relocate_to_current_adr();
+
+	setup_c();
+
+	exynos_continue(downstream_fdt);
+}
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 6612a514..a53834f7 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -13,6 +13,7 @@ lwl-$(CONFIG_MACH_BEAGLEPLAY) += k3-am625-beagleplay.dtb.o k3-am625-r5-beaglepla
 lwl-$(CONFIG_MACH_CLEP7212) += ep7212-clep7212.dtb.o
 lwl-$(CONFIG_MACH_CM_FX6) += imx6dl-cm-fx6.dtb.o imx6q-cm-fx6.dtb.o imx6q-utilite.dtb.o
 lwl-$(CONFIG_MACH_DFI_FS700_M60) += imx6q-dfi-fs700-m60-6q.dtb.o imx6dl-dfi-fs700-m60-6s.dtb.o
+lwl-$(CONFIG_MACH_EXYNOS) += exynos8895-dreamlte.dtb.o
 lwl-$(CONFIG_MACH_DUCKBILL) += imx28-duckbill.dtb.o
 lwl-$(CONFIG_MACH_KINDLE_MX50) += imx50-kindle-d01100.dtb.o imx50-kindle-d01200.dtb.o imx50-kindle-ey21.dtb.o
 lwl-$(CONFIG_MACH_EFIKA_MX_SMARTBOOK) += imx51-genesi-efika-sb.dtb.o
diff --git a/arch/arm/dts/exynos8895-dreamlte.dts b/arch/arm/dts/exynos8895-dreamlte.dts
new file mode 100644
index 00000000..36b5271e
--- /dev/null
+++ b/arch/arm/dts/exynos8895-dreamlte.dts
@@ -0,0 +1,13 @@
+// SPDX-License-Identifier: GPL-2.0 OR BSD-3-Clause
+/*
+ * Samsung Galaxy S8 (dreamlte/SM-G950F) barebox device tree source
+ *
+ * Copyright (c) 2025, Ivaylo Ivanov <ivo.ivanov.ivanov1@gmail.com>
+ */
+
+/dts-v1/;
+#include <arm64/exynos/exynos8895-dreamlte.dts>
+
+/ {
+	barebox,disable-deep-probe;
+};
diff --git a/arch/arm/mach-samsung/Kconfig b/arch/arm/mach-samsung/Kconfig
new file mode 100644
index 00000000..106a48a6
--- /dev/null
+++ b/arch/arm/mach-samsung/Kconfig
@@ -0,0 +1,13 @@
+# SPDX-License-Identifier: GPL-2.0-only
+
+if ARCH_SAMSUNG
+
+config MACH_EXYNOS
+	bool "Samsung Exynos boards support"
+	depends on 64BIT
+	select CPU_V8
+	select ARM_PSCI_CLIENT
+	select HW_HAS_PCI
+	select OF_OVERLAY
+
+endif
diff --git a/images/Makefile b/images/Makefile
index e20d11e1..4be5c3cd 100644
--- a/images/Makefile
+++ b/images/Makefile
@@ -176,6 +176,7 @@ include $(srctree)/images/Makefile.mvebu
 include $(srctree)/images/Makefile.mxs
 include $(srctree)/images/Makefile.omap3
 include $(srctree)/images/Makefile.rockchip
+include $(srctree)/images/Makefile.exynos
 include $(srctree)/images/Makefile.sandbox
 include $(srctree)/images/Makefile.socfpga
 include $(srctree)/images/Makefile.stm32mp
diff --git a/images/Makefile.exynos b/images/Makefile.exynos
new file mode 100644
index 00000000..3beb9107
--- /dev/null
+++ b/images/Makefile.exynos
@@ -0,0 +1,8 @@
+# SPDX-License-Identifier: GPL-2.0-only
+#
+# barebox image generation Makefile for exynos images
+#
+
+pblb-$(CONFIG_MACH_EXYNOS) += start_exynos
+FILE_barebox-exynos.img = start_exynos.pblb
+image-$(CONFIG_MACH_EXYNOS) += barebox-exynos.img
-- 
2.43.0

Re: [PATCH v1 3/4] ARM: boards: add support for Samsung Galaxy S8 (dreamlte)

[Ahmad Fatoum]

Hello Ivaylo,

Thanks for your patch.

On 7/29/25 22:36, Ivaylo Ivanov wrote:
> Phones utilizing an exynos SoC boot android with samsung's proprietary
> bootloader, called s-boot (s-lk on newer devices). However, not only is
> it closed source, it also enforces some limitations that prevent us from
> booting mainline linux cleanly on them, such as an applied overlay device
> tree, disabled framebuffer refreshing, misaligned kernel image at boot.

misaligned kernel image might be a bit problematic for barebox too, but
we can fix it for PBL if needed.

What misalignment are we speaking of?

> Therefore, having another stage bootloader, loaded as a linux kernel
> image by s-boot, is best.
> 
> Add support for Samsung Galaxy S8, utilizing the exynos 8895 SoC. Support
> is modelled to be as reusable on other devices as possible, requiring
> only a minimal set of changes to boot - a barebox device tree, which in
> this case is basically imported torvalds tree for dreamlte, that is then
> matched from the downstream device tree, provided by s-boot at x0.
> 
> For some reason, on certain devices the stack set up by the previous
> bootloader is not enough. Since the idea of this board support is to be
> as generic as possible, setting a fixed stack top via
> ENTRY_FUNCTION_WITHSTACK does not make sense, due to different exynos
> devices having different memory layouts - exynos8895's dram starts at
> 0x80000000, whereas exynos7870's starts at 0x40000000. Instead, set the
> SP as early as possible in the entry C function by taking the memory base
> from the downstream fdt + (SZ_8M - SZ_64K).

naked functions are not support on ARM64, so setting a stack pointer in
C code is always an unsafe operation that could mess up codegen.

If you need to do this dynamically, this needs to be done in assembly.

> Barebox has to be packaged as an android boot image:
> 
> mkbootimg --kernel images/barebox-exynos.img \
> --ramdisk ramdisk.bin \
> --dt stock.dtb
> --cmdline "buildvariant=eng" \
> --base 0x10000000 \
> --kernel_offset 0x00008000 \
> --ramdisk_offset 0x01000000 \
> --second_offset 0x00f00000 \
> --tags_offset 0x00000100 \
> --os_version 9.0.0 \
> --os_patch_level 2019-10 \
> --pagesize 2048 \
> --hash sha1 \
> --output boot.img
> 
> And then flashed to the boot partition:
> 
> heimdall flash --BOOT boot.img
> 
> Currently, only a minimal set of features work. An image can be booted by
> barebox by configuring barebox to jump to the address where ramdisk gets
> loaded by s-boot, and packaging that payload as a ramdisk with mkbootimg.

Nice. Would be good to have this info in Documentation/

> +postcore_platform_driver(exynos_board_driver);
> diff --git a/arch/arm/boards/samsung-exynos/lowlevel.c b/arch/arm/boards/samsung-exynos/lowlevel.c
> new file mode 100644
> index 00000000..9c4a0297
> --- /dev/null
> +++ b/arch/arm/boards/samsung-exynos/lowlevel.c
> @@ -0,0 +1,78 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Copyright (C) 2025 Ivaylo Ivanov <ivo.ivanov.ivanov1@gmail.com>
> + */
> +#include <common.h>
> +#include <pbl.h>
> +#include <linux/sizes.h>
> +#include <asm/barebox-arm-head.h>
> +#include <asm/barebox-arm.h>
> +#include <asm/sections.h>
> +#include <asm/cache.h>
> +#include <asm/mmu.h>
> +
> +extern char __dtb_exynos8895_dreamlte_start[];

As you don't need the DT in PBL, you can embed it in compress form by
using __dtb_z. This will be especially useful when we start to ship
multiple device trees.

> +
> +static bool is_compat(const void *fdt, const char *prefix)
> +{
> +	int node, len;
> +	const char *compat;
> +
> +	node = fdt_path_offset(fdt, "/");
> +	if (node < 0)
> +		return false;
> +
> +	compat = fdt_getprop(fdt, node, "model", &len);
> +	if (!compat)
> +		return false;

Why compare the model and not the compatible as the compat variable name
would suggest?

> +
> +	while (*prefix) {
> +		if (*compat++ != *prefix++)
> +			return false;
> +	}
> +	return true;
> +}
> +
> +static noinline void exynos_continue(void *downstream_fdt)
> +{
> +	void *fdt;
> +	unsigned long membase, memsize;
> +	char *__dtb_start;
> +
> +	/* select device tree dynamically */
> +	if (is_compat(downstream_fdt, "Samsung DREAMLTE")) {
> +		__dtb_start = __dtb_exynos8895_dreamlte_start;
> +	} else {
> +		/* we didn't match any device */
> +		return;
> +	}
> +	fdt = __dtb_start + get_runtime_offset();
> +	fdt_find_mem(fdt, &membase, &memsize);

Ah, so you do need the FDT in uncompressed form..

> +
> +	barebox_arm_entry(membase, memsize, fdt);
> +}
> +
> +ENTRY_FUNCTION(start_exynos, x0, x1, x2)
> +{
> +	void *downstream_fdt = (void *)x0;
> +	unsigned long mem_base, mem_size;
> +
> +	if (!downstream_fdt || fdt_check_header(downstream_fdt))
> +		return;
> +
> +	/*
> +	 * The previous bootloader has a stack set up, but it seems to not be
> +	 * enough as we can't get past the relocation on some devices. Set up
> +	 * a stack determined by the memory node from the downstream fdt.
> +	 */
> +	fdt_find_mem(downstream_fdt, &mem_base, &mem_size);

It's not a good idea to call this here before having set up the C
environment. This makes regressions after compile updates much more
likely. Can't we instead grow down from the start of the barebox binary?

That's what start_dt_2nd in board-dt-2nd-aarch64.S is doing.

In future, we should make it easier to reuse the dt-2nd entry pointer,
maybe with a macro that can be used instead of ENTRY_FUNCTION.

> +	asm volatile("mov sp, %0" : : "r"(mem_base + SZ_8M - SZ_64K));
> +
> +	arm_cpu_lowlevel_init();
> +
> +	relocate_to_current_adr();
> +
> +	setup_c();
> +
> +	exynos_continue(downstream_fdt);
> +}
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index 6612a514..a53834f7 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -13,6 +13,7 @@ lwl-$(CONFIG_MACH_BEAGLEPLAY) += k3-am625-beagleplay.dtb.o k3-am625-r5-beaglepla
>  lwl-$(CONFIG_MACH_CLEP7212) += ep7212-clep7212.dtb.o
>  lwl-$(CONFIG_MACH_CM_FX6) += imx6dl-cm-fx6.dtb.o imx6q-cm-fx6.dtb.o imx6q-utilite.dtb.o
>  lwl-$(CONFIG_MACH_DFI_FS700_M60) += imx6q-dfi-fs700-m60-6q.dtb.o imx6dl-dfi-fs700-m60-6s.dtb.o
> +lwl-$(CONFIG_MACH_EXYNOS) += exynos8895-dreamlte.dtb.o

It's on my todo list to add a way to specify device trees externally to
make. Still need to figure out how it will look like though.

>  lwl-$(CONFIG_MACH_DUCKBILL) += imx28-duckbill.dtb.o
>  lwl-$(CONFIG_MACH_KINDLE_MX50) += imx50-kindle-d01100.dtb.o imx50-kindle-d01200.dtb.o imx50-kindle-ey21.dtb.o
>  lwl-$(CONFIG_MACH_EFIKA_MX_SMARTBOOK) += imx51-genesi-efika-sb.dtb.o
> diff --git a/arch/arm/dts/exynos8895-dreamlte.dts b/arch/arm/dts/exynos8895-dreamlte.dts
> new file mode 100644
> index 00000000..36b5271e
> --- /dev/null
> +++ b/arch/arm/dts/exynos8895-dreamlte.dts
> @@ -0,0 +1,13 @@
> +// SPDX-License-Identifier: GPL-2.0 OR BSD-3-Clause
> +/*
> + * Samsung Galaxy S8 (dreamlte/SM-G950F) barebox device tree source
> + *
> + * Copyright (c) 2025, Ivaylo Ivanov <ivo.ivanov.ivanov1@gmail.com>
> + */
> +
> +/dts-v1/;
> +#include <arm64/exynos/exynos8895-dreamlte.dts>
> +
> +/ {
> +	barebox,disable-deep-probe;

Why not enable it?


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 |

Re: [PATCH v1 3/4] ARM: boards: add support for Samsung Galaxy S8 (dreamlte)

[Ivaylo Ivanov]

On 7/30/25 11:31, Ahmad Fatoum wrote:
> Hello Ivaylo,
>
> Thanks for your patch.
>
> On 7/29/25 22:36, Ivaylo Ivanov wrote:
>> Phones utilizing an exynos SoC boot android with samsung's proprietary
>> bootloader, called s-boot (s-lk on newer devices). However, not only is
>> it closed source, it also enforces some limitations that prevent us from
>> booting mainline linux cleanly on them, such as an applied overlay device
>> tree, disabled framebuffer refreshing, misaligned kernel image at boot.
> misaligned kernel image might be a bit problematic for barebox too, but
> we can fix it for PBL if needed.
>
> What misalignment are we speaking of?

On exynos 8890 up to exynos990, the bootloader takes a random number via
hwrng in a specific range after 80000000. If I recall correctly, when I was booting
mainline linux without any shim on my galaxy S8 (it was 5 years ago), the kernel
was complaining about misaligment, but I'd need to recreate that to be able
to provide logs. Anyways, I've tested barebox on 4 exynos devices and so far
there haven't been any inconsistencies at boot.

>
>> Therefore, having another stage bootloader, loaded as a linux kernel
>> image by s-boot, is best.
>>
>> Add support for Samsung Galaxy S8, utilizing the exynos 8895 SoC. Support
>> is modelled to be as reusable on other devices as possible, requiring
>> only a minimal set of changes to boot - a barebox device tree, which in
>> this case is basically imported torvalds tree for dreamlte, that is then
>> matched from the downstream device tree, provided by s-boot at x0.
>>
>> For some reason, on certain devices the stack set up by the previous
>> bootloader is not enough. Since the idea of this board support is to be
>> as generic as possible, setting a fixed stack top via
>> ENTRY_FUNCTION_WITHSTACK does not make sense, due to different exynos
>> devices having different memory layouts - exynos8895's dram starts at
>> 0x80000000, whereas exynos7870's starts at 0x40000000. Instead, set the
>> SP as early as possible in the entry C function by taking the memory base
>> from the downstream fdt + (SZ_8M - SZ_64K).
> naked functions are not support on ARM64, so setting a stack pointer in
> C code is always an unsafe operation that could mess up codegen.
>
> If you need to do this dynamically, this needs to be done in assembly.

hm, so I could just have a C entry that messes with fdt, and then jump to
the assembly function for SP relocation, after which we go back to C?

>
>> Barebox has to be packaged as an android boot image:
>>
>> mkbootimg --kernel images/barebox-exynos.img \
>> --ramdisk ramdisk.bin \
>> --dt stock.dtb
>> --cmdline "buildvariant=eng" \
>> --base 0x10000000 \
>> --kernel_offset 0x00008000 \
>> --ramdisk_offset 0x01000000 \
>> --second_offset 0x00f00000 \
>> --tags_offset 0x00000100 \
>> --os_version 9.0.0 \
>> --os_patch_level 2019-10 \
>> --pagesize 2048 \
>> --hash sha1 \
>> --output boot.img
>>
>> And then flashed to the boot partition:
>>
>> heimdall flash --BOOT boot.img
>>
>> Currently, only a minimal set of features work. An image can be booted by
>> barebox by configuring barebox to jump to the address where ramdisk gets
>> loaded by s-boot, and packaging that payload as a ramdisk with mkbootimg.
> Nice. Would be good to have this info in Documentation/

I was gonna do that in a separate patch after the patchset gets merged.

>
>> +postcore_platform_driver(exynos_board_driver);
>> diff --git a/arch/arm/boards/samsung-exynos/lowlevel.c b/arch/arm/boards/samsung-exynos/lowlevel.c
>> new file mode 100644
>> index 00000000..9c4a0297
>> --- /dev/null
>> +++ b/arch/arm/boards/samsung-exynos/lowlevel.c
>> @@ -0,0 +1,78 @@
>> +// SPDX-License-Identifier: GPL-2.0-or-later
>> +/*
>> + * Copyright (C) 2025 Ivaylo Ivanov <ivo.ivanov.ivanov1@gmail.com>
>> + */
>> +#include <common.h>
>> +#include <pbl.h>
>> +#include <linux/sizes.h>
>> +#include <asm/barebox-arm-head.h>
>> +#include <asm/barebox-arm.h>
>> +#include <asm/sections.h>
>> +#include <asm/cache.h>
>> +#include <asm/mmu.h>
>> +
>> +extern char __dtb_exynos8895_dreamlte_start[];
> As you don't need the DT in PBL, you can embed it in compress form by
> using __dtb_z. This will be especially useful when we start to ship
> multiple device trees.
>
>> +
>> +static bool is_compat(const void *fdt, const char *prefix)
>> +{
>> +	int node, len;
>> +	const char *compat;
>> +
>> +	node = fdt_path_offset(fdt, "/");
>> +	if (node < 0)
>> +		return false;
>> +
>> +	compat = fdt_getprop(fdt, node, "model", &len);
>> +	if (!compat)
>> +		return false;
> Why compare the model and not the compatible as the compat variable name
> would suggest?

Because Samsung are more consistent at coming up with model name
props than compatibles. For example:

compatible = "samsung,X1S EUR OPEN 05\0samsung,EXYNOS990";
compatible = "samsung, DREAMLTE KOR rev01", "samsung,EXYNOS8895";
compatible = "samsung, J7VE LTE LTN OPEN 00", "samsung,exynos7870";

there are inconsistencies in spacing, capitalizing etc etc. But yeah, I will
change the variable name to is_model.

>
>> +
>> +	while (*prefix) {
>> +		if (*compat++ != *prefix++)
>> +			return false;
>> +	}
>> +	return true;
>> +}
>> +
>> +static noinline void exynos_continue(void *downstream_fdt)
>> +{
>> +	void *fdt;
>> +	unsigned long membase, memsize;
>> +	char *__dtb_start;
>> +
>> +	/* select device tree dynamically */
>> +	if (is_compat(downstream_fdt, "Samsung DREAMLTE")) {
>> +		__dtb_start = __dtb_exynos8895_dreamlte_start;
>> +	} else {
>> +		/* we didn't match any device */
>> +		return;
>> +	}
>> +	fdt = __dtb_start + get_runtime_offset();
>> +	fdt_find_mem(fdt, &membase, &memsize);
> Ah, so you do need the FDT in uncompressed form..

Mhm. I tried taking mem from downstream DT, but it's so broken it
doesn't work.

>
>> +
>> +	barebox_arm_entry(membase, memsize, fdt);
>> +}
>> +
>> +ENTRY_FUNCTION(start_exynos, x0, x1, x2)
>> +{
>> +	void *downstream_fdt = (void *)x0;
>> +	unsigned long mem_base, mem_size;
>> +
>> +	if (!downstream_fdt || fdt_check_header(downstream_fdt))
>> +		return;
>> +
>> +	/*
>> +	 * The previous bootloader has a stack set up, but it seems to not be
>> +	 * enough as we can't get past the relocation on some devices. Set up
>> +	 * a stack determined by the memory node from the downstream fdt.
>> +	 */
>> +	fdt_find_mem(downstream_fdt, &mem_base, &mem_size);
> It's not a good idea to call this here before having set up the C
> environment. This makes regressions after compile updates much more
> likely. Can't we instead grow down from the start of the barebox binary?
>
> That's what start_dt_2nd in board-dt-2nd-aarch64.S is doing.

iirc this is not my first attempt at barebox, I had some work a few months ago,
and the board-dt-2nd wasn't booting. I suppose it's the SP stuff that was borked.
I will test it again though and report back.

>
> In future, we should make it easier to reuse the dt-2nd entry pointer,
> maybe with a macro that can be used instead of ENTRY_FUNCTION.
>
>> +	asm volatile("mov sp, %0" : : "r"(mem_base + SZ_8M - SZ_64K));
>> +
>> +	arm_cpu_lowlevel_init();
>> +
>> +	relocate_to_current_adr();
>> +
>> +	setup_c();
>> +
>> +	exynos_continue(downstream_fdt);
>> +}
>> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
>> index 6612a514..a53834f7 100644
>> --- a/arch/arm/dts/Makefile
>> +++ b/arch/arm/dts/Makefile
>> @@ -13,6 +13,7 @@ lwl-$(CONFIG_MACH_BEAGLEPLAY) += k3-am625-beagleplay.dtb.o k3-am625-r5-beaglepla
>>  lwl-$(CONFIG_MACH_CLEP7212) += ep7212-clep7212.dtb.o
>>  lwl-$(CONFIG_MACH_CM_FX6) += imx6dl-cm-fx6.dtb.o imx6q-cm-fx6.dtb.o imx6q-utilite.dtb.o
>>  lwl-$(CONFIG_MACH_DFI_FS700_M60) += imx6q-dfi-fs700-m60-6q.dtb.o imx6dl-dfi-fs700-m60-6s.dtb.o
>> +lwl-$(CONFIG_MACH_EXYNOS) += exynos8895-dreamlte.dtb.o
> It's on my todo list to add a way to specify device trees externally to
> make. Still need to figure out how it will look like though.

Yeah, I was thinking that it'd be nice to just compile it directly from
dts/src/.

>
>>  lwl-$(CONFIG_MACH_DUCKBILL) += imx28-duckbill.dtb.o
>>  lwl-$(CONFIG_MACH_KINDLE_MX50) += imx50-kindle-d01100.dtb.o imx50-kindle-d01200.dtb.o imx50-kindle-ey21.dtb.o
>>  lwl-$(CONFIG_MACH_EFIKA_MX_SMARTBOOK) += imx51-genesi-efika-sb.dtb.o
>> diff --git a/arch/arm/dts/exynos8895-dreamlte.dts b/arch/arm/dts/exynos8895-dreamlte.dts
>> new file mode 100644
>> index 00000000..36b5271e
>> --- /dev/null
>> +++ b/arch/arm/dts/exynos8895-dreamlte.dts
>> @@ -0,0 +1,13 @@
>> +// SPDX-License-Identifier: GPL-2.0 OR BSD-3-Clause
>> +/*
>> + * Samsung Galaxy S8 (dreamlte/SM-G950F) barebox device tree source
>> + *
>> + * Copyright (c) 2025, Ivaylo Ivanov <ivo.ivanov.ivanov1@gmail.com>
>> + */
>> +
>> +/dts-v1/;
>> +#include <arm64/exynos/exynos8895-dreamlte.dts>
>> +
>> +/ {
>> +	barebox,disable-deep-probe;
> Why not enable it?

Honestly, I other devices doing that and didn't dig too deep into what
it's meant for. Will test.

Thanks and best regards,
Ivaylo

>
>
> Cheers,
> Ahmad
>

Re: [PATCH v1 3/4] ARM: boards: add support for Samsung Galaxy S8 (dreamlte)

[Ahmad Fatoum]

Hi Ivaylo,

On 7/30/25 11:09, Ivaylo Ivanov wrote:
> On 7/30/25 11:31, Ahmad Fatoum wrote:
>> Hello Ivaylo,
>>
>> Thanks for your patch.
>>
>> On 7/29/25 22:36, Ivaylo Ivanov wrote:
>>> Phones utilizing an exynos SoC boot android with samsung's proprietary
>>> bootloader, called s-boot (s-lk on newer devices). However, not only is
>>> it closed source, it also enforces some limitations that prevent us from
>>> booting mainline linux cleanly on them, such as an applied overlay device
>>> tree, disabled framebuffer refreshing, misaligned kernel image at boot.
>> misaligned kernel image might be a bit problematic for barebox too, but
>> we can fix it for PBL if needed.
>>
>> What misalignment are we speaking of?
> 
> On exynos 8890 up to exynos990, the bootloader takes a random number via
> hwrng in a specific range after 80000000. If I recall correctly, when I was booting
> mainline linux without any shim on my galaxy S8 (it was 5 years ago), the kernel
> was complaining about misaligment, but I'd need to recreate that to be able
> to provide logs. Anyways, I've tested barebox on 4 exynos devices and so far
> there haven't been any inconsistencies at boot.

While barebox is relocatable, we link it as if it would be running from
address 0. This has the side effect that adrp instructions are emitted
that assume implicitly that barebox starts at a 4K-aligned address,
because well, 0, is 4K-aligned.

If this proves problematic, we can try to eliminate the generation of
adrp instruction. Did you experience kernel/bootloader being loaded to
an address that's not 4K-aligned?

>>> Therefore, having another stage bootloader, loaded as a linux kernel
>>> image by s-boot, is best.
>>>
>>> Add support for Samsung Galaxy S8, utilizing the exynos 8895 SoC. Support
>>> is modelled to be as reusable on other devices as possible, requiring
>>> only a minimal set of changes to boot - a barebox device tree, which in
>>> this case is basically imported torvalds tree for dreamlte, that is then
>>> matched from the downstream device tree, provided by s-boot at x0.
>>>
>>> For some reason, on certain devices the stack set up by the previous
>>> bootloader is not enough. Since the idea of this board support is to be
>>> as generic as possible, setting a fixed stack top via
>>> ENTRY_FUNCTION_WITHSTACK does not make sense, due to different exynos
>>> devices having different memory layouts - exynos8895's dram starts at
>>> 0x80000000, whereas exynos7870's starts at 0x40000000. Instead, set the
>>> SP as early as possible in the entry C function by taking the memory base
>>> from the downstream fdt + (SZ_8M - SZ_64K).
>> naked functions are not support on ARM64, so setting a stack pointer in
>> C code is always an unsafe operation that could mess up codegen.
>>
>> If you need to do this dynamically, this needs to be done in assembly.
> 
> hm, so I could just have a C entry that messes with fdt, and then jump to
> the assembly function for SP relocation, after which we go back to C?

Yes. See __barebox_arm_entry, which does this generically for all boards.

>>> Currently, only a minimal set of features work. An image can be booted by
>>> barebox by configuring barebox to jump to the address where ramdisk gets
>>> loaded by s-boot, and packaging that payload as a ramdisk with mkbootimg.
>> Nice. Would be good to have this info in Documentation/
> 
> I was gonna do that in a separate patch after the patchset gets merged.

Great.

>>> +	compat = fdt_getprop(fdt, node, "model", &len);
>>> +	if (!compat)
>>> +		return false;
>> Why compare the model and not the compatible as the compat variable name
>> would suggest?
> 
> Because Samsung are more consistent at coming up with model name
> props than compatibles. For example:
> 
> compatible = "samsung,X1S EUR OPEN 05\0samsung,EXYNOS990";
> compatible = "samsung, DREAMLTE KOR rev01", "samsung,EXYNOS8895";
> compatible = "samsung, J7VE LTE LTN OPEN 00", "samsung,exynos7870";
> 
> there are inconsistencies in spacing, capitalizing etc etc. But yeah, I will
> change the variable name to is_model.

Sounds good. Can you add a comment that compatibles are inconsistent?
maybe with an example.

>>> +static noinline void exynos_continue(void *downstream_fdt)
>>> +{
>>> +	void *fdt;
>>> +	unsigned long membase, memsize;
>>> +	char *__dtb_start;
>>> +
>>> +	/* select device tree dynamically */
>>> +	if (is_compat(downstream_fdt, "Samsung DREAMLTE")) {
>>> +		__dtb_start = __dtb_exynos8895_dreamlte_start;
>>> +	} else {
>>> +		/* we didn't match any device */
>>> +		return;
>>> +	}
>>> +	fdt = __dtb_start + get_runtime_offset();
>>> +	fdt_find_mem(fdt, &membase, &memsize);
>> Ah, so you do need the FDT in uncompressed form..
> 
> Mhm. I tried taking mem from downstream DT, but it's so broken it
> doesn't work.

That's a shame.

>>> +	/*
>>> +	 * The previous bootloader has a stack set up, but it seems to not be
>>> +	 * enough as we can't get past the relocation on some devices. Set up
>>> +	 * a stack determined by the memory node from the downstream fdt.
>>> +	 */
>>> +	fdt_find_mem(downstream_fdt, &mem_base, &mem_size);
>> It's not a good idea to call this here before having set up the C
>> environment. This makes regressions after compile updates much more
>> likely. Can't we instead grow down from the start of the barebox binary?
>>
>> That's what start_dt_2nd in board-dt-2nd-aarch64.S is doing.
> 
> iirc this is not my first attempt at barebox, I had some work a few months ago,
> and the board-dt-2nd wasn't booting. I suppose it's the SP stuff that was borked.
> I will test it again though and report back.

Thanks. Two things come to mind that might be worth exploring:

- increment the stack pointer: We are not going to return from the
barebox entry point, so we do not care if we overwrite old stack frames.
Just aligning the stack to the next 4K for example might already be
enough that you could call relocate_to_current_adr(); setup_c(); right
away without first parsing the device tree

- enable CONFIG_PBL_FULLY_PIC: This is still a bit experimental, but it
eliminates a lot of relocation entries that are avoidable. It should be
the default eventually. If aligning the stack is no option and you need
to parse the DT before calling relocate_to_current_adr(), PBL_FULLY_PIC
should help with reducing the chance of problems...

>>> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
>>> index 6612a514..a53834f7 100644
>>> --- a/arch/arm/dts/Makefile
>>> +++ b/arch/arm/dts/Makefile
>>> @@ -13,6 +13,7 @@ lwl-$(CONFIG_MACH_BEAGLEPLAY) += k3-am625-beagleplay.dtb.o k3-am625-r5-beaglepla
>>>  lwl-$(CONFIG_MACH_CLEP7212) += ep7212-clep7212.dtb.o
>>>  lwl-$(CONFIG_MACH_CM_FX6) += imx6dl-cm-fx6.dtb.o imx6q-cm-fx6.dtb.o imx6q-utilite.dtb.o
>>>  lwl-$(CONFIG_MACH_DFI_FS700_M60) += imx6q-dfi-fs700-m60-6q.dtb.o imx6dl-dfi-fs700-m60-6s.dtb.o
>>> +lwl-$(CONFIG_MACH_EXYNOS) += exynos8895-dreamlte.dtb.o
>> It's on my todo list to add a way to specify device trees externally to
>> make. Still need to figure out how it will look like though.
> 
> Yeah, I was thinking that it'd be nice to just compile it directly from
> dts/src/.

Ye, we'll have to think about how the X DTs that are built this way and
bundled into barebox will be selected. The easy way would be just
including them all into the existing barebox-2nd.fit and have the
previous stage bootloader select the correct one, but in your case we
would need custom logic somehow.

>>> +/ {
>>> +	barebox,disable-deep-probe;
>> Why not enable it?
> 
> Honestly, I other devices doing that and didn't dig too deep into what
> it's meant for. Will test.

Deep probe means that barebox will recursively probe resources as needed
instead of returning -EPROBE_DEFER. This can break old board code or
buggy drivers, so it's disabled for a number of boards in-tree.

I don't assume you'll run into issues with your new subarch here, so you
can just enable it unconditionally.

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 |

Re: [PATCH v1 3/4] ARM: boards: add support for Samsung Galaxy S8 (dreamlte)

[Ivaylo Ivanov]

On 7/30/25 12:33, Ahmad Fatoum wrote:
> Hi Ivaylo,
>
> On 7/30/25 11:09, Ivaylo Ivanov wrote:
>> On 7/30/25 11:31, Ahmad Fatoum wrote:
>>> Hello Ivaylo,
>>>
>>> Thanks for your patch.
>>>
>>> On 7/29/25 22:36, Ivaylo Ivanov wrote:
>>>> Phones utilizing an exynos SoC boot android with samsung's proprietary
>>>> bootloader, called s-boot (s-lk on newer devices). However, not only is
>>>> it closed source, it also enforces some limitations that prevent us from
>>>> booting mainline linux cleanly on them, such as an applied overlay device
>>>> tree, disabled framebuffer refreshing, misaligned kernel image at boot.
>>> misaligned kernel image might be a bit problematic for barebox too, but
>>> we can fix it for PBL if needed.
>>>
>>> What misalignment are we speaking of?
>> On exynos 8890 up to exynos990, the bootloader takes a random number via
>> hwrng in a specific range after 80000000. If I recall correctly, when I was booting
>> mainline linux without any shim on my galaxy S8 (it was 5 years ago), the kernel
>> was complaining about misaligment, but I'd need to recreate that to be able
>> to provide logs. Anyways, I've tested barebox on 4 exynos devices and so far
>> there haven't been any inconsistencies at boot.
> While barebox is relocatable, we link it as if it would be running from
> address 0. This has the side effect that adrp instructions are emitted
> that assume implicitly that barebox starts at a 4K-aligned address,
> because well, 0, is 4K-aligned.
>
> If this proves problematic, we can try to eliminate the generation of
> adrp instruction. Did you experience kernel/bootloader being loaded to
> an address that's not 4K-aligned?

Nope, I think it's always 4k-aligned at least. We've been booting mainline linux
using our own bootloader shim implementation (github.com/ivoszbg/uniLoader),
and this hasn't been an issue.

>
>>>> Therefore, having another stage bootloader, loaded as a linux kernel
>>>> image by s-boot, is best.
>>>>
>>>> Add support for Samsung Galaxy S8, utilizing the exynos 8895 SoC. Support
>>>> is modelled to be as reusable on other devices as possible, requiring
>>>> only a minimal set of changes to boot - a barebox device tree, which in
>>>> this case is basically imported torvalds tree for dreamlte, that is then
>>>> matched from the downstream device tree, provided by s-boot at x0.
>>>>
>>>> For some reason, on certain devices the stack set up by the previous
>>>> bootloader is not enough. Since the idea of this board support is to be
>>>> as generic as possible, setting a fixed stack top via
>>>> ENTRY_FUNCTION_WITHSTACK does not make sense, due to different exynos
>>>> devices having different memory layouts - exynos8895's dram starts at
>>>> 0x80000000, whereas exynos7870's starts at 0x40000000. Instead, set the
>>>> SP as early as possible in the entry C function by taking the memory base
>>>> from the downstream fdt + (SZ_8M - SZ_64K).
>>> naked functions are not support on ARM64, so setting a stack pointer in
>>> C code is always an unsafe operation that could mess up codegen.
>>>
>>> If you need to do this dynamically, this needs to be done in assembly.
>> hm, so I could just have a C entry that messes with fdt, and then jump to
>> the assembly function for SP relocation, after which we go back to C?
> Yes. See __barebox_arm_entry, which does this generically for all boards.
>
>>>> Currently, only a minimal set of features work. An image can be booted by
>>>> barebox by configuring barebox to jump to the address where ramdisk gets
>>>> loaded by s-boot, and packaging that payload as a ramdisk with mkbootimg.
>>> Nice. Would be good to have this info in Documentation/
>> I was gonna do that in a separate patch after the patchset gets merged.
> Great.
>
>>>> +	compat = fdt_getprop(fdt, node, "model", &len);
>>>> +	if (!compat)
>>>> +		return false;
>>> Why compare the model and not the compatible as the compat variable name
>>> would suggest?
>> Because Samsung are more consistent at coming up with model name
>> props than compatibles. For example:
>>
>> compatible = "samsung,X1S EUR OPEN 05\0samsung,EXYNOS990";
>> compatible = "samsung, DREAMLTE KOR rev01", "samsung,EXYNOS8895";
>> compatible = "samsung, J7VE LTE LTN OPEN 00", "samsung,exynos7870";
>>
>> there are inconsistencies in spacing, capitalizing etc etc. But yeah, I will
>> change the variable name to is_model.
> Sounds good. Can you add a comment that compatibles are inconsistent?
> maybe with an example.

Okay.

>
>>>> +static noinline void exynos_continue(void *downstream_fdt)
>>>> +{
>>>> +	void *fdt;
>>>> +	unsigned long membase, memsize;
>>>> +	char *__dtb_start;
>>>> +
>>>> +	/* select device tree dynamically */
>>>> +	if (is_compat(downstream_fdt, "Samsung DREAMLTE")) {
>>>> +		__dtb_start = __dtb_exynos8895_dreamlte_start;
>>>> +	} else {
>>>> +		/* we didn't match any device */
>>>> +		return;
>>>> +	}
>>>> +	fdt = __dtb_start + get_runtime_offset();
>>>> +	fdt_find_mem(fdt, &membase, &memsize);
>>> Ah, so you do need the FDT in uncompressed form..
>> Mhm. I tried taking mem from downstream DT, but it's so broken it
>> doesn't work.
> That's a shame.
>
>>>> +	/*
>>>> +	 * The previous bootloader has a stack set up, but it seems to not be
>>>> +	 * enough as we can't get past the relocation on some devices. Set up
>>>> +	 * a stack determined by the memory node from the downstream fdt.
>>>> +	 */
>>>> +	fdt_find_mem(downstream_fdt, &mem_base, &mem_size);
>>> It's not a good idea to call this here before having set up the C
>>> environment. This makes regressions after compile updates much more
>>> likely. Can't we instead grow down from the start of the barebox binary?
>>>
>>> That's what start_dt_2nd in board-dt-2nd-aarch64.S is doing.
>> iirc this is not my first attempt at barebox, I had some work a few months ago,
>> and the board-dt-2nd wasn't booting. I suppose it's the SP stuff that was borked.
>> I will test it again though and report back.
> Thanks. Two things come to mind that might be worth exploring:
>
> - increment the stack pointer: We are not going to return from the
> barebox entry point, so we do not care if we overwrite old stack frames.
> Just aligning the stack to the next 4K for example might already be
> enough that you could call relocate_to_current_adr(); setup_c(); right
> away without first parsing the device tree
>
> - enable CONFIG_PBL_FULLY_PIC: This is still a bit experimental, but it
> eliminates a lot of relocation entries that are avoidable. It should be
> the default eventually. If aligning the stack is no option and you need
> to parse the DT before calling relocate_to_current_adr(), PBL_FULLY_PIC
> should help with reducing the chance of problems...

I tested the board-dt-2nd-aarch64.S logic and it works. I'll add an
entry.S with it for v2, but stripped out of the efi header stuff.

>
>>>> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
>>>> index 6612a514..a53834f7 100644
>>>> --- a/arch/arm/dts/Makefile
>>>> +++ b/arch/arm/dts/Makefile
>>>> @@ -13,6 +13,7 @@ lwl-$(CONFIG_MACH_BEAGLEPLAY) += k3-am625-beagleplay.dtb.o k3-am625-r5-beaglepla
>>>>  lwl-$(CONFIG_MACH_CLEP7212) += ep7212-clep7212.dtb.o
>>>>  lwl-$(CONFIG_MACH_CM_FX6) += imx6dl-cm-fx6.dtb.o imx6q-cm-fx6.dtb.o imx6q-utilite.dtb.o
>>>>  lwl-$(CONFIG_MACH_DFI_FS700_M60) += imx6q-dfi-fs700-m60-6q.dtb.o imx6dl-dfi-fs700-m60-6s.dtb.o
>>>> +lwl-$(CONFIG_MACH_EXYNOS) += exynos8895-dreamlte.dtb.o
>>> It's on my todo list to add a way to specify device trees externally to
>>> make. Still need to figure out how it will look like though.
>> Yeah, I was thinking that it'd be nice to just compile it directly from
>> dts/src/.
> Ye, we'll have to think about how the X DTs that are built this way and
> bundled into barebox will be selected. The easy way would be just
> including them all into the existing barebox-2nd.fit and have the
> previous stage bootloader select the correct one, but in your case we
> would need custom logic somehow.
>
>>>> +/ {
>>>> +	barebox,disable-deep-probe;
>>> Why not enable it?
>> Honestly, I other devices doing that and didn't dig too deep into what
>> it's meant for. Will test.
> Deep probe means that barebox will recursively probe resources as needed
> instead of returning -EPROBE_DEFER. This can break old board code or
> buggy drivers, so it's disabled for a number of boards in-tree.
>
> I don't assume you'll run into issues with your new subarch here, so you
> can just enable it unconditionally.

I see. Thanks!

Best regards,
Ivaylo

>
> Cheers,
> Ahmad
>

[PATCH v1 4/4] ARM: boards: add support for Samsung Galaxy S20 5G (x1s)

[Ivaylo Ivanov]

Add support for Samsung Galaxy S20 5G, based on exynos990, to the
current samsung board support. This platform, just like exynos8895,
needs a bit to be set in order to allow the framebuffer to refresh.

Barebox has to be packaged as an android boot image:

mkbootimg --kernel images/barebox-exynos.img \
--ramdisk ramdisk.bin \
--dt stock.dtb
--cmdline "buildvariant=eng" \
--base 0x10000000 \
--kernel_offset 0x00008000 \
--ramdisk_offset 0x01000000 \
--second_offset 0x00f00000 \
--tags_offset 0x00000100 \
--os_version 9.0.0 \
--os_patch_level 2019-10 \
--pagesize 2048 \
--hash sha1 \
--output boot.img

And then flashed to the boot partition:

heimdall flash --BOOT boot.img

Currently, only a minimal set of features work. An image can be booted by
barebox by configuring barebox to jump to the address where ramdisk gets
loaded by s-boot, and packaging that payload as a ramdisk with mkbootimg.

Signed-off-by: Ivaylo Ivanov <ivo.ivanov.ivanov1@gmail.com>
Tested-by: Umer Uddin <umer.uddin@mentallysanemainliners.org>

---
The tester is also the one who upstreamed support for x1s in mainline
linux. He volunteered for me to upstream barebox support for it
alongside dreamlte, hence why I have my copyright in the x1s overlay
device tree.
---
 arch/arm/boards/samsung-exynos/board.c    |  3 +++
 arch/arm/boards/samsung-exynos/lowlevel.c |  3 +++
 arch/arm/dts/Makefile                     |  3 ++-
 arch/arm/dts/exynos990-x1s.dts            | 13 +++++++++++++
 4 files changed, 21 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/dts/exynos990-x1s.dts

diff --git a/arch/arm/boards/samsung-exynos/board.c b/arch/arm/boards/samsung-exynos/board.c
index 25e4add6..249b1b07 100644
--- a/arch/arm/boards/samsung-exynos/board.c
+++ b/arch/arm/boards/samsung-exynos/board.c
@@ -29,6 +29,8 @@ static int exynos_postcore_init(void)
 	 */
 	if (of_machine_is_compatible("samsung,exynos8895"))
 		decon0_base = IOMEM(0x12860000);
+	else if (of_machine_is_compatible("samsung,exynos990"))
+		decon0_base = IOMEM(0x19050000);
 	else
 		return 0;
 
@@ -49,6 +51,7 @@ static inline int exynos_init(struct device *dev)
 
 static const struct of_device_id exynos_of_match[] = {
 	{ .compatible = "samsung,dreamlte" },
+	{ .compatible = "samsung,x1s" },
 	{ /* Sentinel */},
 };
 
diff --git a/arch/arm/boards/samsung-exynos/lowlevel.c b/arch/arm/boards/samsung-exynos/lowlevel.c
index 9c4a0297..c574535f 100644
--- a/arch/arm/boards/samsung-exynos/lowlevel.c
+++ b/arch/arm/boards/samsung-exynos/lowlevel.c
@@ -12,6 +12,7 @@
 #include <asm/mmu.h>
 
 extern char __dtb_exynos8895_dreamlte_start[];
+extern char __dtb_exynos990_x1s_start[];
 
 static bool is_compat(const void *fdt, const char *prefix)
 {
@@ -42,6 +43,8 @@ static noinline void exynos_continue(void *downstream_fdt)
 	/* select device tree dynamically */
 	if (is_compat(downstream_fdt, "Samsung DREAMLTE")) {
 		__dtb_start = __dtb_exynos8895_dreamlte_start;
+	} else if (is_compat(downstream_fdt, "Samsung X1S")) {
+		__dtb_start = __dtb_exynos990_x1s_start;
 	} else {
 		/* we didn't match any device */
 		return;
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index a53834f7..58f05871 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -13,7 +13,8 @@ lwl-$(CONFIG_MACH_BEAGLEPLAY) += k3-am625-beagleplay.dtb.o k3-am625-r5-beaglepla
 lwl-$(CONFIG_MACH_CLEP7212) += ep7212-clep7212.dtb.o
 lwl-$(CONFIG_MACH_CM_FX6) += imx6dl-cm-fx6.dtb.o imx6q-cm-fx6.dtb.o imx6q-utilite.dtb.o
 lwl-$(CONFIG_MACH_DFI_FS700_M60) += imx6q-dfi-fs700-m60-6q.dtb.o imx6dl-dfi-fs700-m60-6s.dtb.o
-lwl-$(CONFIG_MACH_EXYNOS) += exynos8895-dreamlte.dtb.o
+lwl-$(CONFIG_MACH_EXYNOS) += exynos8895-dreamlte.dtb.o \
+			exynos990-x1s.dtb.o
 lwl-$(CONFIG_MACH_DUCKBILL) += imx28-duckbill.dtb.o
 lwl-$(CONFIG_MACH_KINDLE_MX50) += imx50-kindle-d01100.dtb.o imx50-kindle-d01200.dtb.o imx50-kindle-ey21.dtb.o
 lwl-$(CONFIG_MACH_EFIKA_MX_SMARTBOOK) += imx51-genesi-efika-sb.dtb.o
diff --git a/arch/arm/dts/exynos990-x1s.dts b/arch/arm/dts/exynos990-x1s.dts
new file mode 100644
index 00000000..19d59eaa
--- /dev/null
+++ b/arch/arm/dts/exynos990-x1s.dts
@@ -0,0 +1,13 @@
+// SPDX-License-Identifier: GPL-2.0 OR BSD-3-Clause
+/*
+ * Samsung Galaxy S20 5G (x1s/SM-G981B) barebox device tree source
+ *
+ * Copyright (c) 2025, Ivaylo Ivanov <ivo.ivanov.ivanov1@gmail.com>
+ */
+
+/dts-v1/;
+#include <arm64/exynos/exynos990-x1s.dts>
+
+/ {
+	barebox,disable-deep-probe;
+};
-- 
2.43.0

Re: [PATCH v1 4/4] ARM: boards: add support for Samsung Galaxy S20 5G (x1s)

[Ahmad Fatoum]

Hi Ivaylo,

On 7/29/25 22:36, Ivaylo Ivanov wrote:
> Add support for Samsung Galaxy S20 5G, based on exynos990, to the
> current samsung board support. This platform, just like exynos8895,
> needs a bit to be set in order to allow the framebuffer to refresh.
> 

Oh, a shame that I sold the old S20 FE I had. :/
I still have a rooted S10e though. I should give this a try when I have
time.

> diff --git a/arch/arm/dts/exynos990-x1s.dts b/arch/arm/dts/exynos990-x1s.dts
> new file mode 100644
> index 00000000..19d59eaa
> --- /dev/null
> +++ b/arch/arm/dts/exynos990-x1s.dts
> @@ -0,0 +1,13 @@
> +// SPDX-License-Identifier: GPL-2.0 OR BSD-3-Clause
> +/*
> + * Samsung Galaxy S20 5G (x1s/SM-G981B) barebox device tree source
> + *
> + * Copyright (c) 2025, Ivaylo Ivanov <ivo.ivanov.ivanov1@gmail.com>
> + */
> +
> +/dts-v1/;
> +#include <arm64/exynos/exynos990-x1s.dts>
> +
> +/ {
> +	barebox,disable-deep-probe;

Same comment: we want deep probe as default eventually. Did you run into
problems without this?

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 |

Re: [PATCH v1 4/4] ARM: boards: add support for Samsung Galaxy S20 5G (x1s)

[Ivaylo Ivanov]

On 7/30/25 11:48, Ahmad Fatoum wrote:
> Hi Ivaylo,
>
> On 7/29/25 22:36, Ivaylo Ivanov wrote:
>> Add support for Samsung Galaxy S20 5G, based on exynos990, to the
>> current samsung board support. This platform, just like exynos8895,
>> needs a bit to be set in order to allow the framebuffer to refresh.
>>
> Oh, a shame that I sold the old S20 FE I had. :/
> I still have a rooted S10e though. I should give this a try when I have
> time.

Heh, I was thinking about getting an s10e to bring up mainline linux on it,
but I do have quite a lot of devices to work on right now. At the very least,
I expect to throw in support for 7580 and 8890 in the future for both
mainline linux and barebox. The plan ideally will be to bring up support for
exynos7580 in barebox to a decent state, with mmc and usb working at least.
S20 series are decently supported, but nothing exciting yet.

Another qustion: are there any plans to support booting fit images from an
address in ram instead of a file? I suspect porting over all the ufs stuff from
linux will be a hassle, so for S20 (which does not have an sd card slot, only ufs)
booting a fit image that s-boot has loaded into ram for us might be neat.
As far as I've seen, only "go" can do that, but not "bootm".

Best regards,
Ivaylo

>
>> diff --git a/arch/arm/dts/exynos990-x1s.dts b/arch/arm/dts/exynos990-x1s.dts
>> new file mode 100644
>> index 00000000..19d59eaa
>> --- /dev/null
>> +++ b/arch/arm/dts/exynos990-x1s.dts
>> @@ -0,0 +1,13 @@
>> +// SPDX-License-Identifier: GPL-2.0 OR BSD-3-Clause
>> +/*
>> + * Samsung Galaxy S20 5G (x1s/SM-G981B) barebox device tree source
>> + *
>> + * Copyright (c) 2025, Ivaylo Ivanov <ivo.ivanov.ivanov1@gmail.com>
>> + */
>> +
>> +/dts-v1/;
>> +#include <arm64/exynos/exynos990-x1s.dts>
>> +
>> +/ {
>> +	barebox,disable-deep-probe;
> Same comment: we want deep probe as default eventually. Did you run into
> problems without this?
>
> Cheers,
> Ahmad
>
>> +};

Re: [PATCH v1 4/4] ARM: boards: add support for Samsung Galaxy S20 5G (x1s)

[Ahmad Fatoum]

Hi,

On 7/30/25 11:16, Ivaylo Ivanov wrote:
> On 7/30/25 11:48, Ahmad Fatoum wrote:
>> Hi Ivaylo,
>>
>> On 7/29/25 22:36, Ivaylo Ivanov wrote:
>>> Add support for Samsung Galaxy S20 5G, based on exynos990, to the
>>> current samsung board support. This platform, just like exynos8895,
>>> needs a bit to be set in order to allow the framebuffer to refresh.
>>>
>> Oh, a shame that I sold the old S20 FE I had. :/
>> I still have a rooted S10e though. I should give this a try when I have
>> time.
> 
> Heh, I was thinking about getting an s10e to bring up mainline linux on it,
> but I do have quite a lot of devices to work on right now. At the very least,
> I expect to throw in support for 7580 and 8890 in the future for both
> mainline linux and barebox. The plan ideally will be to bring up support for
> exynos7580 in barebox to a decent state, with mmc and usb working at least.
> S20 series are decently supported, but nothing exciting yet.

Cool stuff. Looking forward to it. :-)

> Another qustion: are there any plans to support booting fit images from an
> address in ram instead of a file? I suspect porting over all the ufs stuff from
> linux will be a hassle

It's something we will want sooner or later, but yes, it will likely be
involved.

> , so for S20 (which does not have an sd card slot, only ufs)
> booting a fit image that s-boot has loaded into ram for us might be neat.
> As far as I've seen, only "go" can do that, but not "bootm".

$ addpart /dev/ram0 0x1000@0x1000(fit)
$ bootm /dev/ram0.fit

would've been the workaround so far.

Since the fuzzing infrastructure has been merged, we also have
ramdisk_init, which sets up a block device on top of a memory buffer
without block layer caching. I think that's sufficient to implement
losetup(8), which would go beyond addpart and even allow mounting file
systems from the loop device.

Cheers,
Ahmad



> 
> Best regards,
> Ivaylo
> 
>>
>>> diff --git a/arch/arm/dts/exynos990-x1s.dts b/arch/arm/dts/exynos990-x1s.dts
>>> new file mode 100644
>>> index 00000000..19d59eaa
>>> --- /dev/null
>>> +++ b/arch/arm/dts/exynos990-x1s.dts
>>> @@ -0,0 +1,13 @@
>>> +// SPDX-License-Identifier: GPL-2.0 OR BSD-3-Clause
>>> +/*
>>> + * Samsung Galaxy S20 5G (x1s/SM-G981B) barebox device tree source
>>> + *
>>> + * Copyright (c) 2025, Ivaylo Ivanov <ivo.ivanov.ivanov1@gmail.com>
>>> + */
>>> +
>>> +/dts-v1/;
>>> +#include <arm64/exynos/exynos990-x1s.dts>
>>> +
>>> +/ {
>>> +	barebox,disable-deep-probe;
>> Same comment: we want deep probe as default eventually. Did you run into
>> problems without this?
>>
>> 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 |

Re: [PATCH v1 4/4] ARM: boards: add support for Samsung Galaxy S20 5G (x1s)

[Ivaylo Ivanov]

On 7/30/25 12:44, Ahmad Fatoum wrote:
> Hi,
>
> On 7/30/25 11:16, Ivaylo Ivanov wrote:
>> On 7/30/25 11:48, Ahmad Fatoum wrote:
>>> Hi Ivaylo,
>>>
>>> On 7/29/25 22:36, Ivaylo Ivanov wrote:
>>>> Add support for Samsung Galaxy S20 5G, based on exynos990, to the
>>>> current samsung board support. This platform, just like exynos8895,
>>>> needs a bit to be set in order to allow the framebuffer to refresh.
>>>>
>>> Oh, a shame that I sold the old S20 FE I had. :/
>>> I still have a rooted S10e though. I should give this a try when I have
>>> time.
>> Heh, I was thinking about getting an s10e to bring up mainline linux on it,
>> but I do have quite a lot of devices to work on right now. At the very least,
>> I expect to throw in support for 7580 and 8890 in the future for both
>> mainline linux and barebox. The plan ideally will be to bring up support for
>> exynos7580 in barebox to a decent state, with mmc and usb working at least.
>> S20 series are decently supported, but nothing exciting yet.
> Cool stuff. Looking forward to it. :-)
>
>> Another qustion: are there any plans to support booting fit images from an
>> address in ram instead of a file? I suspect porting over all the ufs stuff from
>> linux will be a hassle
> It's something we will want sooner or later, but yes, it will likely be
> involved.
>
>> , so for S20 (which does not have an sd card slot, only ufs)
>> booting a fit image that s-boot has loaded into ram for us might be neat.
>> As far as I've seen, only "go" can do that, but not "bootm".
> $ addpart /dev/ram0 0x1000@0x1000(fit)
> $ bootm /dev/ram0.fit
>
> would've been the workaround so far.

Oh, nice. I'll give it a shot and if it works, I'll include it
in a config in the board dir as default boot behavior
(we really cannot interact with the console yet anyways).

>
> Since the fuzzing infrastructure has been merged, we also have
> ramdisk_init, which sets up a block device on top of a memory buffer
> without block layer caching. I think that's sufficient to implement
> losetup(8), which would go beyond addpart and even allow mounting file
> systems from the loop device.

I see. Looking forward to that.

Best regards,
Ivaylo.

>
> Cheers,
> Ahmad
>
>
>
>> Best regards,
>> Ivaylo
>>
>>>> diff --git a/arch/arm/dts/exynos990-x1s.dts b/arch/arm/dts/exynos990-x1s.dts
>>>> new file mode 100644
>>>> index 00000000..19d59eaa
>>>> --- /dev/null
>>>> +++ b/arch/arm/dts/exynos990-x1s.dts
>>>> @@ -0,0 +1,13 @@
>>>> +// SPDX-License-Identifier: GPL-2.0 OR BSD-3-Clause
>>>> +/*
>>>> + * Samsung Galaxy S20 5G (x1s/SM-G981B) barebox device tree source
>>>> + *
>>>> + * Copyright (c) 2025, Ivaylo Ivanov <ivo.ivanov.ivanov1@gmail.com>
>>>> + */
>>>> +
>>>> +/dts-v1/;
>>>> +#include <arm64/exynos/exynos990-x1s.dts>
>>>> +
>>>> +/ {
>>>> +	barebox,disable-deep-probe;
>>> Same comment: we want deep probe as default eventually. Did you run into
>>> problems without this?
>>>
>>> Cheers,
>>> Ahmad
>>>
>>>> +};
>>

Re: [PATCH v1 4/4] ARM: boards: add support for Samsung Galaxy S20 5G (x1s)

[Ahmad Fatoum]

Hi,

On 7/30/25 13:18, Ivaylo Ivanov wrote:
> On 7/30/25 12:44, Ahmad Fatoum wrote:
>> Hi,
>>
>> On 7/30/25 11:16, Ivaylo Ivanov wrote:
>>> On 7/30/25 11:48, Ahmad Fatoum wrote:
>>>> Hi Ivaylo,
>>>>
>>>> On 7/29/25 22:36, Ivaylo Ivanov wrote:
>>>>> Add support for Samsung Galaxy S20 5G, based on exynos990, to the
>>>>> current samsung board support. This platform, just like exynos8895,
>>>>> needs a bit to be set in order to allow the framebuffer to refresh.
>>>>>
>>>> Oh, a shame that I sold the old S20 FE I had. :/
>>>> I still have a rooted S10e though. I should give this a try when I have
>>>> time.
>>> Heh, I was thinking about getting an s10e to bring up mainline linux on it,
>>> but I do have quite a lot of devices to work on right now. At the very least,
>>> I expect to throw in support for 7580 and 8890 in the future for both
>>> mainline linux and barebox. The plan ideally will be to bring up support for
>>> exynos7580 in barebox to a decent state, with mmc and usb working at least.
>>> S20 series are decently supported, but nothing exciting yet.
>> Cool stuff. Looking forward to it. :-)
>>
>>> Another qustion: are there any plans to support booting fit images from an
>>> address in ram instead of a file? I suspect porting over all the ufs stuff from
>>> linux will be a hassle
>> It's something we will want sooner or later, but yes, it will likely be
>> involved.
>>
>>> , so for S20 (which does not have an sd card slot, only ufs)
>>> booting a fit image that s-boot has loaded into ram for us might be neat.
>>> As far as I've seen, only "go" can do that, but not "bootm".
>> $ addpart /dev/ram0 0x1000@0x1000(fit)
>> $ bootm /dev/ram0.fit
>>
>> would've been the workaround so far.
> 
> Oh, nice. I'll give it a shot and if it works, I'll include it
> in a config in the board dir as default boot behavior
> (we really cannot interact with the console yet anyways).

I think a convenient behavior, at least during development is to set
autoboot=menu and set a menu timeout. Then add a config option that
remaps volume up/down to up/down and some button as return and you
should at least be able to navigate the menu.

After timeout expires, system would boot normally.

> 
>>
>> Since the fuzzing infrastructure has been merged, we also have
>> ramdisk_init, which sets up a block device on top of a memory buffer
>> without block layer caching. I think that's sufficient to implement
>> losetup(8), which would go beyond addpart and even allow mounting file
>> systems from the loop device.
> 
> I see. Looking forward to that.
> 
> Best regards,
> Ivaylo.
> 
>>
>> Cheers,
>> Ahmad
>>
>>
>>
>>> Best regards,
>>> Ivaylo
>>>
>>>>> diff --git a/arch/arm/dts/exynos990-x1s.dts b/arch/arm/dts/exynos990-x1s.dts
>>>>> new file mode 100644
>>>>> index 00000000..19d59eaa
>>>>> --- /dev/null
>>>>> +++ b/arch/arm/dts/exynos990-x1s.dts
>>>>> @@ -0,0 +1,13 @@
>>>>> +// SPDX-License-Identifier: GPL-2.0 OR BSD-3-Clause
>>>>> +/*
>>>>> + * Samsung Galaxy S20 5G (x1s/SM-G981B) barebox device tree source
>>>>> + *
>>>>> + * Copyright (c) 2025, Ivaylo Ivanov <ivo.ivanov.ivanov1@gmail.com>
>>>>> + */
>>>>> +
>>>>> +/dts-v1/;
>>>>> +#include <arm64/exynos/exynos990-x1s.dts>
>>>>> +
>>>>> +/ {
>>>>> +	barebox,disable-deep-probe;
>>>> Same comment: we want deep probe as default eventually. Did you run into
>>>> problems without this?
>>>>
>>>> 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 |

Re: [PATCH v1 4/4] ARM: boards: add support for Samsung Galaxy S20 5G (x1s)

[Ivaylo Ivanov]

On 7/30/25 15:50, Ahmad Fatoum wrote:
> Hi,
>
> On 7/30/25 13:18, Ivaylo Ivanov wrote:
>> On 7/30/25 12:44, Ahmad Fatoum wrote:
>>> Hi,
>>>
>>> On 7/30/25 11:16, Ivaylo Ivanov wrote:
>>>> On 7/30/25 11:48, Ahmad Fatoum wrote:
>>>>> Hi Ivaylo,
>>>>>
>>>>> On 7/29/25 22:36, Ivaylo Ivanov wrote:
>>>>>> Add support for Samsung Galaxy S20 5G, based on exynos990, to the
>>>>>> current samsung board support. This platform, just like exynos8895,
>>>>>> needs a bit to be set in order to allow the framebuffer to refresh.
>>>>>>
>>>>> Oh, a shame that I sold the old S20 FE I had. :/
>>>>> I still have a rooted S10e though. I should give this a try when I have
>>>>> time.
>>>> Heh, I was thinking about getting an s10e to bring up mainline linux on it,
>>>> but I do have quite a lot of devices to work on right now. At the very least,
>>>> I expect to throw in support for 7580 and 8890 in the future for both
>>>> mainline linux and barebox. The plan ideally will be to bring up support for
>>>> exynos7580 in barebox to a decent state, with mmc and usb working at least.
>>>> S20 series are decently supported, but nothing exciting yet.
>>> Cool stuff. Looking forward to it. :-)
>>>
>>>> Another qustion: are there any plans to support booting fit images from an
>>>> address in ram instead of a file? I suspect porting over all the ufs stuff from
>>>> linux will be a hassle
>>> It's something we will want sooner or later, but yes, it will likely be
>>> involved.
>>>
>>>> , so for S20 (which does not have an sd card slot, only ufs)
>>>> booting a fit image that s-boot has loaded into ram for us might be neat.
>>>> As far as I've seen, only "go" can do that, but not "bootm".
>>> $ addpart /dev/ram0 0x1000@0x1000(fit)
>>> $ bootm /dev/ram0.fit
>>>
>>> would've been the workaround so far.
>> Oh, nice. I'll give it a shot and if it works, I'll include it
>> in a config in the board dir as default boot behavior
>> (we really cannot interact with the console yet anyways).
> I think a convenient behavior, at least during development is to set
> autoboot=menu and set a menu timeout. Then add a config option that
> remaps volume up/down to up/down and some button as return and you
> should at least be able to navigate the menu.
>
> After timeout expires, system would boot normally.

Hm, I haven't thought of that. Mapping keys will need a pinctrl/gpio driver
though, so I think it will be best to just have default boot behavior as
bootm'ing a fit image from ram, while also having autoboot=menu
and a timeout set. That way we can expand it after adding keys in the
future. Does that sound good?

Best regards,
Ivaylo

>
>>> Since the fuzzing infrastructure has been merged, we also have
>>> ramdisk_init, which sets up a block device on top of a memory buffer
>>> without block layer caching. I think that's sufficient to implement
>>> losetup(8), which would go beyond addpart and even allow mounting file
>>> systems from the loop device.
>> I see. Looking forward to that.
>>
>> Best regards,
>> Ivaylo.
>>
>>> Cheers,
>>> Ahmad
>>>
>>>
>>>
>>>> Best regards,
>>>> Ivaylo
>>>>
>>>>>> diff --git a/arch/arm/dts/exynos990-x1s.dts b/arch/arm/dts/exynos990-x1s.dts
>>>>>> new file mode 100644
>>>>>> index 00000000..19d59eaa
>>>>>> --- /dev/null
>>>>>> +++ b/arch/arm/dts/exynos990-x1s.dts
>>>>>> @@ -0,0 +1,13 @@
>>>>>> +// SPDX-License-Identifier: GPL-2.0 OR BSD-3-Clause
>>>>>> +/*
>>>>>> + * Samsung Galaxy S20 5G (x1s/SM-G981B) barebox device tree source
>>>>>> + *
>>>>>> + * Copyright (c) 2025, Ivaylo Ivanov <ivo.ivanov.ivanov1@gmail.com>
>>>>>> + */
>>>>>> +
>>>>>> +/dts-v1/;
>>>>>> +#include <arm64/exynos/exynos990-x1s.dts>
>>>>>> +
>>>>>> +/ {
>>>>>> +	barebox,disable-deep-probe;
>>>>> Same comment: we want deep probe as default eventually. Did you run into
>>>>> problems without this?
>>>>>
>>>>> Cheers,
>>>>> Ahmad
>>>>>
>>>>>> +};
>>

Re: [PATCH v1 4/4] ARM: boards: add support for Samsung Galaxy S20 5G (x1s)

[Ahmad Fatoum]

Hi Ivaylo,

On 7/30/25 15:12, Ivaylo Ivanov wrote:
> On 7/30/25 15:50, Ahmad Fatoum wrote:
>> Hi,
>>
>> On 7/30/25 13:18, Ivaylo Ivanov wrote:
>>> On 7/30/25 12:44, Ahmad Fatoum wrote:
>>>> Hi,
>>>>
>>>> On 7/30/25 11:16, Ivaylo Ivanov wrote:
>>>>> On 7/30/25 11:48, Ahmad Fatoum wrote:
>>>>>> Hi Ivaylo,
>>>>>>
>>>>>> On 7/29/25 22:36, Ivaylo Ivanov wrote:
>>>>>>> Add support for Samsung Galaxy S20 5G, based on exynos990, to the
>>>>>>> current samsung board support. This platform, just like exynos8895,
>>>>>>> needs a bit to be set in order to allow the framebuffer to refresh.
>>>>>>>
>>>>>> Oh, a shame that I sold the old S20 FE I had. :/
>>>>>> I still have a rooted S10e though. I should give this a try when I have
>>>>>> time.
>>>>> Heh, I was thinking about getting an s10e to bring up mainline linux on it,
>>>>> but I do have quite a lot of devices to work on right now. At the very least,
>>>>> I expect to throw in support for 7580 and 8890 in the future for both
>>>>> mainline linux and barebox. The plan ideally will be to bring up support for
>>>>> exynos7580 in barebox to a decent state, with mmc and usb working at least.
>>>>> S20 series are decently supported, but nothing exciting yet.
>>>> Cool stuff. Looking forward to it. :-)
>>>>
>>>>> Another qustion: are there any plans to support booting fit images from an
>>>>> address in ram instead of a file? I suspect porting over all the ufs stuff from
>>>>> linux will be a hassle
>>>> It's something we will want sooner or later, but yes, it will likely be
>>>> involved.
>>>>
>>>>> , so for S20 (which does not have an sd card slot, only ufs)
>>>>> booting a fit image that s-boot has loaded into ram for us might be neat.
>>>>> As far as I've seen, only "go" can do that, but not "bootm".
>>>> $ addpart /dev/ram0 0x1000@0x1000(fit)
>>>> $ bootm /dev/ram0.fit
>>>>
>>>> would've been the workaround so far.
>>> Oh, nice. I'll give it a shot and if it works, I'll include it
>>> in a config in the board dir as default boot behavior
>>> (we really cannot interact with the console yet anyways).
>> I think a convenient behavior, at least during development is to set
>> autoboot=menu and set a menu timeout. Then add a config option that
>> remaps volume up/down to up/down and some button as return and you
>> should at least be able to navigate the menu.
>>
>> After timeout expires, system would boot normally.
> 
> Hm, I haven't thought of that. Mapping keys will need a pinctrl/gpio driver
> though, so I think it will be best to just have default boot behavior as
> bootm'ing a fit image from ram, while also having autoboot=menu
> and a timeout set. That way we can expand it after adding keys in the
> future. Does that sound good?

Ye, sure. I am just talking where we could go from here in future.

Keep up the good work.

Cheers,
Ahmad

> 
> Best regards,
> Ivaylo
> 
>>
>>>> Since the fuzzing infrastructure has been merged, we also have
>>>> ramdisk_init, which sets up a block device on top of a memory buffer
>>>> without block layer caching. I think that's sufficient to implement
>>>> losetup(8), which would go beyond addpart and even allow mounting file
>>>> systems from the loop device.
>>> I see. Looking forward to that.
>>>
>>> Best regards,
>>> Ivaylo.
>>>
>>>> Cheers,
>>>> Ahmad
>>>>
>>>>
>>>>
>>>>> Best regards,
>>>>> Ivaylo
>>>>>
>>>>>>> diff --git a/arch/arm/dts/exynos990-x1s.dts b/arch/arm/dts/exynos990-x1s.dts
>>>>>>> new file mode 100644
>>>>>>> index 00000000..19d59eaa
>>>>>>> --- /dev/null
>>>>>>> +++ b/arch/arm/dts/exynos990-x1s.dts
>>>>>>> @@ -0,0 +1,13 @@
>>>>>>> +// SPDX-License-Identifier: GPL-2.0 OR BSD-3-Clause
>>>>>>> +/*
>>>>>>> + * Samsung Galaxy S20 5G (x1s/SM-G981B) barebox device tree source
>>>>>>> + *
>>>>>>> + * Copyright (c) 2025, Ivaylo Ivanov <ivo.ivanov.ivanov1@gmail.com>
>>>>>>> + */
>>>>>>> +
>>>>>>> +/dts-v1/;
>>>>>>> +#include <arm64/exynos/exynos990-x1s.dts>
>>>>>>> +
>>>>>>> +/ {
>>>>>>> +	barebox,disable-deep-probe;
>>>>>> Same comment: we want deep probe as default eventually. Did you run into
>>>>>> problems without this?
>>>>>>
>>>>>> 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 |