[PATCH] arm: dts: mvebu: Migrate to upstream DT for Synology DS116 (Armada 385) board
Enable OF_UPSTREAM to use upstream DT and add marvell/ prefix to the
DEFAULT_DEVICE_TREE in DS116 defconfig. Remove current DTS in
arch/arm/dts/ directory.
Signed-off-by: Tony Dinh
---
arch/arm/dts/Makefile | 1 -
arch/arm/dts/armada-385-synology-ds116.dts | 291 -
configs/ds116_defconfig| 3 +-
3 files changed, 2 insertions(+), 293 deletions(-)
delete mode 100644 arch/arm/dts/armada-385-synology-ds116.dts
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index a5c82ebf7a..75f7e616b4 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -155,7 +155,6 @@ dtb-$(CONFIG_ARCH_MVEBU) += \
armada-385-atl-x530.dtb \
armada-385-atl-x530DP.dtb \
armada-385-db-88f6820-amc.dtb \
- armada-385-synology-ds116.dtb \
armada-385-thecus-n2350.dtb \
armada-385-turris-omnia.dtb \
armada-388-clearfog.dtb \
diff --git a/arch/arm/dts/armada-385-synology-ds116.dts
b/arch/arm/dts/armada-385-synology-ds116.dts
deleted file mode 100644
index 82a0373f7f..00
--- a/arch/arm/dts/armada-385-synology-ds116.dts
+++ /dev/null
@@ -1,291 +0,0 @@
-// SPDX-License-Identifier: (GPL-2.0 OR MIT)
-/*
- * Device Tree file for Synology DS116 NAS
- *
- * Copyright (C) 2017 Willy Tarreau
- */
-
-/dts-v1/;
-#include "armada-385.dtsi"
-#include
-
-/ {
- model = "Synology DS116";
- compatible = "marvell,a385-gp", "marvell,armada385",
"marvell,armada380";
-
- chosen {
- stdout-path = "serial0:115200n8";
- };
-
- memory {
- device_type = "memory";
- reg = <0x 0x4000>; /* 1 GB */
- };
-
- soc {
- ranges = ;
-
- internal-regs {
- i2c@11000 {
- pinctrl-names = "default";
- pinctrl-0 = <_pins>;
- status = "okay";
- clock-frequency = <10>;
-
- eeprom@57 {
- compatible = "atmel,24c64";
- reg = <0x57>;
- };
- };
-
- serial@12000 {
- pinctrl-names = "default";
- pinctrl-0 = <_pins>;
- status = "okay";
- };
-
- serial@12100 {
- /* A PIC16F1829 is connected to uart1 at 9600
bps,
-* and takes single-character orders :
-* "1" : power off // already handled by the
poweroff node
-* "2" : short beep
-* "3" : long beep
-* "4" : turn the power LED ON
-* "5" : flash the power LED
-* "6" : turn the power LED OFF
-* "7" : turn the status LED OFF
-* "8" : turn the status LED ON
-* "9" : flash the status LED
-* "A" : flash the motherboard LED (D8)
-* "B" : turn the motherboard LED OFF
-* "C" : hard reset
-*/
- pinctrl-names = "default";
- pinctrl-0 = <_pins>;
- status = "okay";
- };
-
- poweroff@12100 {
- compatible = "synology,power-off";
- reg = <0x12100 0x100>;
- clocks = < 0>;
- };
-
- ethernet@7 {
- pinctrl-names = "default";
- phy = <>;
- phy-mode = "sgmii";
- buffer-manager = <>;
- bm,pool-long = <0>;
- status = "okay";
- };
-
- mdio@72004 {
- pinctrl-names = "default";
- pinctrl-0 = <_pins>;
-
-
Re: [PATCH v2 1/2] doc: Detailed example for netconsole setup
Hi Fiona,
Added Heinrich to CC list.
On Sat, May 18, 2024 at 4:05 AM Fiona Klute wrote:
>
> Hi Tony!
>
> Am 16.05.24 um 21:28 schrieb Tony Dinh:
> > On Thu, May 16, 2024 at 3:43 AM Fiona Klute wrote:
> >>
> >> This adds details that I would have liked to have readily available,
> >> in particular how to activate the network interface before enabling
> >> netconsole, and how to integrate netconsole so you can use the U-Boot
> >> prompt.
> >>
> >> Signed-off-by: Fiona Klute
> >> ---
> >> Changes in v2:
> >> * Include stderr redirection
> >> * Use 4 spaces instead of tabs for code block to avoid overflowing
> >>lines
> >>
> >> doc/usage/netconsole.rst | 33 -
> >> 1 file changed, 32 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/doc/usage/netconsole.rst b/doc/usage/netconsole.rst
> >> index 2aa3b9ccc5..647f0c220b 100644
> >> --- a/doc/usage/netconsole.rst
> >> +++ b/doc/usage/netconsole.rst
> >> @@ -18,7 +18,9 @@ broadcast address and port are used. If it is set
> >> to an IP
> >> address of 0 (or 0.0.0.0) then no messages are sent to the network.
> >> The source / listening port can be configured separately by setting
> >> the 'ncinport' environment variable and the destination port can be
> >> -configured by setting the 'ncoutport' environment variable.
> >> +configured by setting the 'ncoutport' environment variable. Note that
> >> +you need to set up the network interface (e.g. using DHCP) before it
> >> +can be used for network console.
> >>
> >> For example, if your server IP is 192.168.1.1, you could use::
> >>
> >> @@ -107,3 +109,32 @@ as follows:
> >>
> >> Note that unlike the U-Boot implementation the Linux netconsole is
> >> unidirectional, i. e. you have console output only in Linux.
> >> +
> >> +Setup via environment
> >> +-
> >> +
> >> +If persistent environment is enabled in your U-Boot configuration, you
> >> +can configure the network console using the environment. For example::
> >> +
> >> +=> env set autoload no
> >> +=> env set hostname "u-boot"
> >> +=> env set bootdelay 5
> >> +=> env set nc 'dhcp; env set stdout nc; env set stderr nc; env set
> >> stdin nc'
> >> +=> env set ncip 192.168.1.1
> >> +=> env set preboot "${preboot}; run nc;"
> >> +=> env save
> >> +=> reset
> >> +
> >> +``autoload no`` tells the ``dhcp`` command to configure the network
> >> +interface without trying to load an image. ``hostname "u-boot"`` sets
> >> +the hostname to be sent in DHCP requests, so they are easy to
> >> +recognize in the DHCP server log. The command in ``nc`` calls ``dhcp``
> >> +to make sure the network interface is set up before enabling
> >> +netconsole.
> >> +
> >> +Adding ``nc`` to ``preboot`` tells U-Boot to activate netconsole
> >> +before trying to find any boot options, so you can interact with it if
> >> +desired.
> >> +
> >> +``env save`` stores the settings persistently, and ``reset`` then
> >> +triggers a fresh start that will use the changed settings.
> >> --
> >> 2.43.0
> >>
> >
> > Just for information, if the board uses static IP then the example
> > would be slightly different. I usually use static IP and ping the
> > netconsole server to make sure it is up. However, I think this DHCP
> > example is good enough to show how to prepare and activate netconsole.
>
> Maybe it'd make sense to link to a general network setup section for
> alternatives? The problem is I can't find any in the existing docs, the
> closest I see is the "Automatically updated variables" list:
> https://docs.u-boot.org/en/latest/usage/environment.html#automatically-updated-variables
>
> As far as I understand you can also set the environment variables
> mentioned there manually to configure networking, but I'm not sure if
> that applies to all of them.
>
> Is my understanding correct? If yes, I could send a separate patch to
> add that information, and maybe rename the section to "Network
> configuration variables".
Currently, there is no documentation for using static IP in netconsole
that I'm aware of. I think it would be great if you send a separate
patch after this. Basically, the current u-boot network driver model
will automatically bring up the network when we try to use it, e.g.
pinging a server, or dhcp.
So the difference is instead of dhcp in your example, we could also do this:
env set ipaddr 192.168.1.100
env set nc 'if ping ${ncip}; then env set stdout nc; env set stderr
nc; env set stdin nc; fi'
Note that the board ipaddr needed to be set before the ping.
All the best,
Tony
>
> Best regards,
> Fiona
>
> > Reviewed-by: Tony Dinh
> >
> > All the best,
> > Tony
>
Re: [PATCH v2 1/2] doc: Detailed example for netconsole setup
Hi Fiona,
On Thu, May 16, 2024 at 3:43 AM Fiona Klute wrote:
>
> This adds details that I would have liked to have readily available,
> in particular how to activate the network interface before enabling
> netconsole, and how to integrate netconsole so you can use the U-Boot
> prompt.
>
> Signed-off-by: Fiona Klute
> ---
> Changes in v2:
> * Include stderr redirection
> * Use 4 spaces instead of tabs for code block to avoid overflowing
> lines
>
> doc/usage/netconsole.rst | 33 -
> 1 file changed, 32 insertions(+), 1 deletion(-)
>
> diff --git a/doc/usage/netconsole.rst b/doc/usage/netconsole.rst
> index 2aa3b9ccc5..647f0c220b 100644
> --- a/doc/usage/netconsole.rst
> +++ b/doc/usage/netconsole.rst
> @@ -18,7 +18,9 @@ broadcast address and port are used. If it is set to
> an IP
> address of 0 (or 0.0.0.0) then no messages are sent to the network.
> The source / listening port can be configured separately by setting
> the 'ncinport' environment variable and the destination port can be
> -configured by setting the 'ncoutport' environment variable.
> +configured by setting the 'ncoutport' environment variable. Note that
> +you need to set up the network interface (e.g. using DHCP) before it
> +can be used for network console.
>
> For example, if your server IP is 192.168.1.1, you could use::
>
> @@ -107,3 +109,32 @@ as follows:
>
> Note that unlike the U-Boot implementation the Linux netconsole is
> unidirectional, i. e. you have console output only in Linux.
> +
> +Setup via environment
> +-
> +
> +If persistent environment is enabled in your U-Boot configuration, you
> +can configure the network console using the environment. For example::
> +
> +=> env set autoload no
> +=> env set hostname "u-boot"
> +=> env set bootdelay 5
> +=> env set nc 'dhcp; env set stdout nc; env set stderr nc; env set stdin
> nc'
> +=> env set ncip 192.168.1.1
> +=> env set preboot "${preboot}; run nc;"
> +=> env save
> +=> reset
> +
> +``autoload no`` tells the ``dhcp`` command to configure the network
> +interface without trying to load an image. ``hostname "u-boot"`` sets
> +the hostname to be sent in DHCP requests, so they are easy to
> +recognize in the DHCP server log. The command in ``nc`` calls ``dhcp``
> +to make sure the network interface is set up before enabling
> +netconsole.
> +
> +Adding ``nc`` to ``preboot`` tells U-Boot to activate netconsole
> +before trying to find any boot options, so you can interact with it if
> +desired.
> +
> +``env save`` stores the settings persistently, and ``reset`` then
> +triggers a fresh start that will use the changed settings.
> --
> 2.43.0
>
Just for information, if the board uses static IP then the example
would be slightly different. I usually use static IP and ping the
netconsole server to make sure it is up. However, I think this DHCP
example is good enough to show how to prepare and activate netconsole.
Reviewed-by: Tony Dinh
All the best,
Tony
Re: [PATCH v2 2/2] doc: Update netconsole examples, mention stderr
Hi Fiona, On Thu, May 16, 2024 at 3:43 AM Fiona Klute wrote: > > Stderr was missing from the initial description and example. > > As I understand the env command documentation the subcommand style is > preferred, though the old format is still fully supported. > > Signed-off-by: Fiona Klute > --- > Changes in v2: > * Mention stderr redirection > * Use 4 spaces instead of tabs for code block to avoid overflowing > lines > > doc/usage/netconsole.rst | 16 > 1 file changed, 8 insertions(+), 8 deletions(-) > > diff --git a/doc/usage/netconsole.rst b/doc/usage/netconsole.rst > index 647f0c220b..f745615d9a 100644 > --- a/doc/usage/netconsole.rst > +++ b/doc/usage/netconsole.rst > @@ -3,10 +3,10 @@ Network console > > In U-Boot, we implemented the networked console via the standard > "devices" mechanism, which means that you can switch between the > -serial and network input/output devices by adjusting the 'stdin' and > -'stdout' environment variables. To switch to the networked console, > -set either of these variables to "nc". Input and output can be > -switched independently. > +serial and network input/output devices by adjusting the 'stdin', > +'stdout', and 'stderr' environment variables. To switch to the > +networked console, set either of these variables to "nc". Input and > +output can be switched independently. > > The default buffer size can be overridden by setting > CFG_NETCONSOLE_BUFFER_SIZE. > @@ -24,10 +24,10 @@ can be used for network console. > > For example, if your server IP is 192.168.1.1, you could use:: > > - => setenv nc 'setenv stdout nc;setenv stdin nc' > - => setenv ncip 192.168.1.1 > - => saveenv > - => run nc > +=> env set nc 'env set stdout nc; env set stderr nc; env set stdin nc' > +=> env set ncip 192.168.1.1 > +=> env save > +=> run nc > > On the host side, please use this script to access the console > > -- > 2.43.0 > Reviewed-by: Tony Dinh All the best, Tony
Re: [PATCH 1/2] doc: Detailed example for netconsole setup
Hi Fiona,
On Tue, May 14, 2024 at 5:28 PM Fiona Klute wrote:
>
> This adds details that I would have liked to have readily available,
> in particular how to activate the network interface before enabling
> netconsole, and how to integrate netconsole so you can use the U-Boot
> prompt.
>
> Signed-off-by: Fiona Klute
> ---
> doc/usage/netconsole.rst | 33 -
> 1 file changed, 32 insertions(+), 1 deletion(-)
>
> diff --git a/doc/usage/netconsole.rst b/doc/usage/netconsole.rst
> index 2aa3b9ccc5..0c983e6970 100644
> --- a/doc/usage/netconsole.rst
> +++ b/doc/usage/netconsole.rst
> @@ -18,7 +18,9 @@ broadcast address and port are used. If it is set to
> an IP
> address of 0 (or 0.0.0.0) then no messages are sent to the network.
> The source / listening port can be configured separately by setting
> the 'ncinport' environment variable and the destination port can be
> -configured by setting the 'ncoutport' environment variable.
> +configured by setting the 'ncoutport' environment variable. Note that
> +you need to set up the network interface (e.g. using DHCP) before it
> +can be used for network console.
>
> For example, if your server IP is 192.168.1.1, you could use::
>
> @@ -107,3 +109,32 @@ as follows:
>
> Note that unlike the U-Boot implementation the Linux netconsole is
> unidirectional, i. e. you have console output only in Linux.
> +
> +Setup via environment
> +-
> +
> +If persistent environment is enabled in your U-Boot configuration, you
> +can configure the network console using the environment. For example::
> +
> + => env set autoload no
> + => env set hostname "u-boot"
> + => env set bootdelay 5
> + => env set nc 'dhcp; env set stdout nc; env set stdin nc'
We would need "env set stderr nc" here, too.
All the best,
Tony
> + => env set ncip 192.168.1.1
> + => env set preboot "${preboot}; run nc;"
> + => env save
> + => reset
> +
> +``autoload no`` tells the ``dhcp`` command to configure the network
> +interface without trying to load an image. ``hostname "u-boot"`` sets
> +the hostname to be sent in DHCP requests, so they are easy to
> +recognize in the DHCP server log. The command in ``nc`` calls ``dhcp``
> +to make sure the network interface is set up before enabling
> +netconsole.
> +
> +Adding ``nc`` to ``preboot`` tells U-Boot to activate netconsole
> +before trying to find any boot options, so you can interact with it if
> +desired.
> +
> +``env save`` stores the settings persistently, and ``reset`` then
> +triggers a fresh start that will use the changed settings.
> --
> 2.43.0
>
Re: [PATCH 11/81] ata: Remove and add needed includes
On Wed, May 1, 2024 at 6:31 PM Tom Rini wrote:
>
> Remove from this driver directory and when needed
> add missing include files directly.
>
> Signed-off-by: Tom Rini
> ---
> Cc: Tom Rini
> Cc: Stefan Roese
> Cc: Samuel Holland
> Cc: Sam Edwards
> Cc: Andre Przywara
> Cc: Simon Glass
> Cc: Jonas Karlman
> Cc: Johan Jonker
> Cc: Bin Meng
> Cc: Tony Dinh
> Cc: Michal Simek
Reviewed-by: Tony Dinh
> ---
> drivers/ata/ahci-pci.c | 1 -
> drivers/ata/ahci-uclass.c | 1 -
> drivers/ata/ahci.c | 2 +-
> drivers/ata/ahci_mvebu.c | 1 -
> drivers/ata/ahci_sunxi.c | 1 -
> drivers/ata/dwc_ahci.c | 1 -
> drivers/ata/dwc_ahsata.c | 1 -
> drivers/ata/fsl_sata.c | 1 -
> drivers/ata/libata.c | 2 +-
> drivers/ata/mtk_ahci.c | 1 -
> drivers/ata/sata.c | 1 -
> drivers/ata/sata_bootdev.c | 1 -
> drivers/ata/sata_ceva.c| 1 -
> drivers/ata/sata_mv.c | 2 +-
> drivers/ata/sata_sil.c | 1 -
> 15 files changed, 3 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/ata/ahci-pci.c b/drivers/ata/ahci-pci.c
> index 5356b9d83d34..f2102aaa6353 100644
> --- a/drivers/ata/ahci-pci.c
> +++ b/drivers/ata/ahci-pci.c
> @@ -3,7 +3,6 @@
> * Copyright (C) 2017, Bin Meng
> */
>
> -#include
> #include
> #include
> #include
> diff --git a/drivers/ata/ahci-uclass.c b/drivers/ata/ahci-uclass.c
> index d398b50b9a1e..7affb3f1ec79 100644
> --- a/drivers/ata/ahci-uclass.c
> +++ b/drivers/ata/ahci-uclass.c
> @@ -6,7 +6,6 @@
>
> #define LOG_CATEGORY UCLASS_AHCI
>
> -#include
> #include
> #include
>
> diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
> index 04ddc3394648..ac869296d525 100644
> --- a/drivers/ata/ahci.c
> +++ b/drivers/ata/ahci.c
> @@ -8,10 +8,10 @@
> *
> * This driver provides a SCSI interface to SATA.
> */
> -#include
> #include
> #include
> #include
> +#include
> #include
> #include
>
> diff --git a/drivers/ata/ahci_mvebu.c b/drivers/ata/ahci_mvebu.c
> index f05150d61ddf..f6e2d6bee45b 100644
> --- a/drivers/ata/ahci_mvebu.c
> +++ b/drivers/ata/ahci_mvebu.c
> @@ -3,7 +3,6 @@
> * Copyright (C) 2016 Stefan Roese
> */
>
> -#include
> #include
> #include
> #include
> diff --git a/drivers/ata/ahci_sunxi.c b/drivers/ata/ahci_sunxi.c
> index 9064774e6614..6cf5cee055e7 100644
> --- a/drivers/ata/ahci_sunxi.c
> +++ b/drivers/ata/ahci_sunxi.c
> @@ -1,4 +1,3 @@
> -#include
> #include
> #include
> #include
> diff --git a/drivers/ata/dwc_ahci.c b/drivers/ata/dwc_ahci.c
> index 15fd3e365b2b..b480cde4465b 100644
> --- a/drivers/ata/dwc_ahci.c
> +++ b/drivers/ata/dwc_ahci.c
> @@ -8,7 +8,6 @@
> * Author: Mugunthan V N
> */
>
> -#include
> #include
> #include
> #include
> diff --git a/drivers/ata/dwc_ahsata.c b/drivers/ata/dwc_ahsata.c
> index b4d4e39c9b3b..a29d641343ed 100644
> --- a/drivers/ata/dwc_ahsata.c
> +++ b/drivers/ata/dwc_ahsata.c
> @@ -4,7 +4,6 @@
> * Terry Lv
> */
>
> -#include
> #include
> #include
> #include
> diff --git a/drivers/ata/fsl_sata.c b/drivers/ata/fsl_sata.c
> index 969bc191f8e8..4990148388b6 100644
> --- a/drivers/ata/fsl_sata.c
> +++ b/drivers/ata/fsl_sata.c
> @@ -5,7 +5,6 @@
> * Author: Dave Liu
> */
>
> -#include
> #include
> #include
> #include
> diff --git a/drivers/ata/libata.c b/drivers/ata/libata.c
> index 47e2c5c1cc40..ef659cb1728a 100644
> --- a/drivers/ata/libata.c
> +++ b/drivers/ata/libata.c
> @@ -5,9 +5,9 @@
> * port from the libata of linux kernel
> */
>
> -#include
> #include
> #include
> +#include
>
> u64 ata_id_n_sectors(u16 *id)
> {
> diff --git a/drivers/ata/mtk_ahci.c b/drivers/ata/mtk_ahci.c
> index 2c5227df306b..53aabee0a5e6 100644
> --- a/drivers/ata/mtk_ahci.c
> +++ b/drivers/ata/mtk_ahci.c
> @@ -8,7 +8,6 @@
> * Author: Frank Wunderlich
> */
>
> -#include
> #include
> #include
> #include
> diff --git a/drivers/ata/sata.c b/drivers/ata/sata.c
> index 784d9bbeacb4..84437d3d346b 100644
> --- a/drivers/ata/sata.c
> +++ b/drivers/ata/sata.c
> @@ -9,7 +9,6 @@
> * Dave Liu
> */
>
> -#include
> #include
> #include
> #include
> diff --git a/drivers/ata/sata_bootdev.c b/drivers/ata/sata_bootdev.c
> index f638493ce04f..a5ca6f6fd5bb 100644
> --- a/drivers/ata/sata_bootdev.c
> +++ b/drivers/ata/sata_bootdev.c
> @@ -5,7 +5,6 @@
> * Copyright 2023 Tony Dinh
> */
>
> -#include
> #include
> #include
> #include
> diff --g
Re: [PATCH 149/149] board: zyxel: Remove and add needed includes
On Tue, Apr 30, 2024 at 7:46 PM Tom Rini wrote: > > Remove from this board vendor directory and when needed > add missing include files directly. > > Signed-off-by: Tom Rini > --- > Cc: Tony Dinh > Cc: Luka Perkov Reviewed-by: Tony Dinh Tested-by: Tony Dinh # on Zyxel NSA310s > --- > board/zyxel/nsa310s/nsa310s.c | 1 - > board/zyxel/nsa325/nsa325.c | 1 - > 2 files changed, 2 deletions(-) > > diff --git a/board/zyxel/nsa310s/nsa310s.c b/board/zyxel/nsa310s/nsa310s.c > index b3ea6608914a..d018b5738242 100644 > --- a/board/zyxel/nsa310s/nsa310s.c > +++ b/board/zyxel/nsa310s/nsa310s.c > @@ -4,7 +4,6 @@ > * Copyright (C) 2015 Gerald Kerma > */ > > -#include > #include > #include > #include > diff --git a/board/zyxel/nsa325/nsa325.c b/board/zyxel/nsa325/nsa325.c > index f5f63ee5d3b0..38340b33c8bf 100644 > --- a/board/zyxel/nsa325/nsa325.c > +++ b/board/zyxel/nsa325/nsa325.c > @@ -14,7 +14,6 @@ > * Marvell Semiconductor > */ > > -#include > #include > #include > #include > -- > 2.34.1 >
Re: [PATCH 075/149] board: iomega: Remove and add needed includes
On Tue, Apr 30, 2024 at 7:44 PM Tom Rini wrote: > > Remove from this board vendor directory and when needed > add missing include files directly. > > Signed-off-by: Tom Rini > --- > Cc: Tony Dinh > Cc: Luka Perkov Reviewed-by: Tony Dinh > --- > board/iomega/iconnect/iconnect.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/board/iomega/iconnect/iconnect.c > b/board/iomega/iconnect/iconnect.c > index 038716020019..00b08987e9e8 100644 > --- a/board/iomega/iconnect/iconnect.c > +++ b/board/iomega/iconnect/iconnect.c > @@ -6,7 +6,6 @@ > * Luka Perkov > */ > > -#include > #include > #include > #include > -- > 2.34.1 >
Re: [PATCH 039/149] board: cloudengines: Remove and add needed includes
On Tue, Apr 30, 2024 at 7:44 PM Tom Rini wrote: > > Remove from this board vendor directory and when needed > add missing include files directly. > > Signed-off-by: Tom Rini > --- > Cc: Dave Purdy > Cc: Tony Dinh Reviewed-by: Tony Dinh > --- > board/cloudengines/pogo_e02/pogo_e02.c | 1 - > board/cloudengines/pogo_v4/pogo_v4.c | 1 - > 2 files changed, 2 deletions(-) > > diff --git a/board/cloudengines/pogo_e02/pogo_e02.c > b/board/cloudengines/pogo_e02/pogo_e02.c > index 59e1218b411a..48eee67129fa 100644 > --- a/board/cloudengines/pogo_e02/pogo_e02.c > +++ b/board/cloudengines/pogo_e02/pogo_e02.c > @@ -10,7 +10,6 @@ > * Written-by: Prafulla Wadaskar > */ > > -#include > #include > #include > #include > diff --git a/board/cloudengines/pogo_v4/pogo_v4.c > b/board/cloudengines/pogo_v4/pogo_v4.c > index 61ce0d59c77e..c8ad563f721d 100644 > --- a/board/cloudengines/pogo_v4/pogo_v4.c > +++ b/board/cloudengines/pogo_v4/pogo_v4.c > @@ -11,7 +11,6 @@ > * Written-by: Prafulla Wadaskar > */ > > -#include > #include > #include > #include > -- > 2.34.1 >
Re: [PATCH 011/149] board: Seagate: Remove and add needed includes
On Tue, Apr 30, 2024 at 7:43 PM Tom Rini wrote: > > Remove from this board vendor directory and when needed > add missing include files directly. > > Signed-off-by: Tom Rini > --- > Cc: Tony Dinh > Cc: Evgeni Dobrev Reviewed-by: Tony Dinh > --- > board/Seagate/dockstar/dockstar.c | 1 - > board/Seagate/goflexhome/goflexhome.c | 1 - > board/Seagate/nas220/nas220.c | 1 - > 3 files changed, 3 deletions(-) > > diff --git a/board/Seagate/dockstar/dockstar.c > b/board/Seagate/dockstar/dockstar.c > index d72e3ef24ee6..e6ec00a9c6cc 100644 > --- a/board/Seagate/dockstar/dockstar.c > +++ b/board/Seagate/dockstar/dockstar.c > @@ -9,7 +9,6 @@ > * Marvell Semiconductor > */ > > -#include > #include > #include > #include > diff --git a/board/Seagate/goflexhome/goflexhome.c > b/board/Seagate/goflexhome/goflexhome.c > index caea89c10e07..b2d0ad8c3f22 100644 > --- a/board/Seagate/goflexhome/goflexhome.c > +++ b/board/Seagate/goflexhome/goflexhome.c > @@ -12,7 +12,6 @@ > * Marvell Semiconductor > */ > > -#include > #include > #include > #include > diff --git a/board/Seagate/nas220/nas220.c b/board/Seagate/nas220/nas220.c > index cd2bbdad1cd6..fa7553250d1c 100644 > --- a/board/Seagate/nas220/nas220.c > +++ b/board/Seagate/nas220/nas220.c > @@ -8,7 +8,6 @@ > * Marvell Semiconductor > */ > > -#include > #include > #include > #include > -- > 2.34.1 >
Re: [PATCH 010/149] board: Marvell: Remove and add needed includes
On Tue, Apr 30, 2024 at 7:43 PM Tom Rini wrote: > > Remove from this board vendor directory and when needed > add missing include files directly. > > Signed-off-by: Tom Rini > --- > Cc: Stefan Roese > Cc: Chris Packham > Cc: Tony Dinh > Cc: Jason Cooper > Cc: Siddarth Gore > Cc: Aaron Williams Reviewed-by: Tony Dinh > --- > arch/arm/mach-kirkwood/include/mach/mpp.h | 2 ++ > board/Marvell/db-88f6720/db-88f6720.c | 1 - > board/Marvell/db-88f6820-amc/db-88f6820-amc.c | 2 +- > board/Marvell/db-88f6820-gp/db-88f6820-gp.c | 2 +- > board/Marvell/db-mv784mp-gp/db-mv784mp-gp.c | 1 - > board/Marvell/db-xc3-24g4xg/db-xc3-24g4xg.c | 1 - > board/Marvell/dreamplug/dreamplug.c | 1 - > board/Marvell/guruplug/guruplug.c | 1 - > board/Marvell/mvebu_alleycat-5/board.c| 2 +- > board/Marvell/mvebu_armada-37xx/board.c | 2 +- > board/Marvell/mvebu_armada-8k/board.c | 2 +- > board/Marvell/octeontx2/soc-utils.c | 1 - > board/Marvell/openrd/openrd.c | 1 - > board/Marvell/sheevaplug/sheevaplug.c | 1 - > 14 files changed, 7 insertions(+), 13 deletions(-) > > diff --git a/arch/arm/mach-kirkwood/include/mach/mpp.h > b/arch/arm/mach-kirkwood/include/mach/mpp.h > index 4d1f58c0cbdf..e2757942590b 100644 > --- a/arch/arm/mach-kirkwood/include/mach/mpp.h > +++ b/arch/arm/mach-kirkwood/include/mach/mpp.h > @@ -8,6 +8,8 @@ > #ifndef __KIRKWOOD_MPP_H > #define __KIRKWOOD_MPP_H > > +#include > + > #define MPP(_num, _sel, _in, _out, _F6180, _F6190, _F6192, _F6281) ( \ > /* MPP number */((_num) & 0xff) | \ > /* MPP select value */ (((_sel) & 0xf) << 8) | \ > diff --git a/board/Marvell/db-88f6720/db-88f6720.c > b/board/Marvell/db-88f6720/db-88f6720.c > index 26c30647fbb0..920421366f11 100644 > --- a/board/Marvell/db-88f6720/db-88f6720.c > +++ b/board/Marvell/db-88f6720/db-88f6720.c > @@ -3,7 +3,6 @@ > * Copyright (C) 2016 Stefan Roese > */ > > -#include > #include > #include > #include > diff --git a/board/Marvell/db-88f6820-amc/db-88f6820-amc.c > b/board/Marvell/db-88f6820-amc/db-88f6820-amc.c > index 122c63d11f99..0f92cc385bc8 100644 > --- a/board/Marvell/db-88f6820-amc/db-88f6820-amc.c > +++ b/board/Marvell/db-88f6820-amc/db-88f6820-amc.c > @@ -3,7 +3,7 @@ > * Copyright (C) 2015 Stefan Roese > */ > > -#include > +#include > #include > #include > #include > diff --git a/board/Marvell/db-88f6820-gp/db-88f6820-gp.c > b/board/Marvell/db-88f6820-gp/db-88f6820-gp.c > index 1edc1cb6515c..8f8b2720107a 100644 > --- a/board/Marvell/db-88f6820-gp/db-88f6820-gp.c > +++ b/board/Marvell/db-88f6820-gp/db-88f6820-gp.c > @@ -3,7 +3,7 @@ > * Copyright (C) 2015 Stefan Roese > */ > > -#include > +#include > #include > #include > #include > diff --git a/board/Marvell/db-mv784mp-gp/db-mv784mp-gp.c > b/board/Marvell/db-mv784mp-gp/db-mv784mp-gp.c > index 9e1fdecfca4d..6bca1f91a0a4 100644 > --- a/board/Marvell/db-mv784mp-gp/db-mv784mp-gp.c > +++ b/board/Marvell/db-mv784mp-gp/db-mv784mp-gp.c > @@ -3,7 +3,6 @@ > * Copyright (C) 2014 Stefan Roese > */ > > -#include > #include > #include > #include > diff --git a/board/Marvell/db-xc3-24g4xg/db-xc3-24g4xg.c > b/board/Marvell/db-xc3-24g4xg/db-xc3-24g4xg.c > index 0abdca1cd210..a7a84798a53b 100644 > --- a/board/Marvell/db-xc3-24g4xg/db-xc3-24g4xg.c > +++ b/board/Marvell/db-xc3-24g4xg/db-xc3-24g4xg.c > @@ -3,7 +3,6 @@ > * Copyright (C) 2015 Stefan Roese > */ > > -#include > #include > #include > #include > diff --git a/board/Marvell/dreamplug/dreamplug.c > b/board/Marvell/dreamplug/dreamplug.c > index d15faa1cb7ff..381275061318 100644 > --- a/board/Marvell/dreamplug/dreamplug.c > +++ b/board/Marvell/dreamplug/dreamplug.c > @@ -8,7 +8,6 @@ > * Written-by: Siddarth Gore > */ > > -#include > #include > #include > #include > diff --git a/board/Marvell/guruplug/guruplug.c > b/board/Marvell/guruplug/guruplug.c > index ea87ded222e6..7c3cea22b936 100644 > --- a/board/Marvell/guruplug/guruplug.c > +++ b/board/Marvell/guruplug/guruplug.c > @@ -5,7 +5,6 @@ > * Written-by: Siddarth Gore > */ > > -#include > #include > #include > #include > diff --git a/board/Marvell/mvebu_alleycat-5/board.c > b/board/Marvell/mvebu_alleycat-5/board.c > index 0c4f8e03b859..c1b7cc3b613c 100644 > --- a/board/Marvell/mvebu_alleycat-5/board.c > +++ b/board/Marvell/mvebu_alleycat-5/board.c > @@ -1,6 +1,6 @@ > // SPDX-License-Identifier: GPL-2.0+ > > -#inclu
Re: [PATCH 001/149] global: Make include
Hi Tom, This patch does not apply cleanly on the master branch. Perhaps this patch series has a dependency on another previous patch? Please see below at arch/arm/lib/bdinfo.c. On Tue, Apr 30, 2024 at 7:50 PM Tom Rini wrote: > > This follows the example of RISC-V where includes > directly as "gd" includes a reference to bd_info already > and so the first must include the second anyhow. We then remove > from all of the places which include references to "gd" > an so have already. > > Signed-off-by: Tom Rini > --- > api/api_platform-arm.c | 1 - > api/api_platform-mips.c| 1 - > api/api_platform-powerpc.c | 1 - > arch/arc/include/asm/global_data.h | 2 ++ > arch/arm/include/asm/global_data.h | 1 + > arch/arm/lib/bdinfo.c | 1 - > arch/arm/lib/cache-cp15.c | 1 - > arch/arm/mach-davinci/cpu.c| 1 - > arch/arm/mach-davinci/misc.c | 1 - > arch/arm/mach-davinci/spl.c| 1 - > arch/arm/mach-imx/ele_ahab.c | 1 - > arch/arm/mach-imx/mx5/mx53_dram.c | 1 - > arch/arm/mach-mediatek/mt7622/init.c | 1 - > arch/arm/mach-mediatek/mt7981/init.c | 1 - > arch/arm/mach-mediatek/mt7986/init.c | 1 - > arch/arm/mach-mediatek/mt7988/init.c | 1 - > arch/arm/mach-mvebu/armada8k/dram.c| 1 - > arch/arm/mach-mvebu/dram.c | 1 - > arch/arm/mach-omap2/omap-cache.c | 1 - > arch/arm/mach-omap2/omap3/emif4.c | 1 - > arch/arm/mach-omap2/omap3/sdrc.c | 1 - > arch/arm/mach-owl/soc.c| 1 - > arch/arm/mach-renesas/memmap-gen3.c| 1 - > arch/arm/mach-renesas/memmap-rzg2l.c | 1 - > arch/arm/mach-socfpga/clock_manager.c | 1 - > arch/arm/mach-socfpga/clock_manager_agilex5.c | 1 - > arch/arm/mach-socfpga/spl_a10.c| 1 - > arch/arm/mach-socfpga/spl_agilex.c | 1 - > arch/arm/mach-socfpga/spl_gen5.c | 1 - > arch/arm/mach-socfpga/spl_n5x.c| 1 - > arch/arm/mach-socfpga/spl_s10.c| 1 - > arch/arm/mach-uniphier/dram_init.c | 1 - > arch/arm/mach-versal-net/clk.c | 1 - > arch/arm/mach-versal-net/cpu.c | 1 - > arch/arm/mach-versal/clk.c | 1 - > arch/arm/mach-versal/cpu.c | 1 - > arch/arm/mach-zynqmp/clk.c | 1 - > arch/arm/mach-zynqmp/cpu.c | 1 - > arch/m68k/include/asm/global_data.h| 2 ++ > arch/m68k/lib/bdinfo.c | 1 - > arch/microblaze/cpu/spl.c | 1 - > arch/microblaze/include/asm/global_data.h | 1 + > arch/mips/include/asm/global_data.h| 1 + > arch/mips/lib/traps.c | 1 - > arch/nios2/include/asm/global_data.h | 1 + > arch/powerpc/cpu/mpc83xx/interrupts.c | 1 - > arch/powerpc/cpu/mpc83xx/pcie.c| 1 - > arch/powerpc/cpu/mpc83xx/spd_sdram.c | 1 - > arch/powerpc/cpu/mpc83xx/speed.c | 1 - > arch/powerpc/cpu/mpc85xx/b4860_ids.c | 1 + > arch/powerpc/cpu/mpc85xx/cmd_errata.c | 1 - > arch/powerpc/cpu/mpc85xx/fsl_corenet2_serdes.c | 1 - > arch/powerpc/cpu/mpc85xx/p2041_ids.c | 3 ++- > arch/powerpc/cpu/mpc85xx/p2041_serdes.c| 1 - > arch/powerpc/cpu/mpc85xx/p3041_ids.c | 1 + > arch/powerpc/cpu/mpc85xx/p4080_ids.c | 1 + > arch/powerpc/cpu/mpc85xx/p5040_ids.c | 1 + > arch/powerpc/cpu/mpc85xx/speed.c | 1 - > arch/powerpc/cpu/mpc85xx/spl_minimal.c | 1 - > arch/powerpc/cpu/mpc85xx/t1024_ids.c | 3 ++- > arch/powerpc/cpu/mpc85xx/t1024_serdes.c| 1 - > arch/powerpc/cpu/mpc85xx/t1040_ids.c | 3 ++- > arch/powerpc/cpu/mpc85xx/t1040_serdes.c| 3 ++- > arch/powerpc/cpu/mpc85xx/t2080_ids.c | 3 ++- > arch/powerpc/cpu/mpc85xx/t2080_serdes.c| 3 ++- > arch/powerpc/cpu/mpc85xx/t4240_ids.c | 3 ++- > arch/powerpc/cpu/mpc85xx/t4240_serdes.c| 1 - > arch/powerpc/cpu/mpc8xxx/fsl_lbc.c | 1 - > arch/powerpc/cpu/mpc8xxx/fsl_pamu.c| 4 +++- > arch/powerpc/cpu/mpc8xxx/law.c | 1 - > arch/powerpc/cpu/mpc8xxx/pamu_table.c | 1 - > arch/powerpc/cpu/mpc8xxx/srio.c| 3 ++- > arch/powerpc/include/asm/fsl_liodn.h | 4 +++- > arch/powerpc/include/asm/fsl_portals.h | 2 ++ > arch/powerpc/include/asm/global_data.h | 2 ++ > arch/powerpc/lib/bdinfo.c | 1 - > arch/riscv/lib/boot.c | 3 ++- > arch/sandbox/include/asm/global_data.h | 1 + > arch/sh/include/asm/global_data.h | 2 ++ >
Re: [PATCH u-boot-mvebu 00/10] Turris Omnia DDR training changes
Hi Marek, On Tue, Apr 16, 2024 at 3:11 AM Marek Behún wrote: > > Hi Tony, > > hmm no I did not change the version number. > > The changes are only relevant for debug messages, there is no > functional changes in how the DDR training is done, unless I made a > mistake. > > I am not sure that changing the version is a good idea unless this is > also done for the upstream where I sent the PR. But who knows if > Marvell will have some people assigned to merge the PR. > > Since U-Boot prints its own version, people can easily reproduce the > code for a given binary from U-Boot version string. OK, sounds good. Tested-by: Tony Dinh # regression test for DS116 All the best, Tony > > Marek > > On Mon, 15 Apr 2024 15:20:49 -0700 > Tony Dinh wrote: > > > Hi Marek, > > > > I'm running a regression test with this patch on another Armada 385 > > board (Synology DS116). And > > it is running without problem. > > > > I noticed that there is no version bump. Is this still 14.0.0? It's kind of > > hard to see which version we are using without a minor revision such as > > 14.0.1. > > > > All the best, > > Tony > > > > On Mon, Apr 15, 2024 at 9:39 AM Marek Behún wrote: > > > > > > Hi Stefan, > > > > > > this series adds some changes to DDR3 training for Armada 38x and > > > Turris Omnia. > > > > > > - patches 1-4 are meant to allow for reducing another 10 KiB in the > > > SPL binary. They were also sent to mv-ddr-marvell, via PR on github, > > > https://github.com/MarvellEmbeddedProcessors/mv-ddr-marvell/pull/45/ > > > but I am told that Armada team has left Marvell, so who knows if this > > > will ever be merged there > > > - patch 5 enables this reduction for Turris Omnia > > > - patches 6-8 import old DDR3 training code and make some changes so > > > that it works with U-Boot. The reason why this is being done is > > > explained in patch 6 > > > - patch 9 glues the old DDR3 training code to current U-Boot > > > - patch 10 allows for dynamic selection of old DDR3 training code on > > > Turris Omnia, via an U-Boot environment variable > > > > > > Marek > > > > > > Marek Behún (10): > > > ddr: marvell: a38x: debug: return from ddr3_tip_print_log() early if > > > we won't print anything > > > ddr: marvell: a38x: debug: Remove unused variables > > > ddr: marvell: a38x: debug: Define DDR_VIEWER_TOOL variables only if > > > needed, and make them static > > > ddr: marvell: a38x: debug: Allow compiling with immutable debug > > > settings to reduce binary size > > > arm: mvebu: turris_omnia: Enable immutable debug settings in DDR3 > > > training by default > > > ddr: marvell: a38x: Import old DDR training code from 2017 version of > > > U-Boot > > > ddr: marvell: a38x: old: Fix some compiler warning of the old code > > > ddr: marvell: a38x: old: Backport immutable debug settings > > > arm: mvebu: a38x: Add optional support for using old DDR3 training > > > code > > > arm: mvebu: turris_omnia: Support old DDR3 training, selectable via > > > env var > > > > > > arch/arm/mach-mvebu/Kconfig | 15 + > > > arch/arm/mach-mvebu/include/mach/cpu.h|1 + > > > arch/arm/mach-mvebu/spl.c | 37 +- > > > board/CZ.NIC/turris_omnia/Makefile|1 + > > > board/CZ.NIC/turris_omnia/old_ddr3_training.c | 79 + > > > board/CZ.NIC/turris_omnia/turris_omnia.c |2 +- > > > configs/turris_omnia_defconfig|1 + > > > drivers/ddr/marvell/a38x/Makefile |2 + > > > drivers/ddr/marvell/a38x/ddr3_debug.c | 30 +- > > > drivers/ddr/marvell/a38x/ddr3_init.c |3 +- > > > drivers/ddr/marvell/a38x/ddr3_init.h | 43 +- > > > drivers/ddr/marvell/a38x/old/Makefile | 29 + > > > drivers/ddr/marvell/a38x/old/ddr3_a38x.c | 738 + > > > drivers/ddr/marvell/a38x/old/ddr3_a38x.h | 93 + > > > .../marvell/a38x/old/ddr3_a38x_mc_static.h| 226 ++ > > > .../ddr/marvell/a38x/old/ddr3_a38x_topology.h | 22 + > > > .../ddr/marvell/a38x/old/ddr3_a38x_training.c | 40 + > > > drivers/ddr/marvell/a38x/old/ddr3_debug.c | 1545 ++ > > > .../marvell/a38x/old/ddr3_hws_hw_training.c | 148 + > > > .../marvell/a38x/old/ddr3_hws_hw_training.h | 49
Re: [PATCH u-boot-mvebu 00/10] Turris Omnia DDR training changes
Hi Marek, I'm running a regression test with this patch on another Armada 385 board (Synology DS116). And it is running without problem. I noticed that there is no version bump. Is this still 14.0.0? It's kind of hard to see which version we are using without a minor revision such as 14.0.1. All the best, Tony On Mon, Apr 15, 2024 at 9:39 AM Marek Behún wrote: > > Hi Stefan, > > this series adds some changes to DDR3 training for Armada 38x and > Turris Omnia. > > - patches 1-4 are meant to allow for reducing another 10 KiB in the > SPL binary. They were also sent to mv-ddr-marvell, via PR on github, > https://github.com/MarvellEmbeddedProcessors/mv-ddr-marvell/pull/45/ > but I am told that Armada team has left Marvell, so who knows if this > will ever be merged there > - patch 5 enables this reduction for Turris Omnia > - patches 6-8 import old DDR3 training code and make some changes so > that it works with U-Boot. The reason why this is being done is > explained in patch 6 > - patch 9 glues the old DDR3 training code to current U-Boot > - patch 10 allows for dynamic selection of old DDR3 training code on > Turris Omnia, via an U-Boot environment variable > > Marek > > Marek Behún (10): > ddr: marvell: a38x: debug: return from ddr3_tip_print_log() early if > we won't print anything > ddr: marvell: a38x: debug: Remove unused variables > ddr: marvell: a38x: debug: Define DDR_VIEWER_TOOL variables only if > needed, and make them static > ddr: marvell: a38x: debug: Allow compiling with immutable debug > settings to reduce binary size > arm: mvebu: turris_omnia: Enable immutable debug settings in DDR3 > training by default > ddr: marvell: a38x: Import old DDR training code from 2017 version of > U-Boot > ddr: marvell: a38x: old: Fix some compiler warning of the old code > ddr: marvell: a38x: old: Backport immutable debug settings > arm: mvebu: a38x: Add optional support for using old DDR3 training > code > arm: mvebu: turris_omnia: Support old DDR3 training, selectable via > env var > > arch/arm/mach-mvebu/Kconfig | 15 + > arch/arm/mach-mvebu/include/mach/cpu.h|1 + > arch/arm/mach-mvebu/spl.c | 37 +- > board/CZ.NIC/turris_omnia/Makefile|1 + > board/CZ.NIC/turris_omnia/old_ddr3_training.c | 79 + > board/CZ.NIC/turris_omnia/turris_omnia.c |2 +- > configs/turris_omnia_defconfig|1 + > drivers/ddr/marvell/a38x/Makefile |2 + > drivers/ddr/marvell/a38x/ddr3_debug.c | 30 +- > drivers/ddr/marvell/a38x/ddr3_init.c |3 +- > drivers/ddr/marvell/a38x/ddr3_init.h | 43 +- > drivers/ddr/marvell/a38x/old/Makefile | 29 + > drivers/ddr/marvell/a38x/old/ddr3_a38x.c | 738 + > drivers/ddr/marvell/a38x/old/ddr3_a38x.h | 93 + > .../marvell/a38x/old/ddr3_a38x_mc_static.h| 226 ++ > .../ddr/marvell/a38x/old/ddr3_a38x_topology.h | 22 + > .../ddr/marvell/a38x/old/ddr3_a38x_training.c | 40 + > drivers/ddr/marvell/a38x/old/ddr3_debug.c | 1545 ++ > .../marvell/a38x/old/ddr3_hws_hw_training.c | 148 + > .../marvell/a38x/old/ddr3_hws_hw_training.h | 49 + > .../a38x/old/ddr3_hws_hw_training_def.h | 464 +++ > .../marvell/a38x/old/ddr3_hws_sil_training.h | 17 + > drivers/ddr/marvell/a38x/old/ddr3_init.c | 770 + > drivers/ddr/marvell/a38x/old/ddr3_init.h | 405 +++ > .../ddr/marvell/a38x/old/ddr3_logging_def.h | 101 + > .../marvell/a38x/old/ddr3_patterns_64bit.h| 924 ++ > .../ddr/marvell/a38x/old/ddr3_topology_def.h | 76 + > drivers/ddr/marvell/a38x/old/ddr3_training.c | 2651 + > .../ddr/marvell/a38x/old/ddr3_training_bist.c | 289 ++ > .../a38x/old/ddr3_training_centralization.c | 712 + > .../ddr/marvell/a38x/old/ddr3_training_db.c | 652 > .../marvell/a38x/old/ddr3_training_hw_algo.c | 686 + > .../marvell/a38x/old/ddr3_training_hw_algo.h | 14 + > .../ddr/marvell/a38x/old/ddr3_training_ip.h | 178 ++ > .../marvell/a38x/old/ddr3_training_ip_bist.h | 54 + > .../old/ddr3_training_ip_centralization.h | 15 + > .../marvell/a38x/old/ddr3_training_ip_db.h| 34 + > .../marvell/a38x/old/ddr3_training_ip_def.h | 173 ++ > .../a38x/old/ddr3_training_ip_engine.c| 1355 + > .../a38x/old/ddr3_training_ip_engine.h| 85 + > .../marvell/a38x/old/ddr3_training_ip_flow.h | 349 +++ > .../marvell/a38x/old/ddr3_training_ip_pbs.h | 41 + > .../a38x/old/ddr3_training_ip_prv_if.h| 107 + > .../a38x/old/ddr3_training_ip_static.h| 31 + > .../marvell/a38x/old/ddr3_training_leveling.c | 1837 > .../marvell/a38x/old/ddr3_training_leveling.h | 17 + > .../ddr/marvell/a38x/old/ddr3_training_pbs.c | 995 +++ > .../marvell/a38x/old/ddr3_training_static.c | 538 >
[PATCH v3] arm: dts: kirkwood: Enable upstream DT on Kirkwood boards
Enable OF_UPSTREAM to use upstream DT and add marvell/ prefix to the
DEFAULT_DEVICE_TREE for Kirkwood boards. And so we can directly build
DTBs from dts/upstream/src/arm/marvell, and including *-u-boot.dtsi
files from arch/arm/dts/ directory.
Background:
The following 2 commands and filters were used in the analysis to determine
which upstream DTS and DTSI files can be used as they are, or need to have
modified/created *-u-boot.dtsi for u-boot specific implementation, and
which board should be opt-out from OF_UPSTREAM.
"git grep -li arch_kirkwood configs | xargs grep DEVICE_TREE | cut -d '"' -f2 |
xargs -n1 sh -c 'diff -qs arch/arm/dts/$1.dts
dts/upstream/src/arm/marvell/$1.dts' sh | grep differ"
"diff -qrbu arch/arm/dts/ dts/upstream/src/arm/marvell/ | grep kirkwood | grep
".dtsi ""
More detailed information can be found at:
https://lore.kernel.org/u-boot/20240328021825.17935-1-mibo...@gmail.com/T/#u
I've regression tested this patch with the Zyxel NSA325 (Kirkwood 88F6282)
and Zyxel NSA310S (Kirkwood 88F6281). The Zyxel NSA325 board has a
USB 3.0 controller attached to the PCIe bus. And the Zyxel NSA310S
has an extensive overhaul in bindings and styles in upstream DTS version.
Tested-by: Michael Walle # on lschv2
Acked-by: Sumit Garg
Reviewed-by: Stefan Roese
Signed-off-by: Tony Dinh
---
Changes in v3:
- Collect Reviewed/Tested/Acked-by tags.
- Trim the commit description and point to lore.kernel.org for detailed
information.
- No change from the V2 patch.
Changes in v2:
Remove unnecessary redefined OF_UPSTREAM and use "imply OF_UPSTREAM" for
KW88F6281 and KW88F6192 SoCs.
arch/arm/dts/kirkwood-dreamplug-u-boot.dtsi | 7 +++
arch/arm/dts/kirkwood-lschlv2-u-boot.dtsi | 6 --
arch/arm/dts/kirkwood-lsxhl-u-boot.dtsi | 6 --
arch/arm/dts/kirkwood-nsa325-u-boot.dtsi| 7 +++
arch/arm/mach-kirkwood/Kconfig | 2 ++
configs/SBx81LIFKW_defconfig| 1 +
configs/SBx81LIFXCAT_defconfig | 1 +
configs/d2net_v2_defconfig | 2 +-
configs/dns325_defconfig| 2 +-
configs/dockstar_defconfig | 2 +-
configs/dreamplug_defconfig | 2 +-
configs/ds109_defconfig | 2 +-
configs/goflexhome_defconfig| 2 +-
configs/guruplug_defconfig | 2 +-
configs/ib62x0_defconfig| 2 +-
configs/iconnect_defconfig | 2 +-
configs/inetspace_v2_defconfig | 2 +-
configs/lschlv2_defconfig | 2 +-
configs/lsxhl_defconfig | 2 +-
configs/nas220_defconfig| 2 +-
configs/net2big_v2_defconfig| 2 +-
configs/netspace_lite_v2_defconfig | 2 +-
configs/netspace_max_v2_defconfig | 2 +-
configs/netspace_mini_v2_defconfig | 2 +-
configs/netspace_v2_defconfig | 2 +-
configs/nsa310s_defconfig | 2 +-
configs/nsa325_defconfig| 2 +-
configs/openrd_base_defconfig | 2 +-
configs/openrd_client_defconfig | 2 +-
configs/openrd_ultimate_defconfig | 2 +-
configs/pogo_e02_defconfig | 2 +-
configs/pogo_v4_defconfig | 2 +-
configs/sheevaplug_defconfig| 2 +-
33 files changed, 52 insertions(+), 30 deletions(-)
create mode 100644 arch/arm/dts/kirkwood-dreamplug-u-boot.dtsi
create mode 100644 arch/arm/dts/kirkwood-nsa325-u-boot.dtsi
diff --git a/arch/arm/dts/kirkwood-dreamplug-u-boot.dtsi
b/arch/arm/dts/kirkwood-dreamplug-u-boot.dtsi
new file mode 100644
index 00..59f19a211f
--- /dev/null
+++ b/arch/arm/dts/kirkwood-dreamplug-u-boot.dtsi
@@ -0,0 +1,7 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+/ {
+ aliases {
+ spi0 =
+ };
+};
diff --git a/arch/arm/dts/kirkwood-lschlv2-u-boot.dtsi
b/arch/arm/dts/kirkwood-lschlv2-u-boot.dtsi
index 7fc2d7d3b4..cf33ff822e 100644
--- a/arch/arm/dts/kirkwood-lschlv2-u-boot.dtsi
+++ b/arch/arm/dts/kirkwood-lschlv2-u-boot.dtsi
@@ -1,7 +1,9 @@
// SPDX-License-Identifier: GPL-2.0+
- {
- status = "disabled";
+/ {
+ aliases {
+ spi0 =
+ };
};
_power {
diff --git a/arch/arm/dts/kirkwood-lsxhl-u-boot.dtsi
b/arch/arm/dts/kirkwood-lsxhl-u-boot.dtsi
index 7fc2d7d3b4..cf33ff822e 100644
--- a/arch/arm/dts/kirkwood-lsxhl-u-boot.dtsi
+++ b/arch/arm/dts/kirkwood-lsxhl-u-boot.dtsi
@@ -1,7 +1,9 @@
// SPDX-License-Identifier: GPL-2.0+
- {
- status = "disabled";
+/ {
+ aliases {
+ spi0 =
+ };
};
_power {
diff --git a/arch/arm/dts/kirkwood-nsa325-u-boot.dtsi
b/arch/arm/dts/kirkwood-nsa325-u-boot.dtsi
new file mode 100644
index 00..dec27b2a87
--- /dev/null
+++ b/arch/arm/dts/kirkwood-nsa325-u-boot.dtsi
@@ -0,0 +1,7 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+ {
Re: [PATCH v2] arm: dts: kirkwood: Enable upstream DT on Kirkwood boards
Hi Michael, Hi Stefan, It seems either the Denx server or Gmail has failed to send/deliver Stefan's response to my Inbox. Luckily, I also monitored lore.kernel.org and I saw the response. So I'd like to answer that below. On Thu, Mar 28, 2024 at 12:41 AM Michael Walle wrote: > > Hi, > > On Thu Mar 28, 2024 at 3:18 AM CET, Tony Dinh wrote: > > Enable OF_UPSTREAM to use upstream DT and add marvell/ prefix to the > > DEFAULT_DEVICE_TREE for Kirkwood boards. And so we can directly build > > DTBs from dts/upstream/src/arm/marvell, and including *-u-boot.dtsi > > files from arch/arm/dts/ directory. > > > > Background: > > > > Hi Stefan, > > Hi Michael, > > > > I did a survey and we currently have 28 Kirkwood boards. Using some > > commands and filters, here are the finding. > > > > git grep -li arch_kirkwood configs | xargs grep DEVICE_TREE | cut -d '"' > > -f2 | xargs -n1 sh -c 'diff -qs arch/arm/dts/$1.dts > > dts/upstream/src/arm/marvell/$1.dts' sh | grep differ > > > > diff: dts/upstream/src/arm/marvell/kirkwood-atl-sbx81lifkw.dts: No such > > file or directory > > diff: dts/upstream/src/arm/marvell/kirkwood-atl-sbx81lifxcat.dts: No such > > file or directory > > ... > > Are you sure you want to have all this text in the commit log? > Please see my response to you and Stefan below. > You seem to have forgotten my tag: > Tested-by: Michael Walle # on lschv2 My bad! Stefan's comment (about the large commit text): "This is also my concern. Even though I love descriptive commit messages, this seems to be a bit too much IMHO. Not sure if and how to get these findings of yours archived otherwise." I can send a V3 patch. I will cut out the Background stuff and point it to: https://lore.kernel.org/u-boot/55229181-3aff-4bff-afb5-df778f5f1...@denx.de/T/#t And also I will collect Michael's Test-by tag and your Review-by tag in the commit description. Does that sound OK? Stefan's comment: "Tony, many thanks to work on this consolidation. Very impressive results. I can't test anything of this though, but my plan would be to pull this in the upcoming merge window, if nobody complains." Reviewed-by: Stefan Roese " I think between Michael and I, we've tested 3 representative Kirkwood boards. Time permitted, I will update u-boot for a few of my other Kirkwood boards, and will send patches if I see any regression. All the best, Tony
[PATCH v2] arm: dts: kirkwood: Enable upstream DT on Kirkwood boards
differ
Files arch/arm/dts/kirkwood-6281.dtsi and
dts/upstream/src/arm/marvell/kirkwood-6281.dtsi differ
Files arch/arm/dts/kirkwood-98dx4122.dtsi and
dts/upstream/src/arm/marvell/kirkwood-98dx4122.dtsi differ
5. DTSI files that will need new or modified -u-boot.dtsi
Files arch/arm/dts/kirkwood-dreamplug.dts and
dts/upstream/src/arm/marvell/kirkwood-dreamplug.dts differ
Files arch/arm/dts/kirkwood-lsxl.dtsi and
dts/upstream/src/arm/marvell/kirkwood-lsxl.dtsi differ
Files arch/arm/dts/kirkwood-nsa3x0-common.dtsi and
dts/upstream/src/arm/marvell/kirkwood-nsa3x0-common.dtsi differ
So these u-boot.dtsi files need to be created/modified so we can use upstream
DTS/DTSI:
modified: arch/arm/dts/kirkwood-lschlv2-u-boot.dtsi
modified: arch/arm/dts/kirkwood-lsxhl-u-boot.dtsi
new file: arch/arm/dts/kirkwood-dreamplug-u-boot.dtsi
new file: arch/arm/dts/kirkwood-nsa325-u-boot.dtsi
I've regression tested this patch with the Zyxel NSA325 (Kirkwood 88F6282)
and Zyxel NSA310S (Kirkwood 88F6281). The Zyxel NSA325 board has a
USB 3.0 controller attached to the PCIe bus. And the Zyxel NSA310S
has an extensive overhaul in bindings and styles in upstream DTS version.
Signed-off-by: Tony Dinh
---
Changes in v2:
Remove unnecessary redefined OF_UPSTREAM and use "imply OF_UPSTREAM" for
KW88F6281 and KW88F6192 SoCs.
arch/arm/dts/kirkwood-dreamplug-u-boot.dtsi | 7 +++
arch/arm/dts/kirkwood-lschlv2-u-boot.dtsi | 6 --
arch/arm/dts/kirkwood-lsxhl-u-boot.dtsi | 6 --
arch/arm/dts/kirkwood-nsa325-u-boot.dtsi| 7 +++
arch/arm/mach-kirkwood/Kconfig | 2 ++
configs/SBx81LIFKW_defconfig| 1 +
configs/SBx81LIFXCAT_defconfig | 1 +
configs/d2net_v2_defconfig | 2 +-
configs/dns325_defconfig| 2 +-
configs/dockstar_defconfig | 2 +-
configs/dreamplug_defconfig | 2 +-
configs/ds109_defconfig | 2 +-
configs/goflexhome_defconfig| 2 +-
configs/guruplug_defconfig | 2 +-
configs/ib62x0_defconfig| 2 +-
configs/iconnect_defconfig | 2 +-
configs/inetspace_v2_defconfig | 2 +-
configs/lschlv2_defconfig | 2 +-
configs/lsxhl_defconfig | 2 +-
configs/nas220_defconfig| 2 +-
configs/net2big_v2_defconfig| 2 +-
configs/netspace_lite_v2_defconfig | 2 +-
configs/netspace_max_v2_defconfig | 2 +-
configs/netspace_mini_v2_defconfig | 2 +-
configs/netspace_v2_defconfig | 2 +-
configs/nsa310s_defconfig | 2 +-
configs/nsa325_defconfig| 2 +-
configs/openrd_base_defconfig | 2 +-
configs/openrd_client_defconfig | 2 +-
configs/openrd_ultimate_defconfig | 2 +-
configs/pogo_e02_defconfig | 2 +-
configs/pogo_v4_defconfig | 2 +-
configs/sheevaplug_defconfig| 2 +-
33 files changed, 52 insertions(+), 30 deletions(-)
create mode 100644 arch/arm/dts/kirkwood-dreamplug-u-boot.dtsi
create mode 100644 arch/arm/dts/kirkwood-nsa325-u-boot.dtsi
diff --git a/arch/arm/dts/kirkwood-dreamplug-u-boot.dtsi
b/arch/arm/dts/kirkwood-dreamplug-u-boot.dtsi
new file mode 100644
index 00..59f19a211f
--- /dev/null
+++ b/arch/arm/dts/kirkwood-dreamplug-u-boot.dtsi
@@ -0,0 +1,7 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+/ {
+ aliases {
+ spi0 =
+ };
+};
diff --git a/arch/arm/dts/kirkwood-lschlv2-u-boot.dtsi
b/arch/arm/dts/kirkwood-lschlv2-u-boot.dtsi
index 7fc2d7d3b4..cf33ff822e 100644
--- a/arch/arm/dts/kirkwood-lschlv2-u-boot.dtsi
+++ b/arch/arm/dts/kirkwood-lschlv2-u-boot.dtsi
@@ -1,7 +1,9 @@
// SPDX-License-Identifier: GPL-2.0+
- {
- status = "disabled";
+/ {
+ aliases {
+ spi0 =
+ };
};
_power {
diff --git a/arch/arm/dts/kirkwood-lsxhl-u-boot.dtsi
b/arch/arm/dts/kirkwood-lsxhl-u-boot.dtsi
index 7fc2d7d3b4..cf33ff822e 100644
--- a/arch/arm/dts/kirkwood-lsxhl-u-boot.dtsi
+++ b/arch/arm/dts/kirkwood-lsxhl-u-boot.dtsi
@@ -1,7 +1,9 @@
// SPDX-License-Identifier: GPL-2.0+
- {
- status = "disabled";
+/ {
+ aliases {
+ spi0 =
+ };
};
_power {
diff --git a/arch/arm/dts/kirkwood-nsa325-u-boot.dtsi
b/arch/arm/dts/kirkwood-nsa325-u-boot.dtsi
new file mode 100644
index 00..dec27b2a87
--- /dev/null
+++ b/arch/arm/dts/kirkwood-nsa325-u-boot.dtsi
@@ -0,0 +1,7 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+ {
+ partition@0 {
+ /delete-property/ read-only;
+ };
+};
diff --git a/arch/arm/mach-kirkwood/Kconfig b/arch/arm/mach-kirkwood/Kconfig
index c2fff84a68..031d4e5ecd 100644
--- a/arch/arm/mach-kirkwood/Kconfig
+++ b/arch/arm/mach-kirkwood/Kconfig
@@ -6,10 +6,12 @@ config FEROCEO
Re: [PATCH] arm: dts: kirkwood: Remove DTS files for Kirkwood boards
Hi Sumit, On Tue, Mar 26, 2024 at 9:30 PM Sumit Garg wrote: > > On Wed, 27 Mar 2024 at 02:43, Tony Dinh wrote: > > > > Remove DTS and DTSI files for Kirkwood boards that have upstream supports. > > nit: s/supports/support/ > > > > > This patch depends on > > "arm: dts: kirkwood: Enable upstream DT on Kirkwood boards" > > https://patchwork.ozlabs.org/project/uboot/patch/20240322021747.14873-1-mibo...@gmail.com/ > > > > Signed-off-by: Tony Dinh > > --- > > > > arch/arm/dts/Makefile | 28 +- > > arch/arm/dts/kirkwood-6192.dtsi | 88 -- > > arch/arm/dts/kirkwood-6281.dtsi | 90 -- > > arch/arm/dts/kirkwood-6282.dtsi | 161 > > arch/arm/dts/kirkwood-98dx4122.dtsi | 53 -- > > arch/arm/dts/kirkwood-blackarmor-nas220.dts | 172 > > arch/arm/dts/kirkwood-d2net.dts | 45 - > > arch/arm/dts/kirkwood-dns325.dts | 63 -- > > arch/arm/dts/kirkwood-dnskw.dtsi | 235 - > > arch/arm/dts/kirkwood-dockstar.dts| 110 --- > > arch/arm/dts/kirkwood-dreamplug.dts | 131 --- > > arch/arm/dts/kirkwood-ds109.dts | 40 - > > arch/arm/dts/kirkwood-goflexnet.dts | 190 > > .../arm/dts/kirkwood-guruplug-server-plus.dts | 133 --- > > arch/arm/dts/kirkwood-ib62x0.dts | 146 --- > > arch/arm/dts/kirkwood-iconnect.dts| 195 > > arch/arm/dts/kirkwood-is2.dts | 40 - > > arch/arm/dts/kirkwood-lschlv2.dts | 20 - > > arch/arm/dts/kirkwood-lsxhl.dts | 20 - > > arch/arm/dts/kirkwood-lsxl.dtsi | 241 - > > arch/arm/dts/kirkwood-net2big.dts | 63 -- > > arch/arm/dts/kirkwood-netxbig.dtsi| 232 - > > arch/arm/dts/kirkwood-ns2-common.dtsi | 97 -- > > arch/arm/dts/kirkwood-ns2.dts | 40 - > > arch/arm/dts/kirkwood-ns2lite.dts | 35 - > > arch/arm/dts/kirkwood-ns2max.dts | 59 -- > > arch/arm/dts/kirkwood-ns2mini.dts | 60 -- > > arch/arm/dts/kirkwood-nsa310s.dts | 319 --- > > arch/arm/dts/kirkwood-nsa325.dts | 231 - > > arch/arm/dts/kirkwood-nsa3x0-common.dtsi | 157 > > arch/arm/dts/kirkwood-openrd-base.dts | 39 - > > arch/arm/dts/kirkwood-openrd-client.dts | 73 -- > > arch/arm/dts/kirkwood-openrd-ultimate.dts | 55 -- > > arch/arm/dts/kirkwood-openrd.dtsi | 122 --- > > arch/arm/dts/kirkwood-pogo_e02.dts| 132 --- > > arch/arm/dts/kirkwood-pogoplug-series-4.dts | 180 > > arch/arm/dts/kirkwood-sheevaplug-common.dtsi | 104 --- > > arch/arm/dts/kirkwood-sheevaplug.dts | 42 - > > arch/arm/dts/kirkwood-synology.dtsi | 855 -- > > arch/arm/dts/kirkwood.dtsi| 393 > > 40 files changed, 1 insertion(+), 5488 deletions(-) > > Glad to see this diff stat. Really appreciate your hard work. All the best, Tony > > Reviewed-by: Sumit Garg > > -Sumit > > > delete mode 100644 arch/arm/dts/kirkwood-6192.dtsi > > delete mode 100644 arch/arm/dts/kirkwood-6281.dtsi > > delete mode 100644 arch/arm/dts/kirkwood-6282.dtsi > > delete mode 100644 arch/arm/dts/kirkwood-98dx4122.dtsi > > delete mode 100644 arch/arm/dts/kirkwood-blackarmor-nas220.dts > > delete mode 100644 arch/arm/dts/kirkwood-d2net.dts > > delete mode 100644 arch/arm/dts/kirkwood-dns325.dts > > delete mode 100644 arch/arm/dts/kirkwood-dnskw.dtsi > > delete mode 100644 arch/arm/dts/kirkwood-dockstar.dts > > delete mode 100644 arch/arm/dts/kirkwood-dreamplug.dts > > delete mode 100644 arch/arm/dts/kirkwood-ds109.dts > > delete mode 100644 arch/arm/dts/kirkwood-goflexnet.dts > > delete mode 100644 arch/arm/dts/kirkwood-guruplug-server-plus.dts > > delete mode 100644 arch/arm/dts/kirkwood-ib62x0.dts > > delete mode 100644 arch/arm/dts/kirkwood-iconnect.dts > > delete mode 100644 arch/arm/dts/kirkwood-is2.dts > > delete mode 100644 arch/arm/dts/kirkwood-lschlv2.dts > > delete mode 100644 arch/arm/dts/kirkwood-lsxhl.dts > > delete mode 100644 arch/arm/dts/kirkwood-lsxl.dtsi > > delete mode 100644 arch/arm/dts/kirkwood-net2big.dts > > delete mode 100644 arch/arm/dts/kirkwood-netxbig.dtsi > > delete mode 100644 arch/arm/dts/kirkwood-ns2-common.dtsi > > delete mode 100644 arch/arm/dts/kirkwood-ns2.dts > > delete mode 100644 arch/arm/dts/kirkwood-ns
Re: [PATCH] arm: dts: kirkwood: Enable upstream DT on Kirkwood boards
Hi Sumit, On Tue, Mar 26, 2024 at 9:21 PM Sumit Garg wrote: > > Hi Tony, > > On Fri, 22 Mar 2024 at 07:48, Tony Dinh wrote: > > > > Enable OF_UPSTREAM to use upstream DT and add marvell/ prefix to the > > DEFAULT_DEVICE_TREE for Kirkwood boards. And so we can directly build > > DTBs from dts/upstream/src/arm/marvell, and including *-u-boot.dtsi > > files from arch/arm/dts/ directory. > > > > Background: > > > > Hi Stefan, > > Hi Michael, > > > > I did a survey and we currently have 28 Kirkwood boards. Using some > > commands and filters, here are the finding. > > > > git grep -li arch_kirkwood configs | xargs grep DEVICE_TREE | cut -d '"' > > -f2 | xargs -n1 sh -c 'diff -qs arch/arm/dts/$1.dts > > dts/upstream/src/arm/marvell/$1.dts' sh | grep differ > > > > diff: dts/upstream/src/arm/marvell/kirkwood-atl-sbx81lifkw.dts: No such > > file or directory > > diff: dts/upstream/src/arm/marvell/kirkwood-atl-sbx81lifxcat.dts: No such > > file or directory > > > > Files arch/arm/dts/kirkwood-dockstar.dts and > > dts/upstream/src/arm/marvell/kirkwood-dockstar.dts differ > > Files arch/arm/dts/kirkwood-dreamplug.dts and > > dts/upstream/src/arm/marvell/kirkwood-dreamplug.dts differ > > Files arch/arm/dts/kirkwood-goflexnet.dts and > > dts/upstream/src/arm/marvell/kirkwood-goflexnet.dts differ > > Files arch/arm/dts/kirkwood-guruplug-server-plus.dts and > > dts/upstream/src/arm/marvell/kirkwood-guruplug-server-plus.dts differ > > Files arch/arm/dts/kirkwood-iconnect.dts and > > dts/upstream/src/arm/marvell/kirkwood-iconnect.dts differ > > Files arch/arm/dts/kirkwood-net2big.dts and > > dts/upstream/src/arm/marvell/kirkwood-net2big.dts differ > > Files arch/arm/dts/kirkwood-ns2max.dts and > > dts/upstream/src/arm/marvell/kirkwood-ns2max.dts differ > > Files arch/arm/dts/kirkwood-ns2mini.dts and > > dts/upstream/src/arm/marvell/kirkwood-ns2mini.dts differ > > Files arch/arm/dts/kirkwood-nsa310s.dts and > > dts/upstream/src/arm/marvell/kirkwood-nsa310s.dts differ > > Files arch/arm/dts/kirkwood-nsa325.dts and > > dts/upstream/src/arm/marvell/kirkwood-nsa325.dts differ > > Files arch/arm/dts/kirkwood-openrd-client.dts and > > dts/upstream/src/arm/marvell/kirkwood-openrd-client.dts differ > > > > diff -qrbu arch/arm/dts/ dts/upstream/src/arm/marvell/ | grep kirkwood | > > grep ".dtsi " > > > > Files arch/arm/dts/kirkwood-6192.dtsi and > > dts/upstream/src/arm/marvell/kirkwood-6192.dtsi differ > > Files arch/arm/dts/kirkwood-6281.dtsi and > > dts/upstream/src/arm/marvell/kirkwood-6281.dtsi differ > > Files arch/arm/dts/kirkwood-98dx4122.dtsi and > > dts/upstream/src/arm/marvell/kirkwood-98dx4122.dtsi differ > > Files arch/arm/dts/kirkwood-dnskw.dtsi and > > dts/upstream/src/arm/marvell/kirkwood-dnskw.dtsi differ > > Files arch/arm/dts/kirkwood.dtsi and > > dts/upstream/src/arm/marvell/kirkwood.dtsi differ > > Files arch/arm/dts/kirkwood-lsxl.dtsi and > > dts/upstream/src/arm/marvell/kirkwood-lsxl.dtsi differ > > Files arch/arm/dts/kirkwood-nsa3x0-common.dtsi and > > dts/upstream/src/arm/marvell/kirkwood-nsa3x0-common.dtsi differ > > Files arch/arm/dts/kirkwood-synology.dtsi and > > dts/upstream/src/arm/marvell/kirkwood-synology.dtsi differ > > > > And after reviewing these differences, the following are my observation. > > > > OF_LIST is not used in these Kirkwood boards. > > > > 1. Boards that have only u-boot DTS that should be opt-out for now with > > "#CONFIG_OF_UPSTREAM is not set" > > > > diff: dts/upstream/src/arm/marvell/kirkwood-atl-sbx81lifkw.dts: No such > > file or directory > > diff: dts/upstream/src/arm/marvell/kirkwood-atl-sbx81lifxcat.dts: No such > > file or directory > > > > 2. DTS and DTSI files that have only cosmetic, style, or binding changes > > (safe to take) > > > > Files arch/arm/dts/kirkwood-dockstar.dts and > > dts/upstream/src/arm/marvell/kirkwood-dockstar.dts differ > > Files arch/arm/dts/kirkwood-goflexnet.dts and > > dts/upstream/src/arm/marvell/kirkwood-goflexnet.dts differ > > Files arch/arm/dts/kirkwood-guruplug-server-plus.dts and > > dts/upstream/src/arm/marvell/kirkwood-guruplug-server-plus.dts differ > > Files arch/arm/dts/kirkwood-iconnect.dts and > > dts/upstream/src/arm/marvell/kirkwood-iconnect.dts differ > > Files arch/arm/dts/kirkwood-net2big.dts and > > dts/upstream/src/arm/marvell/kirkwood-net2big.dts differ > > Files arch/arm/dts/kirkwood-ns2max.dts an
[PATCH] arm: dts: kirkwood: Remove DTS files for Kirkwood boards
Remove DTS and DTSI files for Kirkwood boards that have upstream supports. This patch depends on "arm: dts: kirkwood: Enable upstream DT on Kirkwood boards" https://patchwork.ozlabs.org/project/uboot/patch/20240322021747.14873-1-mibo...@gmail.com/ Signed-off-by: Tony Dinh --- arch/arm/dts/Makefile | 28 +- arch/arm/dts/kirkwood-6192.dtsi | 88 -- arch/arm/dts/kirkwood-6281.dtsi | 90 -- arch/arm/dts/kirkwood-6282.dtsi | 161 arch/arm/dts/kirkwood-98dx4122.dtsi | 53 -- arch/arm/dts/kirkwood-blackarmor-nas220.dts | 172 arch/arm/dts/kirkwood-d2net.dts | 45 - arch/arm/dts/kirkwood-dns325.dts | 63 -- arch/arm/dts/kirkwood-dnskw.dtsi | 235 - arch/arm/dts/kirkwood-dockstar.dts| 110 --- arch/arm/dts/kirkwood-dreamplug.dts | 131 --- arch/arm/dts/kirkwood-ds109.dts | 40 - arch/arm/dts/kirkwood-goflexnet.dts | 190 .../arm/dts/kirkwood-guruplug-server-plus.dts | 133 --- arch/arm/dts/kirkwood-ib62x0.dts | 146 --- arch/arm/dts/kirkwood-iconnect.dts| 195 arch/arm/dts/kirkwood-is2.dts | 40 - arch/arm/dts/kirkwood-lschlv2.dts | 20 - arch/arm/dts/kirkwood-lsxhl.dts | 20 - arch/arm/dts/kirkwood-lsxl.dtsi | 241 - arch/arm/dts/kirkwood-net2big.dts | 63 -- arch/arm/dts/kirkwood-netxbig.dtsi| 232 - arch/arm/dts/kirkwood-ns2-common.dtsi | 97 -- arch/arm/dts/kirkwood-ns2.dts | 40 - arch/arm/dts/kirkwood-ns2lite.dts | 35 - arch/arm/dts/kirkwood-ns2max.dts | 59 -- arch/arm/dts/kirkwood-ns2mini.dts | 60 -- arch/arm/dts/kirkwood-nsa310s.dts | 319 --- arch/arm/dts/kirkwood-nsa325.dts | 231 - arch/arm/dts/kirkwood-nsa3x0-common.dtsi | 157 arch/arm/dts/kirkwood-openrd-base.dts | 39 - arch/arm/dts/kirkwood-openrd-client.dts | 73 -- arch/arm/dts/kirkwood-openrd-ultimate.dts | 55 -- arch/arm/dts/kirkwood-openrd.dtsi | 122 --- arch/arm/dts/kirkwood-pogo_e02.dts| 132 --- arch/arm/dts/kirkwood-pogoplug-series-4.dts | 180 arch/arm/dts/kirkwood-sheevaplug-common.dtsi | 104 --- arch/arm/dts/kirkwood-sheevaplug.dts | 42 - arch/arm/dts/kirkwood-synology.dtsi | 855 -- arch/arm/dts/kirkwood.dtsi| 393 40 files changed, 1 insertion(+), 5488 deletions(-) delete mode 100644 arch/arm/dts/kirkwood-6192.dtsi delete mode 100644 arch/arm/dts/kirkwood-6281.dtsi delete mode 100644 arch/arm/dts/kirkwood-6282.dtsi delete mode 100644 arch/arm/dts/kirkwood-98dx4122.dtsi delete mode 100644 arch/arm/dts/kirkwood-blackarmor-nas220.dts delete mode 100644 arch/arm/dts/kirkwood-d2net.dts delete mode 100644 arch/arm/dts/kirkwood-dns325.dts delete mode 100644 arch/arm/dts/kirkwood-dnskw.dtsi delete mode 100644 arch/arm/dts/kirkwood-dockstar.dts delete mode 100644 arch/arm/dts/kirkwood-dreamplug.dts delete mode 100644 arch/arm/dts/kirkwood-ds109.dts delete mode 100644 arch/arm/dts/kirkwood-goflexnet.dts delete mode 100644 arch/arm/dts/kirkwood-guruplug-server-plus.dts delete mode 100644 arch/arm/dts/kirkwood-ib62x0.dts delete mode 100644 arch/arm/dts/kirkwood-iconnect.dts delete mode 100644 arch/arm/dts/kirkwood-is2.dts delete mode 100644 arch/arm/dts/kirkwood-lschlv2.dts delete mode 100644 arch/arm/dts/kirkwood-lsxhl.dts delete mode 100644 arch/arm/dts/kirkwood-lsxl.dtsi delete mode 100644 arch/arm/dts/kirkwood-net2big.dts delete mode 100644 arch/arm/dts/kirkwood-netxbig.dtsi delete mode 100644 arch/arm/dts/kirkwood-ns2-common.dtsi delete mode 100644 arch/arm/dts/kirkwood-ns2.dts delete mode 100644 arch/arm/dts/kirkwood-ns2lite.dts delete mode 100644 arch/arm/dts/kirkwood-ns2max.dts delete mode 100644 arch/arm/dts/kirkwood-ns2mini.dts delete mode 100644 arch/arm/dts/kirkwood-nsa310s.dts delete mode 100644 arch/arm/dts/kirkwood-nsa325.dts delete mode 100644 arch/arm/dts/kirkwood-nsa3x0-common.dtsi delete mode 100644 arch/arm/dts/kirkwood-openrd-base.dts delete mode 100644 arch/arm/dts/kirkwood-openrd-client.dts delete mode 100644 arch/arm/dts/kirkwood-openrd-ultimate.dts delete mode 100644 arch/arm/dts/kirkwood-openrd.dtsi delete mode 100644 arch/arm/dts/kirkwood-pogo_e02.dts delete mode 100644 arch/arm/dts/kirkwood-pogoplug-series-4.dts delete mode 100644 arch/arm/dts/kirkwood-sheevaplug-common.dtsi delete mode 100644 arch/arm/dts/kirkwood-sheevaplug.dts delete mode 100644 arch/arm/dts/kirkwood-synology.dtsi delete mode 100644 arch/arm/dts/kirkwood.dtsi diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile index d85a33055c..896476a823 100644 --- a/arch/arm/dts/Makefile +++ b/arch/arm/dts/Makefile @@ -47,33 +47,7 @@ dtb-$(CONFIG_ARCH_DAVINCI) +
Re: [PATCH] arm: dts: kirkwood: Enable upstream DT on Kirkwood boards
Hi Michael, On Fri, Mar 22, 2024 at 2:10 PM Michael Walle wrote: > > Hi Tony, > > On Fri Mar 22, 2024 at 3:17 AM CET, Tony Dinh wrote: > > Enable OF_UPSTREAM to use upstream DT and add marvell/ prefix to the > > DEFAULT_DEVICE_TREE for Kirkwood boards. And so we can directly build > > DTBs from dts/upstream/src/arm/marvell, and including *-u-boot.dtsi > > files from arch/arm/dts/ directory. > > Thanks for taking care. > > > Signed-off-by: Tony Dinh > > Tested-by: Michael Walle # on lschlv2 > > lsxl should work too as it is just different in memory and cpu > frequency settings. > > > --- > > > > arch/arm/dts/kirkwood-lschlv2-u-boot.dtsi | 6 -- > > arch/arm/dts/kirkwood-lsxhl-u-boot.dtsi | 6 -- > > arch/arm/dts/kirkwood-lschlv2.dts > arch/arm/dts/kirkwood-lsxhl.dts > > Should be then be removed. Thanks for the lschlv2 review/test! I plan to send a follow-up patch to remove the corresponding DTS and DTSI files. All the best, Tony > > -michael
[PATCH] arm: dts: kirkwood: Enable upstream DT on Kirkwood boards
differ
Files arch/arm/dts/kirkwood-6281.dtsi and
dts/upstream/src/arm/marvell/kirkwood-6281.dtsi differ
Files arch/arm/dts/kirkwood-98dx4122.dtsi and
dts/upstream/src/arm/marvell/kirkwood-98dx4122.dtsi differ
5. DTSI files that will need new or modified -u-boot.dtsi
Files arch/arm/dts/kirkwood-dreamplug.dts and
dts/upstream/src/arm/marvell/kirkwood-dreamplug.dts differ
Files arch/arm/dts/kirkwood-lsxl.dtsi and
dts/upstream/src/arm/marvell/kirkwood-lsxl.dtsi differ
Files arch/arm/dts/kirkwood-nsa3x0-common.dtsi and
dts/upstream/src/arm/marvell/kirkwood-nsa3x0-common.dtsi differ
So these u-boot.dtsi files need to be created/modified so we can use upstream
DTS/DTSI:
modified: arch/arm/dts/kirkwood-lschlv2-u-boot.dtsi
modified: arch/arm/dts/kirkwood-lsxhl-u-boot.dtsi
new file: arch/arm/dts/kirkwood-dreamplug-u-boot.dtsi
new file: arch/arm/dts/kirkwood-nsa325-u-boot.dtsi
I've regression tested this patch with the Zyxel NSA325 (Kirkwood 88F6282)
and Zyxel NSA310S (Kirkwood 88F6281). The Zyxel NSA325 board has a
USB 3.0 controller attached to the PCIe bus. And the Zyxel NSA310S
has an extensive overhaul in bindings and styles in upstream DTS version.
Signed-off-by: Tony Dinh
---
arch/arm/dts/kirkwood-dreamplug-u-boot.dtsi | 7 +++
arch/arm/dts/kirkwood-lschlv2-u-boot.dtsi | 6 --
arch/arm/dts/kirkwood-lsxhl-u-boot.dtsi | 6 --
arch/arm/dts/kirkwood-nsa325-u-boot.dtsi| 7 +++
arch/arm/mach-kirkwood/Kconfig | 4
configs/SBx81LIFKW_defconfig| 1 +
configs/SBx81LIFXCAT_defconfig | 1 +
configs/d2net_v2_defconfig | 2 +-
configs/dns325_defconfig| 2 +-
configs/dockstar_defconfig | 2 +-
configs/dreamplug_defconfig | 2 +-
configs/ds109_defconfig | 2 +-
configs/goflexhome_defconfig| 2 +-
configs/guruplug_defconfig | 2 +-
configs/ib62x0_defconfig| 2 +-
configs/iconnect_defconfig | 2 +-
configs/inetspace_v2_defconfig | 2 +-
configs/lschlv2_defconfig | 2 +-
configs/lsxhl_defconfig | 2 +-
configs/nas220_defconfig| 2 +-
configs/net2big_v2_defconfig| 2 +-
configs/netspace_lite_v2_defconfig | 2 +-
configs/netspace_max_v2_defconfig | 2 +-
configs/netspace_mini_v2_defconfig | 2 +-
configs/netspace_v2_defconfig | 2 +-
configs/nsa310s_defconfig | 2 +-
configs/nsa325_defconfig| 2 +-
configs/openrd_base_defconfig | 2 +-
configs/openrd_client_defconfig | 2 +-
configs/openrd_ultimate_defconfig | 2 +-
configs/pogo_e02_defconfig | 2 +-
configs/pogo_v4_defconfig | 2 +-
configs/sheevaplug_defconfig| 2 +-
33 files changed, 54 insertions(+), 30 deletions(-)
create mode 100644 arch/arm/dts/kirkwood-dreamplug-u-boot.dtsi
create mode 100644 arch/arm/dts/kirkwood-nsa325-u-boot.dtsi
diff --git a/arch/arm/dts/kirkwood-dreamplug-u-boot.dtsi
b/arch/arm/dts/kirkwood-dreamplug-u-boot.dtsi
new file mode 100644
index 00..59f19a211f
--- /dev/null
+++ b/arch/arm/dts/kirkwood-dreamplug-u-boot.dtsi
@@ -0,0 +1,7 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+/ {
+ aliases {
+ spi0 =
+ };
+};
diff --git a/arch/arm/dts/kirkwood-lschlv2-u-boot.dtsi
b/arch/arm/dts/kirkwood-lschlv2-u-boot.dtsi
index 7fc2d7d3b4..cf33ff822e 100644
--- a/arch/arm/dts/kirkwood-lschlv2-u-boot.dtsi
+++ b/arch/arm/dts/kirkwood-lschlv2-u-boot.dtsi
@@ -1,7 +1,9 @@
// SPDX-License-Identifier: GPL-2.0+
- {
- status = "disabled";
+/ {
+ aliases {
+ spi0 =
+ };
};
_power {
diff --git a/arch/arm/dts/kirkwood-lsxhl-u-boot.dtsi
b/arch/arm/dts/kirkwood-lsxhl-u-boot.dtsi
index 7fc2d7d3b4..cf33ff822e 100644
--- a/arch/arm/dts/kirkwood-lsxhl-u-boot.dtsi
+++ b/arch/arm/dts/kirkwood-lsxhl-u-boot.dtsi
@@ -1,7 +1,9 @@
// SPDX-License-Identifier: GPL-2.0+
- {
- status = "disabled";
+/ {
+ aliases {
+ spi0 =
+ };
};
_power {
diff --git a/arch/arm/dts/kirkwood-nsa325-u-boot.dtsi
b/arch/arm/dts/kirkwood-nsa325-u-boot.dtsi
new file mode 100644
index 00..dec27b2a87
--- /dev/null
+++ b/arch/arm/dts/kirkwood-nsa325-u-boot.dtsi
@@ -0,0 +1,7 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+ {
+ partition@0 {
+ /delete-property/ read-only;
+ };
+};
diff --git a/arch/arm/mach-kirkwood/Kconfig b/arch/arm/mach-kirkwood/Kconfig
index c2fff84a68..39593c83d0 100644
--- a/arch/arm/mach-kirkwood/Kconfig
+++ b/arch/arm/mach-kirkwood/Kconfig
@@ -28,6 +28,10 @@ config CUSTOM_SYS_INIT_SP_ADDR
depends on HAS_CUSTOM_SYS_INIT_SP_ADDR
default 0x5ff000
+config OF_UPSTREAM
+ bool "Use u
Re: [PATCH] Makefile: Add missing OF_UPSTREAM Makefile for 32bit ARM
Thanks, Sumit! On Tue, Mar 19, 2024 at 6:02 AM Adam Ford wrote: > > On Mon, Mar 18, 2024 at 10:03 AM Marek Vasut > wrote: > > > > Copy dts/upstream/src/arm64/Makefile into dts/upstream/src/arm/Makefile > > and create a commit. This makes 32bit ARM buildable with OF_UPSTREAM . > > > > Signed-off-by: Marek Vasut > > Tested-by: Adam Ford #am3517-evm Tested-by: Tony Dinh All the best, Tony > > > --- > > Cc: Adam Ford > > Cc: Biju Das > > Cc: Lad Prabhakar > > Cc: Paul Barker > > Cc: Ralph Siemsen > > Cc: Tom Rini > > --- > > dts/upstream/src/arm/Makefile | 14 ++ > > 1 file changed, 14 insertions(+) > > create mode 100644 dts/upstream/src/arm/Makefile > > > > diff --git a/dts/upstream/src/arm/Makefile b/dts/upstream/src/arm/Makefile > > new file mode 100644 > > index 000..9a8f6aa3584 > > --- /dev/null > > +++ b/dts/upstream/src/arm/Makefile > > @@ -0,0 +1,14 @@ > > +# SPDX-License-Identifier: GPL-2.0+ > > + > > +include $(srctree)/scripts/Makefile.dts > > + > > +targets += $(dtb-y) > > + > > +# Add any required device tree compiler flags here > > +DTC_FLAGS += -a 0x8 > > + > > +PHONY += dtbs > > +dtbs: $(addprefix $(obj)/, $(dtb-y)) > > + @: > > + > > +clean-files := */*.dtb */*.dtbo > > -- > > 2.43.0 > >
Re: [PATCH v6 00/11] An effort to bring DT bindings compliance within U-Boot
Hi Sumit, On Sun, Mar 10, 2024 at 11:24 PM Sumit Garg wrote: > > Hi Tony, > > On Mon, 11 Mar 2024 at 09:20, Tony Dinh wrote: > > > > Hi Sumit, > > Hi Tom, > > > > On Mon, Mar 4, 2024 at 4:29 AM Fabio Estevam wrote: > > > > > > On Mon, Mar 4, 2024 at 9:15 AM Sumit Garg wrote: > > > > > > > I suppose the earlier reference patch wasn't complete, can you rather > > > > try its v4 [1] instead? > > > > > > > > [1] > > > > https://patchwork.ozlabs.org/project/uboot/patch/20240304121257.3551104-1-sumit.g...@linaro.org/ > > > > > > This one works, thanks! > > > > I'm testing this for a Marvell Armada 385 board (Synology DS116). I'm > > on the next branch, but perhaps something is still missing. > > > > diff --git a/configs/ds116_defconfig b/configs/ds116_defconfig > > index 02ddc0e7918..1fbedcf91cf 100644 > > --- a/configs/ds116_defconfig > > +++ b/configs/ds116_defconfig > > @@ -16,7 +16,7 @@ CONFIG_SF_DEFAULT_SPEED=5000 > > CONFIG_ENV_SIZE=0x1 > > CONFIG_ENV_OFFSET=0x7E > > CONFIG_ENV_SECT_SIZE=0x1 > > -CONFIG_DEFAULT_DEVICE_TREE="armada-385-synology-ds116" > > +CONFIG_DEFAULT_DEVICE_TREE="marvell/armada-385-synology-ds116" > > CONFIG_SPL_TEXT_BASE=0x4030 > > CONFIG_SPL_SERIAL=y > > CONFIG_SPL_STACK=0x4002c000 > > @@ -29,7 +29,6 @@ CONFIG_PCI=y > > CONFIG_DEBUG_UART=y > > CONFIG_AHCI=y > > CONFIG_BOOTSTD_FULL=y > > -CONFIG_BOOTSTD_DEFAULTS=y > > CONFIG_BOOTDELAY=10 > > CONFIG_USE_PREBOOT=y > > CONFIG_SYS_CONSOLE_INFO_QUIET=y > > @@ -57,6 +56,7 @@ CONFIG_CMD_CACHE=y > > CONFIG_CMD_TIME=y > > CONFIG_CMD_MTDPARTS=y > > > > CONFIG_MTDPARTS_DEFAULT="mtdparts=spi0.0:1m(u-boot),7040k(kernel),64k(u-boot-env),-(data)" > > +CONFIG_OF_UPSTREAM=y > > CONFIG_ENV_OVERWRITE=y > > CONFIG_SYS_RELOC_GD_ENV_ADDR=y > > CONFIG_VERSION_VARIABLE=y > > > > # make ds116_defconfig > > > > # grep -i ds116 .config > > CONFIG_SYS_BOARD="ds116" > > CONFIG_SYS_CONFIG_NAME="ds116" > > CONFIG_TARGET_DS116=y > > CONFIG_DEFAULT_DEVICE_TREE="marvell/armada-385-synology-ds116" > > CONFIG_IDENT_STRING="\nSynology DS116" > > CONFIG_SYS_PROMPT="DS116> " > > CONFIG_OF_LIST="marvell/armada-385-synology-ds116" > > CONFIG_SPL_OF_LIST="marvell/armada-385-synology-ds116" > > > > Built it, and looks like vendor Marvell is missing during the Make > > file execution. > > > > make -f ./scripts/Makefile.build obj=dts dtbs > > make -f ./scripts/Makefile.build obj=dts/upstream/src/arm dtbs > > scripts/Makefile.build:57: dts/upstream/src/arm/Makefile: No such file > > or directory > > As you are building for the 32-bit Arm, you have to add a Makefile > here [1] similar to this one [2] for arm64. > > [1] > https://source.denx.de/u-boot/u-boot/-/tree/next/dts/upstream/src/arm?ref_type=heads > [2] > https://source.denx.de/u-boot/u-boot/-/blob/next/dts/upstream/src/arm64/Makefile?ref_type=heads Thanks! It works great with that Make file. All the best, Tony > > -Sumit > > > make[2]: *** No rule to make target 'dts/upstream/src/arm/Makefile'. Stop. > > make[1]: *** [dts/Makefile:54: arch-dtbs] Error 2 > > make: *** [Makefile:1166: dts/dt.dtb] Error 2 > > make: *** Waiting for unfinished jobs > > make: Leaving directory '/usr/src/u-boot' > > > > I also tried Bryan's patch like you've suggested to Fabio. But it > > seems Bryan's patch was already in the next branch. Did I miss > > something? > > > > All the best , > > Tony
Re: [PATCH v6 00/11] An effort to bring DT bindings compliance within U-Boot
Hi Sumit, Hi Tom, On Mon, Mar 4, 2024 at 4:29 AM Fabio Estevam wrote: > > On Mon, Mar 4, 2024 at 9:15 AM Sumit Garg wrote: > > > I suppose the earlier reference patch wasn't complete, can you rather > > try its v4 [1] instead? > > > > [1] > > https://patchwork.ozlabs.org/project/uboot/patch/20240304121257.3551104-1-sumit.g...@linaro.org/ > > This one works, thanks! I'm testing this for a Marvell Armada 385 board (Synology DS116). I'm on the next branch, but perhaps something is still missing. diff --git a/configs/ds116_defconfig b/configs/ds116_defconfig index 02ddc0e7918..1fbedcf91cf 100644 --- a/configs/ds116_defconfig +++ b/configs/ds116_defconfig @@ -16,7 +16,7 @@ CONFIG_SF_DEFAULT_SPEED=5000 CONFIG_ENV_SIZE=0x1 CONFIG_ENV_OFFSET=0x7E CONFIG_ENV_SECT_SIZE=0x1 -CONFIG_DEFAULT_DEVICE_TREE="armada-385-synology-ds116" +CONFIG_DEFAULT_DEVICE_TREE="marvell/armada-385-synology-ds116" CONFIG_SPL_TEXT_BASE=0x4030 CONFIG_SPL_SERIAL=y CONFIG_SPL_STACK=0x4002c000 @@ -29,7 +29,6 @@ CONFIG_PCI=y CONFIG_DEBUG_UART=y CONFIG_AHCI=y CONFIG_BOOTSTD_FULL=y -CONFIG_BOOTSTD_DEFAULTS=y CONFIG_BOOTDELAY=10 CONFIG_USE_PREBOOT=y CONFIG_SYS_CONSOLE_INFO_QUIET=y @@ -57,6 +56,7 @@ CONFIG_CMD_CACHE=y CONFIG_CMD_TIME=y CONFIG_CMD_MTDPARTS=y CONFIG_MTDPARTS_DEFAULT="mtdparts=spi0.0:1m(u-boot),7040k(kernel),64k(u-boot-env),-(data)" +CONFIG_OF_UPSTREAM=y CONFIG_ENV_OVERWRITE=y CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_VERSION_VARIABLE=y # make ds116_defconfig # grep -i ds116 .config CONFIG_SYS_BOARD="ds116" CONFIG_SYS_CONFIG_NAME="ds116" CONFIG_TARGET_DS116=y CONFIG_DEFAULT_DEVICE_TREE="marvell/armada-385-synology-ds116" CONFIG_IDENT_STRING="\nSynology DS116" CONFIG_SYS_PROMPT="DS116> " CONFIG_OF_LIST="marvell/armada-385-synology-ds116" CONFIG_SPL_OF_LIST="marvell/armada-385-synology-ds116" Built it, and looks like vendor Marvell is missing during the Make file execution. make -f ./scripts/Makefile.build obj=dts dtbs make -f ./scripts/Makefile.build obj=dts/upstream/src/arm dtbs scripts/Makefile.build:57: dts/upstream/src/arm/Makefile: No such file or directory make[2]: *** No rule to make target 'dts/upstream/src/arm/Makefile'. Stop. make[1]: *** [dts/Makefile:54: arch-dtbs] Error 2 make: *** [Makefile:1166: dts/dt.dtb] Error 2 make: *** Waiting for unfinished jobs make: Leaving directory '/usr/src/u-boot' I also tried Bryan's patch like you've suggested to Fabio. But it seems Bryan's patch was already in the next branch. Did I miss something? All the best , Tony
Re: [PATCH RFC 26/26] dts: support building all dtb files for a specific vendor
Hi Caleb, On Mon, Mar 4, 2024 at 9:24 AM Caleb Connolly wrote: > > This adjusts OF_UPSTREAM to behave more like the kernel by allowing for > all the devicetree files for a given vendor to be compiled. This is > useful for Qualcomm in particular as most boards are supported by a > single U-Boot build just provided with a different DT. > > Signed-off-by: Caleb Connolly > --- > dts/Kconfig | 24 > scripts/Makefile.dts | 17 - > 2 files changed, 40 insertions(+), 1 deletion(-) > > diff --git a/dts/Kconfig b/dts/Kconfig > index b9b6367154ef..67d9dc489856 100644 > --- a/dts/Kconfig > +++ b/dts/Kconfig > @@ -100,8 +100,32 @@ config OF_UPSTREAM > However, newer boards whose devicetree source files haven't landed > in > the dts/upstream subtree, they can override this option to have the > DT build from existing U-Boot tree location instead. > > +config OF_UPSTREAM_BUILD_VENDOR > + bool "Build all devicetree files for a particular vendor" > + depends on OF_UPSTREAM > + help > + Enable building all devicetree files for a particular vendor. This > + is useful for generic U-Boot configurations where many boards can > + be supported with a single binary. > + > + This is only available for platforms using upstream devicetree. > + > +config OF_UPSTREAM_VENDOR > + string "Vendor to build all upstream devicetree files for" > + depends on OF_UPSTREAM_BUILD_VENDOR > + default "qcom" if ARCH_SNAPDRAGON > + default "rockchip" if ARCH_ROCKCHIP > + default "amlogic" if ARCH_MESON > + default "allwinner" if ARCH_SUNXI > + default "mediatek" if ARCH_MEDIATEK > + default "marvell" if ARCH_MVEBU Perhaps here it should be: default "marvell" if ARCH_MVEBU || ARCH_KIRKWOOD All the best, Tony > + default "xilinx" if ARCH_VERSAL || ARCH_ZYNQ > + default "nvidia" if ARCH_TEGRA > + help > + Select the vendor to build all devicetree files for. > + > choice > prompt "Provider of DTB for DT control" > depends on OF_CONTROL > > diff --git a/scripts/Makefile.dts b/scripts/Makefile.dts > index 5e2429c6170c..8005527f3df7 100644 > --- a/scripts/Makefile.dts > +++ b/scripts/Makefile.dts > @@ -1,3 +1,18 @@ > # SPDX-License-Identifier: GPL-2.0+ > > -dtb-y += $(patsubst %,%.dtb,$(subst ",,$(CONFIG_DEFAULT_DEVICE_TREE) > $(CONFIG_OF_LIST) $(CONFIG_SPL_OF_LIST))) > +dtb-y += $(patsubst %,%.dtb,\ > + $(subst ",,$(CONFIG_DEFAULT_DEVICE_TREE) $(CONFIG_OF_LIST) > $(CONFIG_SPL_OF_LIST))) > + > +ifeq ($(CONFIG_OF_UPSTREAM_BUILD_VENDOR),y) > +ifeq ($(CONFIG_ARM64),y) > +dt_dir := $(srctree)/dts/upstream/src/arm64 > +else > +dt_dir := $(srctree)/dts/upstream/src/$(ARCH) > +endif > + > +dtb-vendor_dts := $(patsubst %.dts,%.dtb, \ > + $(wildcard $(dt_dir)/$(subst ",,$(CONFIG_OF_UPSTREAM_VENDOR))/*.dts)) > + > +dtb-y += $(subst $(dt_dir)/,,$(dtb-vendor_dts)) > + > +endif > > -- > 2.44.0 >
Re: I'm looking for the source code of a specific u-boot version.
On Thu, Dec 28, 2023 at 11:48 AM Simon Glass wrote: > > Hi Mario, > > On Thu, Dec 28, 2023 at 3:48 PM Mario Marietto wrote: > > > > I tried to compile it,but If failed : > > > > /mnt/zroot2/zroot2/OS/Chromebook/freebsd-xen/domU-freebsd/bootloaders/u-boot-2017.05# > > ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- make snow_defconfig > > > > HOSTCC scripts/basic/fixdep > > HOSTCC scripts/kconfig/conf.o > > HOSTCC scripts/kconfig/zconf.tab.o > > In file included from scripts/kconfig/zconf.tab.c:2470: > > In function ‘dep_stack_insert’, > > inlined from ‘sym_check_print_recursive’ at > > scripts/kconfig/symbol.c:1123:3, > > inlined from ‘sym_check_deps’ at scripts/kconfig/symbol.c:1300:3: > > scripts/kconfig/symbol.c:1099:19: warning: storing the address of > > local variable ‘cv_stack’ in ‘check_top’ [-Wdangling-pointer=] > > 1099 | check_top = stack; > > | ~~^~~ > > scripts/kconfig/symbol.c: In function ‘sym_check_deps’: > > scripts/kconfig/symbol.c:1120:26: note: ‘cv_stack’ declared here > > 1120 | struct dep_stack cv_stack; > > | ^~~~ > > scripts/kconfig/symbol.c:1090:4: note: ‘check_top’ declared here > > 1090 | } *check_top; > > |^ > > HOSTLD scripts/kconfig/conf > > # > > # configuration written to .config > > # > > > > /mnt/zroot2/zroot2/OS/Chromebook/freebsd-xen/domU-freebsd/bootloaders/u-boot-2017.05# > > ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- make > > > > scripts/kconfig/conf --silentoldconfig Kconfig > > CHK include/config.h > > CFG u-boot.cfg > > GEN include/autoconf.mk > > GEN include/autoconf.mk.dep > > CFG spl/u-boot.cfg > > GEN spl/include/autoconf.mk > > CHK include/config/uboot.release > > CHK include/generated/version_autogenerated.h > > CHK include/generated/timestamp_autogenerated.h > > UPD include/generated/timestamp_autogenerated.h > > CC lib/asm-offsets.s > > arm-linux-gnueabihf-gcc: error: unrecognized -march target: armv5 > > arm-linux-gnueabihf-gcc: note: valid arguments are: armv4 armv4t > > armv5t armv5te armv5tej armv6 armv6j armv6k armv6z armv6kz armv6zk > > armv6t2 armv6-m armv6s-m armv7 armv7-a armv7ve armv7-r armv7-m > > armv7e-m armv8-a armv8.1-a armv8.2-a armv8.3-a armv8.4-a armv8.5-a > > armv8.6-a armv8-m.base armv8-m.main armv8-r armv8.1-m.main armv9-a > > iwmmxt iwmmxt2; did you mean ‘armv4’? > > arm-linux-gnueabihf-gcc: error: missing argument to ‘-march=’ > > make[1]: *** [Kbuild:44: lib/asm-offsets.s] Error 1 > > make: *** [Makefile:1287: prepare0] Error 2 > > You might need to compile with an old toolchain, e.g. gcc 4? I think Simon is right. I could not rebuild that 2017.05 u-boot with gcc 12 now. So I looked at the old log, and it was built with gcc 6.3. gcc -Wp,-MD,disk/.part_efi.o.d -nostdinc -isystem /usr/lib/gcc/arm-linux-gnueabi/6/include -Iinclude -I./arch/arm/include -include ./include/linux/kconfig.h -D__KERNEL__ -D__UBOOT__ -Wall -Wstrict-prototypes -Wno-format-security -fno-builtin -ffreestanding -Os -fno-stack-protector -fno-delete-null-pointer-checks -g -fstack-usage -Wno-format-nonliteral -Werror=date-time -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux -mword-relocations -fno-pic -ffunction-sections -fdata-sections -fno-common -ffixed-r9 -msoft-float -pipe -march=armv5te -D__LINUX_ARM_ARCH__=5 -I./arch/arm/mach-kirkwood/include-D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(part_efi)" -D"KBUILD_MODNAME=KBUILD_STR(part_efi)" -c -o disk/part_efi.o disk/part_efi.c # ll /usr/lib/gcc/arm-linux-gnueabi/6* -d drwxr-xr-x 5 root root 4096 Apr 14 2019 /usr/lib/gcc/arm-linux-gnueabi/6 lrwxrwxrwx 1 root root1 May 16 2017 /usr/lib/gcc/arm-linux-gnueabi/6.3.0 -> 6 Hope this helps. All the best, Tony > > Regards, > Simon > > > > > > On Thu, Dec 28, 2023 at 3:47 PM Mario Marietto > > wrote: > > > > > > Hello. > > > > > > Can someone provide the right link to download u-boot-2017.0.5 , please ? > > > > > > I've found it here,but I'm not sure that it's the correct version : > > > > > > https://src.fedoraproject.org/repo/pkgs/uboot-tools/u-boot-2017.05.tar.bz2/sha512/be270f9242a72b05463092a022bbabd54996762de1ff23bf7575124ac02e62f49572a4e2f6f571a5019047d40027e56e35593b5cc373c4a5a39b100c3377ba93/ > > > > > > Can you confirm it ? thanks. > > > > > > On Thu, Dec 28, 2023 at 1:14 AM Tony Dinh wrote: > > > > >
Re: I'm looking for the source code of a specific u-boot version.
Hi Mario and Heinrich, On Wed, Dec 27, 2023 at 12:23 PM Mario Marietto wrote: > > Hello. > > I'm trying to boot FreeBSD for arm32 bit as DomU on my ARM Chromebook > SNOW with xen. Basically there are two ways to accomplish this task : > > > 1) to write a patch that allows the FreeBSD kernel to boot as a zImage > file. This could be accomplished applying this patch to a specific > file that's on the source code of FreeBSD : > > > https://xenbits.xen.org/gitweb/?p=p...8;hb=0782e25d98cc1391472717035f986c979edef0c9 > > > > This patch was written by Julien Grall a lot of time ago and now it > does not work anymore. This is the reason explain by the xen > developers : > > > > It appears FreeBSD-CURRENT removed the last step converting the kernel > file to kernel.bin.The patch can be readily rebased, but without > kernel.bin that doesn't do too much. > > > > So,without a rebase of that patch the first option is not applicable. > And I'm not able to fix it. > > > 2) booting FreeBSD using U-Boot,as explained to me by a xen developer : > > > I was trying to explain why and how Julien's patch works so that you > could be the one to re-do something similar or fix the patch on the > FreeBSD kernel that you are working with. I am happy to help review > and write patches but I don't work with the FreeBSD kernel so I > wouldn't be able to help you quickly. However, I might have a > suggestion. Do you know if FreeBSD can be booted by U-Boot ? > Because > U-Boot definitely boots as Xen on ARM guest firmware/bootloader. You > should be able to build U-Boot and use the U-Boot binary as Xen guest > kernel, then U-Boot could load FreeBSD from disk or network and start > it. For instance as domU config file: > > kernel="/home/petalinux/u-boot.bin" > disk = [ '/home/petalinux/test.img,raw,xvda' ] > > > Actually I'm working on the idea n. 2. Basically I need to find the > proper u-boot file that's able to boot the image of FreeBSD that I > have installed (13.2 for arm32 bit). Maybe I found it here : > > > http://commondatastorage.googleapis.com/chromeos-localmirror/distfiles/nv_uboot-snow-simplefb.kpart.bz2 > > > I found that link inside this tutorial : > > > https://wiki.freebsd.org/arm/Chromebook > > > the version of u-boot that has been embedded in that file is the following > one : > > > # strings nv_uboot-snow-simplefb.kpart | grep U-Boot > U-Boot 2011.12-gc1f6280 (May 27 2013 - 15:06:59) for SMDK5250 > > > So the question is easy : I need to find the source code of that old > version of u-boot,because once compiled,it will give me the proper > u-boot.bin kernel / bootloader file that maybe will be able to boot > FreeBSD. Yes, it can boot a 32-bit ARM board. I'm not a FreeBSD person, but I've helped a FreeBSD user booting a 32-bit ARM box with u-boot (GoFlexHome Marvell Kirkwood 6281). The u-boot version was 2017.05. I used an out-of-tree u-boot build. This u-boot executed the ubldr to boot FreeBSD. Please see here: https://forum.doozan.com/read.php?3,49039,82059#msg-82059 It's been so long, I don't remember the details. Just to confirm what Heinrich said that u-boot can indeed boot 32-bit FreeBSD, since many years ago. All the best, Tony > > > -- > Mario.
Re: [PATCH 0/8] An effort to bring DT bindings compliance within U-boot
Hi Sumit Hi Simon, On Tue, Dec 26, 2023 at 2:13 AM Sumit Garg wrote: > > Hi Simon, > > On Tue, 26 Dec 2023 at 15:17, Simon Glass wrote: > > > > Hi Sumit, > > > > On Fri, Dec 22, 2023 at 5:34 AM Sumit Garg wrote: > > > > > > On Thu, 21 Dec 2023 at 20:48, Simon Glass wrote: > > > > > > > > Hi, > > > > > > > > On Thu, Dec 21, 2023 at 3:03 PM Tom Rini wrote: > > > > > > > > > > On Thu, Dec 14, 2023 at 07:20:55PM +0530, Sumit Garg wrote: > > > > > > > > > > > Prerquisite > > > > > > --- > > > > > > > > > > > > This patch series requires devicetree-rebasing git repo to be added > > > > > > as a > > > > > > subtree to the main U-boot repo via: > > > > > > > > > > > > $ git subtree add --prefix devicetree-rebasing \ > > > > > > > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git > > > > > > \ > > > > > > v6.6-dts --squash > > > > > > > > > > So, I've played with subtree a little and I think this is the right > > > > > way > > > > > forward in these cases. If anyone wants to take a look at how this > > > > > works > > > > > in practice, take a look at: > > > > > https://source.denx.de/u-boot/u-boot/-/commits/WIP/u-boot-with-devicetree-rebasing-since-v6.1/?ref_type=heads > > > > > In that tree I started with the v6.1-dts tag, sync'd all the configs > > > > > (to > > > > > have an example of a normal commit) and then did a merge of each tag > > > > > until v6.6-dts, so provide some history. And git log looks like what I > > > > > want to see, the squash commit has clear references to what we are > > > > > getting and I make a merge commit that says what I did. If you pull > > > > > the > > > > > tree and checkout the branch, all the code is right there already, > > > > > nothing further to do. Same with tarball releases. The only thing I > > > > > don't like is the size growth there, but we'll reclaim some of it when > > > > > we delete our obsolete bindings, and then obsolete dts files. > > > > > > > > I spent a bit of time with subtree as well, as part of reviewing this > > > > series, using the instructions Sumit provided. It seems OK to me. We > > > > have to accept that it adds code and there will be changes/churn, but > > > > it is not too different to accepting patches on those files within > > > > U-Boot. We will bring in files which U-Boot doesn't use, but U-Boot > > > > does support a good proportion of the boards supported by Linux, so I > > > > don't see that as a big cost. > > > > > > > > From my experimentation, subtrees seem to have no impact on buildman, > > > > which is great. Am I missing anything? > > > > > > No it shouldn't cause any regression on existing tools/CI/build > > > systems. It is just a version controlled way of importing third party > > > source code as a tarball. > > > > > > > > > > > I still worry about the board-level 'switch' between U-Boot DT and > > > > upstream ones. I believe that should be at the SoC level instead. > > > > > > > > > > Probably I wasn't clear enough in my earlier replies but this series > > > motivates for a SoC level switch only. Patch #7 is essentially a > > > switch for Amlogic meson-gxbb SoC and its derived boards. > > > > OK good...but that's not quite what I mean. You have a fragment like > > this in multiple defconfig files: > > > > +CONFIG_OF_UPSTREAM=y > > +CONFIG_DEFAULT_DEVICE_TREE="amlogic/meson-gxbb-odroidc2" > > > > instead, OF_UPSTREAM should be enabled via 'imply' for the SoC, in the > > Kconfig. > > Okay I got your point. It makes sense to me. I will do that for v3. > > > We should not have to specify the filename like this. It is > > laborious and error-prone. > > The only differentiation in naming here is just silicon vendor prefix > addition (amlogic/ in this case). The reason for this being that I > just want to mirror the whole silicon vendor directory from DT > rebasing rather than mirroring individual DT files. Given this do you > have any better alternatives? > So how do we handle the case where the DTS exists in u-boot, but not in Linux? For example, the DTS was developed for u-boot first and has not been accepted in the Linux device tree yet. Can we set in the board defconfig like: # CONFIG_OF_UPSTREAM is not set Would that allow the DTS to remain in arch//dts? Thanks, Tony
Re: bootstd: Scanning for USB bootflow will remove existing SCSI bootflow
Hi Simon, On Mon, Nov 6, 2023 at 12:51 PM Tony Dinh wrote: > > On Mon, Nov 6, 2023 at 11:51 AM Tom Rini wrote: > > > > On Mon, Nov 06, 2023 at 11:42:51AM -0800, Tony Dinh wrote: > > > Hi Simon, > > > > > > On Mon, Nov 6, 2023 at 9:25 AM Simon Glass wrote: > > > > > > > > Hi Tony, > > > > > > > > On Wed, 4 Oct 2023 at 21:23, Tony Dinh wrote: > > > > > > > > > > Hi Simon, > > > > > > > > > > On Mon, Oct 2, 2023 at 12:25 PM Tony Dinh wrote: > > > > > > > > > > > > Hi Simon, > > > > > > > > > > > > On Sun, Oct 1, 2023 at 6:22 PM Simon Glass > > > > > > wrote: > > > > > > > > > > > > > > Hi Tony, > > > > > > > > > > > > > > On Tue, 26 Sept 2023 at 13:40, Tony Dinh > > > > > > > wrote: > > > > > > > > > > > > > > > > Hi Simon, > > > > > > > > > > > > > > > > On Tue, Sep 26, 2023 at 4:37 AM Simon Glass > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > Hi Tony, > > > > > > > > > > > > > > > > > > On Mon, 25 Sept 2023 at 14:02, Tony Dinh > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > Hi Simon, > > > > > > > > > > > > > > > > > > > > Here is an observation during testing the bootflow command. > > > > > > > > > > > > > > > > > > > > If there is a SCSI bootflow, scanning for USB bootflow will > > > > > > > > > > remove that existing > > > > > > > > > > SCSI bootflow. To bring it back, I scanned for SCSI > > > > > > > > > > bootflow again, and it was > > > > > > > > > > back to normal. Perhaps there is some kind of indexing > > > > > > > > > > problem? > > > > > > > > > > > > > > > > > > Yes that's right. The 'botflow scan' command is not additive. > > > > > > > > > The > > > > > > > > > first thing it does is removing existing bootflows. > > > > > > > > > > > > > > > > Thanks for clarifying that. I assumed it is additive, because > > > > > > > > the > > > > > > > > existing USB bootflow was not removed when I did a "bootflow > > > > > > > > scan > > > > > > > > scsi" immediately after (see the end of the log). > > > > > > > > > > > > > > Yes, but I'm not sure what is going on there. Perhaps it is a bug? > > > > > > > When you scan SCSI it should not also scan USB. > > > > > > > > > > > > Yes, it looks like a bug. I think I can see the problem and am > > > > > > working > > > > > > on a patch. > > > > > > > > > > Just to let you know, I'm out of time to work on this topic. I will > > > > > revisit it some other time, if you have not already tracked it down. > > > > > > > > If you are able to use 'bootflow scan -l' in each case, then I might > > > > be able to see what it is scanning USB, when you are asking for SCSI. > > > > I also wonder if this bug may have been fixed due to other changes? > > > > > > I'm wondering about that, too. I will rerun the test with the master > > > branch with debug trace. If we cannot see it, I'll do it again when > > > other bootstd patches are merged. Right now I am not sure which of > > > your bootstd patches I should apply to the tree for testing, do you > > > have a list for that? > > > > Right now the only outstanding bootstd patch I know of is your recent > > one, as I was waiting for Simon's review (which he did today) before > > merging and applying. > > Thanks Tom! I'll run the test in my tree as is then. The good news: apparently one of your recent bootstd patches has fixed this problem! I think your bootstd mmc scanning patch is probably where it was fixed. I tested with rc2 plus my recent patch (not yet merged to master) in the tree: https://pa
Re: bootstd: Scanning for USB bootflow will remove existing SCSI bootflow
On Mon, Nov 6, 2023 at 11:51 AM Tom Rini wrote: > > On Mon, Nov 06, 2023 at 11:42:51AM -0800, Tony Dinh wrote: > > Hi Simon, > > > > On Mon, Nov 6, 2023 at 9:25 AM Simon Glass wrote: > > > > > > Hi Tony, > > > > > > On Wed, 4 Oct 2023 at 21:23, Tony Dinh wrote: > > > > > > > > Hi Simon, > > > > > > > > On Mon, Oct 2, 2023 at 12:25 PM Tony Dinh wrote: > > > > > > > > > > Hi Simon, > > > > > > > > > > On Sun, Oct 1, 2023 at 6:22 PM Simon Glass wrote: > > > > > > > > > > > > Hi Tony, > > > > > > > > > > > > On Tue, 26 Sept 2023 at 13:40, Tony Dinh wrote: > > > > > > > > > > > > > > Hi Simon, > > > > > > > > > > > > > > On Tue, Sep 26, 2023 at 4:37 AM Simon Glass > > > > > > > wrote: > > > > > > > > > > > > > > > > Hi Tony, > > > > > > > > > > > > > > > > On Mon, 25 Sept 2023 at 14:02, Tony Dinh > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > Hi Simon, > > > > > > > > > > > > > > > > > > Here is an observation during testing the bootflow command. > > > > > > > > > > > > > > > > > > If there is a SCSI bootflow, scanning for USB bootflow will > > > > > > > > > remove that existing > > > > > > > > > SCSI bootflow. To bring it back, I scanned for SCSI bootflow > > > > > > > > > again, and it was > > > > > > > > > back to normal. Perhaps there is some kind of indexing > > > > > > > > > problem? > > > > > > > > > > > > > > > > Yes that's right. The 'botflow scan' command is not additive. > > > > > > > > The > > > > > > > > first thing it does is removing existing bootflows. > > > > > > > > > > > > > > Thanks for clarifying that. I assumed it is additive, because the > > > > > > > existing USB bootflow was not removed when I did a "bootflow scan > > > > > > > scsi" immediately after (see the end of the log). > > > > > > > > > > > > Yes, but I'm not sure what is going on there. Perhaps it is a bug? > > > > > > When you scan SCSI it should not also scan USB. > > > > > > > > > > Yes, it looks like a bug. I think I can see the problem and am working > > > > > on a patch. > > > > > > > > Just to let you know, I'm out of time to work on this topic. I will > > > > revisit it some other time, if you have not already tracked it down. > > > > > > If you are able to use 'bootflow scan -l' in each case, then I might > > > be able to see what it is scanning USB, when you are asking for SCSI. > > > I also wonder if this bug may have been fixed due to other changes? > > > > I'm wondering about that, too. I will rerun the test with the master > > branch with debug trace. If we cannot see it, I'll do it again when > > other bootstd patches are merged. Right now I am not sure which of > > your bootstd patches I should apply to the tree for testing, do you > > have a list for that? > > Right now the only outstanding bootstd patch I know of is your recent > one, as I was waiting for Simon's review (which he did today) before > merging and applying. Thanks Tom! I'll run the test in my tree as is then. All the best, Tony
Re: bootstd: Scanning for USB bootflow will remove existing SCSI bootflow
Hi Simon, On Mon, Nov 6, 2023 at 9:25 AM Simon Glass wrote: > > Hi Tony, > > On Wed, 4 Oct 2023 at 21:23, Tony Dinh wrote: > > > > Hi Simon, > > > > On Mon, Oct 2, 2023 at 12:25 PM Tony Dinh wrote: > > > > > > Hi Simon, > > > > > > On Sun, Oct 1, 2023 at 6:22 PM Simon Glass wrote: > > > > > > > > Hi Tony, > > > > > > > > On Tue, 26 Sept 2023 at 13:40, Tony Dinh wrote: > > > > > > > > > > Hi Simon, > > > > > > > > > > On Tue, Sep 26, 2023 at 4:37 AM Simon Glass wrote: > > > > > > > > > > > > Hi Tony, > > > > > > > > > > > > On Mon, 25 Sept 2023 at 14:02, Tony Dinh wrote: > > > > > > > > > > > > > > Hi Simon, > > > > > > > > > > > > > > Here is an observation during testing the bootflow command. > > > > > > > > > > > > > > If there is a SCSI bootflow, scanning for USB bootflow will > > > > > > > remove that existing > > > > > > > SCSI bootflow. To bring it back, I scanned for SCSI bootflow > > > > > > > again, and it was > > > > > > > back to normal. Perhaps there is some kind of indexing problem? > > > > > > > > > > > > Yes that's right. The 'botflow scan' command is not additive. The > > > > > > first thing it does is removing existing bootflows. > > > > > > > > > > Thanks for clarifying that. I assumed it is additive, because the > > > > > existing USB bootflow was not removed when I did a "bootflow scan > > > > > scsi" immediately after (see the end of the log). > > > > > > > > Yes, but I'm not sure what is going on there. Perhaps it is a bug? > > > > When you scan SCSI it should not also scan USB. > > > > > > Yes, it looks like a bug. I think I can see the problem and am working > > > on a patch. > > > > Just to let you know, I'm out of time to work on this topic. I will > > revisit it some other time, if you have not already tracked it down. > > If you are able to use 'bootflow scan -l' in each case, then I might > be able to see what it is scanning USB, when you are asking for SCSI. > I also wonder if this bug may have been fixed due to other changes? I'm wondering about that, too. I will rerun the test with the master branch with debug trace. If we cannot see it, I'll do it again when other bootstd patches are merged. Right now I am not sure which of your bootstd patches I should apply to the tree for testing, do you have a list for that? All the best, Tony > > Regards, > Simon
[PATCH v2] bootstd: Skip over bad device during bootflows scanning
During bootstd scanning for bootdevs, if bootdev_hunt_drv() encounters
a device not found error (e.g. ENOENT), let it return a successful status
so that bootstd will continue scanning the next devices, not stopping
prematurely.
Background:
During scanning for bootflows, it's possible for bootstd to encounter a
faulty device controller. Also when the same u-boot is used for another
variant of the same board, some device controller such as SATA might
not exist.
I've found this issue while converting the Marvell Sheevaplug board to
use bootstd. This board has 2 variants, the original Sheevaplug has MMC and
USB only, but the later variant comes with USB, MMC, and eSATA ports. We
have been using the same u-boot (starting with CONFIG_IDE and later with DM
CONFIG_SATA) for both variants. This worked well with the old
envs-scripting booting scheme.
Signed-off-by: Tony Dinh
---
Changes in v2:
- Restore bootdev_next_prio() to the original.
- Add a check in bootdev_hunt_drv(). If its descendant bootdev hunt driver
function returns -ENOENT, set the hunt status to successful (this is the
case where the device does not exist, or a bad device controller).
- Update bootdev_hunter_func() docs to indicate that a return
status -ENOENT is not an error, just a "device not found" status.
- Set status of sata_rescan() to -ENOENT when the SATA device is not found.
boot/bootdev-uclass.c | 2 +-
drivers/ata/sata.c| 2 +-
include/bootdev.h | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/boot/bootdev-uclass.c b/boot/bootdev-uclass.c
index 44ae98a926..4926a50da8 100644
--- a/boot/bootdev-uclass.c
+++ b/boot/bootdev-uclass.c
@@ -784,7 +784,7 @@ static int bootdev_hunt_drv(struct bootdev_hunter *info,
uint seq, bool show)
if (info->hunt) {
ret = info->hunt(info, show);
log_debug(" - hunt result %d\n", ret);
- if (ret)
+ if (ret && ret != -ENOENT)
return ret;
}
std->hunters_used |= BIT(seq);
diff --git a/drivers/ata/sata.c b/drivers/ata/sata.c
index dcb5fcf476..64fc078bad 100644
--- a/drivers/ata/sata.c
+++ b/drivers/ata/sata.c
@@ -65,7 +65,7 @@ int sata_rescan(bool verbose)
ret = uclass_find_first_device(UCLASS_AHCI, );
if (ret || !dev) {
printf("Cannot find SATA device (err=%d)\n", ret);
- return -ENOSYS;
+ return -ENOENT;
}
ret = device_remove(dev, DM_REMOVE_NORMAL);
diff --git a/include/bootdev.h b/include/bootdev.h
index b079a91b5b..35fa25aff1 100644
--- a/include/bootdev.h
+++ b/include/bootdev.h
@@ -65,7 +65,7 @@ struct bootdev_hunter;
*
* @info: Info structure describing this hunter
* @show: true to show information from the hunter
- * Returns: 0 if OK, -ve on error
+ * Returns: 0 if OK, -ENOENT on device not found, otherwise -ve on error
*/
typedef int (*bootdev_hunter_func)(struct bootdev_hunter *info, bool show);
--
2.39.2
Re: [PATCH] bootstd: Skip over bad device during bootflows scanning
Hi Simon,
On Wed, Nov 1, 2023 at 9:10 AM Simon Glass wrote:
>
> Hi Tony,
>
> On Tue, 31 Oct 2023 at 13:45, Tony Dinh wrote:
> >
> > On Tue, Oct 31, 2023 at 12:26 PM Tony Dinh wrote:
> > >
> > > Hi Simon,
> > >
> > > On Mon, Oct 30, 2023 at 12:47 PM Tony Dinh wrote:
> > > >
> > > > During scanning for the next bootdev, if bootdev_next_prio() encounters
> > > > a device error (e.g. ENOSYS), let it continue scanning the next devices,
> > > > not stopping prematurely.
> > > >
> > > > Background:
> > > >
> > > > During scanning for bootflows, it's possible for bootstd to encounter a
> > > > faulty device controller. Also when the same u-boot is used for another
> > > > variant of the same board, some device controller such as SATA might
> > > > not exist.
> > > >
> > > > I've found this issue while converting the Marvell Sheevaplug board to
> > > > use bootstd. This board has 2 variants, the original Sheevaplug has MMC
> > > > and
> > > > USB only, but the later variant comes with USB, MMC, and eSATA ports. We
> > > > have been using the same u-boot (starting with CONFIG_IDE and later
> > > > with DM
> > > > CONFIG_SATA) for both variants. This worked well with the old
> > > > envs-scripting booting scheme.
> > > >
> > > > Signed-off-by: Tony Dinh
> > > > ---
> > > >
> > > > boot/bootdev-uclass.c | 2 --
> > > > 1 file changed, 2 deletions(-)
> > > >
> > > > diff --git a/boot/bootdev-uclass.c b/boot/bootdev-uclass.c
> > > > index 44ae98a926..b1d48e5b69 100644
> > > > --- a/boot/bootdev-uclass.c
> > > > +++ b/boot/bootdev-uclass.c
> > > > @@ -677,8 +677,6 @@ int bootdev_next_prio(struct bootflow_iter *iter,
> > > > struct udevice **devp)
> > > >
> > > > BOOTFLOWIF_SHOW);
> > > > log_debug("- bootdev_hunt_prio() ret
> > > > %d\n",
> > > > ret);
> > > > - if (ret)
> > > > - return log_msg_ret("hun", ret);
> > > > }
> > > > } else {
> > > > ret = device_probe(dev);
> > > > --
> > > > 2.39.2
> > > >
> > >
> > > Per your request, here is the console trace log when the device error
> > > occurs. Perhaps we could improve bootdev_next_prio() to make the error
> > > status more visible in the console with printf? I've briefly looked at
> > > other device bootdev hunt drivers and did not see enough console
> > > output for this type of error, so it might be better that we have this
> > > output either in bootdev_next_prio() or bootdev_hunt_drv().
> > >
> > >
> > > U-Boot 2024.01-rc1-tld-1-3-gd697d7b93a-dirty (Oct 26 2023 - 16:17:16
> > > -0700)
> > > Marvell-Sheevaplug
> > >
> > > SoC: Kirkwood 88F6281_A0
> > > DRAM: 512 MiB
> > > Core: 17 devices, 12 uclasses, devicetree: separate
> > > NAND: 512 MiB
> > > MMC: 338-uclass_find_device_by_seq() 0
> > > 346-uclass_find_device_by_seq()- 0 'mvsdio@9'
> > > 349-uclass_find_device_by_seq()- found
> > > 252- mvebu_mmc_power_up() mvebu_mmc mvsdio@9: power up
> > > 399-mvebu_mmc_initialize() mvebu_mmc mvsdio@9: mvebu_mmc_initialize
> > > 338-uclass_find_device_by_seq() 1
> > > 346-uclass_find_device_by_seq()- 0 'mvsdio@9'
> > > 353-uclass_find_device_by_seq()- not found
> > > mvsdio@9: 0
> > > Loading Environment from NAND... 338-uclass_find_device_by_seq() 0
> > > 346-uclass_find_device_by_seq()- 0 'ethernet-controller@72000'
> > > 349-uclass_find_device_by_seq()- found
> > > OK
> > > In:serial
> > > Out: serial
> > > Err: serial
> > > Net: eth0: ethernet-controller@72000
> > > Hit any key to stop autoboot: 0
> > >
> > > => env def -a
> > > ## Resetting to default environment
> > >
> > > => bootflow scan -l
> > > Scanning for bootflows in all bootdevs
> > > Seq Method State UclassPart Name
> > > Filena
Re: Re bootstd: Skip over bad device during bootflows scanning
Hi Simon, On Tue, Oct 31, 2023 at 12:00 PM Tony Dinh wrote: > > Hi Simon, > > On Tue, Oct 31, 2023 at 11:50 AM Simon Glass wrote: > > > > Hi Tony, > > > > Sorry I cannot reply to the patch[1]. > > > > Can you please send the console trace for this situation? I don't want > > to ignore errors completely, so wonder if there is a special error > > code which could be produced when a device is missing? > > The error is -ENOSYS (-38). But sure, I'll post the console log. I've sent the console log in the patch thread. All the best, Tony
Re: [PATCH] bootstd: Skip over bad device during bootflows scanning
On Tue, Oct 31, 2023 at 12:26 PM Tony Dinh wrote:
>
> Hi Simon,
>
> On Mon, Oct 30, 2023 at 12:47 PM Tony Dinh wrote:
> >
> > During scanning for the next bootdev, if bootdev_next_prio() encounters
> > a device error (e.g. ENOSYS), let it continue scanning the next devices,
> > not stopping prematurely.
> >
> > Background:
> >
> > During scanning for bootflows, it's possible for bootstd to encounter a
> > faulty device controller. Also when the same u-boot is used for another
> > variant of the same board, some device controller such as SATA might
> > not exist.
> >
> > I've found this issue while converting the Marvell Sheevaplug board to
> > use bootstd. This board has 2 variants, the original Sheevaplug has MMC and
> > USB only, but the later variant comes with USB, MMC, and eSATA ports. We
> > have been using the same u-boot (starting with CONFIG_IDE and later with DM
> > CONFIG_SATA) for both variants. This worked well with the old
> > envs-scripting booting scheme.
> >
> > Signed-off-by: Tony Dinh
> > ---
> >
> > boot/bootdev-uclass.c | 2 --
> > 1 file changed, 2 deletions(-)
> >
> > diff --git a/boot/bootdev-uclass.c b/boot/bootdev-uclass.c
> > index 44ae98a926..b1d48e5b69 100644
> > --- a/boot/bootdev-uclass.c
> > +++ b/boot/bootdev-uclass.c
> > @@ -677,8 +677,6 @@ int bootdev_next_prio(struct bootflow_iter *iter,
> > struct udevice **devp)
> > BOOTFLOWIF_SHOW);
> > log_debug("- bootdev_hunt_prio() ret %d\n",
> > ret);
> > - if (ret)
> > - return log_msg_ret("hun", ret);
> > }
> > } else {
> > ret = device_probe(dev);
> > --
> > 2.39.2
> >
>
> Per your request, here is the console trace log when the device error
> occurs. Perhaps we could improve bootdev_next_prio() to make the error
> status more visible in the console with printf? I've briefly looked at
> other device bootdev hunt drivers and did not see enough console
> output for this type of error, so it might be better that we have this
> output either in bootdev_next_prio() or bootdev_hunt_drv().
>
>
> U-Boot 2024.01-rc1-tld-1-3-gd697d7b93a-dirty (Oct 26 2023 - 16:17:16
> -0700)
> Marvell-Sheevaplug
>
> SoC: Kirkwood 88F6281_A0
> DRAM: 512 MiB
> Core: 17 devices, 12 uclasses, devicetree: separate
> NAND: 512 MiB
> MMC: 338-uclass_find_device_by_seq() 0
> 346-uclass_find_device_by_seq()- 0 'mvsdio@9'
> 349-uclass_find_device_by_seq()- found
> 252- mvebu_mmc_power_up() mvebu_mmc mvsdio@9: power up
> 399-mvebu_mmc_initialize() mvebu_mmc mvsdio@9: mvebu_mmc_initialize
> 338-uclass_find_device_by_seq() 1
> 346-uclass_find_device_by_seq()- 0 'mvsdio@9'
> 353-uclass_find_device_by_seq()- not found
> mvsdio@9: 0
> Loading Environment from NAND... 338-uclass_find_device_by_seq() 0
> 346-uclass_find_device_by_seq()- 0 'ethernet-controller@72000'
> 349-uclass_find_device_by_seq()- found
> OK
> In:serial
> Out: serial
> Err: serial
> Net: eth0: ethernet-controller@72000
> Hit any key to stop autoboot: 0
>
> => env def -a
> ## Resetting to default environment
>
> => bootflow scan -l
> Scanning for bootflows in all bootdevs
> Seq Method State UclassPart Name Filename
> --- --- --
>
> 338-uclass_find_device_by_seq() 0
> 346-uclass_find_device_by_seq()- 0 'extlinux'
> 349-uclass_find_device_by_seq()- found
> 338-uclass_find_device_by_seq() 1
> 346-uclass_find_device_by_seq()- 0 'extlinux'
> 346-uclass_find_device_by_seq()- 1 'script'
> 349-uclass_find_device_by_seq()- found
> 338-uclass_find_device_by_seq() 2
> 346-uclass_find_device_by_seq()- 0 'extlinux'
> 346-uclass_find_device_by_seq()- 1 'script'
> 346-uclass_find_device_by_seq()- 2 'pxe'
> 349-uclass_find_device_by_seq()- found
> 871- bootdev_hunt_prio() Hunting for priority 1
> 883- bootdev_hunt_prio() exit 0
> 715- bootdev_setup_iter() - bootdev_hunt_prio() ret 0
> 83-bootstd_get_bootdev_order() - targets
> 746- bootdev_setup_iter() setup labels
> 641- bootdev_next_prio() next prio 0: dev=/none
> 659- bootdev_next_prio() - ethernet-control...@72000.boo: 6, want 0
> 659- bootdev_next_prio() - mvsdio@9.boot
Re: [PATCH] bootstd: Skip over bad device during bootflows scanning
Hi Simon,
On Mon, Oct 30, 2023 at 12:47 PM Tony Dinh wrote:
>
> During scanning for the next bootdev, if bootdev_next_prio() encounters
> a device error (e.g. ENOSYS), let it continue scanning the next devices,
> not stopping prematurely.
>
> Background:
>
> During scanning for bootflows, it's possible for bootstd to encounter a
> faulty device controller. Also when the same u-boot is used for another
> variant of the same board, some device controller such as SATA might
> not exist.
>
> I've found this issue while converting the Marvell Sheevaplug board to
> use bootstd. This board has 2 variants, the original Sheevaplug has MMC and
> USB only, but the later variant comes with USB, MMC, and eSATA ports. We
> have been using the same u-boot (starting with CONFIG_IDE and later with DM
> CONFIG_SATA) for both variants. This worked well with the old
> envs-scripting booting scheme.
>
> Signed-off-by: Tony Dinh
> ---
>
> boot/bootdev-uclass.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/boot/bootdev-uclass.c b/boot/bootdev-uclass.c
> index 44ae98a926..b1d48e5b69 100644
> --- a/boot/bootdev-uclass.c
> +++ b/boot/bootdev-uclass.c
> @@ -677,8 +677,6 @@ int bootdev_next_prio(struct bootflow_iter *iter, struct
> udevice **devp)
> BOOTFLOWIF_SHOW);
> log_debug("- bootdev_hunt_prio() ret %d\n",
> ret);
> - if (ret)
> - return log_msg_ret("hun", ret);
> }
> } else {
> ret = device_probe(dev);
> --
> 2.39.2
>
Per your request, here is the console trace log when the device error
occurs. Perhaps we could improve bootdev_next_prio() to make the error
status more visible in the console with printf? I've briefly looked at
other device bootdev hunt drivers and did not see enough console
output for this type of error, so it might be better that we have this
output either in bootdev_next_prio() or bootdev_hunt_drv().
U-Boot 2024.01-rc1-tld-1-3-gd697d7b93a-dirty (Oct 26 2023 - 16:17:16 -0700)
Marvell-Sheevaplug
SoC: Kirkwood 88F6281_A0
DRAM: 512 MiB
Core: 17 devices, 12 uclasses, devicetree: separate
NAND: 512 MiB
MMC: 338-uclass_find_device_by_seq() 0
346-uclass_find_device_by_seq()- 0 'mvsdio@9'
349-uclass_find_device_by_seq()- found
252- mvebu_mmc_power_up() mvebu_mmc mvsdio@9: power up
399-mvebu_mmc_initialize() mvebu_mmc mvsdio@9: mvebu_mmc_initialize
338-uclass_find_device_by_seq() 1
346-uclass_find_device_by_seq()- 0 'mvsdio@9'
353-uclass_find_device_by_seq()- not found
mvsdio@9: 0
Loading Environment from NAND... 338-uclass_find_device_by_seq() 0
346-uclass_find_device_by_seq()- 0 'ethernet-controller@72000'
349-uclass_find_device_by_seq()- found
OK
In:serial
Out: serial
Err: serial
Net: eth0: ethernet-controller@72000
Hit any key to stop autoboot: 0
=> env def -a
## Resetting to default environment
=> bootflow scan -l
Scanning for bootflows in all bootdevs
Seq Method State UclassPart Name Filename
--- --- --
338-uclass_find_device_by_seq() 0
346-uclass_find_device_by_seq()- 0 'extlinux'
349-uclass_find_device_by_seq()- found
338-uclass_find_device_by_seq() 1
346-uclass_find_device_by_seq()- 0 'extlinux'
346-uclass_find_device_by_seq()- 1 'script'
349-uclass_find_device_by_seq()- found
338-uclass_find_device_by_seq() 2
346-uclass_find_device_by_seq()- 0 'extlinux'
346-uclass_find_device_by_seq()- 1 'script'
346-uclass_find_device_by_seq()- 2 'pxe'
349-uclass_find_device_by_seq()- found
871- bootdev_hunt_prio() Hunting for priority 1
883- bootdev_hunt_prio() exit 0
715- bootdev_setup_iter() - bootdev_hunt_prio() ret 0
83-bootstd_get_bootdev_order() - targets
746- bootdev_setup_iter() setup labels
641- bootdev_next_prio() next prio 0: dev=/none
659- bootdev_next_prio() - ethernet-control...@72000.boo: 6, want 0
659- bootdev_next_prio() - mvsdio@9.bootdev: 2, want 0
668- bootdev_next_prio() None found at prio 0, moving to 1
871- bootdev_hunt_prio() Hunting for priority 1
883- bootdev_hunt_prio() exit 0
678- bootdev_next_prio() - bootdev_hunt_prio() ret 0
659- bootdev_next_prio() - ethernet-control...@72000.boo: 6, want 1
659- bootdev_next_prio() - mvsdio@9.bootdev: 2, want 1
668- bootdev_next_prio() None found at prio 1, moving to 2
871- bootdev_hunt_prio() Hunting for priority 2
Hunting with: mmc
783-bootdev_hunt_drv() Hunting with: mmc
879- bootdev_hunt_prio() bootdev_hunt_drv() return 0
883- boo
Re: Re bootstd: Skip over bad device during bootflows scanning
Hi Simon, On Tue, Oct 31, 2023 at 11:50 AM Simon Glass wrote: > > Hi Tony, > > Sorry I cannot reply to the patch[1]. > > Can you please send the console trace for this situation? I don't want > to ignore errors completely, so wonder if there is a special error > code which could be produced when a device is missing? The error is -ENOSYS (-38). But sure, I'll post the console log. Thanks, Tony > > Regards, > Simon > > [1] > https://patchwork.ozlabs.org/project/uboot/patch/20231030194650.11594-1-mibo...@gmail.com/
[PATCH] bootstd: Skip over bad device during bootflows scanning
During scanning for the next bootdev, if bootdev_next_prio() encounters
a device error (e.g. ENOSYS), let it continue scanning the next devices,
not stopping prematurely.
Background:
During scanning for bootflows, it's possible for bootstd to encounter a
faulty device controller. Also when the same u-boot is used for another
variant of the same board, some device controller such as SATA might
not exist.
I've found this issue while converting the Marvell Sheevaplug board to
use bootstd. This board has 2 variants, the original Sheevaplug has MMC and
USB only, but the later variant comes with USB, MMC, and eSATA ports. We
have been using the same u-boot (starting with CONFIG_IDE and later with DM
CONFIG_SATA) for both variants. This worked well with the old
envs-scripting booting scheme.
Signed-off-by: Tony Dinh
---
boot/bootdev-uclass.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/boot/bootdev-uclass.c b/boot/bootdev-uclass.c
index 44ae98a926..b1d48e5b69 100644
--- a/boot/bootdev-uclass.c
+++ b/boot/bootdev-uclass.c
@@ -677,8 +677,6 @@ int bootdev_next_prio(struct bootflow_iter *iter, struct
udevice **devp)
BOOTFLOWIF_SHOW);
log_debug("- bootdev_hunt_prio() ret %d\n",
ret);
- if (ret)
- return log_msg_ret("hun", ret);
}
} else {
ret = device_probe(dev);
--
2.39.2
Re: [PATCH] fixup! usb: xhci: Guard all calls to xhci_wait_for_event
On Sun, Oct 29, 2023 at 2:33 PM Peter Robinson wrote: > > On Sun, Oct 29, 2023 at 9:25 PM Marek Vasut wrote: > > > > On 10/27/23 08:03, Hector Martin wrote: > > > On 27/10/2023 09.36, Marek Vasut wrote: > > >> On 10/27/23 01:26, Hector Martin wrote: > > >>> Gah, I should've paid more attention to that rebase. Here's a dumb > > >>> fixup for this patch. I'll squash it into a v2 if needed alongside > > >>> any other changes, or if it looks good feel free to apply/squash > > >>> it in directly. > > >>> > > >>> --- > > >>>drivers/usb/host/xhci-ring.c | 1 + > > >>>1 file changed, 1 insertion(+) > > >>> > > >>> diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c > > >>> index e2bd2e999a8e..7f2507be0cf0 100644 > > >>> --- a/drivers/usb/host/xhci-ring.c > > >>> +++ b/drivers/usb/host/xhci-ring.c > > >>> @@ -532,6 +532,7 @@ static void reset_ep(struct usb_device *udev, int > > >>> ep_index) > > >>> event = xhci_wait_for_event(ctrl, TRB_COMPLETION); > > >>> if (!event) > > >>> return; > > >>> + field = le32_to_cpu(event->trans_event.flags); > > >>> BUG_ON(TRB_TO_SLOT_ID(field) != udev->slot_id); > > >>> xhci_acknowledge_event(ctrl); > > >> > > >> Please squash, and add > > >> > > >> Reviewed-by: Marek Vasut > > >> > > >> Also, +CC Minda, > > >> > > >> there has been a similar fix to this one but with much more information > > >> about the failure, see: > > >> > > >> [PATCH v1] usb: xhci: Check return value of wait for TRB_TRANSFER event > > >> > > >> I think it would be useful to somehow include that information, so it > > >> wouldn't be lost. > > > > > > The root cause for *that* failure is what I fix in patch #5. From that > > > thread: > > > > > >> scanning bus xhci_pci for devices... WARN halted endpoint, queueing > > > URB anyway. > > > > > > Without #5 and without #1, that situation then leads to fireworks. > > > > > > A bunch of things are broken, which is why this is a series and not a > > > single patch. I have more fixes to timeout handling, mass storage, etc. > > > coming up after this. I fixed most of this in one long day of trying > > > random USB devices, so it's not so much subtle super specific problems I > > > could document the crashes for as just wide-ranging problems in the > > > u-boot USB stack. None of this is particularly hard to repro if you just > > > try a bunch of normal consumer USB devices, including things like USB > > > HDDs which take time to spin-up leading to timeouts etc. > > > > I think majority of users I can think of use USB mass storage devices, > > like USB pen drives, not so much HDDs as far as I can tell. > > We see a bunch of spinning rust users in Fedora, these sorts of > devices are used by a bunch of people that want to run up cheap home > NAS devices so from experience I'd say while not usual to be USB > sticks and some form of solid state storage, spinning disk isn't > unusual. What Peter said. A very common use case, even more so than USB flash drives, is for the consumers to plug in a USB HDD to their routers or home NAS, as a cheap and quick solution. I've seen this type of timeout failure happen quite often with large >= 3TB HDDs in USB enclosure. All the best, Tony > > > > The crash dumps > > > aren't particularly useful, it's the subtleties of the xHCI interactions > > > that are, but for that you need to add and enable a lot more debugging > > > (patch #8). > > > > The crash dumps are more for posterity, when someone searches for a > > problem they see. Search engines tend to pick those up and it might > > point those people in the right direction. > > > > Also, it is good to include information about what triggered the crash, > > e.g. which USB device on which hardware, in case this is needed in the > > future. > > > > > I think the main reason all this stuff is broken and we're finding out > > > now is that u-boot has traditionally been used in embedded devices with > > > fairly narrow use cases for USB > > > > Yes > > > > >, and now we're running it on > > > workstation-grade laptops and desktops and people are plugging in all > > > kinds of normal USB devices and expecting their bootloader not to freak > > > out with them (even though most of the time it doesn't need to talk to > > > them). It's really easy to run into this stuff when that's your use case. > > > > It is really appreciated to see people fix things like this stuff, thanks !
[PATCH] arm: kirkwood: Enable bootstd for Zyxel NSA310S board
Enable bootstd for Zyxel NSA310S board, and remove distroboot. Signed-off-by: Tony Dinh --- configs/nsa310s_defconfig | 3 ++- include/configs/nsa310s.h | 17 ++--- 2 files changed, 4 insertions(+), 16 deletions(-) diff --git a/configs/nsa310s_defconfig b/configs/nsa310s_defconfig index ff4895622c..038ef42e9d 100644 --- a/configs/nsa310s_defconfig +++ b/configs/nsa310s_defconfig @@ -19,7 +19,8 @@ CONFIG_DEBUG_UART_CLOCK=16667 CONFIG_IDENT_STRING="\nZyXEL NSA310S/320S 1/2-Bay Power Media Server" CONFIG_SYS_LOAD_ADDR=0x80 CONFIG_DEBUG_UART=y -CONFIG_DISTRO_DEFAULTS=y +CONFIG_BOOTSTD_FULL=y +CONFIG_BOOTSTD_DEFAULTS=y CONFIG_BOOTDELAY=3 CONFIG_USE_PREBOOT=y # CONFIG_DISPLAY_BOARDINFO is not set diff --git a/include/configs/nsa310s.h b/include/configs/nsa310s.h index fa029a176b..8c4d03553d 100644 --- a/include/configs/nsa310s.h +++ b/include/configs/nsa310s.h @@ -1,6 +1,6 @@ /* SPDX-License-Identifier: GPL-2.0+ */ /* - * Copyright (C) 2015, 2021-2022 Tony Dinh + * Copyright (C) 2015, 2021-2023 Tony Dinh * Copyright (C) 2015 * Gerald Kerma * Luka Perkov @@ -15,14 +15,6 @@ */ #include "mv-common.h" -/* Include the common distro boot environment */ -#ifndef CONFIG_SPL_BUILD - -#define BOOT_TARGET_DEVICES(func) \ - func(USB, usb, 0) \ - func(SATA, sata, 0) \ - func(DHCP, dhcp, na) - #define KERNEL_ADDR_R __stringify(0x80) #define FDT_ADDR_R __stringify(0x2c0) #define RAMDISK_ADDR_R __stringify(0x0110) @@ -34,16 +26,11 @@ "ramdisk_addr_r=" RAMDISK_ADDR_R "\0" \ "scriptaddr=" SCRIPT_ADDR_R "\0" -#include - #define CFG_EXTRA_ENV_SETTINGS \ "console=console=ttyS0,115200\0" \ "kernel=/boot/zImage\0" \ "fdt=/boot/nsa310s.dtb\0" \ "bootargs_root=ubi.mtd=3 root=ubi0:rootfs rootfstype=ubifs rw\0" \ - LOAD_ADDRESS_ENV_SETTINGS \ - BOOTENV - -#endif /* CONFIG_SPL_BUILD */ + LOAD_ADDRESS_ENV_SETTINGS #endif /* _CONFIG_NSA310S_H */ -- 2.39.2
[PATCH] arm: kirkwood: Enable bootstd for Pogo V4 board
Enable bootstd for Pogo V4 board, and remove distroboot. Signed-off-by: Tony Dinh --- configs/pogo_v4_defconfig | 3 ++- include/configs/pogo_v4.h | 35 ++- 2 files changed, 4 insertions(+), 34 deletions(-) diff --git a/configs/pogo_v4_defconfig b/configs/pogo_v4_defconfig index 2747c3c72d..ff6411d894 100644 --- a/configs/pogo_v4_defconfig +++ b/configs/pogo_v4_defconfig @@ -17,7 +17,8 @@ CONFIG_IDENT_STRING="\nPogoplug V4" CONFIG_SYS_LOAD_ADDR=0x80 CONFIG_PCI=y CONFIG_LTO=y -CONFIG_DISTRO_DEFAULTS=y +CONFIG_BOOTSTD_FULL=y +CONFIG_BOOTSTD_DEFAULTS=y CONFIG_BOOTSTAGE=y CONFIG_SHOW_BOOT_PROGRESS=y CONFIG_BOOTDELAY=10 diff --git a/include/configs/pogo_v4.h b/include/configs/pogo_v4.h index 3371579023..d5003538da 100644 --- a/include/configs/pogo_v4.h +++ b/include/configs/pogo_v4.h @@ -1,6 +1,6 @@ /* SPDX-License-Identifier: GPL-2.0+ */ /* - * Copyright (C) 2014-2022 Tony Dinh + * Copyright (C) 2014-2023 Tony Dinh * * Based on * Copyright (C) 2012 @@ -21,33 +21,6 @@ */ #include "mv-common.h" -/* Include the common distro boot environment */ -#ifndef CONFIG_SPL_BUILD - -#ifdef CONFIG_MMC -#define BOOT_TARGET_DEVICES_MMC(func) func(MMC, mmc, 0) -#else -#define BOOT_TARGET_DEVICES_MMC(func) -#endif - -#ifdef CONFIG_SATA -#define BOOT_TARGET_DEVICES_SATA(func) func(SATA, sata, 0) -#else -#define BOOT_TARGET_DEVICES_SATA(func) -#endif - -#ifdef CONFIG_USB_STORAGE -#define BOOT_TARGET_DEVICES_USB(func) func(USB, usb, 0) -#else -#define BOOT_TARGET_DEVICES_USB(func) -#endif - -#define BOOT_TARGET_DEVICES(func) \ - BOOT_TARGET_DEVICES_MMC(func) \ - BOOT_TARGET_DEVICES_USB(func) \ - BOOT_TARGET_DEVICES_SATA(func) \ - func(DHCP, dhcp, na) - #define KERNEL_ADDR_R __stringify(0x80) #define FDT_ADDR_R __stringify(0x2c0) #define RAMDISK_ADDR_R __stringify(0x0110) @@ -59,14 +32,10 @@ "ramdisk_addr_r=" RAMDISK_ADDR_R "\0" \ "scriptaddr=" SCRIPT_ADDR_R "\0" -#include - #define CFG_EXTRA_ENV_SETTINGS \ LOAD_ADDRESS_ENV_SETTINGS \ "fdtfile=" CONFIG_DEFAULT_DEVICE_TREE ".dtb\0" \ "mtdparts=" CONFIG_MTDPARTS_DEFAULT "\0" \ - "console=ttyS0,115200\0" \ - BOOTENV -#endif /* CONFIG_SPL_BUILD */ + "console=ttyS0,115200\0" #endif /* _CONFIG_POGO_V4_H */ -- 2.39.2
Re: [PATCH v5] bootstd: sata: Add bootstd support for ahci sata
On Mon, Oct 23, 2023 at 12:08 PM Tom Rini wrote: > > On Wed, 11 Oct 2023 13:26:42 -0700, Tony Dinh wrote: > > > Add ahci sata bootdev and corresponding hunting function. > > > > > > I know this is recent but given their importance, applied to u-boot/master, > thanks! > > -- > Tom > Thanks Tom! All the best, Tony
Re: When do we merge bug fixes and new functionality
Hi Tom, Simon, Stefan, On Tue, Oct 10, 2023 at 12:14 AM Tony Dinh wrote: > > Hi Tom, Simon, Stefan, > > I have a few people waiting for these patches to get merged. So I hope > you don't mind (I'm not sure about the merging schedule), I'd bug you > guys about these patches. Wondering if these will be in v2024.01-rc1 > or subsequence rc? > > bootstd: sata: bootdev scanning for ahci sata with no drive attached > https://patchwork.ozlabs.org/project/uboot/patch/20231007033429.25109-1-mibo...@gmail.com/ > > bootstd: use ARCH_DMA_MINALIGN in memalign() when allocating memory > https://patchwork.ozlabs.org/project/uboot/patch/20230919212722.16216-1-mibo...@gmail.com/ > > bootstd: sata: Add bootstd support for ahci sata > https://patchwork.ozlabs.org/project/uboot/patch/20230917230649.30357-1-mibo...@gmail.com/ > > arm: mvebu: Enable bootstd for Synology DS116 board > https://patchwork.ozlabs.org/project/uboot/patch/20231007213548.20276-1-mibo...@gmail.com/ > > arm: mvebu: Enable bootstd for Thecus N2350 board > https://patchwork.ozlabs.org/project/uboot/patch/20231007220814.30783-1-mibo...@gmail.com/ > > arm: mvebu: sata_mv: Add bootstd hook to enable sata_bootdev > https://patchwork.ozlabs.org/project/uboot/patch/20230906052242.21568-1-mibo...@gmail.com/ > > arm: kirkwood: Add support for ZyXEL NSA325 board > https://patchwork.ozlabs.org/project/uboot/patch/2023082600.7827-1-mibo...@gmail.com/ > > arm: kirkwood: Pogo v4: Enable LTO > https://patchwork.ozlabs.org/project/uboot/patch/20230824190713.30866-1-mibo...@gmail.com/ Thanks Stefan and Tom for picking up most of these patches. There are 2 remaining patches that hopefully Simon or Tom will pick them up? bootstd: sata: bootdev scanning for ahci sata with no drive attached https://patchwork.ozlabs.org/project/uboot/patch/20231007033429.25109-1-mibo...@gmail.com/ [v5] bootstd: sata: Add bootstd support for ahci sata https://patchwork.ozlabs.org/project/uboot/patch/20231011202643.9194-1-mibo...@gmail.com/ All the best, Tony
[RESEND PATCH] arm: kirkwood: Pogo v4: Enable LTO
Enable building Pogo V4 u-boot image with LTO, which results in about 30K reduction in size. Rebased to latest master and resend. Signed-off-by: Tony Dinh --- configs/pogo_v4_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/pogo_v4_defconfig b/configs/pogo_v4_defconfig index cbbade3c0c..fd62146ed3 100644 --- a/configs/pogo_v4_defconfig +++ b/configs/pogo_v4_defconfig @@ -15,6 +15,7 @@ CONFIG_ENV_OFFSET=0xC CONFIG_DEFAULT_DEVICE_TREE="kirkwood-pogoplug-series-4" CONFIG_IDENT_STRING="\nPogoplug V4" CONFIG_SYS_LOAD_ADDR=0x80 +CONFIG_LTO=y CONFIG_PCI=y CONFIG_DISTRO_DEFAULTS=y CONFIG_BOOTSTAGE=y -- 2.39.2
[PATCH v5] bootstd: sata: Add bootstd support for ahci sata
Add ahci sata bootdev and corresponding hunting function.
Signed-off-by: Tony Dinh
---
Changes in v5:
- In bootmeth_script script_boot(), it's unnecessary to check for ret so
remove it. While we're here, also initialize ret in declaration.
Changes in v4:
- Revise logic in bootmeth_script() to set devtype to sata for non-scsi
SATA device
- Rewrite sata_rescan() logic to properly remove all devices before probing
- Add description to sata_rescan() header
Changes in v3:
- Correct drivers/ata/Makefile to compile sata_bootdev only if
ahci sata is enabled.
Changes in v2:
- set devtype to sata in bootmeth_script for non-scsi SATA device.
boot/bootmeth_script.c | 16 +++---
drivers/ata/Makefile | 2 +-
drivers/ata/sata.c | 32
drivers/ata/sata_bootdev.c | 62 ++
include/sata.h | 6
5 files changed, 113 insertions(+), 5 deletions(-)
create mode 100644 drivers/ata/sata_bootdev.c
diff --git a/boot/bootmeth_script.c b/boot/bootmeth_script.c
index 345114dabf..06340e43d2 100644
--- a/boot/bootmeth_script.c
+++ b/boot/bootmeth_script.c
@@ -188,12 +188,20 @@ static int script_boot(struct udevice *dev, struct
bootflow *bflow)
{
struct blk_desc *desc = dev_get_uclass_plat(bflow->blk);
ulong addr;
- int ret;
+ int ret = 0;
- if (desc->uclass_id == UCLASS_USB)
+ if (desc->uclass_id == UCLASS_USB) {
ret = env_set("devtype", "usb");
- else
- ret = env_set("devtype", blk_get_devtype(bflow->blk));
+ } else {
+ /* If the uclass is AHCI, but the driver is ATA
+* (not scsi), set devtype to sata
+*/
+ if (IS_ENABLED(CONFIG_SATA) &&
+ desc->uclass_id == UCLASS_AHCI)
+ ret = env_set("devtype", "sata");
+ else
+ ret = env_set("devtype", blk_get_devtype(bflow->blk));
+ }
if (!ret)
ret = env_set_hex("devnum", desc->devnum);
if (!ret)
diff --git a/drivers/ata/Makefile b/drivers/ata/Makefile
index 6e30180b8b..0b6f91098a 100644
--- a/drivers/ata/Makefile
+++ b/drivers/ata/Makefile
@@ -10,7 +10,7 @@ obj-$(CONFIG_SCSI_AHCI) += ahci.o
obj-$(CONFIG_DWC_AHSATA) += dwc_ahsata.o
obj-$(CONFIG_FSL_SATA) += fsl_sata.o
obj-$(CONFIG_LIBATA) += libata.o
-obj-$(CONFIG_SATA) += sata.o
+obj-$(CONFIG_SATA) += sata.o sata_bootdev.o
obj-$(CONFIG_SATA_CEVA) += sata_ceva.o
obj-$(CONFIG_SATA_MV) += sata_mv.o
obj-$(CONFIG_SATA_SIL) += sata_sil.o
diff --git a/drivers/ata/sata.c b/drivers/ata/sata.c
index ce3e9b5a40..f126b84e05 100644
--- a/drivers/ata/sata.c
+++ b/drivers/ata/sata.c
@@ -15,6 +15,8 @@
#include
#include
#include
+#include
+#include
#ifndef CONFIG_AHCI
struct blk_desc sata_dev_desc[CONFIG_SYS_SATA_MAX_DEVICE];
@@ -50,6 +52,36 @@ int sata_scan(struct udevice *dev)
return ops->scan(dev);
}
+int sata_rescan(bool verbose)
+{
+ int ret;
+ struct udevice *dev;
+
+ if (verbose)
+ printf("Removing devices on SATA bus...\n");
+
+ blk_unbind_all(UCLASS_AHCI);
+
+ ret = uclass_find_first_device(UCLASS_AHCI, );
+ if (ret || !dev) {
+ printf("Cannot find SATA device (err=%d)\n", ret);
+ return -ENOSYS;
+ }
+
+ ret = device_remove(dev, DM_REMOVE_NORMAL);
+ if (ret) {
+ printf("Cannot remove SATA device '%s' (err=%d)\n", dev->name,
ret);
+ return -ENOSYS;
+ }
+
+ if (verbose)
+ printf("Rescanning SATA bus for devices...\n");
+
+ ret = uclass_probe_all(UCLASS_AHCI);
+
+ return ret;
+}
+
#ifndef CONFIG_AHCI
#ifdef CONFIG_PARTITIONS
struct blk_desc *sata_get_dev(int dev)
diff --git a/drivers/ata/sata_bootdev.c b/drivers/ata/sata_bootdev.c
new file mode 100644
index 00..f638493ce0
--- /dev/null
+++ b/drivers/ata/sata_bootdev.c
@@ -0,0 +1,62 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Bootdev for sata
+ *
+ * Copyright 2023 Tony Dinh
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+static int sata_bootdev_bind(struct udevice *dev)
+{
+ struct bootdev_uc_plat *ucp = dev_get_uclass_plat(dev);
+
+ ucp->prio = BOOTDEVP_4_SCAN_FAST;
+
+ return 0;
+}
+
+static int sata_bootdev_hunt(struct bootdev_hunter *info, bool show)
+{
+ int ret;
+
+ if (IS_ENABLED(CONFIG_PCI)) {
+ ret = pci_init();
+ if (ret)
+ return ret;
+ }
+
+ ret = sata_rescan(true);
+ if (ret)
+ return ret;
+
+ return 0;
+}
+
+struct bootdev_ops sata_bootdev_ops = {
+};
+
+static const struct udevice_id sata_bootdev_ids[] = {
+ { .compatible = "u-bo
Re: [PATCH v4] bootstd: sata: Add bootstd support for ahci sata
Hi Tom,
On Wed, Oct 11, 2023 at 7:43 AM Tom Rini wrote:
>
> On Sun, Sep 17, 2023 at 04:06:48PM -0700, Tony Dinh wrote:
> > Add ahci sata bootdev and corresponding hunting function.
> >
> > Signed-off-by: Tony Dinh
> > Reviewed-by: Simon Glass
> > ---
> >
> > Changes in v4:
> > - Revise logic in bootmeth_script() to set devtype to sata for non-scsi
> > SATA device
> > - Rewrite sata_rescan() logic to properly remove all devices before probing
> > - Add description to sata_rescan() header
> >
> > Changes in v3:
> > - Correct drivers/ata/Makefile to compile sata_bootdev only if
> > ahci sata is enabled.
> >
> > Changes in v2:
> > - set devtype to sata in bootmeth_script for non-scsi SATA device.
> >
> > boot/bootmeth_script.c | 14 +++--
> > drivers/ata/Makefile | 2 +-
> > drivers/ata/sata.c | 32
> > drivers/ata/sata_bootdev.c | 62 ++
> > include/sata.h | 6
> > 5 files changed, 112 insertions(+), 4 deletions(-)
> > create mode 100644 drivers/ata/sata_bootdev.c
> >
> > diff --git a/boot/bootmeth_script.c b/boot/bootmeth_script.c
> > index 58c57a2d4b..96e0ec5efa 100644
> > --- a/boot/bootmeth_script.c
> > +++ b/boot/bootmeth_script.c
> > @@ -190,10 +190,18 @@ static int script_boot(struct udevice *dev, struct
> > bootflow *bflow)
> > ulong addr;
> > int ret;
> >
> > - if (desc->uclass_id == UCLASS_USB)
> > + if (desc->uclass_id == UCLASS_USB) {
> > ret = env_set("devtype", "usb");
> > - else
> > - ret = env_set("devtype", blk_get_devtype(bflow->blk));
> > + } else {
> > + /* If the uclass is AHCI, but the driver is ATA
> > + * (not scsi), set devtype to sata
> > + */
> > + if (!ret && IS_ENABLED(CONFIG_SATA) &&
>
> This is a warning here as ret is uninitalized at this point.
Thanks! I'll send the v5 patch.
All the best ,
Tony
>
> --
> Tom
When do we merge bug fixes and new functionality
Hi Tom, Simon, Stefan, I have a few people waiting for these patches to get merged. So I hope you don't mind (I'm not sure about the merging schedule), I'd bug you guys about these patches. Wondering if these will be in v2024.01-rc1 or subsequence rc? bootstd: sata: bootdev scanning for ahci sata with no drive attached https://patchwork.ozlabs.org/project/uboot/patch/20231007033429.25109-1-mibo...@gmail.com/ bootstd: use ARCH_DMA_MINALIGN in memalign() when allocating memory https://patchwork.ozlabs.org/project/uboot/patch/20230919212722.16216-1-mibo...@gmail.com/ bootstd: sata: Add bootstd support for ahci sata https://patchwork.ozlabs.org/project/uboot/patch/20230917230649.30357-1-mibo...@gmail.com/ arm: mvebu: Enable bootstd for Synology DS116 board https://patchwork.ozlabs.org/project/uboot/patch/20231007213548.20276-1-mibo...@gmail.com/ arm: mvebu: Enable bootstd for Thecus N2350 board https://patchwork.ozlabs.org/project/uboot/patch/20231007220814.30783-1-mibo...@gmail.com/ arm: mvebu: sata_mv: Add bootstd hook to enable sata_bootdev https://patchwork.ozlabs.org/project/uboot/patch/20230906052242.21568-1-mibo...@gmail.com/ arm: kirkwood: Add support for ZyXEL NSA325 board https://patchwork.ozlabs.org/project/uboot/patch/2023082600.7827-1-mibo...@gmail.com/ arm: kirkwood: Pogo v4: Enable LTO https://patchwork.ozlabs.org/project/uboot/patch/20230824190713.30866-1-mibo...@gmail.com/ All the best, Tony
[PATCH] arm: mvebu: Enable bootstd for Thecus N2350 board
Enable bootstd for Thecus N2350 board, and remove distroboot. Signed-off-by: Tony Dinh --- configs/n2350_defconfig | 3 ++- include/configs/n2350.h | 12 +--- 2 files changed, 3 insertions(+), 12 deletions(-) diff --git a/configs/n2350_defconfig b/configs/n2350_defconfig index 109f0e10e9..07135742d3 100644 --- a/configs/n2350_defconfig +++ b/configs/n2350_defconfig @@ -29,7 +29,8 @@ CONFIG_ENV_ADDR=0x10 CONFIG_PCI=y CONFIG_DEBUG_UART=y CONFIG_AHCI=y -CONFIG_DISTRO_DEFAULTS=y +CONFIG_BOOTSTD_FULL=y +CONFIG_BOOTSTD_DEFAULTS=y CONFIG_BOOTDELAY=10 CONFIG_USE_PREBOOT=y CONFIG_SYS_CONSOLE_INFO_QUIET=y diff --git a/include/configs/n2350.h b/include/configs/n2350.h index 92b2270236..d8a9814d3e 100644 --- a/include/configs/n2350.h +++ b/include/configs/n2350.h @@ -20,15 +20,8 @@ */ #include "mv-common.h" -/* Include the common distro boot environment */ #ifndef CONFIG_SPL_BUILD -#define BOOT_TARGET_DEVICES(func) \ - func(SCSI, scsi, 0) \ - func(USB, usb, 0) \ - func(PXE, pxe, na) \ - func(DHCP, dhcp, na) - #define KERNEL_ADDR_R __stringify(0x100) #define FDT_ADDR_R __stringify(0x200) #define RAMDISK_ADDR_R __stringify(0x220) @@ -42,14 +35,11 @@ "scriptaddr=" SCRIPT_ADDR_R "\0" \ "pxefile_addr_r=" PXEFILE_ADDR_R "\0" -#include - #define CFG_EXTRA_ENV_SETTINGS \ RELOCATION_LIMITS_ENV_SETTINGS \ LOAD_ADDRESS_ENV_SETTINGS \ "fdtfile=" CONFIG_DEFAULT_DEVICE_TREE ".dtb\0" \ - "console=ttyS0,115200\0" \ - BOOTENV + "console=ttyS0,115200\0" #endif /* CONFIG_SPL_BUILD */ -- 2.39.2
[PATCH] arm: mvebu: Enable bootstd for Synology DS116 board
Enable bootstd for Synology DS116 board, and remove distroboot. Signed-off-by: Tony Dinh --- configs/ds116_defconfig | 3 ++- include/configs/ds116.h | 12 +--- 2 files changed, 3 insertions(+), 12 deletions(-) diff --git a/configs/ds116_defconfig b/configs/ds116_defconfig index 0cd546c223..2437be73cd 100644 --- a/configs/ds116_defconfig +++ b/configs/ds116_defconfig @@ -28,7 +28,8 @@ CONFIG_SYS_LOAD_ADDR=0x80 CONFIG_PCI=y CONFIG_DEBUG_UART=y CONFIG_AHCI=y -CONFIG_DISTRO_DEFAULTS=y +CONFIG_BOOTSTD_FULL=y +CONFIG_BOOTSTD_DEFAULTS=y CONFIG_BOOTDELAY=10 CONFIG_USE_PREBOOT=y CONFIG_SYS_CONSOLE_INFO_QUIET=y diff --git a/include/configs/ds116.h b/include/configs/ds116.h index 031f4f6afc..0883ec4d53 100644 --- a/include/configs/ds116.h +++ b/include/configs/ds116.h @@ -20,15 +20,8 @@ */ #include "mv-common.h" -/* Include the common distro boot environment */ #ifndef CONFIG_SPL_BUILD -#define BOOT_TARGET_DEVICES(func) \ - func(USB, usb, 0) \ - func(SCSI, scsi, 0) \ - func(PXE, pxe, na) \ - func(DHCP, dhcp, na) - #define KERNEL_ADDR_R __stringify(0x100) #define FDT_ADDR_R __stringify(0x200) #define RAMDISK_ADDR_R __stringify(0x220) @@ -42,14 +35,11 @@ "scriptaddr=" SCRIPT_ADDR_R "\0" \ "pxefile_addr_r=" PXEFILE_ADDR_R "\0" -#include - #define CFG_EXTRA_ENV_SETTINGS \ RELOCATION_LIMITS_ENV_SETTINGS \ LOAD_ADDRESS_ENV_SETTINGS \ "fdtfile=" CONFIG_DEFAULT_DEVICE_TREE ".dtb\0" \ - "console=ttyS0,115200\0" \ - BOOTENV + "console=ttyS0,115200\0" #endif /* CONFIG_SPL_BUILD */ -- 2.39.2
[RESEND PATCH] bootstd: sata: bootdev scanning for ahci sata with no drive attached
It's normal to have no SATA drive attached to the controller, so return a
successful status when there is no block device found after probing.
Note: this patch depends on the previous patch
https://patchwork.ozlabs.org/project/uboot/patch/20230917230649.30357-1-mibo...@gmail.com/
Resend the right patch.
Signed-off-by: Tony Dinh
---
drivers/ata/sata.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/ata/sata.c b/drivers/ata/sata.c
index f126b84e05..dcb5fcf476 100644
--- a/drivers/ata/sata.c
+++ b/drivers/ata/sata.c
@@ -79,6 +79,12 @@ int sata_rescan(bool verbose)
ret = uclass_probe_all(UCLASS_AHCI);
+ if (ret == -ENODEV) {
+ if (verbose)
+ printf("No SATA block device found\n");
+ return 0;
+ }
+
return ret;
}
--
2.39.2
Re: [PATCH] bootstd: sata: bootdev scanning for ahci sata with no drive attached
On Fri, Oct 6, 2023 at 5:49 PM Tony Dinh wrote:
>
> It's normal to have no SATA drive attached to the controller, so return a
> successful status when there is no block device found after probing.
>
> Note: this patch depends on the previous patch
> https://patchwork.ozlabs.org/project/uboot/patch/20230917230649.30357-1-mibo...@gmail.com/
>
> Signed-off-by: Tony Dinh
> ---
>
> drivers/ata/sata.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/ata/sata.c b/drivers/ata/sata.c
> index f126b84e05..59c40a829f 100644
> --- a/drivers/ata/sata.c
> +++ b/drivers/ata/sata.c
> @@ -79,6 +79,11 @@ int sata_rescan(bool verbose)
>
> ret = uclass_probe_all(UCLASS_AHCI);
>
> + if (verbose && ret == -ENODEV) {
> + printf("No SATA block device found\n");
> + return 0;
> + }
> +
> return ret;
> }
>
> --
> 2.39.2
>
Sorry, I need to resend this patch (fat finger).
All the best,
Tony
[PATCH] bootstd: sata: bootdev scanning for ahci sata with no drive attached
It's normal to have no SATA drive attached to the controller, so return a
successful status when there is no block device found after probing.
Note: this patch depends on the previous patch
https://patchwork.ozlabs.org/project/uboot/patch/20230917230649.30357-1-mibo...@gmail.com/
Signed-off-by: Tony Dinh
---
drivers/ata/sata.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/ata/sata.c b/drivers/ata/sata.c
index f126b84e05..59c40a829f 100644
--- a/drivers/ata/sata.c
+++ b/drivers/ata/sata.c
@@ -79,6 +79,11 @@ int sata_rescan(bool verbose)
ret = uclass_probe_all(UCLASS_AHCI);
+ if (verbose && ret == -ENODEV) {
+ printf("No SATA block device found\n");
+ return 0;
+ }
+
return ret;
}
--
2.39.2
Re: bootstd: Scanning for USB bootflow will remove existing SCSI bootflow
Hi Simon, On Mon, Oct 2, 2023 at 12:25 PM Tony Dinh wrote: > > Hi Simon, > > On Sun, Oct 1, 2023 at 6:22 PM Simon Glass wrote: > > > > Hi Tony, > > > > On Tue, 26 Sept 2023 at 13:40, Tony Dinh wrote: > > > > > > Hi Simon, > > > > > > On Tue, Sep 26, 2023 at 4:37 AM Simon Glass wrote: > > > > > > > > Hi Tony, > > > > > > > > On Mon, 25 Sept 2023 at 14:02, Tony Dinh wrote: > > > > > > > > > > Hi Simon, > > > > > > > > > > Here is an observation during testing the bootflow command. > > > > > > > > > > If there is a SCSI bootflow, scanning for USB bootflow will remove > > > > > that existing > > > > > SCSI bootflow. To bring it back, I scanned for SCSI bootflow again, > > > > > and it was > > > > > back to normal. Perhaps there is some kind of indexing problem? > > > > > > > > Yes that's right. The 'botflow scan' command is not additive. The > > > > first thing it does is removing existing bootflows. > > > > > > Thanks for clarifying that. I assumed it is additive, because the > > > existing USB bootflow was not removed when I did a "bootflow scan > > > scsi" immediately after (see the end of the log). > > > > Yes, but I'm not sure what is going on there. Perhaps it is a bug? > > When you scan SCSI it should not also scan USB. > > Yes, it looks like a bug. I think I can see the problem and am working > on a patch. Just to let you know, I'm out of time to work on this topic. I will revisit it some other time, if you have not already tracked it down. All the best, Tony > > All the best, > Tony > > > > > > Regards, > > SImon
Re: bootstd: Scanning for USB bootflow will remove existing SCSI bootflow
Hi Simon, On Sun, Oct 1, 2023 at 6:22 PM Simon Glass wrote: > > Hi Tony, > > On Tue, 26 Sept 2023 at 13:40, Tony Dinh wrote: > > > > Hi Simon, > > > > On Tue, Sep 26, 2023 at 4:37 AM Simon Glass wrote: > > > > > > Hi Tony, > > > > > > On Mon, 25 Sept 2023 at 14:02, Tony Dinh wrote: > > > > > > > > Hi Simon, > > > > > > > > Here is an observation during testing the bootflow command. > > > > > > > > If there is a SCSI bootflow, scanning for USB bootflow will remove that > > > > existing > > > > SCSI bootflow. To bring it back, I scanned for SCSI bootflow again, and > > > > it was > > > > back to normal. Perhaps there is some kind of indexing problem? > > > > > > Yes that's right. The 'botflow scan' command is not additive. The > > > first thing it does is removing existing bootflows. > > > > Thanks for clarifying that. I assumed it is additive, because the > > existing USB bootflow was not removed when I did a "bootflow scan > > scsi" immediately after (see the end of the log). > > Yes, but I'm not sure what is going on there. Perhaps it is a bug? > When you scan SCSI it should not also scan USB. Yes, it looks like a bug. I think I can see the problem and am working on a patch. All the best, Tony > > Regards, > SImon
Re: bootstd: Scanning for USB bootflow will remove existing SCSI bootflow
Hi Simon, On Tue, Sep 26, 2023 at 4:37 AM Simon Glass wrote: > > Hi Tony, > > On Mon, 25 Sept 2023 at 14:02, Tony Dinh wrote: > > > > Hi Simon, > > > > Here is an observation during testing the bootflow command. > > > > If there is a SCSI bootflow, scanning for USB bootflow will remove that > > existing > > SCSI bootflow. To bring it back, I scanned for SCSI bootflow again, and it > > was > > back to normal. Perhaps there is some kind of indexing problem? > > Yes that's right. The 'botflow scan' command is not additive. The > first thing it does is removing existing bootflows. Thanks for clarifying that. I assumed it is additive, because the existing USB bootflow was not removed when I did a "bootflow scan scsi" immediately after (see the end of the log). Thanks, Tony > > > > > Please see the log below after the break. > > > > All the best, > > Tony > > > > === > > > > > > U-Boot 2023.10-rc4-tld-1-00044-g9c21b2a350-dirty (Sep 18 2023 - 12:16:59 > > -0700) > > Thecus N2350 > > > > > > > > N2350 > env def -a > > ## Resetting to default environment > > > > N2350 > bootflow scan scsi > > pcie0.0: Link down > > pcie1.0: Link down > > scanning bus for devices... > > SATA link 0 timeout. > > Target spinup took 0 ms. > > AHCI 0001. 32 slots 2 ports 6 Gbps 0x3 impl SATA mode > > flags: 64bit ncq led only pmp fbss pio slum part sxs > > Device 0: (1:0) Vendor: ATA Prod.: ST750LX003-1AC15 Rev: SM12 > > Type: Hard Disk > > Capacity: 715404.8 MB = 698.6 GB (1465149168 x 512) > > ** File not found /boot/boot.bmp ** > > > > N2350 > bootflow l > > Showing all bootflows > > Seq Method State UclassPart Name Filename > > --- --- -- > > > > 0 script ready scsi 1 ahci_scsi.id1lun0.bootdev > > /boot/boot.scr > > --- --- -- > > > > (1 bootflow, 1 valid) > > > > N2350 > bootflow scan usb > > Bus usb@58000: USB EHCI 1.00 > > Bus usb3@f: MVEBU XHCI INIT controller @ 0xf10f4000 > > Register 2000120 NbrPorts 2 > > Starting the controller > > USB XHCI 1.00 > > Bus usb3@f8000: MVEBU XHCI INIT controller @ 0xf10fc000 > > Register 2000120 NbrPorts 2 > > Starting the controller > > USB XHCI 1.00 > > scanning bus usb@58000 for devices... 1 USB Device(s) found > > scanning bus usb3@f for devices... 1 USB Device(s) found > > scanning bus usb3@f8000 for devices... 2 USB Device(s) found > > ** File not found /boot/boot.bmp ** > > > > N2350 > bootflow l > > Showing all bootflows > > Seq Method State UclassPart Name Filename > > --- --- -- > > > > 0 script ready usb_mass_1 usb_mass_storage.lun0.boo > > /boot/boot.scr > > --- --- -- > > > > (1 bootflow, 1 valid) > > > > N2350 > bootflow scan scsi > > ** File not found /boot/boot.bmp ** > > ** File not found /boot/boot.bmp ** > > > > N2350 > bootflow l > > Showing all bootflows > > Seq Method State UclassPart Name Filename > > --- --- -- > > > > 0 script ready scsi 1 ahci_scsi.id1lun0.bootdev > > /boot/boot.scr > > 1 script ready usb_mass_1 usb_mass_storage.lun0.boo > > /boot/boot.scr > > --- --- -- > > > > (2 bootflows, 2 valid) > > > > > > Regards, > Simon
bootstd: Scanning for USB bootflow will remove existing SCSI bootflow
Hi Simon, Here is an observation during testing the bootflow command. If there is a SCSI bootflow, scanning for USB bootflow will remove that existing SCSI bootflow. To bring it back, I scanned for SCSI bootflow again, and it was back to normal. Perhaps there is some kind of indexing problem? Please see the log below after the break. All the best, Tony === U-Boot 2023.10-rc4-tld-1-00044-g9c21b2a350-dirty (Sep 18 2023 - 12:16:59 -0700) Thecus N2350 N2350 > env def -a ## Resetting to default environment N2350 > bootflow scan scsi pcie0.0: Link down pcie1.0: Link down scanning bus for devices... SATA link 0 timeout. Target spinup took 0 ms. AHCI 0001. 32 slots 2 ports 6 Gbps 0x3 impl SATA mode flags: 64bit ncq led only pmp fbss pio slum part sxs Device 0: (1:0) Vendor: ATA Prod.: ST750LX003-1AC15 Rev: SM12 Type: Hard Disk Capacity: 715404.8 MB = 698.6 GB (1465149168 x 512) ** File not found /boot/boot.bmp ** N2350 > bootflow l Showing all bootflows Seq Method State UclassPart Name Filename --- --- -- 0 script ready scsi 1 ahci_scsi.id1lun0.bootdev /boot/boot.scr --- --- -- (1 bootflow, 1 valid) N2350 > bootflow scan usb Bus usb@58000: USB EHCI 1.00 Bus usb3@f: MVEBU XHCI INIT controller @ 0xf10f4000 Register 2000120 NbrPorts 2 Starting the controller USB XHCI 1.00 Bus usb3@f8000: MVEBU XHCI INIT controller @ 0xf10fc000 Register 2000120 NbrPorts 2 Starting the controller USB XHCI 1.00 scanning bus usb@58000 for devices... 1 USB Device(s) found scanning bus usb3@f for devices... 1 USB Device(s) found scanning bus usb3@f8000 for devices... 2 USB Device(s) found ** File not found /boot/boot.bmp ** N2350 > bootflow l Showing all bootflows Seq Method State UclassPart Name Filename --- --- -- 0 script ready usb_mass_1 usb_mass_storage.lun0.boo /boot/boot.scr --- --- -- (1 bootflow, 1 valid) N2350 > bootflow scan scsi ** File not found /boot/boot.bmp ** ** File not found /boot/boot.bmp ** N2350 > bootflow l Showing all bootflows Seq Method State UclassPart Name Filename --- --- -- 0 script ready scsi 1 ahci_scsi.id1lun0.bootdev /boot/boot.scr 1 script ready usb_mass_1 usb_mass_storage.lun0.boo /boot/boot.scr --- --- -- (2 bootflows, 2 valid)
Re: [PATCH] arm: mvebu: sata_mv: Add bootstd hook to enable sata_bootdev
Thanks Stefan!
All the best,
Tony
On Mon, Sep 25, 2023 at 1:14 AM Stefan Roese wrote:
>
> On 9/6/23 07:22, Tony Dinh wrote:
> > Add hook in sata_mv probe to enable bootstd bootdev.
> >
> > Note: bootdev_setup_for_sibling_blk() invocation is a noop if bootsd is
> > not enabled for ahci sata yet.
> >
> > Signed-off-by: Tony Dinh
>
> Reviewed-by: Stefan Roese
>
> Thanks,
> Stefan
>
> > ---
> >
> > drivers/ata/sata_mv.c | 8 +++-
> > 1 file changed, 7 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/ata/sata_mv.c b/drivers/ata/sata_mv.c
> > index 18c7a66db1..55a5365b5a 100644
> > --- a/drivers/ata/sata_mv.c
> > +++ b/drivers/ata/sata_mv.c
> > @@ -34,6 +34,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -1104,6 +1105,12 @@ static int sata_mv_probe(struct udevice *dev)
> > /* TODO: undo create */
> > continue;
> >
> > + ret = bootdev_setup_for_sibling_blk(blk, "sata_bootdev");
> > + if (ret) {
> > + printf("%s: Failed to create bootdev\n", __func__);
> > + continue;
> > + }
> > +
> > /* If we got here, the current SATA port was probed
> >* successfully, so set the probe status to successful.
> >*/
> > @@ -1116,7 +1123,6 @@ static int sata_mv_probe(struct udevice *dev)
> > static int sata_mv_scan(struct udevice *dev)
> > {
> > /* Nothing to do here */
> > -
> > return 0;
> > }
> >
>
> Viele Grüße,
> Stefan Roese
>
> --
> DENX Software Engineering GmbH, Managing Director: Erika Unter
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
Re: [PATCH] arm: mvebu: sata_mv: Add bootstd hook to enable sata_bootdev
Hi Simon,
On Sun, Sep 24, 2023 at 1:40 PM Simon Glass wrote:
>
> Hi Tony,
>
> On Tue, 5 Sept 2023 at 23:23, Tony Dinh wrote:
> >
> > Add hook in sata_mv probe to enable bootstd bootdev.
> >
> > Note: bootdev_setup_for_sibling_blk() invocation is a noop if bootsd is
> > not enabled for ahci sata yet.
> >
> > Signed-off-by: Tony Dinh
> > ---
> >
> > drivers/ata/sata_mv.c | 8 +++-
> > 1 file changed, 7 insertions(+), 1 deletion(-)
> >
>
> Reviewed-by: Simon Glass
>
> But please see below
>
> > diff --git a/drivers/ata/sata_mv.c b/drivers/ata/sata_mv.c
> > index 18c7a66db1..55a5365b5a 100644
> > --- a/drivers/ata/sata_mv.c
> > +++ b/drivers/ata/sata_mv.c
> > @@ -34,6 +34,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -1104,6 +1105,12 @@ static int sata_mv_probe(struct udevice *dev)
> > /* TODO: undo create */
> > continue;
> >
> > + ret = bootdev_setup_for_sibling_blk(blk, "sata_bootdev");
> > + if (ret) {
> > + printf("%s: Failed to create bootdev\n", __func__);
> > + continue;
> > + }
> > +
> > /* If we got here, the current SATA port was probed
> > * successfully, so set the probe status to successful.
> > */
> > @@ -1116,7 +1123,6 @@ static int sata_mv_probe(struct udevice *dev)
> > static int sata_mv_scan(struct udevice *dev)
> > {
> > /* Nothing to do here */
> > -
>
> You should leave this - the style is to put a newline before the final
> return in a function.
Thanks,
Tony
>
> > return 0;
> > }
> >
> > --
> > 2.39.2
> >
>
> Regards,
> Simon
Re: [PATCH] arm: mvebu: sata_mv: Add bootstd hook to enable sata_bootdev
Hi Stefan,
In case you forgot, please review this patch!
Thanks,
Tony
On Tue, Sep 5, 2023 at 10:23 PM Tony Dinh wrote:
>
> Add hook in sata_mv probe to enable bootstd bootdev.
>
> Note: bootdev_setup_for_sibling_blk() invocation is a noop if bootsd is
> not enabled for ahci sata yet.
>
> Signed-off-by: Tony Dinh
> ---
>
> drivers/ata/sata_mv.c | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/ata/sata_mv.c b/drivers/ata/sata_mv.c
> index 18c7a66db1..55a5365b5a 100644
> --- a/drivers/ata/sata_mv.c
> +++ b/drivers/ata/sata_mv.c
> @@ -34,6 +34,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -1104,6 +1105,12 @@ static int sata_mv_probe(struct udevice *dev)
> /* TODO: undo create */
> continue;
>
> + ret = bootdev_setup_for_sibling_blk(blk, "sata_bootdev");
> + if (ret) {
> + printf("%s: Failed to create bootdev\n", __func__);
> + continue;
> + }
> +
> /* If we got here, the current SATA port was probed
> * successfully, so set the probe status to successful.
> */
> @@ -1116,7 +1123,6 @@ static int sata_mv_probe(struct udevice *dev)
> static int sata_mv_scan(struct udevice *dev)
> {
> /* Nothing to do here */
> -
> return 0;
> }
>
> --
> 2.39.2
>
[PATCH] bootstd: use ARCH_DMA_MINALIGN in memalign() when allocating memory
Use ARCH_DMA_MINALIGN in memalign() when allocating memory to read the script
from the media.
Ref:
https://lore.kernel.org/u-boot/cajalify05f3cr4x4g2mvkppxnbefzrhq+5cngyn8ejpg8en...@mail.gmail.com/T/#m26daadc2463fe653b814a94e6309e5e6bb6be1d1
Note: this patch depends on the previous patch
https://patchwork.ozlabs.org/project/uboot/patch/20230917230649.30357-1-mibo...@gmail.com/
Signed-off-by: Tony Dinh
---
boot/bootmeth_script.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/boot/bootmeth_script.c b/boot/bootmeth_script.c
index 96e0ec5efa..de2e510da1 100644
--- a/boot/bootmeth_script.c
+++ b/boot/bootmeth_script.c
@@ -99,7 +99,7 @@ static int script_read_bootflow_file(struct udevice *bootstd,
if (!bflow->subdir)
return log_msg_ret("prefix", -ENOMEM);
- ret = bootmeth_alloc_file(bflow, 0x1, 1);
+ ret = bootmeth_alloc_file(bflow, 0x1, ARCH_DMA_MINALIGN);
if (ret)
return log_msg_ret("read", ret);
--
2.39.2
[PATCH v4] bootstd: sata: Add bootstd support for ahci sata
Add ahci sata bootdev and corresponding hunting function.
Signed-off-by: Tony Dinh
---
Changes in v4:
- Revise logic in bootmeth_script() to set devtype to sata for non-scsi
SATA device
- Rewrite sata_rescan() logic to properly remove all devices before probing
- Add description to sata_rescan() header
Changes in v3:
- Correct drivers/ata/Makefile to compile sata_bootdev only if
ahci sata is enabled.
Changes in v2:
- set devtype to sata in bootmeth_script for non-scsi SATA device.
boot/bootmeth_script.c | 14 +++--
drivers/ata/Makefile | 2 +-
drivers/ata/sata.c | 32
drivers/ata/sata_bootdev.c | 62 ++
include/sata.h | 6
5 files changed, 112 insertions(+), 4 deletions(-)
create mode 100644 drivers/ata/sata_bootdev.c
diff --git a/boot/bootmeth_script.c b/boot/bootmeth_script.c
index 58c57a2d4b..96e0ec5efa 100644
--- a/boot/bootmeth_script.c
+++ b/boot/bootmeth_script.c
@@ -190,10 +190,18 @@ static int script_boot(struct udevice *dev, struct
bootflow *bflow)
ulong addr;
int ret;
- if (desc->uclass_id == UCLASS_USB)
+ if (desc->uclass_id == UCLASS_USB) {
ret = env_set("devtype", "usb");
- else
- ret = env_set("devtype", blk_get_devtype(bflow->blk));
+ } else {
+ /* If the uclass is AHCI, but the driver is ATA
+* (not scsi), set devtype to sata
+*/
+ if (!ret && IS_ENABLED(CONFIG_SATA) &&
+ desc->uclass_id == UCLASS_AHCI)
+ ret = env_set("devtype", "sata");
+ else
+ ret = env_set("devtype", blk_get_devtype(bflow->blk));
+ }
if (!ret)
ret = env_set_hex("devnum", desc->devnum);
if (!ret)
diff --git a/drivers/ata/Makefile b/drivers/ata/Makefile
index 6e30180b8b..0b6f91098a 100644
--- a/drivers/ata/Makefile
+++ b/drivers/ata/Makefile
@@ -10,7 +10,7 @@ obj-$(CONFIG_SCSI_AHCI) += ahci.o
obj-$(CONFIG_DWC_AHSATA) += dwc_ahsata.o
obj-$(CONFIG_FSL_SATA) += fsl_sata.o
obj-$(CONFIG_LIBATA) += libata.o
-obj-$(CONFIG_SATA) += sata.o
+obj-$(CONFIG_SATA) += sata.o sata_bootdev.o
obj-$(CONFIG_SATA_CEVA) += sata_ceva.o
obj-$(CONFIG_SATA_MV) += sata_mv.o
obj-$(CONFIG_SATA_SIL) += sata_sil.o
diff --git a/drivers/ata/sata.c b/drivers/ata/sata.c
index ce3e9b5a40..f126b84e05 100644
--- a/drivers/ata/sata.c
+++ b/drivers/ata/sata.c
@@ -15,6 +15,8 @@
#include
#include
#include
+#include
+#include
#ifndef CONFIG_AHCI
struct blk_desc sata_dev_desc[CONFIG_SYS_SATA_MAX_DEVICE];
@@ -50,6 +52,36 @@ int sata_scan(struct udevice *dev)
return ops->scan(dev);
}
+int sata_rescan(bool verbose)
+{
+ int ret;
+ struct udevice *dev;
+
+ if (verbose)
+ printf("Removing devices on SATA bus...\n");
+
+ blk_unbind_all(UCLASS_AHCI);
+
+ ret = uclass_find_first_device(UCLASS_AHCI, );
+ if (ret || !dev) {
+ printf("Cannot find SATA device (err=%d)\n", ret);
+ return -ENOSYS;
+ }
+
+ ret = device_remove(dev, DM_REMOVE_NORMAL);
+ if (ret) {
+ printf("Cannot remove SATA device '%s' (err=%d)\n", dev->name,
ret);
+ return -ENOSYS;
+ }
+
+ if (verbose)
+ printf("Rescanning SATA bus for devices...\n");
+
+ ret = uclass_probe_all(UCLASS_AHCI);
+
+ return ret;
+}
+
#ifndef CONFIG_AHCI
#ifdef CONFIG_PARTITIONS
struct blk_desc *sata_get_dev(int dev)
diff --git a/drivers/ata/sata_bootdev.c b/drivers/ata/sata_bootdev.c
new file mode 100644
index 00..f638493ce0
--- /dev/null
+++ b/drivers/ata/sata_bootdev.c
@@ -0,0 +1,62 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Bootdev for sata
+ *
+ * Copyright 2023 Tony Dinh
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+static int sata_bootdev_bind(struct udevice *dev)
+{
+ struct bootdev_uc_plat *ucp = dev_get_uclass_plat(dev);
+
+ ucp->prio = BOOTDEVP_4_SCAN_FAST;
+
+ return 0;
+}
+
+static int sata_bootdev_hunt(struct bootdev_hunter *info, bool show)
+{
+ int ret;
+
+ if (IS_ENABLED(CONFIG_PCI)) {
+ ret = pci_init();
+ if (ret)
+ return ret;
+ }
+
+ ret = sata_rescan(true);
+ if (ret)
+ return ret;
+
+ return 0;
+}
+
+struct bootdev_ops sata_bootdev_ops = {
+};
+
+static const struct udevice_id sata_bootdev_ids[] = {
+ { .compatible = "u-boot,bootdev-sata" },
+ { }
+};
+
+U_BOOT_DRIVER(sata_bootdev) = {
+ .name = "sata_bootdev",
+ .id = UCLASS_BOOTDEV,
+ .ops= _bootdev_ops,
+ .
Re: bootstd: CACHE Misaligned operation errors (Marvell Armada 385)
Hi Simon,
On Fri, Sep 15, 2023 at 8:40 PM Tony Dinh wrote:
>
> On Fri, Sep 15, 2023 at 6:32 PM Tony Dinh wrote:
> >
> > Hi Tom, Hi Simon,
> >
> > On Wed, Sep 13, 2023 at 9:53 PM Tony Dinh wrote:
> > >
> > > Hi Simon,
> > >
> > > On Wed, Sep 13, 2023 at 8:38 PM Simon Glass wrote:
> > > >
> > > > Hi Tom,
> > > >
> > > > On Wed, 13 Sept 2023 at 14:14, Tom Rini wrote:
> > > > >
> > > > > On Wed, Sep 13, 2023 at 12:56:53PM -0700, Tony Dinh wrote:
> > > > > > Hi Tom,
> > > > > >
> > > > > > On Wed, Sep 13, 2023 at 9:22 AM Tom Rini wrote:
> > > > > > >
> > > > > > > On Tue, Sep 12, 2023 at 12:38:00PM -0700, Tony Dinh wrote:
> > > > > > >
> > > > > > > > I've been testing the boostd for a few Marvell boards and
> > > > > > > > seeing this
> > > > > > > > error on the Thecus N2350 (Marvell Armada 385, dual-core CPU).
> > > > > > > > The
> > > > > > > > "bootflow scan scsi" command triggered the "CACHE: Misaligned
> > > > > > > > operation at range" error. However, this error did not affect
> > > > > > > > the
> > > > > > > > result of the scan, i.e. the bootflow for scsi partition was
> > > > > > > > created
> > > > > > > > correctly, and u-boot is running normally.
> > > > > > > >
> > > > > > > > Enabling CONFIG_SYS_DCACHE_OFF got rid of the errors altogether.
> > > > > > > > Perhaps this is a case where the DCACHE is not required and
> > > > > > > > should be
> > > > > > > > turned off?
> > > > > > > >
> > > > > > > > Please see the log after the break below.
> > > > > > >
> > > > > > > Can you please try -next ? There's at least one SCSI related
> > > > > > > cache
> > > > > > > alignment fix there that's not in master, thanks.
> > > > > >
> > > > > > Unfortunately I got the same errors. This time the ranges are
> > > > > > different, of course.
> > > > > >
> > > > > > master:
> > > > > >
> > > > > > N2350 > bootflow scan scsi
> > > > > > CACHE: Misaligned operation at range [3fb99f88, 3fb9a388]
> > > > > > CACHE: Misaligned operation at range [3fb99f88, 3fb9a388]
> > > > > > CACHE: Misaligned operation at range [3fb99f88, 3fb9a388]
> > > > > > ERROR: v7_outer_cache_inval_range - start address is not aligned -
> > > > > > 0x3fb99f88
> > > > > > ERROR: v7_outer_cache_inval_range - stop address is not aligned -
> > > > > > 0x3fb9a388
> > > > > >
> > > > > > next:
> > > > > >
> > > > > > N2350 > bootflow scan scsi
> > > > > > CACHE: Misaligned operation at range [3fb80388, 3fb80788]
> > > > > > CACHE: Misaligned operation at range [3fb80388, 3fb80788]
> > > > > > CACHE: Misaligned operation at range [3fb80388, 3fb80788]
> > > > > > ERROR: v7_outer_cache_inval_range - start address is not aligned -
> > > > > > 0x3fb80388
> > > > > > ERROR: v7_outer_cache_inval_range - stop address is not aligned -
> > > > > > 0x3fb80788
> > > > >
> > > > > Can you debug to where these calls are so we can align these buffers?
> > > > > See 02660defdc8a ("scsi: Cache align temporary buffer") for an
> > > > > example.
> > > >
> > > > I wonder if we need to use memalign() when allocating memory to read
> > > > things from the media? But I am not sure which file time is being read,
> > > > or which bootmeth it is.
> > >
> > > Looks like we probably need to align the buffer tempbuff.
> > >
> > > /drivers/scsi/scsi.c
> > > static int scsi_detect_dev(struct udevice *dev, int target, int lun,
> > > struct blk_desc *dev_desc)
> > > {
> > > unsigned char perq, modi;
> > > lbaint_t capacity;
> > > unsigned long blksz;
> > > struct scsi_cmd *pccb = (struct scsi_cmd *)
> > > int count, err;
Re: bootstd: CACHE Misaligned operation errors (Marvell Armada 385)
On Fri, Sep 15, 2023 at 6:32 PM Tony Dinh wrote:
>
> Hi Tom, Hi Simon,
>
> On Wed, Sep 13, 2023 at 9:53 PM Tony Dinh wrote:
> >
> > Hi Simon,
> >
> > On Wed, Sep 13, 2023 at 8:38 PM Simon Glass wrote:
> > >
> > > Hi Tom,
> > >
> > > On Wed, 13 Sept 2023 at 14:14, Tom Rini wrote:
> > > >
> > > > On Wed, Sep 13, 2023 at 12:56:53PM -0700, Tony Dinh wrote:
> > > > > Hi Tom,
> > > > >
> > > > > On Wed, Sep 13, 2023 at 9:22 AM Tom Rini wrote:
> > > > > >
> > > > > > On Tue, Sep 12, 2023 at 12:38:00PM -0700, Tony Dinh wrote:
> > > > > >
> > > > > > > I've been testing the boostd for a few Marvell boards and seeing
> > > > > > > this
> > > > > > > error on the Thecus N2350 (Marvell Armada 385, dual-core CPU). The
> > > > > > > "bootflow scan scsi" command triggered the "CACHE: Misaligned
> > > > > > > operation at range" error. However, this error did not affect the
> > > > > > > result of the scan, i.e. the bootflow for scsi partition was
> > > > > > > created
> > > > > > > correctly, and u-boot is running normally.
> > > > > > >
> > > > > > > Enabling CONFIG_SYS_DCACHE_OFF got rid of the errors altogether.
> > > > > > > Perhaps this is a case where the DCACHE is not required and
> > > > > > > should be
> > > > > > > turned off?
> > > > > > >
> > > > > > > Please see the log after the break below.
> > > > > >
> > > > > > Can you please try -next ? There's at least one SCSI related cache
> > > > > > alignment fix there that's not in master, thanks.
> > > > >
> > > > > Unfortunately I got the same errors. This time the ranges are
> > > > > different, of course.
> > > > >
> > > > > master:
> > > > >
> > > > > N2350 > bootflow scan scsi
> > > > > CACHE: Misaligned operation at range [3fb99f88, 3fb9a388]
> > > > > CACHE: Misaligned operation at range [3fb99f88, 3fb9a388]
> > > > > CACHE: Misaligned operation at range [3fb99f88, 3fb9a388]
> > > > > ERROR: v7_outer_cache_inval_range - start address is not aligned -
> > > > > 0x3fb99f88
> > > > > ERROR: v7_outer_cache_inval_range - stop address is not aligned -
> > > > > 0x3fb9a388
> > > > >
> > > > > next:
> > > > >
> > > > > N2350 > bootflow scan scsi
> > > > > CACHE: Misaligned operation at range [3fb80388, 3fb80788]
> > > > > CACHE: Misaligned operation at range [3fb80388, 3fb80788]
> > > > > CACHE: Misaligned operation at range [3fb80388, 3fb80788]
> > > > > ERROR: v7_outer_cache_inval_range - start address is not aligned -
> > > > > 0x3fb80388
> > > > > ERROR: v7_outer_cache_inval_range - stop address is not aligned -
> > > > > 0x3fb80788
> > > >
> > > > Can you debug to where these calls are so we can align these buffers?
> > > > See 02660defdc8a ("scsi: Cache align temporary buffer") for an example.
> > >
> > > I wonder if we need to use memalign() when allocating memory to read
> > > things from the media? But I am not sure which file time is being read,
> > > or which bootmeth it is.
> >
> > Looks like we probably need to align the buffer tempbuff.
> >
> > /drivers/scsi/scsi.c
> > static int scsi_detect_dev(struct udevice *dev, int target, int lun,
> > struct blk_desc *dev_desc)
> > {
> > unsigned char perq, modi;
> > lbaint_t capacity;
> > unsigned long blksz;
> > struct scsi_cmd *pccb = (struct scsi_cmd *)
> > int count, err;
> >
> > pccb->target = target;
> > pccb->lun = lun;
> > pccb->pdata = (unsigned char *)
> > pccb->datalen = 512;
> >
> > If you look at the log I posted previously, this error shows up during
> > "bootflow scan scsi".
> >
>
> Taking the hint from Simon. I turned on log_debug and can see where
> the alignment is not correct. It is fs.c fs_read_alloc(). The
> memalign() call here probably needs to be revised to take into
> consideration ARCH_DMA_MINALIGN somehow? It is 64 for armv7.
>
> diff --git a/fs/fs.c b/fs/fs.c
&
Re: bootstd: CACHE Misaligned operation errors (Marvell Armada 385)
Hi Tom, Hi Simon,
On Wed, Sep 13, 2023 at 9:53 PM Tony Dinh wrote:
>
> Hi Simon,
>
> On Wed, Sep 13, 2023 at 8:38 PM Simon Glass wrote:
> >
> > Hi Tom,
> >
> > On Wed, 13 Sept 2023 at 14:14, Tom Rini wrote:
> > >
> > > On Wed, Sep 13, 2023 at 12:56:53PM -0700, Tony Dinh wrote:
> > > > Hi Tom,
> > > >
> > > > On Wed, Sep 13, 2023 at 9:22 AM Tom Rini wrote:
> > > > >
> > > > > On Tue, Sep 12, 2023 at 12:38:00PM -0700, Tony Dinh wrote:
> > > > >
> > > > > > I've been testing the boostd for a few Marvell boards and seeing
> > > > > > this
> > > > > > error on the Thecus N2350 (Marvell Armada 385, dual-core CPU). The
> > > > > > "bootflow scan scsi" command triggered the "CACHE: Misaligned
> > > > > > operation at range" error. However, this error did not affect the
> > > > > > result of the scan, i.e. the bootflow for scsi partition was created
> > > > > > correctly, and u-boot is running normally.
> > > > > >
> > > > > > Enabling CONFIG_SYS_DCACHE_OFF got rid of the errors altogether.
> > > > > > Perhaps this is a case where the DCACHE is not required and should
> > > > > > be
> > > > > > turned off?
> > > > > >
> > > > > > Please see the log after the break below.
> > > > >
> > > > > Can you please try -next ? There's at least one SCSI related cache
> > > > > alignment fix there that's not in master, thanks.
> > > >
> > > > Unfortunately I got the same errors. This time the ranges are
> > > > different, of course.
> > > >
> > > > master:
> > > >
> > > > N2350 > bootflow scan scsi
> > > > CACHE: Misaligned operation at range [3fb99f88, 3fb9a388]
> > > > CACHE: Misaligned operation at range [3fb99f88, 3fb9a388]
> > > > CACHE: Misaligned operation at range [3fb99f88, 3fb9a388]
> > > > ERROR: v7_outer_cache_inval_range - start address is not aligned -
> > > > 0x3fb99f88
> > > > ERROR: v7_outer_cache_inval_range - stop address is not aligned -
> > > > 0x3fb9a388
> > > >
> > > > next:
> > > >
> > > > N2350 > bootflow scan scsi
> > > > CACHE: Misaligned operation at range [3fb80388, 3fb80788]
> > > > CACHE: Misaligned operation at range [3fb80388, 3fb80788]
> > > > CACHE: Misaligned operation at range [3fb80388, 3fb80788]
> > > > ERROR: v7_outer_cache_inval_range - start address is not aligned -
> > > > 0x3fb80388
> > > > ERROR: v7_outer_cache_inval_range - stop address is not aligned -
> > > > 0x3fb80788
> > >
> > > Can you debug to where these calls are so we can align these buffers?
> > > See 02660defdc8a ("scsi: Cache align temporary buffer") for an example.
> >
> > I wonder if we need to use memalign() when allocating memory to read things
> > from the media? But I am not sure which file time is being read, or which
> > bootmeth it is.
>
> Looks like we probably need to align the buffer tempbuff.
>
> /drivers/scsi/scsi.c
> static int scsi_detect_dev(struct udevice *dev, int target, int lun,
> struct blk_desc *dev_desc)
> {
> unsigned char perq, modi;
> lbaint_t capacity;
> unsigned long blksz;
> struct scsi_cmd *pccb = (struct scsi_cmd *)
> int count, err;
>
> pccb->target = target;
> pccb->lun = lun;
> pccb->pdata = (unsigned char *)
> pccb->datalen = 512;
>
> If you look at the log I posted previously, this error shows up during
> "bootflow scan scsi".
>
Taking the hint from Simon. I turned on log_debug and can see where
the alignment is not correct. It is fs.c fs_read_alloc(). The
memalign() call here probably needs to be revised to take into
consideration ARCH_DMA_MINALIGN somehow? It is 64 for armv7.
diff --git a/fs/fs.c b/fs/fs.c
index 2b815b1db0..b70281532e 100644
--- a/fs/fs.c
+++ b/fs/fs.c
@@ -1019,9 +1019,12 @@ int fs_read_alloc(const char *fname, ulong
size, uint align, void **bufp)
int ret;
buf = memalign(align, size + 1);
+ log_debug("aligned buf addr 0x%x\n", (unsigned int)buf);
+
if (!buf)
return log_msg_ret("buf", -ENOMEM);
addr = map_to_sysmem(buf);
+ log_debug("aligned buf sysmem addr 0x%x\n", (unsigned int)addr);
ret = fs_read(fname, addr, 0, size, _read);
if (ret)
Re: bootstd: CACHE Misaligned operation errors (Marvell Armada 385)
Hi Simon,
On Wed, Sep 13, 2023 at 8:38 PM Simon Glass wrote:
>
> Hi Tom,
>
> On Wed, 13 Sept 2023 at 14:14, Tom Rini wrote:
> >
> > On Wed, Sep 13, 2023 at 12:56:53PM -0700, Tony Dinh wrote:
> > > Hi Tom,
> > >
> > > On Wed, Sep 13, 2023 at 9:22 AM Tom Rini wrote:
> > > >
> > > > On Tue, Sep 12, 2023 at 12:38:00PM -0700, Tony Dinh wrote:
> > > >
> > > > > I've been testing the boostd for a few Marvell boards and seeing this
> > > > > error on the Thecus N2350 (Marvell Armada 385, dual-core CPU). The
> > > > > "bootflow scan scsi" command triggered the "CACHE: Misaligned
> > > > > operation at range" error. However, this error did not affect the
> > > > > result of the scan, i.e. the bootflow for scsi partition was created
> > > > > correctly, and u-boot is running normally.
> > > > >
> > > > > Enabling CONFIG_SYS_DCACHE_OFF got rid of the errors altogether.
> > > > > Perhaps this is a case where the DCACHE is not required and should be
> > > > > turned off?
> > > > >
> > > > > Please see the log after the break below.
> > > >
> > > > Can you please try -next ? There's at least one SCSI related cache
> > > > alignment fix there that's not in master, thanks.
> > >
> > > Unfortunately I got the same errors. This time the ranges are
> > > different, of course.
> > >
> > > master:
> > >
> > > N2350 > bootflow scan scsi
> > > CACHE: Misaligned operation at range [3fb99f88, 3fb9a388]
> > > CACHE: Misaligned operation at range [3fb99f88, 3fb9a388]
> > > CACHE: Misaligned operation at range [3fb99f88, 3fb9a388]
> > > ERROR: v7_outer_cache_inval_range - start address is not aligned -
> > > 0x3fb99f88
> > > ERROR: v7_outer_cache_inval_range - stop address is not aligned -
> > > 0x3fb9a388
> > >
> > > next:
> > >
> > > N2350 > bootflow scan scsi
> > > CACHE: Misaligned operation at range [3fb80388, 3fb80788]
> > > CACHE: Misaligned operation at range [3fb80388, 3fb80788]
> > > CACHE: Misaligned operation at range [3fb80388, 3fb80788]
> > > ERROR: v7_outer_cache_inval_range - start address is not aligned -
> > > 0x3fb80388
> > > ERROR: v7_outer_cache_inval_range - stop address is not aligned -
> > > 0x3fb80788
> >
> > Can you debug to where these calls are so we can align these buffers?
> > See 02660defdc8a ("scsi: Cache align temporary buffer") for an example.
>
> I wonder if we need to use memalign() when allocating memory to read things
> from the media? But I am not sure which file time is being read, or which
> bootmeth it is.
Looks like we probably need to align the buffer tempbuff.
/drivers/scsi/scsi.c
static int scsi_detect_dev(struct udevice *dev, int target, int lun,
struct blk_desc *dev_desc)
{
unsigned char perq, modi;
lbaint_t capacity;
unsigned long blksz;
struct scsi_cmd *pccb = (struct scsi_cmd *)
int count, err;
pccb->target = target;
pccb->lun = lun;
pccb->pdata = (unsigned char *)
pccb->datalen = 512;
If you look at the log I posted previously, this error shows up during
"bootflow scan scsi".
All the best,
Tony
>
> Regards,
> Simon
Re: bootstd: CACHE Misaligned operation errors (Marvell Armada 385)
Hi Tom,
On Wed, Sep 13, 2023 at 1:13 PM Tom Rini wrote:
>
> On Wed, Sep 13, 2023 at 12:56:53PM -0700, Tony Dinh wrote:
> > Hi Tom,
> >
> > On Wed, Sep 13, 2023 at 9:22 AM Tom Rini wrote:
> > >
> > > On Tue, Sep 12, 2023 at 12:38:00PM -0700, Tony Dinh wrote:
> > >
> > > > I've been testing the boostd for a few Marvell boards and seeing this
> > > > error on the Thecus N2350 (Marvell Armada 385, dual-core CPU). The
> > > > "bootflow scan scsi" command triggered the "CACHE: Misaligned
> > > > operation at range" error. However, this error did not affect the
> > > > result of the scan, i.e. the bootflow for scsi partition was created
> > > > correctly, and u-boot is running normally.
> > > >
> > > > Enabling CONFIG_SYS_DCACHE_OFF got rid of the errors altogether.
> > > > Perhaps this is a case where the DCACHE is not required and should be
> > > > turned off?
> > > >
> > > > Please see the log after the break below.
> > >
> > > Can you please try -next ? There's at least one SCSI related cache
> > > alignment fix there that's not in master, thanks.
> >
> > Unfortunately I got the same errors. This time the ranges are
> > different, of course.
> >
> > master:
> >
> > N2350 > bootflow scan scsi
> > CACHE: Misaligned operation at range [3fb99f88, 3fb9a388]
> > CACHE: Misaligned operation at range [3fb99f88, 3fb9a388]
> > CACHE: Misaligned operation at range [3fb99f88, 3fb9a388]
> > ERROR: v7_outer_cache_inval_range - start address is not aligned -
> > 0x3fb99f88
> > ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x3fb9a388
> >
> > next:
> >
> > N2350 > bootflow scan scsi
> > CACHE: Misaligned operation at range [3fb80388, 3fb80788]
> > CACHE: Misaligned operation at range [3fb80388, 3fb80788]
> > CACHE: Misaligned operation at range [3fb80388, 3fb80788]
> > ERROR: v7_outer_cache_inval_range - start address is not aligned -
> > 0x3fb80388
> > ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x3fb80788
>
> Can you debug to where these calls are so we can align these buffers?
> See 02660defdc8a ("scsi: Cache align temporary buffer") for an example.
I've added some printfs to the code. Looks like the last calls were
SCSI_READ16 (0x48) in this sequence:
scsi_exec() --> ahci_scsi_exec() --> ata_scsiop_read_write()
Note that the misaligned errors do not always occur.
I've also looked at the other recent commit by Marek and tried to
enable CONFIG_BOUNCE_BUFFER:
https://github.com/u-boot/u-boot/commit/4f543e82b9831333bc0effe9540d8e6a9dde3cb5
But I think it is a noop without a callback from the driver.
Please see the boot log below after the break.
Thanks,
Tony
U-Boot 2023.10-rc4-tld-1-00284-gce67ba1e30-dirty (Sep 13 2023 - 16:44:56 -0700)
Thecus N2350
SoC: MV88F6820-A0 at 1066 MHz
DRAM: 1 GiB (533 MHz, 32-bit, ECC not enabled)
Core: 65 devices, 23 uclasses, devicetree: separate
NAND: 512 MiB
MMC:
Loading Environment from SPIFlash... SF: Detected mx25l3205d with page
size 256 Bytes, erase size 4 KiB, total 4 MiB
*** Warning - bad CRC, using default environment
Model: Thecus N2350
Net:
Warning: ethernet@7 (eth0) using random MAC address - a2:6f:f1:4a:2e:51
eth0: ethernet@7
Hit any key to stop autoboot: 0
N2350 > env def -a
## Resetting to default environment
N2350 > bootdev l
Seq Probed Status UclassName
--- -- -- --
0 [ ] OK ethernet ethernet@7.bootdev
--- -- -- --
(1 bootdev)
N2350 > bootdev hunt scsi
Hunting with: scsi
pcie0.0: Link down
pcie1.0: Link down
scsi_scan
scanning bus for devices...
scsi_scan_dev
SATA link 0 timeout.
Target spinup took 0 ms.
AHCI 0001. 32 slots 2 ports 6 Gbps 0x3 impl SATA mode
flags: 64bit ncq led only pmp fbss pio slum part sxs
do_scsi_scan_one
scsi_detect_dev
scsi_setup_inquiry
scsi_exec
ahci_scsi_exec
ahci_scsi_exec cmd = 0x12
do_scsi_scan_one
scsi_detect_dev
scsi_setup_inquiry
scsi_exec
ahci_scsi_exec
ahci_scsi_exec cmd = 0x12
scsi_ident_cpy
scsi_ident_cpy
scsi_ident_cpy
scsi_exec
ahci_scsi_exec
ahci_scsi_exec cmd = 0x0
scsi_read_capacity
scsi_exec
ahci_scsi_exec
ahci_scsi_exec cmd = 0x25
scsi_exec
ahci_scsi_exec
ahci_scsi_exec cmd = 0x28
ata_scsiop_read_write
scsi_exec
ahci_scsi_exec
ahci_scsi_exec cmd = 0x28
ata_scsiop_read_write
scsi_exec
ahci_scsi_exec
ahci_scsi_exec cmd = 0x28
ata_scsiop_read_write
scsi_exec
ahci_scsi_exec
ahci_scsi_exec cmd = 0x28
ata_scsiop_read_write
scsi_exec
ahci_scsi_exec
ahci_scsi_exec cmd = 0x28
ata_scsiop_read_write
Device 0: (1:0) Vendor: ATA Pro
Re: bootstd: CACHE Misaligned operation errors (Marvell Armada 385)
Hi Tom, On Wed, Sep 13, 2023 at 9:22 AM Tom Rini wrote: > > On Tue, Sep 12, 2023 at 12:38:00PM -0700, Tony Dinh wrote: > > > I've been testing the boostd for a few Marvell boards and seeing this > > error on the Thecus N2350 (Marvell Armada 385, dual-core CPU). The > > "bootflow scan scsi" command triggered the "CACHE: Misaligned > > operation at range" error. However, this error did not affect the > > result of the scan, i.e. the bootflow for scsi partition was created > > correctly, and u-boot is running normally. > > > > Enabling CONFIG_SYS_DCACHE_OFF got rid of the errors altogether. > > Perhaps this is a case where the DCACHE is not required and should be > > turned off? > > > > Please see the log after the break below. > > Can you please try -next ? There's at least one SCSI related cache > alignment fix there that's not in master, thanks. Unfortunately I got the same errors. This time the ranges are different, of course. master: N2350 > bootflow scan scsi CACHE: Misaligned operation at range [3fb99f88, 3fb9a388] CACHE: Misaligned operation at range [3fb99f88, 3fb9a388] CACHE: Misaligned operation at range [3fb99f88, 3fb9a388] ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x3fb99f88 ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x3fb9a388 next: N2350 > bootflow scan scsi CACHE: Misaligned operation at range [3fb80388, 3fb80788] CACHE: Misaligned operation at range [3fb80388, 3fb80788] CACHE: Misaligned operation at range [3fb80388, 3fb80788] ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x3fb80388 ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x3fb80788 Thanks, Tony > > -- > Tom
bootstd: CACHE Misaligned operation errors (Marvell Armada 385)
I've been testing the boostd for a few Marvell boards and seeing this error on the Thecus N2350 (Marvell Armada 385, dual-core CPU). The "bootflow scan scsi" command triggered the "CACHE: Misaligned operation at range" error. However, this error did not affect the result of the scan, i.e. the bootflow for scsi partition was created correctly, and u-boot is running normally. Enabling CONFIG_SYS_DCACHE_OFF got rid of the errors altogether. Perhaps this is a case where the DCACHE is not required and should be turned off? Please see the log after the break below. All the best, Tony U-Boot 2023.10-rc4-tld-1-00036-gbb16283b81-dirty (Sep 11 2023 - 11:56:18 -0700) Thecus N2350 SoC: MV88F6820-A0 at 1066 MHz DRAM: 1 GiB (533 MHz, 32-bit, ECC not enabled) Core: 65 devices, 23 uclasses, devicetree: separate NAND: 512 MiB MMC: Loading Environment from SPIFlash... SF: Detected mx25l3205d with page size 256 Bytes, erase size 4 KiB, total 4 MiB *** Warning - bad CRC, using default environment Model: Thecus N2350 Net: Warning: ethernet@7 (eth0) using random MAC address - be:13:ae:99:49:ab eth0: ethernet@7 Hit any key to stop autoboot: 0 N2350 > env def -a ## Resetting to default environment N2350 > bootdev l Seq Probed Status UclassName --- -- -- -- 0 [ ] OK ethernet ethernet@7.bootdev --- -- -- -- (1 bootdev) N2350 > bootdev hunt scsi Hunting with: scsi pcie0.0: Link down pcie1.0: Link down scanning bus for devices... SATA link 0 timeout. Target spinup took 0 ms. AHCI 0001. 32 slots 2 ports 6 Gbps 0x3 impl SATA mode flags: 64bit ncq led only pmp fbss pio slum part sxs Device 0: (1:0) Vendor: ATA Prod.: ST750LX003-1AC15 Rev: SM12 Type: Hard Disk Capacity: 715404.8 MB = 698.6 GB (1465149168 x 512) N2350 > bootflow scan usb Bus usb@58000: USB EHCI 1.00 Bus usb3@f: MVEBU XHCI INIT controller @ 0xf10f4000 Register 2000120 NbrPorts 2 Starting the controller USB XHCI 1.00 Bus usb3@f8000: MVEBU XHCI INIT controller @ 0xf10fc000 Register 2000120 NbrPorts 2 Starting the controller USB XHCI 1.00 scanning bus usb@58000 for devices... 1 USB Device(s) found scanning bus usb3@f for devices... 1 USB Device(s) found scanning bus usb3@f8000 for devices... 2 USB Device(s) found ** File not found /boot/boot.bmp ** N2350 > bootflow scan scsi CACHE: Misaligned operation at range [3fb7fe48, 3fb80248] CACHE: Misaligned operation at range [3fb7fe48, 3fb80248] CACHE: Misaligned operation at range [3fb7fe48, 3fb80248] ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x3fb7fe48 ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x3fb80248 ** File not found /boot/boot.bmp ** ** File not found /boot/boot.bmp ** N2350 > bootflow scan scsi CACHE: Misaligned operation at range [3fb88a88, 3fb88e88] CACHE: Misaligned operation at range [3fb88a88, 3fb88e88] CACHE: Misaligned operation at range [3fb88a88, 3fb88e88] ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x3fb88a88 ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x3fb88e88 ** File not found /boot/boot.bmp ** ** File not found /boot/boot.bmp ** N2350 > bootflow l Showing all bootflows Seq Method State UclassPart Name Filename --- --- -- 0 script ready scsi 1 ahci_scsi.id1lun0.bootdev /boot/boot.scr 1 script ready usb_mass_1 usb_mass_storage.lun0.boo /boot/boot.scr --- --- -- (2 bootflows, 2 valid) N2350 > boot Scanning for bootflows in all bootdevs Seq Method State UclassPart Name Filename --- --- -- Scanning global bootmeth 'efi_mgr': Hunting with: mmc Scanning bootdev 'ahci_scsi.id1lun0.bootdev': CACHE: Misaligned operation at range [3fb91d08, 3fb92108] CACHE: Misaligned operation at range [3fb91d08, 3fb92108] CACHE: Misaligned operation at range [3fb91d08, 3fb92108] ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x3fb91d08 ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x3fb92108 ** File not found /boot/boot.bmp ** 0 script ready scsi 1 ahci_scsi.id1lun0.bootdev /boot/boot.scr ** Booting bootflow 'ahci_scsi.id1lun0.bootdev.part_1' with script Booting with distro boot script loading uImage from scsi 0:1 ... 511 bytes read in 120 ms (40.7 MiB/s) loading uInitrd from scsi 0:1 ... 7355687 bytes read in 197 ms (35.6 MiB/s) loading DTB file from scsi 0:1 ... 20906 bytes read in 16 ms (1.2 MiB/s) ## Booting kernel from Legacy Image at 0100 ... Image Name: Linux-6.4.11-mvebu-tld-1 Created: 2023-08-20 17:34:55 UTC Image Type: ARM Linux Kernel Image (uncompressed)
Re: [PATCH v3] bootstd: sata: Add bootstd support for ahci sata
Hi Simon,
On Sun, Sep 10, 2023 at 3:37 PM Simon Glass wrote:
>
> Hi Tony,
>
> On Fri, 8 Sept 2023 at 13:10, Tony Dinh wrote:
> >
> > Add ahci sata bootdev and corresponding hunting function.
> >
> > Signed-off-by: Tony Dinh
> > ---
> >
> > Changes in v3:
> > - Correct drivers/ata/Makefile to compile sata_bootdev only if
> > ahci sata is enabled.
> >
> > Changes in v2:
> > - set devtype to sata in bootmeth_script for non-scsi SATA device.
> >
> > boot/bootmeth_script.c | 12 ++--
> > drivers/ata/Makefile | 2 +-
> > drivers/ata/sata.c | 25 +++
> > drivers/ata/sata_bootdev.c | 62 ++
> > include/sata.h | 1 +
> > 5 files changed, 99 insertions(+), 3 deletions(-)
> > create mode 100644 drivers/ata/sata_bootdev.c
> >
> > diff --git a/boot/bootmeth_script.c b/boot/bootmeth_script.c
> > index 58c57a2d4b..0269e0f9b0 100644
> > --- a/boot/bootmeth_script.c
> > +++ b/boot/bootmeth_script.c
> > @@ -190,10 +190,18 @@ static int script_boot(struct udevice *dev, struct
> > bootflow *bflow)
> > ulong addr;
> > int ret;
> >
> > - if (desc->uclass_id == UCLASS_USB)
> > + if (desc->uclass_id == UCLASS_USB) {
> > ret = env_set("devtype", "usb");
> > - else
> > + } else {
> > ret = env_set("devtype", blk_get_devtype(bflow->blk));
> > +
> > + /* If the parent uclass is AHCI, but the driver is ATA
> > +* (not scsi), set devtype to sata
> > +*/
> > + if (!ret && IS_ENABLED(CONFIG_SATA) &&
> > + !strcmp("ahci", env_get("devtype")))
>
> Can you not use desc->uclass_id to do the right thing here? It seems
> odd to compare with the value of the env var you just set up above.
Indeed, I must have been too caught up with the env :)
>
> > + ret = env_set("devtype", "sata");
> > + }
> > if (!ret)
> > ret = env_set_hex("devnum", desc->devnum);
> > if (!ret)
> > diff --git a/drivers/ata/Makefile b/drivers/ata/Makefile
> > index 6e30180b8b..0b6f91098a 100644
> > --- a/drivers/ata/Makefile
> > +++ b/drivers/ata/Makefile
> > @@ -10,7 +10,7 @@ obj-$(CONFIG_SCSI_AHCI) += ahci.o
> > obj-$(CONFIG_DWC_AHSATA) += dwc_ahsata.o
> > obj-$(CONFIG_FSL_SATA) += fsl_sata.o
> > obj-$(CONFIG_LIBATA) += libata.o
> > -obj-$(CONFIG_SATA) += sata.o
> > +obj-$(CONFIG_SATA) += sata.o sata_bootdev.o
> > obj-$(CONFIG_SATA_CEVA) += sata_ceva.o
> > obj-$(CONFIG_SATA_MV) += sata_mv.o
> > obj-$(CONFIG_SATA_SIL) += sata_sil.o
> > diff --git a/drivers/ata/sata.c b/drivers/ata/sata.c
> > index ce3e9b5a40..9da7218564 100644
> > --- a/drivers/ata/sata.c
> > +++ b/drivers/ata/sata.c
> > @@ -15,6 +15,8 @@
> > #include
> > #include
> > #include
> > +#include
> > +#include
> >
> > #ifndef CONFIG_AHCI
> > struct blk_desc sata_dev_desc[CONFIG_SYS_SATA_MAX_DEVICE];
> > @@ -50,6 +52,29 @@ int sata_scan(struct udevice *dev)
> > return ops->scan(dev);
> > }
> >
> > +int sata_rescan(bool verbose)
> > +{
> > + struct udevice *dev;
> > + int devnum = 0;
> > + int ret;
> > +
> > + /* Find and probing the SATA controller */
> > + ret = uclass_get_device(UCLASS_AHCI, devnum, );
>
> This does not actually rescan...if the device has already been probed,
> it won't be probed again. You will need to use the logic like in
> sata_remove().
>
> Also, please avoid using devnum. You should probably just use
> uclass_probe_all(UCLASS_AHCI)
OK.
>
> > +
> > + /* Sanity check */
> > + if (ret)
> > + ret = uclass_find_first_device(UCLASS_AHCI, );
>
> That just finds it, but does not probe it. See uclass_first_device_err()
>
> > + if (ret) {
> > + printf("Cannot probe SATA device %d (err=%d)\n", devnum,
> > ret);
> > + return -ENOSYS;
>
> return ret
>
> > + }
> > + if (!dev) {
> > + printf("No SATA device found!\n");
> > + return -ENOSYS;
> > + }
> > + return 0;
> > +}
> > +
> > #ifndef CONFIG_AHCI
> > #ifdef CO
[PATCH v3] bootstd: sata: Add bootstd support for ahci sata
Add ahci sata bootdev and corresponding hunting function.
Signed-off-by: Tony Dinh
---
Changes in v3:
- Correct drivers/ata/Makefile to compile sata_bootdev only if
ahci sata is enabled.
Changes in v2:
- set devtype to sata in bootmeth_script for non-scsi SATA device.
boot/bootmeth_script.c | 12 ++--
drivers/ata/Makefile | 2 +-
drivers/ata/sata.c | 25 +++
drivers/ata/sata_bootdev.c | 62 ++
include/sata.h | 1 +
5 files changed, 99 insertions(+), 3 deletions(-)
create mode 100644 drivers/ata/sata_bootdev.c
diff --git a/boot/bootmeth_script.c b/boot/bootmeth_script.c
index 58c57a2d4b..0269e0f9b0 100644
--- a/boot/bootmeth_script.c
+++ b/boot/bootmeth_script.c
@@ -190,10 +190,18 @@ static int script_boot(struct udevice *dev, struct
bootflow *bflow)
ulong addr;
int ret;
- if (desc->uclass_id == UCLASS_USB)
+ if (desc->uclass_id == UCLASS_USB) {
ret = env_set("devtype", "usb");
- else
+ } else {
ret = env_set("devtype", blk_get_devtype(bflow->blk));
+
+ /* If the parent uclass is AHCI, but the driver is ATA
+* (not scsi), set devtype to sata
+*/
+ if (!ret && IS_ENABLED(CONFIG_SATA) &&
+ !strcmp("ahci", env_get("devtype")))
+ ret = env_set("devtype", "sata");
+ }
if (!ret)
ret = env_set_hex("devnum", desc->devnum);
if (!ret)
diff --git a/drivers/ata/Makefile b/drivers/ata/Makefile
index 6e30180b8b..0b6f91098a 100644
--- a/drivers/ata/Makefile
+++ b/drivers/ata/Makefile
@@ -10,7 +10,7 @@ obj-$(CONFIG_SCSI_AHCI) += ahci.o
obj-$(CONFIG_DWC_AHSATA) += dwc_ahsata.o
obj-$(CONFIG_FSL_SATA) += fsl_sata.o
obj-$(CONFIG_LIBATA) += libata.o
-obj-$(CONFIG_SATA) += sata.o
+obj-$(CONFIG_SATA) += sata.o sata_bootdev.o
obj-$(CONFIG_SATA_CEVA) += sata_ceva.o
obj-$(CONFIG_SATA_MV) += sata_mv.o
obj-$(CONFIG_SATA_SIL) += sata_sil.o
diff --git a/drivers/ata/sata.c b/drivers/ata/sata.c
index ce3e9b5a40..9da7218564 100644
--- a/drivers/ata/sata.c
+++ b/drivers/ata/sata.c
@@ -15,6 +15,8 @@
#include
#include
#include
+#include
+#include
#ifndef CONFIG_AHCI
struct blk_desc sata_dev_desc[CONFIG_SYS_SATA_MAX_DEVICE];
@@ -50,6 +52,29 @@ int sata_scan(struct udevice *dev)
return ops->scan(dev);
}
+int sata_rescan(bool verbose)
+{
+ struct udevice *dev;
+ int devnum = 0;
+ int ret;
+
+ /* Find and probing the SATA controller */
+ ret = uclass_get_device(UCLASS_AHCI, devnum, );
+
+ /* Sanity check */
+ if (ret)
+ ret = uclass_find_first_device(UCLASS_AHCI, );
+ if (ret) {
+ printf("Cannot probe SATA device %d (err=%d)\n", devnum, ret);
+ return -ENOSYS;
+ }
+ if (!dev) {
+ printf("No SATA device found!\n");
+ return -ENOSYS;
+ }
+ return 0;
+}
+
#ifndef CONFIG_AHCI
#ifdef CONFIG_PARTITIONS
struct blk_desc *sata_get_dev(int dev)
diff --git a/drivers/ata/sata_bootdev.c b/drivers/ata/sata_bootdev.c
new file mode 100644
index 00..f638493ce0
--- /dev/null
+++ b/drivers/ata/sata_bootdev.c
@@ -0,0 +1,62 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Bootdev for sata
+ *
+ * Copyright 2023 Tony Dinh
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+static int sata_bootdev_bind(struct udevice *dev)
+{
+ struct bootdev_uc_plat *ucp = dev_get_uclass_plat(dev);
+
+ ucp->prio = BOOTDEVP_4_SCAN_FAST;
+
+ return 0;
+}
+
+static int sata_bootdev_hunt(struct bootdev_hunter *info, bool show)
+{
+ int ret;
+
+ if (IS_ENABLED(CONFIG_PCI)) {
+ ret = pci_init();
+ if (ret)
+ return ret;
+ }
+
+ ret = sata_rescan(true);
+ if (ret)
+ return ret;
+
+ return 0;
+}
+
+struct bootdev_ops sata_bootdev_ops = {
+};
+
+static const struct udevice_id sata_bootdev_ids[] = {
+ { .compatible = "u-boot,bootdev-sata" },
+ { }
+};
+
+U_BOOT_DRIVER(sata_bootdev) = {
+ .name = "sata_bootdev",
+ .id = UCLASS_BOOTDEV,
+ .ops= _bootdev_ops,
+ .bind = sata_bootdev_bind,
+ .of_match = sata_bootdev_ids,
+};
+
+BOOTDEV_HUNTER(sata_bootdev_hunter) = {
+ .prio = BOOTDEVP_4_SCAN_FAST,
+ .uclass = UCLASS_AHCI,
+ .hunt = sata_bootdev_hunt,
+ .drv= DM_DRIVER_REF(sata_bootdev),
+};
diff --git a/include/sata.h b/include/sata.h
index d89f7a8a29..0495744bad 100644
--- a/include/sata.h
+++ b/include/sata.h
@@ -20,5 +20,6 @@ extern struct blk_desc sata_dev_desc[];
int sata_probe(int devnum);
int sata_remove(int devnum);
+int sata_rescan(bool verbose);
#endif
--
2.39.2
Re: [PATCH v2] bootstd: sata: Add bootstd support for ahci sata
On Thu, Sep 7, 2023 at 2:39 PM Tony Dinh wrote:
>
> Add ahci sata bootdev and corresponding hunting function.
>
> Signed-off-by: Tony Dinh
> ---
>
> Changes in v2:
> - set devtype to sata in bootmeth_script for non-scsi SATA device
>
> boot/bootmeth_script.c | 12 ++--
> drivers/ata/Makefile | 1 +
> drivers/ata/sata.c | 25 +++
> drivers/ata/sata_bootdev.c | 62 ++
> include/sata.h | 1 +
> 5 files changed, 99 insertions(+), 2 deletions(-)
> create mode 100644 drivers/ata/sata_bootdev.c
>
> diff --git a/boot/bootmeth_script.c b/boot/bootmeth_script.c
> index a4050c384d..3113183fb0 100644
> --- a/boot/bootmeth_script.c
> +++ b/boot/bootmeth_script.c
> @@ -190,10 +190,18 @@ static int script_boot(struct udevice *dev, struct
> bootflow *bflow)
> ulong addr;
> int ret;
>
> - if (desc->uclass_id == UCLASS_USB)
> + if (desc->uclass_id == UCLASS_USB) {
> ret = env_set("devtype", "usb");
> - else
> + } else {
> ret = env_set("devtype", blk_get_devtype(bflow->blk));
> +
> + /* If the parent uclass is AHCI, but the driver is ATA
> +* (not scsi), set devtype to sata
> +*/
> + if (!ret && IS_ENABLED(CONFIG_SATA) &&
> + !strcmp("ahci", env_get("devtype")))
> + ret = env_set("devtype", "sata");
> + }
> if (!ret)
> ret = env_set_hex("devnum", desc->devnum);
> if (!ret)
> diff --git a/drivers/ata/Makefile b/drivers/ata/Makefile
> index 6e30180b8b..c1b51b5444 100644
> --- a/drivers/ata/Makefile
> +++ b/drivers/ata/Makefile
> @@ -11,6 +11,7 @@ obj-$(CONFIG_DWC_AHSATA) += dwc_ahsata.o
> obj-$(CONFIG_FSL_SATA) += fsl_sata.o
> obj-$(CONFIG_LIBATA) += libata.o
> obj-$(CONFIG_SATA) += sata.o
> +obj-$(CONFIG_BOOTSTD) += sata_bootdev.o
> obj-$(CONFIG_SATA_CEVA) += sata_ceva.o
> obj-$(CONFIG_SATA_MV) += sata_mv.o
> obj-$(CONFIG_SATA_SIL) += sata_sil.o
> diff --git a/drivers/ata/sata.c b/drivers/ata/sata.c
> index ce3e9b5a40..9da7218564 100644
> --- a/drivers/ata/sata.c
> +++ b/drivers/ata/sata.c
> @@ -15,6 +15,8 @@
> #include
> #include
> #include
> +#include
> +#include
>
> #ifndef CONFIG_AHCI
> struct blk_desc sata_dev_desc[CONFIG_SYS_SATA_MAX_DEVICE];
> @@ -50,6 +52,29 @@ int sata_scan(struct udevice *dev)
> return ops->scan(dev);
> }
>
> +int sata_rescan(bool verbose)
> +{
> + struct udevice *dev;
> + int devnum = 0;
> + int ret;
> +
> + /* Find and probing the SATA controller */
> + ret = uclass_get_device(UCLASS_AHCI, devnum, );
> +
> + /* Sanity check */
> + if (ret)
> + ret = uclass_find_first_device(UCLASS_AHCI, );
> + if (ret) {
> + printf("Cannot probe SATA device %d (err=%d)\n", devnum, ret);
> + return -ENOSYS;
> + }
> + if (!dev) {
> + printf("No SATA device found!\n");
> + return -ENOSYS;
> + }
> + return 0;
> +}
> +
> #ifndef CONFIG_AHCI
> #ifdef CONFIG_PARTITIONS
> struct blk_desc *sata_get_dev(int dev)
> diff --git a/drivers/ata/sata_bootdev.c b/drivers/ata/sata_bootdev.c
> new file mode 100644
> index 00..f638493ce0
> --- /dev/null
> +++ b/drivers/ata/sata_bootdev.c
> @@ -0,0 +1,62 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Bootdev for sata
> + *
> + * Copyright 2023 Tony Dinh
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +static int sata_bootdev_bind(struct udevice *dev)
> +{
> + struct bootdev_uc_plat *ucp = dev_get_uclass_plat(dev);
> +
> + ucp->prio = BOOTDEVP_4_SCAN_FAST;
> +
> + return 0;
> +}
> +
> +static int sata_bootdev_hunt(struct bootdev_hunter *info, bool show)
> +{
> + int ret;
> +
> + if (IS_ENABLED(CONFIG_PCI)) {
> + ret = pci_init();
> + if (ret)
> + return ret;
> + }
> +
> + ret = sata_rescan(true);
> + if (ret)
> + return ret;
> +
> + return 0;
> +}
> +
> +struct bootdev_ops sata_bootdev_ops = {
> +};
> +
> +static const struct udevice_id sata_bootdev_ids[] = {
> + { .compatible = "u-boot,bootdev-sata" },
> + { }
> +};
> +
> +U_BOOT_DRIVER
[PATCH v2] bootstd: sata: Add bootstd support for ahci sata
Add ahci sata bootdev and corresponding hunting function.
Signed-off-by: Tony Dinh
---
Changes in v2:
- set devtype to sata in bootmeth_script for non-scsi SATA device
boot/bootmeth_script.c | 12 ++--
drivers/ata/Makefile | 1 +
drivers/ata/sata.c | 25 +++
drivers/ata/sata_bootdev.c | 62 ++
include/sata.h | 1 +
5 files changed, 99 insertions(+), 2 deletions(-)
create mode 100644 drivers/ata/sata_bootdev.c
diff --git a/boot/bootmeth_script.c b/boot/bootmeth_script.c
index a4050c384d..3113183fb0 100644
--- a/boot/bootmeth_script.c
+++ b/boot/bootmeth_script.c
@@ -190,10 +190,18 @@ static int script_boot(struct udevice *dev, struct
bootflow *bflow)
ulong addr;
int ret;
- if (desc->uclass_id == UCLASS_USB)
+ if (desc->uclass_id == UCLASS_USB) {
ret = env_set("devtype", "usb");
- else
+ } else {
ret = env_set("devtype", blk_get_devtype(bflow->blk));
+
+ /* If the parent uclass is AHCI, but the driver is ATA
+* (not scsi), set devtype to sata
+*/
+ if (!ret && IS_ENABLED(CONFIG_SATA) &&
+ !strcmp("ahci", env_get("devtype")))
+ ret = env_set("devtype", "sata");
+ }
if (!ret)
ret = env_set_hex("devnum", desc->devnum);
if (!ret)
diff --git a/drivers/ata/Makefile b/drivers/ata/Makefile
index 6e30180b8b..c1b51b5444 100644
--- a/drivers/ata/Makefile
+++ b/drivers/ata/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_DWC_AHSATA) += dwc_ahsata.o
obj-$(CONFIG_FSL_SATA) += fsl_sata.o
obj-$(CONFIG_LIBATA) += libata.o
obj-$(CONFIG_SATA) += sata.o
+obj-$(CONFIG_BOOTSTD) += sata_bootdev.o
obj-$(CONFIG_SATA_CEVA) += sata_ceva.o
obj-$(CONFIG_SATA_MV) += sata_mv.o
obj-$(CONFIG_SATA_SIL) += sata_sil.o
diff --git a/drivers/ata/sata.c b/drivers/ata/sata.c
index ce3e9b5a40..9da7218564 100644
--- a/drivers/ata/sata.c
+++ b/drivers/ata/sata.c
@@ -15,6 +15,8 @@
#include
#include
#include
+#include
+#include
#ifndef CONFIG_AHCI
struct blk_desc sata_dev_desc[CONFIG_SYS_SATA_MAX_DEVICE];
@@ -50,6 +52,29 @@ int sata_scan(struct udevice *dev)
return ops->scan(dev);
}
+int sata_rescan(bool verbose)
+{
+ struct udevice *dev;
+ int devnum = 0;
+ int ret;
+
+ /* Find and probing the SATA controller */
+ ret = uclass_get_device(UCLASS_AHCI, devnum, );
+
+ /* Sanity check */
+ if (ret)
+ ret = uclass_find_first_device(UCLASS_AHCI, );
+ if (ret) {
+ printf("Cannot probe SATA device %d (err=%d)\n", devnum, ret);
+ return -ENOSYS;
+ }
+ if (!dev) {
+ printf("No SATA device found!\n");
+ return -ENOSYS;
+ }
+ return 0;
+}
+
#ifndef CONFIG_AHCI
#ifdef CONFIG_PARTITIONS
struct blk_desc *sata_get_dev(int dev)
diff --git a/drivers/ata/sata_bootdev.c b/drivers/ata/sata_bootdev.c
new file mode 100644
index 00..f638493ce0
--- /dev/null
+++ b/drivers/ata/sata_bootdev.c
@@ -0,0 +1,62 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Bootdev for sata
+ *
+ * Copyright 2023 Tony Dinh
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+static int sata_bootdev_bind(struct udevice *dev)
+{
+ struct bootdev_uc_plat *ucp = dev_get_uclass_plat(dev);
+
+ ucp->prio = BOOTDEVP_4_SCAN_FAST;
+
+ return 0;
+}
+
+static int sata_bootdev_hunt(struct bootdev_hunter *info, bool show)
+{
+ int ret;
+
+ if (IS_ENABLED(CONFIG_PCI)) {
+ ret = pci_init();
+ if (ret)
+ return ret;
+ }
+
+ ret = sata_rescan(true);
+ if (ret)
+ return ret;
+
+ return 0;
+}
+
+struct bootdev_ops sata_bootdev_ops = {
+};
+
+static const struct udevice_id sata_bootdev_ids[] = {
+ { .compatible = "u-boot,bootdev-sata" },
+ { }
+};
+
+U_BOOT_DRIVER(sata_bootdev) = {
+ .name = "sata_bootdev",
+ .id = UCLASS_BOOTDEV,
+ .ops= _bootdev_ops,
+ .bind = sata_bootdev_bind,
+ .of_match = sata_bootdev_ids,
+};
+
+BOOTDEV_HUNTER(sata_bootdev_hunter) = {
+ .prio = BOOTDEVP_4_SCAN_FAST,
+ .uclass = UCLASS_AHCI,
+ .hunt = sata_bootdev_hunt,
+ .drv= DM_DRIVER_REF(sata_bootdev),
+};
diff --git a/include/sata.h b/include/sata.h
index d89f7a8a29..0495744bad 100644
--- a/include/sata.h
+++ b/include/sata.h
@@ -20,5 +20,6 @@ extern struct blk_desc sata_dev_desc[];
int sata_probe(int devnum);
int sata_remove(int devnum);
+int sata_rescan(bool verbose);
#endif
--
2.39.2
Re: [PATCH] bootstd: sata: Add bootstd support for ahci sata
Hi Simon,
On Tue, Sep 5, 2023 at 9:00 PM Tony Dinh wrote:
>
> Add ahci sata bootdev and corresponding hunting function.
>
> Signed-off-by: Tony Dinh
> ---
>
> drivers/ata/Makefile | 1 +
> drivers/ata/sata.c | 25 +++
> drivers/ata/sata_bootdev.c | 62 ++
> include/sata.h | 1 +
> 4 files changed, 89 insertions(+)
> create mode 100644 drivers/ata/sata_bootdev.c
>
> diff --git a/drivers/ata/Makefile b/drivers/ata/Makefile
> index 6e30180b8b..c1b51b5444 100644
> --- a/drivers/ata/Makefile
> +++ b/drivers/ata/Makefile
> @@ -11,6 +11,7 @@ obj-$(CONFIG_DWC_AHSATA) += dwc_ahsata.o
> obj-$(CONFIG_FSL_SATA) += fsl_sata.o
> obj-$(CONFIG_LIBATA) += libata.o
> obj-$(CONFIG_SATA) += sata.o
> +obj-$(CONFIG_BOOTSTD) += sata_bootdev.o
> obj-$(CONFIG_SATA_CEVA) += sata_ceva.o
> obj-$(CONFIG_SATA_MV) += sata_mv.o
> obj-$(CONFIG_SATA_SIL) += sata_sil.o
> diff --git a/drivers/ata/sata.c b/drivers/ata/sata.c
> index ce3e9b5a40..9da7218564 100644
> --- a/drivers/ata/sata.c
> +++ b/drivers/ata/sata.c
> @@ -15,6 +15,8 @@
> #include
> #include
> #include
> +#include
> +#include
>
> #ifndef CONFIG_AHCI
> struct blk_desc sata_dev_desc[CONFIG_SYS_SATA_MAX_DEVICE];
> @@ -50,6 +52,29 @@ int sata_scan(struct udevice *dev)
> return ops->scan(dev);
> }
>
> +int sata_rescan(bool verbose)
> +{
> + struct udevice *dev;
> + int devnum = 0;
> + int ret;
> +
> + /* Find and probing the SATA controller */
> + ret = uclass_get_device(UCLASS_AHCI, devnum, );
> +
> + /* Sanity check */
> + if (ret)
> + ret = uclass_find_first_device(UCLASS_AHCI, );
> + if (ret) {
> + printf("Cannot probe SATA device %d (err=%d)\n", devnum, ret);
> + return -ENOSYS;
> + }
> + if (!dev) {
> + printf("No SATA device found!\n");
> + return -ENOSYS;
> + }
> + return 0;
> +}
> +
> #ifndef CONFIG_AHCI
> #ifdef CONFIG_PARTITIONS
> struct blk_desc *sata_get_dev(int dev)
> diff --git a/drivers/ata/sata_bootdev.c b/drivers/ata/sata_bootdev.c
> new file mode 100644
> index 00..f638493ce0
> --- /dev/null
> +++ b/drivers/ata/sata_bootdev.c
> @@ -0,0 +1,62 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Bootdev for sata
> + *
> + * Copyright 2023 Tony Dinh
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +static int sata_bootdev_bind(struct udevice *dev)
> +{
> + struct bootdev_uc_plat *ucp = dev_get_uclass_plat(dev);
> +
> + ucp->prio = BOOTDEVP_4_SCAN_FAST;
> +
> + return 0;
> +}
> +
> +static int sata_bootdev_hunt(struct bootdev_hunter *info, bool show)
> +{
> + int ret;
> +
> + if (IS_ENABLED(CONFIG_PCI)) {
> + ret = pci_init();
> + if (ret)
> + return ret;
> + }
> +
> + ret = sata_rescan(true);
> + if (ret)
> + return ret;
> +
> + return 0;
> +}
> +
> +struct bootdev_ops sata_bootdev_ops = {
> +};
> +
> +static const struct udevice_id sata_bootdev_ids[] = {
> + { .compatible = "u-boot,bootdev-sata" },
> + { }
> +};
> +
> +U_BOOT_DRIVER(sata_bootdev) = {
> + .name = "sata_bootdev",
> + .id = UCLASS_BOOTDEV,
> + .ops= _bootdev_ops,
> + .bind = sata_bootdev_bind,
> + .of_match = sata_bootdev_ids,
> +};
> +
> +BOOTDEV_HUNTER(sata_bootdev_hunter) = {
> + .prio = BOOTDEVP_4_SCAN_FAST,
> + .uclass = UCLASS_AHCI,
> + .hunt = sata_bootdev_hunt,
> + .drv= DM_DRIVER_REF(sata_bootdev),
> +};
> diff --git a/include/sata.h b/include/sata.h
> index d89f7a8a29..0495744bad 100644
> --- a/include/sata.h
> +++ b/include/sata.h
> @@ -20,5 +20,6 @@ extern struct blk_desc sata_dev_desc[];
>
> int sata_probe(int devnum);
> int sata_remove(int devnum);
> +int sata_rescan(bool verbose);
>
> #endif
> --
> 2.39.2
>
This will need a followup patch. It's about how the distro boot
devtype is currently set to "ahci" after the bootflow scanning,
instead of "sata". For example,
load ${devtype} ${devnum}:${distro_bootpart} ${kernel_addr_r} ${uImage}
The non-scsi hdd device it must be identified as sata, like below,
load sata ${devnum}:${distro_bootpart} ${kernel_addr_r} ${uImage}
All the best,
Tony
[PATCH] arm: mvebu: sata_mv: Add bootstd hook to enable sata_bootdev
Add hook in sata_mv probe to enable bootstd bootdev.
Note: bootdev_setup_for_sibling_blk() invocation is a noop if bootsd is
not enabled for ahci sata yet.
Signed-off-by: Tony Dinh
---
drivers/ata/sata_mv.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/ata/sata_mv.c b/drivers/ata/sata_mv.c
index 18c7a66db1..55a5365b5a 100644
--- a/drivers/ata/sata_mv.c
+++ b/drivers/ata/sata_mv.c
@@ -34,6 +34,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -1104,6 +1105,12 @@ static int sata_mv_probe(struct udevice *dev)
/* TODO: undo create */
continue;
+ ret = bootdev_setup_for_sibling_blk(blk, "sata_bootdev");
+ if (ret) {
+ printf("%s: Failed to create bootdev\n", __func__);
+ continue;
+ }
+
/* If we got here, the current SATA port was probed
* successfully, so set the probe status to successful.
*/
@@ -1116,7 +1123,6 @@ static int sata_mv_probe(struct udevice *dev)
static int sata_mv_scan(struct udevice *dev)
{
/* Nothing to do here */
-
return 0;
}
--
2.39.2
[PATCH] bootstd: sata: Add bootstd support for ahci sata
Add ahci sata bootdev and corresponding hunting function.
Signed-off-by: Tony Dinh
---
drivers/ata/Makefile | 1 +
drivers/ata/sata.c | 25 +++
drivers/ata/sata_bootdev.c | 62 ++
include/sata.h | 1 +
4 files changed, 89 insertions(+)
create mode 100644 drivers/ata/sata_bootdev.c
diff --git a/drivers/ata/Makefile b/drivers/ata/Makefile
index 6e30180b8b..c1b51b5444 100644
--- a/drivers/ata/Makefile
+++ b/drivers/ata/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_DWC_AHSATA) += dwc_ahsata.o
obj-$(CONFIG_FSL_SATA) += fsl_sata.o
obj-$(CONFIG_LIBATA) += libata.o
obj-$(CONFIG_SATA) += sata.o
+obj-$(CONFIG_BOOTSTD) += sata_bootdev.o
obj-$(CONFIG_SATA_CEVA) += sata_ceva.o
obj-$(CONFIG_SATA_MV) += sata_mv.o
obj-$(CONFIG_SATA_SIL) += sata_sil.o
diff --git a/drivers/ata/sata.c b/drivers/ata/sata.c
index ce3e9b5a40..9da7218564 100644
--- a/drivers/ata/sata.c
+++ b/drivers/ata/sata.c
@@ -15,6 +15,8 @@
#include
#include
#include
+#include
+#include
#ifndef CONFIG_AHCI
struct blk_desc sata_dev_desc[CONFIG_SYS_SATA_MAX_DEVICE];
@@ -50,6 +52,29 @@ int sata_scan(struct udevice *dev)
return ops->scan(dev);
}
+int sata_rescan(bool verbose)
+{
+ struct udevice *dev;
+ int devnum = 0;
+ int ret;
+
+ /* Find and probing the SATA controller */
+ ret = uclass_get_device(UCLASS_AHCI, devnum, );
+
+ /* Sanity check */
+ if (ret)
+ ret = uclass_find_first_device(UCLASS_AHCI, );
+ if (ret) {
+ printf("Cannot probe SATA device %d (err=%d)\n", devnum, ret);
+ return -ENOSYS;
+ }
+ if (!dev) {
+ printf("No SATA device found!\n");
+ return -ENOSYS;
+ }
+ return 0;
+}
+
#ifndef CONFIG_AHCI
#ifdef CONFIG_PARTITIONS
struct blk_desc *sata_get_dev(int dev)
diff --git a/drivers/ata/sata_bootdev.c b/drivers/ata/sata_bootdev.c
new file mode 100644
index 00..f638493ce0
--- /dev/null
+++ b/drivers/ata/sata_bootdev.c
@@ -0,0 +1,62 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Bootdev for sata
+ *
+ * Copyright 2023 Tony Dinh
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+static int sata_bootdev_bind(struct udevice *dev)
+{
+ struct bootdev_uc_plat *ucp = dev_get_uclass_plat(dev);
+
+ ucp->prio = BOOTDEVP_4_SCAN_FAST;
+
+ return 0;
+}
+
+static int sata_bootdev_hunt(struct bootdev_hunter *info, bool show)
+{
+ int ret;
+
+ if (IS_ENABLED(CONFIG_PCI)) {
+ ret = pci_init();
+ if (ret)
+ return ret;
+ }
+
+ ret = sata_rescan(true);
+ if (ret)
+ return ret;
+
+ return 0;
+}
+
+struct bootdev_ops sata_bootdev_ops = {
+};
+
+static const struct udevice_id sata_bootdev_ids[] = {
+ { .compatible = "u-boot,bootdev-sata" },
+ { }
+};
+
+U_BOOT_DRIVER(sata_bootdev) = {
+ .name = "sata_bootdev",
+ .id = UCLASS_BOOTDEV,
+ .ops= _bootdev_ops,
+ .bind = sata_bootdev_bind,
+ .of_match = sata_bootdev_ids,
+};
+
+BOOTDEV_HUNTER(sata_bootdev_hunter) = {
+ .prio = BOOTDEVP_4_SCAN_FAST,
+ .uclass = UCLASS_AHCI,
+ .hunt = sata_bootdev_hunt,
+ .drv= DM_DRIVER_REF(sata_bootdev),
+};
diff --git a/include/sata.h b/include/sata.h
index d89f7a8a29..0495744bad 100644
--- a/include/sata.h
+++ b/include/sata.h
@@ -20,5 +20,6 @@ extern struct blk_desc sata_dev_desc[];
int sata_probe(int devnum);
int sata_remove(int devnum);
+int sata_rescan(bool verbose);
#endif
--
2.39.2
Re: [PATCH] bootstd: Drop some TODOs
Hi Simon, On Fri, Aug 25, 2023 at 5:51 PM Tony Dinh wrote: > > Hi Simon, > > On Fri, Aug 25, 2023 at 4:53 PM Simon Glass wrote: > > > > Hi Tony, > > > > On Fri, 25 Aug 2023 at 14:17, Tony Dinh wrote: > > > > > > Hi Simon, > > > > > > On Thu, Aug 24, 2023 at 6:48 PM Simon Glass wrote: > > > > > > > > The existing TODOs are done, so remove them. Add another that came up > > > > today. > > > > > > > > Signed-off-by: Simon Glass > > > > --- > > > > > > > > doc/develop/bootstd.rst | 4 +--- > > > > 1 file changed, 1 insertion(+), 3 deletions(-) > > > > > > > > diff --git a/doc/develop/bootstd.rst b/doc/develop/bootstd.rst > > > > index ec3136535783..3e566e994d6c 100644 > > > > --- a/doc/develop/bootstd.rst > > > > +++ b/doc/develop/bootstd.rst > > > > @@ -752,9 +752,7 @@ To do > > > > > > > > Some things that need to be done to completely replace the distro-boot > > > > scripts: > > > > > > > > -- add bootdev drivers for dhcp, sata, scsi, ide, virtio > > > > > > Good to see SATA finally in bootdev driver! I'm testing bootstd on a > > > couple boards, and have been waiting for SATA bootdev. Any idea, if I > > > should wait for it to be merged to the next branch, or is there an > > > easy way to do it with one of your patches (I can test it on the > > > latest master branch or next branch). > > > > I believe it went in in the last release - see drivers/scsi/scsi_bootdev.c > > > > If you need something else for SATA, PLMK. > > I see. That's scsi_bootdev for the scsi driver. I think we also need > sata_bootdev for drivers/ata/. For example, the Marvell Kirkwood SoC > boards use sata_mv. I took a close look in the drivers/ata/ directory. Most drivers are using ahci scsi, so they are OK. But the following drivers are ahci but not using scsi: fsl_sata.c sata_sil.c sata_mv.c That TODO item should remain and changed to: -- add bootdev driver for sata All the best, Tony > > Thanks, > Tony > > > > > Regards, > > Simon > > > > > > > > > > Thanks, > > > Tony > > > > > > > -- PXE boot for EFI > > > > -- support for loading U-Boot scripts > > > > +- implement extensions (devicetree overlays with add-on boards) > > > > > > > > Other ideas: > > > > > > > > -- > > > > 2.42.0.rc1.204.g551eb34607-goog > > > >
Re: [PATCH] arm: kirkwood: Add support for ZyXEL NSA325 board
Hi Stefan,
For unknown reasons (probably Gmail glitches), I did not receive your
email review in this thread. But I did receive the other email review
for the Pogo V4 LTO! lore.kernel.org is OK.
https://lore.kernel.org/u-boot/65ab8aa6-c290-0649-0b2e-374c4f84e...@denx.de/T/#mf17689e3e963ab7a34fda34a97f67dea7a877b65
Stefan: "Just checking: Are the DT files imported from the Linux ones?"
Yes, these DT files were copied verbatim from Linux. That's why we see
some minor warnings about styles.
All the best,
Tony
On Fri, Aug 25, 2023 at 8:33 PM Tony Dinh wrote:
>
> ZyXEL NSA325 specifications:
>
> Marvell Kirkwood 88F6282 SoC
> 1.6 GHz CPU
> 1x GBE LAN port (Marvell MV88E1318)
> 512 MB RAM
> 128 MB Eon NAND, SLC
> I2C
> 1x USB 3.0 (on PCIe bus)
> 2x USB 2.0
> 2x SATA (hot swap slots)
> Serial console
>
> Signed-off-by: Tony Dinh
> ---
>
> arch/arm/dts/Makefile| 1 +
> arch/arm/dts/kirkwood-6282.dtsi | 161
> arch/arm/dts/kirkwood-nsa325.dts | 231 +++
> arch/arm/dts/kirkwood-nsa3x0-common.dtsi | 157 +++
> arch/arm/mach-kirkwood/Kconfig | 7 +
> board/zyxel/nsa325/Kconfig | 12 ++
> board/zyxel/nsa325/MAINTAINERS | 9 +
> board/zyxel/nsa325/Makefile | 11 ++
> board/zyxel/nsa325/kwbimage.cfg | 55 ++
> board/zyxel/nsa325/nsa325.c | 196 +++
> configs/nsa325_defconfig | 81
> include/configs/nsa325.h | 37
> 12 files changed, 958 insertions(+)
> create mode 100644 arch/arm/dts/kirkwood-6282.dtsi
> create mode 100644 arch/arm/dts/kirkwood-nsa325.dts
> create mode 100644 arch/arm/dts/kirkwood-nsa3x0-common.dtsi
> create mode 100644 board/zyxel/nsa325/Kconfig
> create mode 100644 board/zyxel/nsa325/MAINTAINERS
> create mode 100644 board/zyxel/nsa325/Makefile
> create mode 100644 board/zyxel/nsa325/kwbimage.cfg
> create mode 100644 board/zyxel/nsa325/nsa325.c
> create mode 100644 configs/nsa325_defconfig
> create mode 100644 include/configs/nsa325.h
>
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index 85fd5b1157..b9fc46544f 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -66,6 +66,7 @@ dtb-$(CONFIG_ARCH_KIRKWOOD) += \
> kirkwood-ns2max.dtb \
> kirkwood-ns2mini.dtb \
> kirkwood-nsa310s.dtb \
> + kirkwood-nsa325.dtb \
> kirkwood-openrd-base.dtb \
> kirkwood-openrd-client.dtb \
> kirkwood-openrd-ultimate.dtb \
> diff --git a/arch/arm/dts/kirkwood-6282.dtsi b/arch/arm/dts/kirkwood-6282.dtsi
> new file mode 100644
> index 00..e732c501ea
> --- /dev/null
> +++ b/arch/arm/dts/kirkwood-6282.dtsi
> @@ -0,0 +1,161 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/ {
> + mbus@f100 {
> + pciec: pcie@8200 {
> + compatible = "marvell,kirkwood-pcie";
> + status = "disabled";
> + device_type = "pci";
> +
> + #address-cells = <3>;
> + #size-cells = <2>;
> +
> + bus-range = <0x00 0xff>;
> +
> + ranges =
> + <0x8200 0 0x4 MBUS_ID(0xf0, 0x01)
> 0x4 0 0x2000
> + 0x8200 0 0x44000 MBUS_ID(0xf0, 0x01)
> 0x44000 0 0x2000
> + 0x8200 0 0x8 MBUS_ID(0xf0, 0x01)
> 0x8 0 0x2000
> + 0x8200 0x1 0 MBUS_ID(0x04, 0xe8) 0
>1 0 /* Port 0.0 MEM */
> + 0x8100 0x1 0 MBUS_ID(0x04, 0xe0) 0
>1 0 /* Port 0.0 IO */
> + 0x8200 0x2 0 MBUS_ID(0x04, 0xd8) 0
>1 0 /* Port 1.0 MEM */
> + 0x8100 0x2 0 MBUS_ID(0x04, 0xd0) 0
>1 0 /* Port 1.0 IO */>;
> +
> + pcie0: pcie@1,0 {
> + device_type = "pci";
> + assigned-addresses = <0x82000800 0 0x0004
> 0 0x2000>;
> + reg = <0x0800 0 0 0 0>;
> + #address-cells = <3>;
> + #size-cells = <2>;
> + #interrupt-cells = <1>;
> + ranges = <0x8200 0 0 0x8200 0x1 0 1 0
> + 0x8100 0 0 0x8100 0
[PATCH] arm: kirkwood: Add support for ZyXEL NSA325 board
ZyXEL NSA325 specifications:
Marvell Kirkwood 88F6282 SoC
1.6 GHz CPU
1x GBE LAN port (Marvell MV88E1318)
512 MB RAM
128 MB Eon NAND, SLC
I2C
1x USB 3.0 (on PCIe bus)
2x USB 2.0
2x SATA (hot swap slots)
Serial console
Signed-off-by: Tony Dinh
---
arch/arm/dts/Makefile| 1 +
arch/arm/dts/kirkwood-6282.dtsi | 161
arch/arm/dts/kirkwood-nsa325.dts | 231 +++
arch/arm/dts/kirkwood-nsa3x0-common.dtsi | 157 +++
arch/arm/mach-kirkwood/Kconfig | 7 +
board/zyxel/nsa325/Kconfig | 12 ++
board/zyxel/nsa325/MAINTAINERS | 9 +
board/zyxel/nsa325/Makefile | 11 ++
board/zyxel/nsa325/kwbimage.cfg | 55 ++
board/zyxel/nsa325/nsa325.c | 196 +++
configs/nsa325_defconfig | 81
include/configs/nsa325.h | 37
12 files changed, 958 insertions(+)
create mode 100644 arch/arm/dts/kirkwood-6282.dtsi
create mode 100644 arch/arm/dts/kirkwood-nsa325.dts
create mode 100644 arch/arm/dts/kirkwood-nsa3x0-common.dtsi
create mode 100644 board/zyxel/nsa325/Kconfig
create mode 100644 board/zyxel/nsa325/MAINTAINERS
create mode 100644 board/zyxel/nsa325/Makefile
create mode 100644 board/zyxel/nsa325/kwbimage.cfg
create mode 100644 board/zyxel/nsa325/nsa325.c
create mode 100644 configs/nsa325_defconfig
create mode 100644 include/configs/nsa325.h
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 85fd5b1157..b9fc46544f 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -66,6 +66,7 @@ dtb-$(CONFIG_ARCH_KIRKWOOD) += \
kirkwood-ns2max.dtb \
kirkwood-ns2mini.dtb \
kirkwood-nsa310s.dtb \
+ kirkwood-nsa325.dtb \
kirkwood-openrd-base.dtb \
kirkwood-openrd-client.dtb \
kirkwood-openrd-ultimate.dtb \
diff --git a/arch/arm/dts/kirkwood-6282.dtsi b/arch/arm/dts/kirkwood-6282.dtsi
new file mode 100644
index 00..e732c501ea
--- /dev/null
+++ b/arch/arm/dts/kirkwood-6282.dtsi
@@ -0,0 +1,161 @@
+// SPDX-License-Identifier: GPL-2.0
+/ {
+ mbus@f100 {
+ pciec: pcie@8200 {
+ compatible = "marvell,kirkwood-pcie";
+ status = "disabled";
+ device_type = "pci";
+
+ #address-cells = <3>;
+ #size-cells = <2>;
+
+ bus-range = <0x00 0xff>;
+
+ ranges =
+ <0x8200 0 0x4 MBUS_ID(0xf0, 0x01)
0x4 0 0x2000
+ 0x8200 0 0x44000 MBUS_ID(0xf0, 0x01)
0x44000 0 0x2000
+ 0x8200 0 0x8 MBUS_ID(0xf0, 0x01)
0x8 0 0x2000
+ 0x8200 0x1 0 MBUS_ID(0x04, 0xe8) 0
1 0 /* Port 0.0 MEM */
+ 0x8100 0x1 0 MBUS_ID(0x04, 0xe0) 0
1 0 /* Port 0.0 IO */
+ 0x8200 0x2 0 MBUS_ID(0x04, 0xd8) 0
1 0 /* Port 1.0 MEM */
+ 0x8100 0x2 0 MBUS_ID(0x04, 0xd0) 0
1 0 /* Port 1.0 IO */>;
+
+ pcie0: pcie@1,0 {
+ device_type = "pci";
+ assigned-addresses = <0x82000800 0 0x0004 0
0x2000>;
+ reg = <0x0800 0 0 0 0>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ #interrupt-cells = <1>;
+ ranges = <0x8200 0 0 0x8200 0x1 0 1 0
+ 0x8100 0 0 0x8100 0x1 0 1 0>;
+ bus-range = <0x00 0xff>;
+ interrupt-names = "intx", "error";
+ interrupts = <9>, <44>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = <0 0 0 1 _intc 0>,
+ <0 0 0 2 _intc 1>,
+ <0 0 0 3 _intc 2>,
+ <0 0 0 4 _intc 3>;
+ marvell,pcie-port = <0>;
+ marvell,pcie-lane = <0>;
+ clocks = <_clk 2>;
+ status = "disabled";
+
+ pcie0_intc: interrupt-controller {
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ };
+
Re: [PATCH] bootstd: Drop some TODOs
Hi Simon, On Fri, Aug 25, 2023 at 4:53 PM Simon Glass wrote: > > Hi Tony, > > On Fri, 25 Aug 2023 at 14:17, Tony Dinh wrote: > > > > Hi Simon, > > > > On Thu, Aug 24, 2023 at 6:48 PM Simon Glass wrote: > > > > > > The existing TODOs are done, so remove them. Add another that came up > > > today. > > > > > > Signed-off-by: Simon Glass > > > --- > > > > > > doc/develop/bootstd.rst | 4 +--- > > > 1 file changed, 1 insertion(+), 3 deletions(-) > > > > > > diff --git a/doc/develop/bootstd.rst b/doc/develop/bootstd.rst > > > index ec3136535783..3e566e994d6c 100644 > > > --- a/doc/develop/bootstd.rst > > > +++ b/doc/develop/bootstd.rst > > > @@ -752,9 +752,7 @@ To do > > > > > > Some things that need to be done to completely replace the distro-boot > > > scripts: > > > > > > -- add bootdev drivers for dhcp, sata, scsi, ide, virtio > > > > Good to see SATA finally in bootdev driver! I'm testing bootstd on a > > couple boards, and have been waiting for SATA bootdev. Any idea, if I > > should wait for it to be merged to the next branch, or is there an > > easy way to do it with one of your patches (I can test it on the > > latest master branch or next branch). > > I believe it went in in the last release - see drivers/scsi/scsi_bootdev.c > > If you need something else for SATA, PLMK. I see. That's scsi_bootdev for the scsi driver. I think we also need sata_bootdev for drivers/ata/. For example, the Marvell Kirkwood SoC boards use sata_mv. Thanks, Tony > > Regards, > Simon > > > > > > Thanks, > > Tony > > > > > -- PXE boot for EFI > > > -- support for loading U-Boot scripts > > > +- implement extensions (devicetree overlays with add-on boards) > > > > > > Other ideas: > > > > > > -- > > > 2.42.0.rc1.204.g551eb34607-goog > > >
Re: [PATCH] bootstd: Drop some TODOs
Hi Simon, On Thu, Aug 24, 2023 at 6:48 PM Simon Glass wrote: > > The existing TODOs are done, so remove them. Add another that came up > today. > > Signed-off-by: Simon Glass > --- > > doc/develop/bootstd.rst | 4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) > > diff --git a/doc/develop/bootstd.rst b/doc/develop/bootstd.rst > index ec3136535783..3e566e994d6c 100644 > --- a/doc/develop/bootstd.rst > +++ b/doc/develop/bootstd.rst > @@ -752,9 +752,7 @@ To do > > Some things that need to be done to completely replace the distro-boot > scripts: > > -- add bootdev drivers for dhcp, sata, scsi, ide, virtio Good to see SATA finally in bootdev driver! I'm testing bootstd on a couple boards, and have been waiting for SATA bootdev. Any idea, if I should wait for it to be merged to the next branch, or is there an easy way to do it with one of your patches (I can test it on the latest master branch or next branch). Thanks, Tony > -- PXE boot for EFI > -- support for loading U-Boot scripts > +- implement extensions (devicetree overlays with add-on boards) > > Other ideas: > > -- > 2.42.0.rc1.204.g551eb34607-goog >
[PATCH] arm: kirkwood: Pogo v4: Enable LTO
Enable building Pogo V4 u-boot image with LTO, which results in about 30K reduction in size. Signed-off-by: Tony Dinh --- configs/pogo_v4_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/pogo_v4_defconfig b/configs/pogo_v4_defconfig index 3e3e811543..ad36da712b 100644 --- a/configs/pogo_v4_defconfig +++ b/configs/pogo_v4_defconfig @@ -16,6 +16,7 @@ CONFIG_DEFAULT_DEVICE_TREE="kirkwood-pogoplug-series-4" CONFIG_SYS_PROMPT="Pogo_V4> " CONFIG_IDENT_STRING="\nPogoplug V4" CONFIG_SYS_LOAD_ADDR=0x80 +CONFIG_LTO=y CONFIG_PCI=y CONFIG_DISTRO_DEFAULTS=y CONFIG_BOOTSTAGE=y -- 2.39.2
Re: [PATCH] arm: Use builtins for ffs/fls
Hi Sean,
On Mon, Jul 31, 2023 at 2:28 PM Sean Anderson wrote:
>
> Since ARMv5, the clz instruction allows for efficient implementation of
> ffs/fls with builtins. Until ARMv7 (with Thumb-2), this instruction is
> only available in ARM mode. LTO makes it difficult to force specific
> functions to be in ARM mode, as it is effectively a form of very
> aggressive inlining. To work around this, fls/ffs are implemented in
> assembly for ARMv5 and ARMv6 when compiling U-Boot in Thumb mode.
> Overall, this saves around 75 bytes per call.
>
> Signed-off-by: Sean Anderson
> ---
> I only tested this on ARMv8. If someone has an ARMv5 or ARMv6 board,
> please test this.
Thanks for the patch! I've tested it with the Pogo V4 board (Kirkwood
88F6192, ARMv5) with LTO and SYS_THUMB_BUILD.
Also nice size reduction:
Before: 502K
After: 499K
So for ARMv5,
Tested-by: Tony Dinh
All the best,
Tony
>
> arch/arm/include/asm/bitops.h | 27 -
> arch/arm/lib/Makefile | 5 +++
> arch/arm/lib/bitops.S | 45 ++
> include/asm-generic/bitops/builtin-__ffs.h | 16
> include/asm-generic/bitops/builtin-__fls.h | 16
> include/asm-generic/bitops/builtin-ffs.h | 15
> include/asm-generic/bitops/builtin-fls.h | 17
> 7 files changed, 140 insertions(+), 1 deletion(-)
> create mode 100644 arch/arm/lib/bitops.S
> create mode 100644 include/asm-generic/bitops/builtin-__ffs.h
> create mode 100644 include/asm-generic/bitops/builtin-__fls.h
> create mode 100644 include/asm-generic/bitops/builtin-ffs.h
> create mode 100644 include/asm-generic/bitops/builtin-fls.h
>
> diff --git a/arch/arm/include/asm/bitops.h b/arch/arm/include/asm/bitops.h
> index fa8548624a..8e897833bb 100644
> --- a/arch/arm/include/asm/bitops.h
> +++ b/arch/arm/include/asm/bitops.h
> @@ -15,9 +15,34 @@
> #ifndef __ASM_ARM_BITOPS_H
> #define __ASM_ARM_BITOPS_H
>
> +#if __LINUX_ARM_ARCH__ < 5
> +
> #include
> #include
> #include
> +
> +#else
> +
> +#define PLATFORM_FFS
> +#define PLATFORM_FLS
> +
> +#if !IS_ENABLED(CONFIG_HAS_THUMB2) && CONFIG_IS_ENABLED(SYS_THUMB_BUILD)
> +
> +unsigned long __fls(unsigned long word);
> +unsigned long __ffs(unsigned long word);
> +int fls(unsigned int x);
> +int ffs(int x);
> +
> +#else
> +
> +#include
> +#include
> +#include
> +#include
> +
> +#endif
> +#endif
> +
> #include
>
> #ifdef __KERNEL__
> @@ -113,7 +138,7 @@ static inline int test_bit(int nr, const void * addr)
>
> static inline int __ilog2(unsigned int x)
> {
> - return generic_fls(x) - 1;
> + return fls(x) - 1;
> }
>
> #define ffz(x) __ffs(~(x))
> diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile
> index 62cf80f373..b1bcd37466 100644
> --- a/arch/arm/lib/Makefile
> +++ b/arch/arm/lib/Makefile
> @@ -113,6 +113,11 @@ AFLAGS_REMOVE_memset.o := -mthumb -mthumb-interwork
> AFLAGS_REMOVE_memcpy.o := -mthumb -mthumb-interwork
> AFLAGS_memset.o := -DMEMSET_NO_THUMB_BUILD
> AFLAGS_memcpy.o := -DMEMCPY_NO_THUMB_BUILD
> +
> +# This is only necessary to force ARM mode on THUMB1 targets.
> +ifneq ($(CONFIG_SYS_ARM_ARCH),4)
> +obj-y += bitops.o
> +endif
> endif
> endif
>
> diff --git a/arch/arm/lib/bitops.S b/arch/arm/lib/bitops.S
> new file mode 100644
> index 00..29d1524634
> --- /dev/null
> +++ b/arch/arm/lib/bitops.S
> @@ -0,0 +1,45 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Copyright (C) 2023 Sean Anderson
> + *
> + * ARM bitops to call when using THUMB1, which doesn't have these
> instructions.
> + */
> +#include
> +#include
> +
> +.pushsection .text.__fls
> +ENTRY(__fls)
> + clz r0, r0
> + rsb r0, r0, #31
> + ret lr
> +ENDPROC(__fls)
> +.popsection
> +
> +.pushsection .text.__ffs
> +ENTRY(__ffs)
> + rsb r3, r0, #0
> + and r0, r0, r3
> + clz r0, r0
> + rsb r0, r0, #31
> + ret lr
> +ENDPROC(__ffs)
> +.popsection
> +
> +.pushsection .text.fls
> +ENTRY(fls)
> + cmp r0, #0
> + clzne r0, r0
> + rsbne r0, r0, #32
> + ret lr
> +ENDPROC(fls)
> +.popsection
> +
> +.pushsection .text.ffs
> +ENTRY(ffs)
> + rsb r3, r0, #0
> + and r0, r0, r3
> + clz r0, r0
> + rsb r0, r0, #32
> + ret lr
> +ENDPROC(ffs)
> +.popsection
> diff --git a/include/asm-generic/bitops/builtin-__ffs.h
> b/include/asm-generic/bitops/builtin-__ffs.h
> new file mode 100644
> index 00..87024da44d
Re: [PATCH] kirkwood: dns325: Enable 2nd harddrive
On Fri, Aug 11, 2023 at 3:02 PM Stefan Roese wrote: > > The 2nd HD is not enabled in U-Boot on the D-Link DNS325. This patch > sets the responsible GPIO to high, enabling the drive. > > Suggested-by: Peter Granilla > Signed-off-by: Stefan Roese > Cc: Tom Rini > --- > board/d-link/dns325/dns325.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/board/d-link/dns325/dns325.c b/board/d-link/dns325/dns325.c > index 055783f63ada..8ebfe4c60189 100644 > --- a/board/d-link/dns325/dns325.c > +++ b/board/d-link/dns325/dns325.c > @@ -89,6 +89,7 @@ int board_early_init_f(void) > kw_gpio_set_blink(DNS325_GPIO_LED_POWER , 1); > > kw_gpio_set_value(DNS325_GPIO_SATA0_EN , 1); > + kw_gpio_set_value(DNS325_GPIO_SATA1_EN , 1); > return 0; > } > > -- > 2.41.0 > Reviewed-by: Tony Dinh All the best, Tony
Re: F2-NAS2 and NSA325 contributions
Hi Henry, On Thu, Jun 29, 2023 at 7:52 PM Henry Smith wrote: > > Oh hello! > > Nice to hear from the person I wanted to contact. I based my work on > your fork of the marvell repo. > My priority is to get the new device into the tree so I don't lose it > and other people can benefit. Please proceed at your own pace. > Whatever you contributed to 2023 can be considered at a later time. > > I have a branch that compiles and boots on F2-NAS2 from TerraMaster. > Powering the thing off, wakeup on a schedule and RTC is implemented > through an extra uC, on/off button is not connected to the SoC I > think. On the NSA325, the Power button is connected to gpio1 14 (mpp 46). It sounds like the F2-NAS2 is using the UART1 port for that purpose instead. I came across a few boards like that. > This uC is most likely connected to SoC via UART1 and receives > commands from a small daemon controlled by a tiny client program. I > wanted to make sure this is not something that would prevent you from > accepting a new board. > It does turn on. Pressing the power button when the device is on shuts > the power off after 5-10s. Time is never set either so I used ntp. Now Don't know about the F2-NAS2 , but the NSA325 has RTC (PCF8563 chip), and it is already supported by current u-boot. > I see u-boot supports that as well but unsure if that would somehow > get passed to the kernel with no real RTC. For these things to work, > the serial commands would have to get deciphered and implemented in > u-boot itself or the OS like it is in TOS from the vendor. I can try > to do it or disassemble at a later time. > If there is no RTC on the F2-NAS2, you can use CONFIG_RTC_EMULATION and CONFIG_CMD_SNTP. But rootfs will need fake-hwclock anyway.. All the best, Tony > czw., 29 cze 2023 o 21:01 Tony Dinh napisał(a): > > > > Hi Henry, > > > > On Thu, Jun 29, 2023 at 6:53 PM Tony Dinh wrote: > > > > > > Hi Heny, > > > > > > On Thu, Jun 29, 2023 at 6:01 PM Henry Smith wrote: > > > > > > > > Hello, > > > > > > > > I'm a hobbyist that has been playing with Linkstation LS-WVL years > > > > ago. After frying UART on that, I got Terramaster F2-NAS2 later and > > > > got u-boot from the main tree to work on it. > > > > > > > > Both landed in the closet until I dug up F2-NAS2 recently. My original > > > > source code modifications and images were nowhere to be found so I > > > > started from scratch. > > > > > > > > First tried to compile and run every defconfig available that uses > > > > Kirkwood SoC: > > > > u-boot # for config in $(grep -i kirkwood ./configs -r | cut -d ":" > > > > -f1 | cut -d "/" -f3 | sort -u); do make clean; make distclean; > > > > ARCH=arm CROSS_COMPILE=arm-none-eabi- make $config && ARCH=arm > > > > CROSS_COMPILE=arm-none-eabi- make -j64; echo $config; read; done > > > > > > > > Unfortunately, that didn't work. Then I saw the following: > > > > "...By the way this box is a close cousin of the NSA325 (Kirkwood)..." > > > > Source: > > > > https://forum.doozan.com/read.php?3,49804,49964#msg-49964 > > > > > > > > With that in mind, I've found the first compiled version I could lay > > > > my hands on: > > > > https://forum.doozan.com/read.php?3,12381 > > > > Actual file: > > > > https://bitly.com/2xnfGmv > > > > > > > > The file worked, here is the source: > > > > https://github.com/mibodhi/u-boot-kirkwood > > > > > > > > > > That is my Kirkwood u-boot GitHub for 2017.07. So it would not compile > > > with current u-boot. > > > > > > > The thing didn't compile and threw errors about libfdt: > > > > https://github.com/hardkernel/u-boot/issues/73 > > > > > > > > This is when I started porting it to the main u-boot tree from that > > > > fork. I got it to boot on Terramaster F2-NAS2. > > > > > > > > To continue, I have 2 questions: > > > > 1) Original changes ported to the original tree were for NSA325. Can > > > > somebody test them on their own box or that's not something you would > > > > do? > > > > > > I've planned to add support to mainline u-boot for ZyXEL NSA325 board. > > > But I've been busy for a while so have not got time to do it. I've > > > already released the u-boot 2023.04. binary in doozan forum. > > > > > > https://forum.doozan.com/read.ph
Re: F2-NAS2 and NSA325 contributions
Hi Henry, On Thu, Jun 29, 2023 at 6:53 PM Tony Dinh wrote: > > Hi Heny, > > On Thu, Jun 29, 2023 at 6:01 PM Henry Smith wrote: > > > > Hello, > > > > I'm a hobbyist that has been playing with Linkstation LS-WVL years > > ago. After frying UART on that, I got Terramaster F2-NAS2 later and > > got u-boot from the main tree to work on it. > > > > Both landed in the closet until I dug up F2-NAS2 recently. My original > > source code modifications and images were nowhere to be found so I > > started from scratch. > > > > First tried to compile and run every defconfig available that uses Kirkwood > > SoC: > > u-boot # for config in $(grep -i kirkwood ./configs -r | cut -d ":" > > -f1 | cut -d "/" -f3 | sort -u); do make clean; make distclean; > > ARCH=arm CROSS_COMPILE=arm-none-eabi- make $config && ARCH=arm > > CROSS_COMPILE=arm-none-eabi- make -j64; echo $config; read; done > > > > Unfortunately, that didn't work. Then I saw the following: > > "...By the way this box is a close cousin of the NSA325 (Kirkwood)..." > > Source: > > https://forum.doozan.com/read.php?3,49804,49964#msg-49964 > > > > With that in mind, I've found the first compiled version I could lay > > my hands on: > > https://forum.doozan.com/read.php?3,12381 > > Actual file: > > https://bitly.com/2xnfGmv > > > > The file worked, here is the source: > > https://github.com/mibodhi/u-boot-kirkwood > > > > That is my Kirkwood u-boot GitHub for 2017.07. So it would not compile > with current u-boot. > > > The thing didn't compile and threw errors about libfdt: > > https://github.com/hardkernel/u-boot/issues/73 > > > > This is when I started porting it to the main u-boot tree from that > > fork. I got it to boot on Terramaster F2-NAS2. > > > > To continue, I have 2 questions: > > 1) Original changes ported to the original tree were for NSA325. Can > > somebody test them on their own box or that's not something you would > > do? > > I've planned to add support to mainline u-boot for ZyXEL NSA325 board. > But I've been busy for a while so have not got time to do it. I've > already released the u-boot 2023.04. binary in doozan forum. > > https://forum.doozan.com/read.php?3,12381 > "2023.04 U-Boot Kirkwood - ZyXEL NSA325. This version adds the > capability of booting with the rootfs attached to the USB 3.0 port in > the front, among other capabilities" > > > 2) I have changes for Terramaster F2-NAS2 derived from #1 as well. How > > do I submit them since the PR pointed me to the mailing list: > > https://github.com/u-boot/u-boot/pull/326 > > Perhaps, you could wait until I send the NSA325 patch to this ML. And > then use that as a template to create the patch for F2-NAS2? We only > submit patches using the mailing list. And the patch will be reviewed > by Stefan and/or others. Of course it's up to you, but I think it > might be best that we could collaborate. > > All the best, > Tony > > > > > Please do not look at the changes in the PR, they are old and > > irrelevant. I will close or update it, depending on what I hear back. > > > > Best, > > > > - Henry Sorry I've misspelled your name previously :) And also just to let you know that I'll be quite occupied with work in the next several weeks, so I might not be able to follow up right away. All the best, Tony
Re: F2-NAS2 and NSA325 contributions
Hi Heny, On Thu, Jun 29, 2023 at 6:01 PM Henry Smith wrote: > > Hello, > > I'm a hobbyist that has been playing with Linkstation LS-WVL years > ago. After frying UART on that, I got Terramaster F2-NAS2 later and > got u-boot from the main tree to work on it. > > Both landed in the closet until I dug up F2-NAS2 recently. My original > source code modifications and images were nowhere to be found so I > started from scratch. > > First tried to compile and run every defconfig available that uses Kirkwood > SoC: > u-boot # for config in $(grep -i kirkwood ./configs -r | cut -d ":" > -f1 | cut -d "/" -f3 | sort -u); do make clean; make distclean; > ARCH=arm CROSS_COMPILE=arm-none-eabi- make $config && ARCH=arm > CROSS_COMPILE=arm-none-eabi- make -j64; echo $config; read; done > > Unfortunately, that didn't work. Then I saw the following: > "...By the way this box is a close cousin of the NSA325 (Kirkwood)..." > Source: > https://forum.doozan.com/read.php?3,49804,49964#msg-49964 > > With that in mind, I've found the first compiled version I could lay > my hands on: > https://forum.doozan.com/read.php?3,12381 > Actual file: > https://bitly.com/2xnfGmv > > The file worked, here is the source: > https://github.com/mibodhi/u-boot-kirkwood > That is my Kirkwood u-boot GitHub for 2017.07. So it would not compile with current u-boot. > The thing didn't compile and threw errors about libfdt: > https://github.com/hardkernel/u-boot/issues/73 > > This is when I started porting it to the main u-boot tree from that > fork. I got it to boot on Terramaster F2-NAS2. > > To continue, I have 2 questions: > 1) Original changes ported to the original tree were for NSA325. Can > somebody test them on their own box or that's not something you would > do? I've planned to add support to mainline u-boot for ZyXEL NSA325 board. But I've been busy for a while so have not got time to do it. I've already released the u-boot 2023.04. binary in doozan forum. https://forum.doozan.com/read.php?3,12381 "2023.04 U-Boot Kirkwood - ZyXEL NSA325. This version adds the capability of booting with the rootfs attached to the USB 3.0 port in the front, among other capabilities" > 2) I have changes for Terramaster F2-NAS2 derived from #1 as well. How > do I submit them since the PR pointed me to the mailing list: > https://github.com/u-boot/u-boot/pull/326 Perhaps, you could wait until I send the NSA325 patch to this ML. And then use that as a template to create the patch for F2-NAS2? We only submit patches using the mailing list. And the patch will be reviewed by Stefan and/or others. Of course it's up to you, but I think it might be best that we could collaborate. All the best, Tony > > Please do not look at the changes in the PR, they are old and > irrelevant. I will close or update it, depending on what I hear back. > > Best, > > - Henry
[Test] arm: mvebu: PCI_MVEBU driver on Kirkwood boards
Hi Pali, FYI. In reference to this patch: https://lore.kernel.org/all/20230114164125.1298-1-p...@kernel.org/ Recently, I built a new Linux kernel 6.3.x for the Kirkwood boards and discovered that the PCI_MVEBU driver was marked as BROKEN in Linux mainline. That was a surprise for me, since I've been running this driver for a long time up to kernel 6.1.x, 6.2.x for Kirkwood boards that support USB 3.0 on PCIe bus. I did not see any problem. I've just removed the CONGIG_BROKEN in my build and am running kernel 6.3.8 currently. Unfortunately, I don't have any Marvell Armada board that uses PCIe for USB 3.0 to test with. As far as I can tell, the u-boot PCI_MVEBU driver also works fine on Kirkwood boards. All the best, Tony
[PATCH] arm: mvebu: Enable gpio-fan for Thecus N2350 board
Add gpio-fan in the DTS and enable the GPIO in board file to start the fan
during boot.
Note that this patch depends on
https://patchwork.ozlabs.org/project/uboot/patch/20230606214539.4229-1-mibo...@gmail.com/
Signed-off-by: Tony Dinh
---
arch/arm/dts/armada-385-thecus-n2350.dts | 15 +++
board/thecus/n2350/n2350.c | 2 +-
2 files changed, 16 insertions(+), 1 deletion(-)
diff --git a/arch/arm/dts/armada-385-thecus-n2350.dts
b/arch/arm/dts/armada-385-thecus-n2350.dts
index 2ad5158c0c..253cf01130 100644
--- a/arch/arm/dts/armada-385-thecus-n2350.dts
+++ b/arch/arm/dts/armada-385-thecus-n2350.dts
@@ -140,6 +140,16 @@
};
};
+ fan {
+ compatible = "gpio-fan";
+ gpios = < 16 GPIO_ACTIVE_HIGH>;
+ gpio-fan,speed-map = <0 0
+ 600 1
+ 3000 2 >;
+ pinctrl-0 = <_fan>;
+ pinctrl-names = "default";
+ };
+
usb3_0_power: v5-vbus0 {
compatible = "regulator-fixed";
regulator-name = "USB3_0_Power";
@@ -378,6 +388,11 @@
marvell,pins = "mpp17";
marvell,function = "gpio";
};
+
+ pmx_fan: pmx-fan {
+ marvell,pins = "mpp48";
+ marvell,function = "gpio";
+ };
};
{
diff --git a/board/thecus/n2350/n2350.c b/board/thecus/n2350/n2350.c
index fd8f95f944..05b125fd7f 100644
--- a/board/thecus/n2350/n2350.c
+++ b/board/thecus/n2350/n2350.c
@@ -25,7 +25,7 @@ DECLARE_GLOBAL_DATA_PTR;
#define N2350_GPP_OUT_ENA_LOW (~(BIT(20) | BIT(21) | BIT(24)))
#define N2350_GPP_OUT_ENA_MID (~(BIT(12) | BIT(13) | BIT(16) | BIT(19) |
BIT(22)))
#define N2350_GPP_OUT_VAL_LOW (BIT(21) | BIT(24))
-#define N2350_GPP_OUT_VAL_MID (BIT(0) | BIT(12) | BIT(13))
+#define N2350_GPP_OUT_VAL_MID (BIT(0) | BIT(12) | BIT(13) | BIT(16))
#define N2350_GPP_POL_LOW 0x0
#define N2350_GPP_POL_MID 0x0
--
2.39.2
[PATCH] arm: mvebu: Clean up Thecus N2350 board DTS
- Update the Thecus N2350 DTS to conform with latest device-tree binding
and styles.
- Correct typo in mdio node.
Signed-off-by: Tony Dinh
---
arch/arm/dts/armada-385-thecus-n2350.dts | 210 +++
1 file changed, 98 insertions(+), 112 deletions(-)
diff --git a/arch/arm/dts/armada-385-thecus-n2350.dts
b/arch/arm/dts/armada-385-thecus-n2350.dts
index fc29c4d25a..2ad5158c0c 100644
--- a/arch/arm/dts/armada-385-thecus-n2350.dts
+++ b/arch/arm/dts/armada-385-thecus-n2350.dts
@@ -23,7 +23,7 @@
stdout-path = "serial0:115200n8";
};
- memory {
+ memory@0 {
device_type = "memory";
reg = <0x 0x4000>; /* 1GB */
};
@@ -37,43 +37,43 @@
};
- usb3_0_phy: usb3_0_phy {
+ usb3_0_phy: usb-phy {
compatible = "usb-nop-xceiv";
vcc-supply = <_0_power>;
+#phy-cells = <0>;
};
- usb3_1_phy: usb3_1_phy {
+ usb3_1_phy: usb-phy {
compatible = "usb-nop-xceiv";
vcc-supply = <_1_power>;
+#phy-cells = <0>;
};
- gpio-keys {
+ keys {
compatible = "gpio-keys";
- #address-cells = <1>;
- #size-cells = <0>;
pinctrl-0 = <_power_button _copy_button
_reset_button>;
pinctrl-names = "default";
- button@1 {
+ button-1 {
label = "Power Button";
linux,code = ;
gpios = < 17 GPIO_ACTIVE_HIGH>;
};
- button@2 {
+ button-2 {
label = "Copy Button";
linux,code = ;
gpios = < 20 GPIO_ACTIVE_HIGH>;
};
- button@3 {
+ button-3 {
label = "Reset Button";
linux,code = ;
gpios = < 18 GPIO_ACTIVE_HIGH>;
};
};
- gpio-leds {
+ leds {
compatible = "gpio-leds";
pinctrl-0 = <_sata1_white_led
_sata1_red_led
@@ -88,142 +88,132 @@
pinctrl-names = "default";
- white_sata1 {
+ led-1 {
label = "n2350:white:sata1";
gpios = < 20 GPIO_ACTIVE_HIGH>;
- linux,default-trigger = "ide-disk1";
};
- red_sata1 {
+ led-2 {
label = "n2350:red:sata1";
gpios = < 14 GPIO_ACTIVE_HIGH>;
};
- white-sata2 {
+ led-3 {
label = "n2350:white:sata2";
gpios = < 19 GPIO_ACTIVE_HIGH>;
};
- red-sata2 {
+ led-4 {
label = "n2350:red:sata2";
gpios = < 15 GPIO_ACTIVE_HIGH>;
};
- white-sys {
+ led-5 {
label = "n2350:white:sys";
gpios = < 14 GPIO_ACTIVE_HIGH>;
linux,default-trigger = "default-on";
};
- red-sys {
+ led-6 {
label = "n2350:red:sys";
gpios = < 15 GPIO_ACTIVE_HIGH>;
};
- blue-pwr {
+ led-7 {
label = "n2350:blue:pwr";
gpios = < 11 GPIO_ACTIVE_HIGH>;
};
- red-pwr {
+ led-8 {
label = "n2350:red:pwr";
gpios = < 18 GPIO_ACTIVE_HIGH>;
};
- white-usb {
+ led-9 {
label = "n2350:white:usb";
gpios = < 16 GPIO_ACTIVE_HIGH>;
};
- red-usb {
+ led-10 {
label = "n2350:red:usb";
gpios = < 17 GPIO_ACTIVE_HIGH>;
};
};
- regulators {
- compatible = "simple-bus";
- #address-cells = <1>;
- #size-cells = <0>;
-
- usb3_0_power: regulator@1 {
- compatible = "regulator-fixed";
- reg = <1>;
- regulator-name = "USB3_0_Power";
-
Re: mmc: Read eMMC partition access bits before card reset
Hi Stefan, On Wed, May 17, 2023 at 1:26 AM Stefan Roese wrote: > > Hi Pali, > > On 5/17/23 00:30, Pali Rohár wrote: > > On Tuesday 16 May 2023 14:56:46 Tom Rini wrote: > >> On Tue, May 16, 2023 at 08:52:23PM +0200, Pali Rohár wrote: > >>> On Tuesday 16 May 2023 11:36:20 Tom Rini wrote: > On Tue, May 16, 2023 at 09:04:27AM +0200, Pali Rohár wrote: > > On Sunday 07 May 2023 22:36:16 Pali Rohár wrote: > >> On Sunday 07 May 2023 12:45:11 Tom Rini wrote: > >>> On Sun, May 07, 2023 at 04:56:04PM +0200, Pali Rohár wrote: > On Sunday 07 May 2023 10:40:44 Tom Rini wrote: > > On Sun, May 07, 2023 at 04:01:04PM +0200, Pali Rohár wrote: > >> On Sunday 07 May 2023 09:54:52 Tom Rini wrote: > >>> On Fri, May 05, 2023 at 09:37:10PM +0200, Pali Rohár wrote: > On Wednesday 03 May 2023 13:14:56 Tom Rini wrote: > > On Wed, May 03, 2023 at 11:18:39AM +0200, Stefan Roese wrote: > > > >> Hi Tom, > >> > >> please pull this next batch of mostly Marvell related patches: > > > > NAK. With commit: > > commit 461fa17970de418a93832f734a595031c0b72128 > > Author: Pali Rohár > > Date: Thu Apr 13 22:57:48 2023 +0200 > > > > mmc: Read eMMC partition access bits before card reset > > > > eMMC specification in section "Access partitions" says > > that all reset > > events will restore the access bits in PARTITION_CONFIG > > CSD register to > > default User Data Area value (0b000). > > > > So read partition access bits from PARTITION_CONFIG CSD > > register before > > issuing card reset. This allows SPL/U-Boot to get > > information which eMMC > > partition was in use before SPL/U-Boot was booted. For > > some platforms this > > is the way how to determinate boot partition from which > > BootROM loaded SPL. > > > > Signed-off-by: Pali Rohár > > > > My am335x_evm now fails to boot with: > > > > U-Boot SPL 2023.07-rc1-00021-g461fa17970de (May 03 2023 - > > 13:10:10 -0400) > > Trying to boot from MMC1 > > omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear > > spl: mmc init failed with error: -110 > > SPL: failed to boot from all boot devices > > ### ERROR ### Please RESET the board ### > > > > I can provide more details / test patches as needed. > > > > -- > > Tom > > I do not know what to do with this... The only idea is to hide > this code > behind CONFIG symbol and enable it only for mvebu. For example > by this: > >>> > >>> Well, maybe the problem is we're trying this on uSD cards? The > >>> failure I > >>> reported was uSD and not eMMC. > >> > >> Maybe it is that reason. Problem is that at this stage we do not > >> know if > >> card is SD or MMC. > >> > >> Martin, can you check if booting from SD card is working fine on > >> mvebu > >> clearfog? > >> > >>> I see a failure with this commit on > >>> rpi_3_32b, also from uSD boot. This time it's: > >>> Loading Environment from FAT... fsm 0, hsts > >>> fsm 0, hsts > >>> ... > >>> > >>> once in U-Boot itself. Going to the commit prior to the above > >>> one and > >>> the board is fine again. > >>> > >>> -- > >>> Tom > >> > >> Immediately after that "problematic code" is card reset function. > >> So > >> another reason for failure is that card reset functionality does > >> not > >> work correctly on your board / platform. > > > > Well, we're at two different platforms and controllers that this > > change > > breaks things on, so I'm not sure where the fault is exactly. My > > mx6cuboxi is still fine booting from uSD. Another TI platform from > > the > > same general era as am335x fails the same way (not a surprise), > > amlogic > > libretech-cc is fine, pine64_plus is fine, and my newer TI > > platforms are > > also fine with this. So maybe the Kconfig is fine, but we just want > > default y, default n if ARCH_OMAP2PLUS || ARCH_BCM283X (the TI > > platforms > > that work are not ARCH_OMAP2PLUS). > > > > -- > > Tom > > And do you see this problem in SPL
Re: [RFC PATCH v8 23/23] DO NOT MERGE: only to make CI happy
Hi Francis,
On Fri, May 12, 2023 at 1:07 PM Francis Laniel
wrote:
>
> This commit set CONFIG_HUSH_PARSER_2021 as the default to trigger the CI with
> this parser.
>
> Nonetheless, the keymile (i.e. VENDOR_KM) board family is not compatible with
> new 2021 hush parser.
> Indeed, This boards used set_local_var() to store some variables as local
> shell.
> They then used get_local_var() to retrieve the variables values.
> Sadly, this two functions do not exist with CONFIG_HUSH_PARSER_2021.
> A patch was proposed to use environment variables rather than local variables
> but it does not tackle the problem, so complementary work is needed to make
> this boards use CONFIG_HUSH_PARSER_2021 [1].
>
> We also remove a #undef of CONFIG_FEATURE_SH_STANDALONE as it does not exist
> in
> U-Boot and causes troubles in the CI.
>
> We also set CONFIG_LTO for kirkwoord sheevaplug and phytec bk4r1, otherwise it
> hits its board size limit.
For Sheevaplug CONFIG_LTO:
Acked-by: Tony Dinh
All the best,
Tony
>
> We also disable some check for pylint as it was not able to find future for
> commit object.
>
> Signed-off-by: Francis Laniel
> [1] https://marc.info/?l=u-boot=165541917618725=2
> ---
> cmd/Kconfig | 3 ++-
> common/cli_hush_upstream.c | 1 -
> configs/sheevaplug_defconfig | 1 +
> tools/patman/series.py | 4
> 4 files changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/cmd/Kconfig b/cmd/Kconfig
> index c0f0e05d2f..2d066f08ba 100644
> --- a/cmd/Kconfig
> +++ b/cmd/Kconfig
> @@ -28,7 +28,7 @@ menu "Hush flavor to use"
>
> config HUSH_OLD_PARSER
> bool "Use hush old parser"
> - default y
> + default y if VENDOR_KM
> help
> This option enables the old flavor of hush based on hush
> Busybox from
> 2005.
> @@ -37,6 +37,7 @@ menu "Hush flavor to use"
>
> config HUSH_2021_PARSER
> bool "Use hush 2021 parser"
> + default y if !VENDOR_KM
> help
> This option enables the new flavor of hush based on hush
> Busybox from
> 2021.
> diff --git a/common/cli_hush_upstream.c b/common/cli_hush_upstream.c
> index 649775a7f7..5d329851c6 100644
> --- a/common/cli_hush_upstream.c
> +++ b/common/cli_hush_upstream.c
> @@ -427,7 +427,6 @@
> #include "NUM_APPLETS.h"
> #if NUM_APPLETS == 1
> /* STANDALONE does not make sense, and won't compile */
> -# undef CONFIG_FEATURE_SH_STANDALONE
> # undef ENABLE_FEATURE_SH_STANDALONE
> # undef IF_FEATURE_SH_STANDALONE
> # undef IF_NOT_FEATURE_SH_STANDALONE
> diff --git a/configs/sheevaplug_defconfig b/configs/sheevaplug_defconfig
> index 2e4901b840..365f779cc8 100644
> --- a/configs/sheevaplug_defconfig
> +++ b/configs/sheevaplug_defconfig
> @@ -16,6 +16,7 @@ CONFIG_ENV_OFFSET=0x8
> CONFIG_DEFAULT_DEVICE_TREE="kirkwood-sheevaplug"
> CONFIG_IDENT_STRING="\nMarvell-Sheevaplug"
> CONFIG_SYS_LOAD_ADDR=0x80
> +CONFIG_LTO=y
> CONFIG_HAS_BOARD_SIZE_LIMIT=y
> CONFIG_BOARD_SIZE_LIMIT=524288
> CONFIG_BOOTDELAY=3
> diff --git a/tools/patman/series.py b/tools/patman/series.py
> index 6866e1dbd0..f99818e33a 100644
> --- a/tools/patman/series.py
> +++ b/tools/patman/series.py
> @@ -316,6 +316,8 @@ class Series(dict):
> # Show progress any commits that are taking forever
> lastlen = 0
> while True:
> +# pylint does not find future which is set above.
> +# pylint: disable=E1101
> left = [commit for commit in self.commits
> if not commit.future.done()]
> if not left:
> @@ -333,6 +335,8 @@ class Series(dict):
> print('Cc processing complete')
>
> for commit in self.commits:
> +# pylint does not find future which is set above.
> +# pylint: disable=E1101
> cc = commit.future.result()
> all_ccs += cc
> print(commit.patch, '\0'.join(sorted(set(cc))), file=fd)
> --
> 2.34.1
>
Re: [RESEND PATCH v2] netconsole: various improvements
On Mon, May 8, 2023 at 3:53 PM Tony Dinh wrote: > > Hi Simon, > > On Mon, May 8, 2023 at 2:23 PM Simon Glass wrote: > > > > Hi Tony, > > > > On Sun, 7 May 2023 at 22:25, Tony Dinh wrote: > > > > > > Hi Tom, > > > > > > On Fri, May 5, 2023 at 11:34 AM Tom Rini wrote: > > > > > > > > On Mon, Apr 03, 2023 at 02:41:52PM -0700, Tony Dinh wrote: > > > > > > > > > Use CONFIG_CONSOLE_MUX for netconsole. When netconsole is running, > > > > > stdin/stdout/stder must be set to some primary console, in addtion to > > > > > nc. > > > > > For example, stdin=serial,nc. Some recent Linux kernels will not boot > > > > > with > > > > > only nc on the stdout list, ie. stdout=nc. When netconsole exits, > > > > > remove > > > > > nc from the list of devices in stdin/stdout/stderr. > > > > > > > > > > Signed-off-by: Tony Dinh > > > > > > > > This breaks the ut_bootstd_bootflow_cmd_boot test on sandbox. I'm not > > > > sure if it's a test issue or something else. > > > > > > Thanks for trying, I'm having some difficulty building a sandbox > > > u-boot, so I can't get to the point where I can see what's the problem > > > yet. > > > > What is going wrong? Does this help? > > > > https://u-boot.readthedocs.io/en/latest/build/gcc.html > > Yes, I've done that when I realized my ARM development box setup > missed several Debian packages building sandbox (I only build Linux > kernels and U-Boot boards natively on ARM). However, after installing > all those packages it is still not possible to build a sandbox on ARM. > So currently I am switching to cross compiling on my Intel laptop. > Later, I'll come back to the ARM box to see whether we need some > documentation update for doc/build/gcc.rst. FYI, what's missing in the doc/build/gcc.rst is the SDL option. I could not build without NO_SDL=1. make sandbox_defconfig all NO_SDL=1 All the best, Tony
Re: [RESEND PATCH v2] netconsole: various improvements
Hi Simon, On Mon, May 8, 2023 at 2:23 PM Simon Glass wrote: > > Hi Tony, > > On Sun, 7 May 2023 at 22:25, Tony Dinh wrote: > > > > Hi Tom, > > > > On Fri, May 5, 2023 at 11:34 AM Tom Rini wrote: > > > > > > On Mon, Apr 03, 2023 at 02:41:52PM -0700, Tony Dinh wrote: > > > > > > > Use CONFIG_CONSOLE_MUX for netconsole. When netconsole is running, > > > > stdin/stdout/stder must be set to some primary console, in addtion to > > > > nc. > > > > For example, stdin=serial,nc. Some recent Linux kernels will not boot > > > > with > > > > only nc on the stdout list, ie. stdout=nc. When netconsole exits, remove > > > > nc from the list of devices in stdin/stdout/stderr. > > > > > > > > Signed-off-by: Tony Dinh > > > > > > This breaks the ut_bootstd_bootflow_cmd_boot test on sandbox. I'm not > > > sure if it's a test issue or something else. > > > > Thanks for trying, I'm having some difficulty building a sandbox > > u-boot, so I can't get to the point where I can see what's the problem > > yet. > > What is going wrong? Does this help? > > https://u-boot.readthedocs.io/en/latest/build/gcc.html Yes, I've done that when I realized my ARM development box setup missed several Debian packages building sandbox (I only build Linux kernels and U-Boot boards natively on ARM). However, after installing all those packages it is still not possible to build a sandbox on ARM. So currently I am switching to cross compiling on my Intel laptop. Later, I'll come back to the ARM box to see whether we need some documentation update for doc/build/gcc.rst. Thanks, Tony > > Regards, > Simon
Re: [RESEND PATCH v2] netconsole: various improvements
Hi Tom, On Fri, May 5, 2023 at 11:34 AM Tom Rini wrote: > > On Mon, Apr 03, 2023 at 02:41:52PM -0700, Tony Dinh wrote: > > > Use CONFIG_CONSOLE_MUX for netconsole. When netconsole is running, > > stdin/stdout/stder must be set to some primary console, in addtion to nc. > > For example, stdin=serial,nc. Some recent Linux kernels will not boot with > > only nc on the stdout list, ie. stdout=nc. When netconsole exits, remove > > nc from the list of devices in stdin/stdout/stderr. > > > > Signed-off-by: Tony Dinh > > This breaks the ut_bootstd_bootflow_cmd_boot test on sandbox. I'm not > sure if it's a test issue or something else. Thanks for trying, I'm having some difficulty building a sandbox u-boot, so I can't get to the point where I can see what's the problem yet. All the best, Tony > > -- > Tom
Re: [RESEND PATCH v2] netconsole: various improvements
Hi Simon, On Mon, Apr 24, 2023 at 12:43 PM Simon Glass wrote: > > Hi Tony, > > On Wed, 19 Apr 2023 at 21:55, Tony Dinh wrote: > > > > On Wed, Apr 19, 2023 at 6:22 PM Tony Dinh wrote: > > > > > > HI Simon, > > > > > > On Tue, Apr 18, 2023 at 6:46 PM Simon Glass wrote: > > > > > > > > Hi Tony, > > > > > > > > On Mon, 3 Apr 2023 at 15:42, Tony Dinh wrote: > > > > > > > > > > Use CONFIG_CONSOLE_MUX for netconsole. When netconsole is running, > > > > > stdin/stdout/stder must be set to some primary console, in addtion to > > > > > nc. > > > > > For example, stdin=serial,nc. Some recent Linux kernels will not boot > > > > > with > > > > > only nc on the stdout list, ie. stdout=nc. When netconsole exits, > > > > > remove > > > > > nc from the list of devices in stdin/stdout/stderr. > > > > > > > > > > Signed-off-by: Tony Dinh > > > > > --- > > > > > > > > > > Changes in v2: > > > > > - Select CONFIG_CONSOLE_MUX if CONFIG_NETCONSOLE is enabled > > > > > - Add new functions in netconsole driver to support CONSOLE_MUX > > > > > - Add new function to encapsulate the process of stopping netconsole > > > > > from bootm > > > > > - Remove unecessary net_timeout initial value = 1 > > > > > - Resend to correct missing include in bootm.c > > > > > > > > > > boot/bootm.c | 14 +++--- > > > > > drivers/net/Kconfig | 10 +++ > > > > > drivers/net/netconsole.c | 60 > > > > > > > > > > include/stdio_dev.h | 1 + > > > > > 4 files changed, 81 insertions(+), 4 deletions(-) > > > > > > > > This seems OK to me but for a few thoughts below. > > > > > > > > But can we use this opportunity to move this to driver model? The > > > > netconsole driver could be bound in eth_post_bind() and the code in > > > > netconsole.c converted to be a driver. > > > > > > > > I think that would be better than building on an out-of-date driver. > > > > > > I'd agree that converting to a driver model is the logical next step. > > > My motivation is to fix the booting problem for the Linux kernel first > > > (I'm having problems booting some kernels without this patch). And > > > then in the next go round, I'll convert netconsole to a driver. Most > > > of the code in this small patch will be needed whether it is an old > > > driver or DM anyway. > > This crosses the line to a feature, IMO... My initial patch would be a pure bug fix. But it also breaks other boards like Nokia, as Pali has pointed out. So in the v2 patch, Console Mux is introduced to cover all boards. I don't think that we are adding any features here. It's just that I'm using netconsole often so I noticed the booting problem with recent Linux kernels. It's kind of a catch-22, without a serial console I cannot debug Linux early booting problems, and with serial console active there is no booting problem. All the best, Tony > > [..] > > > > > > diff --git a/include/stdio_dev.h b/include/stdio_dev.h > > > > > index 3105928970..9d2375a67e 100644 > > > > > --- a/include/stdio_dev.h > > > > > +++ b/include/stdio_dev.h > > > > > @@ -112,6 +112,7 @@ int drv_keyboard_init(void); > > > > > int drv_usbtty_init(void); > > > > > int drv_usbacm_init(void); > > > > > int drv_nc_init(void); > > > > > +void drv_nc_stop(void); > > > > > > > > Once this is a driver we won't need this. > > > > > > Yes, but we still need the nc_stdio_stop() to do the cleanup, i.e. > > > removing nc from stdin/stdout/stderr and deregistering the nc device. > > > Except that it will be a uclass member like .pre_remove()? > > Yes, or perhaps the driver's remove() method. > > > > > > > It will be a bit of a learning curve for me to do the DM netconsole. > > > But I will give it a shot. > > > > In the meantime, can this patch get merged on its own merit as a bug fix? > > I suppose so, so long as you can figure out the conversion. Let me > know if you have any questions. > > Regards, > Simon
Re: [RESEND PATCH v2] netconsole: various improvements
On Wed, Apr 19, 2023 at 6:22 PM Tony Dinh wrote:
>
> HI Simon,
>
> On Tue, Apr 18, 2023 at 6:46 PM Simon Glass wrote:
> >
> > Hi Tony,
> >
> > On Mon, 3 Apr 2023 at 15:42, Tony Dinh wrote:
> > >
> > > Use CONFIG_CONSOLE_MUX for netconsole. When netconsole is running,
> > > stdin/stdout/stder must be set to some primary console, in addtion to nc.
> > > For example, stdin=serial,nc. Some recent Linux kernels will not boot with
> > > only nc on the stdout list, ie. stdout=nc. When netconsole exits, remove
> > > nc from the list of devices in stdin/stdout/stderr.
> > >
> > > Signed-off-by: Tony Dinh
> > > ---
> > >
> > > Changes in v2:
> > > - Select CONFIG_CONSOLE_MUX if CONFIG_NETCONSOLE is enabled
> > > - Add new functions in netconsole driver to support CONSOLE_MUX
> > > - Add new function to encapsulate the process of stopping netconsole
> > > from bootm
> > > - Remove unecessary net_timeout initial value = 1
> > > - Resend to correct missing include in bootm.c
> > >
> > > boot/bootm.c | 14 +++---
> > > drivers/net/Kconfig | 10 +++
> > > drivers/net/netconsole.c | 60
> > > include/stdio_dev.h | 1 +
> > > 4 files changed, 81 insertions(+), 4 deletions(-)
> >
> > This seems OK to me but for a few thoughts below.
> >
> > But can we use this opportunity to move this to driver model? The
> > netconsole driver could be bound in eth_post_bind() and the code in
> > netconsole.c converted to be a driver.
> >
> > I think that would be better than building on an out-of-date driver.
>
> I'd agree that converting to a driver model is the logical next step.
> My motivation is to fix the booting problem for the Linux kernel first
> (I'm having problems booting some kernels without this patch). And
> then in the next go round, I'll convert netconsole to a driver. Most
> of the code in this small patch will be needed whether it is an old
> driver or DM anyway.
>
> >
> > >
> > > diff --git a/boot/bootm.c b/boot/bootm.c
> > > index 2eec60ec7b..1b2542b570 100644
> > > --- a/boot/bootm.c
> > > +++ b/boot/bootm.c
> > > @@ -18,6 +18,7 @@
> > > #include
> > > #include
> > > #include
> > > +#include
> > > #include
> > > #include
> > > #include
> > > @@ -472,11 +473,16 @@ ulong bootm_disable_interrupts(void)
> > > * recover from any failures any more...
> > > */
> > > iflag = disable_interrupts();
> > > -#ifdef CONFIG_NETCONSOLE
> > > - /* Stop the ethernet stack if NetConsole could have left it up */
> > > - eth_halt();
> > > -#endif
> > >
> > > + if (IS_ENABLED(CONFIG_NETCONSOLE)) {
> > > + /*
> > > +* Make sure that the starting kernel message printed out,
> > > +* stop netconsole and the ethernet stack
> > > +*/
> > > + printf("\n\nStarting kernel ...\n\n");
> > > + drv_nc_stop();
> > > + eth_halt();
> > > + }
> > > #if defined(CONFIG_CMD_USB)
> > > /*
> > > * turn off USB to prevent the host controller from writing to the
> > > diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
> > > index ceadee98a1..0661059dfa 100644
> > > --- a/drivers/net/Kconfig
> > > +++ b/drivers/net/Kconfig
> > > @@ -945,4 +945,14 @@ config MDIO_MUX_MESON_G12A
> > > This driver is used for the MDIO mux found on the Amlogic G12A
> > > & compatible
> > > SoCs.
> > >
> > > +config NETCONSOLE
> > > + bool "Enable netconsole"
> > > + select CONSOLE_MUX
> > > + help
> > > + NetConsole requires CONSOLE_MUX, i.e. at least one default
> > > console such
> > > + must be specified in addition to nc console. For example, for
> > > boards that
> > > + the main console is serial, set each of the envs
> > > stdin/stdout/stderr to serial,nc.
> > > + See CONFIG_CONSOLE_MUX and CONFIG_SYS_CONSOLE_IS_IN_ENV help
> > > for detailed
> > > + description of usage.
> > > +
> > > endif # NETDEVICES
> > > diff --git a/drivers/net/netconsole.c b/drivers/net/netcons
Re: [RESEND PATCH v2] netconsole: various improvements
HI Simon,
On Tue, Apr 18, 2023 at 6:46 PM Simon Glass wrote:
>
> Hi Tony,
>
> On Mon, 3 Apr 2023 at 15:42, Tony Dinh wrote:
> >
> > Use CONFIG_CONSOLE_MUX for netconsole. When netconsole is running,
> > stdin/stdout/stder must be set to some primary console, in addtion to nc.
> > For example, stdin=serial,nc. Some recent Linux kernels will not boot with
> > only nc on the stdout list, ie. stdout=nc. When netconsole exits, remove
> > nc from the list of devices in stdin/stdout/stderr.
> >
> > Signed-off-by: Tony Dinh
> > ---
> >
> > Changes in v2:
> > - Select CONFIG_CONSOLE_MUX if CONFIG_NETCONSOLE is enabled
> > - Add new functions in netconsole driver to support CONSOLE_MUX
> > - Add new function to encapsulate the process of stopping netconsole
> > from bootm
> > - Remove unecessary net_timeout initial value = 1
> > - Resend to correct missing include in bootm.c
> >
> > boot/bootm.c | 14 +++---
> > drivers/net/Kconfig | 10 +++
> > drivers/net/netconsole.c | 60
> > include/stdio_dev.h | 1 +
> > 4 files changed, 81 insertions(+), 4 deletions(-)
>
> This seems OK to me but for a few thoughts below.
>
> But can we use this opportunity to move this to driver model? The
> netconsole driver could be bound in eth_post_bind() and the code in
> netconsole.c converted to be a driver.
>
> I think that would be better than building on an out-of-date driver.
I'd agree that converting to a driver model is the logical next step.
My motivation is to fix the booting problem for the Linux kernel first
(I'm having problems booting some kernels without this patch). And
then in the next go round, I'll convert netconsole to a driver. Most
of the code in this small patch will be needed whether it is an old
driver or DM anyway.
>
> >
> > diff --git a/boot/bootm.c b/boot/bootm.c
> > index 2eec60ec7b..1b2542b570 100644
> > --- a/boot/bootm.c
> > +++ b/boot/bootm.c
> > @@ -18,6 +18,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -472,11 +473,16 @@ ulong bootm_disable_interrupts(void)
> > * recover from any failures any more...
> > */
> > iflag = disable_interrupts();
> > -#ifdef CONFIG_NETCONSOLE
> > - /* Stop the ethernet stack if NetConsole could have left it up */
> > - eth_halt();
> > -#endif
> >
> > + if (IS_ENABLED(CONFIG_NETCONSOLE)) {
> > + /*
> > +* Make sure that the starting kernel message printed out,
> > +* stop netconsole and the ethernet stack
> > +*/
> > + printf("\n\nStarting kernel ...\n\n");
> > + drv_nc_stop();
> > + eth_halt();
> > + }
> > #if defined(CONFIG_CMD_USB)
> > /*
> > * turn off USB to prevent the host controller from writing to the
> > diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
> > index ceadee98a1..0661059dfa 100644
> > --- a/drivers/net/Kconfig
> > +++ b/drivers/net/Kconfig
> > @@ -945,4 +945,14 @@ config MDIO_MUX_MESON_G12A
> > This driver is used for the MDIO mux found on the Amlogic G12A &
> > compatible
> > SoCs.
> >
> > +config NETCONSOLE
> > + bool "Enable netconsole"
> > + select CONSOLE_MUX
> > + help
> > + NetConsole requires CONSOLE_MUX, i.e. at least one default
> > console such
> > + must be specified in addition to nc console. For example, for
> > boards that
> > + the main console is serial, set each of the envs
> > stdin/stdout/stderr to serial,nc.
> > + See CONFIG_CONSOLE_MUX and CONFIG_SYS_CONSOLE_IS_IN_ENV help for
> > detailed
> > + description of usage.
> > +
> > endif # NETDEVICES
> > diff --git a/drivers/net/netconsole.c b/drivers/net/netconsole.c
> > index 151bc55e07..bb92d2e130 100644
> > --- a/drivers/net/netconsole.c
> > +++ b/drivers/net/netconsole.c
> > @@ -7,6 +7,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -33,6 +34,12 @@ static int output_packet_len;
> > */
> > enum proto_t net_loop_last_protocol = BOOTP;
> >
> > +/*
> > + * Net console helpers
> > + */
> > +static void usage(void);
> > +static void remove_nc_from(co
Re: [PATCH] ddr: marvell: a38x: Perform DDR training sequence again for 2nd boot
Hi Pali,
I've created a pull request for this patch to the Marvell repo.
https://github.com/MarvellEmbeddedProcessors/mv-ddr-marvell/pull/41
Thanks,
Tony
On Thu, Apr 13, 2023 at 11:06 PM Stefan Roese wrote:
>
> On 4/3/23 06:42, Tony Dinh wrote:
> > - DDR Training sequence happens very fast. The speedup in boot time is
> > negligible by skipping the training sequence during 2nd boot or after.
> > So remove the check and skip.
> > - This change improves the robustness of DDR training. If u-boot crashed
> > during DDR training, the training could be left in a limbo state, where
> > the BootROM has recorded that it is already in a 2nd boot. The training
> > must be repeated in this scenario to get out of this limbo state, but due
> > to the check it cannot be performed.
> >
> > Signed-off-by: Tony Dinh
>
> Applied to u-boot-marvell/master
>
> Thanks,
> Stefan
>
> > ---
> >
> > drivers/ddr/marvell/a38x/mv_ddr_plat.c | 7 ---
> > 1 file changed, 7 deletions(-)
> >
> > diff --git a/drivers/ddr/marvell/a38x/mv_ddr_plat.c
> > b/drivers/ddr/marvell/a38x/mv_ddr_plat.c
> > index 6e7949ac72..8ec9fb0874 100644
> > --- a/drivers/ddr/marvell/a38x/mv_ddr_plat.c
> > +++ b/drivers/ddr/marvell/a38x/mv_ddr_plat.c
> > @@ -1363,13 +1363,6 @@ int mv_ddr_pre_training_soc_config(const char
> > *ddr_type)
> > DRAM_RESET_MASK_MASKED << DRAM_RESET_MASK_OFFS);
> > }
> >
> > - /* Check if DRAM is already initialized */
> > - if (reg_read(REG_BOOTROM_ROUTINE_ADDR) &
> > - (1 << REG_BOOTROM_ROUTINE_DRAM_INIT_OFFS)) {
> > - printf("%s Training Sequence - 2nd boot - Skip\n", ddr_type);
> > - return MV_OK;
> > - }
> > -
> > /* Fix read ready phases for all SOC in reg 0x15c8 */
> > reg_val = reg_read(TRAINING_DBG_3_REG);
> >
>
> Viele Grüße,
> Stefan Roese
>
> --
> DENX Software Engineering GmbH, Managing Director: Erika Unter
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
Re: [RESEND PATCH v2] netconsole: various improvements
Hi Ramon,
Hi Joe,
Any comments on this patch?
Thanks,
Tony
On Mon, Apr 3, 2023 at 2:42 PM Tony Dinh wrote:
>
> Use CONFIG_CONSOLE_MUX for netconsole. When netconsole is running,
> stdin/stdout/stder must be set to some primary console, in addtion to nc.
> For example, stdin=serial,nc. Some recent Linux kernels will not boot with
> only nc on the stdout list, ie. stdout=nc. When netconsole exits, remove
> nc from the list of devices in stdin/stdout/stderr.
>
> Signed-off-by: Tony Dinh
> ---
>
> Changes in v2:
> - Select CONFIG_CONSOLE_MUX if CONFIG_NETCONSOLE is enabled
> - Add new functions in netconsole driver to support CONSOLE_MUX
> - Add new function to encapsulate the process of stopping netconsole
> from bootm
> - Remove unecessary net_timeout initial value = 1
> - Resend to correct missing include in bootm.c
>
> boot/bootm.c | 14 +++---
> drivers/net/Kconfig | 10 +++
> drivers/net/netconsole.c | 60
> include/stdio_dev.h | 1 +
> 4 files changed, 81 insertions(+), 4 deletions(-)
>
> diff --git a/boot/bootm.c b/boot/bootm.c
> index 2eec60ec7b..1b2542b570 100644
> --- a/boot/bootm.c
> +++ b/boot/bootm.c
> @@ -18,6 +18,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -472,11 +473,16 @@ ulong bootm_disable_interrupts(void)
> * recover from any failures any more...
> */
> iflag = disable_interrupts();
> -#ifdef CONFIG_NETCONSOLE
> - /* Stop the ethernet stack if NetConsole could have left it up */
> - eth_halt();
> -#endif
>
> + if (IS_ENABLED(CONFIG_NETCONSOLE)) {
> + /*
> +* Make sure that the starting kernel message printed out,
> +* stop netconsole and the ethernet stack
> +*/
> + printf("\n\nStarting kernel ...\n\n");
> + drv_nc_stop();
> + eth_halt();
> + }
> #if defined(CONFIG_CMD_USB)
> /*
> * turn off USB to prevent the host controller from writing to the
> diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
> index ceadee98a1..0661059dfa 100644
> --- a/drivers/net/Kconfig
> +++ b/drivers/net/Kconfig
> @@ -945,4 +945,14 @@ config MDIO_MUX_MESON_G12A
> This driver is used for the MDIO mux found on the Amlogic G12A &
> compatible
> SoCs.
>
> +config NETCONSOLE
> + bool "Enable netconsole"
> + select CONSOLE_MUX
> + help
> + NetConsole requires CONSOLE_MUX, i.e. at least one default console
> such
> + must be specified in addition to nc console. For example, for
> boards that
> + the main console is serial, set each of the envs
> stdin/stdout/stderr to serial,nc.
> + See CONFIG_CONSOLE_MUX and CONFIG_SYS_CONSOLE_IS_IN_ENV help for
> detailed
> + description of usage.
> +
> endif # NETDEVICES
> diff --git a/drivers/net/netconsole.c b/drivers/net/netconsole.c
> index 151bc55e07..bb92d2e130 100644
> --- a/drivers/net/netconsole.c
> +++ b/drivers/net/netconsole.c
> @@ -7,6 +7,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -33,6 +34,12 @@ static int output_packet_len;
> */
> enum proto_t net_loop_last_protocol = BOOTP;
>
> +/*
> + * Net console helpers
> + */
> +static void usage(void);
> +static void remove_nc_from(const int console);
> +
> static void nc_wait_arp_handler(uchar *pkt, unsigned dest,
> struct in_addr sip, unsigned src,
> unsigned len)
> @@ -111,6 +118,21 @@ static int refresh_settings_from_env(void)
> return 0;
> }
>
> +static void remove_nc_from(const int console)
> +{
> + int ret;
> +
> + ret = iomux_replace_device(console, "nc", "nulldev");
> + if (ret) {
> + printf("\n*** Warning: Cannot remove nc from %s Error=%d\n",
> + stdio_names[console], ret);
> + printf("%s=", stdio_names[console]);
> + iomux_printdevs(console);
> + usage();
> + flush();
> + }
> +}
> +
> /**
> * Called from net_loop in net/net.c before each packet
> */
> @@ -241,6 +263,29 @@ static int nc_stdio_start(struct stdio_dev *dev)
> return 0;
> }
>
> +void nc_stdio_stop(void)
> +{
> + if (IS_ENABLED(CONFIG_CONSOLE_MUX)) {
> + int ret;
> + struct stdio_dev *sdev;
> +
