Re: [RFC] Load U-Boot without LK on DragonBoard 410c (+ DB820c?)
On Sun, Jul 4, 2021 at 12:42 AM Stephan Gerhold wrote:
>
> On Thu, Jul 01, 2021 at 11:07:55AM +0200, Stephan Gerhold wrote:
> > Hi!
> >
> > at the moment the U-Boot ports for both DragonBoard 410c and 820c are
> > designed to be loaded as an Android boot image after Qualcomm's LK
> > bootloader. This is simple to set up but LK is redundant in this case,
> > since everything done by LK can be also done directly by U-Boot.
> >
> > Dropping LK entirely would have at least the following advantages:
> > - Easier installation/board code (no need for Android boot images)
> > - (Slightly) faster boot
> > - Boot directly in 64-bit without a round trip to 32-bit for LK
> >
> > [...]
> >
> > 3. Remaining open questions
> > ===
> >
> > [...]
> >
> > 3. CONFIG_OF_EMBED: There is a big warning about this in the build log:
> > "This option should only be used for debugging purposes. Please use
> > CONFIG_OF_SEPARATE for boards in mainline."
> >
> > The important part here is that we need an ELF image with both
> > U-Boot and the DTB. CONFIG_OF_EMBED is convenient for that because
> > we can just use the ELF image built by the linker and it already
> > contains the DTB.
> >
> > If CONFIG_OF_EMBED is really so bad it might be possible to build
> > a new boot image based on "u-boot-dtb.bin" (which is U-Boot with
> > DTB appended). I'm not sure if this is really much better though.
> >
>
> After looking some more I found "CONFIG_REMAKE_ELF" which seems to do
> exactly this (build a new ELF image based on "u-boot-dtb.bin" with
> appended DTB). So this avoids setting CONFIG_OF_EMBED and therefore the
> build warning. Sounds like the solution I was looking for. :)
>
> Unfortunately it looks like appending the DTB to U-Boot currently
> produces very strange behavior on DragonBoard 410c. It's either:
>
> - Working fine, or
> - Rebooting continously without serial output from U-Boot, or
> - The following serial output:
>
> Qualcomm-DragonBoard 410C
> DRAM: 986 MiB
> No serial driver found
> resetting ...
>
> It behaves consistently given a U-Boot binary but varies when
> adding/removing random features from the U-Boot binary.
>
> After a couple of hours of debugging, I realized that the appended DTB
> becomes corrupted. Specifically, there is a "GPIO_5" written into it, e.g.
>
> 8f6905b8: edfe0dd0 9f10 4f495047 c000355fGPIO_5..
> 8f6905c8: 2800 1100 1000 ...(
> 8f6905d8: df01 880e
> 8f6905e8: 0100
> 8f6905f8: 0300 0400 0200
> 8f690608: 0300 0400 0f00 0200
> 8f690618: 0300 2d00 1b00 6c617551...-Qual
> 8f690628: 6d6d6f63 63655420 6c6f6e68 6569676fcomm Technologie
>
> Depending on enabled features in U-Boot the "GPIO_5" corrupts different
> parts of the DTB, that's why it works somewhat sometimes.
>
> After staring at some drivers and the U-Boot linker script for a while
> I realized that the BSS section overlaps with the appended DTB before
> relocation. And indeed, mach-snapdragon/pinctrl-apq8016.c writes "GPIO_5"
> into "static char pin_name[MAX_PIN_NAME_LEN];" (= BSS) before relocation.
>
> Actually, arch/arm/lib/crt0_64.S says that BSS should not be used at all
> before relocation, because it's uninitialized and might corrupt other
> memory. I found several other commits where similar problems happened
> and it was usually fixed by moving the variables into the data section.
>
> So, I fixed the problem with the diff below and will include it together
> with the changes to drop all the LK-related code. Now everything seems
> fine. (I just wish this would have somehow been more obvious instead of
> the strange behavior...)
>
> Stephan
>
> diff --git a/arch/arm/mach-snapdragon/pinctrl-apq8016.c
> b/arch/arm/mach-snapdragon/pinctrl-apq8016.c
> index 1042b564c3..7940c74287 100644
> --- a/arch/arm/mach-snapdragon/pinctrl-apq8016.c
> +++ b/arch/arm/mach-snapdragon/pinctrl-apq8016.c
> @@ -10,7 +10,7 @@
> #include
>
> #define MAX_PIN_NAME_LEN 32
> -static char pin_name[MAX_PIN_NAME_LEN];
> +static char pin_name[MAX_PIN_NAME_LEN] __section(".data");
> static const char * const msm_pinctrl_pins[] = {
> "SDC1_CLK",
> "SDC1_CMD",
>
Hi.
If I recall correctly, the signing tool only used the ELF sections, so
the appended DTB was deleted.
That's why I kept the "embedded DTB".
In your signing tool, you probably sign the complete file without
parsing the ELF.
Thanks,
Ramon.
Re: [RFC] Load U-Boot without LK on DragonBoard 410c (+ DB820c?)
On Sun, Jul 04, 2021 at 02:08:39PM +0300, Ramon Fried wrote:
> On Sun, Jul 4, 2021 at 12:42 AM Stephan Gerhold wrote:
> >
> > On Thu, Jul 01, 2021 at 11:07:55AM +0200, Stephan Gerhold wrote:
> > > Hi!
> > >
> > > at the moment the U-Boot ports for both DragonBoard 410c and 820c are
> > > designed to be loaded as an Android boot image after Qualcomm's LK
> > > bootloader. This is simple to set up but LK is redundant in this case,
> > > since everything done by LK can be also done directly by U-Boot.
> > >
> > > Dropping LK entirely would have at least the following advantages:
> > > - Easier installation/board code (no need for Android boot images)
> > > - (Slightly) faster boot
> > > - Boot directly in 64-bit without a round trip to 32-bit for LK
> > >
> > > [...]
> > >
> > > 3. Remaining open questions
> > > ===
> > >
> > > [...]
> > >
> > > 3. CONFIG_OF_EMBED: There is a big warning about this in the build log:
> > > "This option should only be used for debugging purposes. Please use
> > > CONFIG_OF_SEPARATE for boards in mainline."
> > >
> > > The important part here is that we need an ELF image with both
> > > U-Boot and the DTB. CONFIG_OF_EMBED is convenient for that because
> > > we can just use the ELF image built by the linker and it already
> > > contains the DTB.
> > >
> > > If CONFIG_OF_EMBED is really so bad it might be possible to build
> > > a new boot image based on "u-boot-dtb.bin" (which is U-Boot with
> > > DTB appended). I'm not sure if this is really much better though.
> > >
> >
> > After looking some more I found "CONFIG_REMAKE_ELF" which seems to do
> > exactly this (build a new ELF image based on "u-boot-dtb.bin" with
> > appended DTB). So this avoids setting CONFIG_OF_EMBED and therefore the
> > build warning. Sounds like the solution I was looking for. :)
> >
> > Unfortunately it looks like appending the DTB to U-Boot currently
> > produces very strange behavior on DragonBoard 410c. It's either:
> >
> > - Working fine, or
> > - Rebooting continously without serial output from U-Boot, or
> > - The following serial output:
> >
> > Qualcomm-DragonBoard 410C
> > DRAM: 986 MiB
> > No serial driver found
> > resetting ...
> >
> > It behaves consistently given a U-Boot binary but varies when
> > adding/removing random features from the U-Boot binary.
> >
> > After a couple of hours of debugging, I realized that the appended DTB
> > becomes corrupted. Specifically, there is a "GPIO_5" written into it, e.g.
> >
> > 8f6905b8: edfe0dd0 9f10 4f495047 c000355fGPIO_5..
> > 8f6905c8: 2800 1100 1000 ...(
> > 8f6905d8: df01 880e
> > 8f6905e8: 0100
> > 8f6905f8: 0300 0400 0200
> > 8f690608: 0300 0400 0f00 0200
> > 8f690618: 0300 2d00 1b00 6c617551...-Qual
> > 8f690628: 6d6d6f63 63655420 6c6f6e68 6569676fcomm Technologie
> >
> > Depending on enabled features in U-Boot the "GPIO_5" corrupts different
> > parts of the DTB, that's why it works somewhat sometimes.
> >
> > After staring at some drivers and the U-Boot linker script for a while
> > I realized that the BSS section overlaps with the appended DTB before
> > relocation. And indeed, mach-snapdragon/pinctrl-apq8016.c writes "GPIO_5"
> > into "static char pin_name[MAX_PIN_NAME_LEN];" (= BSS) before relocation.
> >
> > Actually, arch/arm/lib/crt0_64.S says that BSS should not be used at all
> > before relocation, because it's uninitialized and might corrupt other
> > memory. I found several other commits where similar problems happened
> > and it was usually fixed by moving the variables into the data section.
> >
> > So, I fixed the problem with the diff below and will include it together
> > with the changes to drop all the LK-related code. Now everything seems
> > fine. (I just wish this would have somehow been more obvious instead of
> > the strange behavior...)
> >
> > Stephan
> >
> > diff --git a/arch/arm/mach-snapdragon/pinctrl-apq8016.c
> > b/arch/arm/mach-snapdragon/pinctrl-apq8016.c
> > index 1042b564c3..7940c74287 100644
> > --- a/arch/arm/mach-snapdragon/pinctrl-apq8016.c
> > +++ b/arch/arm/mach-snapdragon/pinctrl-apq8016.c
> > @@ -10,7 +10,7 @@
> > #include
> >
> > #define MAX_PIN_NAME_LEN 32
> > -static char pin_name[MAX_PIN_NAME_LEN];
> > +static char pin_name[MAX_PIN_NAME_LEN] __section(".data");
> > static const char * const msm_pinctrl_pins[] = {
> > "SDC1_CLK",
> > "SDC1_CMD",
> >
> Hi.
> If I recall correctly, the signing tool only used the ELF sections, so
> the appended DTB was deleted.
> That's why I kept the "embedded DTB".
Yes, it doesn't make sense to append the DTB to the ELF file.
That's why "CONFIG_REMAKE_ELF" is useful, it builds a new EL
Re: [RFC] Load U-Boot without LK on DragonBoard 410c (+ DB820c?)
On Sun, Jul 4, 2021 at 2:14 PM Stephan Gerhold wrote:
>
> On Sun, Jul 04, 2021 at 02:08:39PM +0300, Ramon Fried wrote:
> > On Sun, Jul 4, 2021 at 12:42 AM Stephan Gerhold wrote:
> > >
> > > On Thu, Jul 01, 2021 at 11:07:55AM +0200, Stephan Gerhold wrote:
> > > > Hi!
> > > >
> > > > at the moment the U-Boot ports for both DragonBoard 410c and 820c are
> > > > designed to be loaded as an Android boot image after Qualcomm's LK
> > > > bootloader. This is simple to set up but LK is redundant in this case,
> > > > since everything done by LK can be also done directly by U-Boot.
> > > >
> > > > Dropping LK entirely would have at least the following advantages:
> > > > - Easier installation/board code (no need for Android boot images)
> > > > - (Slightly) faster boot
> > > > - Boot directly in 64-bit without a round trip to 32-bit for LK
> > > >
> > > > [...]
> > > >
> > > > 3. Remaining open questions
> > > > ===
> > > >
> > > > [...]
> > > >
> > > > 3. CONFIG_OF_EMBED: There is a big warning about this in the build
> > > > log:
> > > > "This option should only be used for debugging purposes. Please use
> > > > CONFIG_OF_SEPARATE for boards in mainline."
> > > >
> > > > The important part here is that we need an ELF image with both
> > > > U-Boot and the DTB. CONFIG_OF_EMBED is convenient for that because
> > > > we can just use the ELF image built by the linker and it already
> > > > contains the DTB.
> > > >
> > > > If CONFIG_OF_EMBED is really so bad it might be possible to build
> > > > a new boot image based on "u-boot-dtb.bin" (which is U-Boot with
> > > > DTB appended). I'm not sure if this is really much better though.
> > > >
> > >
> > > After looking some more I found "CONFIG_REMAKE_ELF" which seems to do
> > > exactly this (build a new ELF image based on "u-boot-dtb.bin" with
> > > appended DTB). So this avoids setting CONFIG_OF_EMBED and therefore the
> > > build warning. Sounds like the solution I was looking for. :)
> > >
> > > Unfortunately it looks like appending the DTB to U-Boot currently
> > > produces very strange behavior on DragonBoard 410c. It's either:
> > >
> > > - Working fine, or
> > > - Rebooting continously without serial output from U-Boot, or
> > > - The following serial output:
> > >
> > > Qualcomm-DragonBoard 410C
> > > DRAM: 986 MiB
> > > No serial driver found
> > > resetting ...
> > >
> > > It behaves consistently given a U-Boot binary but varies when
> > > adding/removing random features from the U-Boot binary.
> > >
> > > After a couple of hours of debugging, I realized that the appended DTB
> > > becomes corrupted. Specifically, there is a "GPIO_5" written into it, e.g.
> > >
> > > 8f6905b8: edfe0dd0 9f10 4f495047 c000355fGPIO_5..
> > > 8f6905c8: 2800 1100 1000 ...(
> > > 8f6905d8: df01 880e
> > > 8f6905e8: 0100
> > > 8f6905f8: 0300 0400 0200
> > > 8f690608: 0300 0400 0f00 0200
> > > 8f690618: 0300 2d00 1b00 6c617551...-Qual
> > > 8f690628: 6d6d6f63 63655420 6c6f6e68 6569676fcomm Technologie
> > >
> > > Depending on enabled features in U-Boot the "GPIO_5" corrupts different
> > > parts of the DTB, that's why it works somewhat sometimes.
> > >
> > > After staring at some drivers and the U-Boot linker script for a while
> > > I realized that the BSS section overlaps with the appended DTB before
> > > relocation. And indeed, mach-snapdragon/pinctrl-apq8016.c writes "GPIO_5"
> > > into "static char pin_name[MAX_PIN_NAME_LEN];" (= BSS) before relocation.
> > >
> > > Actually, arch/arm/lib/crt0_64.S says that BSS should not be used at all
> > > before relocation, because it's uninitialized and might corrupt other
> > > memory. I found several other commits where similar problems happened
> > > and it was usually fixed by moving the variables into the data section.
> > >
> > > So, I fixed the problem with the diff below and will include it together
> > > with the changes to drop all the LK-related code. Now everything seems
> > > fine. (I just wish this would have somehow been more obvious instead of
> > > the strange behavior...)
> > >
> > > Stephan
> > >
> > > diff --git a/arch/arm/mach-snapdragon/pinctrl-apq8016.c
> > > b/arch/arm/mach-snapdragon/pinctrl-apq8016.c
> > > index 1042b564c3..7940c74287 100644
> > > --- a/arch/arm/mach-snapdragon/pinctrl-apq8016.c
> > > +++ b/arch/arm/mach-snapdragon/pinctrl-apq8016.c
> > > @@ -10,7 +10,7 @@
> > > #include
> > >
> > > #define MAX_PIN_NAME_LEN 32
> > > -static char pin_name[MAX_PIN_NAME_LEN];
> > > +static char pin_name[MAX_PIN_NAME_LEN] __section(".data");
> > > static const char * const msm_pinctrl_pins[] = {
> > > "SDC1_CLK",
> > > "SDC1_CMD",
> > >
>
Re: [PATCH 1/8] imx8mm: Fix USB reg addresses for i.MX8MM
Hi Marek,
On Sat, Jul 3, 2021 at 10:04 PM Marek Vasut wrote:
> > Retrieving the USB base addresses from DT would be preferred, yes, but
> > the current code does not do that.
>
> I implemented exactly that in mx6_parse_dt_addrs() , see:
> 4dcfa3bcbcb ("usb: ehci-mx6: Parse USB PHY and MISC offsets from DT")
We are talking about USB_BASE_ADDR, right?
imx6/imx7/imxrt provide the USB_BASE_ADDR as define.
If we remove the imx6 definition from arch/arm/include/asm/arch-mx6/imx-regs.h
the ehci-mx6: driver fails to build.
I didn't want to change ehci-mx6 in this aspect, so that's why I used
Frieder's patch that passes
USB_BASE_ADDR via define for i.MX8MM too.
Is this an acceptable solution?
> > Without providing these defines:
> >
> > drivers/usb/host/ehci-mx6.c:254:62: error: ‘USB_BASE_ADDR’ undeclared
> > (first use in this function); did you mean ‘SRC_BASE_ADDR’?
> >254 | struct usbnc_regs *usbnc = (struct usbnc_regs
> > *)(uintptr_t)(USB_BASE_ADDR +
>
> I suspect you need CONFIG_PHY for mx8m .
CONFIG_PHY is already selected by imx8mm_evk_defconfig.
Thanks,
Fabio Estevam
[PATCH] rockchip: rk3399: adjust Nanopi R4S board power layout
1. Modify the VCC VDD power layout
2. Modify Ethernet1 interface of PCIE0
Signed-off-by: xiaobo
---
arch/arm/dts/rk3399-nanopi-r4s.dts | 85 ++
1 file changed, 63 insertions(+), 22 deletions(-)
diff --git a/arch/arm/dts/rk3399-nanopi-r4s.dts
b/arch/arm/dts/rk3399-nanopi-r4s.dts
index 6f2cf17bf1..ae22363072 100644
--- a/arch/arm/dts/rk3399-nanopi-r4s.dts
+++ b/arch/arm/dts/rk3399-nanopi-r4s.dts
@@ -17,19 +17,65 @@
model = "FriendlyElec NanoPi R4S";
compatible = "friendlyarm,nanopi-r4s", "rockchip,rk3399";
- aliases {
- ethernet1 = &r8169;
+ chosen {
+ stdout-path = "serial2:150n8";
+ };
+
+ vcc1v8_s3: vcc1v8-s3 {
+ compatible = "regulator-fixed";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ regulator-name = "vcc1v8_s3";
+ vin-supply = <&vcc_1v8>;
+ };
+
+ vcc3v0_sd: vcc3v0-sd {
+ compatible = "regulator-fixed";
+ enable-active-high;
+ gpio = <&gpio0 RK_PA1 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&sdmmc0_pwr_h>;
+ regulator-always-on;
+ regulator-min-microvolt = <300>;
+ regulator-max-microvolt = <300>;
+ regulator-name = "vcc3v0_sd";
+ vin-supply = <&vcc3v3_sys>;
+ };
+
+ vcc3v3_sys: vcc3v3-sys {
+ compatible = "regulator-fixed";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ regulator-name = "vcc3v3_sys";
+ };
+
+ vcc5v0_sys: vcc5v0-sys {
+ compatible = "regulator-fixed";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ regulator-name = "vcc5v0_sys";
+ vin-supply = <&vdd_5v>;
};
vdd_5v: vdd-5v {
compatible = "regulator-fixed";
- regulator-name = "vdd_5v";
regulator-always-on;
regulator-boot-on;
+ regulator-name = "vdd_5v";
};
fan: pwm-fan {
compatible = "pwm-fan";
+ /*
+* With 20KHz PWM and an EVERCOOL EC4007H12SA fan, these levels
+* work out to 0, ~1200, ~3000, and 5000RPM respectively.
+*/
cooling-levels = <0 12 18 255>;
#cooling-cells = <2>;
fan-supply = <&vdd_5v>;
@@ -73,40 +119,39 @@
status = "disabled";
};
+&i2c4 {
+ status = "disabled";
+};
+
&leds {
lan_led: led-1 {
gpios = <&gpio1 RK_PA1 GPIO_ACTIVE_HIGH>;
- label = "nanopi-r4s:green:lan";
+ label = "green:lan";
+ };
+
+ sys_led: led-sys {
+ default-state = "on";
+ gpios = <&gpio0 RK_PB5 GPIO_ACTIVE_HIGH>;
+ label = "red:sys";
};
wan_led: led-2 {
gpios = <&gpio1 RK_PA0 GPIO_ACTIVE_HIGH>;
- label = "nanopi-r4s:green:wan";
+ label = "green:wan";
};
};
&leds_gpio {
rockchip,pins =
- <0 RK_PB5 RK_FUNC_GPIO &pcfg_pull_none>,
<1 RK_PA0 RK_FUNC_GPIO &pcfg_pull_none>,
- <1 RK_PA1 RK_FUNC_GPIO &pcfg_pull_none>;
+ <1 RK_PA1 RK_FUNC_GPIO &pcfg_pull_none>,
+ <0 RK_PB5 RK_FUNC_GPIO &pcfg_pull_none>;
};
&pcie0 {
max-link-speed = <1>;
num-lanes = <1>;
vpcie3v3-supply = <&vcc3v3_sys>;
-
- pcie@0 {
- reg = <0x 0 0 0 0>;
- #address-cells = <3>;
- #size-cells = <2>;
-
- r8169: pcie@0,0 {
- reg = <0x00 0 0 0 0>;
- local-mac-address = [ 00 00 00 00 00 00 ];
- };
- };
};
&sdhci {
@@ -132,7 +177,3 @@
&usbdrd_dwc3_0 {
dr_mode = "host";
};
-
-&vcc3v3_sys {
- vin-supply = <&vcc5v0_sys>;
-};
--
2.32.0
Re: [PATCH v2 17/33] dtoc: Process driver aliases along with drivers
Hi Johan, On Sat, 26 Jun 2021 at 12:32, Simon Glass wrote: > > Hi Johan, > > On Mon, 21 Jun 2021 at 12:39, Johan Jonker wrote: > > > > Hi Simon, Heiko, > > > > With introduction of rockchip-nand-controller.c in Linux and recently > > rockchip_nfc.c in U-boot it offers a renewed opportunity to add support > > for MK808 with a rk3066 + NAND to boot from. > > rk3066 shares /arch/arm/dts/rk3xxx.dtsi with rk3188. > > The only 'usable' boot loader now is closed source with proprietary FTL. > > > > As a spinoff to that discussion I've tried to compile for > > rk3188-radxarock as an example due to the lack of rk3066 support in next > > and enabling the new rockchip_nfc.c driver. > > I'm not familiar with Python/U-boot. > > Do you have an idea what this error below is about? > > > > Kind regards, > > > > Johan > > === > > > > python --version > > Python 2.7.13 > > > > === > > > > From rock_defconfig: > > CONFIG_SPL_OF_PLATDATA=y > > > > === > > > > git clone -b next > > https://source.denx.de/u-boot/custodians/u-boot-rockchip.git > > u-boot-next-20210619 > > > > make rock_defconfig > > > > make CROSS_COMPILE=/usr/bin/arm-linux-gnueabi- menuconfig > > > > [ ] Support for NAND controller on Rockchip SoCs (NEW) > > > > Add to rock.h: > > #define CONFIG_SYS_MAX_NAND_DEVICE 1 > > > > make CROSS_COMPILE=/usr/bin/arm-linux-gnueabi- all > > > > === > > mkdir -p spl/dts/ > > FDTGREP spl/dts/dt-spl.dtb > > COPYspl/u-boot-spl.dtb > > CC spl/./lib/asm-offsets.s > > CC spl/./arch/arm/lib/asm-offsets.s > > DTOCspl/dts/dt-plat.c > > Traceback (most recent call last): > > File "./tools/dtoc/dtoc", line 112, in > > options.phase, instantiate=options.instantiate) > > File > > "~/Downloads/u-boot-next-20210619/tools/dtoc/../dtoc/dtb_platdata.py", > > line 1180, in run_steps > > scan.scan_drivers() > > File > > "~/Downloads/u-boot-next-20210619/tools/dtoc/../dtoc/src_scan.py", line > > 649, in scan_drivers > > self.scan_driver(pathname) > > File > > "~/Downloads/u-boot-next-20210619/tools/dtoc/../dtoc/src_scan.py", line > > 608, in scan_driver > > self._parse_driver(fname, buff) > > File > > "~/Downloads/u-boot-next-20210619/tools/dtoc/../dtoc/src_scan.py", line > > 558, in _parse_driver > > self._driver_aliases[m_alias[2]] = m_alias[1] > > TypeError: '_sre.SRE_Match' object is not subscriptable > > scripts/Makefile.spl:352: recipe for target 'spl/dts/dt-plat.c' failed > > make[1]: *** [spl/dts/dt-plat.c] Error 1 > > Makefile:1977: recipe for target 'spl/u-boot-spl' failed > > make: *** [spl/u-boot-spl] Error 2 > > > > === > > > > Changed: > > self._driver_aliases[m_alias[2]] = m_alias[1] > > > > To: > > self._driver_aliases[m_alias.group(2)] = m_alias.group(1) > > > > Is that a correct python change of mine? > > I think so, yes. I will take a look. This was introduced in Python 3.6 so I suspect your Python is quite old. I will send a patch. > > > > > === > > > > After that it compiles normal with only this warning. > > > > DTOCspl/dts/dt-plat.c > > WARNING: the driver rockchip_rk3188_grf was not found in the driver list > > WARNING: the driver rockchip_rk3188_pmu was not found in the driver list > > WARNING: the driver rockchip_rk3188_uart was not found in the driver list > > DTOCinclude/generated/dt-structs-gen.h > > WARNING: the driver rockchip_rk3188_grf was not found in the driver list > > WARNING: the driver rockchip_rk3188_pmu was not found in the driver list > > WARNING: the driver rockchip_rk3188_uart was not found in the driver list > > DTOCinclude/generated/dt-decl.h > > WARNING: the driver rockchip_rk3188_grf was not found in the driver list > > WARNING: the driver rockchip_rk3188_pmu was not found in the driver list > > WARNING: the driver rockchip_rk3188_uart was not found in the driver list > > OK that means you have the driver missing. It is not fatal unless > OF_PLATDATA_INST is enabled. I'll send a series to improve the warnings here. The problem is in the strange use of the .compatible memory in the rockchip driver, so I've updated dtoc to handle it but show a warning. Regards, Simon
[PATCH 0/8] dtoc: Improvements to warnings
The warning about a missing driver can be a bit confusing and is not specifically mentioned in the documentation. Also some parse errors result in the driver simply being ignored, which is hard to diagnose. This series updates dtoc to try harder to find common errors and report a useful warning. It also adds a section about possible problems to the of-platdata documentation. Unfortunately the use of match-object subscripts is not supported in Python 3.5 and earlier, so a patch is included to avoid this. Finally, a short usage string it added to the help output, with dtoc being converted to use ArgumentParser in the process. Simon Glass (8): dtoc: Avoid using subscripts on match objects dtoc: Convert to use ArgumentParser dtoc: Allow multiple warnings for a driver dtoc: Correct the re_compat regular expression dtoc: Add a stdout check in test_normalized_name() dtoc: Detect unexpected suffix on .of_match dtoc: Detect drivers which do not parse correctly dtoc: Update documentation to cover warnings in more detail doc/develop/driver-model/of-plat.rst | 53 +++ tools/dtoc/main.py | 51 +- tools/dtoc/src_scan.py | 45 +++-- tools/dtoc/test_src_scan.py | 133 ++- 4 files changed, 247 insertions(+), 35 deletions(-) -- 2.32.0.93.g670b81a890-goog
[PATCH 1/8] dtoc: Avoid using subscripts on match objects
These are not supported before Python 3.6 so avoid them. Signed-off-by: Simon Glass --- tools/dtoc/src_scan.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/dtoc/src_scan.py b/tools/dtoc/src_scan.py index 2db96884c85..1dbb56712a3 100644 --- a/tools/dtoc/src_scan.py +++ b/tools/dtoc/src_scan.py @@ -555,7 +555,7 @@ class Scanner: if ids_m: ids_name = ids_m.group(1) elif m_alias: -self._driver_aliases[m_alias[2]] = m_alias[1] +self._driver_aliases[m_alias.group(2)] = m_alias.group(1) # Make the updates based on what we found for driver in drivers.values(): -- 2.32.0.93.g670b81a890-goog
[PATCH 3/8] dtoc: Allow multiple warnings for a driver
At present we show when a driver is missing but this is not always that
useful. There are various reasons way a driver may appear to be missing,
such as a parse error in the source code or a missing field in the driver
declaration.
Update the implementation to record all warnings for each driver, showing
only those which relate to drivers that are actually used. This avoids
spamming the user with warnings related to a driver for a different board.
Signed-off-by: Simon Glass
---
tools/dtoc/src_scan.py | 24
1 file changed, 20 insertions(+), 4 deletions(-)
diff --git a/tools/dtoc/src_scan.py b/tools/dtoc/src_scan.py
index 1dbb56712a3..6c37a71e978 100644
--- a/tools/dtoc/src_scan.py
+++ b/tools/dtoc/src_scan.py
@@ -13,6 +13,7 @@ U_BOOT_DRIVER(), UCLASS_DRIVER and all struct declarations in
header files.
See doc/driver-model/of-plat.rst for more informaiton
"""
+import collections
import os
import re
import sys
@@ -190,6 +191,9 @@ class Scanner:
value: Driver name declared with U_BOOT_DRIVER(driver_name)
_drivers_additional (list or str): List of additional drivers to use
during scanning
+_warnings: Dict of warnings found:
+key: Driver name
+value: Set of warnings
_of_match: Dict holding information about compatible strings
key: Name of struct udevice_id variable
value: Dict of compatible info in that variable:
@@ -217,6 +221,7 @@ class Scanner:
self._driver_aliases = {}
self._drivers_additional = drivers_additional or []
self._missing_drivers = set()
+self._warnings = collections.defaultdict(set)
self._of_match = {}
self._compat_to_driver = {}
self._uclass = {}
@@ -267,7 +272,10 @@ class Scanner:
aliases_c.remove(compat_c)
return compat_c, aliases_c
-self._missing_drivers.add(compat_list_c[0])
+name = compat_list_c[0]
+self._missing_drivers.add(name)
+self._warnings[name].add(
+'WARNING: the driver %s was not found in the driver list' % name)
return compat_list_c[0], compat_list_c[1:]
@@ -577,9 +585,17 @@ class Scanner:
def show_warnings(self):
"""Show any warnings that have been collected"""
-for name in sorted(list(self._missing_drivers)):
-print('WARNING: the driver %s was not found in the driver list'
- % name)
+used_drivers = [drv.name for drv in self._drivers.values() if drv.used]
+missing = self._missing_drivers
+for name in sorted(self._warnings.keys()):
+if name in missing or name in used_drivers:
+warns = sorted(list(self._warnings[name]))
+# For now there is only ever one warning
+print('%s: %s' % (name, warns[0]))
+indent = ' ' * len(name)
+if name in missing:
+missing.remove(name)
+print()
def scan_driver(self, fname):
"""Scan a driver file to build a list of driver names and aliases
--
2.32.0.93.g670b81a890-goog
[PATCH 4/8] dtoc: Correct the re_compat regular expression
This expects a . before the field name (.e.g '.compatible = ...) but
presently accepts anything at all. Fix it.
Signed-off-by: Simon Glass
---
tools/dtoc/src_scan.py | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/dtoc/src_scan.py b/tools/dtoc/src_scan.py
index 6c37a71e978..6e8e1ba51a0 100644
--- a/tools/dtoc/src_scan.py
+++ b/tools/dtoc/src_scan.py
@@ -452,8 +452,8 @@ class Scanner:
# Collect the compatible string, e.g. 'rockchip,rk3288-grf'
compat = None
-re_compat = re.compile(r'{\s*.compatible\s*=\s*"(.*)"\s*'
- r'(,\s*.data\s*=\s*(\S*))?\s*},')
+re_compat = re.compile(r'{\s*\.compatible\s*=\s*"(.*)"\s*'
+ r'(,\s*\.data\s*=\s*(\S*))?\s*},')
# This is a dict of compatible strings that were found:
#key: Compatible string, e.g. 'rockchip,rk3288-grf'
--
2.32.0.93.g670b81a890-goog
[PATCH 5/8] dtoc: Add a stdout check in test_normalized_name()
This test captures output but does not always check it. Add the missing
code and drop the old comment.
Signed-off-by: Simon Glass
---
tools/dtoc/test_src_scan.py | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/tools/dtoc/test_src_scan.py b/tools/dtoc/test_src_scan.py
index d6da03849f9..4e38b25a2f8 100644
--- a/tools/dtoc/test_src_scan.py
+++ b/tools/dtoc/test_src_scan.py
@@ -171,8 +171,7 @@ class TestSrcScan(unittest.TestCase):
self.assertEqual([], aliases)
self.assertEqual(1, len(scan._missing_drivers))
self.assertEqual({'rockchip_rk3288_grf'}, scan._missing_drivers)
-#'WARNING: the driver rockchip_rk3288_grf was not found in the
driver list',
-#stdout.getvalue().strip())
+self.assertEqual('', stdout.getvalue().strip())
i2c = 'I2C_UCLASS'
compat = {'rockchip,rk3288-grf': 'ROCKCHIP_SYSCON_GRF',
--
2.32.0.93.g670b81a890-goog
[PATCH 2/8] dtoc: Convert to use ArgumentParser
Use this parser instead of OptionParser, which is deprecated.
Signed-off-by: Simon Glass
---
tools/dtoc/main.py | 51 --
1 file changed, 27 insertions(+), 24 deletions(-)
diff --git a/tools/dtoc/main.py b/tools/dtoc/main.py
index 93706de89bf..6f9b526bd74 100755
--- a/tools/dtoc/main.py
+++ b/tools/dtoc/main.py
@@ -21,7 +21,7 @@ options. For more information about the use of this options
and tool please
see doc/driver-model/of-plat.rst
"""
-from optparse import OptionParser
+from argparse import ArgumentParser
import os
import sys
import unittest
@@ -51,7 +51,7 @@ def run_tests(processes, args):
result = unittest.TestResult()
sys.argv = [sys.argv[0]]
-test_name = args and args[0] or None
+test_name = args.files and args.files[0] or None
test_dtoc.setup()
@@ -66,47 +66,50 @@ def RunTestCoverage():
"""Run the tests and check that we get 100% coverage"""
sys.argv = [sys.argv[0]]
test_util.RunTestCoverage('tools/dtoc/dtoc', '/main.py',
-['tools/patman/*.py', '*/fdt*', '*test*'], options.build_dir)
+['tools/patman/*.py', '*/fdt*', '*test*'], args.build_dir)
if __name__ != '__main__':
sys.exit(1)
-parser = OptionParser()
-parser.add_option('-B', '--build-dir', type='string', default='b',
+epilog = '''Generate C code from devicetree files. See of-plat.rst for
details'''
+
+parser = ArgumentParser(epilog=epilog)
+parser.add_argument('-B', '--build-dir', type=str, default='b',
help='Directory containing the build output')
-parser.add_option('-c', '--c-output-dir', action='store',
+parser.add_argument('-c', '--c-output-dir', action='store',
help='Select output directory for C files')
-parser.add_option('-C', '--h-output-dir', action='store',
+parser.add_argument('-C', '--h-output-dir', action='store',
help='Select output directory for H files (defaults to
--c-output-di)')
-parser.add_option('-d', '--dtb-file', action='store',
+parser.add_argument('-d', '--dtb-file', action='store',
help='Specify the .dtb input file')
-parser.add_option('-i', '--instantiate', action='store_true', default=False,
+parser.add_argument('-i', '--instantiate', action='store_true', default=False,
help='Instantiate devices to avoid needing device_bind()')
-parser.add_option('--include-disabled', action='store_true',
+parser.add_argument('--include-disabled', action='store_true',
help='Include disabled nodes')
-parser.add_option('-o', '--output', action='store',
+parser.add_argument('-o', '--output', action='store',
help='Select output filename')
-parser.add_option('-p', '--phase', type=str,
+parser.add_argument('-p', '--phase', type=str,
help='set phase of U-Boot this invocation is for (spl/tpl)')
-parser.add_option('-P', '--processes', type=int,
+parser.add_argument('-P', '--processes', type=int,
help='set number of processes to use for running tests')
-parser.add_option('-t', '--test', action='store_true', dest='test',
+parser.add_argument('-t', '--test', action='store_true', dest='test',
default=False, help='run tests')
-parser.add_option('-T', '--test-coverage', action='store_true',
-default=False, help='run tests and check for 100% coverage')
-(options, args) = parser.parse_args()
+parser.add_argument('-T', '--test-coverage', action='store_true',
+default=False, help='run tests and check for 100%% coverage')
+parser.add_argument('files', nargs='*')
+args = parser.parse_args()
# Run our meagre tests
-if options.test:
-ret_code = run_tests(options.processes, args)
+if args.test:
+ret_code = run_tests(args.processes, args)
sys.exit(ret_code)
-elif options.test_coverage:
+elif args.test_coverage:
RunTestCoverage()
else:
-dtb_platdata.run_steps(args, options.dtb_file, options.include_disabled,
- options.output,
- [options.c_output_dir, options.h_output_dir],
- options.phase, instantiate=options.instantiate)
+dtb_platdata.run_steps(args.files, args.dtb_file, args.include_disabled,
+ args.output,
+ [args.c_output_dir, args.h_output_dir],
+ args.phase, instantiate=args.instantiate)
--
2.32.0.93.g670b81a890-goog
[PATCH 6/8] dtoc: Detect unexpected suffix on .of_match
Some rockchip drivers use a suffix on the of_match line which is not
strictly valid. At present this causes the parsing to fail. Fix this
and offer a warning.
Signed-off-by: Simon Glass
---
tools/dtoc/src_scan.py | 12 +++--
tools/dtoc/test_src_scan.py | 92 +
2 files changed, 101 insertions(+), 3 deletions(-)
diff --git a/tools/dtoc/src_scan.py b/tools/dtoc/src_scan.py
index 6e8e1ba51a0..847677757d9 100644
--- a/tools/dtoc/src_scan.py
+++ b/tools/dtoc/src_scan.py
@@ -468,7 +468,7 @@ class Scanner:
# Matches the references to the udevice_id list
re_of_match = re.compile(
-r'\.of_match\s*=\s*(of_match_ptr\()?([a-z0-9_]+)(\))?,')
+r'\.of_match\s*=\s*(of_match_ptr\()?([a-z0-9_]+)([^,]*),')
re_phase = re.compile('^\s*DM_PHASE\((.*)\).*$')
re_hdr = re.compile('^\s*DM_HEADER\((.*)\).*$')
@@ -514,6 +514,11 @@ class Scanner:
driver.uclass_id = m_id.group(1)
elif m_of_match:
compat = m_of_match.group(2)
+suffix = m_of_match.group(3)
+if suffix and suffix != ')':
+self._warnings[driver.name].add(
+"%s: Warning: unexpected suffix '%s' on .of_match
line for compat '%s'" %
+(fname, suffix, compat))
elif m_phase:
driver.phase = m_phase.group(1)
elif m_hdr:
@@ -586,13 +591,14 @@ class Scanner:
def show_warnings(self):
"""Show any warnings that have been collected"""
used_drivers = [drv.name for drv in self._drivers.values() if drv.used]
-missing = self._missing_drivers
+missing = self._missing_drivers.copy()
for name in sorted(self._warnings.keys()):
if name in missing or name in used_drivers:
warns = sorted(list(self._warnings[name]))
-# For now there is only ever one warning
print('%s: %s' % (name, warns[0]))
indent = ' ' * len(name)
+for warn in warns[1:]:
+print('%-s: %s' % (indent, warn))
if name in missing:
missing.remove(name)
print()
diff --git a/tools/dtoc/test_src_scan.py b/tools/dtoc/test_src_scan.py
index 4e38b25a2f8..62500e80fe7 100644
--- a/tools/dtoc/test_src_scan.py
+++ b/tools/dtoc/test_src_scan.py
@@ -20,6 +20,9 @@ from patman import tools
OUR_PATH = os.path.dirname(os.path.realpath(__file__))
+EXPECT_WARN = {'rockchip_rk3288_grf':
+ {'WARNING: the driver rockchip_rk3288_grf was not found in
the driver list'}}
+
class FakeNode:
"""Fake Node object for testing"""
def __init__(self):
@@ -152,6 +155,7 @@ class TestSrcScan(unittest.TestCase):
'nvidia,tegra20-i2c-dvc': 'TYPE_DVC'}, drv.compat)
self.assertEqual('i2c_bus', drv.priv)
self.assertEqual(1, len(scan._drivers))
+self.assertEqual({}, scan._warnings)
def test_normalized_name(self):
"""Test operation of get_normalized_compat_name()"""
@@ -172,6 +176,7 @@ class TestSrcScan(unittest.TestCase):
self.assertEqual(1, len(scan._missing_drivers))
self.assertEqual({'rockchip_rk3288_grf'}, scan._missing_drivers)
self.assertEqual('', stdout.getvalue().strip())
+self.assertEqual(EXPECT_WARN, scan._warnings)
i2c = 'I2C_UCLASS'
compat = {'rockchip,rk3288-grf': 'ROCKCHIP_SYSCON_GRF',
@@ -188,6 +193,7 @@ class TestSrcScan(unittest.TestCase):
self.assertEqual('', stdout.getvalue().strip())
self.assertEqual('rockchip_rk3288_grf', name)
self.assertEqual([], aliases)
+self.assertEqual(EXPECT_WARN, scan._warnings)
prop.value = 'rockchip,rk3288-srf'
with test_util.capture_sys_output() as (stdout, _):
@@ -195,6 +201,7 @@ class TestSrcScan(unittest.TestCase):
self.assertEqual('', stdout.getvalue().strip())
self.assertEqual('rockchip_rk3288_grf', name)
self.assertEqual(['rockchip_rk3288_srf'], aliases)
+self.assertEqual(EXPECT_WARN, scan._warnings)
def test_scan_errors(self):
"""Test detection of scanning errors"""
@@ -489,3 +496,88 @@ U_BOOT_DRIVER(%s) = {
self.assertEqual(3, seq)
self.assertEqual({'mypath': 3}, uc.alias_path_to_num)
self.assertEqual({2: node, 3: node}, uc.alias_num_to_node)
+
+def test_scan_warnings(self):
+"""Test detection of scanning warnings"""
+buff = '''
+static const struct udevice_id tegra_i2c_ids[] = {
+ { .compatible = "nvidia,tegra114-i2c", .data = TYPE_114 },
+ { }
+};
+
+U_BOOT_DRIVER(i2c_tegra) = {
+ .name = "i2c_tegra",
+ .id = UCLASS_I2C,
+ .of_match = tegra_i2c_ids + 1,
+};
+'''
+# The '+ 1' above should generate a warning
+
+prop = FakeProp()
[PATCH 7/8] dtoc: Detect drivers which do not parse correctly
At present if a driver is missing a uclass or compatible stirng, this
is silently ignored. This makes sense in most cases, particularly for
the compatible string, since it is not required except when the driver
is used with of-platdata.
But it is also not very helpful. When there is some sort of problem
with a driver, the missing compatible string (for example) may be the
cause.
Add a warning in this case, showing it only for drivers which are used
by the build.
Signed-off-by: Simon Glass
---
tools/dtoc/src_scan.py | 7 ++-
tools/dtoc/test_src_scan.py | 38 +
2 files changed, 44 insertions(+), 1 deletion(-)
diff --git a/tools/dtoc/src_scan.py b/tools/dtoc/src_scan.py
index 847677757d9..3bef59d616e 100644
--- a/tools/dtoc/src_scan.py
+++ b/tools/dtoc/src_scan.py
@@ -546,7 +546,12 @@ class Scanner:
# The driver does not have a uclass or compat string.
# The first is required but the second is not, so just
# ignore this.
-pass
+if not driver.uclass_id:
+warn = 'Missing .uclass'
+else:
+warn = 'Missing .compatible'
+self._warnings[driver.name].add('%s in %s' %
+(warn, fname))
driver = None
ids_name = None
compat = None
diff --git a/tools/dtoc/test_src_scan.py b/tools/dtoc/test_src_scan.py
index 62500e80fe7..f03cf8ed7c7 100644
--- a/tools/dtoc/test_src_scan.py
+++ b/tools/dtoc/test_src_scan.py
@@ -581,3 +581,41 @@ rockchip_rk3288_grf: WARNING: the driver
rockchip_rk3288_grf was not found in th
''',
stdout.getvalue())
self.assertIn('tegra_i2c_ids', stdout.getvalue())
+
+def scan_uclass_warning(self):
+"""Test a missing .uclass in the driver"""
+buff = '''
+static const struct udevice_id tegra_i2c_ids[] = {
+ { .compatible = "nvidia,tegra114-i2c", .data = TYPE_114 },
+ { }
+};
+
+U_BOOT_DRIVER(i2c_tegra) = {
+ .name = "i2c_tegra",
+ .of_match = tegra_i2c_ids,
+};
+'''
+scan = src_scan.Scanner(None, None)
+scan._parse_driver('file.c', buff)
+self.assertEqual(
+{'i2c_tegra': {'Missing .uclass in file.c'}},
+scan._warnings)
+
+def scan_compat_warning(self):
+"""Test a missing .compatible in the driver"""
+buff = '''
+static const struct udevice_id tegra_i2c_ids[] = {
+ { .compatible = "nvidia,tegra114-i2c", .data = TYPE_114 },
+ { }
+};
+
+U_BOOT_DRIVER(i2c_tegra) = {
+ .name = "i2c_tegra",
+ .id = UCLASS_I2C,
+};
+'''
+scan = src_scan.Scanner(None, None)
+scan._parse_driver('file.c', buff)
+self.assertEqual(
+{'i2c_tegra': {'Missing .compatible in file.c'}},
+scan._warnings)
--
2.32.0.93.g670b81a890-goog
[PATCH 8/8] dtoc: Update documentation to cover warnings in more detail
When things go wrong it can be confusing to figure out what to change.
Add a few more details to the documentation.
Fix a 'make htmldocs' warning while we are here.
Signed-off-by: Simon Glass
---
doc/develop/driver-model/of-plat.rst | 53
1 file changed, 53 insertions(+)
diff --git a/doc/develop/driver-model/of-plat.rst
b/doc/develop/driver-model/of-plat.rst
index 74f1932473b..e2763965839 100644
--- a/doc/develop/driver-model/of-plat.rst
+++ b/doc/develop/driver-model/of-plat.rst
@@ -597,6 +597,59 @@ as a macro included in the driver definition::
+Problems
+
+
+In some cases you will you see something like this::
+
+ WARNING: the driver rockchip_rk3188_grf was not found in the driver list
+
+The driver list is a list of drivers, each with a name. The name is in the
+U_BOOT_DRIVER() declaration, repeated twice, one in brackets and once as the
+.name member. For example, in the following declaration the driver name is
+`rockchip_rk3188_grf`::
+
+ U_BOOT_DRIVER(rockchip_rk3188_grf) = {
+ .name = "rockchip_rk3188_grf",
+ .id = UCLASS_SYSCON,
+ .of_match = rk3188_syscon_ids + 1,
+ .bind = rk3188_syscon_bind_of_plat,
+ };
+
+The first name U_BOOT_DRIVER(xx) is used to create a linker symbol so that the
+driver can be accessed at build-time without any overhead. The second one
+(.name = "xx") is used at runtime when something wants to print out the driver
+name.
+
+The dtoc tool expects to be able to find a driver for each compatible string in
+the devicetree. For example, if the devicetree has::
+
+ grf: grf@20008000 {
+ compatible = "rockchip,rk3188-grf", "syscon";
+ reg = <0x20008000 0x200>;
+ u-boot,dm-spl;
+ };
+
+then dtoc looks at the first compatible string ("rockchip,rk3188-grf"),
+converts that to a C identifier (rockchip_rk3188_grf) and then looks for that.
+
+Various things can cause dtoc to fail to find the driver and it tries to
+warn about these. For example:
+
+ rockchip_rk3188_uart: Missing .compatible in
drivers/serial/serial_rockchip.c
+: WARNING: the driver rockchip_rk3188_uart was not found
in the driver list
+
+Without a compatible string a driver cannot be used by dtoc, even if the
+compatible string is not actually needed at runtime.
+
+If the problem is simply that there are multiple compatible strings, the
+DM_DRIVER_ALIAS() macro can be used to tell dtoc about this and avoid a
problem.
+
+Checks are also made the referenced driver has a .compatible member and a .id
+member. The first provides the array of compatible strings and the second
+provides the uclass ID.
+
+
Caveats
---
--
2.32.0.93.g670b81a890-goog
Re: [PATCH] fdtdec: fdtdec_get_aliases_highest_id: skip aliases to disabled nodes
Hi Tim, On Fri, 11 Jun 2021 at 11:30, Tim Harvey wrote: > > On Fri, Jun 11, 2021 at 10:23 AM Sean Anderson wrote: > > > > > > > > On 6/11/21 1:16 PM, Tim Harvey wrote: > > > On Fri, Jun 11, 2021 at 10:09 AM Sean Anderson > > wrote: > > >> > > >> > > >> > > >> On 6/11/21 12:32 PM, Tim Harvey wrote: > > >> > On Thu, Apr 29, 2021 at 9:48 AM Tim Harvey > > wrote: > > >> >> > > >> >> On Thu, Apr 29, 2021 at 9:10 AM Simon Glass > > wrote: > > >> >>> > > >> >>> Hi Tim, > > >> >>> > > >> >>> On Fri, 16 Apr 2021 at 14:30, Tim Harvey > > wrote: > > >> > > >> When looking for an alias with the highest id skip aliases for > > nodes > > >> that are disabled. > > >> > > >> Signed-off-by: Tim Harvey > > >> --- > > >> lib/fdtdec.c | 2 ++ > > >> 1 file changed, 2 insertions(+) > > >> > > >> diff --git a/lib/fdtdec.c b/lib/fdtdec.c > > >> index 864589193b..d47195525a 100644 > > >> --- a/lib/fdtdec.c > > >> +++ b/lib/fdtdec.c > > >> @@ -546,6 +546,8 @@ int fdtdec_get_alias_highest_id(const void > > *blob, const char *base) > > >> if (*prop != '/' || prop[len - 1] || > > >> strncmp(name, base, base_len)) > > >> continue; > > >> + if (!fdtdec_get_is_enabled(blob, > > fdt_path_offset(blob, prop))) > > >> + continue; > > >> >>> > > >> >>> We really can't do this here. It is quite an expensive operation > > to > > >> >>> locate the node for a path. > > >> >>> > > >> >>> Why is this needed? It seems odd to have an alias pointing to a > > disabled device. > > >> >>> > > >> >> > > >> >> Simon, > > >> >> > > >> >> The issue I ran into here was with an imx6 based board that does > > not > > >> >> use the FEC ethernet on the SoC. In this case imx6qdl.dtsi > > delcares an > > >> >> alias 'thernet0 = &fec' yet the fec node is not enabled. However > > >> >> because fdtdec_get_alias_highest_id does not skip this alias to a > > >> >> disabled device any enumerated ethernet devices get an index of 1 > > >> >> instead of 0 which is incorrect and causes the mac addresses to be > > >> >> misaligned. > > >> > > >> Is this due getting mac address from the OTP? As I understand it, the > > >> OTP mac addresses are for fec0/fec1, and not for whatever ethernet0 > > >> happens to be. > > >> > > > > > > Sean, > > > > > > No, the issue is that U-Boot thinks there is an fec device simply > > > because an alias points to it even though the fec node pointed to is > > > disabled so when U-Boot finds an ethernet device that is enumerated at > > > runtime (think pcie or usb based mac) those start at index 1 instead > > > of index 0 and end up wanting to be assigned mac's from eth1addr > > > instead of ethaddr. > > > > Ok, and this behavior was different in the past? E.g. it used to be that > > these interfaces were assigned to ethernet0, and so their mac address > > was stored in ethaddr. And then something changed and now they are > > ethernet1 and are trying to get the incorrect mac address? > > > > Sean, > > Yes, in the past before using driver-model this did not occur as > everything was statically declared in board files. > > > Do you know whether it would be possible to remove the alias at the same > > time you mark the fec as disabled? > > > > The dt's are all merged together. The base SoC dt declares the alias > to internal fec ethernet device and that alias can be overridden by > any dts that includes that base soc dt but if you have a gbe that is > discovered and not declared in dt there will be no alias to override > it. When I submitted this patch I looked at what the kernel code did > and noticed it did not reserve indexes/slots for disabled devices so I > figure that's what the bootloader should do also. Can you try enabled OF_LIVE? It is possible that it might be different there. Even if not, it should be a cheap fix. As mentioned the problem with your patch is that the path operation is very expensive. I'm fine with it if you want to add it as a new CONFIG option, so it doesn't affect all platforms. But if you do that, please do update test-fdt.c for the sandbox tests. Regards, Simon
Re: [PATCH 1/1] test: NULL dereference in test-uclass
Hi Heinrich, On Thu, 3 Jun 2021 at 14:08, Heinrich Schuchardt wrote: > > If a test-uclass device is probed outside a test, uts is not defined. > Avoid a NULL dereference in this case. I am missing the motivation for this patch. In what situation does this occur? Regards, Simon > > Signed-off-by: Heinrich Schuchardt > --- > test/dm/test-uclass.c | 12 > 1 file changed, 12 insertions(+) >
Re: [PATCH] dm: core: fix no null pointer detection in ofnode_get_addr_size_index()
Hi Chenguanqiao, On Sat, 15 May 2021 at 09:20, Simon Glass wrote: > > On Thu, 13 May 2021 at 01:38, chenguanqiao wrote: > > > > From: Chen Guanqiao > > > > Fixed a defect of a null pointer being discovered by Coverity Scan: > >CID 331544: Null pointer dereferences (REVERSE_INULL) > >Null-checking "size" suggests that it may be null, but it has already > > been dereferenced on all paths leading to the check. > > > > Signed-off-by: Chen Guanqiao > > --- > > drivers/core/ofnode.c | 13 +++-- > > include/dm/ofnode.h | 2 +- > > 2 files changed, 8 insertions(+), 7 deletions(-) > > > > Reviewed-by: Simon Glass Unfortunately this does not apply to u-boot/next. Can you please rebase it and resend? Regards, Simon
Re: [PATCH] sandbox: Support signal handling only when requested
Hi Heinrich,
On Sun, 6 Jun 2021 at 15:35, Heinrich Schuchardt wrote:
>
> Am 6. Juni 2021 20:07:31 MESZ schrieb Sean Anderson :
> >On 6/6/21 1:57 PM, Heinrich Schuchardt wrote:
> >> On 6/6/21 7:52 PM, Sean Anderson wrote:
> >>> On 6/6/21 1:28 PM, Heinrich Schuchardt wrote:
> On 6/6/21 6:44 PM, Simon Glass wrote:
> > Hi Heinrich,
> >
> > On Mon, 22 Mar 2021 at 18:56, Simon Glass
> >wrote:
> >>
> >> Hi Heinrich,
> >>
> >> On Mon, 22 Mar 2021 at 23:02, Heinrich Schuchardt
> >> wrote:
> >>>
> >>> On 22.03.21 06:21, Simon Glass wrote:
> At present if sandbox crashes it prints a message and tries to
> exit. But
> with the recently introduced signal handler, it often seems to
> >get
> stuck
> in a loop until the stack overflows:
>
> Segmentation violation
>
> Segmentation violation
>
> Segmentation violation
>
> Segmentation violation
>
> Segmentation violation
>
> Segmentation violation
>
> Segmentation violation
> ...
> >>>
> >>> Hello Simon,
> >>>
> >>> do you have a reproducible example? I never have seen this.
> >>
> >> https://source.denx.de/u-boot/custodians/u-boot-dm/-/jobs/242433
> >>
> >> You need to run that commit with pytest though...it does not
> >happen
> >> when run directly.
> >>
> >> BTW this sems to expose some rather nasty bug in dlmalloc or how
> >it is
> >> used. I notice that as soon as the first test is run, the 'top'
> >value
> >> in dlmalloc is outside the range of the malloc pool, which seems
> >> wrong. I wonder if there is something broken with how
> >> dm_test_pre_run() and dm_test_post_run() work.
> >>
> >>>
> >>> Corrupting gd could cause an endless recursive loop, as these
> >lines
> >>> follow printing the observed string:
> >>>
> >>> printf("pc = 0x%lx, ", pc);
> >>> printf("pc_reloc =0x%lx\n\n", pc - gd->reloc_off);
> >>
> >> Yes I suspect printf() is dead.
> >>
> >>>
> >>> If we remove SA_NODEFER from the signal mask in
> >arch/sandbox/cpu/os.c,
> >>> recursion cannot occur anymore. If a segmentation violation
> >occurs
> >>> inside the handler it will be delegated to the default handler.
> >>>
> >>> Furthermore we could consider removing the signal handler at the
> >start
> >>> of os_signal_action().
> >>
> >> The issue is that if you get a segfault you really don't know if
> >you
> >> can continue and do anything else.
> >>
> >> What is the goal with the signal handler? I don't think the user
> >can
> >> do anything about it.
>
> Hello Simon,
>
> the signal handler prints out the crash location and this makes
> analyzing problems much easier. It proved valuable to me several
> >times.
> >>>
> >>> Can't you just rerun with gdb?
> >>
> >> This would require that the problem is easily reproducible which may
> >not
> >> be the case.
> >
> >Hm, perhaps you could keep track of how many times we've tried to catch
> >a signal, and bail if this is the second time around. E.g. something
> >like
> >
>
> Removing SA_NODEFER from the signal mask will let the OS kick in if an
> exception occurs in a signal handler.
>
> No counter is needed.
Yes that is correct.
However I am still going to apply this patch, since I would prefer
that the default behaviour is to exit with a signal, rather than
continue. It indicates some sort of error (except if we are running a
strange test), so it seems wrong to try to continue. It may produce
other issues and sandbox is in an unknown state.
I am happy to discuss another way / patch for doing what you need.
Regards,
Simon
[..]
Re: [PATCH 1/8] imx8mm: Fix USB reg addresses for i.MX8MM
On 7/4/21 5:35 PM, Fabio Estevam wrote:
Hi Marek,
Hi,
On Sat, Jul 3, 2021 at 10:04 PM Marek Vasut wrote:
Retrieving the USB base addresses from DT would be preferred, yes, but
the current code does not do that.
I implemented exactly that in mx6_parse_dt_addrs() , see:
4dcfa3bcbcb ("usb: ehci-mx6: Parse USB PHY and MISC offsets from DT")
We are talking about USB_BASE_ADDR, right?
All of the addresses used by the driver, I am trying hard to get rid of
all that hard-coding in the driver. They should be parsed out of DT.
imx6/imx7/imxrt provide the USB_BASE_ADDR as define.
That's only because they still need to be fully converted, someone needs
to write the PHY driver for those. For MX8M, the NOP PHY driver is used.
If we remove the imx6 definition from arch/arm/include/asm/arch-mx6/imx-regs.h
the ehci-mx6: driver fails to build.
I didn't want to change ehci-mx6 in this aspect, so that's why I used
Frieder's patch that passes
USB_BASE_ADDR via define for i.MX8MM too.
Is this an acceptable solution?
No, let's not do that, because that exactly un-does the attempt to get
rid of these hard-coded addresses. Please parse the address out of DT.
And if you run into something which might still need hard-coded
addresses, please fix it.
The ehci-mx6 is bad, let's not make it worse, lets fix it instead.
Without providing these defines:
drivers/usb/host/ehci-mx6.c:254:62: error: ‘USB_BASE_ADDR’ undeclared
(first use in this function); did you mean ‘SRC_BASE_ADDR’?
254 | struct usbnc_regs *usbnc = (struct usbnc_regs
*)(uintptr_t)(USB_BASE_ADDR +
I suspect you need CONFIG_PHY for mx8m .
CONFIG_PHY is already selected by imx8mm_evk_defconfig.
USBNC is iMX7 specific , so you cannot hit that error on iMX8M, there is
#elif defined(CONFIG_MX7) around it.
[PATCH] misc: i2c_eeprom: Add atmel,24c01 to the list
Linux kernel binding is using atmel,24c01 compatible string. On the
other hand there is atmel,24c01a which is not listed in the kernel.
Add compatible string without "a" suffix to be compatible with Linux
kernel binding.
Signed-off-by: Marek Vasut
Cc: Heiko Schocher
Cc: Michal Simek
---
drivers/misc/i2c_eeprom.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/misc/i2c_eeprom.c b/drivers/misc/i2c_eeprom.c
index 5926c91a2e..99eff8442a 100644
--- a/drivers/misc/i2c_eeprom.c
+++ b/drivers/misc/i2c_eeprom.c
@@ -262,6 +262,7 @@ static const struct i2c_eeprom_drv_data atmel24c512_data = {
static const struct udevice_id i2c_eeprom_std_ids[] = {
{ .compatible = "i2c-eeprom", (ulong)&eeprom_data },
{ .compatible = "microchip,24aa02e48", (ulong)&mc24aa02e48_data },
+ { .compatible = "atmel,24c01", (ulong)&atmel24c01a_data },
{ .compatible = "atmel,24c01a", (ulong)&atmel24c01a_data },
{ .compatible = "atmel,24c02", (ulong)&atmel24c02_data },
{ .compatible = "atmel,24c04", (ulong)&atmel24c04_data },
--
2.30.2
[PATCH 1/2] board-info: Use sysinfo_get()
Replace uclass_first_device_err(UCLASS_SYSINFO, &dev) with sysinfo_get(&dev).
The board_info code may use sysinfo to print board information, so use the
sysinfo functions consistently. The sysinfo_get() is internally implemented
as return uclass_first_device_err(UCLASS_SYSINFO, &dev) anyway, so there is
no functional change.
Signed-off-by: Marek Vasut
Cc: Marcel Ziswiler
Cc: Simon Glass
---
common/board_info.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/common/board_info.c b/common/board_info.c
index 1cfe34f706..89a29c322c 100644
--- a/common/board_info.c
+++ b/common/board_info.c
@@ -31,7 +31,7 @@ int __weak show_board_info(void)
if (IS_ENABLED(CONFIG_SYSINFO)) {
/* This might provide more detail */
- ret = uclass_first_device_err(UCLASS_SYSINFO, &dev);
+ ret = sysinfo_get(&dev);
if (!ret)
ret = sysinfo_get_str(dev,
SYSINFO_ID_BOARD_MODEL,
--
2.30.2
[PATCH 2/2] board-info: Call sysinfo_detect() before sysinfo_get_str()
The sysinfo_get_str() implementation checks whether the sysinfo was even
detected. In U-Boot proper, sysinfo_detect() is not called anywhere but
on one specific board. Call sysinfo_detect() before sysinfo_get_str() to
make sure the sysinfo is detected and sysinfo_get_str() returns valid
value instead of -EPERM.
Signed-off-by: Marek Vasut
Cc: Marcel Ziswiler
Cc: Simon Glass
---
common/board_info.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/common/board_info.c b/common/board_info.c
index 89a29c322c..e0f2d93922 100644
--- a/common/board_info.c
+++ b/common/board_info.c
@@ -32,10 +32,14 @@ int __weak show_board_info(void)
if (IS_ENABLED(CONFIG_SYSINFO)) {
/* This might provide more detail */
ret = sysinfo_get(&dev);
- if (!ret)
- ret = sysinfo_get_str(dev,
+ if (!ret) {
+ ret = sysinfo_detect(dev);
+ if (!ret) {
+ ret = sysinfo_get_str(dev,
SYSINFO_ID_BOARD_MODEL,
sizeof(str), str);
+ }
+ }
}
/* Fail back to the main 'model' if available */
--
2.30.2
[PATCH] sysinfo: rcar3: Add Renesas R-Car Gen3 sysinfo driver
The Renesas R-Car Gen3 development kits contain board ID EEPROM.
This driver parses out the board ID and revision out of that
EEPROM and exports it e.g. for the board-info print on boot.
Signed-off-by: Marek Vasut
Cc: Sean Anderson
Cc: Simon Glass
---
drivers/sysinfo/Kconfig | 7 ++
drivers/sysinfo/Makefile | 1 +
drivers/sysinfo/rcar3.c | 197 +++
3 files changed, 205 insertions(+)
create mode 100644 drivers/sysinfo/rcar3.c
diff --git a/drivers/sysinfo/Kconfig b/drivers/sysinfo/Kconfig
index 381dcd8844..e35f7cb179 100644
--- a/drivers/sysinfo/Kconfig
+++ b/drivers/sysinfo/Kconfig
@@ -17,6 +17,13 @@ config SYSINFO_GAZERBEAM
help
Support querying device information for the gdsys Gazerbeam board.
+config SYSINFO_RCAR3
+ bool "Enable sysinfo driver for the Renesas R-Car Gen3"
+ depends on RCAR_GEN3 && I2C_EEPROM
+ default y if RCAR_GEN3
+ help
+ Support querying SoC version information for Renesas R-Car Gen3.
+
config SYSINFO_SANDBOX
bool "Enable sysinfo driver for the Sandbox board"
help
diff --git a/drivers/sysinfo/Makefile b/drivers/sysinfo/Makefile
index d9f708b7ea..680dde77fe 100644
--- a/drivers/sysinfo/Makefile
+++ b/drivers/sysinfo/Makefile
@@ -5,5 +5,6 @@
obj-y += sysinfo-uclass.o
obj-$(CONFIG_SYSINFO_GAZERBEAM) += gazerbeam.o
obj-$(CONFIG_SYSINFO_GPIO) += gpio.o
+obj-$(CONFIG_SYSINFO_RCAR3) += rcar3.o
obj-$(CONFIG_SYSINFO_SANDBOX) += sandbox.o
obj-$(CONFIG_SYSINFO_SMBIOS) += smbios.o
diff --git a/drivers/sysinfo/rcar3.c b/drivers/sysinfo/rcar3.c
new file mode 100644
index 00..c2f4ddfbbe
--- /dev/null
+++ b/drivers/sysinfo/rcar3.c
@@ -0,0 +1,197 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2021 Marek Vasut
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#define BOARD_CODE_MASK0xF8
+#define BOARD_REV_MASK 0x07
+#define BOARD_CODE_SHIFT 0x03
+
+#define BOARD_SALVATOR_X 0x0
+#define BOARD_KRIEK0x1
+#define BOARD_STARTER_KIT 0x2
+#define BOARD_SALVATOR_XS 0x4
+#define BOARD_EBISU0x8
+#define BOARD_STARTER_KIT_PRE 0xB
+#define BOARD_EBISU_4D 0xD
+#define BOARD_DRAAK0xE
+#define BOARD_EAGLE0xF
+
+/**
+ * struct sysinfo_rcar_priv - sysinfo private data
+ * @boardname: board model and revision
+ * @val: board ID value from eeprom
+ */
+struct sysinfo_rcar_priv {
+ charboardmodel[64];
+ u8 val;
+};
+
+static int sysinfo_rcar_detect(struct udevice *dev)
+{
+ struct sysinfo_rcar_priv *priv = dev_get_priv(dev);
+
+ return priv->val == 0xff;
+}
+
+static int sysinfo_rcar_get_str(struct udevice *dev, int id, size_t size, char
*val)
+{
+ struct sysinfo_rcar_priv *priv = dev_get_priv(dev);
+
+ switch (id) {
+ case SYSINFO_ID_BOARD_MODEL:
+ strncpy(val, priv->boardmodel, size);
+ val[size - 1] = '\0';
+ return 0;
+ default:
+ return -EINVAL;
+ };
+}
+
+static const struct sysinfo_ops sysinfo_rcar_ops = {
+ .detect = sysinfo_rcar_detect,
+ .get_str = sysinfo_rcar_get_str,
+};
+
+static void sysinfo_rcar_parse(struct sysinfo_rcar_priv *priv)
+{
+ const u8 board_id = (priv->val & BOARD_CODE_MASK) >> BOARD_CODE_SHIFT;
+ const u8 board_rev = priv->val & BOARD_REV_MASK;
+ bool salvator_xs = false;
+ bool ebisu_4d = false;
+ char rev_major = '?';
+ char rev_minor = '?';
+
+ switch (board_id) {
+ case BOARD_SALVATOR_XS:
+ salvator_xs = true;
+ fallthrough;
+ case BOARD_SALVATOR_X:
+ if (!(board_rev & ~1)) { /* Only rev 0 and 1 is valid */
+ rev_major = '1';
+ rev_minor = '0' + (board_rev & BIT(0));
+ }
+ snprintf(priv->boardmodel, sizeof(priv->boardmodel),
+"Renesas Salvator-X%s board rev %c.%c",
+salvator_xs ? "S" : "", rev_major, rev_minor);
+ return;
+ case BOARD_STARTER_KIT:
+ if (!(board_rev & ~1)) { /* Only rev 0 and 1 is valid */
+ rev_major = (board_rev & BIT(0)) ? '3' : '1';
+ rev_minor = '0';
+ }
+ snprintf(priv->boardmodel, sizeof(priv->boardmodel),
+"Renesas Starter Kit board rev %c.%c",
+rev_major, rev_minor);
+ return;
+ case BOARD_STARTER_KIT_PRE:
+ if (!(board_rev & ~3)) { /* Only rev 0..3 is valid */
+ rev_major = (board_rev & BIT(1)) ? '2' : '1';
+ rev_minor = (board_rev == 3) ? '1' : '0';
+ }
+ snprintf(priv->boardmodel, sizeof(priv->boardmodel),
+"Renesas Starter Kit Premier board rev %c.%c",
+rev
[PATCH 1/3] ARM: dts: rmobile: Add sysinfo extras on R-Car Gen3
Add sysinfo node and phandle to the board ID EEPROM on all boards
where this functionality is described in DT, which is Salvator-X(S),
ULCB and Ebisu. The u-boot,dm-pre-reloc is necessary here, since the
sysinfo must be available early during boot. The V3M and V3H boards
currently do not describe this board ID EEPROM in upstream DT, but
that could be easily added later, once the DTs contain the necessary
nodes.
ULCB and Ebisu needs the full EEPROM node in the u-boot extras DT,
since the EEPROM node is still missing in the upstream DTs. Ebisu
also needs extra compatible string override for the i2c_dvfs.
Signed-off-by: Marek Vasut
---
arch/arm/dts/r8a77950-salvator-x-u-boot.dts | 17 +++
arch/arm/dts/r8a77950-ulcb-u-boot.dts | 18
arch/arm/dts/r8a77960-salvator-x-u-boot.dts | 17 +++
arch/arm/dts/r8a77960-ulcb-u-boot.dts | 18
arch/arm/dts/r8a77965-salvator-x-u-boot.dts | 17 +++
arch/arm/dts/r8a77965-ulcb-u-boot.dts | 18
arch/arm/dts/r8a77990-ebisu-u-boot.dts | 23 +
7 files changed, 128 insertions(+)
diff --git a/arch/arm/dts/r8a77950-salvator-x-u-boot.dts
b/arch/arm/dts/r8a77950-salvator-x-u-boot.dts
index 36c8a44a90..bb83bc1d7b 100644
--- a/arch/arm/dts/r8a77950-salvator-x-u-boot.dts
+++ b/arch/arm/dts/r8a77950-salvator-x-u-boot.dts
@@ -8,6 +8,23 @@
#include "r8a77950-salvator-x.dts"
#include "r8a77950-u-boot.dtsi"
+/ {
+ sysinfo {
+ compatible = "renesas,rcar-sysinfo";
+ i2c-eeprom = <&sysinfo_eeprom>;
+ u-boot,dm-pre-reloc;
+ };
+};
+
+&i2c_dvfs {
+ u-boot,dm-pre-reloc;
+
+ sysinfo_eeprom: eeprom@50 {
+ u-boot,dm-pre-reloc;
+ status = "okay";
+ };
+};
+
&rpc {
reg = <0 0xee20 0 0x100>, <0 0x0800 0 0x0400>;
status = "okay";
diff --git a/arch/arm/dts/r8a77950-ulcb-u-boot.dts
b/arch/arm/dts/r8a77950-ulcb-u-boot.dts
index d3191c55d5..16d9e38b70 100644
--- a/arch/arm/dts/r8a77950-ulcb-u-boot.dts
+++ b/arch/arm/dts/r8a77950-ulcb-u-boot.dts
@@ -17,6 +17,24 @@
gpio-miso = <&gpio6 10 0>;
gpio-sstbz = <&gpio2 3 0>;
};
+
+ sysinfo {
+ compatible = "renesas,rcar-sysinfo";
+ i2c-eeprom = <&sysinfo_eeprom>;
+ u-boot,dm-pre-reloc;
+ };
+};
+
+&i2c_dvfs {
+ u-boot,dm-pre-reloc;
+
+ sysinfo_eeprom: eeprom@50 {
+ compatible = "rohm,br24t01", "atmel,24c01";
+ reg = <0x50>;
+ pagesize = <8>;
+ u-boot,dm-pre-reloc;
+ status = "okay";
+ };
};
&rpc {
diff --git a/arch/arm/dts/r8a77960-salvator-x-u-boot.dts
b/arch/arm/dts/r8a77960-salvator-x-u-boot.dts
index 439fd6c3ad..dda3567e9e 100644
--- a/arch/arm/dts/r8a77960-salvator-x-u-boot.dts
+++ b/arch/arm/dts/r8a77960-salvator-x-u-boot.dts
@@ -8,6 +8,23 @@
#include "r8a77960-salvator-x.dts"
#include "r8a77960-u-boot.dtsi"
+/ {
+ sysinfo {
+ compatible = "renesas,rcar-sysinfo";
+ i2c-eeprom = <&sysinfo_eeprom>;
+ u-boot,dm-pre-reloc;
+ };
+};
+
+&i2c_dvfs {
+ u-boot,dm-pre-reloc;
+
+ sysinfo_eeprom: eeprom@50 {
+ u-boot,dm-pre-reloc;
+ status = "okay";
+ };
+};
+
&rpc {
reg = <0 0xee20 0 0x100>, <0 0x0800 0 0x0400>;
status = "okay";
diff --git a/arch/arm/dts/r8a77960-ulcb-u-boot.dts
b/arch/arm/dts/r8a77960-ulcb-u-boot.dts
index aab9c95931..e4f77ae262 100644
--- a/arch/arm/dts/r8a77960-ulcb-u-boot.dts
+++ b/arch/arm/dts/r8a77960-ulcb-u-boot.dts
@@ -17,6 +17,24 @@
gpio-miso = <&gpio6 10 0>;
gpio-sstbz = <&gpio2 3 0>;
};
+
+ sysinfo {
+ compatible = "renesas,rcar-sysinfo";
+ i2c-eeprom = <&sysinfo_eeprom>;
+ u-boot,dm-pre-reloc;
+ };
+};
+
+&i2c_dvfs {
+ u-boot,dm-pre-reloc;
+
+ sysinfo_eeprom: eeprom@50 {
+ compatible = "rohm,br24t01", "atmel,24c01";
+ reg = <0x50>;
+ pagesize = <8>;
+ u-boot,dm-pre-reloc;
+ status = "okay";
+ };
};
&rpc {
diff --git a/arch/arm/dts/r8a77965-salvator-x-u-boot.dts
b/arch/arm/dts/r8a77965-salvator-x-u-boot.dts
index 8cbef83b9c..e651e889bc 100644
--- a/arch/arm/dts/r8a77965-salvator-x-u-boot.dts
+++ b/arch/arm/dts/r8a77965-salvator-x-u-boot.dts
@@ -8,6 +8,23 @@
#include "r8a77965-salvator-x.dts"
#include "r8a77965-u-boot.dtsi"
+/ {
+ sysinfo {
+ compatible = "renesas,rcar-sysinfo";
+ i2c-eeprom = <&sysinfo_eeprom>;
+ u-boot,dm-pre-reloc;
+ };
+};
+
+&i2c_dvfs {
+ u-boot,dm-pre-reloc;
+
+ sysinfo_eeprom: eeprom@50 {
+ u-boot,dm-pre-reloc;
+ status = "okay";
+ };
+};
+
&rpc {
reg
[PATCH 2/3] ARM: rmobile: Enable I2C EEPROM support on R-Car Gen3
Enable support for I2C EEPROM driver on supported Renesas R-Car Gen3 boards. This is useful for accessing the board ID EEPROM. Signed-off-by: Marek Vasut --- configs/r8a77990_ebisu_defconfig | 7 +++ configs/rcar3_salvator-x_defconfig | 7 +++ configs/rcar3_ulcb_defconfig | 7 +++ 3 files changed, 21 insertions(+) diff --git a/configs/r8a77990_ebisu_defconfig b/configs/r8a77990_ebisu_defconfig index 15743c1a81..13ca814cbc 100644 --- a/configs/r8a77990_ebisu_defconfig +++ b/configs/r8a77990_ebisu_defconfig @@ -50,6 +50,13 @@ CONFIG_DFU_SF=y CONFIG_RCAR_GPIO=y CONFIG_DM_I2C=y CONFIG_SYS_I2C_RCAR_IIC=y +CONFIG_MISC=y +CONFIG_I2C_EEPROM=y +CONFIG_SYS_I2C_EEPROM_ADDR=0x70 +CONFIG_SYS_I2C_EEPROM_BUS=7 +CONFIG_SYS_EEPROM_SIZE=128 +CONFIG_SYS_EEPROM_PAGE_WRITE_BITS=7 +CONFIG_SYS_EEPROM_PAGE_WRITE_DELAY_MS=10 CONFIG_MMC_IO_VOLTAGE=y CONFIG_MMC_UHS_SUPPORT=y CONFIG_MMC_HS400_SUPPORT=y diff --git a/configs/rcar3_salvator-x_defconfig b/configs/rcar3_salvator-x_defconfig index efd6ca2da8..ef9775abfa 100644 --- a/configs/rcar3_salvator-x_defconfig +++ b/configs/rcar3_salvator-x_defconfig @@ -52,6 +52,13 @@ CONFIG_DFU_SF=y CONFIG_RCAR_GPIO=y CONFIG_DM_I2C=y CONFIG_SYS_I2C_RCAR_IIC=y +CONFIG_MISC=y +CONFIG_I2C_EEPROM=y +CONFIG_SYS_I2C_EEPROM_ADDR=0x70 +CONFIG_SYS_I2C_EEPROM_BUS=7 +CONFIG_SYS_EEPROM_SIZE=128 +CONFIG_SYS_EEPROM_PAGE_WRITE_BITS=7 +CONFIG_SYS_EEPROM_PAGE_WRITE_DELAY_MS=10 CONFIG_MMC_IO_VOLTAGE=y CONFIG_MMC_UHS_SUPPORT=y CONFIG_MMC_HS400_SUPPORT=y diff --git a/configs/rcar3_ulcb_defconfig b/configs/rcar3_ulcb_defconfig index a857e5bd1c..cfec485ec7 100644 --- a/configs/rcar3_ulcb_defconfig +++ b/configs/rcar3_ulcb_defconfig @@ -52,6 +52,13 @@ CONFIG_DFU_SF=y CONFIG_RCAR_GPIO=y CONFIG_DM_I2C=y CONFIG_SYS_I2C_RCAR_IIC=y +CONFIG_MISC=y +CONFIG_I2C_EEPROM=y +CONFIG_SYS_I2C_EEPROM_ADDR=0x70 +CONFIG_SYS_I2C_EEPROM_BUS=7 +CONFIG_SYS_EEPROM_SIZE=128 +CONFIG_SYS_EEPROM_PAGE_WRITE_BITS=7 +CONFIG_SYS_EEPROM_PAGE_WRITE_DELAY_MS=10 CONFIG_MMC_IO_VOLTAGE=y CONFIG_MMC_UHS_SUPPORT=y CONFIG_MMC_HS400_SUPPORT=y -- 2.30.2
[PATCH 3/3] ARM: rmobile: Enable sysinfo on R-Car Gen3
Enable support for sysinfo on supported R-Car Gen3 boards. The sysinfo is used e.g. to access and decode board-specific information and then in turn used by board-info to print those information. On R-Car Gen3 the sysinfo rcar3 driver is used to parse the board ID EEPROM, obtain board type and revision from it, and let board-info print this information on boot. Signed-off-by: Marek Vasut --- configs/r8a77990_ebisu_defconfig | 1 + configs/rcar3_salvator-x_defconfig | 1 + configs/rcar3_ulcb_defconfig | 1 + 3 files changed, 3 insertions(+) diff --git a/configs/r8a77990_ebisu_defconfig b/configs/r8a77990_ebisu_defconfig index 13ca814cbc..69297fef66 100644 --- a/configs/r8a77990_ebisu_defconfig +++ b/configs/r8a77990_ebisu_defconfig @@ -83,6 +83,7 @@ CONFIG_SCIF_CONSOLE=y CONFIG_SPI=y CONFIG_DM_SPI=y CONFIG_RENESAS_RPC_SPI=y +CONFIG_SYSINFO=y CONFIG_TEE=y CONFIG_OPTEE=y CONFIG_USB=y diff --git a/configs/rcar3_salvator-x_defconfig b/configs/rcar3_salvator-x_defconfig index ef9775abfa..150db3bff5 100644 --- a/configs/rcar3_salvator-x_defconfig +++ b/configs/rcar3_salvator-x_defconfig @@ -90,6 +90,7 @@ CONFIG_SCIF_CONSOLE=y CONFIG_SPI=y CONFIG_DM_SPI=y CONFIG_RENESAS_RPC_SPI=y +CONFIG_SYSINFO=y CONFIG_TEE=y CONFIG_OPTEE=y CONFIG_USB=y diff --git a/configs/rcar3_ulcb_defconfig b/configs/rcar3_ulcb_defconfig index cfec485ec7..a6f806c3c3 100644 --- a/configs/rcar3_ulcb_defconfig +++ b/configs/rcar3_ulcb_defconfig @@ -86,6 +86,7 @@ CONFIG_SPI=y CONFIG_DM_SPI=y CONFIG_RENESAS_RPC_SPI=y CONFIG_SYSRESET=y +CONFIG_SYSINFO=y CONFIG_TEE=y CONFIG_OPTEE=y CONFIG_USB=y -- 2.30.2
[PATCH] ARM: rmobile: Align CPU: print with other prints
The CPU: print only has one space after it, while the other prints
from U-Boot align the value to offset 7. Align the CPU: print too.
No functional change.
Signed-off-by: Marek Vasut
---
arch/arm/mach-rmobile/cpu_info.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-rmobile/cpu_info.c b/arch/arm/mach-rmobile/cpu_info.c
index 9ec622bdb5..83bbc4e72a 100644
--- a/arch/arm/mach-rmobile/cpu_info.c
+++ b/arch/arm/mach-rmobile/cpu_info.c
@@ -118,7 +118,7 @@ int print_cpuinfo(void)
{
int i = rmobile_cpuinfo_idx();
- printf("CPU: Renesas Electronics %s rev %d.%d\n",
+ printf("CPU: Renesas Electronics %s rev %d.%d\n",
get_cpu_name(i), rmobile_get_cpu_rev_integer(),
rmobile_get_cpu_rev_fraction());
--
2.30.2
[PATCH] ARM: rmobile: Remove default bootargs
The bootargs in all those boards are a copy of initial example bootargs, just remove those as they make little sense in most configurations. Signed-off-by: Marek Vasut --- configs/hihope_rzg2_defconfig | 1 - configs/r8a77970_eagle_defconfig | 1 - configs/r8a77980_condor_defconfig | 1 - configs/r8a77990_ebisu_defconfig | 1 - configs/r8a77995_draak_defconfig | 1 - configs/rcar3_salvator-x_defconfig | 1 - configs/rcar3_ulcb_defconfig | 1 - 7 files changed, 7 deletions(-) diff --git a/configs/hihope_rzg2_defconfig b/configs/hihope_rzg2_defconfig index be71ebb6a2..800481326d 100644 --- a/configs/hihope_rzg2_defconfig +++ b/configs/hihope_rzg2_defconfig @@ -12,7 +12,6 @@ CONFIG_TARGET_HIHOPE_RZG2=y CONFIG_FIT=y CONFIG_SUPPORT_RAW_INITRD=y CONFIG_USE_BOOTARGS=y -CONFIG_BOOTARGS="root=/dev/nfs rw nfsroot=192.168.0.1:/export/rfs ip=192.168.0.20" CONFIG_DEFAULT_FDT_FILE="r8a774a1-hihope-rzg2m.dtb" # CONFIG_BOARD_EARLY_INIT_F is not set CONFIG_HUSH_PARSER=y diff --git a/configs/r8a77970_eagle_defconfig b/configs/r8a77970_eagle_defconfig index 2e5fb60f1a..2532154978 100644 --- a/configs/r8a77970_eagle_defconfig +++ b/configs/r8a77970_eagle_defconfig @@ -14,7 +14,6 @@ CONFIG_TARGET_EAGLE=y CONFIG_FIT=y CONFIG_SUPPORT_RAW_INITRD=y CONFIG_USE_BOOTARGS=y -CONFIG_BOOTARGS="root=/dev/nfs rw nfsroot=192.168.0.1:/export/rfs ip=192.168.0.20" CONFIG_DEFAULT_FDT_FILE="r8a77970-eagle.dtb" CONFIG_HUSH_PARSER=y CONFIG_CMD_BOOTZ=y diff --git a/configs/r8a77980_condor_defconfig b/configs/r8a77980_condor_defconfig index 1b9948bcbb..02f008ad35 100644 --- a/configs/r8a77980_condor_defconfig +++ b/configs/r8a77980_condor_defconfig @@ -14,7 +14,6 @@ CONFIG_TARGET_CONDOR=y CONFIG_FIT=y CONFIG_SUPPORT_RAW_INITRD=y CONFIG_USE_BOOTARGS=y -CONFIG_BOOTARGS="root=/dev/nfs rw nfsroot=192.168.0.1:/export/rfs ip=192.168.0.20" CONFIG_DEFAULT_FDT_FILE="r8a77980-condor.dtb" # CONFIG_BOARD_EARLY_INIT_F is not set CONFIG_HUSH_PARSER=y diff --git a/configs/r8a77990_ebisu_defconfig b/configs/r8a77990_ebisu_defconfig index 69297fef66..e5cab47f9f 100644 --- a/configs/r8a77990_ebisu_defconfig +++ b/configs/r8a77990_ebisu_defconfig @@ -13,7 +13,6 @@ CONFIG_TARGET_EBISU=y CONFIG_FIT=y CONFIG_SUPPORT_RAW_INITRD=y CONFIG_USE_BOOTARGS=y -CONFIG_BOOTARGS="root=/dev/nfs rw nfsroot=192.168.0.1:/export/rfs ip=192.168.0.20" CONFIG_DEFAULT_FDT_FILE="r8a77990-ebisu.dtb" # CONFIG_BOARD_EARLY_INIT_F is not set CONFIG_UPDATE_TFTP=y diff --git a/configs/r8a77995_draak_defconfig b/configs/r8a77995_draak_defconfig index 562b80b996..acae38a6c0 100644 --- a/configs/r8a77995_draak_defconfig +++ b/configs/r8a77995_draak_defconfig @@ -13,7 +13,6 @@ CONFIG_TARGET_DRAAK=y CONFIG_FIT=y CONFIG_SUPPORT_RAW_INITRD=y CONFIG_USE_BOOTARGS=y -CONFIG_BOOTARGS="root=/dev/nfs rw nfsroot=192.168.0.1:/export/rfs ip=192.168.0.20" CONFIG_DEFAULT_FDT_FILE="r8a77995-draak.dtb" CONFIG_UPDATE_TFTP=y CONFIG_HUSH_PARSER=y diff --git a/configs/rcar3_salvator-x_defconfig b/configs/rcar3_salvator-x_defconfig index 150db3bff5..bb0bcfefe2 100644 --- a/configs/rcar3_salvator-x_defconfig +++ b/configs/rcar3_salvator-x_defconfig @@ -12,7 +12,6 @@ CONFIG_TARGET_SALVATOR_X=y CONFIG_FIT=y CONFIG_SUPPORT_RAW_INITRD=y CONFIG_USE_BOOTARGS=y -CONFIG_BOOTARGS="root=/dev/nfs rw nfsroot=192.168.0.1:/export/rfs ip=192.168.0.20" CONFIG_DEFAULT_FDT_FILE="r8a77950-salvator-x.dtb" CONFIG_UPDATE_TFTP=y CONFIG_HUSH_PARSER=y diff --git a/configs/rcar3_ulcb_defconfig b/configs/rcar3_ulcb_defconfig index a6f806c3c3..e0d72d940d 100644 --- a/configs/rcar3_ulcb_defconfig +++ b/configs/rcar3_ulcb_defconfig @@ -13,7 +13,6 @@ CONFIG_TARGET_ULCB=y CONFIG_FIT=y CONFIG_SUPPORT_RAW_INITRD=y CONFIG_USE_BOOTARGS=y -CONFIG_BOOTARGS="root=/dev/nfs rw nfsroot=192.168.0.1:/export/rfs ip=192.168.0.20" CONFIG_DEFAULT_FDT_FILE="r8a77950-ulcb.dtb" CONFIG_UPDATE_TFTP=y CONFIG_HUSH_PARSER=y -- 2.30.2
[PATCH] ARM: renesas: Set CONFIG_SYS_TEXT_BASE=0x0 on R-Car Gen3
Since R-Car Gen3 already enables position independent build, also set
CONFIG_SYS_TEXT_BASE=0x0 to finalize the switch. This is possible since
534f0fbd65 ("arm64: Fix relocation of env_addr if POSITION_INDEPENDENT=y")
fixed current env_get_char() crash with CONFIG_SYS_TEXT_BASE=0x0 .
This change permits us to start U-Boot from any location in DRAM instead
of specific TEXT_BASE.
Signed-off-by: Marek Vasut
---
configs/rcar3_salvator-x_defconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configs/rcar3_salvator-x_defconfig
b/configs/rcar3_salvator-x_defconfig
index bb0bcfefe2..709e6435ae 100644
--- a/configs/rcar3_salvator-x_defconfig
+++ b/configs/rcar3_salvator-x_defconfig
@@ -1,7 +1,7 @@
CONFIG_ARM=y
CONFIG_ARCH_CPU_INIT=y
CONFIG_ARCH_RMOBILE=y
-CONFIG_SYS_TEXT_BASE=0x5000
+CONFIG_SYS_TEXT_BASE=0x0
CONFIG_ENV_SIZE=0x2
CONFIG_ENV_OFFSET=0xFFFE
CONFIG_DM_GPIO=y
--
2.30.2
[PATCH] arm: imx: Fix spl imx romapi for imx8mn
We experimenting problems with imx8mn family cpu. We try to support
boot0 and boot1 fallback.
The condition to decide what function the bootrom should choose
come from is_boot_from_stream_device
This is a boot from mmcblk0boot0 with some debug
U-Boot SPL 2020.04-5.4.70-2.3.2+gf3bcbdfc62 (Jul 03 2021 - 17:00:27 +)
power_bd71837_init
DDRINFO: start DRAM init
DDRINFO: DRAM rate 1600MTS
DDRINFO:ddrphy calibration done
DDRINFO: ddrmix config done
Normal Boot
Trying to boot from BOOTROM
ROM API interface 2 from boot 131073
Interface is 2 MMC and boot is 131073 and according to this
static int is_boot_from_stream_device(u32 boot)
+{
+ u32 interface;
+
+ interface = boot >> 16;
+ if (interface >= BT_DEV_TYPE_USB)
+ return 1;
+
+ if (interface == BT_DEV_TYPE_MMC && (boot & 1))
+ return 1;
+
+ return 0;
+}
the return is 1, that does not allow us to boot.
Boot from boot1 give 131072 that is boot1 this let device boot because
is_boot_from_stream_device is 0 and
romapi use spl_romapi_load_image_seekable
Adjust the bootcondition let us boot from mmcblk0boot0 and
mmcblk0boot1 without any problem
mmc partconf 0
EXT_CSD[179], PARTITION_CONFIG:
BOOT_ACK: 0x0
BOOT_PARTITION_ENABLE: 0x1
PARTITION_ACCESS: 0x0
and the board was fused already.
Signed-off-by: Michael Trimarchi
---
arch/arm/mach-imx/spl_imx_romapi.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-imx/spl_imx_romapi.c
b/arch/arm/mach-imx/spl_imx_romapi.c
index 7e6a05a6f3..36f8848d45 100644
--- a/arch/arm/mach-imx/spl_imx_romapi.c
+++ b/arch/arm/mach-imx/spl_imx_romapi.c
@@ -18,10 +18,11 @@ static int is_boot_from_stream_device(u32 boot)
u32 interface;
interface = boot >> 16;
+
if (interface >= BT_DEV_TYPE_USB)
return 1;
- if (interface == BT_DEV_TYPE_MMC && (boot & 1))
+ if (!is_imx8mn() && interface == BT_DEV_TYPE_MMC && (boot & 1))
return 1;
return 0;
--
2.25.1
[RFC PATCH] mtd: mxs_nand: Add support for edo mode for imx6ul(lz) architecture
Add a proof of concept to support nand speed mode. This reduce load
time about 4 times for large binary
Signed-off-by: Michael Trimarchi
---
arch/arm/include/asm/mach-imx/regs-gpmi.h | 9 +
drivers/mtd/nand/raw/mxs_nand.c | 238 --
drivers/mtd/nand/raw/mxs_nand_dt.c| 9 +-
include/mxs_nand.h| 1 +
4 files changed, 242 insertions(+), 15 deletions(-)
diff --git a/arch/arm/include/asm/mach-imx/regs-gpmi.h
b/arch/arm/include/asm/mach-imx/regs-gpmi.h
index 33daa53c45..7a15778631 100644
--- a/arch/arm/include/asm/mach-imx/regs-gpmi.h
+++ b/arch/arm/include/asm/mach-imx/regs-gpmi.h
@@ -93,6 +93,11 @@ struct mxs_gpmi_regs {
#defineGPMI_CTRL1_DECOUPLE_CS (1 << 24)
#defineGPMI_CTRL1_WRN_DLY_SEL_MASK (0x3 << 22)
#defineGPMI_CTRL1_WRN_DLY_SEL_OFFSET 22
+#defineGPMI_CTRL1_WRN_DLY_SEL_4_TO_8NS 0x0
+#defineGPMI_CTRL1_WRN_DLY_SEL_6_TO_10NS0x1
+#defineGPMI_CTRL1_WRN_DLY_SEL_7_TO_12NS0x2
+#defineGPMI_CTRL1_WRN_DLY_SEL_NO_DELAY 0x3
+
#defineGPMI_CTRL1_TIMEOUT_IRQ_EN (1 << 20)
#defineGPMI_CTRL1_GANGED_RDYBUSY (1 << 19)
#defineGPMI_CTRL1_BCH_MODE (1 << 18)
@@ -111,6 +116,10 @@ struct mxs_gpmi_regs {
#defineGPMI_CTRL1_ATA_IRQRDY_POLARITY (1 << 2)
#defineGPMI_CTRL1_CAMERA_MODE (1 << 1)
#defineGPMI_CTRL1_GPMI_MODE(1 << 0)
+#defineGPMI_CTRL1_CLEAR_MASK
(GPMI_CTRL1_WRN_DLY_SEL_MASK | \
+GPMI_CTRL1_DLL_ENABLE
| \
+
GPMI_CTRL1_RDN_DELAY_MASK | \
+GPMI_CTRL1_HALF_PERIOD)
#defineGPMI_TIMING0_ADDRESS_SETUP_MASK (0xff << 16)
#defineGPMI_TIMING0_ADDRESS_SETUP_OFFSET 16
diff --git a/drivers/mtd/nand/raw/mxs_nand.c b/drivers/mtd/nand/raw/mxs_nand.c
index e56ebcfddc..ba1ce9cf4c 100644
--- a/drivers/mtd/nand/raw/mxs_nand.c
+++ b/drivers/mtd/nand/raw/mxs_nand.c
@@ -26,8 +26,11 @@
#include
#include
#include
+#include
#include
#include
+#include
+#include
#defineMXS_NAND_DMA_DESCRIPTOR_COUNT 4
@@ -46,6 +49,10 @@
#endif
#defineMXS_NAND_BCH_TIMEOUT1
+#define USEC_PER_SEC 100
+#define NSEC_PER_SEC 10L
+
+#define TO_CYCLES(duration, period) DIV_ROUND_UP_ULL(duration, period)
struct nand_ecclayout fake_ecc_layout;
@@ -1310,6 +1317,206 @@ err1:
return ret;
}
+#if (defined(CONFIG_MX6UL) || defined(CONFIG_MX6ULL))
+/*
+ * <1> Firstly, we should know what's the GPMI-clock means.
+ * The GPMI-clock is the internal clock in the gpmi nand controller.
+ * If you set 100MHz to gpmi nand controller, the GPMI-clock's period
+ * is 10ns. Mark the GPMI-clock's period as GPMI-clock-period.
+ *
+ * <2> Secondly, we should know what's the frequency on the nand chip pins.
+ * The frequency on the nand chip pins is derived from the GPMI-clock.
+ * We can get it from the following equation:
+ *
+ * F = G / (DS + DH)
+ *
+ * F : the frequency on the nand chip pins.
+ * G : the GPMI clock, such as 100MHz.
+ * DS : GPMI_HW_GPMI_TIMING0:DATA_SETUP
+ * DH : GPMI_HW_GPMI_TIMING0:DATA_HOLD
+ *
+ * <3> Thirdly, when the frequency on the nand chip pins is above 33MHz,
+ * the nand EDO(extended Data Out) timing could be applied.
+ * The GPMI implements a feedback read strobe to sample the read data.
+ * The feedback read strobe can be delayed to support the nand EDO timing
+ * where the read strobe may deasserts before the read data is valid, and
+ * read data is valid for some time after read strobe.
+ *
+ * The following figure illustrates some aspects of a NAND Flash read:
+ *
+ * |<---tREA>|
+ * | |
+ * | | |
+ * |<--tRP-->| |
+ * | | |
+ * __ ___|__
+ * RDN\/ |
+ * |
+ * /-\
+ * Read Data--< >-
+ * \-/
+ *| |
+ *|<-D->|
+ * FeedbackRDN
+ * \___/
+ *
+ * D stands for delay, set in the HW_GPMI_CTRL1:RDN_DELAY.
+ *
+ *
+ * <4> Now, we begin to des
Re: [PATCH 0/8] sunxi: mmc: Fixes and speed increase
On 7/3/21 6:24 PM, Andre Przywara wrote: > On Tue, 25 May 2021 00:30:21 +0100 > Andre Przywara wrote: > > Hi, > > thanks to Jaehoon for reviewing some patches in here! > > Can anyone else please have a look at this series? > I am tempted to push them in the upcoming merge window, to expose them > to a wider testing audience, but would really like to have some > people's eyes on it. > > Also testing this on different boards would be much appreciated, > especially patch 7/8 deserves some scrutiny, I guess. For the series: Tested-by: Samuel Holland I have this patch series integrated into my local branch, so I have boot-tested it on several boards: PinePhone (A64), Pine A64+ (A64), Orange Pi Win (A64), Orange Pi PC2 (H5), and Orange Pi Zero 2 (H616). Cheers, Samuel
Re: [PATCH] tools: Fix default target compile tools in Python tools
In commit 1e4687aa47ed ("binman: Use target-specific tools when
cross-compiling"), a utility function was implemented to get preferred
compilation tools using environment variables like CC and CROSS_COMPILE.
Although it intended to provide custom default tools (same as those in
the global Makefile) when no relevant variables were set (for example
using "gcc" for "cc"), it is only doing so when CROSS_COMPILE is set and
returning the literal name of the tool otherwise.
Remove the check for an empty CROSS_COMPILE, which makes the function
use it as an empty prefix to the custom defaults and return the intended
executables.
Fixes: 1e4687aa47ed ("binman: Use target-specific tools when cross-compiling")
Signed-off-by: Alper Nebi Yasak
---
tools/patman/tools.py | 2 --
1 file changed, 2 deletions(-)
Applied to u-boot-dm/next, thanks!
Re: [PATCH] remove struct uclass_driver::ops
On Wed, 19 May 2021 at 10:08, Rasmus Villemoes wrote: > > Each _device_ belonging to a given uclass of course has its own ->ops, > of a type determined by and known to the uclass. > > However, no instance of a uclass_driver seems to populate ->ops, and > the only reference to it in code is this relocation. > > Moreover, it's not really clear what could sensibly be assigned; it > would have to be some "struct uclass_ops *" providing a set of methods > for the core to call on that particular uclass, but should the need > for that ever arise, it would be better to have a member of that > particular type instead of void*. > > Signed-off-by: Rasmus Villemoes > --- > drivers/core/root.c | 3 --- > include/dm/uclass.h | 3 --- > 2 files changed, 6 deletions(-) Reviewed-by: Simon Glass Applied to u-boot-dm/next, thanks!
Re: [PATCH v2 1/1] sandbox: don't refer to symbol _init
> From: U-Boot On Behalf Of Heinrich Schuchardt > Sent: Wednesday, May 19, 2021 6:03 PM > To: Simon Glass > Cc: Ovidiu Panait ; Bin Meng > ; Stefan Roese ; Masahiro Yamada > ; u-boot@lists.denx.de; Heinrich Schuchardt > > Subject: [PATCH v2 1/1] sandbox: don't refer to symbol _init > > GCC provides a symbol _init in crti.o on x86_64 and aarch64 but not on > RISC-V. The following lines leads to a build error for sandbox_defconfig on > RISC-V due to the missing symbol: > > common/board_f.c:269: > #elif defined(CONFIG_SANDBOX) || defined(CONFIG_EFI_APP) > gd->mon_len = (ulong)&_end - (ulong)_init; > > The sandbox code is not copied into the memory allocated using mmap(). > Hence we can safely use gd->mon_len = 0 to avoid the reference to _init. > > Signed-off-by: Heinrich Schuchardt > Reviewed-by: Bin Meng > --- > v2: > fix typo in commit message > --- > common/board_f.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) Reviewed-by: Rick Chen Applied to u-boot-dm/next, thanks!
Re: [PATCH 1/1] sandbox: fix sandbox_reset()
On Wed, 12 May 2021 at 10:39, Heinrich Schuchardt wrote: > > state_uninit() and dm_uninit() are mutually exclusive: > > state_uninit() prints via drivers. So it cannot be executed after > dm_uninit(). > > dm_uninit() requires memory. So it cannot be executed after state_uninit() > which releases all memory. > > Just skip dm_uninit() when resetting the sandbox. We will wake up in a new > process and allocate new memory. So this cleanup is not required. We don't > do it in sandbox_exit() either. > > This avoids a segmentation error when efi_reset_system_boottime() is > invoked by a UEFI application. > > Signed-off-by: Heinrich Schuchardt > --- > arch/sandbox/cpu/start.c | 3 --- > 1 file changed, 3 deletions(-) Reviewed-by: Simon Glass Applied to u-boot-dm/next, thanks!
Re: [PATCH] dm: define LOG_CATEGORY for all uclass
On Tue, 27 Apr 2021 at 02:02, Patrick Delaunay wrote: > > Define LOG_CATEGORY for all uclass to allow filtering with > log command. > > Signed-off-by: Patrick Delaunay > --- > > drivers/adc/adc-uclass.c| 2 ++ > drivers/ata/ahci-uclass.c | 2 ++ > drivers/axi/axi-emul-uclass.c | 2 ++ > drivers/axi/axi-uclass.c| 2 ++ > drivers/block/blk-uclass.c | 2 ++ > drivers/block/ide.c | 2 ++ > drivers/bootcount/bootcount-uclass.c| 2 ++ > drivers/button/button-uclass.c | 2 ++ > drivers/cache/cache-uclass.c| 2 ++ > drivers/clk/clk-uclass.c| 2 ++ > drivers/core/root.c | 2 ++ > drivers/core/simple-bus.c | 2 ++ > drivers/cpu/cpu-uclass.c| 2 ++ > drivers/crypto/rsa_mod_exp/mod_exp_uclass.c | 2 ++ > drivers/dma/dma-uclass.c| 2 ++ > drivers/firmware/firmware-uclass.c | 2 ++ > drivers/hwspinlock/hwspinlock-uclass.c | 2 ++ > drivers/i2c/i2c-emul-uclass.c | 2 ++ > drivers/i2c/i2c-uclass.c| 2 ++ > drivers/i2c/muxes/i2c-mux-uclass.c | 2 ++ > drivers/input/keyboard-uclass.c | 2 ++ > drivers/led/led-uclass.c| 2 ++ > drivers/mailbox/mailbox-uclass.c| 2 ++ > drivers/misc/fs_loader.c| 3 +++ > drivers/misc/i2c_eeprom.c | 2 ++ > drivers/misc/misc-uclass.c | 2 ++ > drivers/misc/p2sb-uclass.c | 2 ++ > drivers/misc/pwrseq-uclass.c| 2 ++ > drivers/mmc/mmc-uclass.c| 2 ++ > drivers/mtd/mtd-uclass.c| 2 ++ > drivers/mtd/spi/sf-uclass.c | 2 ++ > drivers/mux/mux-uclass.c| 2 ++ > drivers/nvme/nvme-uclass.c | 2 ++ > drivers/pch/pch-uclass.c| 2 ++ > drivers/pci/pci-uclass.c| 2 ++ > drivers/pci_endpoint/pci_ep-uclass.c| 2 ++ > drivers/phy/phy-uclass.c| 2 ++ > drivers/pinctrl/pinctrl-uclass.c| 2 ++ > drivers/power/domain/power-domain-uclass.c | 2 ++ > drivers/power/pmic/pmic-uclass.c| 2 ++ > drivers/power/regulator/regulator-uclass.c | 2 ++ > drivers/pwm/pwm-uclass.c| 2 ++ > drivers/ram/ram-uclass.c| 2 ++ > drivers/remoteproc/rproc-uclass.c | 3 +++ > drivers/reset/reset-uclass.c| 2 ++ > drivers/rng/rng-uclass.c| 2 ++ > drivers/rtc/rtc-uclass.c| 2 ++ > drivers/scsi/scsi-uclass.c | 2 ++ > drivers/serial/serial-uclass.c | 2 ++ > drivers/smem/smem-uclass.c | 2 ++ > drivers/soc/soc-uclass.c| 2 ++ > drivers/sound/codec-uclass.c| 2 ++ > drivers/sound/i2s-uclass.c | 2 ++ > drivers/sound/sound-uclass.c| 2 ++ > drivers/spi/spi-emul-uclass.c | 2 ++ > drivers/spmi/spmi-uclass.c | 2 ++ > drivers/sysinfo/sysinfo-uclass.c| 2 ++ > drivers/tee/tee-uclass.c| 2 ++ > drivers/thermal/thermal-uclass.c| 2 ++ > drivers/timer/timer-uclass.c| 2 ++ > drivers/ufs/ufs-uclass.c| 2 ++ > drivers/usb/emul/usb-emul-uclass.c | 2 ++ > drivers/usb/gadget/udc/udc-uclass.c | 2 ++ > drivers/usb/host/usb-uclass.c | 2 ++ > drivers/video/backlight-uclass.c| 2 ++ > drivers/video/bridge/video-bridge-uclass.c | 2 ++ > drivers/video/display-uclass.c | 2 ++ > drivers/video/dsi-host-uclass.c | 2 ++ > drivers/video/panel-uclass.c| 2 ++ > drivers/video/vidconsole-uclass.c | 2 ++ > drivers/video/video-uclass.c| 2 ++ > drivers/video/video_osd-uclass.c| 2 ++ > drivers/virtio/virtio-uclass.c | 2 ++ > drivers/w1-eeprom/w1-eeprom-uclass.c| 2 ++ > drivers/w1/w1-uclass.c | 2 ++ > drivers/watchdog/wdt-uclass.c | 2 ++ > drivers/xen/pvblock.c | 3 +++ > 77 files changed, 157 insertions(+) > Reviewed-by: Simon Glass Applied to u-boot-dm/next, thanks!
Re: [PATCH 1/1] sandbox: ensure that state->ram_buf is in low memory
Hi Heinrich, On Sat, 15 May 2021 at 09:33, Heinrich Schuchardt wrote: > > On 5/15/21 5:19 PM, Simon Glass wrote: > > Hi Heinrich, > > > > On Fri, 14 May 2021 at 18:34, Heinrich Schuchardt > > wrote: > >> > >> Am 14. Mai 2021 22:44:32 MESZ schrieb Simon Glass : > >>> Hi Heinrich, > >>> > >>> On Fri, 14 May 2021 at 00:11, Heinrich Schuchardt > >>> wrote: > > On 5/14/21 1:56 AM, Simon Glass wrote: > > Hi Heinrich, > > > > On Thu, 13 May 2021 at 08:53, Heinrich Schuchardt > >>> wrote: > >> > >> On 5/13/21 4:36 PM, Simon Glass wrote: > >>> Hi Heinrich, > >>> > >>> On Wed, 12 May 2021 at 15:28, Heinrich Schuchardt > >>> wrote: > > Am 12. Mai 2021 18:01:17 MESZ schrieb Simon Glass > >>> : > > Hi Heinrich, > > > > On Tue, 11 May 2021 at 13:03, Heinrich Schuchardt > >>> > > wrote: > >> > >> Addresses in state->ram_buf must be in the low 4 GiB of the > >>> address > > space. > >> Otherwise we cannot correctly fill SMBIOS tables. This shows > >>> up in > > warnings > >> like: > >> > >>WARNING: SMBIOS table_address overflow 7f752735e020 > > > > This sounds like a bug in the smbios-table code. For sandbox it > >>> should > > perhaps use addresses instead of pointers. > > > > I think that code (that I unfortunately wrote) was an > >>> expeditious way > > of getting it running, but is not correct. > > The field you are filling is only 32bit wide. I wonder how that > >>> table is meant to work on systems where the lowest memory address is > >>> above 4 GiB. Such ARMv8 systems exist. > >>> > >>> map_to_sysmem() will give you a 32-bit wide address. Yes SMBIOS > >>> is > >>> legacy and designed for 4GB. > >> > >> I know map_to_sysmem(). But you wrote in lib/smbios.c:487: > >> > >> /* > >> * We must use a pointer here so things work correctly on > >>> sandbox. The > >> * user of this table is not aware of the mapping of addresses > >>> to > >> * sandbox's DRAM buffer. > >> */ > >> > >> For testing you could start a binary with command 'bootefi' or > >>> 'booti' > >> and that binary would analyze the table. So yes, your comment > >>> holds true > >> and you must not use map_to_sysmem() here. > > > > Yes, that is a good point. Perhaps I was not mad when I wrote that. > > What is using the tables on sandbox? > > The UEFI shell has a command smbiosview to display the SMBIOS table. > > With the current U-Boot sandbox it crashes. I do not know what the > >>> cause is: > > FS0:\> smbiosview > > Segmentation violation > pc = 0x7fb0df88d17e, pc_reloc = 0x7fb0cf88d17e > > UEFI image [0x7fb0df836000:0x7fb0df920c5f] pc=0x5717e > '/Shell_x64.efi' > > Here is some of the output for my laptop: > > SMBIOS Entry Point Structure: > Anchor String:_SM_ > EPS Checksum: 0xEE > Entry Point Len: 31 > Version: 3.1 > Number of Structures: 62 > Max Struct size: 145 > Table Address:0x986E9000 > Table Length: 2316 > Entry Point revision: 0x0 > SMBIOS BCD Revision: 0x31 > Inter Anchor: _DMI_ > Inter Checksum: 0x4E > Formatted Area: > : 00 00 00 00 00 *.* > > = > Query Structure, conditions are: > QueryType = Random > QueryHandle = Random > ShowType= SHOW_DETAIL > > > Enter to continue, :q to exit, :[0-3] to change mode, /? for help > $ > = > Type=18, Handle=0x0 > Dump Structure as: > Index=0,Length=0x19,Addr=0x986E9019 > : 12 17 00 00 03 02 02 00-00 00 00 00 00 00 80 00 > ** > 0010: 00 00 80 00 00 00 80 00-00 > >>> *.* > > Enter to continue, :q to exit, :[0-3] to change mode, /? for help > $Structure Type: 32-bit Memory Error Information > Format part Len : 23 > Structure Handle: 0 > 32-bit Memory Error Information - Type: OK > Memory Error - Error granularity: Unknown > Memory Error - Error Operation: Unknown > VendorSyndrome: 0x0 > MemoryArrayErrorAddress: 0x8000 > DeviceErrorAddress: 0x8000 > ErrorResolution: 0x8000 > >>> > >>> OK, I am not sure what to make of that except that it is every bit as > >>> impenetrable as I would expect from UEFI. > >> > >> This is a dump of the SMBIOS tables. Why do you refer to UEFI? > > > > How do you fit so many questions in one email? :-) > > > > I assumed smbiosview is a UEFI command because of the prompt. I have
Re: [PATCH] sandbox: Support signal handling only when requested
Hi Heinrich,
On Sun, 6 Jun 2021 at 15:35, Heinrich Schuchardt wrote:
>
> Am 6. Juni 2021 20:07:31 MESZ schrieb Sean Anderson :
> >On 6/6/21 1:57 PM, Heinrich Schuchardt wrote:
> >> On 6/6/21 7:52 PM, Sean Anderson wrote:
> >>> On 6/6/21 1:28 PM, Heinrich Schuchardt wrote:
> On 6/6/21 6:44 PM, Simon Glass wrote:
> > Hi Heinrich,
> >
> > On Mon, 22 Mar 2021 at 18:56, Simon Glass
> >wrote:
> >>
> >> Hi Heinrich,
> >>
> >> On Mon, 22 Mar 2021 at 23:02, Heinrich Schuchardt
> >> wrote:
> >>>
> >>> On 22.03.21 06:21, Simon Glass wrote:
> At present if sandbox crashes it prints a message and tries to
> exit. But
> with the recently introduced signal handler, it often seems to
> >get
> stuck
> in a loop until the stack overflows:
>
> Segmentation violation
>
> Segmentation violation
>
> Segmentation violation
>
> Segmentation violation
>
> Segmentation violation
>
> Segmentation violation
>
> Segmentation violation
> ...
> >>>
> >>> Hello Simon,
> >>>
> >>> do you have a reproducible example? I never have seen this.
> >>
> >> https://source.denx.de/u-boot/custodians/u-boot-dm/-/jobs/242433
> >>
> >> You need to run that commit with pytest though...it does not
> >happen
> >> when run directly.
> >>
> >> BTW this sems to expose some rather nasty bug in dlmalloc or how
> >it is
> >> used. I notice that as soon as the first test is run, the 'top'
> >value
> >> in dlmalloc is outside the range of the malloc pool, which seems
> >> wrong. I wonder if there is something broken with how
> >> dm_test_pre_run() and dm_test_post_run() work.
> >>
> >>>
> >>> Corrupting gd could cause an endless recursive loop, as these
> >lines
> >>> follow printing the observed string:
> >>>
> >>> printf("pc = 0x%lx, ", pc);
> >>> printf("pc_reloc =0x%lx\n\n", pc - gd->reloc_off);
> >>
> >> Yes I suspect printf() is dead.
> >>
> >>>
> >>> If we remove SA_NODEFER from the signal mask in
> >arch/sandbox/cpu/os.c,
> >>> recursion cannot occur anymore. If a segmentation violation
> >occurs
> >>> inside the handler it will be delegated to the default handler.
> >>>
> >>> Furthermore we could consider removing the signal handler at the
> >start
> >>> of os_signal_action().
> >>
> >> The issue is that if you get a segfault you really don't know if
> >you
> >> can continue and do anything else.
> >>
> >> What is the goal with the signal handler? I don't think the user
> >can
> >> do anything about it.
>
> Hello Simon,
>
> the signal handler prints out the crash location and this makes
> analyzing problems much easier. It proved valuable to me several
> >times.
> >>>
> >>> Can't you just rerun with gdb?
> >>
> >> This would require that the problem is easily reproducible which may
> >not
> >> be the case.
> >
> >Hm, perhaps you could keep track of how many times we've tried to catch
> >a signal, and bail if this is the second time around. E.g. something
> >like
> >
>
> Removing SA_NODEFER from the signal mask will let the OS kick in if an
> exception occurs in a signal handler.
>
> No counter is needed.
Yes that is correct.
However I am still going to apply this patch, since I would prefer
that the default behaviour is to exit with a signal, rather than
continue. It indicates some sort of error (except if we are running a
strange test), so it seems wrong to try to continue. It may produce
other issues and sandbox is in an unknown state.
I am happy to discuss another way / patch for doing what you need.
Regards,
Simon
[..]
Applied to u-boot-dm/next, thanks!
Re: [PATCH v3] sandbox: cros-ec: Add tests for the Chromium OS EC PWM driver
This patch adds a limited pulse-width modulator to sandbox's Chromium OS Embedded Controller emulation. The emulated PWM device supports multiple channels but can only set a duty cycle for each, as the actual EC doesn't expose any functionality or information other than that. Though the EC supports specifying the PWM channel by its type (e.g. display backlight, keyboard backlight), this is not implemented in the emulation as nothing in U-Boot uses this type specification. This emulated PWM device is then used to test the Chromium OS PWM driver in sandbox. Adding the required device node to the sandbox test device-tree unfortunately makes it the first PWM device, so this also touches some other tests to make sure they still use the sandbox PWM. Signed-off-by: Alper Nebi Yasak Reviewed-by: Simon Glass --- This depends on a small fix [1] for cros-ec-pwm which otherwise fails to build. [1] https://patchwork.ozlabs.org/project/uboot/patch/20210514134840.19380-1-alpernebiya...@gmail.com/ Changes in v3: - Add tag: "Reviewed-by: Simon Glass " - Replace instances of "Chrome OS" with "Chromium OS" in commit message - Add missing "EC" in the subject line v2: https://patchwork.ozlabs.org/project/uboot/patch/20210519153017.12544-1-alpernebiya...@gmail.com/ Changes in v2: - Try to clarify commit message v1: https://patchwork.ozlabs.org/project/uboot/patch/20210516154144.141945-1-alpernebiya...@gmail.com/ arch/sandbox/dts/test.dts | 6 +++ arch/sandbox/include/asm/test.h| 10 + configs/sandbox64_defconfig| 1 + configs/sandbox_defconfig | 1 + configs/sandbox_flattree_defconfig | 1 + configs/sandbox_noinst_defconfig | 1 + configs/sandbox_spl_defconfig | 1 + drivers/misc/cros_ec_sandbox.c | 47 +++ test/cmd/pwm.c | 32 +++- test/dm/Makefile | 1 + test/dm/cros_ec_pwm.c | 60 ++ test/dm/panel.c| 2 +- test/dm/pwm.c | 6 ++- 13 files changed, 164 insertions(+), 5 deletions(-) create mode 100644 test/dm/cros_ec_pwm.c Applied to u-boot-dm/next, thanks!
Re: [RFC] Start using guestfish for U-Boot fs tests
On Sat, Jul 03, 2021 at 05:38:07PM -0400, Tom Rini wrote:
> On Sat, Jul 03, 2021 at 05:27:44PM +0300, Alper Nebi Yasak wrote:
> >
> >
> > On 02/07/2021 23:24, Tom Rini wrote:
> > > On Fri, Jul 02, 2021 at 11:03:52PM +0300, Alper Nebi Yasak wrote:
> > >> On 02/07/2021 22:01, Tom Rini wrote:
> > >>> Hey all,
> > >>>
> > >>> I started taking a look at moving to guestfish to see if this resolves
> > >>> the latest problem I've run in to:
> > >>> https://source.denx.de/u-boot/u-boot/-/jobs/284763#L307
> > >>> which I think is due to guestmount not being done in time for the test.
> > >>
> > >> That failing test's setup uses virt-make-fs, different from what you're
> > >> changing below. I locally only see that failure for the clang build, and
> > >> it still fails after adding time.sleep(300) after its virt-make-fs
> > >> calls. I don't think it's an issue in the test setup.
> > >
> > > Ah good, I need to go catch up on that thread again, thanks for looking.
> > >
> > >>> So I started converting things to use guestfish directly:
> > >>> diff --git a/test/py/tests/test_fs/conftest.py
> > >>> b/test/py/tests/test_fs/conftest.py
> > >>> index 7325486cdb1a..e8899cfdd118 100644
> > >>> --- a/test/py/tests/test_fs/conftest.py
> > >>> +++ b/test/py/tests/test_fs/conftest.py
> > >>> @@ -265,10 +265,10 @@ def fs_obj_basic(request, u_boot_config):
> > >>> fs_ubtype = fstype_to_ubname(fs_type)
> > >>> check_ubconfig(u_boot_config, fs_ubtype)
> > >>>
> > >>> -mount_dir = u_boot_config.persistent_data_dir + '/mnt'
> > >>> +data_dir = u_boot_config.persistent_data_dir + '/data'
> > >>>
> > >>> -small_file = mount_dir + '/' + SMALL_FILE
> > >>> -big_file = mount_dir + '/' + BIG_FILE
> > >>> +small_file = data_dir + '/' + SMALL_FILE
> > >>> +big_file = data_dir + '/' + BIG_FILE
> > >>>
> > >>> try:
> > >>>
> > >>> @@ -279,26 +279,14 @@ def fs_obj_basic(request, u_boot_config):
> > >>> return
> > >>>
> > >>> try:
> > >>> -check_call('mkdir -p %s' % mount_dir, shell=True)
> > >>> +check_call('mkdir -p %s' % data_dir, shell=True)
> > >>> except CalledProcessError as err:
> > >>> pytest.skip('Preparing mount folder failed for filesystem: ' +
> > >>> fs_type + '. {}'.format(err))
> > >>> call('rm -f %s' % fs_img, shell=True)
> > >>> return
> > >>>
> > >>> try:
> > >>> -# Mount the image so we can populate it.
> > >>> -mount_fs(fs_type, fs_img, mount_dir)
> > >>> -except CalledProcessError as err:
> > >>> -pytest.skip('Mounting to folder failed for filesystem: ' +
> > >>> fs_type + '. {}'.format(err))
> > >>> -call('rmdir %s' % mount_dir, shell=True)
> > >>> -call('rm -f %s' % fs_img, shell=True)
> > >>> -return
> > >>> -
> > >>> -try:
> > >>> -# Create a subdirectory.
> > >>> -check_call('mkdir %s/SUBDIR' % mount_dir, shell=True)
> > >>> -
> > >>> -# Create big file in this image.
> > >>> +# Create big file to copy in to the image.
> > >>> # Note that we work only on the start 1MB, couple MBs in the
> > >>> 2GB range
> > >>> # and the last 1 MB of the huge 2.5GB file.
> > >>> # So, just put random values only in those areas.
> > >>> @@ -309,10 +297,14 @@ def fs_obj_basic(request, u_boot_config):
> > >>> check_call('dd if=/dev/urandom of=%s bs=1M count=1 seek=2499'
> > >>> % big_file, shell=True)
> > >>>
> > >>> -# Create a small file in this image.
> > >>> +# Create a small file to copy in to the image.
> > >>> check_call('dd if=/dev/urandom of=%s bs=1M count=1'
> > >>> % small_file, shell=True)
> > >>>
> > >>> +# Copy the files in to the image and add a subdirectory.
> > >>> +# Create a subdirectory.
> > >>> +check_call('guestfish add %s : run : mount /dev/sda / : mkdir
> > >>> /SUBDIR : copy-in %s %s /'
> > >>> +% (fs_img, big_file, small_file), shell=True)
> > >>
> > >> It could be faster to do things within guestfish as much as possible,
> > >> instead of preparing the files outside and copying them in.
> > >
> > > This is, I believe, as much as possible. You can't run arbitrary
> > > commands via guestfish, or at least I didn't see how. "dd" isn't really
> > > dd, for example.
> > >
> > >> Also it looks like python bindings are available as python3-guestfs on
> > >> Debian and Ubuntu, just not on pypi.org.
> > >
> > > I saw there's some reason why you can't pip install them, and wasn't
> > > sure it would be any faster, based on doing these commands outside of
> > > pytest first.
> > >
> > >>> # Delete the small file copies which possibly are written as
> > >>> part of a
> > >>> # previous test.
> > >>> # check_call('rm -f "%s.w"' % MB1, shell=True)
> > >>> @@ -357,13 +349,11 @@ def fs_obj_basic(request, u_boot_config):
> > >>>
> > >>> except CalledPro
Re: [PATCH v2 0/4] Allwinner H6 USB3 support
On Wed, 21 Apr 2021 12:53:42 +0200 Marek Vasut wrote: Hi, > On 4/21/21 12:43 PM, Andre Przywara wrote: > > On Sat, 17 Apr 2021 09:20:55 -0500 > > Samuel Holland wrote: > > > > Hi, > > > >> This series adds PHY and XHCI driver support for the USB3 controller > >> found in the Allwinner H6 SoC. > > > > Thanks for the update! > > > >> It has been tested and working on both > >> boards enabled in patch 4, although some users experience issues[1]. > >> > >> [1]: https://lists.denx.de/pipermail/u-boot/2021-February/440767.html > > > > So I could not reproduce those issues either, it works for me fine on my > > Pine-H64. I'd suggest we merge those patches, and check for more > > reports from more users. > > > > Bin, Marek: can you push patches 1, 2 and 3 to the USB tree, to get > > them into the current merge window, still? I would then push 4/4 > > (pending possible fixes) once the first three reached mainline. > > > > And btw: the first two patches of the original v1 series (adding the > > sunxi clocks and reset bits) have been merged into master last week > > already. > > I will pick these once I get ack from Bin. Bin, did you have a chance to have a look at those patches? I wonder if we could merge them in the MW, to expose them to a wider audience? Cheers, Andre
[PATCH] rockchip: rk3399: adjust Nanopi R4S board power layout
1. Modify the VCC VDD power layout
2. Modify Ethernet1 interface of PCIE0
Reviewed-by: Kever Yang
Signed-off-by: xiaobo
---
arch/arm/dts/rk3399-nanopi-r4s.dts | 85 ++
1 file changed, 63 insertions(+), 22 deletions(-)
diff --git a/arch/arm/dts/rk3399-nanopi-r4s.dts
b/arch/arm/dts/rk3399-nanopi-r4s.dts
index 6f2cf17bf1..ae22363072 100644
--- a/arch/arm/dts/rk3399-nanopi-r4s.dts
+++ b/arch/arm/dts/rk3399-nanopi-r4s.dts
@@ -17,19 +17,65 @@
model = "FriendlyElec NanoPi R4S";
compatible = "friendlyarm,nanopi-r4s", "rockchip,rk3399";
- aliases {
- ethernet1 = &r8169;
+ chosen {
+ stdout-path = "serial2:150n8";
+ };
+
+ vcc1v8_s3: vcc1v8-s3 {
+ compatible = "regulator-fixed";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ regulator-name = "vcc1v8_s3";
+ vin-supply = <&vcc_1v8>;
+ };
+
+ vcc3v0_sd: vcc3v0-sd {
+ compatible = "regulator-fixed";
+ enable-active-high;
+ gpio = <&gpio0 RK_PA1 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&sdmmc0_pwr_h>;
+ regulator-always-on;
+ regulator-min-microvolt = <300>;
+ regulator-max-microvolt = <300>;
+ regulator-name = "vcc3v0_sd";
+ vin-supply = <&vcc3v3_sys>;
+ };
+
+ vcc3v3_sys: vcc3v3-sys {
+ compatible = "regulator-fixed";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ regulator-name = "vcc3v3_sys";
+ };
+
+ vcc5v0_sys: vcc5v0-sys {
+ compatible = "regulator-fixed";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ regulator-name = "vcc5v0_sys";
+ vin-supply = <&vdd_5v>;
};
vdd_5v: vdd-5v {
compatible = "regulator-fixed";
- regulator-name = "vdd_5v";
regulator-always-on;
regulator-boot-on;
+ regulator-name = "vdd_5v";
};
fan: pwm-fan {
compatible = "pwm-fan";
+ /*
+* With 20KHz PWM and an EVERCOOL EC4007H12SA fan, these levels
+* work out to 0, ~1200, ~3000, and 5000RPM respectively.
+*/
cooling-levels = <0 12 18 255>;
#cooling-cells = <2>;
fan-supply = <&vdd_5v>;
@@ -73,40 +119,39 @@
status = "disabled";
};
+&i2c4 {
+ status = "disabled";
+};
+
&leds {
lan_led: led-1 {
gpios = <&gpio1 RK_PA1 GPIO_ACTIVE_HIGH>;
- label = "nanopi-r4s:green:lan";
+ label = "green:lan";
+ };
+
+ sys_led: led-sys {
+ default-state = "on";
+ gpios = <&gpio0 RK_PB5 GPIO_ACTIVE_HIGH>;
+ label = "red:sys";
};
wan_led: led-2 {
gpios = <&gpio1 RK_PA0 GPIO_ACTIVE_HIGH>;
- label = "nanopi-r4s:green:wan";
+ label = "green:wan";
};
};
&leds_gpio {
rockchip,pins =
- <0 RK_PB5 RK_FUNC_GPIO &pcfg_pull_none>,
<1 RK_PA0 RK_FUNC_GPIO &pcfg_pull_none>,
- <1 RK_PA1 RK_FUNC_GPIO &pcfg_pull_none>;
+ <1 RK_PA1 RK_FUNC_GPIO &pcfg_pull_none>,
+ <0 RK_PB5 RK_FUNC_GPIO &pcfg_pull_none>;
};
&pcie0 {
max-link-speed = <1>;
num-lanes = <1>;
vpcie3v3-supply = <&vcc3v3_sys>;
-
- pcie@0 {
- reg = <0x 0 0 0 0>;
- #address-cells = <3>;
- #size-cells = <2>;
-
- r8169: pcie@0,0 {
- reg = <0x00 0 0 0 0>;
- local-mac-address = [ 00 00 00 00 00 00 ];
- };
- };
};
&sdhci {
@@ -132,7 +177,3 @@
&usbdrd_dwc3_0 {
dr_mode = "host";
};
-
-&vcc3v3_sys {
- vin-supply = <&vcc5v0_sys>;
-};
--
2.32.0
Re: [PATCH v2 0/4] Allwinner H6 USB3 support
Hi Andre, On Mon, Jul 5, 2021 at 7:10 AM Andre Przywara wrote: > > On Wed, 21 Apr 2021 12:53:42 +0200 > Marek Vasut wrote: > > Hi, > > > On 4/21/21 12:43 PM, Andre Przywara wrote: > > > On Sat, 17 Apr 2021 09:20:55 -0500 > > > Samuel Holland wrote: > > > > > > Hi, > > > > > >> This series adds PHY and XHCI driver support for the USB3 controller > > >> found in the Allwinner H6 SoC. > > > > > > Thanks for the update! > > > > > >> It has been tested and working on both > > >> boards enabled in patch 4, although some users experience issues[1]. > > >> > > >> [1]: https://lists.denx.de/pipermail/u-boot/2021-February/440767.html > > > > > > So I could not reproduce those issues either, it works for me fine on my > > > Pine-H64. I'd suggest we merge those patches, and check for more > > > reports from more users. > > > > > > Bin, Marek: can you push patches 1, 2 and 3 to the USB tree, to get > > > them into the current merge window, still? I would then push 4/4 > > > (pending possible fixes) once the first three reached mainline. > > > > > > And btw: the first two patches of the original v1 series (adding the > > > sunxi clocks and reset bits) have been merged into master last week > > > already. > > > > I will pick these once I get ack from Bin. > > Bin, did you have a chance to have a look at those patches? I wonder if > we could merge them in the MW, to expose them to a wider audience? It looks only this patch is not applied? http://patchwork.ozlabs.org/project/uboot/patch/20210417142059.45337-3-sam...@sholland.org/ I am afraid this is too late as the release date is today. Regards, Bin
Re: [PATCH] misc: i2c_eeprom: Add atmel,24c01 to the list
Hello Marek, On 04.07.21 21:31, Marek Vasut wrote: > Linux kernel binding is using atmel,24c01 compatible string. On the > other hand there is atmel,24c01a which is not listed in the kernel. > Add compatible string without "a" suffix to be compatible with Linux > kernel binding. > > Signed-off-by: Marek Vasut > Cc: Heiko Schocher > Cc: Michal Simek > --- > drivers/misc/i2c_eeprom.c | 1 + > 1 file changed, 1 insertion(+) Reviewed-by: Heiko Schocher Hmm... may dummy remark ... if "atmel,24c01a" is not used in kernel, may we should remove it in U-Boot completly? bye, Heiko -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk 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 v2 1/9] arm: dts: imx8mp: Resync imx8mp device tree include
Hello Teresa,
On 02.07.21 13:19, Teresa Remmet wrote:
> Sync imx8mp include with kernel commit:
> d1689cd3c0f4 ("arm64: dts: imx8mp: Use the correct name for child node "snps,
> dwc3"")
>
> Signed-off-by: Teresa Remmet
> ---
> arch/arm/dts/imx8mp.dtsi | 146 +--
> 1 file changed, 141 insertions(+), 5 deletions(-)
Reviewed-by: Heiko Schocher
bye,
Heiko
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
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 v2 2/9] arm: dts: imx8mp: Add common u-boot dtsi
Hello Teresa, On 02.07.21 13:19, Teresa Remmet wrote: > Factor out the common node settings for dm-spl and dm-pre-reloc > and move them to imx8mp-u-boot.dtsi > > Signed-off-by: Teresa Remmet > --- > arch/arm/dts/imx8mp-evk-u-boot.dtsi | 39 + > .../imx8mp-phyboard-pollux-rdk-u-boot.dtsi| 39 + > arch/arm/dts/imx8mp-u-boot.dtsi | 42 +++ > 3 files changed, 46 insertions(+), 74 deletions(-) > create mode 100644 arch/arm/dts/imx8mp-u-boot.dtsi Reviewed-by: Heiko Schocher bye, Heiko -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk 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 v2 4/9] board: phytec: phycore_imx8mp: Change debug UART
Hello Teresa, On 02.07.21 13:19, Teresa Remmet wrote: > With the first redesign the debug UART had changed from > UART2 to UART1. > As the first hardware revision is considered as alpha and > will not be supported in future. The old setup will not > be preserved. > > Signed-off-by: Teresa Remmet > --- > arch/arm/dts/imx8mp-phyboard-pollux-rdk-u-boot.dtsi | 4 ++-- > board/phytec/phycore_imx8mp/spl.c | 6 +++--- > include/configs/phycore_imx8mp.h| 4 ++-- > 3 files changed, 7 insertions(+), 7 deletions(-) Your patch "[PATCH v2 3/9] arm: dts: imx8mp-phyboard-pollux: Sync dts files with kernel" changed uart2 to uart1 in arch/arm/dts/imx8mp-phyboard-pollux-rdk.dts May this part should be done also in this patch? Beside of this: Reviewed-by: Heiko Schocher bye, Heiko -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk 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 v2 5/9] board: phytec: phycore_imx8mp: Add fec support
Hello Teresa, On 02.07.21 13:19, Teresa Remmet wrote: > Enable support for the fec ethernet on phyCORE-i.MX8MP. > > Signed-off-by: Teresa Remmet > --- > board/phytec/phycore_imx8mp/phycore-imx8mp.c | 14 ++ > configs/phycore-imx8mp_defconfig | 7 +++ > include/configs/phycore_imx8mp.h | 17 + > 3 files changed, 38 insertions(+) Reviewed-by: Heiko Schocher bye, Heiko -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk 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 v2 3/9] arm: dts: imx8mp-phyboard-pollux: Sync dts files with kernel
Hello Teresa,
On 02.07.21 13:19, Teresa Remmet wrote:
> This update includes eqos support and debug uart changes.
>
> Synced with kernel commit
> 846f752866bd ("arm64: dts: imx8mp-phyboard-pollux-rdk: Change debug UART")
>
> Signed-off-by: Teresa Remmet
> ---
> arch/arm/dts/imx8mp-phyboard-pollux-rdk.dts | 58 ++---
> arch/arm/dts/imx8mp-phycore-som.dtsi| 2 +-
> 2 files changed, 52 insertions(+), 8 deletions(-)
Reviewed-by: Heiko Schocher
bye,
Heiko
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
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: [RFC PATCH 03/28] cli: lil: Replace strclone with strdup
On 4 Jul 2021, at 5:26 am, Wolfgang Denk wrote: > > Dear Sean, > > In message you wrote: >> >> Well, since Hush was never updated, I don't believe LIL will be either. > > Let's please be exact here: Hus has never been updated _in_U-Boot_, > but it has seen a lot of changes upstream, which apparently fix all > the issues that motivated you to look for a replacement. > >> I think reducing the amount of ifdefs makes the code substantially >> easier to maintain. My intention is to just use LIL as a starting point >> which can be modified as needed to better suit U-Boot. >> >> The other half of this is that LIL is not particularly actively >> developed. I believe the author sees his work as essentially >> feature-complete, so I expect no major features which we might like to >> backport. > > This sounds like an advantage, indeed, but then you can also > interpret this as betting on a dead horse... My 2c on this. I am the maintainer of JimTcl (and I agree it is too big to be considered a candidate). LIL source code has almost zero comments, poor error checking and no test suite. I would be very hesitant to adopt it in u-boot without serious work. I would much rather see effort put into updating hush to upstream. My guess is that Denys would be amenable to small changes to make it easier to synchronise with busybox in the future. Cheers, Steve
Re: [PATCH v2 9/9] board: phytec: imx8mp-phycore: Switch to binman
Hello Teresa, On 02.07.21 13:19, Teresa Remmet wrote: > Use now binman for image creation. > > Signed-off-by: Teresa Remmet > --- > .../imx8mp-phyboard-pollux-rdk-u-boot.dtsi| 105 ++ > arch/arm/mach-imx/imx8m/Kconfig | 1 + > .../phytec/phycore_imx8mp/imximage-8mp-sd.cfg | 10 ++ > configs/phycore-imx8mp_defconfig | 4 +- > 4 files changed, 118 insertions(+), 2 deletions(-) > create mode 100644 board/phytec/phycore_imx8mp/imximage-8mp-sd.cfg Reviewed-by: Heiko Schocher bye, Heiko -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk 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 v2 9/9] board: phytec: imx8mp-phycore: Switch to binman
On Fri, Jul 2, 2021 at 4:49 PM Teresa Remmet wrote:
>
> Use now binman for image creation.
>
> Signed-off-by: Teresa Remmet
> ---
> .../imx8mp-phyboard-pollux-rdk-u-boot.dtsi| 105 ++
> arch/arm/mach-imx/imx8m/Kconfig | 1 +
> .../phytec/phycore_imx8mp/imximage-8mp-sd.cfg | 10 ++
> configs/phycore-imx8mp_defconfig | 4 +-
> 4 files changed, 118 insertions(+), 2 deletions(-)
> create mode 100644 board/phytec/phycore_imx8mp/imximage-8mp-sd.cfg
>
> diff --git a/arch/arm/dts/imx8mp-phyboard-pollux-rdk-u-boot.dtsi
> b/arch/arm/dts/imx8mp-phyboard-pollux-rdk-u-boot.dtsi
> index dbc48dfb4841..2b8e77cb27c5 100644
> --- a/arch/arm/dts/imx8mp-phyboard-pollux-rdk-u-boot.dtsi
> +++ b/arch/arm/dts/imx8mp-phyboard-pollux-rdk-u-boot.dtsi
> @@ -7,6 +7,10 @@
> #include "imx8mp-u-boot.dtsi"
>
> / {
> + binman: binman {
> + multiple-images;
> + };
> +
> wdt-reboot {
> compatible = "wdt-reboot";
> wdt = <&wdog1>;
> @@ -81,3 +85,104 @@
> &wdog1 {
> u-boot,dm-spl;
> };
> +
> +&binman {
> +u-boot-spl-ddr {
> + filename = "u-boot-spl-ddr.bin";
> + pad-byte = <0xff>;
> + align-size = <4>;
> + align = <4>;
> +
> + u-boot-spl {
> + align-end = <4>;
> + };
> +
> + blob_1: blob-ext@1 {
> + filename = "lpddr4_pmu_train_1d_imem_202006.bin";
> + size = <0x8000>;
> + };
> +
> + blob_2: blob-ext@2 {
> + filename = "lpddr4_pmu_train_1d_dmem_202006.bin";
> + size = <0x4000>;
> + };
> +
> + blob_3: blob-ext@3 {
> + filename = "lpddr4_pmu_train_2d_imem_202006.bin";
> + size = <0x8000>;
> + };
> +
> + blob_4: blob-ext@4 {
> + filename = "lpddr4_pmu_train_2d_dmem_202006.bin";
> + size = <0x4000>;
> + };
> + };
> +
> + flash {
> + mkimage {
> + args = "-n spl/u-boot-spl.cfgout -T imx8mimage -e
> 0x92";
> +
> + blob {
> + filename = "u-boot-spl-ddr.bin";
> + };
> + };
> + };
> +
> + itb {
> + filename = "u-boot.itb";
> +
> + fit {
> + description = "Configuration to load ATF before
> U-Boot";
> + #address-cells = <1>;
> + fit,external-offset = ;
> +
> + images {
> + uboot {
> + description = "U-Boot (64-bit)";
> + type = "standalone";
> + arch = "arm64";
> + compression = "none";
> + load = ;
> +
> + uboot_blob: blob-ext {
> + filename = "u-boot-nodtb.bin";
> + };
> + };
> +
> + atf {
> + description = "ARM Trusted Firmware";
> + type = "firmware";
> + arch = "arm64";
> + compression = "none";
> + load = <0x97>;
> + entry = <0x97>;
> +
> + atf_blob: blob-ext {
> + filename = "bl31.bin";
> + };
> + };
> +
> + fdt {
> + description = "NAME";
> + type = "flat_dt";
> + compression = "none";
> +
> + uboot_fdt_blob: blob-ext {
> + filename = "u-boot.dtb";
> + };
> + };
> + };
> +
> + configurations {
> + default = "conf";
> +
> + conf {
> + description = "NAME";
> + firmware = "uboot";
> + loadables = "atf";
> + fdt = "fdt";
> + };
> + };
> + };
> + };
> +};
I think this wi
Re: Pull request for efi-2021-07-rc5-2
>
[...]
> commit 44ffb6f0ecaf ("smbios: Allow properties to come from the device
> tree") still used CONFIG symbols.
>
> commit e4f8e543f1a9 ("smbios: Drop the unused Kconfig options") dropped
> the CONFIG symbols
Exactly, that was the point I tried to make. I think whatever Da was seing
on his entires as 'correct' was prior to e4f8e543f1a9.
Cheers
/Ilias
>
> Best regards
>
> Heinrich
>
> > The only thing my patch did was fix e4f8e543f1a9 which removed some Kconfig
> > options. Removing those made the strings "" which is against the spec.
> > Heinrich fixed a similar issue with 00a871d34e2f back when we had
> > CONFIG_SMBIOS_MANUFACTURER and CONFIG_SMBIOS_PRODUCT_NAME. Any chance that
> > was your working version and those values were used?
> >
> > >
> > > Having file smbios.dtsi in an x86 specific path (arch/x86/dts/) does not
> > > make much sense. There is nothing architecture specific in it.
> > >
> > > Maybe where Ilias now has filled the missing properties with 'Unknown'
> > > he should have opted for CONFIG_SYS* instead if available. This would
> > > make smbios.dtsi superfluous.
> >
> > We discussed this with Simon and I'll send a follow up patch. The idea is to
> > try and use CONFIG_SYS* and if those are not available, pop a warning and
> > use
> > Unknown
> >
> > Cheers
> > /Ilias
> > >
> > > Best regards
> > >
> > > Heinrich
>
Re: [PATCH] MAINTAINERS, git-mailrc: socfpga: Change co-maintainer to Tien Fong Chee
On Fri, Jul 2, 2021 at 1:40 AM Sean Anderson wrote: > > > > On 7/1/21 12:01 PM, Ley Foon Tan wrote: > > I'm no longer work in Intel, change Intel SoCFPGA co-maintainer to > > Tien Fong Chee. > > > > Signed-off-by: Ley Foon Tan > > --- > > MAINTAINERS| 2 +- > > doc/git-mailrc | 3 ++- > > 2 files changed, 3 insertions(+), 2 deletions(-) > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > index 86ff5e04a6..4997ac97a8 100644 > > --- a/MAINTAINERS > > +++ b/MAINTAINERS > > @@ -118,7 +118,7 @@ F:cmd/arm/ > > ARM ALTERA SOCFPGA > > M: Marek Vasut > > M: Simon Goldschmidt > > -M: Ley Foon Tan > > +M: Tien Fong Chee > > S: Maintainted > > Can you fix this typo while you're at it? > Okay. Regards Ley Foon
