Re: Fastboot

[Jonas Vautherin]

Finally made it work!

I was editing the wrong file: am335x-evm.dts instead of
am335x-pocketbeagle.dts. Because in the defconfig, "am335x-evm" was defined
as the "default", I thought it would boot there. But there is apparently a
mechanism that makes it choose am335x-pocketbeagle.dts instead. I applied
the following patch and it just worked:

```
diff --git a/arch/arm/dts/am335x-pocketbeagle.dts
b/arch/arm/dts/am335x-pocketbeagle.dts
index 62fe5cab9f..3ba1c9c950 100644
--- a/arch/arm/dts/am335x-pocketbeagle.dts
+++ b/arch/arm/dts/am335x-pocketbeagle.dts
@@ -220,7 +220,7 @@

  {
  status = "okay";
- dr_mode = "otg";
+ dr_mode = "peripheral";
 };

 _phy {
```

I struggled with it, but that was a learning experience. Thanks a lot for
the help!

On Thu, Mar 11, 2021 at 1:56 AM Jonas Vautherin 
wrote:

> Thanks a lot, Sean!
>
> From you answer, it seems like what I am trying to do (i.e. applying that
> patch to am335x.dts to set dr_mode to "peripheral") makes sense, though for
> some reason it does not get applied.
>
> I have been careful in checking that the dts file disappears after I
> cleansstate u-boot, and that it gets patched in the do_patch step. I have
> also checked that u-boot.img disappears from the deploy folder when I
> cleansstate, and gets rebuilt after the patch is applied. And finally, I
> have made sure that the cleansstate on my image removed it from the deploy
> folder.
>
> Moreover, I have `find build | grep am335x.dts` to check if I was patching
> the right file (which should be ensured by the fact that I patch it in the
> bbappend of the u-boot recipe).
>
> My fear is that for some reason, it does not use am335x.dts to build the
> device tree but something else entirely, which would mean that I am
> patching something that is not used.
>
> From u-boot.img, or ideally even from my final image I flash on the
> sdcard, is there a way for me to see what is used to define the device tree?
>
> Best,
>
> On Thu, 11 Mar 2021, 00:44 Sean Anderson,  wrote:
>
>> On 3/10/21 12:43 PM, Jonas Vautherin wrote:
>> > Hello!
>> >
>> > I've made some more tests, but I am stuck and I don't really know what
>> > I am missing. Would love to get some insights, if somebody has an idea
>> > :-). So my root problem is that I would like to run my pocketbeagle in
>> > fastboot mode so that I can flash an image from my laptop over USB
>> > (it's a learning experience, I'm new to u-boot).
>> >
>> > When I go into the u-boot prompt and run `fastboot usb 0` (after I set
>> > `log level 7`), I get:
>> >
>> > ```
>> > => fastboot usb 0
>> > uclass_find_device_by_seq() 0 0
>> > uclass_find_device_by_seq()- not found
>> > uclass_find_device_by_seq() 1 0
>> > uclass_find_device_by_seq()- not found
>> > cmd_call() Command failed, result=1
>> > ```
>> >
>> > Similar for `fastboot usb 1` (I don't know which one is the microB on
>> > the pocketbeagle), except the numbers are `0 1` and `1 1` in the log
>> > output.
>>
>> The numbers come from /aliases in the device tree. You should read the
>> datasheet/schematic to figure out which is which :)
>>
>> >
>> > If I `dm tree`, for some reason I see only usb1@47401800 (according to
>> > the `.dts`, usb0 is @47401000).
>> >
>> > ```
>> >   misc  0  [ + ]   ti-musb-wrapper   `-- usb@4740
>> >   usb   0  [   ]   ti-musb-host  `--
>> usb@47401800
>> > ```
>> >
>> > Looking at the defconfig (I use Yocto, so `bitbake -c menuconfig
>> > u-boot), I see that "Default Device Tree for DT control" is
>> > (am335x-evm). Opening
>> >
>> ./build/tmp/work/pocketbeagle-poky-linux-gnueabi/u-boot/1_2020.07-r0/git/arch/arm/dts/am335x-evm.dts
>> > (which I believe is the one corresponding to `am335x-evm` in my
>> > defconfig), I see the following for usb:
>> >
>> > ```
>> >  {
>> > status = "okay";
>> > };
>> >
>> > _ctrl_mod {
>> > status = "okay";
>> > };
>> >
>> > _phy {
>> > status = "okay";
>> > };
>> >
>> > _phy {
>> > status = "okay";
>> > };
>> >
>> >  {
>> > status = "okay";
>> > };
>> >
>> >  {
>> > status = "okay";
>> > dr_mode = "host";
>> > };
>> > ```
>> >
>> > And showing usb0 and usb1 with `fdt print` (after I get the value of
>> > $fdt_blob with `bdinfo` and use it with `fdt addr $fdt_blob`), I get:
>> >
>> > ```
>> > => fdt print /ocp/usb@4740/usb@47401000
>> > usb@47401000 {
>> >  compatible = "ti,musb-am33xx";
>> >  status = "okay";
>> >  reg = <0x47401400 0x0400 0x47401000 0x0200>;
>> >  reg-names = "mc", "control";
>> >  interrupts = <0x0012>;
>> >  interrupt-names = "mc";
>> >  dr_mode = "otg";
>> >  mentor,multipoint = <0x0001>;
>> >  mentor,num-eps = <0x0010>;
>> >  mentor,ram-bits = <0x000c>;
>> >  mentor,power = <0x01f4>;
>> >  phys = <0x0037>;
>> >  dmas = * 0x9df20aa8 [0x0168];
>> >  dma-names = "rx1", "rx2", "rx3", "rx4", "rx5", "rx6", "rx7",
>> "rx8", "rx
>> > 9", "rx10", 

Re: [PATCH v5 00/41] test: Refactor tests to have a single test runner

[Tom Rini]

On Sun, Mar 07, 2021 at 05:34:36PM -0700, Simon Glass wrote:

> At present U-Boot has two broad sets of tests in the C code: driver model
> tests which do a lot of pre-/post-init and command tests which do not.
> 
> This separation makes it slightly harder to write a test, since there are
> two different test-state structures and different rules for running the
> two different test types. At present these rules are determined by where
> the test is (actually its prefix).
> 
> All unit tests can be run from the command line with the 'ut' command.
> Since SPL does not have commands, it currently calls the test runner
> directly and offers no control of which tests are run.
> 
> This seems like a good time to refactor the tests into a unified test
> runner, allowing U-Boot proper and SPL to use the same path, perhaps with
> some different conditions along the way.
> 
> This series sets up a unified runner called ut_run_list(), which runs a
> set of tests from a linker_list. Driver model tests are distinguished by
> a new UT_TESTF_DM flag so that the necessary init and cleanup can still
> be done.
> 
> The runner is modified to support running SPL tests that are not solely
> for driver model. An example test for FIT loading is added as a
> demonstration.
> 
> In addition, some documentation is added to explain how to write tests.

For the series, applied to u-boot/next, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH u-boot v2.1 38/38] ARM: enable LTO for some boards

[Tom Rini]

On Fri, Mar 12, 2021 at 06:36:05PM +0100, Marek Behun wrote:
> On Fri, 12 Mar 2021 18:19:08 +0100
> Heinrich Schuchardt  wrote:
> 
> > On 12.03.21 18:03, Marek Behun wrote:
> > > On Fri, 12 Mar 2021 08:34:41 -0800
> > > Tim Harvey  wrote:
> > >  
> > >> On Fri, Mar 12, 2021 at 5:47 AM Marek Behún  wrote:  
> > >>>
> > >>> Enable LTO for some boards that were tested by people on U-Boot Mailing
> > >>> List.
> > >>>
> > >>> Signed-off-by: Marek Behún 
> > >>> Tested-by: Adam Ford 
> > >>> Tested-by: Pali Rohár 
> > >>> Tested-by: Tim Harvey 
> > >>> ---
> > >>>  configs/am3517_evm_defconfig  | 1 +
> > >>>  configs/da850evm_defconfig| 1 +
> > >>>  configs/da850evm_direct_nor_defconfig | 1 +
> > >>>  configs/da850evm_nand_defconfig   | 1 +
> > >>>  configs/imx6q_logic_defconfig | 1 +
> > >>>  configs/imx8mm_beacon_defconfig   | 1 +
> > >>>  configs/imx8mm_venice_defconfig   | 1 +
> > >>>  configs/imx8mn_beacon_2g_defconfig| 1 +
> > >>>  configs/imx8mn_beacon_defconfig   | 1 +
> > >>>  configs/nokia_rx51_defconfig  | 1 +
> > >>>  configs/omap3_logic_defconfig | 1 +
> > >>>  configs/r8a774a1_beacon_defconfig | 1 +
> > >>>  configs/r8a774b1_beacon_defconfig | 1 +
> > >>>  configs/r8a774e1_beacon_defconfig | 1 +
> > >>>  configs/turris_mox_defconfig  | 1 +
> > >>>  configs/turris_omnia_defconfig| 1 +
> > >>>  16 files changed, 16 insertions(+)
> > >>>
> > >>> diff --git a/configs/am3517_evm_defconfig b/configs/am3517_evm_defconfig
> > >>> index bae0e0af35..d61eec94a4 100644
> > >>> --- a/configs/am3517_evm_defconfig
> > >>> +++ b/configs/am3517_evm_defconfig
> > >>> @@ -1,3 +1,4 @@
> > >>> +CONFIG_LTO=y
> > >>>  CONFIG_ARM=y
> > >>>  # CONFIG_SPL_USE_ARCH_MEMCPY is not set
> > >>>  # CONFIG_SPL_USE_ARCH_MEMSET is not set
> > >>> diff --git a/configs/da850evm_defconfig b/configs/da850evm_defconfig
> > >>> index 26e76a2929..6ff5e21bc6 100644
> > >>> --- a/configs/da850evm_defconfig
> > >>> +++ b/configs/da850evm_defconfig
> > >>> @@ -1,3 +1,4 @@
> > >>> +CONFIG_LTO=y
> > >>>  CONFIG_ARM=y
> > >>>  CONFIG_SYS_THUMB_BUILD=y
> > >>>  CONFIG_ARCH_DAVINCI=y
> > >>> diff --git a/configs/da850evm_direct_nor_defconfig 
> > >>> b/configs/da850evm_direct_nor_defconfig
> > >>> index d3860a963d..06c7ce7c47 100644
> > >>> --- a/configs/da850evm_direct_nor_defconfig
> > >>> +++ b/configs/da850evm_direct_nor_defconfig
> > >>> @@ -1,3 +1,4 @@
> > >>> +CONFIG_LTO=y
> > >>>  CONFIG_ARM=y
> > >>>  CONFIG_ARCH_CPU_INIT=y
> > >>>  CONFIG_ARCH_DAVINCI=y
> > >>> diff --git a/configs/da850evm_nand_defconfig 
> > >>> b/configs/da850evm_nand_defconfig
> > >>> index 0d0e9a148d..be737564e1 100644
> > >>> --- a/configs/da850evm_nand_defconfig
> > >>> +++ b/configs/da850evm_nand_defconfig
> > >>> @@ -1,3 +1,4 @@
> > >>> +CONFIG_LTO=y
> > >>>  CONFIG_ARM=y
> > >>>  CONFIG_SYS_THUMB_BUILD=y
> > >>>  CONFIG_ARCH_DAVINCI=y
> > >>> diff --git a/configs/imx6q_logic_defconfig 
> > >>> b/configs/imx6q_logic_defconfig
> > >>> index 36dc24d080..0f8aea6983 100644
> > >>> --- a/configs/imx6q_logic_defconfig
> > >>> +++ b/configs/imx6q_logic_defconfig
> > >>> @@ -1,3 +1,4 @@
> > >>> +CONFIG_LTO=y
> > >>>  CONFIG_ARM=y
> > >>>  CONFIG_ARCH_MX6=y
> > >>>  CONFIG_SYS_TEXT_BASE=0x1780
> > >>> diff --git a/configs/imx8mm_beacon_defconfig 
> > >>> b/configs/imx8mm_beacon_defconfig
> > >>> index 045b19f4f3..e8bb44eea6 100644
> > >>> --- a/configs/imx8mm_beacon_defconfig
> > >>> +++ b/configs/imx8mm_beacon_defconfig
> > >>> @@ -1,3 +1,4 @@
> > >>> +CONFIG_LTO=y
> > >>>  CONFIG_ARM=y
> > >>>  CONFIG_ARCH_IMX8M=y
> > >>>  CONFIG_SYS_TEXT_BASE=0x4020
> > >>> diff --git a/configs/imx8mm_venice_defconfig 
> > >>> b/configs/imx8mm_venice_defconfig
> > >>> index a15c3641f6..dff8f64540 100644
> > >>> --- a/configs/imx8mm_venice_defconfig
> > >>> +++ b/configs/imx8mm_venice_defconfig
> > >>> @@ -1,3 +1,4 @@
> > >>> +CONFIG_LTO=y
> > >>>  CONFIG_ARM=y
> > >>>  CONFIG_ARCH_IMX8M=y
> > >>>  CONFIG_SYS_TEXT_BASE=0x4020
> > >>> diff --git a/configs/imx8mn_beacon_2g_defconfig 
> > >>> b/configs/imx8mn_beacon_2g_defconfig
> > >>> index 58b8e49486..1c8cbc2c89 100644
> > >>> --- a/configs/imx8mn_beacon_2g_defconfig
> > >>> +++ b/configs/imx8mn_beacon_2g_defconfig
> > >>> @@ -1,3 +1,4 @@
> > >>> +CONFIG_LTO=y
> > >>>  CONFIG_ARM=y
> > >>>  CONFIG_ARCH_IMX8M=y
> > >>>  CONFIG_SYS_TEXT_BASE=0x4020
> > >>> diff --git a/configs/imx8mn_beacon_defconfig 
> > >>> b/configs/imx8mn_beacon_defconfig
> > >>> index d6a3385d8d..6457b9409a 100644
> > >>> --- a/configs/imx8mn_beacon_defconfig
> > >>> +++ b/configs/imx8mn_beacon_defconfig
> > >>> @@ -1,3 +1,4 @@
> > >>> +CONFIG_LTO=y
> > >>>  CONFIG_ARM=y
> > >>>  CONFIG_ARCH_IMX8M=y
> > >>>  CONFIG_SYS_TEXT_BASE=0x4020
> > >>> diff --git a/configs/nokia_rx51_defconfig b/configs/nokia_rx51_defconfig
> > >>> index 312ca3a1a9..85ca627790 100644
> > >>> --- a/configs/nokia_rx51_defconfig
> > >>> +++ b/configs/nokia_rx51_defconfig
> > >>> @@ 

Re: [PATCH u-boot v2.1 38/38] ARM: enable LTO for some boards

[Tim Harvey]

On Fri, Mar 12, 2021 at 9:36 AM Marek Behun  wrote:
>
> On Fri, 12 Mar 2021 18:19:08 +0100
> Heinrich Schuchardt  wrote:
>
> > On 12.03.21 18:03, Marek Behun wrote:
> > > On Fri, 12 Mar 2021 08:34:41 -0800
> > > Tim Harvey  wrote:
> > >
> > >> On Fri, Mar 12, 2021 at 5:47 AM Marek Behún  wrote:
> > >>>
> > >>> Enable LTO for some boards that were tested by people on U-Boot Mailing
> > >>> List.
> > >>>
> > >>> Signed-off-by: Marek Behún 
> > >>> Tested-by: Adam Ford 
> > >>> Tested-by: Pali Rohár 
> > >>> Tested-by: Tim Harvey 
> > >>> ---
> > >>>  configs/am3517_evm_defconfig  | 1 +
> > >>>  configs/da850evm_defconfig| 1 +
> > >>>  configs/da850evm_direct_nor_defconfig | 1 +
> > >>>  configs/da850evm_nand_defconfig   | 1 +
> > >>>  configs/imx6q_logic_defconfig | 1 +
> > >>>  configs/imx8mm_beacon_defconfig   | 1 +
> > >>>  configs/imx8mm_venice_defconfig   | 1 +
> > >>>  configs/imx8mn_beacon_2g_defconfig| 1 +
> > >>>  configs/imx8mn_beacon_defconfig   | 1 +
> > >>>  configs/nokia_rx51_defconfig  | 1 +
> > >>>  configs/omap3_logic_defconfig | 1 +
> > >>>  configs/r8a774a1_beacon_defconfig | 1 +
> > >>>  configs/r8a774b1_beacon_defconfig | 1 +
> > >>>  configs/r8a774e1_beacon_defconfig | 1 +
> > >>>  configs/turris_mox_defconfig  | 1 +
> > >>>  configs/turris_omnia_defconfig| 1 +
> > >>>  16 files changed, 16 insertions(+)
> > >>>
> > >>> diff --git a/configs/am3517_evm_defconfig b/configs/am3517_evm_defconfig
> > >>> index bae0e0af35..d61eec94a4 100644
> > >>> --- a/configs/am3517_evm_defconfig
> > >>> +++ b/configs/am3517_evm_defconfig
> > >>> @@ -1,3 +1,4 @@
> > >>> +CONFIG_LTO=y
> > >>>  CONFIG_ARM=y
> > >>>  # CONFIG_SPL_USE_ARCH_MEMCPY is not set
> > >>>  # CONFIG_SPL_USE_ARCH_MEMSET is not set
> > >>> diff --git a/configs/da850evm_defconfig b/configs/da850evm_defconfig
> > >>> index 26e76a2929..6ff5e21bc6 100644
> > >>> --- a/configs/da850evm_defconfig
> > >>> +++ b/configs/da850evm_defconfig
> > >>> @@ -1,3 +1,4 @@
> > >>> +CONFIG_LTO=y
> > >>>  CONFIG_ARM=y
> > >>>  CONFIG_SYS_THUMB_BUILD=y
> > >>>  CONFIG_ARCH_DAVINCI=y
> > >>> diff --git a/configs/da850evm_direct_nor_defconfig 
> > >>> b/configs/da850evm_direct_nor_defconfig
> > >>> index d3860a963d..06c7ce7c47 100644
> > >>> --- a/configs/da850evm_direct_nor_defconfig
> > >>> +++ b/configs/da850evm_direct_nor_defconfig
> > >>> @@ -1,3 +1,4 @@
> > >>> +CONFIG_LTO=y
> > >>>  CONFIG_ARM=y
> > >>>  CONFIG_ARCH_CPU_INIT=y
> > >>>  CONFIG_ARCH_DAVINCI=y
> > >>> diff --git a/configs/da850evm_nand_defconfig 
> > >>> b/configs/da850evm_nand_defconfig
> > >>> index 0d0e9a148d..be737564e1 100644
> > >>> --- a/configs/da850evm_nand_defconfig
> > >>> +++ b/configs/da850evm_nand_defconfig
> > >>> @@ -1,3 +1,4 @@
> > >>> +CONFIG_LTO=y
> > >>>  CONFIG_ARM=y
> > >>>  CONFIG_SYS_THUMB_BUILD=y
> > >>>  CONFIG_ARCH_DAVINCI=y
> > >>> diff --git a/configs/imx6q_logic_defconfig 
> > >>> b/configs/imx6q_logic_defconfig
> > >>> index 36dc24d080..0f8aea6983 100644
> > >>> --- a/configs/imx6q_logic_defconfig
> > >>> +++ b/configs/imx6q_logic_defconfig
> > >>> @@ -1,3 +1,4 @@
> > >>> +CONFIG_LTO=y
> > >>>  CONFIG_ARM=y
> > >>>  CONFIG_ARCH_MX6=y
> > >>>  CONFIG_SYS_TEXT_BASE=0x1780
> > >>> diff --git a/configs/imx8mm_beacon_defconfig 
> > >>> b/configs/imx8mm_beacon_defconfig
> > >>> index 045b19f4f3..e8bb44eea6 100644
> > >>> --- a/configs/imx8mm_beacon_defconfig
> > >>> +++ b/configs/imx8mm_beacon_defconfig
> > >>> @@ -1,3 +1,4 @@
> > >>> +CONFIG_LTO=y
> > >>>  CONFIG_ARM=y
> > >>>  CONFIG_ARCH_IMX8M=y
> > >>>  CONFIG_SYS_TEXT_BASE=0x4020
> > >>> diff --git a/configs/imx8mm_venice_defconfig 
> > >>> b/configs/imx8mm_venice_defconfig
> > >>> index a15c3641f6..dff8f64540 100644
> > >>> --- a/configs/imx8mm_venice_defconfig
> > >>> +++ b/configs/imx8mm_venice_defconfig
> > >>> @@ -1,3 +1,4 @@
> > >>> +CONFIG_LTO=y
> > >>>  CONFIG_ARM=y
> > >>>  CONFIG_ARCH_IMX8M=y
> > >>>  CONFIG_SYS_TEXT_BASE=0x4020
> > >>> diff --git a/configs/imx8mn_beacon_2g_defconfig 
> > >>> b/configs/imx8mn_beacon_2g_defconfig
> > >>> index 58b8e49486..1c8cbc2c89 100644
> > >>> --- a/configs/imx8mn_beacon_2g_defconfig
> > >>> +++ b/configs/imx8mn_beacon_2g_defconfig
> > >>> @@ -1,3 +1,4 @@
> > >>> +CONFIG_LTO=y
> > >>>  CONFIG_ARM=y
> > >>>  CONFIG_ARCH_IMX8M=y
> > >>>  CONFIG_SYS_TEXT_BASE=0x4020
> > >>> diff --git a/configs/imx8mn_beacon_defconfig 
> > >>> b/configs/imx8mn_beacon_defconfig
> > >>> index d6a3385d8d..6457b9409a 100644
> > >>> --- a/configs/imx8mn_beacon_defconfig
> > >>> +++ b/configs/imx8mn_beacon_defconfig
> > >>> @@ -1,3 +1,4 @@
> > >>> +CONFIG_LTO=y
> > >>>  CONFIG_ARM=y
> > >>>  CONFIG_ARCH_IMX8M=y
> > >>>  CONFIG_SYS_TEXT_BASE=0x4020
> > >>> diff --git a/configs/nokia_rx51_defconfig b/configs/nokia_rx51_defconfig
> > >>> index 312ca3a1a9..85ca627790 100644
> > >>> --- a/configs/nokia_rx51_defconfig
> > >>> +++ b/configs/nokia_rx51_defconfig
> > >>> @@ -1,3 +1,4 @@

Re: [PATCH u-boot v2.1 38/38] ARM: enable LTO for some boards

[Marek Behun]

On Fri, 12 Mar 2021 18:19:08 +0100
Heinrich Schuchardt  wrote:

> On 12.03.21 18:03, Marek Behun wrote:
> > On Fri, 12 Mar 2021 08:34:41 -0800
> > Tim Harvey  wrote:
> >  
> >> On Fri, Mar 12, 2021 at 5:47 AM Marek Behún  wrote:  
> >>>
> >>> Enable LTO for some boards that were tested by people on U-Boot Mailing
> >>> List.
> >>>
> >>> Signed-off-by: Marek Behún 
> >>> Tested-by: Adam Ford 
> >>> Tested-by: Pali Rohár 
> >>> Tested-by: Tim Harvey 
> >>> ---
> >>>  configs/am3517_evm_defconfig  | 1 +
> >>>  configs/da850evm_defconfig| 1 +
> >>>  configs/da850evm_direct_nor_defconfig | 1 +
> >>>  configs/da850evm_nand_defconfig   | 1 +
> >>>  configs/imx6q_logic_defconfig | 1 +
> >>>  configs/imx8mm_beacon_defconfig   | 1 +
> >>>  configs/imx8mm_venice_defconfig   | 1 +
> >>>  configs/imx8mn_beacon_2g_defconfig| 1 +
> >>>  configs/imx8mn_beacon_defconfig   | 1 +
> >>>  configs/nokia_rx51_defconfig  | 1 +
> >>>  configs/omap3_logic_defconfig | 1 +
> >>>  configs/r8a774a1_beacon_defconfig | 1 +
> >>>  configs/r8a774b1_beacon_defconfig | 1 +
> >>>  configs/r8a774e1_beacon_defconfig | 1 +
> >>>  configs/turris_mox_defconfig  | 1 +
> >>>  configs/turris_omnia_defconfig| 1 +
> >>>  16 files changed, 16 insertions(+)
> >>>
> >>> diff --git a/configs/am3517_evm_defconfig b/configs/am3517_evm_defconfig
> >>> index bae0e0af35..d61eec94a4 100644
> >>> --- a/configs/am3517_evm_defconfig
> >>> +++ b/configs/am3517_evm_defconfig
> >>> @@ -1,3 +1,4 @@
> >>> +CONFIG_LTO=y
> >>>  CONFIG_ARM=y
> >>>  # CONFIG_SPL_USE_ARCH_MEMCPY is not set
> >>>  # CONFIG_SPL_USE_ARCH_MEMSET is not set
> >>> diff --git a/configs/da850evm_defconfig b/configs/da850evm_defconfig
> >>> index 26e76a2929..6ff5e21bc6 100644
> >>> --- a/configs/da850evm_defconfig
> >>> +++ b/configs/da850evm_defconfig
> >>> @@ -1,3 +1,4 @@
> >>> +CONFIG_LTO=y
> >>>  CONFIG_ARM=y
> >>>  CONFIG_SYS_THUMB_BUILD=y
> >>>  CONFIG_ARCH_DAVINCI=y
> >>> diff --git a/configs/da850evm_direct_nor_defconfig 
> >>> b/configs/da850evm_direct_nor_defconfig
> >>> index d3860a963d..06c7ce7c47 100644
> >>> --- a/configs/da850evm_direct_nor_defconfig
> >>> +++ b/configs/da850evm_direct_nor_defconfig
> >>> @@ -1,3 +1,4 @@
> >>> +CONFIG_LTO=y
> >>>  CONFIG_ARM=y
> >>>  CONFIG_ARCH_CPU_INIT=y
> >>>  CONFIG_ARCH_DAVINCI=y
> >>> diff --git a/configs/da850evm_nand_defconfig 
> >>> b/configs/da850evm_nand_defconfig
> >>> index 0d0e9a148d..be737564e1 100644
> >>> --- a/configs/da850evm_nand_defconfig
> >>> +++ b/configs/da850evm_nand_defconfig
> >>> @@ -1,3 +1,4 @@
> >>> +CONFIG_LTO=y
> >>>  CONFIG_ARM=y
> >>>  CONFIG_SYS_THUMB_BUILD=y
> >>>  CONFIG_ARCH_DAVINCI=y
> >>> diff --git a/configs/imx6q_logic_defconfig b/configs/imx6q_logic_defconfig
> >>> index 36dc24d080..0f8aea6983 100644
> >>> --- a/configs/imx6q_logic_defconfig
> >>> +++ b/configs/imx6q_logic_defconfig
> >>> @@ -1,3 +1,4 @@
> >>> +CONFIG_LTO=y
> >>>  CONFIG_ARM=y
> >>>  CONFIG_ARCH_MX6=y
> >>>  CONFIG_SYS_TEXT_BASE=0x1780
> >>> diff --git a/configs/imx8mm_beacon_defconfig 
> >>> b/configs/imx8mm_beacon_defconfig
> >>> index 045b19f4f3..e8bb44eea6 100644
> >>> --- a/configs/imx8mm_beacon_defconfig
> >>> +++ b/configs/imx8mm_beacon_defconfig
> >>> @@ -1,3 +1,4 @@
> >>> +CONFIG_LTO=y
> >>>  CONFIG_ARM=y
> >>>  CONFIG_ARCH_IMX8M=y
> >>>  CONFIG_SYS_TEXT_BASE=0x4020
> >>> diff --git a/configs/imx8mm_venice_defconfig 
> >>> b/configs/imx8mm_venice_defconfig
> >>> index a15c3641f6..dff8f64540 100644
> >>> --- a/configs/imx8mm_venice_defconfig
> >>> +++ b/configs/imx8mm_venice_defconfig
> >>> @@ -1,3 +1,4 @@
> >>> +CONFIG_LTO=y
> >>>  CONFIG_ARM=y
> >>>  CONFIG_ARCH_IMX8M=y
> >>>  CONFIG_SYS_TEXT_BASE=0x4020
> >>> diff --git a/configs/imx8mn_beacon_2g_defconfig 
> >>> b/configs/imx8mn_beacon_2g_defconfig
> >>> index 58b8e49486..1c8cbc2c89 100644
> >>> --- a/configs/imx8mn_beacon_2g_defconfig
> >>> +++ b/configs/imx8mn_beacon_2g_defconfig
> >>> @@ -1,3 +1,4 @@
> >>> +CONFIG_LTO=y
> >>>  CONFIG_ARM=y
> >>>  CONFIG_ARCH_IMX8M=y
> >>>  CONFIG_SYS_TEXT_BASE=0x4020
> >>> diff --git a/configs/imx8mn_beacon_defconfig 
> >>> b/configs/imx8mn_beacon_defconfig
> >>> index d6a3385d8d..6457b9409a 100644
> >>> --- a/configs/imx8mn_beacon_defconfig
> >>> +++ b/configs/imx8mn_beacon_defconfig
> >>> @@ -1,3 +1,4 @@
> >>> +CONFIG_LTO=y
> >>>  CONFIG_ARM=y
> >>>  CONFIG_ARCH_IMX8M=y
> >>>  CONFIG_SYS_TEXT_BASE=0x4020
> >>> diff --git a/configs/nokia_rx51_defconfig b/configs/nokia_rx51_defconfig
> >>> index 312ca3a1a9..85ca627790 100644
> >>> --- a/configs/nokia_rx51_defconfig
> >>> +++ b/configs/nokia_rx51_defconfig
> >>> @@ -1,3 +1,4 @@
> >>> +CONFIG_LTO=y
> >>>  CONFIG_ARM=y
> >>>  # CONFIG_SYS_THUMB_BUILD is not set
> >>>  CONFIG_ARCH_OMAP2PLUS=y
> >>> diff --git a/configs/omap3_logic_defconfig b/configs/omap3_logic_defconfig
> >>> index 4e37237b86..cc4b727a2c 100644
> >>> --- a/configs/omap3_logic_defconfig
> >>> +++ 

Re: [PATCH u-boot v2.1 38/38] ARM: enable LTO for some boards

[Heinrich Schuchardt]

On 12.03.21 18:03, Marek Behun wrote:
> On Fri, 12 Mar 2021 08:34:41 -0800
> Tim Harvey  wrote:
>
>> On Fri, Mar 12, 2021 at 5:47 AM Marek Behún  wrote:
>>>
>>> Enable LTO for some boards that were tested by people on U-Boot Mailing
>>> List.
>>>
>>> Signed-off-by: Marek Behún 
>>> Tested-by: Adam Ford 
>>> Tested-by: Pali Rohár 
>>> Tested-by: Tim Harvey 
>>> ---
>>>  configs/am3517_evm_defconfig  | 1 +
>>>  configs/da850evm_defconfig| 1 +
>>>  configs/da850evm_direct_nor_defconfig | 1 +
>>>  configs/da850evm_nand_defconfig   | 1 +
>>>  configs/imx6q_logic_defconfig | 1 +
>>>  configs/imx8mm_beacon_defconfig   | 1 +
>>>  configs/imx8mm_venice_defconfig   | 1 +
>>>  configs/imx8mn_beacon_2g_defconfig| 1 +
>>>  configs/imx8mn_beacon_defconfig   | 1 +
>>>  configs/nokia_rx51_defconfig  | 1 +
>>>  configs/omap3_logic_defconfig | 1 +
>>>  configs/r8a774a1_beacon_defconfig | 1 +
>>>  configs/r8a774b1_beacon_defconfig | 1 +
>>>  configs/r8a774e1_beacon_defconfig | 1 +
>>>  configs/turris_mox_defconfig  | 1 +
>>>  configs/turris_omnia_defconfig| 1 +
>>>  16 files changed, 16 insertions(+)
>>>
>>> diff --git a/configs/am3517_evm_defconfig b/configs/am3517_evm_defconfig
>>> index bae0e0af35..d61eec94a4 100644
>>> --- a/configs/am3517_evm_defconfig
>>> +++ b/configs/am3517_evm_defconfig
>>> @@ -1,3 +1,4 @@
>>> +CONFIG_LTO=y
>>>  CONFIG_ARM=y
>>>  # CONFIG_SPL_USE_ARCH_MEMCPY is not set
>>>  # CONFIG_SPL_USE_ARCH_MEMSET is not set
>>> diff --git a/configs/da850evm_defconfig b/configs/da850evm_defconfig
>>> index 26e76a2929..6ff5e21bc6 100644
>>> --- a/configs/da850evm_defconfig
>>> +++ b/configs/da850evm_defconfig
>>> @@ -1,3 +1,4 @@
>>> +CONFIG_LTO=y
>>>  CONFIG_ARM=y
>>>  CONFIG_SYS_THUMB_BUILD=y
>>>  CONFIG_ARCH_DAVINCI=y
>>> diff --git a/configs/da850evm_direct_nor_defconfig 
>>> b/configs/da850evm_direct_nor_defconfig
>>> index d3860a963d..06c7ce7c47 100644
>>> --- a/configs/da850evm_direct_nor_defconfig
>>> +++ b/configs/da850evm_direct_nor_defconfig
>>> @@ -1,3 +1,4 @@
>>> +CONFIG_LTO=y
>>>  CONFIG_ARM=y
>>>  CONFIG_ARCH_CPU_INIT=y
>>>  CONFIG_ARCH_DAVINCI=y
>>> diff --git a/configs/da850evm_nand_defconfig 
>>> b/configs/da850evm_nand_defconfig
>>> index 0d0e9a148d..be737564e1 100644
>>> --- a/configs/da850evm_nand_defconfig
>>> +++ b/configs/da850evm_nand_defconfig
>>> @@ -1,3 +1,4 @@
>>> +CONFIG_LTO=y
>>>  CONFIG_ARM=y
>>>  CONFIG_SYS_THUMB_BUILD=y
>>>  CONFIG_ARCH_DAVINCI=y
>>> diff --git a/configs/imx6q_logic_defconfig b/configs/imx6q_logic_defconfig
>>> index 36dc24d080..0f8aea6983 100644
>>> --- a/configs/imx6q_logic_defconfig
>>> +++ b/configs/imx6q_logic_defconfig
>>> @@ -1,3 +1,4 @@
>>> +CONFIG_LTO=y
>>>  CONFIG_ARM=y
>>>  CONFIG_ARCH_MX6=y
>>>  CONFIG_SYS_TEXT_BASE=0x1780
>>> diff --git a/configs/imx8mm_beacon_defconfig 
>>> b/configs/imx8mm_beacon_defconfig
>>> index 045b19f4f3..e8bb44eea6 100644
>>> --- a/configs/imx8mm_beacon_defconfig
>>> +++ b/configs/imx8mm_beacon_defconfig
>>> @@ -1,3 +1,4 @@
>>> +CONFIG_LTO=y
>>>  CONFIG_ARM=y
>>>  CONFIG_ARCH_IMX8M=y
>>>  CONFIG_SYS_TEXT_BASE=0x4020
>>> diff --git a/configs/imx8mm_venice_defconfig 
>>> b/configs/imx8mm_venice_defconfig
>>> index a15c3641f6..dff8f64540 100644
>>> --- a/configs/imx8mm_venice_defconfig
>>> +++ b/configs/imx8mm_venice_defconfig
>>> @@ -1,3 +1,4 @@
>>> +CONFIG_LTO=y
>>>  CONFIG_ARM=y
>>>  CONFIG_ARCH_IMX8M=y
>>>  CONFIG_SYS_TEXT_BASE=0x4020
>>> diff --git a/configs/imx8mn_beacon_2g_defconfig 
>>> b/configs/imx8mn_beacon_2g_defconfig
>>> index 58b8e49486..1c8cbc2c89 100644
>>> --- a/configs/imx8mn_beacon_2g_defconfig
>>> +++ b/configs/imx8mn_beacon_2g_defconfig
>>> @@ -1,3 +1,4 @@
>>> +CONFIG_LTO=y
>>>  CONFIG_ARM=y
>>>  CONFIG_ARCH_IMX8M=y
>>>  CONFIG_SYS_TEXT_BASE=0x4020
>>> diff --git a/configs/imx8mn_beacon_defconfig 
>>> b/configs/imx8mn_beacon_defconfig
>>> index d6a3385d8d..6457b9409a 100644
>>> --- a/configs/imx8mn_beacon_defconfig
>>> +++ b/configs/imx8mn_beacon_defconfig
>>> @@ -1,3 +1,4 @@
>>> +CONFIG_LTO=y
>>>  CONFIG_ARM=y
>>>  CONFIG_ARCH_IMX8M=y
>>>  CONFIG_SYS_TEXT_BASE=0x4020
>>> diff --git a/configs/nokia_rx51_defconfig b/configs/nokia_rx51_defconfig
>>> index 312ca3a1a9..85ca627790 100644
>>> --- a/configs/nokia_rx51_defconfig
>>> +++ b/configs/nokia_rx51_defconfig
>>> @@ -1,3 +1,4 @@
>>> +CONFIG_LTO=y
>>>  CONFIG_ARM=y
>>>  # CONFIG_SYS_THUMB_BUILD is not set
>>>  CONFIG_ARCH_OMAP2PLUS=y
>>> diff --git a/configs/omap3_logic_defconfig b/configs/omap3_logic_defconfig
>>> index 4e37237b86..cc4b727a2c 100644
>>> --- a/configs/omap3_logic_defconfig
>>> +++ b/configs/omap3_logic_defconfig
>>> @@ -1,3 +1,4 @@
>>> +CONFIG_LTO=y
>>>  CONFIG_ARM=y
>>>  # CONFIG_SPL_USE_ARCH_MEMCPY is not set
>>>  # CONFIG_SPL_USE_ARCH_MEMSET is not set
>>> diff --git a/configs/r8a774a1_beacon_defconfig 
>>> b/configs/r8a774a1_beacon_defconfig
>>> index 2f45edd92e..9dd5d9192e 100644
>>> --- a/configs/r8a774a1_beacon_defconfig

Re: [PATCH u-boot v2.1 38/38] ARM: enable LTO for some boards

[Marek Behun]

On Fri, 12 Mar 2021 08:34:41 -0800
Tim Harvey  wrote:

> On Fri, Mar 12, 2021 at 5:47 AM Marek Behún  wrote:
> >
> > Enable LTO for some boards that were tested by people on U-Boot Mailing
> > List.
> >
> > Signed-off-by: Marek Behún 
> > Tested-by: Adam Ford 
> > Tested-by: Pali Rohár 
> > Tested-by: Tim Harvey 
> > ---
> >  configs/am3517_evm_defconfig  | 1 +
> >  configs/da850evm_defconfig| 1 +
> >  configs/da850evm_direct_nor_defconfig | 1 +
> >  configs/da850evm_nand_defconfig   | 1 +
> >  configs/imx6q_logic_defconfig | 1 +
> >  configs/imx8mm_beacon_defconfig   | 1 +
> >  configs/imx8mm_venice_defconfig   | 1 +
> >  configs/imx8mn_beacon_2g_defconfig| 1 +
> >  configs/imx8mn_beacon_defconfig   | 1 +
> >  configs/nokia_rx51_defconfig  | 1 +
> >  configs/omap3_logic_defconfig | 1 +
> >  configs/r8a774a1_beacon_defconfig | 1 +
> >  configs/r8a774b1_beacon_defconfig | 1 +
> >  configs/r8a774e1_beacon_defconfig | 1 +
> >  configs/turris_mox_defconfig  | 1 +
> >  configs/turris_omnia_defconfig| 1 +
> >  16 files changed, 16 insertions(+)
> >
> > diff --git a/configs/am3517_evm_defconfig b/configs/am3517_evm_defconfig
> > index bae0e0af35..d61eec94a4 100644
> > --- a/configs/am3517_evm_defconfig
> > +++ b/configs/am3517_evm_defconfig
> > @@ -1,3 +1,4 @@
> > +CONFIG_LTO=y
> >  CONFIG_ARM=y
> >  # CONFIG_SPL_USE_ARCH_MEMCPY is not set
> >  # CONFIG_SPL_USE_ARCH_MEMSET is not set
> > diff --git a/configs/da850evm_defconfig b/configs/da850evm_defconfig
> > index 26e76a2929..6ff5e21bc6 100644
> > --- a/configs/da850evm_defconfig
> > +++ b/configs/da850evm_defconfig
> > @@ -1,3 +1,4 @@
> > +CONFIG_LTO=y
> >  CONFIG_ARM=y
> >  CONFIG_SYS_THUMB_BUILD=y
> >  CONFIG_ARCH_DAVINCI=y
> > diff --git a/configs/da850evm_direct_nor_defconfig 
> > b/configs/da850evm_direct_nor_defconfig
> > index d3860a963d..06c7ce7c47 100644
> > --- a/configs/da850evm_direct_nor_defconfig
> > +++ b/configs/da850evm_direct_nor_defconfig
> > @@ -1,3 +1,4 @@
> > +CONFIG_LTO=y
> >  CONFIG_ARM=y
> >  CONFIG_ARCH_CPU_INIT=y
> >  CONFIG_ARCH_DAVINCI=y
> > diff --git a/configs/da850evm_nand_defconfig 
> > b/configs/da850evm_nand_defconfig
> > index 0d0e9a148d..be737564e1 100644
> > --- a/configs/da850evm_nand_defconfig
> > +++ b/configs/da850evm_nand_defconfig
> > @@ -1,3 +1,4 @@
> > +CONFIG_LTO=y
> >  CONFIG_ARM=y
> >  CONFIG_SYS_THUMB_BUILD=y
> >  CONFIG_ARCH_DAVINCI=y
> > diff --git a/configs/imx6q_logic_defconfig b/configs/imx6q_logic_defconfig
> > index 36dc24d080..0f8aea6983 100644
> > --- a/configs/imx6q_logic_defconfig
> > +++ b/configs/imx6q_logic_defconfig
> > @@ -1,3 +1,4 @@
> > +CONFIG_LTO=y
> >  CONFIG_ARM=y
> >  CONFIG_ARCH_MX6=y
> >  CONFIG_SYS_TEXT_BASE=0x1780
> > diff --git a/configs/imx8mm_beacon_defconfig 
> > b/configs/imx8mm_beacon_defconfig
> > index 045b19f4f3..e8bb44eea6 100644
> > --- a/configs/imx8mm_beacon_defconfig
> > +++ b/configs/imx8mm_beacon_defconfig
> > @@ -1,3 +1,4 @@
> > +CONFIG_LTO=y
> >  CONFIG_ARM=y
> >  CONFIG_ARCH_IMX8M=y
> >  CONFIG_SYS_TEXT_BASE=0x4020
> > diff --git a/configs/imx8mm_venice_defconfig 
> > b/configs/imx8mm_venice_defconfig
> > index a15c3641f6..dff8f64540 100644
> > --- a/configs/imx8mm_venice_defconfig
> > +++ b/configs/imx8mm_venice_defconfig
> > @@ -1,3 +1,4 @@
> > +CONFIG_LTO=y
> >  CONFIG_ARM=y
> >  CONFIG_ARCH_IMX8M=y
> >  CONFIG_SYS_TEXT_BASE=0x4020
> > diff --git a/configs/imx8mn_beacon_2g_defconfig 
> > b/configs/imx8mn_beacon_2g_defconfig
> > index 58b8e49486..1c8cbc2c89 100644
> > --- a/configs/imx8mn_beacon_2g_defconfig
> > +++ b/configs/imx8mn_beacon_2g_defconfig
> > @@ -1,3 +1,4 @@
> > +CONFIG_LTO=y
> >  CONFIG_ARM=y
> >  CONFIG_ARCH_IMX8M=y
> >  CONFIG_SYS_TEXT_BASE=0x4020
> > diff --git a/configs/imx8mn_beacon_defconfig 
> > b/configs/imx8mn_beacon_defconfig
> > index d6a3385d8d..6457b9409a 100644
> > --- a/configs/imx8mn_beacon_defconfig
> > +++ b/configs/imx8mn_beacon_defconfig
> > @@ -1,3 +1,4 @@
> > +CONFIG_LTO=y
> >  CONFIG_ARM=y
> >  CONFIG_ARCH_IMX8M=y
> >  CONFIG_SYS_TEXT_BASE=0x4020
> > diff --git a/configs/nokia_rx51_defconfig b/configs/nokia_rx51_defconfig
> > index 312ca3a1a9..85ca627790 100644
> > --- a/configs/nokia_rx51_defconfig
> > +++ b/configs/nokia_rx51_defconfig
> > @@ -1,3 +1,4 @@
> > +CONFIG_LTO=y
> >  CONFIG_ARM=y
> >  # CONFIG_SYS_THUMB_BUILD is not set
> >  CONFIG_ARCH_OMAP2PLUS=y
> > diff --git a/configs/omap3_logic_defconfig b/configs/omap3_logic_defconfig
> > index 4e37237b86..cc4b727a2c 100644
> > --- a/configs/omap3_logic_defconfig
> > +++ b/configs/omap3_logic_defconfig
> > @@ -1,3 +1,4 @@
> > +CONFIG_LTO=y
> >  CONFIG_ARM=y
> >  # CONFIG_SPL_USE_ARCH_MEMCPY is not set
> >  # CONFIG_SPL_USE_ARCH_MEMSET is not set
> > diff --git a/configs/r8a774a1_beacon_defconfig 
> > b/configs/r8a774a1_beacon_defconfig
> > index 2f45edd92e..9dd5d9192e 100644
> > --- a/configs/r8a774a1_beacon_defconfig
> > +++ b/configs/r8a774a1_beacon_defconfig
> 

Re: [PATCH u-boot v2 14/38] lib: crc32: put the crc_table variable into efi_runtime_rodata section

[Heinrich Schuchardt]

On 12.03.21 11:34, Marek Behún wrote:
> When compiling with LTO, the compiler fails with an error saying that
> `crc_table` causes a section type conflict with `efi_var_buf`.
>
> This is because both are declared to be in the same section (via macro
> `__efi_runtime_data`), but one is const while the other is not.
>
> Put this variable into the section .rodata.efi_runtime, instead of
> .data.efi_runtime, via macro __efi_runtime_rodata.
>
> Signed-off-by: Marek Behún 
> Reviewed-by: Marek Vasut 

Reviewed-by: Heinrich Schuchardt 

> ---
>  lib/crc32.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/lib/crc32.c b/lib/crc32.c
> index e9be3bf386..f2acc107fe 100644
> --- a/lib/crc32.c
> +++ b/lib/crc32.c
> @@ -26,6 +26,7 @@
>  #ifdef USE_HOSTCC
>  #define __efi_runtime
>  #define __efi_runtime_data
> +#define __efi_runtime_rodata
>  #endif
>
>  #define tole(x) cpu_to_le32(x)
> @@ -88,7 +89,7 @@ static void __efi_runtime make_crc_table(void)
>   * Table of CRC-32's of all single-byte values (made by make_crc_table)
>   */
>
> -static const uint32_t __efi_runtime_data crc_table[256] = {
> +static const uint32_t __efi_runtime_rodata crc_table[256] = {
>  tole(0xL), tole(0x77073096L), tole(0xee0e612cL), tole(0x990951baL),
>  tole(0x076dc419L), tole(0x706af48fL), tole(0xe963a535L), tole(0x9e6495a3L),
>  tole(0x0edb8832L), tole(0x79dcb8a4L), tole(0xe0d5e91eL), tole(0x97d2d988L),
>

Re: [PATCH u-boot v2 13/38] efi_selftest: compiler flags for efi_selftest_miniapp_exception.o

[Heinrich Schuchardt]

On 12.03.21 11:34, Marek Behún wrote:
> Add $(CFLAGS_EFI) and remove $(CFLAGS_NON_EFI) for
> efi_selftest_miniapp_exception.o.
>
> The removal is needed when compiling with LTO - this object file needs
> to be compiled without -flto.
>
> The adding is for consistency with other miniapps.
>
> Signed-off-by: Marek Behún 

Reviewed-by: Heinrich Schuchardt 

> ---
>  lib/efi_selftest/Makefile | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/lib/efi_selftest/Makefile b/lib/efi_selftest/Makefile
> index b02fd56e0a..8f042ad254 100644
> --- a/lib/efi_selftest/Makefile
> +++ b/lib/efi_selftest/Makefile
> @@ -10,6 +10,8 @@ ccflags-y += -DHOST_ARCH="$(HOST_ARCH)"
>
>  CFLAGS_dtbdump.o := $(CFLAGS_EFI) -Os -ffreestanding
>  CFLAGS_REMOVE_dtbdump.o := $(CFLAGS_NON_EFI)
> +CFLAGS_efi_selftest_miniapp_exception.o := $(CFLAGS_EFI) -Os -ffreestanding
> +CFLAGS_REMOVE_efi_selftest_miniapp_exception.o := $(CFLAGS_NON_EFI)
>  CFLAGS_efi_selftest_miniapp_exit.o := $(CFLAGS_EFI) -Os -ffreestanding
>  CFLAGS_REMOVE_efi_selftest_miniapp_exit.o := $(CFLAGS_NON_EFI)
>  CFLAGS_efi_selftest_miniapp_return.o := $(CFLAGS_EFI) -Os -ffreestanding
>

Re: [PATCH u-boot v2 12/38] efi_loader: add macro for const EFI runtime data

[Heinrich Schuchardt]

On 12.03.21 11:34, Marek Behún wrote:
> Add macro __efi_runtime_rodata, for const variables with similar purpose
> as those using __efi_runtime_data.
>
> Signed-off-by: Marek Behún 

Reviewed-by: Heinrich Schuchardt 

> ---
>  include/efi_loader.h | 17 +
>  1 file changed, 17 insertions(+)
>
> diff --git a/include/efi_loader.h b/include/efi_loader.h
> index 696f80e9f3..d673ba12e3 100644
> --- a/include/efi_loader.h
> +++ b/include/efi_loader.h
> @@ -682,6 +682,22 @@ ssize_t efi_dp_check_length(const struct efi_device_path 
> *dp,
>   */
>  #define __efi_runtime_data __section(".data.efi_runtime")
>
> +/**
> + * __efi_runtime_rodata - declares a read-only variable for EFI runtime 
> section
> + *
> + * This macro indicates that a variable is read-only (const) and should go 
> into
> + * the EFI runtime section, and thus still be available when the OS is 
> running.
> + *
> + * Only use on variables also declared const.
> + *
> + * Example:
> + *
> + * ::
> + *
> + *   static const __efi_runtime_rodata my_const_table[] = { 1, 2, 3 };
> + */
> +#define __efi_runtime_rodata __section(".rodata.efi_runtime")
> +
>  /**
>   * __efi_runtime - declares a function for EFI runtime section
>   *
> @@ -893,6 +909,7 @@ efi_status_t efi_launch_capsules(void);
>
>  /* Without CONFIG_EFI_LOADER we don't have a runtime section, stub it out */
>  #define __efi_runtime_data
> +#define __efi_runtime_rodata
>  #define __efi_runtime
>  static inline efi_status_t efi_add_runtime_mmio(void *mmio_ptr, u64 len)
>  {
>

Re: [PATCH u-boot v2 11/38] efi_loader: add Sphinx doc for __efi_runtime and __efi_runtime_data

[Heinrich Schuchardt]

On 12.03.21 11:34, Marek Behún wrote:
> Document the macros __efi_runtime and __efi_runtime_data in Sphinx
> style.
>
> Signed-off-by: Marek Behún 

Reviewed-by: Heinrich Schuchardt 

> ---
>  include/efi_loader.h | 29 ++---
>  1 file changed, 26 insertions(+), 3 deletions(-)
>
> diff --git a/include/efi_loader.h b/include/efi_loader.h
> index a8281b3c95..696f80e9f3 100644
> --- a/include/efi_loader.h
> +++ b/include/efi_loader.h
> @@ -666,11 +666,34 @@ ssize_t efi_dp_check_length(const struct 
> efi_device_path *dp,
>   (((_dp)->type == DEVICE_PATH_TYPE_##_type) && \
>((_dp)->sub_type == DEVICE_PATH_SUB_TYPE_##_subtype))
>
> -/*
> - * Use these to indicate that your code / data should go into the EFI runtime
> - * section and thus still be available when the OS is running
> +/**
> + * __efi_runtime_data - declares a non-const variable for EFI runtime section
> + *
> + * This macro indicates that a variable is non-const and should go into the
> + * EFI runtime section, and thus still be available when the OS is running.
> + *
> + * Only use on variables not declared const.
> + *
> + * Example:
> + *
> + * ::
> + *
> + *   static __efi_runtime_data my_computed_table[256];
>   */
>  #define __efi_runtime_data __section(".data.efi_runtime")
> +
> +/**
> + * __efi_runtime - declares a function for EFI runtime section
> + *
> + * This macro indicates that a function should go into the EFI runtime 
> section,
> + * and thus still be available when the OS is running.
> + *
> + * Example:
> + *
> + * ::
> + *
> + *   static __efi_runtime compute_my_table(void);
> + */
>  #define __efi_runtime __section(".text.efi_runtime")
>
>  /* Indicate supported runtime services */
>

Re: [PATCH u-boot v2 10/38] efi_loader: fix warning when linking with LTO

[Heinrich Schuchardt]

On 12.03.21 11:34, Marek Behún wrote:
> When linking with LTO, the compiler complains about type mismatch of
> variables `__efi_runtime_start`, `__efi_runtime_stop`,
> `__efi_runtime_rel_start` and `__efi_runtime_rel_stop`:
>
>  include/efi_loader.h:218:21: warning: type of ‘__efi_runtime_start’
>does not match original
>declaration [-Wlto-type-mismatch]
> 218 | extern unsigned int __efi_runtime_start, __efi_runtime_stop;
> | ^
>   arch/sandbox/lib/sections.c:7:6: note: ‘__efi_runtime_start’ was
>  previously declared here
>   7 | char __efi_runtime_start[0] __attribute__((section(".__efi_run
> |  ^
>
> Change the type to char[] in include/efi_loader.h.
>
> Signed-off-by: Marek Behún 
> Reviewed-by: Bin Meng 

This patch leaves us with definition differences:

We have:

arch/arm/lib/sections.c:31:
char __efi_runtime_start[0]
__attribute__((section(".__efi_runtime_start")));

arch/x86/lib/sections.c:6:char __efi_runtime_start[0]
__attribute__((section(".__efi_runtime_start")));

We should use [] everywhere. [0] was needed by elder GCC versions.

Best regards

Heinrich

> ---
>  include/efi_loader.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/include/efi_loader.h b/include/efi_loader.h
> index e38b41952d..a8281b3c95 100644
> --- a/include/efi_loader.h
> +++ b/include/efi_loader.h
> @@ -215,8 +215,8 @@ extern const efi_guid_t efi_guid_capsule_report;
>  /* GUID of firmware management protocol */
>  extern const efi_guid_t efi_guid_firmware_management_protocol;
>
> -extern unsigned int __efi_runtime_start, __efi_runtime_stop;
> -extern unsigned int __efi_runtime_rel_start, __efi_runtime_rel_stop;
> +extern char __efi_runtime_start[], __efi_runtime_stop[];
> +extern char __efi_runtime_rel_start[], __efi_runtime_rel_stop[];
>
>  /**
>   * struct efi_open_protocol_info_item - open protocol info item
>

Re: [PATCH u-boot v2.1 38/38] ARM: enable LTO for some boards

[Tim Harvey]

On Fri, Mar 12, 2021 at 5:47 AM Marek Behún  wrote:
>
> Enable LTO for some boards that were tested by people on U-Boot Mailing
> List.
>
> Signed-off-by: Marek Behún 
> Tested-by: Adam Ford 
> Tested-by: Pali Rohár 
> Tested-by: Tim Harvey 
> ---
>  configs/am3517_evm_defconfig  | 1 +
>  configs/da850evm_defconfig| 1 +
>  configs/da850evm_direct_nor_defconfig | 1 +
>  configs/da850evm_nand_defconfig   | 1 +
>  configs/imx6q_logic_defconfig | 1 +
>  configs/imx8mm_beacon_defconfig   | 1 +
>  configs/imx8mm_venice_defconfig   | 1 +
>  configs/imx8mn_beacon_2g_defconfig| 1 +
>  configs/imx8mn_beacon_defconfig   | 1 +
>  configs/nokia_rx51_defconfig  | 1 +
>  configs/omap3_logic_defconfig | 1 +
>  configs/r8a774a1_beacon_defconfig | 1 +
>  configs/r8a774b1_beacon_defconfig | 1 +
>  configs/r8a774e1_beacon_defconfig | 1 +
>  configs/turris_mox_defconfig  | 1 +
>  configs/turris_omnia_defconfig| 1 +
>  16 files changed, 16 insertions(+)
>
> diff --git a/configs/am3517_evm_defconfig b/configs/am3517_evm_defconfig
> index bae0e0af35..d61eec94a4 100644
> --- a/configs/am3517_evm_defconfig
> +++ b/configs/am3517_evm_defconfig
> @@ -1,3 +1,4 @@
> +CONFIG_LTO=y
>  CONFIG_ARM=y
>  # CONFIG_SPL_USE_ARCH_MEMCPY is not set
>  # CONFIG_SPL_USE_ARCH_MEMSET is not set
> diff --git a/configs/da850evm_defconfig b/configs/da850evm_defconfig
> index 26e76a2929..6ff5e21bc6 100644
> --- a/configs/da850evm_defconfig
> +++ b/configs/da850evm_defconfig
> @@ -1,3 +1,4 @@
> +CONFIG_LTO=y
>  CONFIG_ARM=y
>  CONFIG_SYS_THUMB_BUILD=y
>  CONFIG_ARCH_DAVINCI=y
> diff --git a/configs/da850evm_direct_nor_defconfig 
> b/configs/da850evm_direct_nor_defconfig
> index d3860a963d..06c7ce7c47 100644
> --- a/configs/da850evm_direct_nor_defconfig
> +++ b/configs/da850evm_direct_nor_defconfig
> @@ -1,3 +1,4 @@
> +CONFIG_LTO=y
>  CONFIG_ARM=y
>  CONFIG_ARCH_CPU_INIT=y
>  CONFIG_ARCH_DAVINCI=y
> diff --git a/configs/da850evm_nand_defconfig b/configs/da850evm_nand_defconfig
> index 0d0e9a148d..be737564e1 100644
> --- a/configs/da850evm_nand_defconfig
> +++ b/configs/da850evm_nand_defconfig
> @@ -1,3 +1,4 @@
> +CONFIG_LTO=y
>  CONFIG_ARM=y
>  CONFIG_SYS_THUMB_BUILD=y
>  CONFIG_ARCH_DAVINCI=y
> diff --git a/configs/imx6q_logic_defconfig b/configs/imx6q_logic_defconfig
> index 36dc24d080..0f8aea6983 100644
> --- a/configs/imx6q_logic_defconfig
> +++ b/configs/imx6q_logic_defconfig
> @@ -1,3 +1,4 @@
> +CONFIG_LTO=y
>  CONFIG_ARM=y
>  CONFIG_ARCH_MX6=y
>  CONFIG_SYS_TEXT_BASE=0x1780
> diff --git a/configs/imx8mm_beacon_defconfig b/configs/imx8mm_beacon_defconfig
> index 045b19f4f3..e8bb44eea6 100644
> --- a/configs/imx8mm_beacon_defconfig
> +++ b/configs/imx8mm_beacon_defconfig
> @@ -1,3 +1,4 @@
> +CONFIG_LTO=y
>  CONFIG_ARM=y
>  CONFIG_ARCH_IMX8M=y
>  CONFIG_SYS_TEXT_BASE=0x4020
> diff --git a/configs/imx8mm_venice_defconfig b/configs/imx8mm_venice_defconfig
> index a15c3641f6..dff8f64540 100644
> --- a/configs/imx8mm_venice_defconfig
> +++ b/configs/imx8mm_venice_defconfig
> @@ -1,3 +1,4 @@
> +CONFIG_LTO=y
>  CONFIG_ARM=y
>  CONFIG_ARCH_IMX8M=y
>  CONFIG_SYS_TEXT_BASE=0x4020
> diff --git a/configs/imx8mn_beacon_2g_defconfig 
> b/configs/imx8mn_beacon_2g_defconfig
> index 58b8e49486..1c8cbc2c89 100644
> --- a/configs/imx8mn_beacon_2g_defconfig
> +++ b/configs/imx8mn_beacon_2g_defconfig
> @@ -1,3 +1,4 @@
> +CONFIG_LTO=y
>  CONFIG_ARM=y
>  CONFIG_ARCH_IMX8M=y
>  CONFIG_SYS_TEXT_BASE=0x4020
> diff --git a/configs/imx8mn_beacon_defconfig b/configs/imx8mn_beacon_defconfig
> index d6a3385d8d..6457b9409a 100644
> --- a/configs/imx8mn_beacon_defconfig
> +++ b/configs/imx8mn_beacon_defconfig
> @@ -1,3 +1,4 @@
> +CONFIG_LTO=y
>  CONFIG_ARM=y
>  CONFIG_ARCH_IMX8M=y
>  CONFIG_SYS_TEXT_BASE=0x4020
> diff --git a/configs/nokia_rx51_defconfig b/configs/nokia_rx51_defconfig
> index 312ca3a1a9..85ca627790 100644
> --- a/configs/nokia_rx51_defconfig
> +++ b/configs/nokia_rx51_defconfig
> @@ -1,3 +1,4 @@
> +CONFIG_LTO=y
>  CONFIG_ARM=y
>  # CONFIG_SYS_THUMB_BUILD is not set
>  CONFIG_ARCH_OMAP2PLUS=y
> diff --git a/configs/omap3_logic_defconfig b/configs/omap3_logic_defconfig
> index 4e37237b86..cc4b727a2c 100644
> --- a/configs/omap3_logic_defconfig
> +++ b/configs/omap3_logic_defconfig
> @@ -1,3 +1,4 @@
> +CONFIG_LTO=y
>  CONFIG_ARM=y
>  # CONFIG_SPL_USE_ARCH_MEMCPY is not set
>  # CONFIG_SPL_USE_ARCH_MEMSET is not set
> diff --git a/configs/r8a774a1_beacon_defconfig 
> b/configs/r8a774a1_beacon_defconfig
> index 2f45edd92e..9dd5d9192e 100644
> --- a/configs/r8a774a1_beacon_defconfig
> +++ b/configs/r8a774a1_beacon_defconfig
> @@ -1,3 +1,4 @@
> +CONFIG_LTO=y
>  CONFIG_ARM=y
>  CONFIG_ARCH_RMOBILE=y
>  CONFIG_SYS_TEXT_BASE=0x5000
> diff --git a/configs/r8a774b1_beacon_defconfig 
> b/configs/r8a774b1_beacon_defconfig
> index ca514bb1aa..b7d7f23f5a 100644
> --- a/configs/r8a774b1_beacon_defconfig
> +++ b/configs/r8a774b1_beacon_defconfig
> @@ -1,3 +1,4 @@
> 

Re: [PATCH 5/6] efidebug: add multiple device path instances on Boot####

[Heinrich Schuchardt]

On 12.03.21 05:44, AKASHI Takahiro wrote:
> Ilias,
>
> Sorry, but I will have to repeat my question for better understandings.
>
> On Sat, Mar 06, 2021 at 12:23:01AM +0200, Ilias Apalodimas wrote:
>> The UEFI spec allow a packed array of UEFI device paths in the
>> FilePathList[] of an EFI_LOAD_OPTION. The first file path must
>> describe the loaded image but the rest are OS specific.
>>
>> Previous patches parse the device path and try to use the second
>> member of the array as an initrd. So let's modify efidebug slightly
>> and install the second file described in the command line as the
>> initrd device path.
>>
>> Signed-off-by: Ilias Apalodimas 
>> ---
>>  cmd/efidebug.c| 193 ++
>>  doc/board/emulation/qemu_capsule_update.rst   |   4 +-
>>  doc/uefi/uefi.rst |   2 +-
>>  .../test_efi_capsule/test_capsule_firmware.py |   6 +-
>>  test/py/tests/test_efi_secboot/test_signed.py |  16 +-
>>  .../test_efi_secboot/test_signed_intca.py |   8 +-
>>  .../tests/test_efi_secboot/test_unsigned.py   |   8 +-
>>  7 files changed, 179 insertions(+), 58 deletions(-)
>>
>> diff --git a/cmd/efidebug.c b/cmd/efidebug.c
>> index bbbcb0a54643..9a1c471a3eaa 100644
>> --- a/cmd/efidebug.c
>> +++ b/cmd/efidebug.c
>> @@ -9,6 +9,8 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -19,6 +21,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>
>>  #define BS systab.boottime
>>  #define RT systab.runtime
>> @@ -794,6 +797,65 @@ static int do_efi_show_tables(struct cmd_tbl *cmdtp, 
>> int flag,
>>  return CMD_RET_SUCCESS;
>>  }
>>
>> +/**
>> + * add_initrd_instance() - Append a device path to load_options pointing to 
>> an
>> + * inirtd
>> + *
>> + * @argc:   Number of arguments
>> + * @argv:   Argument array
>> + * @file_path   Existing device path, the new instance will be appended
>> + * Return:  Pointer to the device path or ERR_PTR
>> + *
>> + */
>> +static
>> +struct efi_device_path *add_initrd_instance(const char *dev, const char 
>> *part,
>> +const char *file,
>> +const struct efi_device_path *fp,
>> +efi_uintn_t *fp_size)
>> +{
>> +struct efi_device_path *tmp_dp = NULL, *tmp_fp = NULL;
>> +struct efi_device_path *final_fp = NULL, *initrd_dp = NULL;
>> +efi_status_t ret;
>> +const struct efi_initrd_dp id_dp = {
>> +.vendor = {
>> +{
>> +DEVICE_PATH_TYPE_MEDIA_DEVICE,
>> +DEVICE_PATH_SUB_TYPE_VENDOR_PATH,
>> +sizeof(id_dp.vendor),
>> +},
>> +EFI_INITRD_MEDIA_GUID,
>> +},
>> +.end = {
>> +DEVICE_PATH_TYPE_END,
>> +DEVICE_PATH_SUB_TYPE_END,
>> +sizeof(id_dp.end),
>> +}
>> +};
>> +
>> +ret = efi_dp_from_name(dev, part, file, _dp, _fp);
>> +if (ret != EFI_SUCCESS) {
>> +printf("Cannot create device path for \"%s %s\"\n", part, file);
>> +goto out;
>> +}
>> +
>> +initrd_dp =
>> +efi_dp_append_instance((const struct efi_device_path *)_dp,
>> +   tmp_fp);
>> +if (!initrd_dp) {
>> +printf("Cannot append media vendor device path path\n");
>> +goto out;
>> +}
>> +final_fp = efi_dp_concat(fp, initrd_dp);
>> +*fp_size = efi_dp_size(fp) + efi_dp_size(initrd_dp) +
>> +(2 * sizeof(struct efi_device_path));
>> +
>> +out:
>> +efi_free_pool(initrd_dp);
>> +efi_free_pool(tmp_dp);
>> +efi_free_pool(tmp_fp);
>> +return final_fp ? final_fp : ERR_PTR(-EINVAL);
>> +}
>> +
>>  /**
>>   * do_efi_boot_add() - set UEFI load option
>>   *
>> @@ -806,7 +868,9 @@ static int do_efi_show_tables(struct cmd_tbl *cmdtp, int 
>> flag,
>>   *
>>   * Implement efidebug "boot add" sub-command. Create or change UEFI load 
>> option.
>>   *
>> - * efidebug boot add[:]  
>> 
>> + * efidebug boot add -b[:] 
>> + *   -i   [:] 
>> + *   -s ''
>
> We discussed another syntax:
> efidebug boot add  ...
> efidebug boot add-initrd  
> (Please don't care detailed syntax for now.)

Thanks for revieweing.

Ilias and I discussed the syntax several times. As Ilias pointed out the
code and the test cases will be a bit simpler if there is only one command.

There are less corner cases that we have to test like what happens if
add-initrd is called without a prior definition of a binary.

I think using multiple commands is harder for the user to comprehend.

Setting the Boot variables will typically done from Linux when a new
kernel arrives or by a capsule update. The efidebug command will be less
common.

I prefer to stick with Ilias 

Re: [PATCH v2] tee: optee: Change printing during optee_probe

[Simon Glass]

Hi Ilias,

On Thu, 11 Mar 2021 at 22:07, Ilias Apalodimas
 wrote:
>
> On Thu, Mar 11, 2021 at 09:45:46PM -0700, Simon Glass wrote:
> > Hi Ilias,
> >
> > On Wed, 10 Mar 2021 at 06:35, Ilias Apalodimas
> >  wrote:
> > >
> > > Right now the error messages when optee has a version mismatch or shared
> > > memory is not configured are done with a debug().
> > > That's not very convenient since you have to enable debugging to figure
> > > out what's going on, although this is an actual error.
> >
> > The code that probes the device should report the error.
>
> I am notr sure I am following here. This gets called from the core dm code. Is
> there a callback in that, so we can register a specific print per device?
> If not now how do you expect the core to habdle each specific driver error
> code and print a message that makes sense?

Well, who probes the device? Somewhere there is a call to
uclass_first_device(...) or similar, and that should receive the
error-return value.

>
> > If you put
> > errors in a device driver it bloats the code and also it makes it
> > impossible for the caller to suppress the  error, e.g. if it is OK for
> > the device to not probe.
>
> Well in the op-tee case it's an explicit node you need to add in the DTB. So i
> am not really sure this applies here.

I'm not sure, but you might be thinking of the 'bind' step. For probe
it is OK for devices to fail to probe.

Regards,
Simon


> >
> >
> > >
> > > So let's switch the debug() -> dev_err() and report those explicitly.
> > >
> > > Signed-off-by: Ilias Apalodimas 
> > > Reviewed-by: Patrick Delaunay 
> > > ---
> > >  drivers/tee/optee/core.c | 6 +++---
> > >  1 file changed, 3 insertions(+), 3 deletions(-)

Re: [PATCH] cmd: part: number: remove inconsistent 0x from returned value

[Simon Glass]

Hi Stefan,

On Thu, 11 Mar 2021 at 23:58, Stefan Herbrechtsmeier
 wrote:
>
> Hi Simon,
>
> Am 12.03.2021 um 05:45 schrieb Simon Glass:
> > Hi Stefan,
> >
> > On Mon, 8 Mar 2021 at 03:45, Stefan Herbrechtsmeier
> >  wrote:
> >>
> >> Hi,
> >>
> >> Am 06.03.2021 um 21:12 schrieb Tom Rini:
> >>> On Fri, Mar 05, 2021 at 07:35:24AM -0700, Simon Glass wrote:
>  Hi,
> 
>  On Fri, 5 Mar 2021 at 07:33, Stefan Herbrechtsmeier
>   wrote:
> >
> > Hi Eugeniu,
> >
> > Am 05.03.2021 um 12:52 schrieb Eugeniu Rosca:
> >> Hello Stefan,
> >>
> >> On Fri, Mar 05, 2021 at 07:39:04AM +, Stefan Herbrechtsmeier wrote:
> >>> From: Stefan Herbrechtsmeier 
> >>>
> >>> The part number sub-command returns the hexadecimal value with a 
> >>> leading
> >>> 0x.
> >>
> >> That's to make sure that:
> >>   - users have clear and unequivocal feedback that '10'
> >> returned by the command is really HEX 10, not DEC 10.
> >>   - other U-Boot commands which need to take '0x10' as input
> >> will interpret it correctly, regardless of the way these
> >> other commands implement ascii-to-integer conversion.
> >
> > 'Almost all U-Boot commands expect numbers to be entered in hexadecimal
> > input format.' [1]
> >
> > The filesystem commands use `simple_strtoul(.., 16)` and interpret the
> > value as hexadecimal value.
> >
> > The 0x suggests that a 10 will be interpreted as decimal value and this
> > isn't true.
> >
> >>> This is inconsistent with other values in the command
> >>
> >> It could be, but it is then better to fix the inconsistency in those
> >> commands/sub-commands which add the ambiguity.
> >
> > Normally you are right but U-Boot by design use hexadecimal values
> > without 0x. The env_set_hex functions doesn't use 0x.
> >
> >>> and U-Boot uses hexadecimal values generally.
> >>
> >> The key word is "generally", but not always. Some U-Boot commands will
> >> process '10' as HEX 10 and some will process 10 as DEC 10. So, in order
> >> to avoid these games, I vote for leaving the 0x in place.
> 
>  I would be very surprised if 10 means 0d10 in a partition number. I
>  agree that putting a 0x in these values is a dangerous precedent and
>  will just cause confusion. U-Boot uses hex for addresses and most
>  arguments
> 
> >
> > You can avoid it only if you could mark decimal numbers and that is
> > impossible.
> 
>  0d10 is available. People are not used to it though.
> 
>  Reviewed-by: Simon Glass 
> 
> >
> > @Tom: Does U-Boot still expect numbers to be hexadecimal values?
> >
> > [1] https://www.denx.de/wiki/DULG/UBootCommandLineInterface
> >
> >>>
> >>> Signed-off-by: Stefan Herbrechtsmeier 
> >>> 
> >>>
> >>> ---
> >>>
> >>> cmd/part.c | 2 +-
> >>> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>>
> >>> diff --git a/cmd/part.c b/cmd/part.c
> >>> index 3395c17b89..56e1852c66 100644
> >>> --- a/cmd/part.c
> >>> +++ b/cmd/part.c
> >>> @@ -152,7 +152,7 @@ static int do_part_info(int argc, char *const 
> >>> argv[], enum cmd_part_info param)
> >>>snprintf(buf, sizeof(buf), LBAF, info.size);
> >>>break;
> >>>case CMD_PART_INFO_NUMBER:
> >>> -snprintf(buf, sizeof(buf), "0x%x", part);
> >>> +snprintf(buf, sizeof(buf), "%x", part);
> >>
> >>>
> >>> I am not a fan of this change as well, especially having spent time on
> >>> some platforms that have literally 20+ partition entries.  Being clear
> >>> here that this is a hex value is important.
> >>
> >> But isn't it confusing to use a 0x for a value which is treated as
> >> hexadecimal value by the commands independent of the 0x. The 0x results
> >> in the assumption that the partition is a decimal value without the 0x.
> >>
> >> What is the correct way to convert a hexadecimal value into a decimal
> >> value on the shell? I need a value without prefix (decimal value) to
> >> pass it to the root parameter of the bootargs.
> >>
> >> At the moment the different default numeral systems of common functions
> >> like load and test are very irritating. The load command uses
> >> hexadecimal value and doesn't support decimal value. The test command
> >> uses decimal value by default but supports hexadecimal values with a
> >> prefix. This means that the returned variable filesize of the command
> >> load couldn't be checked by test and the user have to use the itest 
> >> command.
> >
> > Let's use hex where possible. I am not sure what to do with the test
> > command, nor how often we use 'test' with addresses, but I think
> > adding an option to 'test' to make it use hex or dec would be good.
>
> But what is the difference to test vs itest?

Well at 

Re: [PATCH v2 17/21] dm: core: Correctly read of simple-bus

[Simon Glass]

On Fri, 12 Mar 2021 at 06:37, Bin Meng  wrote:
>
> At present we decode simple bus  using the following assumption:
>
> - parent #address-cells 1
> - child #address-cells 1
> - child #size-cells 1
>
> However this might not always be the case.
>
> Update to use fdt_addr_t and fdt_size_t in 'struct simple_bus_plat', and
> use fdt_read_ranges() to correctly decode it according to the actual
> parent and child #address-cells / #size-cells under a Kconfig option
> CONFIG_SIMPLE_BUS_CORRECT_RANGE which can be turned on for any board
> that needs it.
>
> Signed-off-by: Bin Meng 
>
> ---
>
> Changes in v2:
> - include 
> - use a Kconfig option CONFIG_SIMPLE_BUS_CORRECT_RANGE to control the
>   new behavior for boards that want this
>
>  drivers/core/Kconfig  | 13 +
>  drivers/core/simple-bus.c | 32 +---
>  include/dm/simple_bus.h   |  6 +++---
>  3 files changed, 41 insertions(+), 10 deletions(-)

Reviewed-by: Simon Glass 

Re: [PATCH u-boot v2 00/38] U-Boot LTO (Sandbox + Some ARM boards)

[Tom Rini]

On Fri, Mar 12, 2021 at 04:26:54PM +0100, Harald Seiler wrote:
> On Fri, 2021-03-12 at 16:17 +0100, Pali Rohár wrote:
> > On Friday 12 March 2021 16:07:22 Harald Seiler wrote:
> > > On Fri, 2021-03-12 at 15:26 +0100, Marek Behun wrote:
> > > > On Fri, 12 Mar 2021 15:21:05 +0100
> > > > Harald Seiler  wrote:
> > > > 
> > > > > Hi Marek,
> > > > > 
> > > > > On Fri, 2021-03-12 at 11:33 +0100, Marek Behún wrote:
> > > > > > Hello,
> > > > > > 
> > > > > > I am sending version 2 of patches adding support for LTO to U-Boot.
> > > > > > 
> > > > > > This series was tested by Github/Azure CI at
> > > > > >   https://github.com/u-boot/u-boot/pull/57
> > > > > > 
> > > > > > Code reduction is on average 4.23% for u-boot.bin and 13.58% for
> > > > > > u-boot-spl.bin.
> > > > > > 
> > > > > > I am currently running a build test for all 1077 ARM defconfigs.
> > > > > > Of the first 232 defconfigs, 2 are failing when LTO is enabled
> > > > > > (chromebook_jerry and chromebook_speedy). Note that this series
> > > > > > only enables LTO for tested boards.
> > > > > > 
> > > > > > Changes since v1:
> > > > > > - remove patches applied into u-boot-marvell
> > > > > > - added Reviewed-by tags
> > > > > > - addressed some issues discovered by Bin Meng, Marek Vasut,
> > > > > >   Heinrich Schuchardt
> > > > > > - added more ARM boards (thanks to Adam Ford, Tim Harvey and Bin 
> > > > > > Meng)
> > > > > > - removed --gc-sections for ARM if internal libgcc is used
> > > > > > - remove -fwhole-program in final LTO LDFLAGS
> > > > > > - declared all 4 functions (memcpy, memset, memcmp, memmove) __used,
> > > > > >   (these are mentioned in GCC man page for option -nodefaultlibs 
> > > > > > that
> > > > > >    the compiler may generate; this seems to be a bug in GCC that 
> > > > > > linking
> > > > > >    fails with LTO even if these functions are present, because the
> > > > > >    symbols can be renamed on some targets by optimization)  
> > > > > 
> > > > > I'm hitting a compiler error when building with imx6q_logic_defconfig:
> > > > > 
> > > > >   real-ld: error: no memory region specified for loadable section 
> > > > > `.note.gnu.build-id'
> > > > > 
> > > > > It seems this is caused by calling the linker through a gcc invocation
> > > > > which adds a `--build-id` commandline flag.  I think the linker script
> > > > > which is used for SPL in this case 
> > > > > (arch/arm/mach-omap2/u-boot-spl.lds)
> > > > > isn't properly set up to deal with a build-id.
> > > > > 
> > > > > I'm not sure how to deal with this.  One could either add
> > > > > `--build-id=none` to the GCC commandline to suppress generation of 
> > > > > this
> > > > > section entirely (it is not emitted in non-LTO builds right now 
> > > > > anyway) or
> > > > > include it in .text in said linker script so it is visible on the 
> > > > > target.
> > > > > What do you think?
> > > > > 
> > > > > I should note that I am using a Yocto-generated toolchain.  I suppose 
> > > > > most
> > > > > standard toolchains' behavior regarding the `--build-id` flag probably
> > > > > differs.
> > > > > 
> > > > > Regards,
> > > > 
> > > > I encountered this with Debian's cross toolchain, but since this did
> > > > not happen on my station with Gentoo crossdev toolchain, nor on Azure
> > > > CI, I ignored it.
> > > > 
> > > > What is the purpose of --build-id? Why do people use it?
> > > 
> > > I'm not entirely sure but I think it acts as a unique identifier for
> > > a certain binary.  So you can match up a core-dump with its debug info for
> > > example.
> > > 
> > > But I am unsure if anyone in the firmware space is actively using this
> > > feature... At least U-Boot does not actually include the build-id on the
> > > target - it is not generated for SPL at all and U-Boot proper only
> > > contains it in the ELF file, it is not exported into the raw binary.
> > 
> > IIRC Debian is using build id to split out debug symbols to external ELF
> > binary. So based on build id it can correctly identify which external
> > ELF file contains correct debug symbols for stripped ELF binary. IIRC
> > gdb in Debian can locale external ELF file with debug symbols from
> > well-known location, so you just need to install appropriate -dbg
> > package and gdb automatically loads debug symbols.
> > 
> > But if you want to use build id for any purpose, you need some binary
> > "container" where you can store metadata (EXE, ELF, ...). So I think
> > build id would be normally stripped from RAW u-boot.bin binary.
> > 
> > But if you really want to use build id in U-Boot, what about following
> > idea? Put build id into some U-Boot global variable and add some U-Boot
> > command which can print it in U-Boot console. And then based on it you
> > can locale u-boot ELF binary on your disk (if you have not removed it)
> > and you can start e.g. debugging or other things.
> > 
> > In this case build id can be useful for unique identification of the
> > built binary.
> 
> For the record, I don't 

Re: [PATCH u-boot v2 00/38] U-Boot LTO (Sandbox + Some ARM boards)

[Pali Rohár]

On Friday 12 March 2021 16:26:54 Harald Seiler wrote:
> But either way I think this only really matters if you have a
> hardware-debugger and intend to debug U-Boot with it.

You do not need hardware debugger, nor any "real hardware". You can run
U-Boot in qemu-system and use qemu-system capabilities (-S -s) to export
remote gdb control via network TCP socket. Then you can attach your
local gdb to qemu-system (target remote localhost:1234) and debug qemu.

I have used this qemu-system feature more times as it is easier to debug
some issues directly on computer without need to use external HW. But
with ability to run "real u-boot.bin" binary like on read HW.

Re: [PATCH u-boot v2 00/38] U-Boot LTO (Sandbox + Some ARM boards)

[Harald Seiler]

On Fri, 2021-03-12 at 16:17 +0100, Pali Rohár wrote:
> On Friday 12 March 2021 16:07:22 Harald Seiler wrote:
> > On Fri, 2021-03-12 at 15:26 +0100, Marek Behun wrote:
> > > On Fri, 12 Mar 2021 15:21:05 +0100
> > > Harald Seiler  wrote:
> > > 
> > > > Hi Marek,
> > > > 
> > > > On Fri, 2021-03-12 at 11:33 +0100, Marek Behún wrote:
> > > > > Hello,
> > > > > 
> > > > > I am sending version 2 of patches adding support for LTO to U-Boot.
> > > > > 
> > > > > This series was tested by Github/Azure CI at
> > > > >   https://github.com/u-boot/u-boot/pull/57
> > > > > 
> > > > > Code reduction is on average 4.23% for u-boot.bin and 13.58% for
> > > > > u-boot-spl.bin.
> > > > > 
> > > > > I am currently running a build test for all 1077 ARM defconfigs.
> > > > > Of the first 232 defconfigs, 2 are failing when LTO is enabled
> > > > > (chromebook_jerry and chromebook_speedy). Note that this series
> > > > > only enables LTO for tested boards.
> > > > > 
> > > > > Changes since v1:
> > > > > - remove patches applied into u-boot-marvell
> > > > > - added Reviewed-by tags
> > > > > - addressed some issues discovered by Bin Meng, Marek Vasut,
> > > > >   Heinrich Schuchardt
> > > > > - added more ARM boards (thanks to Adam Ford, Tim Harvey and Bin Meng)
> > > > > - removed --gc-sections for ARM if internal libgcc is used
> > > > > - remove -fwhole-program in final LTO LDFLAGS
> > > > > - declared all 4 functions (memcpy, memset, memcmp, memmove) __used,
> > > > >   (these are mentioned in GCC man page for option -nodefaultlibs that
> > > > >    the compiler may generate; this seems to be a bug in GCC that 
> > > > > linking
> > > > >    fails with LTO even if these functions are present, because the
> > > > >    symbols can be renamed on some targets by optimization)  
> > > > 
> > > > I'm hitting a compiler error when building with imx6q_logic_defconfig:
> > > > 
> > > >   real-ld: error: no memory region specified for loadable section 
> > > > `.note.gnu.build-id'
> > > > 
> > > > It seems this is caused by calling the linker through a gcc invocation
> > > > which adds a `--build-id` commandline flag.  I think the linker script
> > > > which is used for SPL in this case (arch/arm/mach-omap2/u-boot-spl.lds)
> > > > isn't properly set up to deal with a build-id.
> > > > 
> > > > I'm not sure how to deal with this.  One could either add
> > > > `--build-id=none` to the GCC commandline to suppress generation of this
> > > > section entirely (it is not emitted in non-LTO builds right now anyway) 
> > > > or
> > > > include it in .text in said linker script so it is visible on the 
> > > > target.
> > > > What do you think?
> > > > 
> > > > I should note that I am using a Yocto-generated toolchain.  I suppose 
> > > > most
> > > > standard toolchains' behavior regarding the `--build-id` flag probably
> > > > differs.
> > > > 
> > > > Regards,
> > > 
> > > I encountered this with Debian's cross toolchain, but since this did
> > > not happen on my station with Gentoo crossdev toolchain, nor on Azure
> > > CI, I ignored it.
> > > 
> > > What is the purpose of --build-id? Why do people use it?
> > 
> > I'm not entirely sure but I think it acts as a unique identifier for
> > a certain binary.  So you can match up a core-dump with its debug info for
> > example.
> > 
> > But I am unsure if anyone in the firmware space is actively using this
> > feature... At least U-Boot does not actually include the build-id on the
> > target - it is not generated for SPL at all and U-Boot proper only
> > contains it in the ELF file, it is not exported into the raw binary.
> 
> IIRC Debian is using build id to split out debug symbols to external ELF
> binary. So based on build id it can correctly identify which external
> ELF file contains correct debug symbols for stripped ELF binary. IIRC
> gdb in Debian can locale external ELF file with debug symbols from
> well-known location, so you just need to install appropriate -dbg
> package and gdb automatically loads debug symbols.
> 
> But if you want to use build id for any purpose, you need some binary
> "container" where you can store metadata (EXE, ELF, ...). So I think
> build id would be normally stripped from RAW u-boot.bin binary.
> 
> But if you really want to use build id in U-Boot, what about following
> idea? Put build id into some U-Boot global variable and add some U-Boot
> command which can print it in U-Boot console. And then based on it you
> can locale u-boot ELF binary on your disk (if you have not removed it)
> and you can start e.g. debugging or other things.
> 
> In this case build id can be useful for unique identification of the
> built binary.

For the record, I don't care much, I just noticed the compiler error and
wanted to raise awareness.

But yeah, it might be useful indeed.  I found a blog-post [1] of someone
else doing exactly this, by just adding

  PROVIDE(g_note_build_id = .);
  *(.note.gnu.build-id)

to the linker script and then referencing `g_note_build_id` 

Re: [PATCH u-boot v2 00/38] U-Boot LTO (Sandbox + Some ARM boards)

[Marek Behun]

On Fri, 12 Mar 2021 16:11:13 +0100
Harald Seiler  wrote:

> On Fri, 2021-03-12 at 16:07 +0100, Harald Seiler wrote:
> > On Fri, 2021-03-12 at 15:26 +0100, Marek Behun wrote:  
> > > On Fri, 12 Mar 2021 15:21:05 +0100
> > > Harald Seiler  wrote:
> > >   
> > > > Hi Marek,
> > > > 
> > > > On Fri, 2021-03-12 at 11:33 +0100, Marek Behún wrote:  
> > > > > Hello,
> > > > > 
> > > > > I am sending version 2 of patches adding support for LTO to U-Boot.
> > > > > 
> > > > > This series was tested by Github/Azure CI at
> > > > >   https://github.com/u-boot/u-boot/pull/57
> > > > > 
> > > > > Code reduction is on average 4.23% for u-boot.bin and 13.58% for
> > > > > u-boot-spl.bin.
> > > > > 
> > > > > I am currently running a build test for all 1077 ARM defconfigs.
> > > > > Of the first 232 defconfigs, 2 are failing when LTO is enabled
> > > > > (chromebook_jerry and chromebook_speedy). Note that this series
> > > > > only enables LTO for tested boards.
> > > > > 
> > > > > Changes since v1:
> > > > > - remove patches applied into u-boot-marvell
> > > > > - added Reviewed-by tags
> > > > > - addressed some issues discovered by Bin Meng, Marek Vasut,
> > > > >   Heinrich Schuchardt
> > > > > - added more ARM boards (thanks to Adam Ford, Tim Harvey and Bin Meng)
> > > > > - removed --gc-sections for ARM if internal libgcc is used
> > > > > - remove -fwhole-program in final LTO LDFLAGS
> > > > > - declared all 4 functions (memcpy, memset, memcmp, memmove) __used,
> > > > >   (these are mentioned in GCC man page for option -nodefaultlibs that
> > > > >    the compiler may generate; this seems to be a bug in GCC that 
> > > > > linking
> > > > >    fails with LTO even if these functions are present, because the
> > > > >    symbols can be renamed on some targets by optimization)    
> > > > 
> > > > I'm hitting a compiler error when building with imx6q_logic_defconfig:
> > > > 
> > > >   real-ld: error: no memory region specified for loadable section 
> > > > `.note.gnu.build-id'
> > > > 
> > > > It seems this is caused by calling the linker through a gcc invocation
> > > > which adds a `--build-id` commandline flag.  I think the linker script
> > > > which is used for SPL in this case (arch/arm/mach-omap2/u-boot-spl.lds)
> > > > isn't properly set up to deal with a build-id.
> > > > 
> > > > I'm not sure how to deal with this.  One could either add
> > > > `--build-id=none` to the GCC commandline to suppress generation of this
> > > > section entirely (it is not emitted in non-LTO builds right now anyway) 
> > > > or
> > > > include it in .text in said linker script so it is visible on the 
> > > > target.
> > > > What do you think?
> > > > 
> > > > I should note that I am using a Yocto-generated toolchain.  I suppose 
> > > > most
> > > > standard toolchains' behavior regarding the `--build-id` flag probably
> > > > differs.
> > > > 
> > > > Regards,  
> > > 
> > > I encountered this with Debian's cross toolchain, but since this did
> > > not happen on my station with Gentoo crossdev toolchain, nor on Azure
> > > CI, I ignored it.
> > > 
> > > What is the purpose of --build-id? Why do people use it?  
> > 
> > I'm not entirely sure but I think it acts as a unique identifier for
> > a certain binary.  So you can match up a core-dump with its debug info for
> > example.
> > 
> > But I am unsure if anyone in the firmware space is actively using this
> > feature... At least U-Boot does not actually include the build-id on the
> > target - it is not generated for SPL at all and U-Boot proper only
> > contains it in the ELF file, it is not exported into the raw binary.  
> 
> This is the origin of --build-id:
> 
>   https://fedoraproject.org/wiki/Releases/FeatureBuildId
> 

Tom, do we want build-id stored in binaries? Maybe it can be useful for
something.

Marek

Re: Please pull u-boot-marvell/master

[Tom Rini]

On Fri, Mar 12, 2021 at 10:02:36AM +0100, Stefan Roese wrote:

> Hi Tom,
> 
> please pull the next batch of Marvell MVEBU related patches. Here the
> summary log:
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH u-boot v2 00/38] U-Boot LTO (Sandbox + Some ARM boards)

[Pali Rohár]

On Friday 12 March 2021 16:07:22 Harald Seiler wrote:
> On Fri, 2021-03-12 at 15:26 +0100, Marek Behun wrote:
> > On Fri, 12 Mar 2021 15:21:05 +0100
> > Harald Seiler  wrote:
> > 
> > > Hi Marek,
> > > 
> > > On Fri, 2021-03-12 at 11:33 +0100, Marek Behún wrote:
> > > > Hello,
> > > > 
> > > > I am sending version 2 of patches adding support for LTO to U-Boot.
> > > > 
> > > > This series was tested by Github/Azure CI at
> > > >   https://github.com/u-boot/u-boot/pull/57
> > > > 
> > > > Code reduction is on average 4.23% for u-boot.bin and 13.58% for
> > > > u-boot-spl.bin.
> > > > 
> > > > I am currently running a build test for all 1077 ARM defconfigs.
> > > > Of the first 232 defconfigs, 2 are failing when LTO is enabled
> > > > (chromebook_jerry and chromebook_speedy). Note that this series
> > > > only enables LTO for tested boards.
> > > > 
> > > > Changes since v1:
> > > > - remove patches applied into u-boot-marvell
> > > > - added Reviewed-by tags
> > > > - addressed some issues discovered by Bin Meng, Marek Vasut,
> > > >   Heinrich Schuchardt
> > > > - added more ARM boards (thanks to Adam Ford, Tim Harvey and Bin Meng)
> > > > - removed --gc-sections for ARM if internal libgcc is used
> > > > - remove -fwhole-program in final LTO LDFLAGS
> > > > - declared all 4 functions (memcpy, memset, memcmp, memmove) __used,
> > > >   (these are mentioned in GCC man page for option -nodefaultlibs that
> > > >    the compiler may generate; this seems to be a bug in GCC that linking
> > > >    fails with LTO even if these functions are present, because the
> > > >    symbols can be renamed on some targets by optimization)  
> > > 
> > > I'm hitting a compiler error when building with imx6q_logic_defconfig:
> > > 
> > >   real-ld: error: no memory region specified for loadable section 
> > > `.note.gnu.build-id'
> > > 
> > > It seems this is caused by calling the linker through a gcc invocation
> > > which adds a `--build-id` commandline flag.  I think the linker script
> > > which is used for SPL in this case (arch/arm/mach-omap2/u-boot-spl.lds)
> > > isn't properly set up to deal with a build-id.
> > > 
> > > I'm not sure how to deal with this.  One could either add
> > > `--build-id=none` to the GCC commandline to suppress generation of this
> > > section entirely (it is not emitted in non-LTO builds right now anyway) or
> > > include it in .text in said linker script so it is visible on the target.
> > > What do you think?
> > > 
> > > I should note that I am using a Yocto-generated toolchain.  I suppose most
> > > standard toolchains' behavior regarding the `--build-id` flag probably
> > > differs.
> > > 
> > > Regards,
> > 
> > I encountered this with Debian's cross toolchain, but since this did
> > not happen on my station with Gentoo crossdev toolchain, nor on Azure
> > CI, I ignored it.
> > 
> > What is the purpose of --build-id? Why do people use it?
> 
> I'm not entirely sure but I think it acts as a unique identifier for
> a certain binary.  So you can match up a core-dump with its debug info for
> example.
> 
> But I am unsure if anyone in the firmware space is actively using this
> feature... At least U-Boot does not actually include the build-id on the
> target - it is not generated for SPL at all and U-Boot proper only
> contains it in the ELF file, it is not exported into the raw binary.

IIRC Debian is using build id to split out debug symbols to external ELF
binary. So based on build id it can correctly identify which external
ELF file contains correct debug symbols for stripped ELF binary. IIRC
gdb in Debian can locale external ELF file with debug symbols from
well-known location, so you just need to install appropriate -dbg
package and gdb automatically loads debug symbols.

But if you want to use build id for any purpose, you need some binary
"container" where you can store metadata (EXE, ELF, ...). So I think
build id would be normally stripped from RAW u-boot.bin binary.

But if you really want to use build id in U-Boot, what about following
idea? Put build id into some U-Boot global variable and add some U-Boot
command which can print it in U-Boot console. And then based on it you
can locale u-boot ELF binary on your disk (if you have not removed it)
and you can start e.g. debugging or other things.

In this case build id can be useful for unique identification of the
built binary.

Re: [PATCH v2 00/21] ppc: qemu: Add eTSEC support

[Bin Meng]

On Fri, Mar 12, 2021 at 9:36 PM Bin Meng  wrote:
>
> QEMU ppce500 machine can dynamically instantiate an eTSEC device
> if "-device eTSEC" is given to QEMU.
>
> This series updates the fixed-link ethernet PHY driver as well as
> the Freescale eTSEC driver to support the QEMU ppce500 board.
>
> 3 patches related to fixed phy in v1 are dropped in v2 as the changes
> were done by Vladimir's fixed phy & Sandbox DSA series [1]. Vladimir's
> series is now included in v2, and updated as needed.
>
> This cover letter is cc'ed to QEMU mailing list for a heads-up.
> A future patch will be sent to QEMU mailing list to bring its in-tree
> U-Boot source codes up-to-date.
>
> This series is avaiable at u-boot-x86/eTSEC for testing.
>
> [1] 
> https://patchwork.ozlabs.org/project/uboot/patch/20210216224804.3355044-2-olte...@gmail.com/
>
> Changes in v2:
> - move device tree parsing from xilinxgmiitorgmii_probe() to
>   xilinxgmiitorgmii_config() and use OF APIs
> - new patch: split from <20210216224804.3355044-4-olte...@gmail.com>
> - include 
> - use a Kconfig option CONFIG_SIMPLE_BUS_CORRECT_RANGE to control the
>   new behavior for boards that want this
> - default y if SANDBOX for CONFIG_SIMPLE_BUS_CORRECT_RANGE
> - turn on CONFIG_SIMPLE_BUS_CORRECT_RANGE in qemu-ppce500_defconfig

Azure results: PASS
https://dev.azure.com/bmeng/GitHub/_build/results?buildId=340=results

Re: [PATCH u-boot v2 00/38] U-Boot LTO (Sandbox + Some ARM boards)

[Harald Seiler]

On Fri, 2021-03-12 at 16:07 +0100, Harald Seiler wrote:
> On Fri, 2021-03-12 at 15:26 +0100, Marek Behun wrote:
> > On Fri, 12 Mar 2021 15:21:05 +0100
> > Harald Seiler  wrote:
> > 
> > > Hi Marek,
> > > 
> > > On Fri, 2021-03-12 at 11:33 +0100, Marek Behún wrote:
> > > > Hello,
> > > > 
> > > > I am sending version 2 of patches adding support for LTO to U-Boot.
> > > > 
> > > > This series was tested by Github/Azure CI at
> > > >   https://github.com/u-boot/u-boot/pull/57
> > > > 
> > > > Code reduction is on average 4.23% for u-boot.bin and 13.58% for
> > > > u-boot-spl.bin.
> > > > 
> > > > I am currently running a build test for all 1077 ARM defconfigs.
> > > > Of the first 232 defconfigs, 2 are failing when LTO is enabled
> > > > (chromebook_jerry and chromebook_speedy). Note that this series
> > > > only enables LTO for tested boards.
> > > > 
> > > > Changes since v1:
> > > > - remove patches applied into u-boot-marvell
> > > > - added Reviewed-by tags
> > > > - addressed some issues discovered by Bin Meng, Marek Vasut,
> > > >   Heinrich Schuchardt
> > > > - added more ARM boards (thanks to Adam Ford, Tim Harvey and Bin Meng)
> > > > - removed --gc-sections for ARM if internal libgcc is used
> > > > - remove -fwhole-program in final LTO LDFLAGS
> > > > - declared all 4 functions (memcpy, memset, memcmp, memmove) __used,
> > > >   (these are mentioned in GCC man page for option -nodefaultlibs that
> > > >    the compiler may generate; this seems to be a bug in GCC that linking
> > > >    fails with LTO even if these functions are present, because the
> > > >    symbols can be renamed on some targets by optimization)  
> > > 
> > > I'm hitting a compiler error when building with imx6q_logic_defconfig:
> > > 
> > >   real-ld: error: no memory region specified for loadable section 
> > > `.note.gnu.build-id'
> > > 
> > > It seems this is caused by calling the linker through a gcc invocation
> > > which adds a `--build-id` commandline flag.  I think the linker script
> > > which is used for SPL in this case (arch/arm/mach-omap2/u-boot-spl.lds)
> > > isn't properly set up to deal with a build-id.
> > > 
> > > I'm not sure how to deal with this.  One could either add
> > > `--build-id=none` to the GCC commandline to suppress generation of this
> > > section entirely (it is not emitted in non-LTO builds right now anyway) or
> > > include it in .text in said linker script so it is visible on the target.
> > > What do you think?
> > > 
> > > I should note that I am using a Yocto-generated toolchain.  I suppose most
> > > standard toolchains' behavior regarding the `--build-id` flag probably
> > > differs.
> > > 
> > > Regards,
> > 
> > I encountered this with Debian's cross toolchain, but since this did
> > not happen on my station with Gentoo crossdev toolchain, nor on Azure
> > CI, I ignored it.
> > 
> > What is the purpose of --build-id? Why do people use it?
> 
> I'm not entirely sure but I think it acts as a unique identifier for
> a certain binary.  So you can match up a core-dump with its debug info for
> example.
> 
> But I am unsure if anyone in the firmware space is actively using this
> feature... At least U-Boot does not actually include the build-id on the
> target - it is not generated for SPL at all and U-Boot proper only
> contains it in the ELF file, it is not exported into the raw binary.

This is the origin of --build-id:

https://fedoraproject.org/wiki/Releases/FeatureBuildId

-- 
Harald

Re: [PATCH u-boot v2 00/38] U-Boot LTO (Sandbox + Some ARM boards)

[Harald Seiler]

On Fri, 2021-03-12 at 15:26 +0100, Marek Behun wrote:
> On Fri, 12 Mar 2021 15:21:05 +0100
> Harald Seiler  wrote:
> 
> > Hi Marek,
> > 
> > On Fri, 2021-03-12 at 11:33 +0100, Marek Behún wrote:
> > > Hello,
> > > 
> > > I am sending version 2 of patches adding support for LTO to U-Boot.
> > > 
> > > This series was tested by Github/Azure CI at
> > >   https://github.com/u-boot/u-boot/pull/57
> > > 
> > > Code reduction is on average 4.23% for u-boot.bin and 13.58% for
> > > u-boot-spl.bin.
> > > 
> > > I am currently running a build test for all 1077 ARM defconfigs.
> > > Of the first 232 defconfigs, 2 are failing when LTO is enabled
> > > (chromebook_jerry and chromebook_speedy). Note that this series
> > > only enables LTO for tested boards.
> > > 
> > > Changes since v1:
> > > - remove patches applied into u-boot-marvell
> > > - added Reviewed-by tags
> > > - addressed some issues discovered by Bin Meng, Marek Vasut,
> > >   Heinrich Schuchardt
> > > - added more ARM boards (thanks to Adam Ford, Tim Harvey and Bin Meng)
> > > - removed --gc-sections for ARM if internal libgcc is used
> > > - remove -fwhole-program in final LTO LDFLAGS
> > > - declared all 4 functions (memcpy, memset, memcmp, memmove) __used,
> > >   (these are mentioned in GCC man page for option -nodefaultlibs that
> > >    the compiler may generate; this seems to be a bug in GCC that linking
> > >    fails with LTO even if these functions are present, because the
> > >    symbols can be renamed on some targets by optimization)  
> > 
> > I'm hitting a compiler error when building with imx6q_logic_defconfig:
> > 
> >   real-ld: error: no memory region specified for loadable section 
> > `.note.gnu.build-id'
> > 
> > It seems this is caused by calling the linker through a gcc invocation
> > which adds a `--build-id` commandline flag.  I think the linker script
> > which is used for SPL in this case (arch/arm/mach-omap2/u-boot-spl.lds)
> > isn't properly set up to deal with a build-id.
> > 
> > I'm not sure how to deal with this.  One could either add
> > `--build-id=none` to the GCC commandline to suppress generation of this
> > section entirely (it is not emitted in non-LTO builds right now anyway) or
> > include it in .text in said linker script so it is visible on the target.
> > What do you think?
> > 
> > I should note that I am using a Yocto-generated toolchain.  I suppose most
> > standard toolchains' behavior regarding the `--build-id` flag probably
> > differs.
> > 
> > Regards,
> 
> I encountered this with Debian's cross toolchain, but since this did
> not happen on my station with Gentoo crossdev toolchain, nor on Azure
> CI, I ignored it.
> 
> What is the purpose of --build-id? Why do people use it?

I'm not entirely sure but I think it acts as a unique identifier for
a certain binary.  So you can match up a core-dump with its debug info for
example.

But I am unsure if anyone in the firmware space is actively using this
feature... At least U-Boot does not actually include the build-id on the
target - it is not generated for SPL at all and U-Boot proper only
contains it in the ELF file, it is not exported into the raw binary.

-- 
Harald

Re: [PATCH u-boot v2 00/38] U-Boot LTO (Sandbox + Some ARM boards)

[Marek Behun]

On Fri, 12 Mar 2021 15:21:05 +0100
Harald Seiler  wrote:

> Hi Marek,
> 
> On Fri, 2021-03-12 at 11:33 +0100, Marek Behún wrote:
> > Hello,
> > 
> > I am sending version 2 of patches adding support for LTO to U-Boot.
> > 
> > This series was tested by Github/Azure CI at
> >   https://github.com/u-boot/u-boot/pull/57
> > 
> > Code reduction is on average 4.23% for u-boot.bin and 13.58% for
> > u-boot-spl.bin.
> > 
> > I am currently running a build test for all 1077 ARM defconfigs.
> > Of the first 232 defconfigs, 2 are failing when LTO is enabled
> > (chromebook_jerry and chromebook_speedy). Note that this series
> > only enables LTO for tested boards.
> > 
> > Changes since v1:
> > - remove patches applied into u-boot-marvell
> > - added Reviewed-by tags
> > - addressed some issues discovered by Bin Meng, Marek Vasut,
> >   Heinrich Schuchardt
> > - added more ARM boards (thanks to Adam Ford, Tim Harvey and Bin Meng)
> > - removed --gc-sections for ARM if internal libgcc is used
> > - remove -fwhole-program in final LTO LDFLAGS
> > - declared all 4 functions (memcpy, memset, memcmp, memmove) __used,
> >   (these are mentioned in GCC man page for option -nodefaultlibs that
> >    the compiler may generate; this seems to be a bug in GCC that linking
> >    fails with LTO even if these functions are present, because the
> >    symbols can be renamed on some targets by optimization)  
> 
> I'm hitting a compiler error when building with imx6q_logic_defconfig:
> 
>   real-ld: error: no memory region specified for loadable section 
> `.note.gnu.build-id'
> 
> It seems this is caused by calling the linker through a gcc invocation
> which adds a `--build-id` commandline flag.  I think the linker script
> which is used for SPL in this case (arch/arm/mach-omap2/u-boot-spl.lds)
> isn't properly set up to deal with a build-id.
> 
> I'm not sure how to deal with this.  One could either add
> `--build-id=none` to the GCC commandline to suppress generation of this
> section entirely (it is not emitted in non-LTO builds right now anyway) or
> include it in .text in said linker script so it is visible on the target.
> What do you think?
> 
> I should note that I am using a Yocto-generated toolchain.  I suppose most
> standard toolchains' behavior regarding the `--build-id` flag probably
> differs.
> 
> Regards,

I encountered this with Debian's cross toolchain, but since this did
not happen on my station with Gentoo crossdev toolchain, nor on Azure
CI, I ignored it.

What is the purpose of --build-id? Why do people use it?

Marek

Re: [PATCH u-boot v2 00/38] U-Boot LTO (Sandbox + Some ARM boards)

[Harald Seiler]

Hi Marek,

On Fri, 2021-03-12 at 11:33 +0100, Marek Behún wrote:
> Hello,
> 
> I am sending version 2 of patches adding support for LTO to U-Boot.
> 
> This series was tested by Github/Azure CI at
>   https://github.com/u-boot/u-boot/pull/57
> 
> Code reduction is on average 4.23% for u-boot.bin and 13.58% for
> u-boot-spl.bin.
> 
> I am currently running a build test for all 1077 ARM defconfigs.
> Of the first 232 defconfigs, 2 are failing when LTO is enabled
> (chromebook_jerry and chromebook_speedy). Note that this series
> only enables LTO for tested boards.
> 
> Changes since v1:
> - remove patches applied into u-boot-marvell
> - added Reviewed-by tags
> - addressed some issues discovered by Bin Meng, Marek Vasut,
>   Heinrich Schuchardt
> - added more ARM boards (thanks to Adam Ford, Tim Harvey and Bin Meng)
> - removed --gc-sections for ARM if internal libgcc is used
> - remove -fwhole-program in final LTO LDFLAGS
> - declared all 4 functions (memcpy, memset, memcmp, memmove) __used,
>   (these are mentioned in GCC man page for option -nodefaultlibs that
>    the compiler may generate; this seems to be a bug in GCC that linking
>    fails with LTO even if these functions are present, because the
>    symbols can be renamed on some targets by optimization)

I'm hitting a compiler error when building with imx6q_logic_defconfig:

  real-ld: error: no memory region specified for loadable section 
`.note.gnu.build-id'

It seems this is caused by calling the linker through a gcc invocation
which adds a `--build-id` commandline flag.  I think the linker script
which is used for SPL in this case (arch/arm/mach-omap2/u-boot-spl.lds)
isn't properly set up to deal with a build-id.

I'm not sure how to deal with this.  One could either add
`--build-id=none` to the GCC commandline to suppress generation of this
section entirely (it is not emitted in non-LTO builds right now anyway) or
include it in .text in said linker script so it is visible on the target.
What do you think?

I should note that I am using a Yocto-generated toolchain.  I suppose most
standard toolchains' behavior regarding the `--build-id` flag probably
differs.

Regards,
-- 
Harald

Re: [PATCH v2 07/21] net: phy: xilinx: Be compatible with live OF tree

[Michal Simek]

+Karthik/Ashok

On 3/12/21 2:35 PM, Bin Meng wrote:
> Following the same updates that were done to the fixed phy driver,
> use ofnode_ APIs instead of fdt_ APIs so that the Xilinx PHY driver
> can support live DT.
> 
> Signed-off-by: Bin Meng 
> 
> ---
> 
> Changes in v2:
> - move device tree parsing from xilinxgmiitorgmii_probe() to
>   xilinxgmiitorgmii_config() and use OF APIs
> 
>  drivers/net/phy/phy.c   | 23 +--
>  drivers/net/phy/xilinx_gmii2rgmii.c | 61 ++---
>  2 files changed, 40 insertions(+), 44 deletions(-)
> 
> diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
> index eae40cc0d6..d464379121 100644
> --- a/drivers/net/phy/phy.c
> +++ b/drivers/net/phy/phy.c
> @@ -953,23 +953,20 @@ static struct phy_device *phy_connect_gmii2rgmii(struct 
> mii_dev *bus,
>  #endif
>  {
>   struct phy_device *phydev = NULL;
> - int sn = dev_of_offset(dev);
> - int off;
> -
> - while (sn > 0) {
> - off = fdt_node_offset_by_compatible(gd->fdt_blob, sn,
> - "xlnx,gmii-to-rgmii-1.0");
> - if (off > 0) {
> - phydev = phy_device_create(bus, off,
> + ofnode node = dev_ofnode(dev);
> +
> + while (ofnode_valid(node)) {
> + node = ofnode_by_compatible(node, "xlnx,gmii-to-rgmii-1.0");
> + if (ofnode_valid(node)) {
> + phydev = phy_device_create(bus, 0,
>  PHY_GMII2RGMII_ID, false,
>  interface);
> + if (phydev)
> + phydev->node = node;
>   break;
>   }
> - if (off == -FDT_ERR_NOTFOUND)
> - sn = fdt_first_subnode(gd->fdt_blob, sn);
> - else
> - printf("%s: Error finding compat string:%d\n",
> -__func__, off);
> +
> + node = ofnode_first_subnode(node);
>   }
>  
>   return phydev;
> diff --git a/drivers/net/phy/xilinx_gmii2rgmii.c 
> b/drivers/net/phy/xilinx_gmii2rgmii.c
> index 74105c0b7d..635c0570ef 100644
> --- a/drivers/net/phy/xilinx_gmii2rgmii.c
> +++ b/drivers/net/phy/xilinx_gmii2rgmii.c
> @@ -18,9 +18,38 @@ DECLARE_GLOBAL_DATA_PTR;
>  
>  static int xilinxgmiitorgmii_config(struct phy_device *phydev)
>  {
> - struct phy_device *ext_phydev = phydev->priv;
> + ofnode node = phy_get_ofnode(phydev);
> + struct phy_device *ext_phydev;
> + struct ofnode_phandle_args phandle;
> + int ext_phyaddr = -1;
> + int ret;
>  
>   debug("%s\n", __func__);
> +
> + if (!ofnode_valid(node))
> + return -EINVAL;
> +
> + phydev->addr = ofnode_read_u32_default(node, "reg", -1);
> + ret = ofnode_parse_phandle_with_args(node, "phy-handle",
> +  NULL, 0, 0, );
> + if (ret)
> + return ret;
> +
> + ext_phyaddr = ofnode_read_u32_default(phandle.node, "reg", -1);
> + ext_phydev = phy_find_by_mask(phydev->bus,
> +   1 << ext_phyaddr,
> +   PHY_INTERFACE_MODE_RGMII);
> + if (!ext_phydev) {
> + printf("%s, No external phy device found\n", __func__);
> + return -EINVAL;
> + }
> +
> + ext_phydev->node = phandle.node;
> + phydev->priv = ext_phydev;
> +
> + debug("%s, gmii2rgmmi:0x%x, extphy:0x%x\n", __func__, phydev->addr,
> +   ext_phyaddr);
> +
>   if (ext_phydev->drv->config)
>   ext_phydev->drv->config(ext_phydev);
>  
> @@ -83,11 +112,6 @@ static int xilinxgmiitorgmii_startup(struct phy_device 
> *phydev)
>  
>  static int xilinxgmiitorgmii_probe(struct phy_device *phydev)
>  {
> - int ofnode = phydev->addr;
> - u32 phy_of_handle;
> - int ext_phyaddr = -1;
> - struct phy_device *ext_phydev;
> -
>   debug("%s\n", __func__);
>  
>   if (phydev->interface != PHY_INTERFACE_MODE_GMII) {
> @@ -95,31 +119,6 @@ static int xilinxgmiitorgmii_probe(struct phy_device 
> *phydev)
>   return -EINVAL;
>   }
>  
> - /*
> -  * Read the phy address again as the one we read in ethernet driver
> -  * was overwritten for the purpose of storing the ofnode
> -  */
> - phydev->addr = fdtdec_get_int(gd->fdt_blob, ofnode, "reg", -1);
> - phy_of_handle = fdtdec_lookup_phandle(gd->fdt_blob, ofnode,
> -   "phy-handle");
> - if (phy_of_handle > 0)
> - ext_phyaddr = fdtdec_get_int(gd->fdt_blob,
> -  phy_of_handle,
> -  "reg", -1);
> - ext_phydev = phy_find_by_mask(phydev->bus,
> -   1 << ext_phyaddr,
> -   PHY_INTERFACE_MODE_RGMII);
> - if (!ext_phydev) {
> - 

[PATCH] spi: zynqmp_gqspi: Simplify baud_rate_val calculation

[Michal Simek]

Condition to setup GQSPI_DFLT_BAUD_RATE_VAL(number 2) in case when
baud_rate_val is more then 7 is wrong. There should be really the biggest
possible value which is 7. This can be achieve in easier way by enabling
calculation till GQSPI_MAX_BAUD_RATE_VAL.

Signed-off-by: Michal Simek 
---

 drivers/spi/zynqmp_gqspi.c | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/drivers/spi/zynqmp_gqspi.c b/drivers/spi/zynqmp_gqspi.c
index f8d13d193e30..900cb2610c7f 100644
--- a/drivers/spi/zynqmp_gqspi.c
+++ b/drivers/spi/zynqmp_gqspi.c
@@ -324,14 +324,10 @@ static int zynqmp_qspi_set_speed(struct udevice *bus, 
uint speed)
if (plat->speed_hz != speed) {
/* Set the clock frequency */
/* If speed == 0, default to lowest speed */
-   while ((baud_rate_val < 8) &&
-  ((plat->frequency /
-  (2 << baud_rate_val)) > speed))
+   while (baud_rate_val < GQSPI_MAX_BAUD_RATE_VAL &&
+  (plat->frequency / (2 << baud_rate_val)) > speed)
baud_rate_val++;
 
-   if (baud_rate_val > GQSPI_MAX_BAUD_RATE_VAL)
-   baud_rate_val = GQSPI_DFLT_BAUD_RATE_VAL;
-
plat->speed_hz = plat->frequency / (2 << baud_rate_val);
 
confr = readl(>confr);
-- 
2.30.1

Re: [PATCH u-boot 37/39] ARM: don't use -ffunction-sections/-fdata-sections with LTO build

[Tom Rini]

On Fri, Mar 12, 2021 at 02:44:19PM +0100, Marek Behun wrote:
> On Fri, 12 Mar 2021 08:18:44 -0500
> Tom Rini  wrote:
> 
> > On Fri, Mar 12, 2021 at 08:29:05AM +0100, Marek Behun wrote:
> > > On Fri, 12 Mar 2021 15:19:26 +0800
> > > Bin Meng  wrote:
> > >   
> > > > On Fri, Mar 12, 2021 at 3:11 PM Marek Behun  wrote: 
> > > >  
> > > > >
> > > > > On Fri, 12 Mar 2021 14:48:04 +0800
> > > > > Bin Meng  wrote:
> > > > >
> > > > > > On Fri, Mar 12, 2021 at 2:45 PM Marek Behun  
> > > > > > wrote:
> > > > > > >
> > > > > > > On Wed, 10 Mar 2021 11:40:42 +0800
> > > > > > > Bin Meng  wrote:
> > > > > > >
> > > > > > > > On Sun, Mar 7, 2021 at 12:26 PM Marek Behún 
> > > > > > > >  wrote:
> > > > > > > > >
> > > > > > > > > When building with LTO, using 
> > > > > > > > > -ffunction-sections/-fdata-sections is not
> > > > > > > > > useful anymore.
> > > > > > > > >
> > > > > > > > > Signed-off-by: Marek Behún 
> > > > > > > > > ---
> > > > > > > > >  arch/arm/config.mk | 8 ++--
> > > > > > > > >  1 file changed, 6 insertions(+), 2 deletions(-)
> > > > > > > > >
> > > > > > > >
> > > > > > > > I believe we should also remove --gc-sections.
> > > > > > >
> > > > > > > It seems that --gc-sections cannot be removed, otherwise some 
> > > > > > > builds,
> > > > > > > for example turris_mox_defconfig, fail with
> > > > > > >
> > > > > > >   LTO u-boot
> > > > > > > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: 
> > > > > > > /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(lse-init.o):
> > > > > > >  in function `init_have_lse_atomics':
> > > > > > > /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/config/aarch64/lse-init.c:44:
> > > > > > >  undefined reference to `__getauxval'
> > > > > > > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: 
> > > > > > > /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(_absvsi2.o):
> > > > > > >  in function `__absvdi2':
> > > > > > > /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:228:
> > > > > > >  undefined reference to `abort'
> > > > > > > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: 
> > > > > > > /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(_absvsi2.o):
> > > > > > >  in function `__absvsi2':
> > > > > > > /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:246:
> > > > > > >  undefined reference to `abort'
> > > > > > > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: 
> > > > > > > /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(_absvdi2.o):
> > > > > > >  in function `__absvti2':
> > > > > > > /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:267:
> > > > > > >  undefined reference to `abort'
> > > > > > > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: 
> > > > > > > /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(_addvsi3.o):
> > > > > > >  in function `__addvdi3':
> > > > > > > /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:81:
> > > > > > >  undefined reference to `abort'
> > > > > > > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: 
> > > > > > > /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(_addvsi3.o):
> > > > > > >  in function `__addvsi3':
> > > > > > > /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:92:
> > > > > > >  undefined reference to `abort'
> > > > > > > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: 
> > > > > > > /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(_addvdi3.o):/var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:106:
> > > > > > >  more undefined references to `abort' follow
> > > > > > > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: 
> > > > > > > /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(_eprintf.o):
> > > > > > >  in function `__eprintf':
> > > > > > > /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:2152:
> > > > > > >  undefined reference to `stderr'
> > > > > > > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: 
> > > > > > > /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:2152:
> > > > > > >  undefined reference to `stderr'
> > > > > > > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: 
> > > > > > > /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(_eprintf.o):
> > > > > > >  in function `fprintf':
> > > > > > > /usr/aarch64-unknown-linux-gnu/sys-include/bits/stdio2.h:103: 
> > > > > > > undefined reference to `__fprintf_chk'
> > > > > > > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: 
> > > > > > > /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(_eprintf.o):
> > > > > > >  in function `__eprintf':
> > > > > > > /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:2153:
> > > > > > >  

[PATCH u-boot v2.1 38/38] ARM: enable LTO for some boards

[Marek Behún]

Enable LTO for some boards that were tested by people on U-Boot Mailing
List.

Signed-off-by: Marek Behún 
Tested-by: Adam Ford 
Tested-by: Pali Rohár 
Tested-by: Tim Harvey 
---
 configs/am3517_evm_defconfig  | 1 +
 configs/da850evm_defconfig| 1 +
 configs/da850evm_direct_nor_defconfig | 1 +
 configs/da850evm_nand_defconfig   | 1 +
 configs/imx6q_logic_defconfig | 1 +
 configs/imx8mm_beacon_defconfig   | 1 +
 configs/imx8mm_venice_defconfig   | 1 +
 configs/imx8mn_beacon_2g_defconfig| 1 +
 configs/imx8mn_beacon_defconfig   | 1 +
 configs/nokia_rx51_defconfig  | 1 +
 configs/omap3_logic_defconfig | 1 +
 configs/r8a774a1_beacon_defconfig | 1 +
 configs/r8a774b1_beacon_defconfig | 1 +
 configs/r8a774e1_beacon_defconfig | 1 +
 configs/turris_mox_defconfig  | 1 +
 configs/turris_omnia_defconfig| 1 +
 16 files changed, 16 insertions(+)

diff --git a/configs/am3517_evm_defconfig b/configs/am3517_evm_defconfig
index bae0e0af35..d61eec94a4 100644
--- a/configs/am3517_evm_defconfig
+++ b/configs/am3517_evm_defconfig
@@ -1,3 +1,4 @@
+CONFIG_LTO=y
 CONFIG_ARM=y
 # CONFIG_SPL_USE_ARCH_MEMCPY is not set
 # CONFIG_SPL_USE_ARCH_MEMSET is not set
diff --git a/configs/da850evm_defconfig b/configs/da850evm_defconfig
index 26e76a2929..6ff5e21bc6 100644
--- a/configs/da850evm_defconfig
+++ b/configs/da850evm_defconfig
@@ -1,3 +1,4 @@
+CONFIG_LTO=y
 CONFIG_ARM=y
 CONFIG_SYS_THUMB_BUILD=y
 CONFIG_ARCH_DAVINCI=y
diff --git a/configs/da850evm_direct_nor_defconfig 
b/configs/da850evm_direct_nor_defconfig
index d3860a963d..06c7ce7c47 100644
--- a/configs/da850evm_direct_nor_defconfig
+++ b/configs/da850evm_direct_nor_defconfig
@@ -1,3 +1,4 @@
+CONFIG_LTO=y
 CONFIG_ARM=y
 CONFIG_ARCH_CPU_INIT=y
 CONFIG_ARCH_DAVINCI=y
diff --git a/configs/da850evm_nand_defconfig b/configs/da850evm_nand_defconfig
index 0d0e9a148d..be737564e1 100644
--- a/configs/da850evm_nand_defconfig
+++ b/configs/da850evm_nand_defconfig
@@ -1,3 +1,4 @@
+CONFIG_LTO=y
 CONFIG_ARM=y
 CONFIG_SYS_THUMB_BUILD=y
 CONFIG_ARCH_DAVINCI=y
diff --git a/configs/imx6q_logic_defconfig b/configs/imx6q_logic_defconfig
index 36dc24d080..0f8aea6983 100644
--- a/configs/imx6q_logic_defconfig
+++ b/configs/imx6q_logic_defconfig
@@ -1,3 +1,4 @@
+CONFIG_LTO=y
 CONFIG_ARM=y
 CONFIG_ARCH_MX6=y
 CONFIG_SYS_TEXT_BASE=0x1780
diff --git a/configs/imx8mm_beacon_defconfig b/configs/imx8mm_beacon_defconfig
index 045b19f4f3..e8bb44eea6 100644
--- a/configs/imx8mm_beacon_defconfig
+++ b/configs/imx8mm_beacon_defconfig
@@ -1,3 +1,4 @@
+CONFIG_LTO=y
 CONFIG_ARM=y
 CONFIG_ARCH_IMX8M=y
 CONFIG_SYS_TEXT_BASE=0x4020
diff --git a/configs/imx8mm_venice_defconfig b/configs/imx8mm_venice_defconfig
index a15c3641f6..dff8f64540 100644
--- a/configs/imx8mm_venice_defconfig
+++ b/configs/imx8mm_venice_defconfig
@@ -1,3 +1,4 @@
+CONFIG_LTO=y
 CONFIG_ARM=y
 CONFIG_ARCH_IMX8M=y
 CONFIG_SYS_TEXT_BASE=0x4020
diff --git a/configs/imx8mn_beacon_2g_defconfig 
b/configs/imx8mn_beacon_2g_defconfig
index 58b8e49486..1c8cbc2c89 100644
--- a/configs/imx8mn_beacon_2g_defconfig
+++ b/configs/imx8mn_beacon_2g_defconfig
@@ -1,3 +1,4 @@
+CONFIG_LTO=y
 CONFIG_ARM=y
 CONFIG_ARCH_IMX8M=y
 CONFIG_SYS_TEXT_BASE=0x4020
diff --git a/configs/imx8mn_beacon_defconfig b/configs/imx8mn_beacon_defconfig
index d6a3385d8d..6457b9409a 100644
--- a/configs/imx8mn_beacon_defconfig
+++ b/configs/imx8mn_beacon_defconfig
@@ -1,3 +1,4 @@
+CONFIG_LTO=y
 CONFIG_ARM=y
 CONFIG_ARCH_IMX8M=y
 CONFIG_SYS_TEXT_BASE=0x4020
diff --git a/configs/nokia_rx51_defconfig b/configs/nokia_rx51_defconfig
index 312ca3a1a9..85ca627790 100644
--- a/configs/nokia_rx51_defconfig
+++ b/configs/nokia_rx51_defconfig
@@ -1,3 +1,4 @@
+CONFIG_LTO=y
 CONFIG_ARM=y
 # CONFIG_SYS_THUMB_BUILD is not set
 CONFIG_ARCH_OMAP2PLUS=y
diff --git a/configs/omap3_logic_defconfig b/configs/omap3_logic_defconfig
index 4e37237b86..cc4b727a2c 100644
--- a/configs/omap3_logic_defconfig
+++ b/configs/omap3_logic_defconfig
@@ -1,3 +1,4 @@
+CONFIG_LTO=y
 CONFIG_ARM=y
 # CONFIG_SPL_USE_ARCH_MEMCPY is not set
 # CONFIG_SPL_USE_ARCH_MEMSET is not set
diff --git a/configs/r8a774a1_beacon_defconfig 
b/configs/r8a774a1_beacon_defconfig
index 2f45edd92e..9dd5d9192e 100644
--- a/configs/r8a774a1_beacon_defconfig
+++ b/configs/r8a774a1_beacon_defconfig
@@ -1,3 +1,4 @@
+CONFIG_LTO=y
 CONFIG_ARM=y
 CONFIG_ARCH_RMOBILE=y
 CONFIG_SYS_TEXT_BASE=0x5000
diff --git a/configs/r8a774b1_beacon_defconfig 
b/configs/r8a774b1_beacon_defconfig
index ca514bb1aa..b7d7f23f5a 100644
--- a/configs/r8a774b1_beacon_defconfig
+++ b/configs/r8a774b1_beacon_defconfig
@@ -1,3 +1,4 @@
+CONFIG_LTO=y
 CONFIG_ARM=y
 CONFIG_ARCH_RMOBILE=y
 CONFIG_SYS_TEXT_BASE=0x5000
diff --git a/configs/r8a774e1_beacon_defconfig 
b/configs/r8a774e1_beacon_defconfig
index b89729d92a..3e44edf29f 100644
--- a/configs/r8a774e1_beacon_defconfig
+++ b/configs/r8a774e1_beacon_defconfig
@@ -1,3 +1,4 @@
+CONFIG_LTO=y
 CONFIG_ARM=y
 

Re: [PATCH u-boot 37/39] ARM: don't use -ffunction-sections/-fdata-sections with LTO build

[Marek Behun]

On Fri, 12 Mar 2021 08:18:44 -0500
Tom Rini  wrote:

> On Fri, Mar 12, 2021 at 08:29:05AM +0100, Marek Behun wrote:
> > On Fri, 12 Mar 2021 15:19:26 +0800
> > Bin Meng  wrote:
> >   
> > > On Fri, Mar 12, 2021 at 3:11 PM Marek Behun  wrote:  
> > > >
> > > > On Fri, 12 Mar 2021 14:48:04 +0800
> > > > Bin Meng  wrote:
> > > >
> > > > > On Fri, Mar 12, 2021 at 2:45 PM Marek Behun  
> > > > > wrote:
> > > > > >
> > > > > > On Wed, 10 Mar 2021 11:40:42 +0800
> > > > > > Bin Meng  wrote:
> > > > > >
> > > > > > > On Sun, Mar 7, 2021 at 12:26 PM Marek Behún  
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > When building with LTO, using 
> > > > > > > > -ffunction-sections/-fdata-sections is not
> > > > > > > > useful anymore.
> > > > > > > >
> > > > > > > > Signed-off-by: Marek Behún 
> > > > > > > > ---
> > > > > > > >  arch/arm/config.mk | 8 ++--
> > > > > > > >  1 file changed, 6 insertions(+), 2 deletions(-)
> > > > > > > >
> > > > > > >
> > > > > > > I believe we should also remove --gc-sections.
> > > > > >
> > > > > > It seems that --gc-sections cannot be removed, otherwise some 
> > > > > > builds,
> > > > > > for example turris_mox_defconfig, fail with
> > > > > >
> > > > > >   LTO u-boot
> > > > > > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: 
> > > > > > /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(lse-init.o): 
> > > > > > in function `init_have_lse_atomics':
> > > > > > /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/config/aarch64/lse-init.c:44:
> > > > > >  undefined reference to `__getauxval'
> > > > > > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: 
> > > > > > /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(_absvsi2.o): 
> > > > > > in function `__absvdi2':
> > > > > > /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:228:
> > > > > >  undefined reference to `abort'
> > > > > > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: 
> > > > > > /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(_absvsi2.o): 
> > > > > > in function `__absvsi2':
> > > > > > /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:246:
> > > > > >  undefined reference to `abort'
> > > > > > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: 
> > > > > > /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(_absvdi2.o): 
> > > > > > in function `__absvti2':
> > > > > > /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:267:
> > > > > >  undefined reference to `abort'
> > > > > > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: 
> > > > > > /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(_addvsi3.o): 
> > > > > > in function `__addvdi3':
> > > > > > /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:81:
> > > > > >  undefined reference to `abort'
> > > > > > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: 
> > > > > > /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(_addvsi3.o): 
> > > > > > in function `__addvsi3':
> > > > > > /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:92:
> > > > > >  undefined reference to `abort'
> > > > > > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: 
> > > > > > /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(_addvdi3.o):/var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:106:
> > > > > >  more undefined references to `abort' follow
> > > > > > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: 
> > > > > > /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(_eprintf.o): 
> > > > > > in function `__eprintf':
> > > > > > /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:2152:
> > > > > >  undefined reference to `stderr'
> > > > > > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: 
> > > > > > /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:2152:
> > > > > >  undefined reference to `stderr'
> > > > > > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: 
> > > > > > /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(_eprintf.o): 
> > > > > > in function `fprintf':
> > > > > > /usr/aarch64-unknown-linux-gnu/sys-include/bits/stdio2.h:103: 
> > > > > > undefined reference to `__fprintf_chk'
> > > > > > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: 
> > > > > > /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(_eprintf.o): 
> > > > > > in function `__eprintf':
> > > > > > /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:2153:
> > > > > >  undefined reference to `fflush'
> > > > > > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: 
> > > > > > /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:2154:
> > > > > >  undefined reference to `abort' 

Re: [PATCH u-boot v2 32/38] ARM: omap3: fix LTO for DM3730 (and possibly other omap3 boards)

[Adam Ford]

On Fri, Mar 12, 2021 at 4:35 AM Marek Behún  wrote:
>
> Adam Ford says that DM3730 needs board.c compiled without LTO flags.
>
> Also add clock.c, since it says in Makefile that it need different
> flags.
>

Tested-by: Adam Ford  #omap3_logic

> Signed-off-by: Marek Behún 
> Suggested-by: Adam Ford 
> ---
>  arch/arm/mach-omap2/omap3/Makefile | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm/mach-omap2/omap3/Makefile 
> b/arch/arm/mach-omap2/omap3/Makefile
> index 91ed8ebc9f..7d22f04bbf 100644
> --- a/arch/arm/mach-omap2/omap3/Makefile
> +++ b/arch/arm/mach-omap2/omap3/Makefile
> @@ -5,10 +5,12 @@
>
>  # If clock.c is compiled for Thumb2, then it fails on OMAP3530
>  CFLAGS_clock.o += -marm
> +CFLAGS_REMOVE_clock.o := $(LTO_CFLAGS)

I have two OMAP3530 boards.  I'll test that this weekend.  I think I
even have them configured for Thumb2

adam

>
>  obj-y  := lowlevel_init.o
>
>  obj-y  += board.o
> +CFLAGS_REMOVE_board.o := $(LTO_CFLAGS)
>  obj-y  += boot.o
>  obj-y  += clock.o
>  obj-y  += sys_info.o
> --
> 2.26.2
>

[PATCH v2 21/21] doc: board: qemu-ppce500: Document eTSEC usage

[Bin Meng]

Document how to launch a QEMU session with eTSEC as a network device.

Signed-off-by: Bin Meng 

---

(no changes since v1)

 doc/board/emulation/qemu-ppce500.rst | 5 +
 1 file changed, 5 insertions(+)

diff --git a/doc/board/emulation/qemu-ppce500.rst 
b/doc/board/emulation/qemu-ppce500.rst
index 0a5c86c61a..5de0aaf55d 100644
--- a/doc/board/emulation/qemu-ppce500.rst
+++ b/doc/board/emulation/qemu-ppce500.rst
@@ -70,6 +70,11 @@ interface at PCI address 0.1.0, but we can switch that to an 
e1000 NIC by::
 $ qemu-system-ppc -nographic -machine ppce500 -bios u-boot \
   -nic tap,ifname=tap0,script=no,downscript=no,model=e1000
 
+The QEMU ppce500 machine can also dynamically instantiate an eTSEC device if
+"-device eTSEC" is given to QEMU::
+
+-netdev tap,ifname=tap0,script=no,downscript=no,id=net0 -device 
eTSEC,netdev=net0
+
 VirtIO BLK driver is also enabled to support booting from a disk image where
 a kernel image is stored. Append the following to QEMU::
 
-- 
2.25.1

[PATCH v2 20/21] ppc: qemu: Enable eTSEC support

[Bin Meng]

QEMU ppce500 target can dynamically instantiate an eTSEC device
if "-device eTSEC" is given to QEMU. This commit enables eTSEC
driver and the required fixed PHY driver to create a usable
network configuration using eTSEC.

Unlike a real world 85xx board that usually stores the eTSEC MAC
address in an EEPROM, CONFIG_NET_RANDOM_ETHADDR is required for
QEMU otherwise U-Boot ethernet initialization complains no valid
ethernet address is set.

Signed-off-by: Bin Meng 
---

(no changes since v1)

 configs/qemu-ppce500_defconfig | 4 
 1 file changed, 4 insertions(+)

diff --git a/configs/qemu-ppce500_defconfig b/configs/qemu-ppce500_defconfig
index 151834b4cf..a1b9ea56ca 100644
--- a/configs/qemu-ppce500_defconfig
+++ b/configs/qemu-ppce500_defconfig
@@ -27,6 +27,7 @@ CONFIG_OF_CONTROL=y
 CONFIG_OF_BOARD=y
 CONFIG_ENV_OVERWRITE=y
 CONFIG_SYS_RELOC_GD_ENV_ADDR=y
+CONFIG_NET_RANDOM_ETHADDR=y
 CONFIG_DM=y
 CONFIG_SIMPLE_BUS_CORRECT_RANGE=y
 CONFIG_BLK=y
@@ -35,8 +36,11 @@ CONFIG_MPC8XXX_GPIO=y
 CONFIG_DM_I2C=y
 CONFIG_SYS_I2C_FSL=y
 # CONFIG_MMC is not set
+CONFIG_PHY_FIXED=y
 CONFIG_DM_ETH=y
+CONFIG_DM_MDIO=y
 CONFIG_E1000=y
+CONFIG_TSEC_ENET=y
 CONFIG_DM_PCI=y
 CONFIG_PCI_MPC85XX=y
 CONFIG_DM_RTC=y
-- 
2.25.1

[PATCH v2 19/21] ppc: qemu: Create a virtual memory mapping of the platform bus

[Bin Meng]

QEMU ppce500 target can dynamically instantiate an eTSEC device on
a platform bus if "-device eTSEC" is given to QEMU. It is presented
as a "simple-bus" in the device tree, with an additional compatible
string "qemu,platform".

Let's create a virtual memory mapping for it in misc_init_r(), in
preparation to adding eTSEC support.

Signed-off-by: Bin Meng 

---

Changes in v2:
- turn on CONFIG_SIMPLE_BUS_CORRECT_RANGE in qemu-ppce500_defconfig

 board/emulation/qemu-ppce500/Kconfig|  6 ++
 board/emulation/qemu-ppce500/qemu-ppce500.c | 18 ++
 configs/qemu-ppce500_defconfig  |  1 +
 3 files changed, 25 insertions(+)

diff --git a/board/emulation/qemu-ppce500/Kconfig 
b/board/emulation/qemu-ppce500/Kconfig
index 4312d986d8..1c5aa18aa9 100644
--- a/board/emulation/qemu-ppce500/Kconfig
+++ b/board/emulation/qemu-ppce500/Kconfig
@@ -9,4 +9,10 @@ config SYS_VENDOR
 config SYS_CONFIG_NAME
default "qemu-ppce500"
 
+config PLATFORM_BUS_MAP_ADDR
+   hex
+   default 0xf000
+   help
+ The QEMU platform bus base mapped address in the virtual memory space.
+
 endif
diff --git a/board/emulation/qemu-ppce500/qemu-ppce500.c 
b/board/emulation/qemu-ppce500/qemu-ppce500.c
index daa103c564..0960dd1f97 100644
--- a/board/emulation/qemu-ppce500/qemu-ppce500.c
+++ b/board/emulation/qemu-ppce500/qemu-ppce500.c
@@ -14,6 +14,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -148,6 +150,22 @@ int misc_init_r(void)
 */
disable_tlb(find_tlb_idx((void *)CONFIG_SYS_TMPVIRT, 1));
 
+   /*
+* Detect the presence of the platform bus node, and
+* create a virtual memory mapping for it.
+*/
+   for (ret = uclass_find_first_device(UCLASS_SIMPLE_BUS, );
+dev;
+ret = uclass_find_next_device()) {
+   if (device_is_compatible(dev, "qemu,platform")) {
+   struct simple_bus_plat *plat = dev_get_uclass_plat(dev);
+
+   assert(!tlb_map_range(CONFIG_PLATFORM_BUS_MAP_ADDR,
+ plat->target, plat->size,
+ TLB_MAP_IO));
+   }
+   }
+
return 0;
 }
 
diff --git a/configs/qemu-ppce500_defconfig b/configs/qemu-ppce500_defconfig
index 536fe7d6e1..151834b4cf 100644
--- a/configs/qemu-ppce500_defconfig
+++ b/configs/qemu-ppce500_defconfig
@@ -28,6 +28,7 @@ CONFIG_OF_BOARD=y
 CONFIG_ENV_OVERWRITE=y
 CONFIG_SYS_RELOC_GD_ENV_ADDR=y
 CONFIG_DM=y
+CONFIG_SIMPLE_BUS_CORRECT_RANGE=y
 CONFIG_BLK=y
 CONFIG_HAVE_BLOCK_DEVICE=y
 CONFIG_MPC8XXX_GPIO=y
-- 
2.25.1

[PATCH v2 18/21] test: dm: Add a test case for simple-bus

[Bin Meng]

This adds a test case to verify reading  of a simple-bus is
working as expected.

Signed-off-by: Bin Meng 
Reviewed-by: Simon Glass 

---

Changes in v2:
- default y if SANDBOX for CONFIG_SIMPLE_BUS_CORRECT_RANGE

 drivers/core/Kconfig |  1 +
 test/dm/Makefile |  1 +
 test/dm/simple-bus.c | 33 +
 3 files changed, 35 insertions(+)
 create mode 100644 test/dm/simple-bus.c

diff --git a/drivers/core/Kconfig b/drivers/core/Kconfig
index c7504edaf8..a7c3120860 100644
--- a/drivers/core/Kconfig
+++ b/drivers/core/Kconfig
@@ -238,6 +238,7 @@ config SPL_SIMPLE_BUS
 config SIMPLE_BUS_CORRECT_RANGE
bool "Decode the 'simple-bus'  by honoring the #address-cells 
and #size-cells"
depends on SIMPLE_BUS
+   default y if SANDBOX
help
  Decoding the 'simple-bus'  by honoring the #address-cells
  and #size-cells of parent/child bus. If unset, #address-cells of
diff --git a/test/dm/Makefile b/test/dm/Makefile
index 1c2fa95f4a..d0d46e7f7e 100644
--- a/test/dm/Makefile
+++ b/test/dm/Makefile
@@ -90,6 +90,7 @@ obj-$(CONFIG_DM_MDIO) += mdio.o
 obj-$(CONFIG_DM_MDIO_MUX) += mdio_mux.o
 obj-$(CONFIG_DM_RNG) += rng.o
 obj-$(CONFIG_CLK_K210_SET_RATE) += k210_pll.o
+obj-$(CONFIG_SIMPLE_BUS) += simple-bus.o
 obj-$(CONFIG_SIMPLE_PM_BUS) += simple-pm-bus.o
 obj-$(CONFIG_RESET_SYSCON) += syscon-reset.o
 obj-$(CONFIG_SCMI_FIRMWARE) += scmi.o
diff --git a/test/dm/simple-bus.c b/test/dm/simple-bus.c
new file mode 100644
index 00..3530b47fac
--- /dev/null
+++ b/test/dm/simple-bus.c
@@ -0,0 +1,33 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2021, Bin Meng 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static int dm_test_simple_bus(struct unit_test_state *uts)
+{
+   struct udevice *dev;
+   struct simple_bus_plat *plat;
+
+   /* locate the dummy device @ translation-test node */
+   ut_assertok(uclass_find_device_by_seq(UCLASS_TEST_DUMMY, 0, ));
+   ut_asserteq_str("dev@0,0", dev->name);
+
+   /* locate the parent node which is a simple-bus */
+   ut_assertnonnull(dev = dev_get_parent(dev));
+   ut_asserteq_str("translation-test@8000", dev->name);
+
+   ut_assertnonnull(plat = dev_get_uclass_plat(dev));
+   ut_asserteq(0, plat->base);
+   ut_asserteq(0x8000, plat->target);
+   ut_asserteq(0x1000, plat->size);
+
+   return 0;
+}
+DM_TEST(dm_test_simple_bus, UT_TESTF_SCAN_FDT | UT_TESTF_FLAT_TREE);
-- 
2.25.1

[PATCH v2 17/21] dm: core: Correctly read of simple-bus

[Bin Meng]

At present we decode simple bus  using the following assumption:

- parent #address-cells 1
- child #address-cells 1
- child #size-cells 1

However this might not always be the case.

Update to use fdt_addr_t and fdt_size_t in 'struct simple_bus_plat', and
use fdt_read_ranges() to correctly decode it according to the actual
parent and child #address-cells / #size-cells under a Kconfig option
CONFIG_SIMPLE_BUS_CORRECT_RANGE which can be turned on for any board
that needs it.

Signed-off-by: Bin Meng 

---

Changes in v2:
- include 
- use a Kconfig option CONFIG_SIMPLE_BUS_CORRECT_RANGE to control the
  new behavior for boards that want this

 drivers/core/Kconfig  | 13 +
 drivers/core/simple-bus.c | 32 +---
 include/dm/simple_bus.h   |  6 +++---
 3 files changed, 41 insertions(+), 10 deletions(-)

diff --git a/drivers/core/Kconfig b/drivers/core/Kconfig
index 1eccac28c6..c7504edaf8 100644
--- a/drivers/core/Kconfig
+++ b/drivers/core/Kconfig
@@ -235,6 +235,19 @@ config SPL_SIMPLE_BUS
  Supports the 'simple-bus' driver, which is used on some systems
  in SPL.
 
+config SIMPLE_BUS_CORRECT_RANGE
+   bool "Decode the 'simple-bus'  by honoring the #address-cells 
and #size-cells"
+   depends on SIMPLE_BUS
+   help
+ Decoding the 'simple-bus'  by honoring the #address-cells
+ and #size-cells of parent/child bus. If unset, #address-cells of
+ parent bus is assumed to be 1, #address-cells and #size-cells of
+ child bus is also assumed to be 1, to save some spaces of using
+ an advanced API to decode the , which benefits SPL image
+ builds that have size limits.
+
+ If you are unsure about this, Say N here.
+
 config SIMPLE_PM_BUS
bool "Support simple-pm-bus driver"
depends on DM && OF_CONTROL && CLK && POWER_DOMAIN
diff --git a/drivers/core/simple-bus.c b/drivers/core/simple-bus.c
index b0c2c20958..18f52d26df 100644
--- a/drivers/core/simple-bus.c
+++ b/drivers/core/simple-bus.c
@@ -4,8 +4,12 @@
  */
 
 #include 
+#include 
 #include 
 #include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
 
 fdt_addr_t simple_bus_translate(struct udevice *dev, fdt_addr_t addr)
 {
@@ -22,16 +26,30 @@ static int simple_bus_post_bind(struct udevice *dev)
 #if CONFIG_IS_ENABLED(OF_PLATDATA)
return 0;
 #else
-   u32 cell[3];
+   struct simple_bus_plat *plat = dev_get_uclass_plat(dev);
int ret;
 
-   ret = dev_read_u32_array(dev, "ranges", cell, ARRAY_SIZE(cell));
-   if (!ret) {
-   struct simple_bus_plat *plat = dev_get_uclass_plat(dev);
+   if (CONFIG_IS_ENABLED(SIMPLE_BUS_CORRECT_RANGE)) {
+   uint64_t caddr, paddr, len;
+
+   /* only read range index 0 */
+   ret = fdt_read_range((void *)gd->fdt_blob, dev_of_offset(dev),
+0, , , );
+   if (!ret) {
+   plat->base = caddr;
+   plat->target = paddr;
+   plat->size = len;
+   }
+   } else {
+   u32 cell[3];
 
-   plat->base = cell[0];
-   plat->target = cell[1];
-   plat->size = cell[2];
+   ret = dev_read_u32_array(dev, "ranges", cell,
+ARRAY_SIZE(cell));
+   if (!ret) {
+   plat->base = cell[0];
+   plat->target = cell[1];
+   plat->size = cell[2];
+   }
}
 
return dm_scan_fdt_dev(dev);
diff --git a/include/dm/simple_bus.h b/include/dm/simple_bus.h
index 4ad4cc4051..b7104013c0 100644
--- a/include/dm/simple_bus.h
+++ b/include/dm/simple_bus.h
@@ -7,9 +7,9 @@
 #define __DM_SIMPLE_BUS_H
 
 struct simple_bus_plat {
-   u32 base;
-   u32 size;
-   u32 target;
+   fdt_addr_t base;
+   fdt_size_t size;
+   fdt_addr_t target;
 };
 
 #endif
-- 
2.25.1

[PATCH v2 16/21] net: tsec: Support property from the subnode "queue-group"

[Bin Meng]

At present the tsec driver uses a non-standard DT bindings to get
its  base / size. The upstream Linux kernel seems to require
the  base / size to be put under a subnode of the eTSEC node
with a name prefix "queue-group". This is not documented in the
kernel DT bindings, but it looks every dtsi file that contains the
eTSEC node was written like this.

This commit updates the tsec driver to handle this case.

Signed-off-by: Bin Meng 
Reviewed-by: Ramon Fried 
---

(no changes since v1)

 drivers/net/tsec.c | 26 --
 1 file changed, 24 insertions(+), 2 deletions(-)

diff --git a/drivers/net/tsec.c b/drivers/net/tsec.c
index f801d020fb..49bed0c1dd 100644
--- a/drivers/net/tsec.c
+++ b/drivers/net/tsec.c
@@ -827,13 +827,35 @@ int tsec_probe(struct udevice *dev)
struct tsec_data *data;
const char *phy_mode;
fdt_addr_t reg;
-   ofnode parent;
+   ofnode parent, child;
int ret;
 
data = (struct tsec_data *)dev_get_driver_data(dev);
 
pdata->iobase = (phys_addr_t)dev_read_addr(dev);
-   priv->regs = dev_remap_addr(dev);
+   if (pdata->iobase != FDT_ADDR_T_NONE) {
+   priv->regs = dev_remap_addr(dev);
+   } else {
+   ofnode_for_each_subnode(child, dev_ofnode(dev)) {
+   if (!strncmp(ofnode_get_name(child), "queue-group",
+strlen("queue-group"))) {
+   reg = ofnode_get_addr(child);
+   if (reg == FDT_ADDR_T_NONE) {
+   printf("No 'reg' property of 
\n");
+   return -ENOENT;
+   }
+   pdata->iobase = reg;
+   priv->regs = map_physmem(pdata->iobase, 0,
+MAP_NOCACHE);
+   break;
+   }
+   }
+
+   if (!ofnode_valid(child)) {
+   printf("No child node for ?\n");
+   return -ENOENT;
+   }
+   }
 
ret = dev_read_phandle_with_args(dev, "tbi-handle", NULL, 0, 0,
 _args);
-- 
2.25.1

[PATCH v2 14/21] sandbox: Add a DSA sandbox driver and unit test

[Bin Meng]

From: Claudiu Manoil 

The DSA sandbox driver is used for unit testing the DSA class code.
It implements a simple 2 port switch plus 1 CPU port, and uses a
very simple tag to identify the ports.

The DSA sandbox device is connected via CPU port to a regular Ethernet
sandbox device, called 'dsa-test-eth, managed by the existing eth
sandbox driver.  The 'dsa-test-eth' is not intended for testing the
eth class code however, but it is used to emulate traffic through the
'lan0' and 'lan1' front pannel switch ports.  To achieve this the dsa
sandbox driver registers a tx handler for the 'dsa-test-eth' device.
The switch ports, labeled as 'lan0' and 'lan1', are also registered
as eth devices by the dsa class code this time.  So pinging through
these switch ports is as easy as:

=> setenv ethact lan0
=> ping 1.2.3.5

Unit tests for the dsa class code were also added.  The 'dsa_probe'
test exercises most API functions from dsa.h.  The 'dsa' unit test
simply exercises ARP/ICMP traffic through the two switch ports,
including tag injection and extraction, with the help of the dsa
sandbox driver.

I took care to minimize the impact on the existing eth unit tests,
though some adjustments needed to be made with the addition of
extra eth interfaces used by the dsa unit tests. The additional eth
interfaces also require MAC addresses, these have been added to the
sandbox default environment.

Signed-off-by: Alex Marginean 
Signed-off-by: Claudiu Manoil 
Reviewed-by: Simon Glass 
Signed-off-by: Vladimir Oltean 
Message-Id: <20210216224804.3355044-5-olte...@gmail.com>
Signed-off-by: Bin Meng 
---

(no changes since v1)

 arch/Kconfig  |   2 +
 arch/sandbox/dts/test.dts |  48 ++
 drivers/net/Kconfig   |   9 ++
 drivers/net/Makefile  |   1 +
 drivers/net/dsa_sandbox.c | 179 ++
 include/configs/sandbox.h |   2 +
 test/dm/Makefile  |   1 +
 test/dm/dsa.c |  82 +
 test/dm/eth.c |  10 +--
 9 files changed, 329 insertions(+), 5 deletions(-)
 create mode 100644 drivers/net/dsa_sandbox.c
 create mode 100644 test/dm/dsa.c

diff --git a/arch/Kconfig b/arch/Kconfig
index 27843cd79c..5672d1df7e 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -160,6 +160,8 @@ config SANDBOX
imply CMD_CLONE
imply SILENT_CONSOLE
imply BOOTARGS_SUBST
+   imply PHY_FIXED
+   imply DM_DSA
 
 config SH
bool "SuperH architecture"
diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
index 995c93c95a..0e3eb63481 100644
--- a/arch/sandbox/dts/test.dts
+++ b/arch/sandbox/dts/test.dts
@@ -15,7 +15,9 @@
aliases {
console = 
eth0 = "/eth@10002000";
+   eth2 = _0;
eth3 = _3;
+   eth4 = _eth0;
eth5 = _5;
gpio1 = _a;
gpio2 = _b;
@@ -478,6 +480,52 @@
fake-host-hwaddr = [00 00 66 44 22 22];
};
 
+   dsa_eth0: dsa-test-eth {
+   compatible = "sandbox,eth";
+   reg = <0x10006000 0x1000>;
+   fake-host-hwaddr = [00 00 66 44 22 66];
+   };
+
+   dsa-test {
+   compatible = "sandbox,dsa";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   swp_0: port@0 {
+   reg = <0>;
+   label = "lan0";
+   phy-mode = "rgmii-rxid";
+
+   fixed-link {
+   speed = <100>;
+   full-duplex;
+   };
+   };
+
+   swp_1: port@1 {
+   reg = <1>;
+   label = "lan1";
+   phy-mode = "rgmii-txid";
+
+   fixed-link {
+   speed = <100>;
+   full-duplex;
+   };
+   };
+
+   port@2 {
+   reg = <2>;
+   ethernet = <_eth0>;
+
+   fixed-link {
+   speed = <1000>;
+   full-duplex;
+   };
+   };
+   };
+   };
+
fixed-link-test1 {
fixed-link {
speed = <1000>;
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 0e84c22b50..f96ee64249 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -78,6 +78,15 @@ config DM_ETH_PHY
help
  Enable driver model for Ethernet Generic PHY .
 
+config DSA_SANDBOX
+   depends on DM_DSA && SANDBOX
+   default y
+   bool "Sandbox: 

[PATCH v2 15/21] dt-bindings: net: Update Freescale TSEC to support "queue-group"

[Bin Meng]

At present the Freescale TSEC node DT bindings doc requires a 
property in the TSEC node. But this might not always be the case.
In the upstream Linux kernel, there is no DT bindings doc for it
but the kernel driver tests a subnode of a name prefixed with
"queue-group", as we can see from gfar_of_init():

  for_each_available_child_of_node(np, child) {
  if (!of_node_name_eq(child, "queue-group"))
  ...

in drivers/net/ethernet/freescale/gianfar.c

Update our DT bindings to describe this alternate description.

Signed-off-by: Bin Meng 
Reviewed-by: Ramon Fried 
---

(no changes since v1)

 doc/device-tree-bindings/net/fsl-tsec-phy.txt | 15 ++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/doc/device-tree-bindings/net/fsl-tsec-phy.txt 
b/doc/device-tree-bindings/net/fsl-tsec-phy.txt
index a44c5fd9d9..2f9309839c 100644
--- a/doc/device-tree-bindings/net/fsl-tsec-phy.txt
+++ b/doc/device-tree-bindings/net/fsl-tsec-phy.txt
@@ -3,7 +3,9 @@
 Properties:
 
   - compatible : Should be "fsl,etsec2" or "gianfar"
-  - reg : Offset and length of the register set for the device
+  - reg : Offset and length of the register set for the device. If this is
+missing, a subnode with a name prefix "queue-group" must be provided to
+provide the  property.
   - phy-handle : See ethernet.txt file in the same directory.
   - phy-connection-type : See ethernet.txt file in the same directory. This
 property is only really needed if the connection is of type "rgmii-id",
@@ -18,6 +20,17 @@ Example:
phy-connection-type = "sgmii";
};
 
+An alternate description with "queue-group" subnode example:
+   ethernet@24000 {
+   compatible = "fsl,etsec2";
+   phy-handle = <>;
+   phy-connection-type = "sgmii";
+
+   queue-group {
+   reg = <0x24000 0x1000>;
+   };
+   };
+
 Child nodes of the TSEC controller are typically the individual PHY devices
 connected via the MDIO bus (sometimes the MDIO bus controller is separate).
 
-- 
2.25.1

[PATCH v2 13/21] net: tsec: Use dm_eth_phy_connect() directly for the DM case

[Bin Meng]

From: Vladimir Oltean 

Now that the fixed phy driver has been fully adapted to OF APIs,
and dm_eth_phy_connect() already can handle the fixed phy, call
dm_eth_phy_connect() directly in the DM tsec driver.

Signed-off-by: Vladimir Oltean 
Reviewed-by: Bin Meng 
Tested-by: Bin Meng 
Message-Id: <20210216224804.3355044-4-olte...@gmail.com>
[bmeng: split from "net: mdio: teach dm_eth_phy_connect to connect to fixed 
PHY"]
Signed-off-by: Bin Meng 

---

Changes in v2:
- new patch: split from <20210216224804.3355044-4-olte...@gmail.com>

 drivers/net/tsec.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/net/tsec.c b/drivers/net/tsec.c
index ec48689372..f801d020fb 100644
--- a/drivers/net/tsec.c
+++ b/drivers/net/tsec.c
@@ -707,11 +707,7 @@ static int init_phy(struct tsec_private *priv)
tsec_configure_serdes(priv);
 
 #if defined(CONFIG_DM_ETH) && defined(CONFIG_DM_MDIO)
-   if (ofnode_valid(ofnode_find_subnode(dev_ofnode(priv->dev),
-"fixed-link")))
-   phydev = phy_connect(NULL, 0, priv->dev, priv->interface);
-   else
-   phydev = dm_eth_phy_connect(priv->dev);
+   phydev = dm_eth_phy_connect(priv->dev);
 #else
phydev = phy_connect(priv->bus, priv->phyaddr, priv->dev,
 priv->interface);
-- 
2.25.1

[PATCH v2 12/21] net: phy: fixed: Support the old DT binding

[Bin Meng]

Update fixedphy_probe() to support the old DT binding.

Signed-off-by: Bin Meng 
Reviewed-by: Ramon Fried 
---

(no changes since v1)

 drivers/net/phy/fixed.c | 26 +++---
 1 file changed, 23 insertions(+), 3 deletions(-)

diff --git a/drivers/net/phy/fixed.c b/drivers/net/phy/fixed.c
index 304e506554..ea05a45244 100644
--- a/drivers/net/phy/fixed.c
+++ b/drivers/net/phy/fixed.c
@@ -27,13 +27,27 @@ static int fixedphy_config(struct phy_device *phydev)
 {
ofnode node = phy_get_ofnode(phydev);
struct fixed_link *priv;
+   bool old_binding = false;
u32 val;
+   u32 old_val[5];
 
if (!ofnode_valid(node))
return -EINVAL;
 
/* check for mandatory properties within fixed-link node */
val = ofnode_read_u32_default(node, "speed", 0);
+
+   if (!val) {
+   /* try old binding */
+   old_binding = true;
+   if (ofnode_read_u32_array(node, "fixed-link", old_val,
+ ARRAY_SIZE(old_val))) {
+   printf("ERROR: no/invalid  property!\n");
+   return -ENOENT;
+   }
+   val = old_val[2];
+   }
+
if (val != SPEED_10 && val != SPEED_100 && val != SPEED_1000 &&
val != SPEED_2500 && val != SPEED_1) {
printf("ERROR: no/invalid speed given in fixed-link node!\n");
@@ -48,9 +62,15 @@ static int fixedphy_config(struct phy_device *phydev)
phydev->priv = priv;
 
priv->link_speed = val;
-   priv->duplex = ofnode_read_bool(node, "full-duplex");
-   priv->pause = ofnode_read_bool(node, "pause");
-   priv->asym_pause = ofnode_read_bool(node, "asym-pause");
+   if (!old_binding) {
+   priv->duplex = ofnode_read_bool(node, "full-duplex");
+   priv->pause = ofnode_read_bool(node, "pause");
+   priv->asym_pause = ofnode_read_bool(node, "asym-pause");
+   } else {
+   priv->duplex = old_val[1];
+   priv->pause = old_val[3];
+   priv->asym_pause = old_val[4];
+   }
 
return 0;
 }
-- 
2.25.1

[PATCH v2 11/21] net: phy: fixed: Add the missing ending newline

[Bin Meng]

The printf statement doesn't end with a newline. Add it.

Signed-off-by: Bin Meng 
Reviewed-by: Ramon Fried 
---

(no changes since v1)

 drivers/net/phy/fixed.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/phy/fixed.c b/drivers/net/phy/fixed.c
index 1d2587278f..304e506554 100644
--- a/drivers/net/phy/fixed.c
+++ b/drivers/net/phy/fixed.c
@@ -36,7 +36,7 @@ static int fixedphy_config(struct phy_device *phydev)
val = ofnode_read_u32_default(node, "speed", 0);
if (val != SPEED_10 && val != SPEED_100 && val != SPEED_1000 &&
val != SPEED_2500 && val != SPEED_1) {
-   printf("ERROR: no/invalid speed given in fixed-link node!");
+   printf("ERROR: no/invalid speed given in fixed-link node!\n");
return -EINVAL;
}
 
-- 
2.25.1

[PATCH v2 10/21] net: phy: fixed: Make driver ops static

[Bin Meng]

The PHY driver ops should be made static.

Signed-off-by: Bin Meng 
Reviewed-by: Ramon Fried 
---

(no changes since v1)

 drivers/net/phy/fixed.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/net/phy/fixed.c b/drivers/net/phy/fixed.c
index 11342df1c5..1d2587278f 100644
--- a/drivers/net/phy/fixed.c
+++ b/drivers/net/phy/fixed.c
@@ -15,7 +15,7 @@
 
 DECLARE_GLOBAL_DATA_PTR;
 
-int fixedphy_probe(struct phy_device *phydev)
+static int fixedphy_probe(struct phy_device *phydev)
 {
/* fixed-link phy must not be reset by core phy code */
phydev->flags |= PHY_FLAG_BROKEN_RESET;
@@ -23,7 +23,7 @@ int fixedphy_probe(struct phy_device *phydev)
return 0;
 }
 
-int fixedphy_config(struct phy_device *phydev)
+static int fixedphy_config(struct phy_device *phydev)
 {
ofnode node = phy_get_ofnode(phydev);
struct fixed_link *priv;
@@ -55,7 +55,7 @@ int fixedphy_config(struct phy_device *phydev)
return 0;
 }
 
-int fixedphy_startup(struct phy_device *phydev)
+static int fixedphy_startup(struct phy_device *phydev)
 {
struct fixed_link *priv = phydev->priv;
 
@@ -68,7 +68,7 @@ int fixedphy_startup(struct phy_device *phydev)
return 0;
 }
 
-int fixedphy_shutdown(struct phy_device *phydev)
+static int fixedphy_shutdown(struct phy_device *phydev)
 {
return 0;
 }
-- 
2.25.1

[PATCH v2 09/21] net: phy: Simplify the logic of phy_connect_fixed()

[Bin Meng]

Simplify the logic of phy_connect_fixed() by using the new API
ofnode_phy_is_fixed_link(), which brings additional bonus of
supporting the old DT bindings.

Signed-off-by: Bin Meng 
Reviewed-by: Ramon Fried 
---

(no changes since v1)

 drivers/net/phy/phy.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
index c7cdf64a0a..dcdef9e661 100644
--- a/drivers/net/phy/phy.c
+++ b/drivers/net/phy/phy.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1008,15 +1009,14 @@ static struct phy_device *phy_connect_fixed(struct 
mii_dev *bus,
phy_interface_t interface)
 {
ofnode node = dev_ofnode(dev), subnode;
-   struct phy_device *phydev;
-
-   subnode = ofnode_find_subnode(node, "fixed-link");
-   if (!ofnode_valid(subnode))
-   return NULL;
+   struct phy_device *phydev = NULL;
 
-   phydev = phy_device_create(bus, 0, PHY_FIXED_ID, false, interface);
-   if (phydev)
-   phydev->node = subnode;
+   if (ofnode_phy_is_fixed_link(node, )) {
+   phydev = phy_device_create(bus, 0, PHY_FIXED_ID,
+  false, interface);
+   if (phydev)
+   phydev->node = subnode;
+   }
 
return phydev;
 }
-- 
2.25.1

[PATCH v2 08/21] net: phy: xilinx: Drop #ifdef CONFIG_DM_ETH around phy_connect_gmii2rgmii()

[Bin Meng]

At present phy_connect_gmii2rgmii() is implemented using a DM API
dev_of_offset() hence it cannot support a non-DM configuration.
Remove the non-DM version prototype of phy_connect_gmii2rgmii()
and make the driver depend on CONFIG_DM_ETH.

Signed-off-by: Bin Meng 
Acked-by: Michal Simek 
Reviewed-by: Ramon Fried 
---

(no changes since v1)

 drivers/net/phy/Kconfig | 1 +
 drivers/net/phy/phy.c   | 6 --
 2 files changed, 1 insertion(+), 6 deletions(-)

diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
index d69503067d..070ffa82cb 100644
--- a/drivers/net/phy/Kconfig
+++ b/drivers/net/phy/Kconfig
@@ -292,6 +292,7 @@ config PHY_XILINX
 
 config PHY_XILINX_GMII2RGMII
bool "Xilinx GMII to RGMII Ethernet PHYs support"
+   depends on DM_ETH
help
  This adds support for Xilinx GMII to RGMII IP core. This IP acts
  as bridge between MAC connected over GMII and external phy that
diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
index d464379121..c7cdf64a0a 100644
--- a/drivers/net/phy/phy.c
+++ b/drivers/net/phy/phy.c
@@ -942,15 +942,9 @@ void phy_connect_dev(struct phy_device *phydev, struct 
eth_device *dev)
 }
 
 #ifdef CONFIG_PHY_XILINX_GMII2RGMII
-#ifdef CONFIG_DM_ETH
 static struct phy_device *phy_connect_gmii2rgmii(struct mii_dev *bus,
 struct udevice *dev,
 phy_interface_t interface)
-#else
-static struct phy_device *phy_connect_gmii2rgmii(struct mii_dev *bus,
-struct eth_device *dev,
-phy_interface_t interface)
-#endif
 {
struct phy_device *phydev = NULL;
ofnode node = dev_ofnode(dev);
-- 
2.25.1

[PATCH v2 07/21] net: phy: xilinx: Be compatible with live OF tree

[Bin Meng]

Following the same updates that were done to the fixed phy driver,
use ofnode_ APIs instead of fdt_ APIs so that the Xilinx PHY driver
can support live DT.

Signed-off-by: Bin Meng 

---

Changes in v2:
- move device tree parsing from xilinxgmiitorgmii_probe() to
  xilinxgmiitorgmii_config() and use OF APIs

 drivers/net/phy/phy.c   | 23 +--
 drivers/net/phy/xilinx_gmii2rgmii.c | 61 ++---
 2 files changed, 40 insertions(+), 44 deletions(-)

diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
index eae40cc0d6..d464379121 100644
--- a/drivers/net/phy/phy.c
+++ b/drivers/net/phy/phy.c
@@ -953,23 +953,20 @@ static struct phy_device *phy_connect_gmii2rgmii(struct 
mii_dev *bus,
 #endif
 {
struct phy_device *phydev = NULL;
-   int sn = dev_of_offset(dev);
-   int off;
-
-   while (sn > 0) {
-   off = fdt_node_offset_by_compatible(gd->fdt_blob, sn,
-   "xlnx,gmii-to-rgmii-1.0");
-   if (off > 0) {
-   phydev = phy_device_create(bus, off,
+   ofnode node = dev_ofnode(dev);
+
+   while (ofnode_valid(node)) {
+   node = ofnode_by_compatible(node, "xlnx,gmii-to-rgmii-1.0");
+   if (ofnode_valid(node)) {
+   phydev = phy_device_create(bus, 0,
   PHY_GMII2RGMII_ID, false,
   interface);
+   if (phydev)
+   phydev->node = node;
break;
}
-   if (off == -FDT_ERR_NOTFOUND)
-   sn = fdt_first_subnode(gd->fdt_blob, sn);
-   else
-   printf("%s: Error finding compat string:%d\n",
-  __func__, off);
+
+   node = ofnode_first_subnode(node);
}
 
return phydev;
diff --git a/drivers/net/phy/xilinx_gmii2rgmii.c 
b/drivers/net/phy/xilinx_gmii2rgmii.c
index 74105c0b7d..635c0570ef 100644
--- a/drivers/net/phy/xilinx_gmii2rgmii.c
+++ b/drivers/net/phy/xilinx_gmii2rgmii.c
@@ -18,9 +18,38 @@ DECLARE_GLOBAL_DATA_PTR;
 
 static int xilinxgmiitorgmii_config(struct phy_device *phydev)
 {
-   struct phy_device *ext_phydev = phydev->priv;
+   ofnode node = phy_get_ofnode(phydev);
+   struct phy_device *ext_phydev;
+   struct ofnode_phandle_args phandle;
+   int ext_phyaddr = -1;
+   int ret;
 
debug("%s\n", __func__);
+
+   if (!ofnode_valid(node))
+   return -EINVAL;
+
+   phydev->addr = ofnode_read_u32_default(node, "reg", -1);
+   ret = ofnode_parse_phandle_with_args(node, "phy-handle",
+NULL, 0, 0, );
+   if (ret)
+   return ret;
+
+   ext_phyaddr = ofnode_read_u32_default(phandle.node, "reg", -1);
+   ext_phydev = phy_find_by_mask(phydev->bus,
+ 1 << ext_phyaddr,
+ PHY_INTERFACE_MODE_RGMII);
+   if (!ext_phydev) {
+   printf("%s, No external phy device found\n", __func__);
+   return -EINVAL;
+   }
+
+   ext_phydev->node = phandle.node;
+   phydev->priv = ext_phydev;
+
+   debug("%s, gmii2rgmmi:0x%x, extphy:0x%x\n", __func__, phydev->addr,
+ ext_phyaddr);
+
if (ext_phydev->drv->config)
ext_phydev->drv->config(ext_phydev);
 
@@ -83,11 +112,6 @@ static int xilinxgmiitorgmii_startup(struct phy_device 
*phydev)
 
 static int xilinxgmiitorgmii_probe(struct phy_device *phydev)
 {
-   int ofnode = phydev->addr;
-   u32 phy_of_handle;
-   int ext_phyaddr = -1;
-   struct phy_device *ext_phydev;
-
debug("%s\n", __func__);
 
if (phydev->interface != PHY_INTERFACE_MODE_GMII) {
@@ -95,31 +119,6 @@ static int xilinxgmiitorgmii_probe(struct phy_device 
*phydev)
return -EINVAL;
}
 
-   /*
-* Read the phy address again as the one we read in ethernet driver
-* was overwritten for the purpose of storing the ofnode
-*/
-   phydev->addr = fdtdec_get_int(gd->fdt_blob, ofnode, "reg", -1);
-   phy_of_handle = fdtdec_lookup_phandle(gd->fdt_blob, ofnode,
- "phy-handle");
-   if (phy_of_handle > 0)
-   ext_phyaddr = fdtdec_get_int(gd->fdt_blob,
-phy_of_handle,
-"reg", -1);
-   ext_phydev = phy_find_by_mask(phydev->bus,
- 1 << ext_phyaddr,
- PHY_INTERFACE_MODE_RGMII);
-   if (!ext_phydev) {
-   printf("%s, No external phy device found\n", __func__);
-   return -EINVAL;
-   }
-
-   ext_phydev->node = offset_to_ofnode(phy_of_handle);
-   

[PATCH v2 06/21] net: phy: fixed: Drop #ifdef CONFIG_DM_ETH around phy_connect_fixed

[Bin Meng]

From: Vladimir Oltean 

In drivers/net/phy/Kconfig, CONFIG_PHY_FIXED already depends on
CONFIG_DM_ETH, so the function prototype definition when
CONFIG_DM_ETH=n does nothing, so it can be dropped. It is also
never reachable, since the whole function is already under #ifdef
CONFIG_PHY_FIXED (which again, as I said, depends on CONFIG_DM_ETH=y).

Signed-off-by: Vladimir Oltean 
Reviewed-by: Bin Meng 
Tested-by: Bin Meng 
Message-Id: <20210216224804.3355044-3-olte...@gmail.com>
Signed-off-by: Bin Meng 
---

(no changes since v1)

 drivers/net/phy/phy.c | 6 --
 1 file changed, 6 deletions(-)

diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
index 2feb559bba..eae40cc0d6 100644
--- a/drivers/net/phy/phy.c
+++ b/drivers/net/phy/phy.c
@@ -1012,15 +1012,9 @@ struct phy_device *fixed_phy_create(ofnode node)
return phydev;
 }
 
-#ifdef CONFIG_DM_ETH
 static struct phy_device *phy_connect_fixed(struct mii_dev *bus,
struct udevice *dev,
phy_interface_t interface)
-#else
-static struct phy_device *phy_connect_fixed(struct mii_dev *bus,
-   struct eth_device *dev,
-   phy_interface_t interface)
-#endif
 {
ofnode node = dev_ofnode(dev), subnode;
struct phy_device *phydev;
-- 
2.25.1

[PATCH v2 05/21] net: phy: fixed: Be compatible with live OF tree

[Bin Meng]

From: Vladimir Oltean 

On systems that use CONFIG_OF_LIVE, the "ofnode" type is defined
as const struct device_node *np, while on the flat DT systems it
is defined as a long of_offset into gd->fdt_blob.

It is desirable that the fixed PHY driver uses the higher-level
ofnode abstraction instead of parsing gd->fdt_blob directly,
because that enables it to work on live OF systems.

The fixed PHY driver has used a nasty hack since its introduction in
commit db40c1aa1c10 ("drivers/net/phy: add fixed-phy / fixed-link support"),
which is to pass the long gd->fdt_blob offset inside int phydev->addr
(a value that normally holds the MDIO bus address at which the PHY
responds). Even ignoring the fact that the types were already
mismatched leading to a potential truncation (flat OF offset was
supposed to be a long and not an int), we really cannot extend this
hack any longer, because there's no way an int will hold the other
representation of ofnode, the struct device_node *np.

So we unfortunately need to do the right thing, which is to use the
framework introduced by Grygorii Strashko in
commit eef0b8a930d1 ("net: phy: add ofnode node to struct phy_device").
This will populate phydev->node for the fixed PHY.

Note that phydev->node will not be valid in the probe function, since
that is called synchronously from phy_device_create and we really have
no way of passing the ofnode directly through the phy_device_create API.
So we do what other drivers do too: we move the OF parsing logic from
the .probe to the .config method of the PHY driver. The new function
will be called at phy_config() time.

I do believe I've converted all the possible call paths for creating
a PHY with PHY_FIXED_ID, so there is really no reason to maintain
compatibility with the old logic of retrieving a flat OF tree offset
from phydev->addr. We just pass 0 to phydev->addr now.

Signed-off-by: Vladimir Oltean 
Reviewed-by: Bin Meng 
Tested-by: Bin Meng 
Message-Id: <20210216224804.3355044-2-olte...@gmail.com>
[bmeng: keep fixedphy_probe(); update mdio-uclass.c to handle fixed phy]
Signed-off-by: Bin Meng 
---

(no changes since v1)

 drivers/net/phy/fixed.c | 26 +-
 drivers/net/phy/phy.c   | 30 +++---
 net/mdio-uclass.c   |  6 --
 3 files changed, 36 insertions(+), 26 deletions(-)

diff --git a/drivers/net/phy/fixed.c b/drivers/net/phy/fixed.c
index 1a38c29469..11342df1c5 100644
--- a/drivers/net/phy/fixed.c
+++ b/drivers/net/phy/fixed.c
@@ -17,13 +17,23 @@ DECLARE_GLOBAL_DATA_PTR;
 
 int fixedphy_probe(struct phy_device *phydev)
 {
+   /* fixed-link phy must not be reset by core phy code */
+   phydev->flags |= PHY_FLAG_BROKEN_RESET;
+
+   return 0;
+}
+
+int fixedphy_config(struct phy_device *phydev)
+{
+   ofnode node = phy_get_ofnode(phydev);
struct fixed_link *priv;
-   int ofnode = phydev->addr;
u32 val;
 
+   if (!ofnode_valid(node))
+   return -EINVAL;
+
/* check for mandatory properties within fixed-link node */
-   val = fdt_getprop_u32_default_node(gd->fdt_blob,
-  ofnode, 0, "speed", 0);
+   val = ofnode_read_u32_default(node, "speed", 0);
if (val != SPEED_10 && val != SPEED_100 && val != SPEED_1000 &&
val != SPEED_2500 && val != SPEED_1) {
printf("ERROR: no/invalid speed given in fixed-link node!");
@@ -38,12 +48,9 @@ int fixedphy_probe(struct phy_device *phydev)
phydev->priv = priv;
 
priv->link_speed = val;
-   priv->duplex = fdtdec_get_bool(gd->fdt_blob, ofnode, "full-duplex");
-   priv->pause = fdtdec_get_bool(gd->fdt_blob, ofnode, "pause");
-   priv->asym_pause = fdtdec_get_bool(gd->fdt_blob, ofnode, "asym-pause");
-
-   /* fixed-link phy must not be reset by core phy code */
-   phydev->flags |= PHY_FLAG_BROKEN_RESET;
+   priv->duplex = ofnode_read_bool(node, "full-duplex");
+   priv->pause = ofnode_read_bool(node, "pause");
+   priv->asym_pause = ofnode_read_bool(node, "asym-pause");
 
return 0;
 }
@@ -72,6 +79,7 @@ static struct phy_driver fixedphy_driver = {
.name   = "Fixed PHY",
.features   = PHY_GBIT_FEATURES | SUPPORTED_MII,
.probe  = fixedphy_probe,
+   .config = fixedphy_config,
.startup= fixedphy_startup,
.shutdown   = fixedphy_shutdown,
 };
diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
index 89e3076bfd..2feb559bba 100644
--- a/drivers/net/phy/phy.c
+++ b/drivers/net/phy/phy.c
@@ -988,6 +988,7 @@ static struct phy_device *phy_connect_gmii2rgmii(struct 
mii_dev *bus,
 struct phy_device *fixed_phy_create(ofnode node)
 {
phy_interface_t interface = PHY_INTERFACE_MODE_NONE;
+   struct phy_device *phydev;
const char *if_str;
ofnode subnode;
 
@@ -1004,8 +1005,11 @@ struct phy_device *fixed_phy_create(ofnode node)
return NULL;
   

[PATCH v2 04/21] dm: mdio: Use ofnode_phy_is_fixed_link() API

[Bin Meng]

Switch to use the ofnode_phy_is_fixed_link() API which can support
both the new and old DT bindings.

Signed-off-by: Bin Meng 
Reviewed-by: Ramon Fried 
---

(no changes since v1)

 net/mdio-uclass.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/net/mdio-uclass.c b/net/mdio-uclass.c
index 5da984ca3f..2a9533c88b 100644
--- a/net/mdio-uclass.c
+++ b/net/mdio-uclass.c
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -140,7 +141,7 @@ static struct phy_device *dm_eth_connect_phy_handle(struct 
udevice *ethdev,
int i;
 
if (CONFIG_IS_ENABLED(PHY_FIXED) &&
-   ofnode_valid(dev_read_subnode(ethdev, "fixed-link"))) {
+   ofnode_phy_is_fixed_link(dev_ofnode(ethdev), NULL)) {
phy = phy_connect(NULL, -1, ethdev, interface);
goto out;
}
-- 
2.25.1

[PATCH v2 03/21] test: dm: Add a case to test ofnode_phy_is_fixed_link()

[Bin Meng]

This adds a test case to test the new ofnode_phy_is_fixed_link() API.
Both the new and old DT bindings are covered.

Signed-off-by: Bin Meng 
Reviewed-by: Simon Glass 
---

(no changes since v1)

 arch/sandbox/dts/test.dts | 11 +++
 test/dm/of_extra.c| 18 ++
 2 files changed, 29 insertions(+)

diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
index 2600360224..995c93c95a 100644
--- a/arch/sandbox/dts/test.dts
+++ b/arch/sandbox/dts/test.dts
@@ -478,6 +478,17 @@
fake-host-hwaddr = [00 00 66 44 22 22];
};
 
+   fixed-link-test1 {
+   fixed-link {
+   speed = <1000>;
+   full-duplex;
+   };
+   };
+
+   fixed-link-test2 {
+   fixed-link = <0 1 1000 0 0>;
+   };
+
firmware {
sandbox_firmware: sandbox-firmware {
compatible = "sandbox,firmware";
diff --git a/test/dm/of_extra.c b/test/dm/of_extra.c
index b19cd3787d..d7c584fa33 100644
--- a/test/dm/of_extra.c
+++ b/test/dm/of_extra.c
@@ -36,3 +36,21 @@ static int dm_test_ofnode_read_fmap_entry(struct 
unit_test_state *uts)
return 0;
 }
 DM_TEST(dm_test_ofnode_read_fmap_entry, 0);
+
+static int dm_test_ofnode_phy_is_fixed_link(struct unit_test_state *uts)
+{
+   ofnode eth_node, phy_node, node;
+
+   eth_node = ofnode_path("/fixed-link-test1");
+   ut_assert(ofnode_phy_is_fixed_link(eth_node, _node));
+   node = ofnode_path("/fixed-link-test1/fixed-link");
+   ut_asserteq_mem(_node, , sizeof(ofnode));
+
+   eth_node = ofnode_path("/fixed-link-test2");
+   ut_assert(ofnode_phy_is_fixed_link(eth_node, _node));
+   node = eth_node;
+   ut_asserteq_mem(_node, , sizeof(ofnode));
+
+   return 0;
+}
+DM_TEST(dm_test_ofnode_phy_is_fixed_link, 0);
-- 
2.25.1

[PATCH v2 02/21] of: extra: Introduce ofnode_phy_is_fixed_link() API

[Bin Meng]

Introduce a helper API ofnode_phy_is_fixed_link() to detect whether
the ethernet controller connects to a fixed-link pseudo-PHY device.

Note there are two ways to describe a fixed PHY attached to an
Ethernet device:

- the new DT binding, where 'fixed-link' is a sub-node of the
  Ethernet device
- the old DT binding, where 'fixed-link' is a property with 5
  cells encoding various information about the fixed PHY

Signed-off-by: Bin Meng 
Reviewed-by: Simon Glass 
---

(no changes since v1)

 drivers/core/of_extra.c | 26 ++
 include/dm/of_extra.h   | 18 ++
 2 files changed, 44 insertions(+)

diff --git a/drivers/core/of_extra.c b/drivers/core/of_extra.c
index 653344529e..a16f9a8dc1 100644
--- a/drivers/core/of_extra.c
+++ b/drivers/core/of_extra.c
@@ -130,3 +130,29 @@ int ofnode_decode_memory_region(ofnode config_node, const 
char *mem_type,
 
return 0;
 }
+
+bool ofnode_phy_is_fixed_link(ofnode eth_node, ofnode *phy_node)
+{
+   bool found = false;
+   ofnode node, subnode;
+   int len;
+
+   /* new binding */
+   subnode = ofnode_find_subnode(eth_node, "fixed-link");
+   if (ofnode_valid(subnode)) {
+   node = subnode;
+   found = true;
+   }
+
+   /* old binding */
+   if (ofnode_get_property(eth_node, "fixed-link", ) &&
+   len == (5 * sizeof(__be32))) {
+   node = eth_node;
+   found = true;
+   }
+
+   if (found && phy_node)
+   *phy_node = node;
+
+   return found;
+}
diff --git a/include/dm/of_extra.h b/include/dm/of_extra.h
index ca15df21b0..3641f68fe3 100644
--- a/include/dm/of_extra.h
+++ b/include/dm/of_extra.h
@@ -86,4 +86,22 @@ int ofnode_decode_memory_region(ofnode config_node, const 
char *mem_type,
const char *suffix, fdt_addr_t *basep,
fdt_size_t *sizep);
 
+/**
+ * ofnode_phy_is_fixed_link() - Detect fixed-link pseudo-PHY device
+ *
+ * This function detects whether the ethernet controller connects to a
+ * fixed-link pseudo-PHY device.
+ *
+ * This function supports the following two DT bindings:
+ * - the new DT binding, where 'fixed-link' is a sub-node of the
+ *   Ethernet device
+ * - the old DT binding, where 'fixed-link' is a property with 5
+ *   cells encoding various information about the fixed PHY
+ *
+ * @param eth_node ofnode containing the fixed-link subnode/property
+ * @param phy_node if fixed-link PHY detected, containing the PHY ofnode
+ * @return true if a fixed-link pseudo-PHY device exists, false otherwise
+ */
+bool ofnode_phy_is_fixed_link(ofnode eth_node, ofnode *phy_node);
+
 #endif
-- 
2.25.1

[PATCH v2 01/21] dt-bindings: net: Add the old DT bindings for "fixed-link"

[Bin Meng]

Per the upstream Linux kernel doc:

  Documentation/devicetree/bindings/net/ethernet-controller.yaml

There are two ways to describe a fixed PHY attached to an Ethernet
device. This updates our dt-bindings doc to add the old DT bindings.

Signed-off-by: Bin Meng 
Reviewed-by: Ramon Fried 
---

(no changes since v1)

 doc/device-tree-bindings/net/fixed-link.txt | 47 +++--
 1 file changed, 35 insertions(+), 12 deletions(-)

diff --git a/doc/device-tree-bindings/net/fixed-link.txt 
b/doc/device-tree-bindings/net/fixed-link.txt
index 5829bd81a2..71ab480701 100644
--- a/doc/device-tree-bindings/net/fixed-link.txt
+++ b/doc/device-tree-bindings/net/fixed-link.txt
@@ -5,21 +5,36 @@ Some Ethernet MACs have a "fixed link", and are not connected 
to a
 normal MDIO-managed PHY device. For those situations, a Device Tree
 binding allows to describe a "fixed link".
 
-Such a fixed link situation is described by creating a 'fixed-link'
-sub-node of the Ethernet MAC device node, with the following
-properties:
-
-* 'speed' (integer, mandatory), to indicate the link speed. Accepted
-  values are 10, 100 and 1000
-* 'full-duplex' (boolean, optional), to indicate that full duplex is
-  used. When absent, half duplex is assumed.
-* 'pause' (boolean, optional), to indicate that pause should be
-  enabled.
-* 'asym-pause' (boolean, optional), to indicate that asym_pause should
-  be enabled.
+Note there are two ways to describe a fixed PHY attached to an
+Ethernet device:
+
+- The new DT binding, where 'fixed-link' is a sub-node of the Ethernet
+  MAC device node, with the following properties:
+
+  * 'speed' (integer, mandatory), to indicate the link speed. Accepted
+values are 10, 100 and 1000
+  * 'full-duplex' (boolean, optional), to indicate that full duplex is
+used. When absent, half duplex is assumed.
+  * 'pause' (boolean, optional), to indicate that pause should be
+enabled.
+  * 'asym-pause' (boolean, optional), to indicate that asym_pause should
+be enabled.
+
+- The old DT binding, where 'fixed-link' is a property with 5 cells
+  encoding various information about the fixed PHY, in the form of
+  .
+
+  * 'phy_id', emulated PHY ID, choose any but unique to the all specified
+fixed-links
+  * 'full-duplex', 0 for half duplex or 1 for full duplex
+  * 'speed', link speed in Mbits/sec, accepts only 10, 100 and 1000
+  * 'pause', 0 for no pause, 1 for pause
+  * 'asym-pause', 0 for no asymmetric pause, 1 for asymmetric pause
 
 Examples:
 
+The new binding:
+
 ethernet@0 {
...
fixed-link {
@@ -28,3 +43,11 @@ ethernet@0 {
};
...
 };
+
+The old binding:
+
+ethernet@0 {
+   ...
+   fixed-link = <0 1 1000 0 0>;
+   ...
+};
-- 
2.25.1

[PATCH v2 00/21] ppc: qemu: Add eTSEC support

[Bin Meng]

QEMU ppce500 machine can dynamically instantiate an eTSEC device
if "-device eTSEC" is given to QEMU.

This series updates the fixed-link ethernet PHY driver as well as
the Freescale eTSEC driver to support the QEMU ppce500 board.

3 patches related to fixed phy in v1 are dropped in v2 as the changes
were done by Vladimir's fixed phy & Sandbox DSA series [1]. Vladimir's
series is now included in v2, and updated as needed.

This cover letter is cc'ed to QEMU mailing list for a heads-up.
A future patch will be sent to QEMU mailing list to bring its in-tree
U-Boot source codes up-to-date.

This series is avaiable at u-boot-x86/eTSEC for testing.

[1] 
https://patchwork.ozlabs.org/project/uboot/patch/20210216224804.3355044-2-olte...@gmail.com/

Changes in v2:
- move device tree parsing from xilinxgmiitorgmii_probe() to
  xilinxgmiitorgmii_config() and use OF APIs
- new patch: split from <20210216224804.3355044-4-olte...@gmail.com>
- include 
- use a Kconfig option CONFIG_SIMPLE_BUS_CORRECT_RANGE to control the
  new behavior for boards that want this
- default y if SANDBOX for CONFIG_SIMPLE_BUS_CORRECT_RANGE
- turn on CONFIG_SIMPLE_BUS_CORRECT_RANGE in qemu-ppce500_defconfig

Bin Meng (17):
  dt-bindings: net: Add the old DT bindings for "fixed-link"
  of: extra: Introduce ofnode_phy_is_fixed_link() API
  test: dm: Add a case to test ofnode_phy_is_fixed_link()
  dm: mdio: Use ofnode_phy_is_fixed_link() API
  net: phy: xilinx: Be compatible with live OF tree
  net: phy: xilinx: Drop #ifdef CONFIG_DM_ETH around
phy_connect_gmii2rgmii()
  net: phy: Simplify the logic of phy_connect_fixed()
  net: phy: fixed: Make driver ops static
  net: phy: fixed: Add the missing ending newline
  net: phy: fixed: Support the old DT binding
  dt-bindings: net: Update Freescale TSEC to support "queue-group"
  net: tsec: Support  property from the subnode "queue-group"
  dm: core: Correctly read  of simple-bus
  test: dm: Add a test case for simple-bus 
  ppc: qemu: Create a virtual memory mapping of the platform bus
  ppc: qemu: Enable eTSEC support
  doc: board: qemu-ppce500: Document eTSEC usage

Claudiu Manoil (1):
  sandbox: Add a DSA sandbox driver and unit test

Vladimir Oltean (3):
  net: phy: fixed: Be compatible with live OF tree
  net: phy: fixed: Drop #ifdef CONFIG_DM_ETH around phy_connect_fixed
  net: tsec: Use dm_eth_phy_connect() directly for the DM case

 arch/Kconfig  |   2 +
 arch/sandbox/dts/test.dts |  59 ++
 board/emulation/qemu-ppce500/Kconfig  |   6 +
 board/emulation/qemu-ppce500/qemu-ppce500.c   |  18 ++
 configs/qemu-ppce500_defconfig|   5 +
 doc/board/emulation/qemu-ppce500.rst  |   5 +
 doc/device-tree-bindings/net/fixed-link.txt   |  47 +++--
 doc/device-tree-bindings/net/fsl-tsec-phy.txt |  15 +-
 drivers/core/Kconfig  |  14 ++
 drivers/core/of_extra.c   |  26 +++
 drivers/core/simple-bus.c |  32 +++-
 drivers/net/Kconfig   |   9 +
 drivers/net/Makefile  |   1 +
 drivers/net/dsa_sandbox.c | 179 ++
 drivers/net/phy/Kconfig   |   1 +
 drivers/net/phy/fixed.c   |  54 --
 drivers/net/phy/phy.c |  63 +++---
 drivers/net/phy/xilinx_gmii2rgmii.c   |  61 +++---
 drivers/net/tsec.c|  32 +++-
 include/configs/sandbox.h |   2 +
 include/dm/of_extra.h |  18 ++
 include/dm/simple_bus.h   |   6 +-
 net/mdio-uclass.c |   7 +-
 test/dm/Makefile  |   2 +
 test/dm/dsa.c |  82 
 test/dm/eth.c |  10 +-
 test/dm/of_extra.c|  18 ++
 test/dm/simple-bus.c  |  33 
 28 files changed, 687 insertions(+), 120 deletions(-)
 create mode 100644 drivers/net/dsa_sandbox.c
 create mode 100644 test/dm/dsa.c
 create mode 100644 test/dm/simple-bus.c

-- 
2.25.1

Re: [PATCHv5 0/6] SCP03 control, documentation and tests.

[Jorge Ramirez-Ortiz, Foundries]

On 12/03/21, Tom Rini wrote:
> On Fri, Mar 12, 2021 at 09:28:25AM +0100, Jorge Ramirez-Ortiz, Foundries 
> wrote:
> > On 11/03/21, Simon Glass wrote:
> > > Hi Foundries,
> > > 
> > > On Wed, 10 Mar 2021 at 09:59, Jorge Ramirez-Ortiz, Foundries
> > >  wrote:
> > > >
> > > > On 14/02/21, Jorge Ramirez-Ortiz wrote:
> > > > > Simply adding the reviewed-by tags to the v5 series.
> > > >
> > > > why has this not been merged yet?
> > > 
> > > You can check in patchwork to see whose queue it is in.
> > 
> > ah ok, thanks Simon.
> > (adding Tom to the thread now).
> 
> I am a bit behind on merging stuff to -next, sorry.

np thanks! I am a bit paranoid sometimes :)

> 
> -- 
> Tom

Re: [PATCHv5 0/6] SCP03 control, documentation and tests.

[Tom Rini]

On Fri, Mar 12, 2021 at 09:28:25AM +0100, Jorge Ramirez-Ortiz, Foundries wrote:
> On 11/03/21, Simon Glass wrote:
> > Hi Foundries,
> > 
> > On Wed, 10 Mar 2021 at 09:59, Jorge Ramirez-Ortiz, Foundries
> >  wrote:
> > >
> > > On 14/02/21, Jorge Ramirez-Ortiz wrote:
> > > > Simply adding the reviewed-by tags to the v5 series.
> > >
> > > why has this not been merged yet?
> > 
> > You can check in patchwork to see whose queue it is in.
> 
> ah ok, thanks Simon.
> (adding Tom to the thread now).

I am a bit behind on merging stuff to -next, sorry.

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH u-boot 37/39] ARM: don't use -ffunction-sections/-fdata-sections with LTO build

[Tom Rini]

On Fri, Mar 12, 2021 at 08:29:05AM +0100, Marek Behun wrote:
> On Fri, 12 Mar 2021 15:19:26 +0800
> Bin Meng  wrote:
> 
> > On Fri, Mar 12, 2021 at 3:11 PM Marek Behun  wrote:
> > >
> > > On Fri, 12 Mar 2021 14:48:04 +0800
> > > Bin Meng  wrote:
> > >  
> > > > On Fri, Mar 12, 2021 at 2:45 PM Marek Behun  wrote: 
> > > >  
> > > > >
> > > > > On Wed, 10 Mar 2021 11:40:42 +0800
> > > > > Bin Meng  wrote:
> > > > >  
> > > > > > On Sun, Mar 7, 2021 at 12:26 PM Marek Behún  
> > > > > > wrote:  
> > > > > > >
> > > > > > > When building with LTO, using -ffunction-sections/-fdata-sections 
> > > > > > > is not
> > > > > > > useful anymore.
> > > > > > >
> > > > > > > Signed-off-by: Marek Behún 
> > > > > > > ---
> > > > > > >  arch/arm/config.mk | 8 ++--
> > > > > > >  1 file changed, 6 insertions(+), 2 deletions(-)
> > > > > > >  
> > > > > >
> > > > > > I believe we should also remove --gc-sections.  
> > > > >
> > > > > It seems that --gc-sections cannot be removed, otherwise some builds,
> > > > > for example turris_mox_defconfig, fail with
> > > > >
> > > > >   LTO u-boot
> > > > > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: 
> > > > > /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(lse-init.o): 
> > > > > in function `init_have_lse_atomics':
> > > > > /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/config/aarch64/lse-init.c:44:
> > > > >  undefined reference to `__getauxval'
> > > > > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: 
> > > > > /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(_absvsi2.o): 
> > > > > in function `__absvdi2':
> > > > > /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:228:
> > > > >  undefined reference to `abort'
> > > > > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: 
> > > > > /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(_absvsi2.o): 
> > > > > in function `__absvsi2':
> > > > > /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:246:
> > > > >  undefined reference to `abort'
> > > > > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: 
> > > > > /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(_absvdi2.o): 
> > > > > in function `__absvti2':
> > > > > /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:267:
> > > > >  undefined reference to `abort'
> > > > > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: 
> > > > > /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(_addvsi3.o): 
> > > > > in function `__addvdi3':
> > > > > /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:81:
> > > > >  undefined reference to `abort'
> > > > > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: 
> > > > > /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(_addvsi3.o): 
> > > > > in function `__addvsi3':
> > > > > /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:92:
> > > > >  undefined reference to `abort'
> > > > > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: 
> > > > > /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(_addvdi3.o):/var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:106:
> > > > >  more undefined references to `abort' follow
> > > > > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: 
> > > > > /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(_eprintf.o): 
> > > > > in function `__eprintf':
> > > > > /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:2152:
> > > > >  undefined reference to `stderr'
> > > > > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: 
> > > > > /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:2152:
> > > > >  undefined reference to `stderr'
> > > > > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: 
> > > > > /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(_eprintf.o): 
> > > > > in function `fprintf':
> > > > > /usr/aarch64-unknown-linux-gnu/sys-include/bits/stdio2.h:103: 
> > > > > undefined reference to `__fprintf_chk'
> > > > > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: 
> > > > > /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(_eprintf.o): 
> > > > > in function `__eprintf':
> > > > > /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:2153:
> > > > >  undefined reference to `fflush'
> > > > > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: 
> > > > > /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:2154:
> > > > >  undefined reference to `abort'  
> > > >
> > > > Ouch! How compiler behaves when it comes to LTO and works with all
> > > > these compiler/linker options is really a mystery ...  
> > >
> > > OK, it seems that on aarch64 we are actually using system's libgcc :)  
> > 
> > Thanks.
> > 
> 

[PATCH] mtd: rawnand: fsl_ifc: fix FSL NAND driver to read all ONFI parameter pages

[Maxim Kochetkov]

Linux commit a75bbe71a27 ("mtd: rawnand: fsl_ifc: fix FSL NAND driver to
 read all ONFI parameter pages")

Per ONFI specification (Rev. 4.0), if the CRC of the first parameter page
read is not valid, the host should read redundant parameter page copies.
Fix FSL NAND driver to read the two redundant copies which are mandatory
in the specification.

Signed-off-by: Jane Wan 
Signed-off-by: Boris Brezillon 

Signed-off-by: Maxim Kochetkov 
---
 drivers/mtd/nand/raw/fsl_ifc_nand.c | 17 ++---
 1 file changed, 10 insertions(+), 7 deletions(-)

diff --git a/drivers/mtd/nand/raw/fsl_ifc_nand.c 
b/drivers/mtd/nand/raw/fsl_ifc_nand.c
index cf20238782..e5ff937872 100644
--- a/drivers/mtd/nand/raw/fsl_ifc_nand.c
+++ b/drivers/mtd/nand/raw/fsl_ifc_nand.c
@@ -411,9 +411,16 @@ static void fsl_ifc_cmdfunc(struct mtd_info *mtd, unsigned 
int command,
/* READID must read all possible bytes while CEB is active */
case NAND_CMD_READID:
case NAND_CMD_PARAM: {
+   /*
+* For READID, read 8 bytes that are currently used.
+* For PARAM, read all 3 copies of 256-bytes pages.
+*/
+   int len = 8;
int timing = IFC_FIR_OP_RB;
-   if (command == NAND_CMD_PARAM)
+   if (command == NAND_CMD_PARAM) {
timing = IFC_FIR_OP_RBCD;
+   len = 256 * 3;
+   }
 
ifc_out32(>ifc_nand.nand_fir0,
  (IFC_FIR_OP_CW0 << IFC_NAND_FIR0_OP0_SHIFT) |
@@ -423,12 +430,8 @@ static void fsl_ifc_cmdfunc(struct mtd_info *mtd, unsigned 
int command,
  command << IFC_NAND_FCR0_CMD0_SHIFT);
ifc_out32(>ifc_nand.row3, column);
 
-   /*
-* although currently it's 8 bytes for READID, we always read
-* the maximum 256 bytes(for PARAM)
-*/
-   ifc_out32(>ifc_nand.nand_fbcr, 256);
-   ctrl->read_bytes = 256;
+   ifc_out32(>ifc_nand.nand_fbcr, len);
+   ctrl->read_bytes = len;
 
set_addr(mtd, 0, 0, 0);
fsl_ifc_run_command(mtd);
-- 
2.30.2

Re: [PATCH] doc: stm32mp1: Use u-boot.itb if CONFIG_SPL_LOAD_FIT=y

[Patrice CHOTARD]

Hi

On 3/9/21 3:32 PM, Patrice CHOTARD wrote:
> Hi Marek
> 
> On 3/6/21 9:44 PM, Marek Vasut wrote:
>> For systems where SPL loads fitImage, i.e. CONFIG_SPL_LOAD_FIT=y, use
>> u-boot.itb in the relevant documentation parts. Otherwise use u-boot.img.
>>
>> Signed-off-by: Marek Vasut 
>> Cc: Patrice Chotard 
>> Cc: Patrick Delaunay 
>> ---
>>  doc/board/st/stm32mp1.rst | 16 +++-
>>  1 file changed, 11 insertions(+), 5 deletions(-)
>>
>> diff --git a/doc/board/st/stm32mp1.rst b/doc/board/st/stm32mp1.rst
>> index 20f5c9e301e..f0c2b09b988 100644
>> --- a/doc/board/st/stm32mp1.rst
>> +++ b/doc/board/st/stm32mp1.rst
>> @@ -237,7 +237,8 @@ Build Procedure
>>- For Basic boot
>>  
>>   - FSBL = spl/u-boot-spl.stm32
>> - - SSBL = u-boot.img
>> + - SSBL = u-boot.img (without CONFIG_SPL_LOAD_FIT) or
>> +  u-boot.itb (with CONFIG_SPL_LOAD_FIT=y)
>>  
>>  Switch Setting for Boot Mode
>>  
>> @@ -347,7 +348,9 @@ c) copy the FSBL (2 times) and SSBL file on the correct 
>> partition.
>>  
>>  # dd if=u-boot-spl.stm32 of=/dev/mmcblk0p1
>>  # dd if=u-boot-spl.stm32 of=/dev/mmcblk0p2
>> -# dd if=u-boot.img of=/dev/mmcblk0p3
>> +# dd if=u-boot.img of=/dev/mmcblk0p3 # Without CONFIG_SPL_LOAD_FIT
>> +  OR
>> +  dd if=u-boot.itb of=/dev/mmcblk0p3 # With CONFIG_SPL_LOAD_FIT=y
>>  
>> for trusted boot mode: ::
>>  
>> @@ -363,8 +366,9 @@ Prepare eMMC
>>  You can use U-Boot to copy binary in eMMC.
>>  
>>  In the next example, you need to boot from SD card and the images
>> -(u-boot-spl.stm32, u-boot.img) are presents on SD card (mmc 0)
>> -in ext4 partition 4 (bootfs).
>> +(u-boot-spl.stm32, u-boot.img for systems without CONFIG_SPL_LOAD_FIT
>> +or u-boot.itb for systems with CONFIG_SPL_LOAD_FIT=y) are presents on
>> +SD card (mmc 0) in ext4 partition 4 (bootfs).
>>  
>>  To boot from SD card, select BootPinMode = 1 0 1 and reset.
>>  
>> @@ -387,7 +391,9 @@ b) copy SPL on eMMC on firts boot partition
>>  
>>  c) copy U-Boot in first GPT partition of eMMC::
>>  
>> -# ext4load mmc 0:4 0xC000 u-boo t.img
>> +# ext4load mmc 0:4 0xC000 u-boot.img # Without CONFIG_SPL_LOAD_FIT
>> +  OR
>> +  ext4load mmc 0:4 0xC000 u-boot.itb # With CONFIG_SPL_LOAD_FIT=y
>>  # mmc dev 1
>>  # part start mmc 1 1 partstart
>>  # mmc write ${fileaddr} ${partstart} ${filesize}
>>
> 
> Reviewed-by: Patrice Chotard 
> Thanks
> Patrice
> 
Applied to u-boot-stm/next

Thanks

Patrice

Re: [PATCH 2/2] video: dw_mipi_dsi: update log of dphy_enable

[Patrice CHOTARD]

Hi

On 3/4/21 4:00 PM, yannick Fertre wrote:
> Acked-by: Yannick Fertre 
> 
> 
> On 3/4/21 1:14 PM, Patrick Delaunay wrote:
>> From: Yannick Fertre 
>>
>> The DSI phy can be turned on from the DSI digital interface in
>> the dphy_enable() function or from a dedicated DSI phy "wrapper"
>> in phy_ops->init() function. If the STM32MP1 case, the wrapper
>> is used then the dphy_enable() "warning" traces are not relevant.
>>
>> This patch moves these "warning" traces to "debug" traces so
>> they are still available for DSI phy based on the digital
>> interface in debug logging mode, but not there in normal mode
>> for both cases.
>> Note: The related Linux kernel driver uses a "debug"
>> message too.
>>
>> Signed-off-by: Yannick Fertre 
>> Signed-off-by: Patrick Delaunay 
>> ---
>>
>>   drivers/video/dw_mipi_dsi.c | 8 
>>   1 file changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/video/dw_mipi_dsi.c b/drivers/video/dw_mipi_dsi.c
>> index a5beed3514..9ae09eec12 100644
>> --- a/drivers/video/dw_mipi_dsi.c
>> +++ b/drivers/video/dw_mipi_dsi.c
>> @@ -721,15 +721,15 @@ static void dw_mipi_dsi_dphy_enable(struct dw_mipi_dsi 
>> *dsi)
>>   ret = readl_poll_timeout(dsi->base + DSI_PHY_STATUS, val,
>>    val & PHY_LOCK, PHY_STATUS_TIMEOUT_US);
>>   if (ret)
>> -    dev_warn(dsi->dsi_host.dev,
>> - "failed to wait phy lock state\n");
>> +    dev_dbg(dsi->dsi_host.dev,
>> +    "failed to wait phy lock state\n");
>>     ret = readl_poll_timeout(dsi->base + DSI_PHY_STATUS,
>>    val, val & PHY_STOP_STATE_CLK_LANE,
>>    PHY_STATUS_TIMEOUT_US);
>>   if (ret)
>> -    dev_warn(dsi->dsi_host.dev,
>> - "failed to wait phy clk lane stop state\n");
>> +    dev_dbg(dsi->dsi_host.dev,
>> +    "failed to wait phy clk lane stop state\n");
>>   }
>>     static void dw_mipi_dsi_clear_err(struct dw_mipi_dsi *dsi)
>>
Applied to u-boot-stm/next

Thanks

Patrice

Re: [PATCH 1/2] video: dw_mipi_dsi: missing device to log debug

[Patrice CHOTARD]

Hi

On 3/4/21 3:59 PM, yannick Fertre wrote:
> Acked-by: Yannick Fertre 
> 
> 
> On 3/4/21 1:14 PM, Patrick Delaunay wrote:
>> From: Yannick Fertre 
>>
>> Missing udevice to struct dw_mipi_dsi to log trace.
>>
>> Signed-off-by: Yannick Fertre 
>> Signed-off-by: Patrick Delaunay 
>> ---
>>
>>   drivers/video/dw_mipi_dsi.c | 1 +
>>   1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/video/dw_mipi_dsi.c b/drivers/video/dw_mipi_dsi.c
>> index 4dde648814..a5beed3514 100644
>> --- a/drivers/video/dw_mipi_dsi.c
>> +++ b/drivers/video/dw_mipi_dsi.c
>> @@ -797,6 +797,7 @@ static int dw_mipi_dsi_init(struct udevice *dev,
>>   dsi->phy_ops = phy_ops;
>>   dsi->max_data_lanes = max_data_lanes;
>>   dsi->device = device;
>> +    dsi->dsi_host.dev = (struct device *)dev;
>>   dsi->dsi_host.ops = _mipi_dsi_host_ops;
>>   device->host = >dsi_host;
>>  
Applied to u-boot-stm/next

Thanks

Patrice

Re: [PATCH] video: stm32: remove all child of DSI bridge when its probe failed

[Patrice CHOTARD]

Hi

On 3/9/21 3:21 PM, Patrice CHOTARD wrote:
> Hi Patrick
> 
> On 3/4/21 1:10 PM, Patrick Delaunay wrote:
>> From: Patrick Delaunay 
>>
>> Remove the child device of the STM32 DSI bridge when the driver probe
>> failed to stop futher probe request on panels used with STMicroelectronics
>> board (orisetech_otm8009a.c or raydium-rm68200.c driver).
>>
>> This patch avoid the trace "cannot get reset GPIO" when
>> STM32MP157 device tree is used on stm32MP151 SOC without DSI support.
>>
>> In this hw_version value is 0, as DSI bridge is absent and the panel
>> ofdata_to_platdata is called for each try of panel probe,
>> the gpio reset pin is requested but after dsi father probe failed).
>>
>> For the next request, the PANEL ofdata_to_platdata failed as the gpio
>> is already used.
>>
>> Signed-off-by: Patrick Delaunay 
>> Signed-off-by: Patrick Delaunay 
>> ---
>>
>>  drivers/video/stm32/stm32_dsi.c | 3 +++
>>  1 file changed, 3 insertions(+)
>>
>> diff --git a/drivers/video/stm32/stm32_dsi.c 
>> b/drivers/video/stm32/stm32_dsi.c
>> index 8891ca4b78..4027e978c8 100644
>> --- a/drivers/video/stm32/stm32_dsi.c
>> +++ b/drivers/video/stm32/stm32_dsi.c
>> @@ -483,6 +483,9 @@ static int stm32_dsi_probe(struct udevice *dev)
>>  if (priv->hw_version != HWVER_130 &&
>>  priv->hw_version != HWVER_131) {
>>  dev_err(dev, "DSI version 0x%x not supported\n", 
>> priv->hw_version);
>> +dev_dbg(dev, "remove and unbind all DSI child\n");
>> +device_chld_remove(dev, NULL, DM_REMOVE_NORMAL);
>> +device_chld_unbind(dev, NULL);
>>  ret = -ENODEV;
>>  goto err_clk;
>>  }
>>
> Reviewed-by: Patrice Chotard 
> Thanks
> Patrice
> 
Applied to u-boot-stm/next

Thanks

Patrice

Re: [PATCH] configs: stm32mp15: move bootdelay configuration in defconfig

[Patrice CHOTARD]

Hi

On 3/9/21 3:21 PM, Patrice CHOTARD wrote:
> Hi Patrick
> 
> On 3/1/21 7:40 PM, Patrick Delaunay wrote:
>> The STM32MP15 boards have no reason to configure bootdelay in stm32mp1.h
>> as it is already done with CONFIG_BOOTDELAY (default = 2) and in
>> include/env_default.h.
>>
>> This patch allows configuration for customers which reuse stm32mp1.h
>> and reduce the size of the default environment.
>>
>> Signed-off-by: Patrick Delaunay 
>> ---
>>
>>  configs/stm32mp15_basic_defconfig   | 1 +
>>  configs/stm32mp15_dhcom_basic_defconfig | 1 +
>>  configs/stm32mp15_dhcor_basic_defconfig | 1 +
>>  configs/stm32mp15_trusted_defconfig | 1 +
>>  include/configs/stm32mp1.h  | 1 -
>>  5 files changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/configs/stm32mp15_basic_defconfig 
>> b/configs/stm32mp15_basic_defconfig
>> index 1c680984b8..0864d4f252 100644
>> --- a/configs/stm32mp15_basic_defconfig
>> +++ b/configs/stm32mp15_basic_defconfig
>> @@ -20,6 +20,7 @@ CONFIG_SPL_SPI_SUPPORT=y
>>  CONFIG_DEFAULT_DEVICE_TREE="stm32mp157c-ev1"
>>  CONFIG_DISTRO_DEFAULTS=y
>>  CONFIG_FIT=y
>> +CONFIG_BOOTDELAY=1
>>  CONFIG_BOOTCOMMAND="run bootcmd_stm32mp"
>>  CONFIG_SPL_LOG=y
>>  CONFIG_BOARD_EARLY_INIT_F=y
>> diff --git a/configs/stm32mp15_dhcom_basic_defconfig 
>> b/configs/stm32mp15_dhcom_basic_defconfig
>> index ed285e9161..e36d34d001 100644
>> --- a/configs/stm32mp15_dhcom_basic_defconfig
>> +++ b/configs/stm32mp15_dhcom_basic_defconfig
>> @@ -19,6 +19,7 @@ CONFIG_FIT=y
>>  CONFIG_SPL_LOAD_FIT=y
>>  CONFIG_SPL_FIT_SOURCE="board/dhelectronics/dh_stm32mp1/u-boot-dhcom.its"
>>  # CONFIG_USE_SPL_FIT_GENERATOR is not set
>> +CONFIG_BOOTDELAY=1
>>  CONFIG_BOOTCOMMAND="run bootcmd_stm32mp"
>>  CONFIG_BOARD_EARLY_INIT_F=y
>>  CONFIG_SPL_LEGACY_IMAGE_SUPPORT=y
>> diff --git a/configs/stm32mp15_dhcor_basic_defconfig 
>> b/configs/stm32mp15_dhcor_basic_defconfig
>> index a6620561ac..4794b1a14d 100644
>> --- a/configs/stm32mp15_dhcor_basic_defconfig
>> +++ b/configs/stm32mp15_dhcor_basic_defconfig
>> @@ -17,6 +17,7 @@ CONFIG_FIT=y
>>  CONFIG_SPL_LOAD_FIT=y
>>  CONFIG_SPL_FIT_SOURCE="board/dhelectronics/dh_stm32mp1/u-boot-dhcor.its"
>>  # CONFIG_USE_SPL_FIT_GENERATOR is not set
>> +CONFIG_BOOTDELAY=1
>>  CONFIG_BOOTCOMMAND="run bootcmd_stm32mp"
>>  CONFIG_BOARD_EARLY_INIT_F=y
>>  CONFIG_SPL_LEGACY_IMAGE_SUPPORT=y
>> diff --git a/configs/stm32mp15_trusted_defconfig 
>> b/configs/stm32mp15_trusted_defconfig
>> index 107041119f..4becdbb238 100644
>> --- a/configs/stm32mp15_trusted_defconfig
>> +++ b/configs/stm32mp15_trusted_defconfig
>> @@ -13,6 +13,7 @@ CONFIG_ENV_OFFSET_REDUND=0x2C
>>  CONFIG_DEFAULT_DEVICE_TREE="stm32mp157c-ev1"
>>  CONFIG_DISTRO_DEFAULTS=y
>>  CONFIG_FIT=y
>> +CONFIG_BOOTDELAY=1
>>  CONFIG_BOOTCOMMAND="run bootcmd_stm32mp"
>>  CONFIG_SYS_PROMPT="STM32MP> "
>>  CONFIG_CMD_ADTIMG=y
>> diff --git a/include/configs/stm32mp1.h b/include/configs/stm32mp1.h
>> index 36e400453e..db2117a3d7 100644
>> --- a/include/configs/stm32mp1.h
>> +++ b/include/configs/stm32mp1.h
>> @@ -160,7 +160,6 @@
>>   * and the ramdisk at the end.
>>   */
>>  #define CONFIG_EXTRA_ENV_SETTINGS \
>> -"bootdelay=1\0" \
>>  "kernel_addr_r=0xc200\0" \
>>  "fdt_addr_r=0xc400\0" \
>>  "scriptaddr=0xc410\0" \
>>
> 
> Reviewed-by: Patrice Chotard 
> Thanks
> Patrice
> 
Applied to u-boot-stm/next

Thanks

Patrice

Re: [PATCH] board: stm32mp1: use CONFIG_SYS_MMC_ENV_DEV when available

[Patrice CHOTARD]

Hi

On 3/1/21 1:17 PM, Patrick Delaunay wrote:
> Check whether user has explicitly defined the mmc device to use
> in mmc_get_env_dev() with CONFIG_SYS_MMC_ENV_DEV.
> 
> On STMicroelectronics boards the used mmc device for environment is
> the instance of boot device provided by the ROM code; the mmc instance
> is configured by alias in device tree. The used partition is defined in
> device tree with u-boot,mmc-env-partition = "ssbl".
> 
> This patch allows to override this selection for the support of customer
> boards without alias; for example when SDMMC1 is not used and ENV in
> mmc0=SDMMC2, user can force the value: CONFIG_SYS_MMC_ENV_DEV = 0.
> 
> On STMicroelectronics boards, the current behavior is kept with
> CONFIG_SYS_MMC_ENV_DEV = -1.
> 
> Signed-off-by: Patrick Delaunay 
> ---
> 
>  board/st/stm32mp1/stm32mp1.c| 8 +++-
>  configs/stm32mp15_basic_defconfig   | 1 +
>  configs/stm32mp15_trusted_defconfig | 1 +
>  3 files changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/board/st/stm32mp1/stm32mp1.c b/board/st/stm32mp1/stm32mp1.c
> index ab85d8ba68..759181fb5d 100644
> --- a/board/st/stm32mp1/stm32mp1.c
> +++ b/board/st/stm32mp1/stm32mp1.c
> @@ -862,8 +862,14 @@ const char *env_ext4_get_dev_part(void)
>  
>  int mmc_get_env_dev(void)
>  {
> - u32 bootmode = get_bootmode();
> + u32 bootmode;
> +
> + if (CONFIG_SYS_MMC_ENV_DEV >= 0)
> + return CONFIG_SYS_MMC_ENV_DEV;
> +
> + bootmode = get_bootmode();
>  
> + /* use boot instance to select the correct mmc device identifier */
>   return (bootmode & TAMP_BOOT_INSTANCE_MASK) - 1;
>  }
>  
> diff --git a/configs/stm32mp15_basic_defconfig 
> b/configs/stm32mp15_basic_defconfig
> index 1c680984b8..a2f745099e 100644
> --- a/configs/stm32mp15_basic_defconfig
> +++ b/configs/stm32mp15_basic_defconfig
> @@ -71,6 +71,7 @@ CONFIG_ENV_UBI_PART="UBI"
>  CONFIG_ENV_UBI_VOLUME="uboot_config"
>  CONFIG_ENV_UBI_VOLUME_REDUND="uboot_config_r"
>  CONFIG_SYS_RELOC_GD_ENV_ADDR=y
> +CONFIG_SYS_MMC_ENV_DEV=-1
>  # CONFIG_SPL_ENV_IS_NOWHERE is not set
>  # CONFIG_SPL_ENV_IS_IN_SPI_FLASH is not set
>  CONFIG_STM32_ADC=y
> diff --git a/configs/stm32mp15_trusted_defconfig 
> b/configs/stm32mp15_trusted_defconfig
> index 107041119f..f41aaa750f 100644
> --- a/configs/stm32mp15_trusted_defconfig
> +++ b/configs/stm32mp15_trusted_defconfig
> @@ -52,6 +52,7 @@ CONFIG_ENV_UBI_PART="UBI"
>  CONFIG_ENV_UBI_VOLUME="uboot_config"
>  CONFIG_ENV_UBI_VOLUME_REDUND="uboot_config_r"
>  CONFIG_SYS_RELOC_GD_ENV_ADDR=y
> +CONFIG_SYS_MMC_ENV_DEV=-1
>  CONFIG_STM32_ADC=y
>  CONFIG_SET_DFU_ALT_INFO=y
>  CONFIG_USB_FUNCTION_FASTBOOT=y
> 
Applied to u-boot-stm/next

Thanks

Patrice

Re: [PATCH] stm32mp: bsec: manage clock when present in device tree

[Patrice CHOTARD]

Hi

On 3/9/21 2:27 PM, Patrice CHOTARD wrote:
> Hi Patrick
> 
> On 2/25/21 1:43 PM, Patrick Delaunay wrote:
>> Enable the clocks during bsec probe when they are present in device tree.
>>
>> Signed-off-by: Patrick Delaunay 
>> ---
>>
>>  arch/arm/mach-stm32mp/bsec.c | 10 ++
>>  1 file changed, 10 insertions(+)
>>
>> diff --git a/arch/arm/mach-stm32mp/bsec.c b/arch/arm/mach-stm32mp/bsec.c
>> index 88c7aec8b4..fe39bd80cf 100644
>> --- a/arch/arm/mach-stm32mp/bsec.c
>> +++ b/arch/arm/mach-stm32mp/bsec.c
>> @@ -6,6 +6,7 @@
>>  #define LOG_CATEGORY UCLASS_MISC
>>  
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -490,6 +491,15 @@ static int stm32mp_bsec_probe(struct udevice *dev)
>>  {
>>  int otp;
>>  struct stm32mp_bsec_plat *plat;
>> +struct clk_bulk clk_bulk;
>> +int ret;
>> +
>> +ret = clk_get_bulk(dev, _bulk);
>> +if (!ret) {
>> +ret = clk_enable_bulk(_bulk);
>> +if (ret)
>> +return ret;
>> +}
>>  
>>  /*
>>   * update unlocked shadow for OTP cleared by the rom code
>>
> 
> Reviewed-by: Patrice Chotard 
> Thanks
> Patrice
> 
Applied to u-boot-stm/next

Thanks

Patrice

Re: [PATCH 4/4] stm32mp: stm32prog: replace alias by serial device sequence number

[Patrice CHOTARD]

Hi

On 3/9/21 2:14 PM, Patrice CHOTARD wrote:
> Hi Patrick
> 
> On 2/25/21 1:37 PM, Patrick Delaunay wrote:
>> The command "stm32prog serial " can directly use the device sequence
>> number of serial uclass as this sequence number is egual to alias when it
>> exist; this assumption simplify the code and avoid access to gd->fdt_blob
>> and the device tree parsing.
>>
>> Signed-off-by: Patrick Delaunay 
>> ---
>>
>>  .../cmd_stm32prog/stm32prog_serial.c  | 29 ---
>>  arch/arm/mach-stm32mp/cpu.c   | 11 +++
>>  2 files changed, 10 insertions(+), 30 deletions(-)
>>
>> diff --git a/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog_serial.c 
>> b/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog_serial.c
>> index 373ca20886..a51e5e3ec8 100644
>> --- a/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog_serial.c
>> +++ b/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog_serial.c
>> @@ -187,36 +187,19 @@ static int stm32prog_read(struct stm32prog_data *data, 
>> u8 phase, u32 offset,
>>  int stm32prog_serial_init(struct stm32prog_data *data, int link_dev)
>>  {
>>  struct udevice *dev = NULL;
>> -int node;
>> -char alias[10];
>> -const char *path;
>>  struct dm_serial_ops *ops;
>>  /* no parity, 8 bits, 1 stop */
>>  u32 serial_config = SERIAL_DEFAULT_CONFIG;
>>  
>>  down_serial_dev = NULL;
>>  
>> -sprintf(alias, "serial%d", link_dev);
>> -path = fdt_get_alias(gd->fdt_blob, alias);
>> -if (!path) {
>> -log_err("%s alias not found", alias);
>> -return -ENODEV;
>> -}
>> -node = fdt_path_offset(gd->fdt_blob, path);
>> -if (!uclass_get_device_by_of_offset(UCLASS_SERIAL, node,
>> -)) {
>> -down_serial_dev = dev;
>> -} else if (node > 0 &&
>> -   !lists_bind_fdt(gd->dm_root, offset_to_ofnode(node),
>> -   , false)) {
>> -if (!device_probe(dev))
>> -down_serial_dev = dev;
>> -}
>> -if (!down_serial_dev) {
>> -log_err("%s = %s device not found", alias, path);
>> +if (uclass_get_device_by_seq(UCLASS_SERIAL, link_dev, )) {
>> +log_err("serial %d device not found\n", link_dev);
>>  return -ENODEV;
>>  }
>>  
>> +down_serial_dev = dev;
>> +
>>  /* force silent console on uart only when used */
>>  if (gd->cur_serial_dev == down_serial_dev)
>>  gd->flags |= GD_FLG_DISABLE_CONSOLE | GD_FLG_SILENT;
>> @@ -226,11 +209,11 @@ int stm32prog_serial_init(struct stm32prog_data *data, 
>> int link_dev)
>>  ops = serial_get_ops(down_serial_dev);
>>  
>>  if (!ops) {
>> -log_err("%s = %s missing ops", alias, path);
>> +log_err("serial %d = %s missing ops\n", link_dev, dev->name);
>>  return -ENODEV;
>>  }
>>  if (!ops->setconfig) {
>> -log_err("%s = %s missing setconfig", alias, path);
>> +log_err("serial %d = %s missing setconfig\n", link_dev, 
>> dev->name);
>>  return -ENODEV;
>>  }
>>  
>> diff --git a/arch/arm/mach-stm32mp/cpu.c b/arch/arm/mach-stm32mp/cpu.c
>> index 527b6290de..9a76b5633b 100644
>> --- a/arch/arm/mach-stm32mp/cpu.c
>> +++ b/arch/arm/mach-stm32mp/cpu.c
>> @@ -466,7 +466,6 @@ static void setup_boot_mode(void)
>>  unsigned int instance = (boot_mode & TAMP_BOOT_INSTANCE_MASK) - 1;
>>  u32 forced_mode = (boot_ctx & TAMP_BOOT_FORCED_MASK);
>>  struct udevice *dev;
>> -int alias;
>>  
>>  log_debug("%s: boot_ctx=0x%x => boot_mode=%x, instance=%d forced=%x\n",
>>__func__, boot_ctx, boot_mode, instance, forced_mode);
>> @@ -474,20 +473,18 @@ static void setup_boot_mode(void)
>>  case BOOT_SERIAL_UART:
>>  if (instance > ARRAY_SIZE(serial_addr))
>>  break;
>> -/* serial : search associated alias in devicetree */
>> +/* serial : search associated node in devicetree */
>>  sprintf(cmd, "serial@%x", serial_addr[instance]);
>> -if (uclass_get_device_by_name(UCLASS_SERIAL, cmd, ) ||
>> -fdtdec_get_alias_seq(gd->fdt_blob, "serial",
>> - dev_of_offset(dev), )) {
>> +if (uclass_get_device_by_name(UCLASS_SERIAL, cmd, )) {
>>  /* restore console on error */
>>  if (IS_ENABLED(CONFIG_CMD_STM32PROG_SERIAL))
>>  gd->flags &= ~(GD_FLG_SILENT |
>> GD_FLG_DISABLE_CONSOLE);
>> -printf("serial%d = %s not found in device tree!\n",
>> +printf("uart%d = %s not found in device tree!\n",
>> instance, cmd);
>>  break;
>>  }
>> -sprintf(cmd, "%d", alias);
>> +sprintf(cmd, "%d", dev_seq(dev));
>>  env_set("boot_device", "serial");

Re: [PATCH 2/4] stm32mp: stm32prog: Add CONFIG_CMD_STM32PROG_SERIAL and _USB

[Patrice CHOTARD]

Hi

On 3/9/21 2:08 PM, Patrice CHOTARD wrote:
> Hi Patrick
> 
> On 2/25/21 1:37 PM, Patrick Delaunay wrote:
>> Add CONFIG_CMD_STM32PROG_SERIAL and CONFIG_CMD_STM32PROG_USB to
>> independently select the support of UART or USB communication for
>> STM32CubeProgrammer.
>>
>> For serial boot over UART, user can deactivate CONFIG_CMD_STM32PROG_SERIAL
>> to use U-Boot console of binary loaded by UART (for board bring-up for
>> example).
>>
>> Signed-off-by: Patrick Delaunay 
>> ---
>>
>>  arch/arm/mach-stm32mp/Makefile|  2 +-
>>  arch/arm/mach-stm32mp/cmd_stm32prog/Kconfig   | 20 ++--
>>  arch/arm/mach-stm32mp/cmd_stm32prog/Makefile  |  8 +++
>>  .../cmd_stm32prog/cmd_stm32prog.c |  4 ++--
>>  .../mach-stm32mp/cmd_stm32prog/stm32prog.h| 23 ++-
>>  arch/arm/mach-stm32mp/cpu.c   |  5 ++--
>>  board/st/common/stm32mp_dfu.c |  9 
>>  7 files changed, 55 insertions(+), 16 deletions(-)
>>
>> diff --git a/arch/arm/mach-stm32mp/Makefile b/arch/arm/mach-stm32mp/Makefile
>> index c8aa24d489..aa39867080 100644
>> --- a/arch/arm/mach-stm32mp/Makefile
>> +++ b/arch/arm/mach-stm32mp/Makefile
>> @@ -11,7 +11,7 @@ obj-y += bsec.o
>>  ifdef CONFIG_SPL_BUILD
>>  obj-y += spl.o
>>  else
>> -obj-$(CONFIG_CMD_STM32PROG) += cmd_stm32prog/
>> +obj-y += cmd_stm32prog/
>>  obj-$(CONFIG_CMD_STM32KEY) += cmd_stm32key.o
>>  obj-$(CONFIG_ARMV7_PSCI) += psci.o
>>  obj-$(CONFIG_TFABOOT) += boot_params.o
>> diff --git a/arch/arm/mach-stm32mp/cmd_stm32prog/Kconfig 
>> b/arch/arm/mach-stm32mp/cmd_stm32prog/Kconfig
>> index 609a678793..f4c0d18d4d 100644
>> --- a/arch/arm/mach-stm32mp/cmd_stm32prog/Kconfig
>> +++ b/arch/arm/mach-stm32mp/cmd_stm32prog/Kconfig
>> @@ -11,8 +11,24 @@ config CMD_STM32PROG
>>  imply DFU_MTD if MTD
>>  help
>>  activate a specific command stm32prog for STM32MP soc family
>> -witch update the device with the tools STM32CubeProgrammer,
>> -using UART with STM32 protocol or USB with DFU protocol
>> +witch update the device with the tools STM32CubeProgrammer
>>  NB: access to not volatile memory (NOR/NAND/SD/eMMC) is based
>>  on U-Boot DFU framework
>>  
>> +config CMD_STM32PROG_USB
>> +bool "support stm32prog over USB"
>> +depends on CMD_STM32PROG
>> +default y
>> +help
>> +activate the command "stm32prog usb" for STM32MP soc family
>> +witch update the device with the tools STM32CubeProgrammer,
>> +using USB with DFU protocol
>> +
>> +config CMD_STM32PROG_SERIAL
>> +bool "support stm32prog over UART"
>> +depends on CMD_STM32PROG
>> +default y
>> +help
>> +activate the command "stm32prog serial" for STM32MP soc family
>> +with the tools STM32CubeProgrammer using U-Boot serial device
>> +and UART protocol.
>> \ No newline at end of file
>> diff --git a/arch/arm/mach-stm32mp/cmd_stm32prog/Makefile 
>> b/arch/arm/mach-stm32mp/cmd_stm32prog/Makefile
>> index 548a378921..b57e1bf870 100644
>> --- a/arch/arm/mach-stm32mp/cmd_stm32prog/Makefile
>> +++ b/arch/arm/mach-stm32mp/cmd_stm32prog/Makefile
>> @@ -3,7 +3,7 @@
>>  # Copyright (C) 2020, STMicroelectronics - All Rights Reserved
>>  #
>>  
>> -obj-y += cmd_stm32prog.o
>> -obj-y += stm32prog.o
>> -obj-y += stm32prog_serial.o
>> -obj-y += stm32prog_usb.o
>> +obj-$(CONFIG_CMD_STM32PROG) += cmd_stm32prog.o
>> +obj-$(CONFIG_CMD_STM32PROG) += stm32prog.o
>> +obj-$(CONFIG_CMD_STM32PROG_SERIAL) += stm32prog_serial.o
>> +obj-$(CONFIG_CMD_STM32PROG_USB) += stm32prog_usb.o
>> diff --git a/arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c 
>> b/arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c
>> index 34a6be66c3..a7e2861764 100644
>> --- a/arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c
>> +++ b/arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c
>> @@ -50,9 +50,9 @@ static int do_stm32prog(struct cmd_tbl *cmdtp, int flag, 
>> int argc,
>>  if (argc < 3 ||  argc > 5)
>>  return CMD_RET_USAGE;
>>  
>> -if (!strcmp(argv[1], "usb"))
>> +if (IS_ENABLED(CONFIG_CMD_STM32PROG_USB) && !strcmp(argv[1], "usb"))
>>  link = LINK_USB;
>> -else if (!strcmp(argv[1], "serial"))
>> +else if (IS_ENABLED(CONFIG_CMD_STM32PROG_SERIAL) && !strcmp(argv[1], 
>> "serial"))
>>  link = LINK_SERIAL;
>>  
>>  if (link == LINK_UNDEFINED) {
>> diff --git a/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.h 
>> b/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.h
>> index be482c3402..18af99c78b 100644
>> --- a/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.h
>> +++ b/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.h
>> @@ -177,9 +177,30 @@ char *stm32prog_get_error(struct stm32prog_data *data);
>>  
>>  /* Main function */
>>  int stm32prog_init(struct stm32prog_data *data, ulong addr, ulong size);
>> +void stm32prog_clean(struct stm32prog_data *data);
>> +
>> +#ifdef 

Re: [PATCH 3/4] stm32mp: stm32prog: reactivate console and display serial error

[Patrice CHOTARD]

Hi

On 2/25/21 1:37 PM, Patrick Delaunay wrote:
> When serial instance is not found in device tree, the console
> should be enabled and the error should be indicated.
> 
> Signed-off-by: Patrick Delaunay 
> ---
> 
>  arch/arm/mach-stm32mp/cpu.c | 14 ++
>  1 file changed, 10 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arm/mach-stm32mp/cpu.c b/arch/arm/mach-stm32mp/cpu.c
> index a453f89d02..527b6290de 100644
> --- a/arch/arm/mach-stm32mp/cpu.c
> +++ b/arch/arm/mach-stm32mp/cpu.c
> @@ -476,11 +476,17 @@ static void setup_boot_mode(void)
>   break;
>   /* serial : search associated alias in devicetree */
>   sprintf(cmd, "serial@%x", serial_addr[instance]);
> - if (uclass_get_device_by_name(UCLASS_SERIAL, cmd, ))
> - break;
> - if (fdtdec_get_alias_seq(gd->fdt_blob, "serial",
> -  dev_of_offset(dev), ))
> + if (uclass_get_device_by_name(UCLASS_SERIAL, cmd, ) ||
> + fdtdec_get_alias_seq(gd->fdt_blob, "serial",
> +  dev_of_offset(dev), )) {
> + /* restore console on error */
> + if (IS_ENABLED(CONFIG_CMD_STM32PROG_SERIAL))
> + gd->flags &= ~(GD_FLG_SILENT |
> +GD_FLG_DISABLE_CONSOLE);
> + printf("serial%d = %s not found in device tree!\n",
> +instance, cmd);
>   break;
> + }
>   sprintf(cmd, "%d", alias);
>   env_set("boot_device", "serial");
>   env_set("boot_instance", cmd);
> 
Applied to u-boot-stm/next

Thanks

Patrice

Re: [Uboot-stm32] [PATCH 1/4] stm32mp: stm32prog: Add Kconfig file for stm32prog command

[Patrice CHOTARD]

Hi

On 3/9/21 2:07 PM, Patrice CHOTARD wrote:
> Hi Patrick
> 
> On 2/25/21 1:37 PM, Patrick Delaunay wrote:
>> Move CONFIG_CMD_STM32PROG in a specific Kconfig file for stm32prog command.
>>
>> Signed-off-by: Patrick Delaunay 
>> ---
>>
>>  arch/arm/mach-stm32mp/Kconfig   | 18 +-
>>  arch/arm/mach-stm32mp/cmd_stm32prog/Kconfig | 18 ++
>>  2 files changed, 19 insertions(+), 17 deletions(-)
>>  create mode 100644 arch/arm/mach-stm32mp/cmd_stm32prog/Kconfig
>>
>> diff --git a/arch/arm/mach-stm32mp/Kconfig b/arch/arm/mach-stm32mp/Kconfig
>> index f538d7cb83..079d66a80c 100644
>> --- a/arch/arm/mach-stm32mp/Kconfig
>> +++ b/arch/arm/mach-stm32mp/Kconfig
>> @@ -121,23 +121,6 @@ config STM32_ETZPC
>>  help
>>Say y to enable STM32 Extended TrustZone Protection
>>  
>> -config CMD_STM32PROG
>> -bool "command stm32prog for STM32CudeProgrammer"
>> -select DFU
>> -select DFU_RAM
>> -select DFU_VIRT
>> -select PARTITION_TYPE_GUID
>> -imply CMD_GPT if MMC
>> -imply CMD_MTD if MTD
>> -imply DFU_MMC if MMC
>> -imply DFU_MTD if MTD
>> -help
>> -activate a specific command stm32prog for STM32MP soc family
>> -witch update the device with the tools STM32CubeProgrammer,
>> -using UART with STM32 protocol or USB with DFU protocol
>> -NB: access to not volatile memory (NOR/NAND/SD/eMMC) is based
>> -on U-Boot DFU framework
>> -
>>  config CMD_STM32KEY
>>  bool "command stm32key to fuse public key hash"
>>  default y
>> @@ -177,6 +160,7 @@ config DEBUG_UART_CLOCK
>>  default 6400
>>  endif
>>  
>> +source "arch/arm/mach-stm32mp/cmd_stm32prog/Kconfig"
>>  source "board/st/stm32mp1/Kconfig"
>>  source "board/dhelectronics/dh_stm32mp1/Kconfig"
>>  
>> diff --git a/arch/arm/mach-stm32mp/cmd_stm32prog/Kconfig 
>> b/arch/arm/mach-stm32mp/cmd_stm32prog/Kconfig
>> new file mode 100644
>> index 00..609a678793
>> --- /dev/null
>> +++ b/arch/arm/mach-stm32mp/cmd_stm32prog/Kconfig
>> @@ -0,0 +1,18 @@
>> +
>> +config CMD_STM32PROG
>> +bool "command stm32prog for STM32CudeProgrammer"
>> +select DFU
>> +select DFU_RAM
>> +select DFU_VIRT
>> +select PARTITION_TYPE_GUID
>> +imply CMD_GPT if MMC
>> +imply CMD_MTD if MTD
>> +imply DFU_MMC if MMC
>> +imply DFU_MTD if MTD
>> +help
>> +activate a specific command stm32prog for STM32MP soc family
>> +witch update the device with the tools STM32CubeProgrammer,
>> +using UART with STM32 protocol or USB with DFU protocol
>> +NB: access to not volatile memory (NOR/NAND/SD/eMMC) is based
>> +on U-Boot DFU framework
>> +
>>
> 
> 
> Reviewed-by: Patrice Chotard 
> 
> Thanks
> Patrice
> ___
> Uboot-stm32 mailing list
> uboot-st...@st-md-mailman.stormreply.com
> https://st-md-mailman.stormreply.com/mailman/listinfo/uboot-stm32
> 
Applied to u-boot-stm/next

Thanks

Patrice

Re: [PATCH] board: st: remove the nand MTD configuration for NOR boot in stm32mp1 board

[Patrice CHOTARD]

Hi

On 3/9/21 2:06 PM, Patrice CHOTARD wrote:
> Hi Patrick
> 
> On 2/25/21 11:49 AM, Patrick Delaunay wrote:
>> Since commit d5d726d3cc47 ("configs: stm32mp1: only support SD card after
>> NOR in bootcmd_stm32mp"), the stm32mp1 boards only support SD card after
>> NOR boot device, so the MTD partitions for nand0 or spi-nand0 are useless
>> (no need of "UBI" partition in nand0 or spi-nand0).
>>
>> This patch removes these nand MTD update for nor boot and simplify nand0
>> and spi-nand0 support (remove the mtd_boot variable).
>>
>> Signed-off-by: Patrick Delaunay 
>> Signed-off-by: Patrick Delaunay 
>> ---
>>
>>  board/st/common/stm32mp_mtdparts.c | 16 +---
>>  1 file changed, 5 insertions(+), 11 deletions(-)
>>
>> diff --git a/board/st/common/stm32mp_mtdparts.c 
>> b/board/st/common/stm32mp_mtdparts.c
>> index 69eb10844d..f074fc189d 100644
>> --- a/board/st/common/stm32mp_mtdparts.c
>> +++ b/board/st/common/stm32mp_mtdparts.c
>> @@ -122,28 +122,24 @@ void board_mtdparts_default(const char **mtdids, const 
>> char **mtdparts)
>>  log_debug("mtd device = %s\n", dev->name);
>>  }
>>  
>> -if (nor || nand) {
>> +if (nand) {
>>  mtd = get_mtd_device_nm("nand0");
>>  if (!IS_ERR_OR_NULL(mtd)) {
>> -const char *mtd_boot = CONFIG_MTDPARTS_NAND0_BOOT;
>>  const char *mtd_tee = CONFIG_MTDPARTS_NAND0_TEE;
>> -
>>  board_set_mtdparts("nand0", ids, parts,
>> -   !nor ? mtd_boot : NULL,
>> +   CONFIG_MTDPARTS_NAND0_BOOT,
>> !nor && tee ? mtd_tee : NULL,
>> "-(UBI)");
>>  put_mtd_device(mtd);
>>  }
>>  }
>>  
>> -if (nor || spinand) {
>> +if (spinand) {
>>  mtd = get_mtd_device_nm("spi-nand0");
>>  if (!IS_ERR_OR_NULL(mtd)) {
>> -const char *mtd_boot = CONFIG_MTDPARTS_SPINAND0_BOOT;
>>  const char *mtd_tee = CONFIG_MTDPARTS_SPINAND0_TEE;
>> -
>>  board_set_mtdparts("spi-nand0", ids, parts,
>> -   !nor ? mtd_boot : NULL,
>> +   CONFIG_MTDPARTS_SPINAND0_BOOT,
>> !nor && tee ? mtd_tee : NULL,
>> "-(UBI)");
>>  put_mtd_device(mtd);
>> @@ -152,11 +148,9 @@ void board_mtdparts_default(const char **mtdids, const 
>> char **mtdparts)
>>  
>>  if (nor) {
>>  if (!uclass_get_device(UCLASS_SPI_FLASH, 0, )) {
>> -const char *mtd_boot = CONFIG_MTDPARTS_NOR0_BOOT;
>>  const char *mtd_tee = CONFIG_MTDPARTS_NOR0_TEE;
>> -
>>  board_set_mtdparts("nor0", ids, parts,
>> -   mtd_boot,
>> +   CONFIG_MTDPARTS_NOR0_BOOT,
>> tee ? mtd_tee : NULL,
>> "-(nor_user)");
>>  }
>>
> 
> 
> 
> Reviewed-by: Patrice Chotard 
> 
> Thanks
> Patrice
> 
Applied to u-boot-stm/next

Thanks

Patrice

Re: [Uboot-stm32] [PATCH 5/6] scmi: cosmetic: reorder include files

[Patrice CHOTARD]

Hi

On 3/12/21 1:26 PM, Patrice CHOTARD wrote:
> 
> 
> On 3/9/21 2:04 PM, Patrice CHOTARD wrote:
>> Hi Patrick
>>
>> On 2/24/21 11:19 AM, Patrick Delaunay wrote:
>>> Reorder include files in expected order.
>>>
>>> Signed-off-by: Patrick Delaunay 
>>> ---
>>>
>>>  drivers/firmware/scmi/mailbox_agent.c | 2 +-
>>>  drivers/firmware/scmi/scmi_agent-uclass.c | 3 +--
>>>  2 files changed, 2 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/firmware/scmi/mailbox_agent.c 
>>> b/drivers/firmware/scmi/mailbox_agent.c
>>> index 8043e2c2de..ea35e7e09e 100644
>>> --- a/drivers/firmware/scmi/mailbox_agent.c
>>> +++ b/drivers/firmware/scmi/mailbox_agent.c
>>> @@ -7,11 +7,11 @@
>>>  
>>>  #include 
>>>  #include 
>>> -#include 
>>>  #include 
>>>  #include 
>>>  #include 
>>>  #include 
>>> +#include 
>>>  #include 
>>>  #include 
>>>  
>>> diff --git a/drivers/firmware/scmi/scmi_agent-uclass.c 
>>> b/drivers/firmware/scmi/scmi_agent-uclass.c
>>> index 2491e0a747..527163b5ce 100644
>>> --- a/drivers/firmware/scmi/scmi_agent-uclass.c
>>> +++ b/drivers/firmware/scmi/scmi_agent-uclass.c
>>> @@ -7,11 +7,10 @@
>>>  
>>>  #include 
>>>  #include 
>>> -#include 
>>>  #include 
>>>  #include 
>>>  #include 
>>> -
>>> +#include 
>>>  #include 
>>>  #include 
>>>  
>>>
>>
>>
>> Reviewed-by: Patrice Chotard 
>>
>> Thanks
>> Patrice
>>
> Applied to u-boot-stm/next
> 
> Thanks
> 
> Patrice
> 
Applied to u-boot-stm/next

Thanks

Patrice

Re: [Uboot-stm32] [PATCH 5/6] scmi: cosmetic: reorder include files

[Patrice CHOTARD]

On 3/9/21 2:04 PM, Patrice CHOTARD wrote:
> Hi Patrick
> 
> On 2/24/21 11:19 AM, Patrick Delaunay wrote:
>> Reorder include files in expected order.
>>
>> Signed-off-by: Patrick Delaunay 
>> ---
>>
>>  drivers/firmware/scmi/mailbox_agent.c | 2 +-
>>  drivers/firmware/scmi/scmi_agent-uclass.c | 3 +--
>>  2 files changed, 2 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/firmware/scmi/mailbox_agent.c 
>> b/drivers/firmware/scmi/mailbox_agent.c
>> index 8043e2c2de..ea35e7e09e 100644
>> --- a/drivers/firmware/scmi/mailbox_agent.c
>> +++ b/drivers/firmware/scmi/mailbox_agent.c
>> @@ -7,11 +7,11 @@
>>  
>>  #include 
>>  #include 
>> -#include 
>>  #include 
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  
>> diff --git a/drivers/firmware/scmi/scmi_agent-uclass.c 
>> b/drivers/firmware/scmi/scmi_agent-uclass.c
>> index 2491e0a747..527163b5ce 100644
>> --- a/drivers/firmware/scmi/scmi_agent-uclass.c
>> +++ b/drivers/firmware/scmi/scmi_agent-uclass.c
>> @@ -7,11 +7,10 @@
>>  
>>  #include 
>>  #include 
>> -#include 
>>  #include 
>>  #include 
>>  #include 
>> -
>> +#include 
>>  #include 
>>  #include 
>>  
>>
> 
> 
> Reviewed-by: Patrice Chotard 
> 
> Thanks
> Patrice
> 
Applied to u-boot-stm/next

Thanks

Patrice

Re: [Uboot-stm32] [PATCH 4/6] scmi: define LOG_CATEGORY

[Patrice CHOTARD]

Hi

On 3/9/21 2:03 PM, Patrice CHOTARD wrote:
> Hi Patrick
> 
> On 2/24/21 11:19 AM, Patrick Delaunay wrote:
>> Define LOG_CATEGORY to allow filtering with log command.
>>
>> Signed-off-by: Patrick Delaunay 
>> ---
>>
>>  drivers/firmware/scmi/mailbox_agent.c| 2 ++
>>  drivers/firmware/scmi/sandbox-scmi_agent.c   | 2 ++
>>  drivers/firmware/scmi/sandbox-scmi_devices.c | 2 ++
>>  drivers/firmware/scmi/scmi_agent-uclass.c| 2 ++
>>  drivers/firmware/scmi/smccc_agent.c  | 2 ++
>>  drivers/firmware/scmi/smt.c  | 2 ++
>>  6 files changed, 12 insertions(+)
>>
>> diff --git a/drivers/firmware/scmi/mailbox_agent.c 
>> b/drivers/firmware/scmi/mailbox_agent.c
>> index 3f4b04a4ae..8043e2c2de 100644
>> --- a/drivers/firmware/scmi/mailbox_agent.c
>> +++ b/drivers/firmware/scmi/mailbox_agent.c
>> @@ -3,6 +3,8 @@
>>   * Copyright (C) 2020 Linaro Limited.
>>   */
>>  
>> +#define LOG_CATEGORY UCLASS_SCMI_AGENT
>> +
>>  #include 
>>  #include 
>>  #include 
>> diff --git a/drivers/firmware/scmi/sandbox-scmi_agent.c 
>> b/drivers/firmware/scmi/sandbox-scmi_agent.c
>> index 35de68c75d..97a5dace15 100644
>> --- a/drivers/firmware/scmi/sandbox-scmi_agent.c
>> +++ b/drivers/firmware/scmi/sandbox-scmi_agent.c
>> @@ -3,6 +3,8 @@
>>   * Copyright (C) 2020, Linaro Limited
>>   */
>>  
>> +#define LOG_CATEGORY UCLASS_SCMI_AGENT
>> +
>>  #include 
>>  #include 
>>  #include 
>> diff --git a/drivers/firmware/scmi/sandbox-scmi_devices.c 
>> b/drivers/firmware/scmi/sandbox-scmi_devices.c
>> index 1a6fafbf53..69239a198f 100644
>> --- a/drivers/firmware/scmi/sandbox-scmi_devices.c
>> +++ b/drivers/firmware/scmi/sandbox-scmi_devices.c
>> @@ -3,6 +3,8 @@
>>   * Copyright (C) 2020, Linaro Limited
>>   */
>>  
>> +#define LOG_CATEGORY UCLASS_MISC
>> +
>>  #include 
>>  #include 
>>  #include 
>> diff --git a/drivers/firmware/scmi/scmi_agent-uclass.c 
>> b/drivers/firmware/scmi/scmi_agent-uclass.c
>> index 516e690ac2..2491e0a747 100644
>> --- a/drivers/firmware/scmi/scmi_agent-uclass.c
>> +++ b/drivers/firmware/scmi/scmi_agent-uclass.c
>> @@ -3,6 +3,8 @@
>>   * Copyright (C) 2020 Linaro Limited.
>>   */
>>  
>> +#define LOG_CATEGORY UCLASS_SCMI_AGENT
>> +
>>  #include 
>>  #include 
>>  #include 
>> diff --git a/drivers/firmware/scmi/smccc_agent.c 
>> b/drivers/firmware/scmi/smccc_agent.c
>> index 81c2884bb7..f185891e8f 100644
>> --- a/drivers/firmware/scmi/smccc_agent.c
>> +++ b/drivers/firmware/scmi/smccc_agent.c
>> @@ -3,6 +3,8 @@
>>   * Copyright (C) 2020 Linaro Limited.
>>   */
>>  
>> +#define LOG_CATEGORY UCLASS_SCMI_AGENT
>> +
>>  #include 
>>  #include 
>>  #include 
>> diff --git a/drivers/firmware/scmi/smt.c b/drivers/firmware/scmi/smt.c
>> index d25478796a..60b9d499b7 100644
>> --- a/drivers/firmware/scmi/smt.c
>> +++ b/drivers/firmware/scmi/smt.c
>> @@ -4,6 +4,8 @@
>>   * Copyright (C) 2019-2020 Linaro Limited.
>>   */
>>  
>> +#define LOG_CATEGORY UCLASS_SCMI_AGENT
>> +
>>  #include 
>>  #include 
>>  #include 
>>
> 
> Reviewed-by: Patrice Chotard 
> 
> Thanks
> Patrice
> ___
> Uboot-stm32 mailing list
> uboot-st...@st-md-mailman.stormreply.com
> https://st-md-mailman.stormreply.com/mailman/listinfo/uboot-stm32
> 

Applied to u-boot-stm/next

Thanks

Patrice

Re: [Uboot-stm32] [PATCH 3/6] scmi: Include device_compat.h

[Patrice CHOTARD]

HI

On 3/9/21 2:03 PM, Patrice CHOTARD wrote:
> Hi Patrick
> 
> On 2/24/21 11:19 AM, Patrick Delaunay wrote:
>> Include the file needed for log function prototype, this patch solves the
>> compilation issue for undefined reference to `dev_err'.
>>
>> Signed-off-by: Patrick Delaunay 
>> ---
>>
>>  drivers/firmware/scmi/smccc_agent.c | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/firmware/scmi/smccc_agent.c 
>> b/drivers/firmware/scmi/smccc_agent.c
>> index 64d0929f69..81c2884bb7 100644
>> --- a/drivers/firmware/scmi/smccc_agent.c
>> +++ b/drivers/firmware/scmi/smccc_agent.c
>> @@ -9,6 +9,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>>
> 
> Reviewed-by: Patrice Chotard 
> 
> Thanks
> Patrice
> 
Applied to u-boot-stm/next

Thanks

Patrice

Re: [Uboot-stm32] [PATCH 2/6] clk: stm32mp1: gets root clocks from fdt

[Patrice CHOTARD]

Hi

On 3/9/21 2:02 PM, Patrice CHOTARD wrote:
> Hi Patrick
> 
> On 2/24/21 11:19 AM, Patrick Delaunay wrote:
>> From: Etienne Carriere 
>>
>> This change makes stm32mp1 clock driver to get the root clocks
>> reference from the device node in the FDT rather than fetching
>> straight these clocks by their name. Driver now stores the
>> clock reference and use it to know if a root clock is present,
>> get its rate or gets its related udevice reference.
>>
>> Signed-off-by: Etienne Carriere 
>> Signed-off-by: Patrick Delaunay 
>> ---
>>
>>  drivers/clk/clk_stm32mp1.c | 62 ++
>>  1 file changed, 23 insertions(+), 39 deletions(-)
>>
>> diff --git a/drivers/clk/clk_stm32mp1.c b/drivers/clk/clk_stm32mp1.c
>> index 848e33f4e8..0c0ef366a1 100644
>> --- a/drivers/clk/clk_stm32mp1.c
>> +++ b/drivers/clk/clk_stm32mp1.c
>> @@ -250,7 +250,7 @@ DECLARE_GLOBAL_DATA_PTR;
>>  enum stm32mp1_parent_id {
>>  /*
>>   * _HSI, _HSE, _CSI, _LSI, _LSE should not be moved
>> - * they are used as index in osc[] as entry point
>> + * they are used as index in osc_clk[] as clock reference
>>   */
>>  _HSI,
>>  _HSE,
>> @@ -430,8 +430,7 @@ struct stm32mp1_clk_data {
>>  struct stm32mp1_clk_priv {
>>  fdt_addr_t base;
>>  const struct stm32mp1_clk_data *data;
>> -ulong osc[NB_OSC];
>> -struct udevice *osc_dev[NB_OSC];
>> +struct clk osc_clk[NB_OSC];
>>  };
>>  
>>  #define STM32MP1_CLK(off, b, idx, s)\
>> @@ -790,7 +789,7 @@ static ulong stm32mp1_clk_get_fixed(struct 
>> stm32mp1_clk_priv *priv, int idx)
>>  return 0;
>>  }
>>  
>> -return priv->osc[idx];
>> +return clk_get_rate(>osc_clk[idx]);
>>  }
>>  
>>  static int stm32mp1_clk_get_id(struct stm32mp1_clk_priv *priv, unsigned 
>> long id)
>> @@ -1545,7 +1544,7 @@ static int stm32mp1_hsidiv(fdt_addr_t rcc, ulong 
>> hsifreq)
>>  break;
>>  
>>  if (hsidiv == 4) {
>> -log_err("clk-hsi frequency invalid");
>> +log_err("hsi frequency invalid");
>>  return -1;
>>  }
>>  
>> @@ -1952,13 +1951,13 @@ static int stm32mp1_clktree(struct udevice *dev)
>>   * switch ON oscillator found in device-tree,
>>   * HSI already ON after bootrom
>>   */
>> -if (priv->osc[_LSI])
>> +if (clk_valid(>osc_clk[_LSI]))
>>  stm32mp1_lsi_set(rcc, 1);
>>  
>> -if (priv->osc[_LSE]) {
>> +if (clk_valid(>osc_clk[_LSE])) {
>>  int bypass, digbyp;
>>  u32 lsedrv;
>> -struct udevice *dev = priv->osc_dev[_LSE];
>> +struct udevice *dev = priv->osc_clk[_LSE].dev;
>>  
>>  bypass = dev_read_bool(dev, "st,bypass");
>>  digbyp = dev_read_bool(dev, "st,digbypass");
>> @@ -1969,9 +1968,9 @@ static int stm32mp1_clktree(struct udevice *dev)
>>  stm32mp1_lse_enable(rcc, bypass, digbyp, lsedrv);
>>  }
>>  
>> -if (priv->osc[_HSE]) {
>> +if (clk_valid(>osc_clk[_HSE])) {
>>  int bypass, digbyp, css;
>> -struct udevice *dev = priv->osc_dev[_HSE];
>> +struct udevice *dev = priv->osc_clk[_HSE].dev;
>>  
>>  bypass = dev_read_bool(dev, "st,bypass");
>>  digbyp = dev_read_bool(dev, "st,digbypass");
>> @@ -1996,8 +1995,8 @@ static int stm32mp1_clktree(struct udevice *dev)
>>  
>>  /* configure HSIDIV */
>>  dev_dbg(dev, "configure HSIDIV\n");
>> -if (priv->osc[_HSI]) {
>> -stm32mp1_hsidiv(rcc, priv->osc[_HSI]);
>> +if (clk_valid(>osc_clk[_HSI])) {
>> +stm32mp1_hsidiv(rcc, clk_get_rate(>osc_clk[_HSI]));
>>  stgen_config(priv);
>>  }
>>  
>> @@ -2043,7 +2042,7 @@ static int stm32mp1_clktree(struct udevice *dev)
>>  }
>>  
>>  /* wait LSE ready before to use it */
>> -if (priv->osc[_LSE])
>> +if (clk_valid(>osc_clk[_LSE]))
>>  stm32mp1_lse_wait(rcc);
>>  
>>  /* configure with expected clock source */
>> @@ -2082,7 +2081,7 @@ static int stm32mp1_clktree(struct udevice *dev)
>>  
>>  dev_dbg(dev, "oscillator off\n");
>>  /* switch OFF HSI if not found in device-tree */
>> -if (!priv->osc[_HSI])
>> +if (!clk_valid(>osc_clk[_HSI]))
>>  stm32mp1_hsi_set(rcc, 0);
>>  
>>  /* Software Self-Refresh mode (SSR) during DDR initilialization */
>> @@ -2178,40 +2177,25 @@ static ulong stm32mp1_clk_set_rate(struct clk *clk, 
>> unsigned long clk_rate)
>>  return -EINVAL;
>>  }
>>  
>> -static void stm32mp1_osc_clk_init(const char *name,
>> -  struct stm32mp1_clk_priv *priv,
>> -  int index)
>> -{
>> -struct clk clk;
>> -struct udevice *dev = NULL;
>> -
>> -priv->osc[index] = 0;
>> -clk.id = 0;
>> -if (!uclass_get_device_by_name(UCLASS_CLK, name, )) {
>> -if (clk_request(dev, ))
>> -log_err("%s request", name);
>> -else
>> -priv->osc[index] 

Re: [PATCH 1/6] ARM: dts: stm32mp1: explicit clock reference needed by RCC clock driver

[Patrice CHOTARD]

HI

On 3/9/21 1:57 PM, Patrice CHOTARD wrote:
> Hi Patrick
> 
> On 2/24/21 11:19 AM, Patrick Delaunay wrote:
>> From: Etienne Carriere 
>>
>> Define in the RCC clock provider node which root clocks the driver
>> depends on. These are root oscillators, which may be present or
>> not, upon FDT content.
>>
>> This update binding is introduced in Linux kernel device tree by patch
>> "ARM: dts: stm32: move clocks/resets to SCMI resources for stm32mp15"
>>
>> This patch is a preliminary step for SCMI support of stm32mp15
>> boards with trusted boot chain, based on TF-A or OP-TEE.
>>
>> Signed-off-by: Etienne Carriere 
>> Signed-off-by: Patrick Delaunay 
>> ---
>>
>> Reference:
>>
>> https://patchwork.kernel.org/project/linux-arm-kernel/patch/20210126090120.19900-13-gabriel.fernan...@foss.st.com/
>>
>>
>>  arch/arm/dts/stm32mp151.dtsi | 4 
>>  1 file changed, 4 insertions(+)
>>
>> diff --git a/arch/arm/dts/stm32mp151.dtsi b/arch/arm/dts/stm32mp151.dtsi
>> index eedea6f4b8..b564fc6269 100644
>> --- a/arch/arm/dts/stm32mp151.dtsi
>> +++ b/arch/arm/dts/stm32mp151.dtsi
>> @@ -1136,6 +1136,10 @@
>>  reg = <0x5000 0x1000>;
>>  #clock-cells = <1>;
>>  #reset-cells = <1>;
>> +
>> +clock-names = "hse", "hsi", "csi", "lse", "lsi";
>> +clocks = <_hse>, <_hsi>, <_csi>,
>> + <_lse>, <_lsi>;
>>  };
>>  
>>  pwr_regulators: pwr@50001000 {
>>
> 
> Reviewed-by: Patrice Chotard 
> 
Applied to u-boot-stm/next

Thanks

Patrice

Re: [PATCH 1/6] ARM: dts: stm32mp1: explicit clock reference needed by RCC clock driver

[Patrice CHOTARD]

HI

On 3/9/21 1:57 PM, Patrice CHOTARD wrote:
> Hi Patrick
> 
> On 2/24/21 11:19 AM, Patrick Delaunay wrote:
>> From: Etienne Carriere 
>>
>> Define in the RCC clock provider node which root clocks the driver
>> depends on. These are root oscillators, which may be present or
>> not, upon FDT content.
>>
>> This update binding is introduced in Linux kernel device tree by patch
>> "ARM: dts: stm32: move clocks/resets to SCMI resources for stm32mp15"
>>
>> This patch is a preliminary step for SCMI support of stm32mp15
>> boards with trusted boot chain, based on TF-A or OP-TEE.
>>
>> Signed-off-by: Etienne Carriere 
>> Signed-off-by: Patrick Delaunay 
>> ---
>>
>> Reference:
>>
>> https://patchwork.kernel.org/project/linux-arm-kernel/patch/20210126090120.19900-13-gabriel.fernan...@foss.st.com/
>>
>>
>>  arch/arm/dts/stm32mp151.dtsi | 4 
>>  1 file changed, 4 insertions(+)
>>
>> diff --git a/arch/arm/dts/stm32mp151.dtsi b/arch/arm/dts/stm32mp151.dtsi
>> index eedea6f4b8..b564fc6269 100644
>> --- a/arch/arm/dts/stm32mp151.dtsi
>> +++ b/arch/arm/dts/stm32mp151.dtsi
>> @@ -1136,6 +1136,10 @@
>>  reg = <0x5000 0x1000>;
>>  #clock-cells = <1>;
>>  #reset-cells = <1>;
>> +
>> +clock-names = "hse", "hsi", "csi", "lse", "lsi";
>> +clocks = <_hse>, <_hsi>, <_csi>,
>> + <_lse>, <_lsi>;
>>  };
>>  
>>  pwr_regulators: pwr@50001000 {
>>
> 
> Reviewed-by: Patrice Chotard 
> 
Applied to u-boot-stm/next

Thanks

Patrice

Re: [Uboot-stm32] [PATCH 4/4] mtd: spinand: Add WATCHDOG_RESET() in spinand_mtd_read/write()

[Patrice CHOTARD]

Hi

On 1/27/21 4:19 PM, Patrick DELAUNAY wrote:
> Hi,
> 
> On 1/20/21 2:42 PM, Patrice Chotard wrote:
>> In case of big area read/write on spi nand, watchdog timeout may occurs.
>> To fix that, add WATCHDOG_RESET() in spinand_mtd_read() and
>> spinand_mtd_write() to ensure that watchdog is reset.
>>
>> Signed-off-by: Patrice Chotard 
>>
>> ---
>>
>>   drivers/mtd/nand/spi/core.c | 3 +++
>>   1 file changed, 3 insertions(+)
>>
>> diff --git a/drivers/mtd/nand/spi/core.c b/drivers/mtd/nand/spi/core.c
>> index cb8ffa3fa9..7f54422c93 100644
>> --- a/drivers/mtd/nand/spi/core.c
>> +++ b/drivers/mtd/nand/spi/core.c
>> @@ -24,6 +24,7 @@
>>   #include 
>>   #include 
>>   #include 
>> +#include 
>>   #include 
>>   #endif
>>   @@ -574,6 +575,7 @@ static int spinand_mtd_read(struct mtd_info *mtd, 
>> loff_t from,
>>   #endif
>>     nanddev_io_for_each_page(nand, from, ops, ) {
>> +    WATCHDOG_RESET();
>>   ret = spinand_select_target(spinand, iter.req.pos.target);
>>   if (ret)
>>   break;
>> @@ -625,6 +627,7 @@ static int spinand_mtd_write(struct mtd_info *mtd, 
>> loff_t to,
>>   #endif
>>     nanddev_io_for_each_page(nand, to, ops, ) {
>> +    WATCHDOG_RESET();
>>   ret = spinand_select_target(spinand, iter.req.pos.target);
>>   if (ret)
>>   break;
> 
> 
> Reviewed-by: Patrick Delaunay 
> 
> Thanks
> 
> Patrick
> 
> 
Applied to u-boot-stm/next

Thanks

Patrice

Re: [Uboot-stm32] [PATCH 3/4] mtd: nand: Add WATCHDOG_RESET() in nanddev_mtd_erase()

[Patrice CHOTARD]

Hi

On 1/27/21 4:15 PM, Patrick DELAUNAY wrote:
> Hi Patrice,
> 
> On 1/20/21 2:42 PM, Patrice Chotard wrote:
>> In case of big area erased on nand, watchdog timeout may occurs.
>> To fix that, add WATCHDOG_RESET() in nanddev_mtd_erase() to ensure that
>> watchdog is reset.
>>
>> Signed-off-by: Patrice Chotard 
>> ---
>>
>>   drivers/mtd/nand/core.c | 2 ++
>>   1 file changed, 2 insertions(+)
>>
>> diff --git a/drivers/mtd/nand/core.c b/drivers/mtd/nand/core.c
>> index 3abaef23c5..ec11bf44f8 100644
>> --- a/drivers/mtd/nand/core.c
>> +++ b/drivers/mtd/nand/core.c
>> @@ -10,6 +10,7 @@
>>   #define pr_fmt(fmt)    "nand: " fmt
>>     #include 
>> +#include 
>>   #ifndef __UBOOT__
>>   #include 
>>   #endif
>> @@ -162,6 +163,7 @@ int nanddev_mtd_erase(struct mtd_info *mtd, struct 
>> erase_info *einfo)
>>   nanddev_offs_to_pos(nand, einfo->addr, );
>>   nanddev_offs_to_pos(nand, einfo->addr + einfo->len - 1, );
>>   while (nanddev_pos_cmp(, ) <= 0) {
>> +    WATCHDOG_RESET();
>>   ret = nanddev_erase(nand, );
>>   if (ret) {
>>   einfo->fail_addr = nanddev_pos_to_offs(nand, );
> 
> 
> Reviewed-by: Patrick Delaunay 
> 
> Thanks
> 
> Patrick
> 
Applied to u-boot-stm/next

Thanks

Patrice

Re: [Uboot-stm32] [PATCH 2/4] spi: stm32_qspi: Add WATCHDOG_RESET in _stm32_qspi_read_fifo()

[Patrice CHOTARD]

Hi

On 1/27/21 4:15 PM, Patrick DELAUNAY wrote:
> Hi Patrice
> 
> On 1/20/21 2:42 PM, Patrice Chotard wrote:
>> In case of reading large area and memory-map mode is misconfigured
>> (memory-map size declared lower than the real size of the memory chip)
>> watchdog can be triggered.
>>
>> Add WATCHDOG_RESET() in _stm32_qspi_read_fifo to fix it.
>>
>> Issue reproduced with stm32mp157c-ev1 board and memory map size set to
>> 1, with following command:
>> sf read 0xC000 0 0x400
>>
>> Signed-off-by: Patrice Chotard 
>> ---
>>
>>   drivers/spi/stm32_qspi.c | 2 ++
>>   1 file changed, 2 insertions(+)
>>
>> diff --git a/drivers/spi/stm32_qspi.c b/drivers/spi/stm32_qspi.c
>> index 958c394a1a..c3da17f991 100644
>> --- a/drivers/spi/stm32_qspi.c
>> +++ b/drivers/spi/stm32_qspi.c
>> @@ -11,6 +11,7 @@
>>   #include 
>>   #include 
>>   #include 
>> +#include 
>>   #include 
>>   #include 
>>   #include 
>> @@ -163,6 +164,7 @@ static int _stm32_qspi_wait_cmd(struct stm32_qspi_priv 
>> *priv,
>>   static void _stm32_qspi_read_fifo(u8 *val, void __iomem *addr)
>>   {
>>   *val = readb(addr);
>> +    WATCHDOG_RESET();
>>   }
>>     static void _stm32_qspi_write_fifo(u8 *val, void __iomem *addr)
> 
> 
> Reviewed-by: Patrick Delaunay 
> 
> Thanks
> 
> Patrick
> 
Applied to u-boot-stm/next

Thanks

Patrice

Re: [Uboot-stm32] [PATCH 1/4] mtd: spi-nor: Add WATCHDOG_RESET() in spi_nor_core callbacks

[Patrice CHOTARD]

Hi

On 1/27/21 4:14 PM, Patrick DELAUNAY wrote:
> Hi Patrice,
> 
> On 1/20/21 2:42 PM, Patrice Chotard wrote:
>> In case of big area write/erase on spi nor, watchdog timeout may occurs.
>> Issue reproduced on stm32mp157c-ev1 with following commands:
>>
>> sf write 0xC000 0 0x300
>> or
>> sf erase 0 0x100
>>
>> Signed-off-by: Patrice Chotard 
>> ---
>>
>>   drivers/mtd/spi/spi-nor-core.c | 3 +++
>>   1 file changed, 3 insertions(+)
>>
>> diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
>> index eb49a6c11c..51e0613d4c 100644
>> --- a/drivers/mtd/spi/spi-nor-core.c
>> +++ b/drivers/mtd/spi/spi-nor-core.c
>> @@ -10,6 +10,7 @@
>>    */
>>     #include 
>> +#include 
>>   #include 
>>   #include 
>>   #include 
>> @@ -557,6 +558,7 @@ static int spi_nor_erase(struct mtd_info *mtd, struct 
>> erase_info *instr)
>>   len = instr->len;
>>     while (len) {
>> +    WATCHDOG_RESET();
>>   #ifdef CONFIG_SPI_FLASH_BAR
>>   ret = write_bar(nor, addr);
>>   if (ret < 0)
>> @@ -1235,6 +1237,7 @@ static int spi_nor_write(struct mtd_info *mtd, loff_t 
>> to, size_t len,
>>   for (i = 0; i < len; ) {
>>   ssize_t written;
>>   loff_t addr = to + i;
>> +    WATCHDOG_RESET();
>>     /*
>>    * If page_size is a power of two, the offset can be quickly
> 
> 
> Reviewed-by: Patrick Delaunay 
> 
> Thanks
> 
> Patrick
> 
> 

Applied to u-boot-stm/next

Thanks

Patrice

Re: [PATCH 2/2] board: st: Remove board_early_init_f and board_late_init callbacks for stm32 boards

[Patrice CHOTARD]

Hi

On 3/12/21 10:51 AM, Patrick DELAUNAY wrote:
> Hi Patrice
> 
> On 2/24/21 1:38 PM, Patrice Chotard wrote:
>> Remove board_early_init_f() and board_late_init() callbacks for stm32
>> boards as the corresponding flags (CONFIG_BOARD_LATE_INIT and
>> CONFIG_BOARD_EARLY_INIT_R) are now disabled.
>>
>> Signed-off-by: Patrice Chotard 
>> ---
>>
>>   board/st/stm32f429-discovery/stm32f429-discovery.c   |  5 -
>>   board/st/stm32f429-evaluation/stm32f429-evaluation.c |  5 -
>>   board/st/stm32f469-discovery/stm32f469-discovery.c   |  5 -
>>   board/st/stm32f746-disco/stm32f746-disco.c   |  5 -
>>   board/st/stm32h743-disco/stm32h743-disco.c   | 10 --
>>   board/st/stm32h743-eval/stm32h743-eval.c | 10 --
>>   6 files changed, 40 deletions(-)
>>
> 
> Reviewed-by: Patrick Delaunay 
> 
> Thanks
> Patrick
> 

Applied to u-boot-stm/next

Thanks

Patrice

Re: [PATCH 1/2] configs: stm32: Remove BOARD_EARLY_INIT_F and BOARD_LATE_INIT for stm32 boards

[Patrice CHOTARD]

Hi

On 2/24/21 1:38 PM, Patrice Chotard wrote:
> These flags was defined and callbacks linked to these flags are empty
> and only returning 0.
> Remove BOARD_EARLY_INIT_F and BOARD_LATE_INIT flags for these stm32 boards.
> 
> Signed-off-by: Patrice Chotard 
> ---
> 
>  configs/stm32f429-discovery_defconfig  | 1 -
>  configs/stm32f429-evaluation_defconfig | 1 -
>  configs/stm32f469-discovery_defconfig  | 1 -
>  configs/stm32f746-disco_defconfig  | 1 -
>  configs/stm32f769-disco_defconfig  | 2 --
>  configs/stm32h743-disco_defconfig  | 2 --
>  configs/stm32h743-eval_defconfig   | 2 --
>  7 files changed, 10 deletions(-)
> 
> diff --git a/configs/stm32f429-discovery_defconfig 
> b/configs/stm32f429-discovery_defconfig
> index 99bf64ace5..a1721fddfd 100644
> --- a/configs/stm32f429-discovery_defconfig
> +++ b/configs/stm32f429-discovery_defconfig
> @@ -14,7 +14,6 @@ CONFIG_USE_BOOTARGS=y
>  CONFIG_BOOTARGS="console=ttyS0,115200 earlyprintk consoleblank=0 
> ignore_loglevel"
>  # CONFIG_DISPLAY_CPUINFO is not set
>  # CONFIG_DISPLAY_BOARDINFO is not set
> -CONFIG_BOARD_EARLY_INIT_F=y
>  CONFIG_MISC_INIT_R=y
>  CONFIG_HUSH_PARSER=y
>  CONFIG_SYS_PROMPT="U-Boot > "
> diff --git a/configs/stm32f429-evaluation_defconfig 
> b/configs/stm32f429-evaluation_defconfig
> index 4511ac85ce..55505ea378 100644
> --- a/configs/stm32f429-evaluation_defconfig
> +++ b/configs/stm32f429-evaluation_defconfig
> @@ -11,7 +11,6 @@ CONFIG_DISTRO_DEFAULTS=y
>  CONFIG_BOOTDELAY=3
>  # CONFIG_USE_BOOTCOMMAND is not set
>  # CONFIG_DISPLAY_CPUINFO is not set
> -CONFIG_BOARD_EARLY_INIT_F=y
>  CONFIG_MISC_INIT_R=y
>  CONFIG_SYS_PROMPT="U-Boot > "
>  CONFIG_CMD_IMLS=y
> diff --git a/configs/stm32f469-discovery_defconfig 
> b/configs/stm32f469-discovery_defconfig
> index d13794e420..37603970c2 100644
> --- a/configs/stm32f469-discovery_defconfig
> +++ b/configs/stm32f469-discovery_defconfig
> @@ -11,7 +11,6 @@ CONFIG_DISTRO_DEFAULTS=y
>  CONFIG_BOOTDELAY=3
>  # CONFIG_USE_BOOTCOMMAND is not set
>  # CONFIG_DISPLAY_CPUINFO is not set
> -CONFIG_BOARD_EARLY_INIT_F=y
>  CONFIG_MISC_INIT_R=y
>  CONFIG_SYS_PROMPT="U-Boot > "
>  CONFIG_CMD_IMLS=y
> diff --git a/configs/stm32f746-disco_defconfig 
> b/configs/stm32f746-disco_defconfig
> index 106ef28b83..e6585e5e9c 100644
> --- a/configs/stm32f746-disco_defconfig
> +++ b/configs/stm32f746-disco_defconfig
> @@ -18,7 +18,6 @@ CONFIG_BOOTARGS="console=ttyS0,115200 earlyprintk 
> consoleblank=0 ignore_loglevel
>  # CONFIG_USE_BOOTCOMMAND is not set
>  # CONFIG_DISPLAY_CPUINFO is not set
>  # CONFIG_DISPLAY_BOARDINFO is not set
> -CONFIG_BOARD_EARLY_INIT_F=y
>  CONFIG_BOARD_LATE_INIT=y
>  CONFIG_SYS_PROMPT="U-Boot > "
>  CONFIG_CMD_GPT=y
> diff --git a/configs/stm32f769-disco_defconfig 
> b/configs/stm32f769-disco_defconfig
> index cc3fad603b..6dc9668326 100644
> --- a/configs/stm32f769-disco_defconfig
> +++ b/configs/stm32f769-disco_defconfig
> @@ -18,8 +18,6 @@ CONFIG_BOOTARGS="console=ttyS0,115200 earlyprintk 
> consoleblank=0 ignore_loglevel
>  # CONFIG_USE_BOOTCOMMAND is not set
>  # CONFIG_DISPLAY_CPUINFO is not set
>  # CONFIG_DISPLAY_BOARDINFO is not set
> -CONFIG_BOARD_EARLY_INIT_F=y
> -CONFIG_BOARD_LATE_INIT=y
>  CONFIG_SYS_PROMPT="U-Boot > "
>  CONFIG_CMD_GPT=y
>  # CONFIG_RANDOM_UUID is not set
> diff --git a/configs/stm32h743-disco_defconfig 
> b/configs/stm32h743-disco_defconfig
> index 788da28f55..4f4144c917 100644
> --- a/configs/stm32h743-disco_defconfig
> +++ b/configs/stm32h743-disco_defconfig
> @@ -15,8 +15,6 @@ CONFIG_AUTOBOOT_STOP_STR=" "
>  # CONFIG_USE_BOOTCOMMAND is not set
>  CONFIG_DEFAULT_FDT_FILE="stm32h743i-disco"
>  # CONFIG_DISPLAY_CPUINFO is not set
> -CONFIG_BOARD_EARLY_INIT_F=y
> -CONFIG_BOARD_LATE_INIT=y
>  CONFIG_SYS_PROMPT="U-Boot > "
>  CONFIG_CMD_GPT=y
>  CONFIG_CMD_MMC=y
> diff --git a/configs/stm32h743-eval_defconfig 
> b/configs/stm32h743-eval_defconfig
> index d752f5e792..18124859e6 100644
> --- a/configs/stm32h743-eval_defconfig
> +++ b/configs/stm32h743-eval_defconfig
> @@ -15,8 +15,6 @@ CONFIG_AUTOBOOT_STOP_STR=" "
>  # CONFIG_USE_BOOTCOMMAND is not set
>  CONFIG_DEFAULT_FDT_FILE="stm32h743i-eval"
>  # CONFIG_DISPLAY_CPUINFO is not set
> -CONFIG_BOARD_EARLY_INIT_F=y
> -CONFIG_BOARD_LATE_INIT=y
>  CONFIG_SYS_PROMPT="U-Boot > "
>  CONFIG_CMD_GPT=y
>  CONFIG_CMD_MMC=y
> 

Applied to u-boot-stm/next

Thanks

Patrice

Re: [PATCH] arm: stm32mp: Fix compilation issue when SYS_DCACHE_OFF and/or SYS_DCACHE_SYS are enabled

[Patrice CHOTARD]

Hi

On 3/12/21 10:52 AM, Patrick DELAUNAY wrote:
> Hi Patrice,
> 
> On 2/24/21 1:53 PM, Patrice Chotard wrote:
>> From: Patrice Chotard 
>>
>> Fix following compilation issue when SYS_DCACHE_OFF and/or SYS_DCACHE_SYS
>> are enabled :
>>
>> arch/arm/mach-stm32mp/cpu.c: In function ‘early_enable_caches’:
>> arch/arm/mach-stm32mp/cpu.c:223:10: error: ‘volatile struct 
>> arch_global_data’ has no member named ‘tlb_size’
>>    223 |  gd->arch.tlb_size = PGTABLE_SIZE;
>>    |  ^
>> arch/arm/mach-stm32mp/cpu.c:224:10: error: ‘volatile struct 
>> arch_global_data’ has no member named ‘tlb_addr’
>>    224 |  gd->arch.tlb_addr = (unsigned long)_tlb;
>>    |  ^
>>
>> Signed-off-by: Patrice Chotard 
>> Signed-off-by: Patrice Chotard 
>> ---
>>
>>   arch/arm/mach-stm32mp/cpu.c | 6 --
>>   1 file changed, 4 insertions(+), 2 deletions(-)
>>
> 
> 
> Reviewed-by: Patrick Delaunay 
> 
> Thanks
> Patrick

Applied to u-boot-stm/next

Thanks

Patrice

Regression on RPi with commit 4cbb293 (efi_loader: consider no-map property of reserved memory)

[Peter Robinson]

Hey Heinrich,

Not sure why this hasn't come up before as the issue with testing goes
back to 2021.01-rc1/merge window, or if it's something like a newer
firmware (I currently have one from 2021-02-25) but I'm seeing issues
with the Raspberry Pi bringing up the secondary CPUs in Linux [1].

Ine of our users worked out it was a u-boot issue and with bisecting I
got it down to down to the "efi_loader: consider no-map property of
reserved memory" commit 4cbb293. I don't know too much about SMP
bringing online CPUs on the RPi raspberry pi but I wonder if that
commit is clobbering some piece of memory needed for that (I vaguely
remember some mention of spin tables).

I see it on both the original RPi3 and the 3B+, what are your thoughts?

Peter

[0.008498] Remapping and enabling EFI services.
[0.009304] smp: Bringing up secondary CPUs ...
[5.042966] CPU1: failed to come online
[5.042994] CPU1: failed in unknown state : 0x0
[   10.085989] CPU2: failed to come online
[   10.086017] CPU2: failed in unknown state : 0x0
[   15.128975] CPU3: failed to come online
[   15.129003] CPU3: failed in unknown state : 0x0
[   15.129114] smp: Brought up 1 node, 1 CPU
[   15.129138] SMP: Total of 1 processors activated.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1921924

Re: [PATCH u-boot 12/39] string: make memcpy() and memset() visible to fix LTO linking errors

[Bin Meng]

Hi Marek,

On Fri, Mar 12, 2021 at 6:09 PM Marek Behun  wrote:
>
> I created a gcc bug for this
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99559

Thank you for filling a bug report to the GCC community.

Regards,
Bin

[PATCH u-boot v2 33/38] armv8: SPL: discard relocation information

[Marek Behún]

For some reason when building SPL for ARMv8 with LTO, the relocation
information is not discarded.

Discard it explicitly in the linker script.

This fixes LTO build for imx8mm_venice_defconfig.

Signed-off-by: Marek Behún 
---
 arch/arm/cpu/armv8/u-boot-spl.lds | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/cpu/armv8/u-boot-spl.lds 
b/arch/arm/cpu/armv8/u-boot-spl.lds
index 0e67ab09d7..9edb662b09 100644
--- a/arch/arm/cpu/armv8/u-boot-spl.lds
+++ b/arch/arm/cpu/armv8/u-boot-spl.lds
@@ -77,6 +77,7 @@ SECTIONS
KEEP(*(.__bss_end));
} >.sdram
 
+   /DISCARD/ : { *(.rela*) }
/DISCARD/ : { *(.dynsym) }
/DISCARD/ : { *(.dynstr*) }
/DISCARD/ : { *(.dynamic*) }
-- 
2.26.2

[PATCH u-boot v2 28/38] ARM: kona: fix clk_bsc_enable() type mismatch for LTO

[Marek Behún]

When building with LTO, the compiler complains about type mismatch of
function clk_bsc_enable() in file:
  arch/arm/cpu/armv7/kona-common/clk-stubs.c
vs other files that define or use this function:
  warning: type of ‘clk_bsc_enable’ does not match original declaration.

Change the type of this function to that of the other usages.

Signed-off-by: Marek Behún 
Reviewed-by: Bin Meng 
---
 arch/arm/cpu/armv7/kona-common/clk-stubs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/cpu/armv7/kona-common/clk-stubs.c 
b/arch/arm/cpu/armv7/kona-common/clk-stubs.c
index 2dfa3f7e73..4eddaca887 100644
--- a/arch/arm/cpu/armv7/kona-common/clk-stubs.c
+++ b/arch/arm/cpu/armv7/kona-common/clk-stubs.c
@@ -14,7 +14,7 @@ int __weak clk_sdio_enable(void *base, u32 rate, u32 
*actual_ratep)
return 0;
 }
 
-int __weak clk_bsc_enable(void *base, u32 rate, u32 *actual_ratep)
+int __weak clk_bsc_enable(void *base)
 {
return 0;
 }
-- 
2.26.2

[PATCH u-boot v2 32/38] ARM: omap3: fix LTO for DM3730 (and possibly other omap3 boards)

[Marek Behún]

Adam Ford says that DM3730 needs board.c compiled without LTO flags.

Also add clock.c, since it says in Makefile that it need different
flags.

Signed-off-by: Marek Behún 
Suggested-by: Adam Ford 
---
 arch/arm/mach-omap2/omap3/Makefile | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/mach-omap2/omap3/Makefile 
b/arch/arm/mach-omap2/omap3/Makefile
index 91ed8ebc9f..7d22f04bbf 100644
--- a/arch/arm/mach-omap2/omap3/Makefile
+++ b/arch/arm/mach-omap2/omap3/Makefile
@@ -5,10 +5,12 @@
 
 # If clock.c is compiled for Thumb2, then it fails on OMAP3530
 CFLAGS_clock.o += -marm
+CFLAGS_REMOVE_clock.o := $(LTO_CFLAGS)
 
 obj-y  := lowlevel_init.o
 
 obj-y  += board.o
+CFLAGS_REMOVE_board.o := $(LTO_CFLAGS)
 obj-y  += boot.o
 obj-y  += clock.o
 obj-y  += sys_info.o
-- 
2.26.2

[PATCH u-boot v2 21/38] sandbox: enable LTO by default

[Marek Behún]

Build sandbox targets with LTO by default.

Signed-off-by: Marek Behún 
Reviewed-by: Bin Meng 
---
 arch/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/Kconfig b/arch/Kconfig
index a6dab3e56d..b884b7b248 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -123,6 +123,7 @@ config SANDBOX
select SYSRESET_CMD_POWEROFF
imply BITREVERSE
select BLOBLIST
+   imply LTO
imply CMD_DM
imply CMD_EXCEPTION
imply CMD_GETTIME
-- 
2.26.2

[PATCH u-boot v2 18/38] sandbox: errno: avoid conflict with libc's errno

[Marek Behún]

When building with LTO, the system libc's `errno` variable used in
arch/sandbox/cpu/os.c conflicts with U-Boot's `errno` (defined in
lib/errno.c) with the following error:
 .../ld: errno@@GLIBC_PRIVATE: TLS definition in /lib64/libc.so.6
 section .tbss mismatches non-TLS reference in
 /tmp/u-boot.EQlEXz.ltrans0.ltrans.o

To avoid this conflict use different asm label for this variable when
CONFIG_SANDBOX is enabled.

Signed-off-by: Marek Behún 
Reviewed-by: Bin Meng 
Reviewed-by: Simon Glass 
---
 include/errno.h | 8 +++-
 lib/errno.c | 4 +++-
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/include/errno.h b/include/errno.h
index 3af539b9e9..652ad67306 100644
--- a/include/errno.h
+++ b/include/errno.h
@@ -8,7 +8,13 @@
 
 #include 
 
-extern int errno;
+#ifdef __SANDBOX__
+#define __errno_asm_label asm("__u_boot_errno")
+#else
+#define __errno_asm_label
+#endif
+
+extern int errno __errno_asm_label;
 
 #define __set_errno(val) do { errno = val; } while (0)
 
diff --git a/lib/errno.c b/lib/errno.c
index 8330a8fd14..ca0c756bd9 100644
--- a/lib/errno.c
+++ b/lib/errno.c
@@ -1 +1,3 @@
-int errno = 0;
+#include 
+
+int errno __errno_asm_label = 0;
-- 
2.26.2

[PATCH u-boot v2 38/38] ARM: enable LTO for some boards

[Marek Behún]

Enable LTO for some boards that were tested by people on U-Boot Mailing
List.

Signed-off-by: Marek Behún 
Tested-by: Adam Ford 
Tested-by: Pali Rohár 
Tested-by: Tim Harvey 
---
 configs/am3517_evm_defconfig  | 1 +
 configs/da850evm_defconfig| 1 +
 configs/da850evm_direct_nor_defconfig | 1 +
 configs/da850evm_nand_defconfig   | 1 +
 configs/imx6q_logic_defconfig | 1 +
 configs/imx8mm_beacon_defconfig   | 1 +
 configs/imx8mm_venice_defconfig   | 1 +
 configs/imx8mn_beacon_2g_defconfig| 1 +
 configs/imx8mn_beacon_defconfig   | 1 +
 configs/nokia_rx51_defconfig  | 1 +
 configs/r8a774a1_beacon_defconfig | 1 +
 configs/r8a774b1_beacon_defconfig | 1 +
 configs/r8a774e1_beacon_defconfig | 1 +
 configs/turris_mox_defconfig  | 1 +
 configs/turris_omnia_defconfig| 1 +
 15 files changed, 15 insertions(+)

diff --git a/configs/am3517_evm_defconfig b/configs/am3517_evm_defconfig
index bae0e0af35..d61eec94a4 100644
--- a/configs/am3517_evm_defconfig
+++ b/configs/am3517_evm_defconfig
@@ -1,3 +1,4 @@
+CONFIG_LTO=y
 CONFIG_ARM=y
 # CONFIG_SPL_USE_ARCH_MEMCPY is not set
 # CONFIG_SPL_USE_ARCH_MEMSET is not set
diff --git a/configs/da850evm_defconfig b/configs/da850evm_defconfig
index 26e76a2929..6ff5e21bc6 100644
--- a/configs/da850evm_defconfig
+++ b/configs/da850evm_defconfig
@@ -1,3 +1,4 @@
+CONFIG_LTO=y
 CONFIG_ARM=y
 CONFIG_SYS_THUMB_BUILD=y
 CONFIG_ARCH_DAVINCI=y
diff --git a/configs/da850evm_direct_nor_defconfig 
b/configs/da850evm_direct_nor_defconfig
index d3860a963d..06c7ce7c47 100644
--- a/configs/da850evm_direct_nor_defconfig
+++ b/configs/da850evm_direct_nor_defconfig
@@ -1,3 +1,4 @@
+CONFIG_LTO=y
 CONFIG_ARM=y
 CONFIG_ARCH_CPU_INIT=y
 CONFIG_ARCH_DAVINCI=y
diff --git a/configs/da850evm_nand_defconfig b/configs/da850evm_nand_defconfig
index 0d0e9a148d..be737564e1 100644
--- a/configs/da850evm_nand_defconfig
+++ b/configs/da850evm_nand_defconfig
@@ -1,3 +1,4 @@
+CONFIG_LTO=y
 CONFIG_ARM=y
 CONFIG_SYS_THUMB_BUILD=y
 CONFIG_ARCH_DAVINCI=y
diff --git a/configs/imx6q_logic_defconfig b/configs/imx6q_logic_defconfig
index 36dc24d080..0f8aea6983 100644
--- a/configs/imx6q_logic_defconfig
+++ b/configs/imx6q_logic_defconfig
@@ -1,3 +1,4 @@
+CONFIG_LTO=y
 CONFIG_ARM=y
 CONFIG_ARCH_MX6=y
 CONFIG_SYS_TEXT_BASE=0x1780
diff --git a/configs/imx8mm_beacon_defconfig b/configs/imx8mm_beacon_defconfig
index 045b19f4f3..e8bb44eea6 100644
--- a/configs/imx8mm_beacon_defconfig
+++ b/configs/imx8mm_beacon_defconfig
@@ -1,3 +1,4 @@
+CONFIG_LTO=y
 CONFIG_ARM=y
 CONFIG_ARCH_IMX8M=y
 CONFIG_SYS_TEXT_BASE=0x4020
diff --git a/configs/imx8mm_venice_defconfig b/configs/imx8mm_venice_defconfig
index a15c3641f6..dff8f64540 100644
--- a/configs/imx8mm_venice_defconfig
+++ b/configs/imx8mm_venice_defconfig
@@ -1,3 +1,4 @@
+CONFIG_LTO=y
 CONFIG_ARM=y
 CONFIG_ARCH_IMX8M=y
 CONFIG_SYS_TEXT_BASE=0x4020
diff --git a/configs/imx8mn_beacon_2g_defconfig 
b/configs/imx8mn_beacon_2g_defconfig
index 58b8e49486..1c8cbc2c89 100644
--- a/configs/imx8mn_beacon_2g_defconfig
+++ b/configs/imx8mn_beacon_2g_defconfig
@@ -1,3 +1,4 @@
+CONFIG_LTO=y
 CONFIG_ARM=y
 CONFIG_ARCH_IMX8M=y
 CONFIG_SYS_TEXT_BASE=0x4020
diff --git a/configs/imx8mn_beacon_defconfig b/configs/imx8mn_beacon_defconfig
index d6a3385d8d..6457b9409a 100644
--- a/configs/imx8mn_beacon_defconfig
+++ b/configs/imx8mn_beacon_defconfig
@@ -1,3 +1,4 @@
+CONFIG_LTO=y
 CONFIG_ARM=y
 CONFIG_ARCH_IMX8M=y
 CONFIG_SYS_TEXT_BASE=0x4020
diff --git a/configs/nokia_rx51_defconfig b/configs/nokia_rx51_defconfig
index 312ca3a1a9..85ca627790 100644
--- a/configs/nokia_rx51_defconfig
+++ b/configs/nokia_rx51_defconfig
@@ -1,3 +1,4 @@
+CONFIG_LTO=y
 CONFIG_ARM=y
 # CONFIG_SYS_THUMB_BUILD is not set
 CONFIG_ARCH_OMAP2PLUS=y
diff --git a/configs/r8a774a1_beacon_defconfig 
b/configs/r8a774a1_beacon_defconfig
index 2f45edd92e..9dd5d9192e 100644
--- a/configs/r8a774a1_beacon_defconfig
+++ b/configs/r8a774a1_beacon_defconfig
@@ -1,3 +1,4 @@
+CONFIG_LTO=y
 CONFIG_ARM=y
 CONFIG_ARCH_RMOBILE=y
 CONFIG_SYS_TEXT_BASE=0x5000
diff --git a/configs/r8a774b1_beacon_defconfig 
b/configs/r8a774b1_beacon_defconfig
index ca514bb1aa..b7d7f23f5a 100644
--- a/configs/r8a774b1_beacon_defconfig
+++ b/configs/r8a774b1_beacon_defconfig
@@ -1,3 +1,4 @@
+CONFIG_LTO=y
 CONFIG_ARM=y
 CONFIG_ARCH_RMOBILE=y
 CONFIG_SYS_TEXT_BASE=0x5000
diff --git a/configs/r8a774e1_beacon_defconfig 
b/configs/r8a774e1_beacon_defconfig
index b89729d92a..3e44edf29f 100644
--- a/configs/r8a774e1_beacon_defconfig
+++ b/configs/r8a774e1_beacon_defconfig
@@ -1,3 +1,4 @@
+CONFIG_LTO=y
 CONFIG_ARM=y
 CONFIG_ARCH_RMOBILE=y
 CONFIG_SYS_TEXT_BASE=0x5000
diff --git a/configs/turris_mox_defconfig b/configs/turris_mox_defconfig
index f938fbb475..2a351d9180 100644
--- a/configs/turris_mox_defconfig
+++ b/configs/turris_mox_defconfig
@@ -1,3 +1,4 @@
+CONFIG_LTO=y
 CONFIG_ARM=y
 CONFIG_ARCH_CPU_INIT=y
 CONFIG_ARCH_MVEBU=y
diff --git a/configs/turris_omnia_defconfig 

[PATCH u-boot v2 35/38] ARM: make LTO available

[Marek Behún]

Make LTO available for ARM architecture.

Signed-off-by: Marek Behún 
---
 arch/Kconfig  | 1 +
 arch/arm/lib/Makefile | 2 ++
 2 files changed, 3 insertions(+)

diff --git a/arch/Kconfig b/arch/Kconfig
index b884b7b248..bf4b8afcb4 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -33,6 +33,7 @@ config ARC
 
 config ARM
bool "ARM architecture"
+   select ARCH_SUPPORTS_LTO
select CREATE_ARCH_SYMLINK
select HAVE_PRIVATE_LIBGCC if !ARM64
select SUPPORT_OF_CONTROL
diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile
index 61bef1d5af..7f66332715 100644
--- a/arch/arm/lib/Makefile
+++ b/arch/arm/lib/Makefile
@@ -45,6 +45,8 @@ obj-$(CONFIG_SEMIHOSTING) += semihosting.o
 
 obj-y  += bdinfo.o
 obj-y  += sections.o
+CFLAGS_REMOVE_sections.o := $(LTO_CFLAGS)
+
 obj-y  += stack.o
 ifdef CONFIG_CPU_V7M
 obj-y  += interrupts_m.o
-- 
2.26.2

[PATCH u-boot v2 37/38] ARM: don't use --gc-sections with LTO when using private libgcc

[Marek Behún]

When using LTO, we can throw away the --gc-sections flag, but only if
using private libgcc.

When using system's libgcc, --gc-sections is still needed, otherwise
linking will fail due to undefined references to libc's symbols.

Signed-off-by: Marek Behún 
---
 arch/arm/config.mk | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/config.mk b/arch/arm/config.mk
index 2b2c6ad2e5..68745d489f 100644
--- a/arch/arm/config.mk
+++ b/arch/arm/config.mk
@@ -14,7 +14,9 @@ endif
 CFLAGS_NON_EFI := -fno-pic -ffixed-r9 -ffunction-sections -fdata-sections
 CFLAGS_EFI := -fpic -fshort-wchar
 
+ifneq ($(CONFIG_LTO)$(CONFIG_USE_PRIVATE_LIBGCC),yy)
 LDFLAGS_FINAL += --gc-sections
+endif
 
 ifndef CONFIG_LTO
 PLATFORM_RELFLAGS += -ffunction-sections -fdata-sections
-- 
2.26.2

[PATCH u-boot v2 34/38] ata: ahci: fix ahci_link_up() type mismatch for LTO

[Marek Behún]

When building highbank_defconfig with LTO, the compiler complains about
type mismatch of function ahci_link_up().

The third parameter of this function is of type u8 in
drivers/ata/ahci.c, but of type int in board/highbank/ahci.c.

There is no reason in using u8, and the code using this function
actually passes an int variable into the function (so it is implicitly
converted to u8).

Change the type of this parameter to int in drivers/ata/ahci.c.

Signed-off-by: Marek Behún 
Reviewed-by: Bin Meng 
---
 drivers/ata/ahci.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index 2ef21ec508..3d16bc21a8 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -110,7 +110,7 @@ static int waiting_for_cmd_completed(void __iomem *offset,
return (i < timeout_msec) ? 0 : -1;
 }
 
-int __weak ahci_link_up(struct ahci_uc_priv *uc_priv, u8 port)
+int __weak ahci_link_up(struct ahci_uc_priv *uc_priv, int port)
 {
u32 tmp;
int j = 0;
-- 
2.26.2

[PATCH u-boot v2 36/38] ARM: don't use -ffunction-sections/-fdata-sections with LTO build

[Marek Behún]

When building with LTO, using -ffunction-sections/-fdata-sections is not
useful anymore.

Signed-off-by: Marek Behún 
---
 arch/arm/config.mk | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/arch/arm/config.mk b/arch/arm/config.mk
index 4153f7e371..2b2c6ad2e5 100644
--- a/arch/arm/config.mk
+++ b/arch/arm/config.mk
@@ -15,8 +15,12 @@ CFLAGS_NON_EFI := -fno-pic -ffixed-r9 -ffunction-sections 
-fdata-sections
 CFLAGS_EFI := -fpic -fshort-wchar
 
 LDFLAGS_FINAL += --gc-sections
-PLATFORM_RELFLAGS += -ffunction-sections -fdata-sections \
--fno-common -ffixed-r9
+
+ifndef CONFIG_LTO
+PLATFORM_RELFLAGS += -ffunction-sections -fdata-sections
+endif
+
+PLATFORM_RELFLAGS += -fno-common -ffixed-r9
 PLATFORM_RELFLAGS += $(call cc-option, -msoft-float) \
   $(call cc-option,-mshort-load-bytes,$(call cc-option,-malignment-traps,))
 
-- 
2.26.2

[PATCH u-boot v2 31/38] ARM: fix LTO for rockchip and samsung

[Marek Behún]

When building with LTO, the compiler complains about type mismatch of
function usb_gadget_handle_interrupts(). This function is defined
without parameters in files
  arch/arm/mach-rockchip/board.c
  board/samsung/common/exynos5-dt.c
but it should have one parameter, int index.

Fix this.

Signed-off-by: Marek Behún 
Reviewed-by: Bin Meng 
---
 arch/arm/mach-rockchip/board.c| 2 +-
 board/samsung/common/exynos5-dt.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-rockchip/board.c b/arch/arm/mach-rockchip/board.c
index c386b52987..5304eb055c 100644
--- a/arch/arm/mach-rockchip/board.c
+++ b/arch/arm/mach-rockchip/board.c
@@ -139,7 +139,7 @@ static struct dwc3_device dwc3_device_data = {
.hsphy_mode = USBPHY_INTERFACE_MODE_UTMIW,
 };
 
-int usb_gadget_handle_interrupts(void)
+int usb_gadget_handle_interrupts(int index)
 {
dwc3_uboot_handle_interrupt(0);
return 0;
diff --git a/board/samsung/common/exynos5-dt.c 
b/board/samsung/common/exynos5-dt.c
index 4463cdcb87..1318ea716a 100644
--- a/board/samsung/common/exynos5-dt.c
+++ b/board/samsung/common/exynos5-dt.c
@@ -126,7 +126,7 @@ static struct dwc3_device dwc3_device_data = {
.index = 0,
 };
 
-int usb_gadget_handle_interrupts(void)
+int usb_gadget_handle_interrupts(int index)
 {
dwc3_uboot_handle_interrupt(0);
return 0;
-- 
2.26.2

[PATCH u-boot v2 17/38] build: support building with Link Time Optimizations

[Marek Behún]

Add plumbing for building U-Boot with Link Time Optimizations.

When building with LTO, $(PLATFORM_LIBS) has to be in --whole-archive /
--no-whole-archive group, otherwise some functions declared in assembly
may not be resolved and linking may fail.

Signed-off-by: Marek Behún 
---
 Kbuild   |  2 ++
 Kconfig  | 19 +++
 Makefile | 36 
 scripts/Makefile.lib |  3 +++
 scripts/Makefile.spl | 17 +
 5 files changed, 77 insertions(+)

diff --git a/Kbuild b/Kbuild
index 1eac091594..bf52e54051 100644
--- a/Kbuild
+++ b/Kbuild
@@ -10,6 +10,8 @@ generic-offsets-file := 
include/generated/generic-asm-offsets.h
 always  := $(generic-offsets-file)
 targets := lib/asm-offsets.s
 
+CFLAGS_REMOVE_asm-offsets.o := $(LTO_CFLAGS)
+
 $(obj)/$(generic-offsets-file): $(obj)/lib/asm-offsets.s FORCE
$(call filechk,offsets,__GENERIC_ASM_OFFSETS_H__)
 
diff --git a/Kconfig b/Kconfig
index 86f0a39bb0..ceba53926f 100644
--- a/Kconfig
+++ b/Kconfig
@@ -85,6 +85,25 @@ config SPL_OPTIMIZE_INLINING
  do what it thinks is best, which is desirable in some cases for size
  reasons.
 
+config ARCH_SUPPORTS_LTO
+   bool
+
+config LTO
+   bool "Enable Link Time Optimizations"
+   depends on ARCH_SUPPORTS_LTO
+   default n
+   help
+ This option enables Link Time Optimization (LTO), a mechanism which
+ allows the compiler to optimize between different compilation units.
+
+ This can optimize away dead code paths, resulting in smaller binary
+ size (if CC_OPTIMIZE_FOR_SIZE is enabled).
+
+ This option is not available for every architecture and may
+ introduce bugs.
+
+ If unsure, say n.
+
 config TPL_OPTIMIZE_INLINING
bool "Allow compiler to uninline functions marked 'inline' in TPL"
depends on TPL
diff --git a/Makefile b/Makefile
index 8fcae036ea..9518ba4a32 100644
--- a/Makefile
+++ b/Makefile
@@ -677,6 +677,27 @@ else
 KBUILD_CFLAGS  += -O2
 endif
 
+LTO_CFLAGS :=
+LTO_FINAL_LDFLAGS :=
+export LTO_CFLAGS LTO_FINAL_LDFLAGS
+ifdef CONFIG_LTO
+   LTO_CFLAGS  := -flto
+
+   CFLAGS_NON_EFI  += $(LTO_CFLAGS)
+
+   ifeq ($(cc-name),clang)
+   LTO_FINAL_LDFLAGS   += -flto
+   else
+   LTO_FINAL_LDFLAGS   += -fuse-linker-plugin -flto=jobserver
+
+   # use plugin aware tools
+   AR  = $(CROSS_COMPILE)gcc-ar
+   NM  = $(CROSS_COMPILE)gcc-nm
+   endif
+
+   KBUILD_CFLAGS   += $(LTO_CFLAGS)
+endif
+
 KBUILD_CFLAGS += $(call cc-option,-fno-stack-protector)
 KBUILD_CFLAGS += $(call cc-option,-fno-delete-null-pointer-checks)
 
@@ -1746,6 +1767,20 @@ ARCH_POSTLINK := $(wildcard 
$(srctree)/arch/$(ARCH)/Makefile.postlink)
 
 # Rule to link u-boot
 # May be overridden by arch/$(ARCH)/config.mk
+ifdef CONFIG_LTO
+quiet_cmd_u-boot__ ?= LTO $@
+  cmd_u-boot__ ?=  
\
+   $(CC) -nostdlib -nostartfiles   
\
+   $(LTO_FINAL_LDFLAGS) $(c_flags) 
\
+   $(KBUILD_LDFLAGS:%=-Wl,%) $(LDFLAGS_u-boot:%=-Wl,%) -o $@   
\
+   -T u-boot.lds $(u-boot-init)
\
+   -Wl,--whole-archive 
\
+   $(u-boot-main)  
\
+   $(PLATFORM_LIBS)
\
+   -Wl,--no-whole-archive  
\
+   -Wl,-Map,u-boot.map;
\
+   $(if $(ARCH_POSTLINK), $(MAKE) -f $(ARCH_POSTLINK) $@, true)
+else
 quiet_cmd_u-boot__ ?= LD  $@
   cmd_u-boot__ ?= $(LD) $(KBUILD_LDFLAGS) $(LDFLAGS_u-boot) -o $@  
\
-T u-boot.lds $(u-boot-init)
\
@@ -1754,6 +1789,7 @@ quiet_cmd_u-boot__ ?= LD  $@
--no-whole-archive  
\
$(PLATFORM_LIBS) -Map u-boot.map;   
\
$(if $(ARCH_POSTLINK), $(MAKE) -f $(ARCH_POSTLINK) $@, true)
+endif
 
 quiet_cmd_smap = GEN common/system_map.o
 cmd_smap = \
diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index 78543c6dd1..78bbebe7e9 100644
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -419,6 +419,9 @@ $(obj)/%_efi.so: $(obj)/%.o $(obj)/efi_crt0.o 
$(obj)/efi_reloc.o $(obj)/efi_free
 
 targets += $(obj)/efi_crt0.o $(obj)/efi_reloc.o $(obj)/efi_freestanding.o
 
+CFLAGS_REMOVE_efi_reloc.o := $(LTO_CFLAGS)
+CFLAGS_REMOVE_efi_freestanding.o := $(LTO_CFLAGS)
+
 # ACPI
 #