date:20230111

Re: [PATCH 1/1] efi_loader: use EFI_EXIT in efi_riscv_get_boot_hartid

2023-01-11 Thread Ilias Apalodimas

On Wed, Jan 11, 2023 at 07:13:01PM +0100, Heinrich Schuchardt wrote:
> After calling EFI_ENTRY we have to call EFI_EXIT before returning.
>
> Add a missing EFI_EXIT().
>
> Fixes: 1ccf87165e38 ("efi_loader: Enable RISCV_EFI_BOOT_PROTOCOL support")
> Reported-by: Dave Jones 
> Signed-off-by: Heinrich Schuchardt 
> ---
>  lib/efi_loader/efi_riscv.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/lib/efi_loader/efi_riscv.c b/lib/efi_loader/efi_riscv.c
> index bccfefd8fb..064172755b 100644
> --- a/lib/efi_loader/efi_riscv.c
> +++ b/lib/efi_loader/efi_riscv.c
> @@ -31,7 +31,7 @@ efi_riscv_get_boot_hartid(struct riscv_efi_boot_protocol 
> *this,
>   EFI_ENTRY("%p, %p",  this, boot_hartid);
>
>   if (this != _efi_boot_prot || !boot_hartid)
> - return EFI_INVALID_PARAMETER;
> + return EFI_EXIT(EFI_INVALID_PARAMETER);
>
>   *boot_hartid = gd->arch.boot_hart;
>
> --
> 2.37.2
>

Reviewed-by: Ilias Apalodimas

Re: [PATCH u-boot 2/2] Makefile: Build working u-boot-dtb.bin target also for mpc85xx

2023-01-11 Thread Heiko Schocher

Hello Pali,

On 11.01.23 19:13, Pali Rohár wrote:
> On Wednesday 11 January 2023 19:02:38 Pali Rohár wrote:
>> On Wednesday 11 January 2023 18:55:40 Pali Rohár wrote:
>>> On Wednesday 11 January 2023 09:01:37 Tom Rini wrote:
 On Wed, Jan 11, 2023 at 01:52:24PM +0100, Heiko Schocher wrote:
> Hello Pali, Tom,
>
> I just tried azure build with my socrates board updates based on
> v2023.01 and the 2 patches from Pali:
>
> http://patchwork.ozlabs.org/project/uboot/patch/20221228200437.30971-1-p...@kernel.org/
> http://patchwork.ozlabs.org/project/uboot/patch/20221228200437.30971-2-p...@kernel.org/
>>>
>>> At the time when I sent those two patches to ML, I checked that P1/P2
>>> powerpc boards and also socrates board compiles successfully.
>>>
>>> Now I imported those two patches on top of the current master branch and
>>> they still compiles without any problems for socrates board.
>>>
> and get errors for powerpc build:
>
> https://dev.azure.com/hs0298/110c3e42-44d5-4db4-9bd5-8a8bbead15f3/_apis/build/builds/93/logs/601
>
> socrates board builds fine ... my patches are socrates board specfic,
> so hopefully no impact for other boards ...
>>>
>>> From that build log it looks like that u-boot fails for socrates and
>>> kmcent2 board. Which is strange as you said that too that socrates is
>>> building fine...

misreaded azure output, so socrates is failing because missing u-boot.dtb,
sorry. Interesting is, that my yocto build works ...

>>
>> kmcent2 is expected to fail with my above two patches on top of the
>> v2023.01 without this kmcent2 commit which is now already in master:
>> https://source.denx.de/u-boot/u-boot/-/commit/499fe577c8011dd8a9184548c419db42aef079a7
> 
> And now I think I see the reason why it is failing also for socrates
> board. Error in the build log is:
> 
> 2023-01-11T12:16:04.4937207Z +binman: [Errno 2] No such file or directory: 
> 'u-boot.dtb'
> 2023-01-11T12:16:04.4937685Z +make[1]: *** [Makefile:1613: u-boot-dtb.bin] 
> Error 1

Yup.

> u-boot.dtb builds make by Makefile rule:
> 
> u-boot.dtb: dts/dt.dtb
>   $(call cmd,copy)
> 
> But socrates-u-boot.dtsi has specified that use dts/dt.dtb and this
> dependency is also specified in Makefile.
> 
> And it looks like that binman needs also u-boot.dtb file. So it is
> possible to hit a race condition, that make builds u-boot.dtb later than
> rule for binman.

Exactly over this I stumbled yesterday in the evening and I made a local
fix:

diff --git a/Makefile b/Makefile
index fb1454552a..60f5cffccd 100644
--- a/Makefile
+++ b/Makefile
@@ -1609,7 +1609,7 @@ OBJCOPYFLAGS_u-boot-br.bin := -O binary -j .bootpg -j 
.resetvec
 u-boot-br.bin: u-boot FORCE
$(call if_changed,objcopy)
 else ifeq ($(CONFIG_TARGET_SOCRATES),y)
-u-boot-dtb.bin: u-boot-nodtb.bin dts/dt.dtb FORCE
+u-boot-dtb.bin: u-boot-nodtb.bin dts/dt.dtb u-boot.dtb FORCE
$(call if_changed,binman)
 endif


> I would suggest to try to apply this patch, which should instruct make
> to do not call binman until u-boot.dtb is correctly built:
> 
> diff --git a/Makefile b/Makefile
> index 3c76486a620e..5d2ef8cc81c5 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1603,7 +1603,7 @@ OBJCOPYFLAGS_u-boot-br.bin := -O binary -j .bootpg -j 
> .resetvec
>  u-boot-br.bin: u-boot FORCE
>   $(call if_changed,objcopy)
>  else ifeq ($(CONFIG_TARGET_SOCRATES),y)
> -u-boot-dtb.bin: u-boot-nodtb.bin dts/dt.dtb FORCE
> +u-boot-dtb.bin: u-boot-nodtb.bin u-boot.dtb FORCE
>   $(call if_changed,binman)
>  endif
>  
> diff --git a/arch/powerpc/dts/socrates-u-boot.dtsi 
> b/arch/powerpc/dts/socrates-u-boot.dtsi
> index ba2e56d35675..f6af611b513c 100644
> --- a/arch/powerpc/dts/socrates-u-boot.dtsi
> +++ b/arch/powerpc/dts/socrates-u-boot.dtsi
> @@ -9,7 +9,7 @@
>   pad-byte = <0xff>;
>   // Place dtb one sector before u-boot-nodtb.bin
>   blob {
> - filename = "dts/dt.dtb";
> + filename = "u-boot.dtb";
>   };
>   u-boot-nodtb {
>   filename = "u-boot-nodtb.bin";
> 
> 
> Heiko, could you try to put commit 499fe577c8011dd8a9184548c419db42aef079a7
> and above patch to your branch and retest it again?

Of course! Just have to wait until other azure build finished...

In the meantime I rebased my patchset to current HEAD, so above
commit is already in, and I had to adapt some patches for socrates.

I write the results hopefully soon.

bye,
Heikp
 socrates is one of the two failing boards, in that link:
 2023-01-11T12:16:04.4930367Zpowerpc:  w+   MPC837XERDB kmcoge5ne
 kmeter1 kmopti2 kmsupx5 kmtepr2 tuge1 tuxx1 MPC8548CDS MPC8548CDS_36BIT
 MPC8548CDS_legacy P1010RDB-PA_36BIT_NAND P1010RDB-PA_36BIT_NOR
 P1010RDB-PA_36BIT_SDCARD P1010RDB-PA_36BIT_SPIFLASH P1010RDB-PA_NAND
 P1010RDB-PA_NOR P1010RDB-PA_SDCARD P1010RDB-PA_SPIFLASH
 P1010RDB-PB_36BIT_NAND P1010RDB-PB_36BIT_NOR

Re: [PATCH u-boot 2/2] Makefile: Build working u-boot-dtb.bin target also for mpc85xx

2023-01-11 Thread Heiko Schocher

Hello Tom,

On 11.01.23 15:01, Tom Rini wrote:
> On Wed, Jan 11, 2023 at 01:52:24PM +0100, Heiko Schocher wrote:
>> Hello Pali, Tom,
>>
>> I just tried azure build with my socrates board updates based on
>> v2023.01 and the 2 patches from Pali:
>>
>> http://patchwork.ozlabs.org/project/uboot/patch/20221228200437.30971-1-p...@kernel.org/
>> http://patchwork.ozlabs.org/project/uboot/patch/20221228200437.30971-2-p...@kernel.org/
>>
>> and get errors for powerpc build:
>>
>> https://dev.azure.com/hs0298/110c3e42-44d5-4db4-9bd5-8a8bbead15f3/_apis/build/builds/93/logs/601
>>
>> socrates board builds fine ... my patches are socrates board specfic,
>> so hopefully no impact for other boards ...
> 
> socrates is one of the two failing boards, in that link:
> 2023-01-11T12:16:04.4930367Zpowerpc:  w+   MPC837XERDB kmcoge5ne
> kmeter1 kmopti2 kmsupx5 kmtepr2 tuge1 tuxx1 MPC8548CDS MPC8548CDS_36BIT
> MPC8548CDS_legacy P1010RDB-PA_36BIT_NAND P1010RDB-PA_36BIT_NOR
> P1010RDB-PA_36BIT_SDCARD P1010RDB-PA_36BIT_SPIFLASH P1010RDB-PA_NAND
> P1010RDB-PA_NOR P1010RDB-PA_SDCARD P1010RDB-PA_SPIFLASH
> P1010RDB-PB_36BIT_NAND P1010RDB-PB_36BIT_NOR P1010RDB-PB_36BIT_SDCARD
> P1010RDB-PB_36BIT_SPIFLASH P1010RDB-PB_NAND P1010RDB-PB_NOR
> P1010RDB-PB_SDCARD P1010RDB-PB_SPIFLASH P1020RDB-PC P1020RDB-PC_36BIT
> P1020RDB-PC_36BIT_NAND P1020RDB-PC_36BIT_SDCARD
> P1020RDB-PC_36BIT_SPIFLASH P1020RDB-PC_NAND P1020RDB-PC_SDCARD
> P1020RDB-PC_SPIFLASH P1020RDB-PD P1020RDB-PD_NAND P1020RDB-PD_SDCARD
> P1020RDB-PD_SPIFLASH P2020RDB-PC P2020RDB-PC_36BIT
> P2020RDB-PC_36BIT_NAND P2020RDB-PC_36BIT_SDCARD
> P2020RDB-PC_36BIT_SPIFLASH P2020RDB-PC_NAND P2020RDB-PC_SDCARD
> P2020RDB-PC_SPIFLASH P2041RDB P2041RDB_NAND P2041RDB_SDCARD
> P2041RDB_SPIFLASH T1024RDB T1024RDB_NAND T1024RDB_SDCARD
> T1024RDB_SPIFLASH T1042D4RDB T1042D4RDB_NAND T1042D4RDB_SDCARD
> T1042D4RDB_SPIFLASH T2080QDS T2080QDS_NAND T2080QDS_SDCARD
> T2080QDS_SECURE_BOOT T2080QDS_SPIFLASH T2080QDS_SRIO_PCIE_BOOT T2080RDB
> T2080RDB_NAND T2080RDB_revD T2080RDB_revD_NAND T2080RDB_revD_SDCARD
> T2080RDB_revD_SPIFLASH T2080RDB_SDCARD T2080RDB_SPIFLASH T4240RDB
> T4240RDB_SDCARD +   socrates kmcent2

Yep, noted this later ... and have local a fix for socrates
board, but first just started a build with patches from pali
to be sure, that I did not introduced some mistake ...
> 
>> @Tom: Do you know if v2023.01 builds fine for powerpc
> 
> Yes, CI is passing.

Ok, fine, so I do not start one ... just started one with patches
from pali.

Thanks for the info!

bye,
Heiko
-- 
DENX Software Engineering GmbH,  Managing Director: Erika Unter
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: h...@denx.de

Re: [PATCH 2/3] power: regulator: Add a driver for AXP PMIC regulators

2023-01-11 Thread Samuel Holland

Hi Andre,

On 1/11/23 17:08, Andre Przywara wrote:
> On Mon, 28 Nov 2022 00:47:55 -0600
> Samuel Holland  wrote:
> 
> Hi Samuel,
> 
>> This driver handles most voltage regulators found in X-Powers AXP PMICs.
>> It is based on, and intended to replace, the regulator driver in TF-A.
> 
> Many thanks for putting this together! That's much appreciated.
> 
>> AXP PMIC regulators can be divided into 6 categories:
>>  - Switches without voltage control => fully supported.
>>  - Single linear range => fully supported.
>>  - Two linear ranges, "step" and "2 * step" => fully supported.
>>  - Two linear ranges, "step" and "5 * step" => only the first range is
>>supported. No boards are known to use the second range.
>>  - Non-linear voltage values => fully supported.
>>  - LDOs shared with GPIO pins => not supported.
> 
> Quite an impressive feature list!
> 
> So I first scratched my head about the ffs and shift dance, but then
> realised that some of those older PMICs stuffed two voltage controls in
> one register. Neat solution for that!
> 
> I compared the tables against all datasheets, just found one bug (plus
> apparently one documentation bug).
> And one question about the license, see below.
> 
> Otherwise I am ready to take that driver now, just need to test it on
> some boards.
> 
>>
>> Signed-off-by: Samuel Holland 
>> ---
>>
>>  drivers/power/regulator/Kconfig |  14 ++
>>  drivers/power/regulator/Makefile|   1 +
>>  drivers/power/regulator/axp_regulator.c | 308 
>>  3 files changed, 323 insertions(+)
>>  create mode 100644 drivers/power/regulator/axp_regulator.c
>>
>> diff --git a/drivers/power/regulator/Kconfig 
>> b/drivers/power/regulator/Kconfig
>> index c519e066ef0..de776556ffe 100644
>> --- a/drivers/power/regulator/Kconfig
>> +++ b/drivers/power/regulator/Kconfig
>> @@ -43,6 +43,20 @@ config REGULATOR_AS3722
>>but does not yet support change voltages. Currently this must be
>>done using direct register writes to the PMIC.
>>  
>> +config REGULATOR_AXP
>> +bool "Enable driver for X-Powers AXP PMIC regulators"
>> +depends on DM_REGULATOR && PMIC_AXP
>> +help
>> +  Enable support for the regulators (DCDCs, LDOs) in the
>> +  X-Powers AXP152, AXP2xx, and AXP8xx PMICs.
>> +
>> +config SPL_REGULATOR_AXP
>> +bool "Enable driver for X-Powers AXP PMIC regulators in SPL"
>> +depends on SPL_DM_REGULATOR && SPL_PMIC_AXP
>> +help
>> +  Enable support in SPL for the regulators (DCDCs, LDOs) in the
>> +  X-Powers AXP152, AXP2xx, and AXP8xx PMICs.
>> +
>>  config DM_REGULATOR_BD71837
>>  bool "Enable Driver Model for ROHM BD71837/BD71847 regulators"
>>  depends on DM_REGULATOR && DM_PMIC_BD71837
>> diff --git a/drivers/power/regulator/Makefile 
>> b/drivers/power/regulator/Makefile
>> index bc736068bca..eb06b85bcd9 100644
>> --- a/drivers/power/regulator/Makefile
>> +++ b/drivers/power/regulator/Makefile
>> @@ -7,6 +7,7 @@
>>  obj-$(CONFIG_$(SPL_)DM_REGULATOR) += regulator-uclass.o
>>  obj-$(CONFIG_REGULATOR_ACT8846) += act8846.o
>>  obj-$(CONFIG_REGULATOR_AS3722)  += as3722_regulator.o
>> +obj-$(CONFIG_$(SPL_)REGULATOR_AXP) += axp_regulator.o
>>  obj-$(CONFIG_$(SPL_)DM_REGULATOR_DA9063) += da9063.o
>>  obj-$(CONFIG_DM_REGULATOR_MAX77686) += max77686.o
>>  obj-$(CONFIG_$(SPL_)DM_PMIC_PFUZE100) += pfuze100.o
>> diff --git a/drivers/power/regulator/axp_regulator.c 
>> b/drivers/power/regulator/axp_regulator.c
>> new file mode 100644
>> index 000..7af3cccd043
>> --- /dev/null
>> +++ b/drivers/power/regulator/axp_regulator.c
>> @@ -0,0 +1,308 @@
>> +// SPDX-License-Identifier: BSD-3-Clause
> 
> So just BSD-3 looks a bit odd. I guess this comes because you copied
> some code (actually not that much?) from TF-A? Looking at the history
> there, it was just you and me contributing. I see one small patch from
> someone else, but you didn't copy that code.
> So I am fine with dual licensing this as "GPL-2.0 OR BSD-3-Clause". If
> you agree as well, I would appreciate if you would change the license.

Yes, the license is because I took the code from TF-A. I am fine with
dual-licensing as well.

>> +/*
>> + * Copyright (c) 2017-2019, ARM Limited and Contributors. All rights 
>> reserved.
>> + * Copyright (c) 2018-2022 Samuel Holland 
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#define NA 0xff
>> +
>> +struct axp_regulator_plat {
>> +const char  *name;
>> +u8  enable_reg;
>> +u8  enable_mask;
>> +u8  volt_reg;
>> +u8  volt_mask;
>> +u16 min_mV;
>> +u16 max_mV;
>> +u8  step_mV;
>> +u8  split;
>> +const u16   *table;
>> +};
>> +
>> +static int axp_regulator_get_value(struct udevice *dev)
>> +{
>> +const struct axp_regulator_plat *plat = dev_get_plat(dev);
>> +int mV, sel;
>> +
>> +if

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

2023-01-11 Thread Rob Herring

On Mon, Dec 19, 2022 at 1:21 PM Simon Glass  wrote:
>
> Hi Abdellatif,
>
> On Mon, 19 Dec 2022 at 04:12, Abdellatif El Khlifi
>  wrote:
> >
> > On Mon, Dec 05, 2022 at 09:49:30AM -0600, Rob Herring wrote:
> > > On Sun, Dec 4, 2022 at 1:22 PM Simon Glass  wrote:
> > > >
> > > > Hi Rob,
> > > >
> > > > On Tue, 29 Nov 2022 at 05:22, Rob Herring  wrote:
> > > > >
> > > > > On Fri, Nov 25, 2022 at 3:18 PM Simon Glass  wrote:
> > > > > >
> > > > > > Hi Abdellatif,
> > > > > >
> > > > > > On Thu, 24 Nov 2022 at 06:21, Abdellatif El Khlifi 
> > > > > >  wrote:
> > > > > > >
> > > > > > > On Tue, Nov 22, 2022 at 07:09:16PM -0700, Simon Glass wrote:
> > > > > > > >  should be called 'priov' and should beHi Abdellatif,
> > > > > > > >
> > > > > >
> > > > > > [..]
> > > > > >
> > > > > > > > > +/**
> > > > > > > > > + * ffa_device_get - create, bind and probe the arm_ffa device
> > > > > > > > > + * @pdev: the address of a device pointer (to be filled when 
> > > > > > > > > the arm_ffa bus device is created
> > > > > > > > > + *   successfully)
> > > > > > > > > + *
> > > > > > > > > + * This function makes sure the arm_ffa device is
> > > > > > > > > + * created, bound to this driver, probed and ready to use.
> > > > > > > > > + * Arm FF-A transport is implemented through a single U-Boot
> > > > > > > > > + * device managing the FF-A bus (arm_ffa).
> > > > > > > > > + *
> > > > > > > > > + * Return:
> > > > > > > > > + *
> > > > > > > > > + * 0 on success. Otherwise, failure
> > > > > > > > > + */
> > > > > > > > > +int ffa_device_get(struct udevice **pdev)
> > > > > > > > > +{
> > > > > > > > > +   int ret;
> > > > > > > > > +   struct udevice *dev = NULL;
> > > > > > > > > +
> > > > > > > > > +   ret = device_bind(dm_root(), DM_DRIVER_GET(arm_ffa), 
> > > > > > > > > FFA_DRV_NAME, NULL, ofnode_null(),
> > > > > > > > > + );
> > > > > > > >
> > > > > > > > Please add a DT binding. Even if only temporary, we need 
> > > > > > > > something for this.
> > > > > > >
> > > > > > > Thanks for the feedback. I'm happy to address all the comments.
> > > > > > >
> > > > > > > Regarding DT binding and FF-A discovery. We agreed with Linaro 
> > > > > > > and Rob Herring
> > > > > > > about the following:
> > > > > > >
> > > > > > > - DT is only for what we failed to make discoverable. For 
> > > > > > > hardware, we're stuck
> > > > > > >   with it. We shouldn't repeat that for software interfaces. This 
> > > > > > > approach is
> > > > > > >   already applied in the FF-A kernel driver which comes with no 
> > > > > > > DT support and
> > > > > > >   discovers the bus with bus_register() API [1].
> > > > > >
> > > > > > This may be the UEFI view, but it is not how U-Boot works. This is 
> > > > > > not something we are 'stuck' with. It is how we define what is 
> > > > > > present on a device. This is how the PCI bus works in U-Boot. It is 
> > > > > > best practice in U-Boot to use the device tree to make this things 
> > > > > > visible and configurable. Unlike with Linux there is no other way 
> > > > > > to provide configuration needed by these devices.
> > > > >
> > > > > Where do you get UEFI out of this?
> > > >
> > > > I assume it was UEFI as there was no discussion about this in U-Boot.
> > > > Which firmware project was consulted about this?
> > > >
> > > > >
> > > > > It is the discoverability of hardware that is fixed (and we are stuck
> > > > > with). We can't change hardware. The disoverability may be PCI
> > > > > VID/PID, USB device descriptors, or nothing. We only use DT when those
> > > > > are not sufficient. For a software interface, there is no reason to
> > > > > make them non-discoverable as the interface can be fixed (at least for
> > > > > new things like FF-A).
> > > >
> > > > Here I am talking about the controller itself, the top-level node in
> > > > the device tree. For PCI this is a device tree node and it should be
> > > > the same here. So I am not saying that the devices on the bus need to
> > > > be in the device tree (that can be optional, but may be useful in some
> > > > situations where it is status and known).
> > >
> > > Sure, the PCI host bridges are not discoverable, have a bunch of
> > > resources, and do need to be in DT. The downstream devices only do if
> > > they have extra resources such as when a device is soldered down on a
> > > board rather than a standard slot.
> > >
> > > > We need something like:
> > > >
> > > > ff-a {
> > > > compatible = "something";
> > > > };
> > > >
> > > > I don't know what mechanism is actually used to communicate with it,
> > > > but that will be enough to get the top-level driver started.
> > >
> > > There's discovery of FF-A itself and then discovery of FF-A features
> > > (e.g. partitions). Both of those are discoverable without DT. The
> > > first is done by checking the SMCCC version, then checking for FF-A
> > > presence and features. Putting this into DT is redundant. Worse, what
> > > if they

Re: Applying DTB Overlays from ATF on RZ/G2

2023-01-11 Thread Marek Vasut


On 1/12/23 00:06, Adam Ford wrote:

On Tue, Jan 10, 2023 at 7:40 AM Marek Vasut  wrote:


On 1/10/23 14:19, Adam Ford wrote:

On Tue, Jan 10, 2023 at 7:02 AM Marek Vasut  wrote:


On 1/7/23 13:01, Adam Ford wrote:

On Wed, Jan 4, 2023 at 5:55 PM Marek Vasut  wrote:


On 1/5/23 00:48, Heinrich Schuchardt wrote:

Am 5. Januar 2023 00:19:36 MEZ schrieb Adam Ford :

On Wed, Jan 4, 2023 at 5:15 PM Heinrich Schuchardt  wrote:


On 1/4/23 22:35, Adam Ford wrote:

ATF generates a couple memory nodes based on how it's compiled and
generates a reserved-memory node, and I want to overlay it with the
device tree so Linux knows about this reserved memory.

When I boot U-Boot, I can read the reserved-memory node:

=> fdt addr 0xe631e588
Working FDT set to e631e588
=> fdt print /reserved-memory
reserved-memory {
lossy-decompression@5400 {
renesas,formats = <0x>;
no-map;
reg = <0x 0x5400 0x 0x0300>;
compatible = "renesas,lossy-decompression", "shared-dma-pool";
};
};
=>

I attempt to overlay it with the following:

=> run loadfdt
65932 bytes read in 6 ms (10.5 MiB/s)
=> fdt addr $load_addr


When actually setting the address you will see a message "Working FDT
set to %lx\n". So I assume $load_addr is empty.

Did you mean $loadaddr or $fileaddr?


Opps, that was a copy-paste error.  Even with that, I still get the
failure to overlay:



Did you load a .dtbo file to apply? You cannot apply a devicetree.

Is the fdt that you want to apply the overlay to built with symbols (dtc 
parameter -@)?


Note that the fragment passed to U-Boot by upstream ATF is already
automatically merged into the U-Boot control DT (see
board/renesas/rcar-common/common.c ) . U-Boot should pass that on to
Linux automatically.


I ran some tests, and it appears the function fdtdec_board_setup is
never getting called.  That looks like the code that grabs the blob
from ATF.  I intentionally removed the memory nodes from the kernel
device tree expecting the memory nodes to get added from ATF, but when
I booted it, it promptly hung.  That implied to me that the memory
nodes didn't get added from ATF.

I added some debug code and noticed that ft_board_setup did not get
executed, so I created a call to fdtdec_board_setup from
ft_board_setup and my board booted just fine.  I am curious to know if
other rcar/rzg2 boards are seeing something similar?  Is calling
fdtdec_board_setup from ft_board_setup appropriate?


Note that fdtdec_board_setup() is called very early on when U-Boot
itself starts up and it is used to patch the fragment passed from ATF
into U-Boot control DT. The ft_board_setup() is called before booting
OS, i.e. at much later stage.

Can you maybe summarize what exactly it is that you're trying to pass
through , and from where to where ?


There is a reserved-memory node generated by ATF and I want to pass
that node to the Linux Kernel, so the memory is reserved, because
accessing the memory will cause Linux to crash.  I wanted to put the
reserved-memory node into the kernel dts file, but Geert asked me to
pass the blob from ATF instead of hard-coding it into the dts.
I am just trying to figure out how to make that happen, because it
appears the memory isn't being reserved.


So, can you check whether the U-Boot control DT does contain this
reserved memory node ?

=> fdt addr $fdtcontroladdr
=> fdt print /path/to/the/node


=> fdt addr $fdtcontroladdr
Working FDT set to bbedccb0
=> fdt print /reserved-memory
reserved-memory {
lossy-decompression@5400 {
compatible = "renesas,lossy-decompression", "shared-dma-pool";
reg = <0x 0x5400 0x 0x0300>;
no-map;
renesas,formats = <0x>;
};
};
=>

So it does appear that the reserved-memory is showing up here.

Is there a way to export just this node and append it to the kernel's DTB?


H, I would start digging around boot/image-fdt.c 
boot_fdt_add_mem_rsv_regions() .


Can you check in 'bdinfo' whether this lossy decomp area is already 
protected by LMB in U-Boot ?

Re: [PATCH v2 3/3] lmb: consider EFI memory map

2023-01-11 Thread Tom Rini

On Thu, Jan 12, 2023 at 12:35:15AM +0100, Heinrich Schuchardt wrote:
> 
> 
> On 1/11/23 23:59, Mark Kettenis wrote:
> > > From: Simon Glass 
> > > Date: Wed, 11 Jan 2023 14:08:27 -0700
> > 
> > Hi Simon,
> > 
> > > Hi Heinrich,
> > > 
> > > On Wed, 11 Jan 2023 at 11:03, Heinrich Schuchardt
> > >  wrote:
> > > > 
> > > > 
> > > > 
> > > > On 1/11/23 18:55, Simon Glass wrote:
> > > > > Hi Heinrich,
> > > > > 
> > > > > On Wed, 11 Jan 2023 at 09:59, Heinrich Schuchardt
> > > > >  wrote:
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > On 1/11/23 17:48, Simon Glass wrote:
> > > > > > > Hi,
> > > > > > > 
> > > > > > > On Wed, 11 Jan 2023 at 06:59, Tom Rini  wrote:
> > > > > > > > 
> > > > > > > > On Wed, Jan 11, 2023 at 08:43:37AM +0100, Heinrich Schuchardt 
> > > > > > > > wrote:
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > On 1/11/23 01:15, Simon Glass wrote:
> > > > > > > > > > Hi Heinrich,
> > > > > > > > > > 
> > > > > > > > > > On Mon, 9 Jan 2023 at 13:53, Heinrich Schuchardt
> > > > > > > > > >  wrote:
> > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > On 1/9/23 21:31, Simon Glass wrote:
> > > > > > > > > > > > Hi Mark,
> > > > > > > > > > > > 
> > > > > > > > > > > > On Mon, 9 Jan 2023 at 13:20, Mark Kettenis 
> > > > > > > > > > > >  wrote:
> > > > > > > > > > > > > 
> > > > > > > > > > > > > > From: Simon Glass 
> > > > > > > > > > > > > > Date: Mon, 9 Jan 2023 13:11:01 -0700
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > Hi Heinrich,
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > We need to fix how EFI does addresses. It seems to 
> > > > > > > > > > > > > > use them as
> > > > > > > > > > > > > > pointers but store them as u64 ?
> > > > > > > > > > > 
> > > > > > > > > > > That is similar to what you have been doing with physical 
> > > > > > > > > > > addresses.
> > > > > > > > > > > 
> > > > > > > > > > > > > 
> > > > > > > > > > > > > They're defined to a 64-bit unsigned integer by the 
> > > > > > > > > > > > > UEFI
> > > > > > > > > > > > > specification, so you can't change it.
> > > > > > > > > > > > 
> > > > > > > > > > > > I don't mean changing the spec, just changing the 
> > > > > > > > > > > > internal U-Boot
> > > > > > > > > > > > implementation, which is very confusing. This confusion 
> > > > > > > > > > > > is spreading
> > > > > > > > > > > > out, too.
> > > > > > > > > > > > 
> > > > > > > > > > > > Regards,
> > > > > > > > > > > > Simon
> > > > > > > > > > > 
> > > > > > > > > > > The real interesting thing is how memory should be 
> > > > > > > > > > > managed in U-Boot:
> > > > > > > > > > > 
> > > > > > > > > > > I would prefer to create a shared global memory 
> > > > > > > > > > > management on 4KiB page
> > > > > > > > > > > level used both for EFI and the rest of U-Boot.
> > > > > > > > > > 
> > > > > > > > > > Sounds good.
> > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > What EFI adds to the requirements is that you need more 
> > > > > > > > > > > than free
> > > > > > > > > > > (EfiConventionalMemory) and used memory. EFI knows 16 
> > > > > > > > > > > different types of
> > > > > > > > > > > memory usage (see enum efi_memory_type).
> > > > > > > > > > 
> > > > > > > > > > That's a shame. How much of this is legacy and how much is 
> > > > > > > > > > useful?
> > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > When loading a file (e.g. with the "load" command) this 
> > > > > > > > > > > should lead to a
> > > > > > > > > > > memory reservation. You should not be able to load a 
> > > > > > > > > > > second file into an
> > > > > > > > > > > overlapping memory area without releasing the allocated 
> > > > > > > > > > > memory first.
> > > > > > > > > > > 
> > > > > > > > > > > This would replace lmb which currently tries to 
> > > > > > > > > > > recalculate available
> > > > > > > > > > > memory ab initio again and again.
> > > > > > > > > > > 
> > > > > > > > > > > With managed memory we should be able to get rid of all 
> > > > > > > > > > > those constants
> > > > > > > > > > > like $loadaddr, $fdt_addr_r, $kernel_addr_r, etc. and 
> > > > > > > > > > > instead use a
> > > > > > > > > > > register of named loaded files.
> > > > > > > > > > 
> > > > > > > > > > This is where standard boot comes in, since it knows what 
> > > > > > > > > > it has
> > > > > > > > > > loaded and has pointers to it.
> > > > > > > > > > 
> > > > > > > > > > I see a future where we don't use these commands when we 
> > > > > > > > > > want to save
> > > > > > > > > > space. It can save 300KB from the U-Boot size.
> > > > > > > > > > 
> > > > > > > > > > But this really has to come later, since there is so much 
> > > > > > > > > > churn already!
> > > > > > > > > > 
> > > > > > > > > > For now, please don't add EFI allocation into lmb..that is 
> > > > > > > > > > just odd.
> > > > > > > > > 
> > > > > > > > > It is not odd but necessary. Without it the

Re: U-Boot v2023.01 broken on riscv64 qemu virt platform: "fdt fixup event failed"

2023-01-11 Thread Tom Rini

On Thu, Jan 12, 2023 at 01:16:43AM +0100, Heinrich Schuchardt wrote:
> On 1/12/23 01:04, Tom Rini wrote:
> > On Thu, Jan 12, 2023 at 01:01:55AM +0100, Heinrich Schuchardt wrote:
> > > On 1/12/23 00:59, Tom Rini wrote:
> > > > On Thu, Jan 12, 2023 at 12:40:05AM +0100, Heinrich Schuchardt wrote:
> > > > > On 1/12/23 00:29, Simon Glass wrote:
> > > > > > () Hi Heinrich,
> > > > > > 
> > > > > > On Wed, 11 Jan 2023 at 16:22, Heinrich Schuchardt 
> > > > > >  wrote:
> > > > > > > 
> > > > > > > On 1/11/23 20:08, Karsten Merker wrote:
> > > > > > > > Hello,
> > > > > > > > 
> > > > > > > > it looks like U-Boot v2023.01 is currently broken for the 
> > > > > > > > riscv64
> > > > > > > > architecture on the qemu "virt" platform; the boot process of a
> > > > > > > > riscv64 VM fails during FDT fixup:
> > > > > > > > 
> > > > > > > > -8<--8<--8<--8<--8<--8<-
> > > > > > > > 
> > > > > > > > OpenSBI v1.1
> > > > > > > >_  _
> > > > > > > >   / __ \  / |  _ \_   _|
> > > > > > > >  | |  | |_ __   ___ _ __ | (___ | |_) || |
> > > > > > > >  | |  | | '_ \ / _ \ '_ \ \___ \|  _ < | |
> > > > > > > >  | |__| | |_) |  __/ | | |) | |_) || |_
> > > > > > > >   \/| .__/ \___|_| |_|_/|/_|
> > > > > > > > | |
> > > > > > > > |_|
> > > > > > > > 
> > > > > > > > Platform Name : riscv-virtio,qemu
> > > > > > > > Platform Features : medeleg
> > > > > > > > Platform HART Count   : 4
> > > > > > > > Platform IPI Device   : aclint-mswi
> > > > > > > > Platform Timer Device : aclint-mtimer @ 1000Hz
> > > > > > > > Platform Console Device   : uart8250
> > > > > > > > Platform HSM Device   : ---
> > > > > > > > Platform Reboot Device: sifive_test
> > > > > > > > Platform Shutdown Device  : sifive_test
> > > > > > > > Firmware Base : 0x8000
> > > > > > > > Firmware Size : 312 KB
> > > > > > > > Runtime SBI Version   : 1.0
> > > > > > > > 
> > > > > > > > Domain0 Name  : root
> > > > > > > > Domain0 Boot HART : 2
> > > > > > > > Domain0 HARTs : 0*,1*,2*,3*
> > > > > > > > Domain0 Region00  : 
> > > > > > > > 0x0200-0x0200 (I)
> > > > > > > > Domain0 Region01  : 
> > > > > > > > 0x8000-0x8007 ()
> > > > > > > > Domain0 Region02  : 
> > > > > > > > 0x-0x (R,W,X)
> > > > > > > > Domain0 Next Address  : 0x8020
> > > > > > > > Domain0 Next Arg1 : 0x8220
> > > > > > > > Domain0 Next Mode : S-mode
> > > > > > > > Domain0 SysReset  : yes
> > > > > > > > 
> > > > > > > > Boot HART ID  : 2
> > > > > > > > Boot HART Domain  : root
> > > > > > > > Boot HART Priv Version: v1.12
> > > > > > > > Boot HART Base ISA: rv64imafdch
> > > > > > > > Boot HART ISA Extensions  : time,sstc
> > > > > > > > Boot HART PMP Count   : 16
> > > > > > > > Boot HART PMP Granularity : 4
> > > > > > > > Boot HART PMP Address Bits: 54
> > > > > > > > Boot HART MHPM Count  : 16
> > > > > > > > Boot HART MIDELEG : 0x1666
> > > > > > > > Boot HART MEDELEG : 0x00f0b509
> > > > > > > > 
> > > > > > > > 
> > > > > > > > U-Boot 2023.01+dfsg-1 (Jan 10 2023 - 03:18:09 +)
> > > > > > > > 
> > > > > > > > CPU:   
> > > > > > > > rv64imafdch_zicsr_zifencei_zihintpause_zba_zbb_zbc_zbs_sstc
> > > > > > > > Model: riscv-virtio,qemu
> > > > > > > > DRAM:  8 GiB
> > > > > > > > Core:  31 devices, 15 uclasses, devicetree: board
> > > > > > > > Flash: 32 MiB
> > > > > > > > Loading Environment from nowhere... OK
> > > > > > > > In:serial@1000
> > > > > > > > Out:   serial@1000
> > > > > > > > Err:   serial@1000
> > > > > > > > Net:   eth0: virtio-net#2
> > > > > > > > Working FDT set to ff7344b0
> > > > > > > > Hit any key to stop autoboot:  0
> > > > > > > > 
> > > > > > > > Device 0: QEMU VirtIO Block Device
> > > > > > > > Type: Hard Disk
> > > > > > > > Capacity: 102400.0 MB = 100.0 GB (209715200 x 
> > > > > > > > 512)
> > > > > > > > ... is now current device
> > > > > > > > Scanning virtio 0:1...
> > > > > > > > Found /boot/extlinux/extlinux.conf
> > > > > > > > Retrieving file: /boot/extlinux/extlinux.conf
> > > > > > > > U-Boot menu
> > > > > > > > 1:Debian GNU/Linux bookworm/sid 6.1.0-1-riscv64
> > > > > > > > 2:Debian GNU/Linux bookworm/sid 6.1.0-1-riscv64 (rescue 
> > > > > > > > target)
> > > > > > > > 3:Debian GNU/Linux bookworm/sid 6.0.0-6-riscv64
> > > > > > > > 4:Debian GNU/Linux bookworm/sid 6.0.0-6-riscv64 (rescue 
> > > > > > > > target)
> > > > > > > > 5:Debian GNU/Linux bookworm/sid 6.0.0-5-riscv64
> > > > > > > > 6:Debian GNU/Linux bookworm/sid 6.0.0-5-riscv64 (rescue 
> > > > > > > >

Re: U-Boot v2023.01 broken on riscv64 qemu virt platform: "fdt fixup event failed"

2023-01-11 Thread Heinrich Schuchardt


On 1/12/23 01:04, Tom Rini wrote:

On Thu, Jan 12, 2023 at 01:01:55AM +0100, Heinrich Schuchardt wrote:

On 1/12/23 00:59, Tom Rini wrote:

On Thu, Jan 12, 2023 at 12:40:05AM +0100, Heinrich Schuchardt wrote:

On 1/12/23 00:29, Simon Glass wrote:

() Hi Heinrich,

On Wed, 11 Jan 2023 at 16:22, Heinrich Schuchardt  wrote:


On 1/11/23 20:08, Karsten Merker wrote:

Hello,

it looks like U-Boot v2023.01 is currently broken for the riscv64
architecture on the qemu "virt" platform; the boot process of a
riscv64 VM fails during FDT fixup:

-8<--8<--8<--8<--8<--8<-

OpenSBI v1.1
   _  _
  / __ \  / |  _ \_   _|
 | |  | |_ __   ___ _ __ | (___ | |_) || |
 | |  | | '_ \ / _ \ '_ \ \___ \|  _ < | |
 | |__| | |_) |  __/ | | |) | |_) || |_
  \/| .__/ \___|_| |_|_/|/_|
| |
|_|

Platform Name : riscv-virtio,qemu
Platform Features : medeleg
Platform HART Count   : 4
Platform IPI Device   : aclint-mswi
Platform Timer Device : aclint-mtimer @ 1000Hz
Platform Console Device   : uart8250
Platform HSM Device   : ---
Platform Reboot Device: sifive_test
Platform Shutdown Device  : sifive_test
Firmware Base : 0x8000
Firmware Size : 312 KB
Runtime SBI Version   : 1.0

Domain0 Name  : root
Domain0 Boot HART : 2
Domain0 HARTs : 0*,1*,2*,3*
Domain0 Region00  : 0x0200-0x0200 (I)
Domain0 Region01  : 0x8000-0x8007 ()
Domain0 Region02  : 0x-0x (R,W,X)
Domain0 Next Address  : 0x8020
Domain0 Next Arg1 : 0x8220
Domain0 Next Mode : S-mode
Domain0 SysReset  : yes

Boot HART ID  : 2
Boot HART Domain  : root
Boot HART Priv Version: v1.12
Boot HART Base ISA: rv64imafdch
Boot HART ISA Extensions  : time,sstc
Boot HART PMP Count   : 16
Boot HART PMP Granularity : 4
Boot HART PMP Address Bits: 54
Boot HART MHPM Count  : 16
Boot HART MIDELEG : 0x1666
Boot HART MEDELEG : 0x00f0b509


U-Boot 2023.01+dfsg-1 (Jan 10 2023 - 03:18:09 +)

CPU:   rv64imafdch_zicsr_zifencei_zihintpause_zba_zbb_zbc_zbs_sstc
Model: riscv-virtio,qemu
DRAM:  8 GiB
Core:  31 devices, 15 uclasses, devicetree: board
Flash: 32 MiB
Loading Environment from nowhere... OK
In:serial@1000
Out:   serial@1000
Err:   serial@1000
Net:   eth0: virtio-net#2
Working FDT set to ff7344b0
Hit any key to stop autoboot:  0

Device 0: QEMU VirtIO Block Device
Type: Hard Disk
Capacity: 102400.0 MB = 100.0 GB (209715200 x 512)
... is now current device
Scanning virtio 0:1...
Found /boot/extlinux/extlinux.conf
Retrieving file: /boot/extlinux/extlinux.conf
U-Boot menu
1:Debian GNU/Linux bookworm/sid 6.1.0-1-riscv64
2:Debian GNU/Linux bookworm/sid 6.1.0-1-riscv64 (rescue target)
3:Debian GNU/Linux bookworm/sid 6.0.0-6-riscv64
4:Debian GNU/Linux bookworm/sid 6.0.0-6-riscv64 (rescue target)
5:Debian GNU/Linux bookworm/sid 6.0.0-5-riscv64
6:Debian GNU/Linux bookworm/sid 6.0.0-5-riscv64 (rescue target)
Enter choice: 1:  Debian GNU/Linux bookworm/sid 6.1.0-1-riscv64
Retrieving file: /boot/initrd.img-6.1.0-1-riscv64
Retrieving file: /boot/vmlinux-6.1.0-1-riscv64
append: root=/dev/vda1 rw noquiet
Moving Image from 0x8400 to 0x8020, end=815e5000
## Flattened Device Tree blob at ff7344b0
   Booting using the fdt blob at 0xff7344b0
Working FDT set to ff7344b0
   Using Device Tree in place at ff7344b0, end ff738dea
Working FDT set to ff7344b0
ERROR: fdt fixup event failed: -22
 - must RESET the board to recover.

FDT creation failed! hanging...### ERROR ### Please RESET the board ###

-8<--8<--8<--8<--8<--8<-

Software versions used:
- OpenSBI 1.1 (Debian package: opensbi 1.1-2)
- QEMU 7.2.0 (Debian package: qemu-system-misc 1:7.2+dfsg-1+b2)
- U-Boot v2023.01 (Debian package: u-boot-qemu 2023.01+dfsg-1)

The issue is independent from the kernel that gets booted.  With
U-Boot v2022.10 everything works without problems.  I have used
git bisect (with qemu-riscv64_smode_defconfig) to narrow down the
specific change that triggers the issue and that has resulted in
the following commit:

-8<--8<--8<--8<--8<--8<-

commit a56f663f07073713042bb0fd08053aeb667e717b (HEAD)
Author: Simon Glass 
Date:   Thu Oct 20 18:23:14 2022 -0600

vbe: Add info about the VBE device to the fwupd node

At present we put the driver in the /chosen node in U-Boot. This is a 
bit
strange, since U-Boot doesn't normally use that node itself. It is 
better
to put it under the bootstd node.

To make

Re: kernel doesn't start on Odroid U2 unless setting initrd_high

2023-01-11 Thread Tom Rini

On Wed, Jan 11, 2023 at 10:08:59PM +0100, Joost van Zwieten wrote:
> 
> 
> On Wed, Jan 11, 2023 at 15:38, Tom Rini  wrote:
> > On Wed, Jan 11, 2023 at 09:28:42PM +0100, Joost van Zwieten wrote:
> > > 
> > > 
> > >  On Tue, Jan 10, 2023 at 18:29, Tom Rini  wrote:
> > >  > On Wed, Jan 11, 2023 at 12:10:42AM +0100, Joost van Zwieten wrote:
> > >  > >
> > >  > >
> > >  > >  On Tue, Jan 10, 2023 at 18:08, Tom Rini 
> > > wrote:
> > >  > >  > On Wed, Jan 11, 2023 at 12:01:46AM +0100, Joost van Zwieten
> > > wrote:
> > >  > >  > >
> > >  > >  > >
> > >  > >  > >  On Tue, Jan 10, 2023 at 13:41, Tom Rini
> > > 
> > >  > > wrote:
> > >  > >  > >  > On Tue, Jan 10, 2023 at 09:13:32AM +0100, Joost van
> > > Zwieten
> > >  > > wrote:
> > >  > >  > >  >
> > >  > >  > >  > >  Dear maintainers,
> > >  > >  > >  > >
> > >  > >  > >  > >  As of commit 4963f63fe61f15329d77472a762b1d8bf754d24b
> > >  > > U-Boot
> > >  > >  > > fails
> > >  > >  > >  > > to start
> > >  > >  > >  > >  a kernel (with `bootz`) on my Odroid U2 unless I
> > > force
> > >  > >  > >  > > `initrd_high`, e.g.
> > >  > >  > >  > >  to `0x5000`. With commit 4963f63f and
> > > `initrd_high`
> > >  > >  > > *unset* I
> > >  > >  > >  > > get the
> > >  > >  > >  > >  following output:
> > >  > >  > >  > >
> > >  > >  > >  > > U-Boot 2020.10-rc2-00314-g4963f63fe6 (Jan 09 2023
> > > -
> > >  > > 23:59:31
> > >  > >  > >  > > +0100)
> > >  > >  > >  > >
> > >  > >  > >  > > CPU: Exynos4412 @ 1 GHz
> > >  > >  > >  > > Model: Odroid based on Exynos4412
> > >  > >  > >  > > Type: u3
> > >  > >  > >  > > DRAM: 2 GiB
> > >  > >  > >  > > LDO20@VDDQ_EMMC_1.8V: set 180 uV; enabling
> > >  > >  > >  > > LDO22@VDDQ_EMMC_2.8V: set 280 uV; enabling
> > >  > >  > >  > > LDO21@TFLASH_2.8V: set 280 uV; enabling
> > >  > >  > >  > > MMC: SAMSUNG SDHCI: 2, EXYNOS DWMMC: 0
> > >  > >  > >  > > Loading Environment from MMC... *** Warning - bad
> > > CRC,
> > >  > > using
> > >  > >  > >  > > default
> > >  > >  > >  > >  environment
> > >  > >  > >  > >
> > >  > >  > >  > > In: serial
> > >  > >  > >  > > Out: serial
> > >  > >  > >  > > Err: serial
> > >  > >  > >  > > Boot device: MMC(2)
> > >  > >  > >  > > Net: No ethernet found.
> > >  > >  > >  > > Hit any key to stop autoboot: 0
> > >  > >  > >  > > Odroid # env set fk_kvers 5.10.0-20-armmp
> > >  > >  > >  > > Odroid # load mmc ${mmcbootdev}:${mmcbootpart}
> > >  > > ${fdt_addr_r}
> > >  > >  > >  > >  /boot/dtbs/${fk_kvers}/exynos4412-odroidu3.dtb
> > >  > >  > >  > > 53440 bytes read in 50 ms (1 MiB/s)
> > >  > >  > >  > > Odroid # load mmc ${mmcbootdev}:${mmcbootpart}
> > >  > >  > > ${kernel_addr_r}
> > >  > >  > >  > >  /boot/vmlinuz-${fk_kvers}
> > >  > >  > >  > > 4973056 bytes read in 182 ms (26.1 MiB/s)
> > >  > >  > >  > > Odroid # load mmc ${mmcbootdev}:${mmcbootpart}
> > >  > >  > > ${ramdisk_addr_r}
> > >  > >  > >  > >  /boot/initrd.img-${fk_kvers}
> > >  > >  > >  > > 22231585 bytes read in 777 ms (27.3 MiB/s)
> > >  > >  > >  > > Odroid # env set bootargs console=ttySAC1,115200n8
> > >  > >  > >  > > Odroid # bootz ${kernel_addr_r}
> > >  > >  > > ${ramdisk_addr_r}:${filesize}
> > >  > >  > >  > >  ${fdt_addr_r}
> > >  > >  > >  > > Kernel image @ 0x4100 [ 0x00 - 0x4be200 ]
> > >  > >  > >  > > ## Flattened Device Tree blob at 4080
> > >  > >  > >  > >Booting using the fdt blob at 0x4080
> > >  > >  > >  > >Loading Ramdisk to b9947000, end bae7aa21 ...
> > > OK
> > >  > >  > >  > >Loading Device Tree to b9936000, end b99460bf
> > > ... OK
> > >  > >  > >  > >
> > >  > >  > >  > > Starting kernel ...
> > >  > >  > >  > >
> > >  > >  > >  > >  And that's all I ever see. Normally the initrd loads
> > > a
> > >  > > module
> > >  > >  > > that
> > >  > >  > >  > > causes an
> > >  > >  > >  > >  LED on the Odroid to blink, and this is not happening
> > >  > > either,
> > >  > >  > > so
> > >  > >  > >  > > I'm pretty
> > >  > >  > >  > >  confident the kernel doesn't start or at least
> > > crashes
> > >  > > before
> > >  > >  > >  > > producing
> > >  > >  > >  > >  output. If I set `initrd_high` to `0x5000` (or
> > >  > > something
> > >  > >  > > in the
> > >  > >  > >  > >  neighborhood) the kernel starts just fine:
> > >  > >  > >  > >
> > >  > >  > >  > > U-Boot 2020.10-rc2-00314-g4963f63fe6 (Jan 09 2023
> > > -
> > >  > > 23:59:31
> > >  > >  > >  > > +0100)
> > >  > >  > >  > >
> > >  > >  > >  > > CPU: Exynos4412 @ 1 GHz
> > >  > >  > >  > > Model: Odroid based on Exynos4412
> > >  > >  > >  > > Type: u3
> > >  > >  > >  > > DRAM: 2 GiB
> > >  > >  > >  > > LDO20@VDDQ_EMMC_1.8V: set 180 uV; enabling
> > >  > >  > >  > > LDO22@VDDQ_EMMC_2.8V: set 280 uV; enabling
> > >  > >  > >  > > LDO21@TFLASH_2.8V: set 280 uV; enabling
> > >  > >  > >  > > MMC: SAMSUNG SDHCI: 2, EXYNOS DWMMC:

Re: U-Boot v2023.01 broken on riscv64 qemu virt platform: "fdt fixup event failed"

2023-01-11 Thread Tom Rini

On Thu, Jan 12, 2023 at 01:01:55AM +0100, Heinrich Schuchardt wrote:
> On 1/12/23 00:59, Tom Rini wrote:
> > On Thu, Jan 12, 2023 at 12:40:05AM +0100, Heinrich Schuchardt wrote:
> > > On 1/12/23 00:29, Simon Glass wrote:
> > > > () Hi Heinrich,
> > > > 
> > > > On Wed, 11 Jan 2023 at 16:22, Heinrich Schuchardt  
> > > > wrote:
> > > > > 
> > > > > On 1/11/23 20:08, Karsten Merker wrote:
> > > > > > Hello,
> > > > > > 
> > > > > > it looks like U-Boot v2023.01 is currently broken for the riscv64
> > > > > > architecture on the qemu "virt" platform; the boot process of a
> > > > > > riscv64 VM fails during FDT fixup:
> > > > > > 
> > > > > > -8<--8<--8<--8<--8<--8<-
> > > > > > 
> > > > > > OpenSBI v1.1
> > > > > >   _  _
> > > > > >  / __ \  / |  _ \_   _|
> > > > > > | |  | |_ __   ___ _ __ | (___ | |_) || |
> > > > > > | |  | | '_ \ / _ \ '_ \ \___ \|  _ < | |
> > > > > > | |__| | |_) |  __/ | | |) | |_) || |_
> > > > > >  \/| .__/ \___|_| |_|_/|/_|
> > > > > >| |
> > > > > >|_|
> > > > > > 
> > > > > > Platform Name : riscv-virtio,qemu
> > > > > > Platform Features : medeleg
> > > > > > Platform HART Count   : 4
> > > > > > Platform IPI Device   : aclint-mswi
> > > > > > Platform Timer Device : aclint-mtimer @ 1000Hz
> > > > > > Platform Console Device   : uart8250
> > > > > > Platform HSM Device   : ---
> > > > > > Platform Reboot Device: sifive_test
> > > > > > Platform Shutdown Device  : sifive_test
> > > > > > Firmware Base : 0x8000
> > > > > > Firmware Size : 312 KB
> > > > > > Runtime SBI Version   : 1.0
> > > > > > 
> > > > > > Domain0 Name  : root
> > > > > > Domain0 Boot HART : 2
> > > > > > Domain0 HARTs : 0*,1*,2*,3*
> > > > > > Domain0 Region00  : 0x0200-0x0200 
> > > > > > (I)
> > > > > > Domain0 Region01  : 0x8000-0x8007 ()
> > > > > > Domain0 Region02  : 0x-0x 
> > > > > > (R,W,X)
> > > > > > Domain0 Next Address  : 0x8020
> > > > > > Domain0 Next Arg1 : 0x8220
> > > > > > Domain0 Next Mode : S-mode
> > > > > > Domain0 SysReset  : yes
> > > > > > 
> > > > > > Boot HART ID  : 2
> > > > > > Boot HART Domain  : root
> > > > > > Boot HART Priv Version: v1.12
> > > > > > Boot HART Base ISA: rv64imafdch
> > > > > > Boot HART ISA Extensions  : time,sstc
> > > > > > Boot HART PMP Count   : 16
> > > > > > Boot HART PMP Granularity : 4
> > > > > > Boot HART PMP Address Bits: 54
> > > > > > Boot HART MHPM Count  : 16
> > > > > > Boot HART MIDELEG : 0x1666
> > > > > > Boot HART MEDELEG : 0x00f0b509
> > > > > > 
> > > > > > 
> > > > > > U-Boot 2023.01+dfsg-1 (Jan 10 2023 - 03:18:09 +)
> > > > > > 
> > > > > > CPU:   rv64imafdch_zicsr_zifencei_zihintpause_zba_zbb_zbc_zbs_sstc
> > > > > > Model: riscv-virtio,qemu
> > > > > > DRAM:  8 GiB
> > > > > > Core:  31 devices, 15 uclasses, devicetree: board
> > > > > > Flash: 32 MiB
> > > > > > Loading Environment from nowhere... OK
> > > > > > In:serial@1000
> > > > > > Out:   serial@1000
> > > > > > Err:   serial@1000
> > > > > > Net:   eth0: virtio-net#2
> > > > > > Working FDT set to ff7344b0
> > > > > > Hit any key to stop autoboot:  0
> > > > > > 
> > > > > > Device 0: QEMU VirtIO Block Device
> > > > > >Type: Hard Disk
> > > > > >Capacity: 102400.0 MB = 100.0 GB (209715200 x 512)
> > > > > > ... is now current device
> > > > > > Scanning virtio 0:1...
> > > > > > Found /boot/extlinux/extlinux.conf
> > > > > > Retrieving file: /boot/extlinux/extlinux.conf
> > > > > > U-Boot menu
> > > > > > 1:Debian GNU/Linux bookworm/sid 6.1.0-1-riscv64
> > > > > > 2:Debian GNU/Linux bookworm/sid 6.1.0-1-riscv64 (rescue target)
> > > > > > 3:Debian GNU/Linux bookworm/sid 6.0.0-6-riscv64
> > > > > > 4:Debian GNU/Linux bookworm/sid 6.0.0-6-riscv64 (rescue target)
> > > > > > 5:Debian GNU/Linux bookworm/sid 6.0.0-5-riscv64
> > > > > > 6:Debian GNU/Linux bookworm/sid 6.0.0-5-riscv64 (rescue target)
> > > > > > Enter choice: 1:  Debian GNU/Linux bookworm/sid 6.1.0-1-riscv64
> > > > > > Retrieving file: /boot/initrd.img-6.1.0-1-riscv64
> > > > > > Retrieving file: /boot/vmlinux-6.1.0-1-riscv64
> > > > > > append: root=/dev/vda1 rw noquiet
> > > > > > Moving Image from 0x8400 to 0x8020, end=815e5000
> > > > > > ## Flattened Device Tree blob at ff7344b0
> > > > > >   Booting using the fdt blob at 0xff7344b0
> > > > > > Working FDT set to ff7344b0
> > > > > >   Using Device Tree in place at ff7344b0, end 
> > > > > > ff738dea
> > > > > > Working FDT set to ff7344b0
> >

Re: U-Boot v2023.01 broken on riscv64 qemu virt platform: "fdt fixup event failed"

2023-01-11 Thread Heinrich Schuchardt

On 1/12/23 00:42, Simon Glass wrote:

Hi Heinrich,

Thanks Karsten for reporting the issue.

Bisection points to Simon's patch:

a56f663f0707371
vbe: Add info about the VBE device to the fwupd node

In bootmeth_vbe_simple_ft_fixup() probing device vbe_simple fails
because all fwupd related properties are missing in the QEMU device-tree.

The following change is enough to make QEMU boot again:

CONFIG_BOOTMETH_VBE=n

@Simon:

CONFIG_BOOTMETH_VBE should default to 'no' as only the sandbox provides
the required data in the devicetree. Or bootmeth_vbe_simple_ft_fixup()
should ignore a failure to probe vbe_simple.

It is supposed to ignore that failure. Could it be that there is a bug
in vbe_find_next_device() that it should set *devp to NULL when it
doesn't find anything?

The vbe_simple device exists on qemu-riscv64_smode_defconfig but cannot
be probed.

OK, so setting *devp = NULL before the last 'return 0' might help?

It is not clear to me what you want to change. Could you send a patch
for testing, please.

You can start qemu-riscv64_smode_defconfig on QEMU 7.0 or higher with

qemu-system-riscv64 \
-machine virt -nographic -m 2048 -smp 4 \
-kernel u-boot.bin \
-device virtio-net-device,netdev=eth0 -netdev user,id=eth0 \
-drive file=disk.img,format=raw,if=virtio

You could use this disk image:
https://cdimage.ubuntu.com/releases/22.10/release/ubuntu-22.10-preinstalled-server-riscv64+unmatched.img.xz
after extraction.

Best regards

Heinrich

How come this failure does not show in CI?

We currently lack tests to actually start a binary via the Linux legacy
entry point.

Ah OK, so the fixup never runs.

Regards,
Simon

Re: U-Boot v2023.01 broken on riscv64 qemu virt platform: "fdt fixup event failed"

2023-01-11 Thread Heinrich Schuchardt


On 1/12/23 00:59, Tom Rini wrote:

On Thu, Jan 12, 2023 at 12:40:05AM +0100, Heinrich Schuchardt wrote:

On 1/12/23 00:29, Simon Glass wrote:

() Hi Heinrich,

On Wed, 11 Jan 2023 at 16:22, Heinrich Schuchardt  wrote:


On 1/11/23 20:08, Karsten Merker wrote:

Hello,

it looks like U-Boot v2023.01 is currently broken for the riscv64
architecture on the qemu "virt" platform; the boot process of a
riscv64 VM fails during FDT fixup:

-8<--8<--8<--8<--8<--8<-

OpenSBI v1.1
  _  _
 / __ \  / |  _ \_   _|
| |  | |_ __   ___ _ __ | (___ | |_) || |
| |  | | '_ \ / _ \ '_ \ \___ \|  _ < | |
| |__| | |_) |  __/ | | |) | |_) || |_
 \/| .__/ \___|_| |_|_/|/_|
   | |
   |_|

Platform Name : riscv-virtio,qemu
Platform Features : medeleg
Platform HART Count   : 4
Platform IPI Device   : aclint-mswi
Platform Timer Device : aclint-mtimer @ 1000Hz
Platform Console Device   : uart8250
Platform HSM Device   : ---
Platform Reboot Device: sifive_test
Platform Shutdown Device  : sifive_test
Firmware Base : 0x8000
Firmware Size : 312 KB
Runtime SBI Version   : 1.0

Domain0 Name  : root
Domain0 Boot HART : 2
Domain0 HARTs : 0*,1*,2*,3*
Domain0 Region00  : 0x0200-0x0200 (I)
Domain0 Region01  : 0x8000-0x8007 ()
Domain0 Region02  : 0x-0x (R,W,X)
Domain0 Next Address  : 0x8020
Domain0 Next Arg1 : 0x8220
Domain0 Next Mode : S-mode
Domain0 SysReset  : yes

Boot HART ID  : 2
Boot HART Domain  : root
Boot HART Priv Version: v1.12
Boot HART Base ISA: rv64imafdch
Boot HART ISA Extensions  : time,sstc
Boot HART PMP Count   : 16
Boot HART PMP Granularity : 4
Boot HART PMP Address Bits: 54
Boot HART MHPM Count  : 16
Boot HART MIDELEG : 0x1666
Boot HART MEDELEG : 0x00f0b509


U-Boot 2023.01+dfsg-1 (Jan 10 2023 - 03:18:09 +)

CPU:   rv64imafdch_zicsr_zifencei_zihintpause_zba_zbb_zbc_zbs_sstc
Model: riscv-virtio,qemu
DRAM:  8 GiB
Core:  31 devices, 15 uclasses, devicetree: board
Flash: 32 MiB
Loading Environment from nowhere... OK
In:serial@1000
Out:   serial@1000
Err:   serial@1000
Net:   eth0: virtio-net#2
Working FDT set to ff7344b0
Hit any key to stop autoboot:  0

Device 0: QEMU VirtIO Block Device
   Type: Hard Disk
   Capacity: 102400.0 MB = 100.0 GB (209715200 x 512)
... is now current device
Scanning virtio 0:1...
Found /boot/extlinux/extlinux.conf
Retrieving file: /boot/extlinux/extlinux.conf
U-Boot menu
1:Debian GNU/Linux bookworm/sid 6.1.0-1-riscv64
2:Debian GNU/Linux bookworm/sid 6.1.0-1-riscv64 (rescue target)
3:Debian GNU/Linux bookworm/sid 6.0.0-6-riscv64
4:Debian GNU/Linux bookworm/sid 6.0.0-6-riscv64 (rescue target)
5:Debian GNU/Linux bookworm/sid 6.0.0-5-riscv64
6:Debian GNU/Linux bookworm/sid 6.0.0-5-riscv64 (rescue target)
Enter choice: 1:  Debian GNU/Linux bookworm/sid 6.1.0-1-riscv64
Retrieving file: /boot/initrd.img-6.1.0-1-riscv64
Retrieving file: /boot/vmlinux-6.1.0-1-riscv64
append: root=/dev/vda1 rw noquiet
Moving Image from 0x8400 to 0x8020, end=815e5000
## Flattened Device Tree blob at ff7344b0
  Booting using the fdt blob at 0xff7344b0
Working FDT set to ff7344b0
  Using Device Tree in place at ff7344b0, end ff738dea
Working FDT set to ff7344b0
ERROR: fdt fixup event failed: -22
- must RESET the board to recover.

FDT creation failed! hanging...### ERROR ### Please RESET the board ###

-8<--8<--8<--8<--8<--8<-

Software versions used:
- OpenSBI 1.1 (Debian package: opensbi 1.1-2)
- QEMU 7.2.0 (Debian package: qemu-system-misc 1:7.2+dfsg-1+b2)
- U-Boot v2023.01 (Debian package: u-boot-qemu 2023.01+dfsg-1)

The issue is independent from the kernel that gets booted.  With
U-Boot v2022.10 everything works without problems.  I have used
git bisect (with qemu-riscv64_smode_defconfig) to narrow down the
specific change that triggers the issue and that has resulted in
the following commit:

-8<--8<--8<--8<--8<--8<-

commit a56f663f07073713042bb0fd08053aeb667e717b (HEAD)
Author: Simon Glass 
Date:   Thu Oct 20 18:23:14 2022 -0600

   vbe: Add info about the VBE device to the fwupd node

   At present we put the driver in the /chosen node in U-Boot. This is a bit
   strange, since U-Boot doesn't normally use that node itself. It is better
   to put it under the bootstd node.

   To make this work we need to copy create the node under /chosen when
   fixing up the device tree. Copy over all the properties

Re: U-Boot v2023.01 broken on riscv64 qemu virt platform: "fdt fixup event failed"

2023-01-11 Thread Tom Rini

On Thu, Jan 12, 2023 at 12:40:05AM +0100, Heinrich Schuchardt wrote:
> On 1/12/23 00:29, Simon Glass wrote:
> > () Hi Heinrich,
> > 
> > On Wed, 11 Jan 2023 at 16:22, Heinrich Schuchardt  
> > wrote:
> > > 
> > > On 1/11/23 20:08, Karsten Merker wrote:
> > > > Hello,
> > > > 
> > > > it looks like U-Boot v2023.01 is currently broken for the riscv64
> > > > architecture on the qemu "virt" platform; the boot process of a
> > > > riscv64 VM fails during FDT fixup:
> > > > 
> > > > -8<--8<--8<--8<--8<--8<-
> > > > 
> > > > OpenSBI v1.1
> > > >  _  _
> > > > / __ \  / |  _ \_   _|
> > > >| |  | |_ __   ___ _ __ | (___ | |_) || |
> > > >| |  | | '_ \ / _ \ '_ \ \___ \|  _ < | |
> > > >| |__| | |_) |  __/ | | |) | |_) || |_
> > > > \/| .__/ \___|_| |_|_/|/_|
> > > >   | |
> > > >   |_|
> > > > 
> > > > Platform Name : riscv-virtio,qemu
> > > > Platform Features : medeleg
> > > > Platform HART Count   : 4
> > > > Platform IPI Device   : aclint-mswi
> > > > Platform Timer Device : aclint-mtimer @ 1000Hz
> > > > Platform Console Device   : uart8250
> > > > Platform HSM Device   : ---
> > > > Platform Reboot Device: sifive_test
> > > > Platform Shutdown Device  : sifive_test
> > > > Firmware Base : 0x8000
> > > > Firmware Size : 312 KB
> > > > Runtime SBI Version   : 1.0
> > > > 
> > > > Domain0 Name  : root
> > > > Domain0 Boot HART : 2
> > > > Domain0 HARTs : 0*,1*,2*,3*
> > > > Domain0 Region00  : 0x0200-0x0200 (I)
> > > > Domain0 Region01  : 0x8000-0x8007 ()
> > > > Domain0 Region02  : 0x-0x 
> > > > (R,W,X)
> > > > Domain0 Next Address  : 0x8020
> > > > Domain0 Next Arg1 : 0x8220
> > > > Domain0 Next Mode : S-mode
> > > > Domain0 SysReset  : yes
> > > > 
> > > > Boot HART ID  : 2
> > > > Boot HART Domain  : root
> > > > Boot HART Priv Version: v1.12
> > > > Boot HART Base ISA: rv64imafdch
> > > > Boot HART ISA Extensions  : time,sstc
> > > > Boot HART PMP Count   : 16
> > > > Boot HART PMP Granularity : 4
> > > > Boot HART PMP Address Bits: 54
> > > > Boot HART MHPM Count  : 16
> > > > Boot HART MIDELEG : 0x1666
> > > > Boot HART MEDELEG : 0x00f0b509
> > > > 
> > > > 
> > > > U-Boot 2023.01+dfsg-1 (Jan 10 2023 - 03:18:09 +)
> > > > 
> > > > CPU:   rv64imafdch_zicsr_zifencei_zihintpause_zba_zbb_zbc_zbs_sstc
> > > > Model: riscv-virtio,qemu
> > > > DRAM:  8 GiB
> > > > Core:  31 devices, 15 uclasses, devicetree: board
> > > > Flash: 32 MiB
> > > > Loading Environment from nowhere... OK
> > > > In:serial@1000
> > > > Out:   serial@1000
> > > > Err:   serial@1000
> > > > Net:   eth0: virtio-net#2
> > > > Working FDT set to ff7344b0
> > > > Hit any key to stop autoboot:  0
> > > > 
> > > > Device 0: QEMU VirtIO Block Device
> > > >   Type: Hard Disk
> > > >   Capacity: 102400.0 MB = 100.0 GB (209715200 x 512)
> > > > ... is now current device
> > > > Scanning virtio 0:1...
> > > > Found /boot/extlinux/extlinux.conf
> > > > Retrieving file: /boot/extlinux/extlinux.conf
> > > > U-Boot menu
> > > > 1:Debian GNU/Linux bookworm/sid 6.1.0-1-riscv64
> > > > 2:Debian GNU/Linux bookworm/sid 6.1.0-1-riscv64 (rescue target)
> > > > 3:Debian GNU/Linux bookworm/sid 6.0.0-6-riscv64
> > > > 4:Debian GNU/Linux bookworm/sid 6.0.0-6-riscv64 (rescue target)
> > > > 5:Debian GNU/Linux bookworm/sid 6.0.0-5-riscv64
> > > > 6:Debian GNU/Linux bookworm/sid 6.0.0-5-riscv64 (rescue target)
> > > > Enter choice: 1:  Debian GNU/Linux bookworm/sid 6.1.0-1-riscv64
> > > > Retrieving file: /boot/initrd.img-6.1.0-1-riscv64
> > > > Retrieving file: /boot/vmlinux-6.1.0-1-riscv64
> > > > append: root=/dev/vda1 rw noquiet
> > > > Moving Image from 0x8400 to 0x8020, end=815e5000
> > > > ## Flattened Device Tree blob at ff7344b0
> > > >  Booting using the fdt blob at 0xff7344b0
> > > > Working FDT set to ff7344b0
> > > >  Using Device Tree in place at ff7344b0, end 
> > > > ff738dea
> > > > Working FDT set to ff7344b0
> > > > ERROR: fdt fixup event failed: -22
> > > >- must RESET the board to recover.
> > > > 
> > > > FDT creation failed! hanging...### ERROR ### Please RESET the board ###
> > > > 
> > > > -8<--8<--8<--8<--8<--8<-
> > > > 
> > > > Software versions used:
> > > > - OpenSBI 1.1 (Debian package: opensbi 1.1-2)
> > > > - QEMU 7.2.0 (Debian package: qemu-system-misc 1:7.2+dfsg-1+b2)
> > > > - U-Boot v2023.01 (Debian package: u-boot-qemu 2023.01+dfsg-1)
> > > > 
> > > > The issue is independent

97 matches

Mail list logo