Re: [PATCH v3 3/9] phy: phy-mtk-tphy: add support USB phys
On Thu, 2020-03-26 at 16:01 +0800, Chunfeng Yun wrote: > Support USB2 and USB3 PHY with shared banks when support multi-phys > > Signed-off-by: Chunfeng Yun > --- > v3: no changes > > v2: > 1. get the count of phys by dev_get_child_count() > --- > drivers/phy/phy-mtk-tphy.c | 227 +++-- > 1 file changed, 218 insertions(+), 9 deletions(-) > Reviewed-by: Weijie Gao
Re: [PATCH v3 4/9] phy: phy-mtk-tphy: add support new version
On Thu, 2020-03-26 at 16:01 +0800, Chunfeng Yun wrote: > The new version removes all shared banks between multi-phys > > Signed-off-by: Chunfeng Yun > --- > v2~v3: no changes > --- > drivers/phy/phy-mtk-tphy.c | 68 +++--- > 1 file changed, 63 insertions(+), 5 deletions(-) > Reviewed-by: Weijie Gao
Re: [PATCH v3 5/9] phy: phy-mtk-tphy: add a new reference clock
On Thu, 2020-03-26 at 16:01 +0800, Chunfeng Yun wrote: > Usually the digital and analog phys use the same reference clock, > but some platforms have two separate reference clocks for each of > them, so add another optional clock to support them. > In order to keep the clock names consistent with PHY IP's, change > the da_ref for analog phy and ref clock for digital phy. > > Signed-off-by: Chunfeng Yun > --- > v2~v3: no changes > --- > drivers/phy/phy-mtk-tphy.c | 21 ++--- > 1 file changed, 18 insertions(+), 3 deletions(-) > Reviewed-by: Weijie Gao
Re: [PATCH v3 6/9] xhci: mediatek: Add support for MTK xHCI host controller
On Thu, 2020-03-26 at 16:01 +0800, Chunfeng Yun wrote: > This patch is used to support the on-chip xHCI controller on > MediaTek SoCs, currently only control/bulk transfers are > supported. > > Signed-off-by: Chunfeng Yun > --- > v3: > use macro approach to access registers suggested by Marek > > v2: > 1. use clk_bulk to get clocks suggested by Marek > 2. use clrsetbits_le32() etc suggeseted by Marek > --- > drivers/usb/host/Kconfig| 6 + > drivers/usb/host/Makefile | 1 + > drivers/usb/host/xhci-mtk.c | 364 > 3 files changed, 371 insertions(+) > create mode 100644 drivers/usb/host/xhci-mtk.c > Reviewed-by: Weijie Gao
Re: [PATCH v3 7/9] arm: dts: mt7629: add usb related nodes
On Thu, 2020-03-26 at 16:01 +0800, Chunfeng Yun wrote: > Add usb, phy and clock nodes > > Signed-off-by: Chunfeng Yun > --- > v3: no changes > > v2: > 1. remove fixed clock clk20m > --- > arch/arm/dts/mt7629-rfb.dts | 8 > arch/arm/dts/mt7629.dtsi| 41 + > 2 files changed, 49 insertions(+) > Reviewed-by: Weijie Gao
Re: [PATCH v3 9/9] dt-bindings: usb: mtk-xhci: Add binding for MediaTek xHCI host controller
On Thu, 2020-03-26 at 16:01 +0800, Chunfeng Yun wrote: > Add dt-binding for MediaTek xHCI host controller > > Signed-off-by: Chunfeng Yun > --- > v2~v3: no changes > --- > .../usb/mediatek,mtk-xhci.txt | 40 +++ > 1 file changed, 40 insertions(+) > create mode 100644 doc/device-tree-bindings/usb/mediatek,mtk-xhci.txt > Reviewed-by: Weijie Gao
Re: [PATCH v5 02/14] test: dm: add test item for ofnode_get_child_count()
On Fri, 2020-04-10 at 13:45 +0800, Chunfeng Yun wrote: > Add a test item for ofnode_get_child_count() > > Signed-off-by: Chunfeng Yun > Reviewed-by: Simon Glass > --- > v4~v5: no changes > > v3: > 1. squash dts patch into this one suggested by Simon > 2. add reviewed-by Simon > > v2: > a new patch to test ofnode_get_child_count() suggested by Simon > --- > arch/sandbox/dts/test.dts | 18 ++ > test/dm/ofnode.c | 21 + > 2 files changed, 39 insertions(+) > Reviewed-by: Weijie Gao
Re: [PATCH v5 01/14] dm: core: Add function to get child count of ofnode or device
On Fri, 2020-04-10 at 13:45 +0800, Chunfeng Yun wrote: > This patch add function used to get the child count of > a ofnode or a device > > Signed-off-by: Chunfeng Yun > --- > v4~v5: no changes > > v3: > 1. add non/inline function dev_get_child_count() instead of macro > suggested by Simon > > v2: > 1. move ofnode_get_child_count() into ofnode.c suggested by Simon > 2. add a new macro dev_get_child_count() > --- > drivers/core/ofnode.c | 11 +++ > drivers/core/read.c | 5 + > include/dm/ofnode.h | 8 > include/dm/read.h | 13 + > 4 files changed, 37 insertions(+) > Reviewed-by: Weijie Gao
Re: [PATCH v5 04/14] test: dm: phy: add a test item for the phy_bulk API
On Fri, 2020-04-10 at 13:45 +0800, Chunfeng Yun wrote: > Add a test item for the phy_bulk API > > Signed-off-by: Chunfeng Yun > --- > v5: no changes > > v4: new patch > --- > arch/sandbox/dts/test.dts | 11 +++ > test/dm/phy.c | 29 + > 2 files changed, 40 insertions(+) > Reviewed-by: Weijie Gao
Re: [PATCH v5 03/14] phy: Add get/enable/disable for a bulk of phys
On Fri, 2020-04-10 at 13:45 +0800, Chunfeng Yun wrote: > This patch adds a "bulk" API to the phy API in order to > get/enable/disable a group of phys associated with a device. > > The bulk API will avoid adding a copy of the same code to > manage a group of phys in drivers. > > Signed-off-by: Chunfeng Yun > --- > v5: no changes > > v4: new patch > --- > drivers/phy/phy-uclass.c | 80 > include/generic-phy.h| 66 + > 2 files changed, 146 insertions(+) > Reviewed-by: Weijie Gao
Re: [PATCH v5 05/14] usb: dwc3: use the phy bulk API to get phys
On Fri, 2020-04-10 at 13:45 +0800, Chunfeng Yun wrote: > Get a group of phys by the phy bulk API > > Signed-off-by: Chunfeng Yun > --- > v5: no changes > > v4: new patch > --- > drivers/usb/dwc3/core.c | 83 - > drivers/usb/dwc3/dwc3-generic.c | 7 ++- > include/dwc3-uboot.h| 11 ++--- > 3 files changed, 17 insertions(+), 84 deletions(-) > Reviewed-by: Weijie Gao
Re: [PATCH v5 07/14] phy: phy-mtk-tphy: add support USB phys
On Fri, 2020-04-10 at 13:45 +0800, Chunfeng Yun wrote: > Support USB2 and USB3 PHY with shared banks when support multi-phys > > Signed-off-by: Chunfeng Yun > --- > v3~v5: no changes > > v2: > 1. get the count of phys by dev_get_child_count() > --- > drivers/phy/phy-mtk-tphy.c | 227 +++-- > 1 file changed, 218 insertions(+), 9 deletions(-) > Reviewed-by: Weijie Gao
Re: [PATCH v5 10/14] xhci: mediatek: Add support for MTK xHCI host controller
On Fri, 2020-04-10 at 13:45 +0800, Chunfeng Yun wrote: > This patch is used to support the on-chip xHCI controller on > MediaTek SoCs, currently control/bulk/interrupt transfers are > supported. > > Signed-off-by: Chunfeng Yun > --- > v5: > 1. print error number suggested by Marek > 2. support interrupt transfer > > v4: > 1. use phy_bulk API > > v3: > 1. use macro approach to access registers suggested by Marek > > v2: > 1. use clk_bulk to get clocks suggested by Marek > 2. use clrsetbits_le32() etc suggeseted by Marek > --- > drivers/usb/host/Kconfig| 6 + > drivers/usb/host/Makefile | 1 + > drivers/usb/host/xhci-mtk.c | 296 > drivers/usb/host/xhci.c | 10 ++ > include/usb/xhci.h | 3 + > 5 files changed, 316 insertions(+) > create mode 100644 drivers/usb/host/xhci-mtk.c > Reviewed-by: Weijie Gao
Re: [PATCH v5 09/14] phy: phy-mtk-tphy: add a new reference clock
On Fri, 2020-04-10 at 13:45 +0800, Chunfeng Yun wrote: > Usually the digital and analog phys use the same reference clock, > but some platforms have two separate reference clocks for each of > them, so add another optional clock to support them. > In order to keep the clock names consistent with PHY IP's, change > the da_ref for analog phy and ref clock for digital phy. > > Signed-off-by: Chunfeng Yun > --- > v2~v5: no changes > --- > drivers/phy/phy-mtk-tphy.c | 21 ++--- > 1 file changed, 18 insertions(+), 3 deletions(-) > Reviewed-by: Weijie Gao
Re: [PATCH v5 12/14] dt-bindings: phy-mtk-tphy: add properties of address mapping and clocks
On Fri, 2020-04-10 at 13:45 +0800, Chunfeng Yun wrote: > 1. add the address mapping related properties; > 2. make "ref" clock optional, and add optional clock "da_ref"; > 3. add the banks layout of TPHY V1 and V2; > > Signed-off-by: Chunfeng Yun > --- > v2~v5: no changes > --- > doc/device-tree-bindings/phy/phy-mtk-tphy.txt | 78 --- > 1 file changed, 68 insertions(+), 10 deletions(-) > Reviewed-by: Weijie Gao
Re: [PATCH v5 06/14] usb: dwc2_udc_otg: use the phy bulk API to get phys
On Fri, 2020-04-10 at 13:45 +0800, Chunfeng Yun wrote: > Use the phy bulk API to get a group of phys > > Signed-off-by: Chunfeng Yun > --- > v5: no changes > > v4: new patch > --- > drivers/usb/gadget/dwc2_udc_otg.c | 90 +-- > 1 file changed, 12 insertions(+), 78 deletions(-) > Reviewed-by: Weijie Gao
Re: [PATCH v5 08/14] phy: phy-mtk-tphy: add support new version
On Fri, 2020-04-10 at 13:45 +0800, Chunfeng Yun wrote: > The new version removes all shared banks between multi-phys > > Signed-off-by: Chunfeng Yun > --- > v2~v5: no changes > --- > drivers/phy/phy-mtk-tphy.c | 68 +++--- > 1 file changed, 63 insertions(+), 5 deletions(-) > Reviewed-by: Weijie Gao
Re: [PATCH v5 14/14] MAINTAINERS: MediaTek: add USB related files
On Fri, 2020-04-10 at 13:45 +0800, Chunfeng Yun wrote: > Add dt-binding files of xhci-mtk and phys, C files of > phys. > > Signed-off-by: Chunfeng Yun > --- > v5: new patch > --- > MAINTAINERS | 3 +++ > 1 file changed, 3 insertions(+) > Reviewed-by: Weijie Gao
Re: [PATCH v5 13/14] dt-bindings: usb: mtk-xhci: Add binding for MediaTek xHCI host controller
On Fri, 2020-04-10 at 13:45 +0800, Chunfeng Yun wrote: > Add dt-binding for MediaTek xHCI host controller > > Signed-off-by: Chunfeng Yun > --- > v2~v5: no changes > --- > .../usb/mediatek,mtk-xhci.txt | 40 +++ > 1 file changed, 40 insertions(+) > create mode 100644 doc/device-tree-bindings/usb/mediatek,mtk-xhci.txt > Reviewed-by: Weijie Gao
Re: [PATCH v5 11/14] arm: dts: mt7629: add usb related nodes
On Fri, 2020-04-10 at 13:45 +0800, Chunfeng Yun wrote: > Add usb, phy and clock nodes > > Signed-off-by: Chunfeng Yun > --- > v3~v5: no changes > > v2: > 1. remove fixed clock clk20m > --- > arch/arm/dts/mt7629-rfb.dts | 8 > arch/arm/dts/mt7629.dtsi| 41 + > 2 files changed, 49 insertions(+) > Reviewed-by: Weijie Gao
Re: [PATCH v3 8/9] dt-bindings: phy-mtk-tphy: add properties of address mapping and clocks
On Thu, 2020-03-26 at 16:01 +0800, Chunfeng Yun wrote: > 1. add the address mapping related properties; > 2. make "ref" clock optional, and add optional clock "da_ref"; > 3. add the banks layout of TPHY V1 and V2; > > Signed-off-by: Chunfeng Yun > --- > v2~v3: no changes > --- > doc/device-tree-bindings/phy/phy-mtk-tphy.txt | 78 --- > 1 file changed, 68 insertions(+), 10 deletions(-) > Reviewed-by: Weijie Gao
Re: [PATCH 1/3] mips: mt76x8: ddr_cal: Rename dqs_test_valid() to dqs_test_error()
On Fri, 2020-03-06 at 15:14 +0100, Stefan Roese wrote: > This function returns "-1" (true) upon error. So the function name does > not match its implementation which is confusing. This patch renames the > function to dqs_test_error() which makes the code easier to read. > > Also change the return type to bool and return "true" or "false". > > Signed-off-by: Stefan Roese > Cc: Weijie Gao > Cc: Daniel Schwierzeck > --- > arch/mips/mach-mtmips/ddr_cal.c | 12 ++-- > 1 file changed, 6 insertions(+), 6 deletions(-) > Reviewed-by: Weijie Gao
Re: [PATCH 2/3] mips: mt76x8: ddr_cal: Change types from u32 to int in dqs_find_min/max
On Fri, 2020-03-06 at 15:14 +0100, Stefan Roese wrote: > This change is made to enable comparison of integer variables, which > might be negative in the next patch. No functional change is intended > in this patch. > > Signed-off-by: Stefan Roese > Cc: Weijie Gao > Cc: Daniel Schwierzeck > --- > arch/mips/mach-mtmips/ddr_cal.c | 14 -- > 1 file changed, 8 insertions(+), 6 deletions(-) > Reviewed-by: Weijie Gao
Re: [PATCH 3/3] mips: mt76x8: ddr_cal: Correct dqs_find_min/max implementations
On Fri, 2020-03-06 at 15:14 +0100, Stefan Roese wrote: > The current implementations have some issues detecting the correct > values: > > dqs_find_max() will return "last passing fieldval + 1" instead of > "last passing fieldval". Also it will return "maxval + 1" in the > case that all fieldvals are tested valid (without error). > > dqs_find_min() will not test the "lowest" value because of using ">" > instead of ">=". > > This patch now rewrites these functions to fix those issues. Also, > this patch uses the same approach of a for loop in both functions making > it easier to read and maintain. > > Since the variables are integers now, we can use min()/max(), which > handles the wrap around case for fieldval=0: return (0 - 1). > > Signed-off-by: Stefan Roese > Cc: Weijie Gao > Cc: Daniel Schwierzeck > --- > arch/mips/mach-mtmips/ddr_cal.c | 28 ++-- > 1 file changed, 10 insertions(+), 18 deletions(-) > Reviewed-by: Weijie Gao
Re: [Uboot-stm32] [PATCH 1/2] net: dwc_eth_qos: implement reset-gpios for stm32
Hi
On 3/18/20 10:50 AM, Patrick Delaunay wrote:
> From: Christophe Roullier
>
> Add management of property "reset-gpios" in the node identified by
> "phy-handle" to configure any GPIO used to reset the PHY.
>
> Signed-off-by: Christophe Roullier
> Reviewed-by: Patrice CHOTARD
> Reviewed-by: Patrick DELAUNAY
> Signed-off-by: Patrick Delaunay
> ---
>
> drivers/net/dwc_eth_qos.c | 53 +++
> 1 file changed, 53 insertions(+)
Applied to u-boot-stm/next
Thanks
Patrice
>
> diff --git a/drivers/net/dwc_eth_qos.c b/drivers/net/dwc_eth_qos.c
> index 0564bebf76..4796659216 100644
> --- a/drivers/net/dwc_eth_qos.c
> +++ b/drivers/net/dwc_eth_qos.c
> @@ -694,6 +694,29 @@ static int eqos_start_resets_tegra186(struct udevice
> *dev)
>
> static int eqos_start_resets_stm32(struct udevice *dev)
> {
> + struct eqos_priv *eqos = dev_get_priv(dev);
> + int ret;
> +
> + debug("%s(dev=%p):\n", __func__, dev);
> + if (dm_gpio_is_valid(&eqos->phy_reset_gpio)) {
> + ret = dm_gpio_set_value(&eqos->phy_reset_gpio, 1);
> + if (ret < 0) {
> + pr_err("dm_gpio_set_value(phy_reset, assert) failed:
> %d",
> +ret);
> + return ret;
> + }
> +
> + udelay(2);
> +
> + ret = dm_gpio_set_value(&eqos->phy_reset_gpio, 0);
> + if (ret < 0) {
> + pr_err("dm_gpio_set_value(phy_reset, deassert) failed:
> %d",
> +ret);
> + return ret;
> + }
> + }
> + debug("%s: OK\n", __func__);
> +
> return 0;
> }
>
> @@ -709,6 +732,18 @@ static int eqos_stop_resets_tegra186(struct udevice *dev)
>
> static int eqos_stop_resets_stm32(struct udevice *dev)
> {
> + struct eqos_priv *eqos = dev_get_priv(dev);
> + int ret;
> +
> + if (dm_gpio_is_valid(&eqos->phy_reset_gpio)) {
> + ret = dm_gpio_set_value(&eqos->phy_reset_gpio, 1);
> + if (ret < 0) {
> + pr_err("dm_gpio_set_value(phy_reset, assert) failed:
> %d",
> +ret);
> + return ret;
> + }
> + }
> +
> return 0;
> }
>
> @@ -1604,6 +1639,7 @@ static int eqos_probe_resources_stm32(struct udevice
> *dev)
> struct eqos_priv *eqos = dev_get_priv(dev);
> int ret;
> phy_interface_t interface;
> + struct ofnode_phandle_args phandle_args;
>
> debug("%s(dev=%p):\n", __func__, dev);
>
> @@ -1641,6 +1677,20 @@ static int eqos_probe_resources_stm32(struct udevice
> *dev)
> if (ret)
> pr_warn("No phy clock provided %d", ret);
>
> + ret = dev_read_phandle_with_args(dev, "phy-handle", NULL, 0, 0,
> + &phandle_args);
> + if (!ret) {
> + /* search "reset-gpios" in phy node */
> + ret = gpio_request_by_name_nodev(phandle_args.node,
> + "reset-gpios", 0,
> + &eqos->phy_reset_gpio,
> + GPIOD_IS_OUT |
> + GPIOD_IS_OUT_ACTIVE);
> + if (ret)
> + pr_warn("gpio_request_by_name(phy reset) not provided
> %d",
> + ret);
> + }
> +
> debug("%s: OK\n", __func__);
> return 0;
>
> @@ -1704,6 +1754,9 @@ static int eqos_remove_resources_stm32(struct udevice
> *dev)
> if (clk_valid(&eqos->clk_ck))
> clk_free(&eqos->clk_ck);
>
> + if (dm_gpio_is_valid(&eqos->phy_reset_gpio))
> + dm_gpio_free(dev, &eqos->phy_reset_gpio);
> +
> debug("%s: OK\n", __func__);
> return 0;
> }
Re: [Uboot-stm32] [PATCH 2/2] net: dwc_eth_qos: implement phy reg and max-speed for stm32
Hi
On 3/18/20 10:50 AM, Patrick Delaunay wrote:
> Add management of property "reg" to configure @ of phy and
> also "max-speed" property to specify maximum speed in Mbit/s
> supported by the device
>
> Signed-off-by: Christophe Roullier
> Reviewed-by: Patrick DELAUNAY
> Signed-off-by: Patrick Delaunay
> ---
>
> drivers/net/dwc_eth_qos.c | 19 ++-
> 1 file changed, 18 insertions(+), 1 deletion(-)
Applied to u-boot-stm/next
Thanks
Patrice
>
> diff --git a/drivers/net/dwc_eth_qos.c b/drivers/net/dwc_eth_qos.c
> index 4796659216..63f2086dec 100644
> --- a/drivers/net/dwc_eth_qos.c
> +++ b/drivers/net/dwc_eth_qos.c
> @@ -306,6 +306,8 @@ struct eqos_priv {
> struct clk clk_slave_bus;
> struct mii_dev *mii;
> struct phy_device *phy;
> + int phyaddr;
> + u32 max_speed;
> void *descs;
> struct eqos_desc *tx_descs;
> struct eqos_desc *rx_descs;
> @@ -1081,12 +1083,21 @@ static int eqos_start(struct udevice *dev)
>* don't need to reconnect/reconfigure again
>*/
> if (!eqos->phy) {
> - eqos->phy = phy_connect(eqos->mii, -1, dev,
> + eqos->phy = phy_connect(eqos->mii, eqos->phyaddr, dev,
> eqos->config->interface(dev));
> if (!eqos->phy) {
> pr_err("phy_connect() failed");
> goto err_stop_resets;
> }
> +
> + if (eqos->max_speed) {
> + ret = phy_set_supported(eqos->phy, eqos->max_speed);
> + if (ret) {
> + pr_err("phy_set_supported() failed: %d", ret);
> + goto err_shutdown_phy;
> + }
> + }
> +
> ret = phy_config(eqos->phy);
> if (ret < 0) {
> pr_err("phy_config() failed: %d", ret);
> @@ -1654,6 +1665,8 @@ static int eqos_probe_resources_stm32(struct udevice
> *dev)
> if (ret)
> return -EINVAL;
>
> + eqos->max_speed = dev_read_u32_default(dev, "max-speed", 0);
> +
> ret = clk_get_by_name(dev, "stmmaceth", &eqos->clk_master_bus);
> if (ret) {
> pr_err("clk_get_by_name(master_bus) failed: %d", ret);
> @@ -1677,6 +1690,7 @@ static int eqos_probe_resources_stm32(struct udevice
> *dev)
> if (ret)
> pr_warn("No phy clock provided %d", ret);
>
> + eqos->phyaddr = -1;
> ret = dev_read_phandle_with_args(dev, "phy-handle", NULL, 0, 0,
>&phandle_args);
> if (!ret) {
> @@ -1689,6 +1703,9 @@ static int eqos_probe_resources_stm32(struct udevice
> *dev)
> if (ret)
> pr_warn("gpio_request_by_name(phy reset) not provided
> %d",
> ret);
> +
> + eqos->phyaddr = ofnode_read_u32_default(phandle_args.node,
> + "reg", -1);
> }
>
> debug("%s: OK\n", __func__);
Re: [PATCH] ARM: dts: stm32: Define FMC2 base address
Hi On 4/9/20 7:31 PM, Patrick DELAUNAY wrote: > Dear, > >> From: Marek Vasut >> Sent: jeudi 9 avril 2020 13:23 >> >> On 4/1/20 3:45 PM, Patrick DELAUNAY wrote: >>> Hi Marek, >> Hi, >> From: Marek Vasut Sent: jeudi 26 mars 2020 16:57 Define FMC2 base address, for use in board files, until there is an actual FMC2 bus driver. Signed-off-by: Marek Vasut Cc: Patrick Delaunay Cc: Patrice Chotard --- arch/arm/mach-stm32mp/include/mach/stm32.h | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/mach-stm32mp/include/mach/stm32.h b/arch/arm/mach- stm32mp/include/mach/stm32.h index f0636005e5..62d95d7f88 100644 --- a/arch/arm/mach-stm32mp/include/mach/stm32.h +++ b/arch/arm/mach-stm32mp/include/mach/stm32.h @@ -13,6 +13,7 @@ #define STM32_RCC_BASE0x5000 #define STM32_PWR_BASE0x50001000 #define STM32_DBGMCU_BASE 0x50081000 +#define STM32_FMC2_BASE 0x58002000 >>> For me, the address should be defined in this file only for the few >>> addresses used before device tree avaibility: I want to avoid to have all >>> the >> device defined here. >>> But normally it is not the case for FMC2, even if I understand the current >>> need, >> without FMC2 bus driver >>> I will take this patch only it is not possible to get FMC2 address from >>> device >> tree. >> >> I can parse this information from the DT, but what would be the benefit? >> Slower boot due to the need to traverse DT and more complex code? > I am convinced now (thanks to Christophe) because the correct FMC bus driver > is not yet ready... > > It will be clean-up later when no more used. > > Reviewed-by: Patrick Delaunay > > Thanks > > Patrick > > Applied to u-boot-stm/next Thanks Patrice
Re: [PATCH V4] ARM: dts: stm32: Add KS8851-16MLL ethernet on FMC2
Hi
On 3/30/20 12:12 PM, Patrice CHOTARD wrote:
> Hi Marek
>
> On 3/28/20 2:01 AM, Marek Vasut wrote:
>> Add DT entries, Kconfig entries and board-specific entries to configure
>> FMC2 bus and make KS8851-16MLL on that bus accessible to U-Boot.
>>
>> Signed-off-by: Marek Vasut
>> Cc: Patrick Delaunay
>> Cc: Patrice Chotard
>> ---
>> V2: Configure FMC2 nCS4 for SRAM as well
>> V3: Adjust the register macros
>> V4: Use more macros
>> ---
>> arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi | 68 ++
>> board/dhelectronics/dh_stm32mp1/board.c| 52 +
>> configs/stm32mp15_dhcom_basic_defconfig| 1 +
>> 3 files changed, 121 insertions(+)
>>
>> diff --git a/arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi
>> b/arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi
>> index 6c952a57ee..eba3588540 100644
>> --- a/arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi
>> +++ b/arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi
>> @@ -37,6 +37,12 @@
>> default-state = "on";
>> };
>> };
>> +
>> +/* This is actually on FMC2, but we do not have bus driver for that */
>> +ksz8851: ks8851mll@6400 {
>> +compatible = "micrel,ks8851-mll";
>> +reg = <0x6400 0x2>;
>> +};
>> };
>>
>> &i2c4 {
>> @@ -50,6 +56,68 @@
>> };
>> };
>>
>> +&pinctrl {
>> +/* These should bound to FMC2 bus driver, but we do not have one */
>> +pinctrl-0 = <&fmc_pins_b>;
>> +pinctrl-1 = <&fmc_sleep_pins_b>;
>> +pinctrl-names = "default", "sleep";
>> +
>> +fmc_pins_b: fmc-0 {
>> +pins1 {
>> +pinmux = , /* FMC_NOE */
>> + , /* FMC_NWE */
>> + , /* FMC_NL */
>> + , /* FMC_D0 */
>> + , /* FMC_D1 */
>> + , /* FMC_D2 */
>> + , /* FMC_D3 */
>> + , /* FMC_D4 */
>> + , /* FMC_D5 */
>> + , /* FMC_D6 */
>> + , /* FMC_D7 */
>> + , /* FMC_D8 */
>> + , /* FMC_D9 */
>> + , /* FMC_D10 */
>> + , /* FMC_D11 */
>> + , /* FMC_D12 */
>> + , /* FMC_D13 */
>> + , /* FMC_D14 */
>> + , /* FMC_D15 */
>> + , /*
>> FMC_NE2_FMC_NCE */
>> + ; /* FMC_NE4 */
>> +bias-disable;
>> +drive-push-pull;
>> +slew-rate = <3>;
>> +};
>> +};
>> +
>> +fmc_sleep_pins_b: fmc-sleep-0 {
>> +pins {
>> +pinmux = , /* FMC_NOE */
>> + , /* FMC_NWE */
>> + , /* FMC_NL */
>> + , /* FMC_D0 */
>> + , /* FMC_D1 */
>> + , /* FMC_D2 */
>> + , /* FMC_D3 */
>> + , /* FMC_D4 */
>> + , /* FMC_D5 */
>> + , /* FMC_D6 */
>> + , /* FMC_D7 */
>> + , /* FMC_D8 */
>> + , /* FMC_D9 */
>> + , /* FMC_D10 */
>> + , /* FMC_D11 */
>> + , /* FMC_D12 */
>> + , /* FMC_D13 */
>> + , /* FMC_D14 */
>> + , /* FMC_D15 */
>> + , /*
>> FMC_NE2_FMC_NCE */
>> + ; /* FMC_NE4 */
>> +};
>> +};
>> +};
>> +
>> &pmic {
>> u-boot,dm-pre-reloc;
>> };
>> diff --git a/board/dhelectronics/dh_stm32mp1/board.c
>> b/board/dhelectronics/dh_stm32mp1/board.c
>> index 7bcd713a86..a3458a2623 100644
>> --- a/board/dhelectronics/dh_stm32mp1/board.c
>> +++ b/board/dhelectronics/dh_stm32mp1/board.c
>> @@ -375,6 +375,56 @@ static void sysconf_init(void)
>> #endif
>> }
>>
>> +static void board_init_fmc2(void)
>> +{
>> +#define STM32_FMC2_BCR1 0x0
>> +#define STM32_FMC2_BTR1 0x4
>> +#define STM32_FMC2_BWTR10x104
>> +#define STM32_FMC2_BCR(x) ((x) * 0x8 + STM32_FMC2_BCR1)
>> +#define STM32_FMC2_BCRx_FMCEN BIT(31)
>> +#define STM32_FMC2_BCRx_WRENBIT(12)
>> +#define STM32_FMC2_BCRx_RSVDBIT(7)
>> +#define STM32_FMC2_BCRx_FACCEN BIT(6)
>> +#define STM32_FMC2_BCRx_MWID(n) ((n) << 4)
>> +#define STM32_FMC2_BCRx_MTYP(n) ((n) << 2)
>> +#define STM32_FMC2_BCRx_MUXEN BIT(1)
>> +#define STM32_FMC2_BCRx_MBKEN BIT(0)
>> +
Re: [Uboot-stm32] [PATCH] configs: stm32mp1: replace STM32MP1_TRUSTED by TFABOOT
Hi
On 4/1/20 9:46 AM, Patrice CHOTARD wrote:
> Hi Patrick
>
> On 4/1/20 9:07 AM, Patrick Delaunay wrote:
>> Activate ARCH_SUPPORT_TFABOOT and replace the arch stm32mp
>> specific config CONFIG_STM32MP1_TRUSTED by the generic CONFIG_TFABOOT
>> introduced by the commit 535d76a12150 ("armv8: layerscape: Add TFABOOT
>> support").
>> This config CONFIG_TFABOOT is activated for the trusted boot chain,
>> when U-Boot is loaded by TF-A.
>>
>> Signed-off-by: Patrick Delaunay
>> ---
Applied to u-boot-stm/next
Thanks
Patrice
>>
>> arch/arm/Kconfig| 1 +
>> arch/arm/mach-stm32mp/Kconfig | 21 ++---
>> arch/arm/mach-stm32mp/bsec.c| 18 +-
>> arch/arm/mach-stm32mp/cpu.c | 10 +-
>> board/dhelectronics/dh_stm32mp1/board.c | 4 ++--
>> board/st/stm32mp1/stm32mp1.c| 4 ++--
>> configs/stm32mp15_optee_defconfig | 1 +
>> configs/stm32mp15_trusted_defconfig | 1 +
>> drivers/clk/clk_stm32mp1.c | 2 +-
>> drivers/ram/stm32mp1/stm32mp1_ram.c | 2 +-
>> include/configs/stm32mp1.h | 2 +-
>> 11 files changed, 30 insertions(+), 36 deletions(-)
>>
>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
>> index 5d367888d8..54ff4557d4 100644
>> --- a/arch/arm/Kconfig
>> +++ b/arch/arm/Kconfig
>> @@ -1583,6 +1583,7 @@ config ARCH_STI
>> config ARCH_STM32MP
>> bool "Support STMicroelectronics STM32MP Socs with cortex A"
>> select ARCH_MISC_INIT
>> +select ARCH_SUPPORT_TFABOOT
>> select BOARD_LATE_INIT
>> select CLK
>> select DM
>> diff --git a/arch/arm/mach-stm32mp/Kconfig b/arch/arm/mach-stm32mp/Kconfig
>> index e4d621dee8..e42e9e2e82 100644
>> --- a/arch/arm/mach-stm32mp/Kconfig
>> +++ b/arch/arm/mach-stm32mp/Kconfig
>> @@ -35,9 +35,10 @@ config ENV_SIZE
>>
>> config STM32MP15x
>> bool "Support STMicroelectronics STM32MP15x Soc"
>> -select ARCH_SUPPORT_PSCI if !STM32MP1_TRUSTED
>> +select ARCH_SUPPORT_PSCI if !TFABOOT
>> +select ARM_SMCCC if TFABOOT
>> select CPU_V7A
>> -select CPU_V7_HAS_NONSEC if !STM32MP1_TRUSTED
>> +select CPU_V7_HAS_NONSEC if !TFABOOT
>> select CPU_V7_HAS_VIRT
>> select OF_BOARD_SETUP
>> select PINCTRL_STM32
>> @@ -45,8 +46,8 @@ config STM32MP15x
>> select STM32_RESET
>> select STM32_SERIAL
>> select SYS_ARCH_TIMER
>> -imply SYSRESET_PSCI if STM32MP1_TRUSTED
>> -imply SYSRESET_SYSCON if !STM32MP1_TRUSTED
>> +imply SYSRESET_PSCI if TFABOOT
>> +imply SYSRESET_SYSCON if !TFABOOT
>> help
>> support of STMicroelectronics SOC STM32MP15x family
>> STM32MP157, STM32MP153 or STM32MP151
>> @@ -83,19 +84,9 @@ config TARGET_DH_STM32MP1_PDK2
>>
>> endchoice
>>
>> -config STM32MP1_TRUSTED
>> -bool "Support trusted boot with TF-A"
>> -default y if !SPL
>> -select ARM_SMCCC
>> -help
>> -Say Y here to enable boot with TF-A
>> -Trusted boot chain is :
>> -BootRom => TF-A.stm32 (clock & DDR) => U-Boot.stm32
>> -TF-A monitor provides proprietary SMC to manage secure devices
>> -
>> config STM32MP1_OPTEE
>> bool "Support trusted boot with TF-A and OP-TEE"
>> -depends on STM32MP1_TRUSTED
>> +depends on TFABOOT
>> default n
>> help
>> Say Y here to enable boot with TF-A and OP-TEE
>> diff --git a/arch/arm/mach-stm32mp/bsec.c b/arch/arm/mach-stm32mp/bsec.c
>> index 3b923f088e..0d5850b4a9 100644
>> --- a/arch/arm/mach-stm32mp/bsec.c
>> +++ b/arch/arm/mach-stm32mp/bsec.c
>> @@ -68,7 +68,7 @@ static bool bsec_read_lock(u32 address, u32 otp)
>> return !!(readl(address + bank) & bit);
>> }
>>
>> -#ifndef CONFIG_STM32MP1_TRUSTED
>> +#ifndef CONFIG_TFABOOT
>> /**
>> * bsec_check_error() - Check status of one otp
>> * @base: base address of bsec IP
>> @@ -273,7 +273,7 @@ static int bsec_program_otp(long base, u32 val, u32 otp)
>>
>> return ret;
>> }
>> -#endif /* CONFIG_STM32MP1_TRUSTED */
>> +#endif /* CONFIG_TFABOOT */
>>
>> /* BSEC MISC driver ***/
>> struct stm32mp_bsec_platdata {
>> @@ -282,7 +282,7 @@ struct stm32mp_bsec_platdata {
>>
>> static int stm32mp_bsec_read_otp(struct udevice *dev, u32 *val, u32 otp)
>> {
>> -#ifdef CONFIG_STM32MP1_TRUSTED
>> +#ifdef CONFIG_TFABOOT
>> return stm32_smc(STM32_SMC_BSEC,
>> STM32_SMC_READ_OTP,
>> otp, 0, val);
>> @@ -313,7 +313,7 @@ static int stm32mp_bsec_read_otp(struct udevice *dev,
>> u32 *val, u32 otp)
>>
>> static int stm32mp_bsec_read_shadow(struct udevice *dev, u32 *val, u32 otp)
>> {
>> -#ifdef CONFIG_STM32MP1_TRUSTED
>> +#ifdef CONFIG_TFABOOT
>> return stm32_smc(STM32_SMC_BSEC,
>> STM32_SMC_READ_SHADOW,
>> otp, 0, val);
>> @@ -336,7 +336,7 @@ static int stm32mp_bsec_read_lock(struct udevice *dev,
>> u32 *val,
Re: [PATCH v3 19/23] travis/gitlab/azure: Use -W to avoid warnings check
Hi Simon,
st 18. 3. 2020 v 16:48 odesílatel Simon Glass napsal:
>
> We can use the -W flag to tell buildman to ignore warnings. Since we also
> have -E defined, compiler warnings are promoted to errors, so they will
> still cause a failure. But migration warnings of the form:
>
> = WARNING ==
> This board does not use CONFIG_DM. CONFIG_DM will be
> compulsory starting with the v2020.01 release.
> Failure to update may result in board removal.
> See doc/driver-model/migration.rst for more info.
>
> will now be ignored.
>
> Signed-off-by: Simon Glass
> Fixes: 329f5ef51d2 (travis.yml: run buildman with option -E)
> ---
>
> Changes in v3:
> - Bring back the -E flag and add -W
> - Rewrite the commit message
>
> Changes in v2:
> - Add Fixes tag
> - Just drop the -E flag
> - Update travis, azure also
>
> .azure-pipelines.yml | 8
> .gitlab-ci.yml | 23 +++
> .travis.yml | 13 ++---
> 3 files changed, 21 insertions(+), 23 deletions(-)
>
> diff --git a/.azure-pipelines.yml b/.azure-pipelines.yml
> index 50d00fa899..a97a3f8b19 100644
> --- a/.azure-pipelines.yml
> +++ b/.azure-pipelines.yml
> @@ -247,8 +247,8 @@ jobs:
>cd ${WORK_DIR}
>export UBOOT_TRAVIS_BUILD_DIR=/tmp/${TEST_PY_BD};
>ret=0;
> - tools/buildman/buildman -o ${UBOOT_TRAVIS_BUILD_DIR} -w -E --board
> ${TEST_PY_BD} ${OVERRIDE} || ret=$?;
> - if [[ $ret -ne 0 && $ret -ne 129 ]]; then
> + tools/buildman/buildman -o ${UBOOT_TRAVIS_BUILD_DIR} -w -E -W
> --board ${TEST_PY_BD} ${OVERRIDE} || ret=$?;
> + if [[ $ret -ne 0 ]]; then
>tools/buildman/buildman -o ${UBOOT_TRAVIS_BUILD_DIR} -w -se
> --board ${TEST_PY_BD};
>exit $ret;
>fi
> @@ -396,8 +396,8 @@ jobs:
>cat << "EOF" >> build.sh
>if [[ "${BUILDMAN}" != "" ]]; then
>ret=0;
> - tools/buildman/buildman -o /tmp -P -E ${BUILDMAN} ${OVERRIDE}
> || ret=$?;
> - if [[ $ret -ne 0 && $ret -ne 129 ]]; then
> + tools/buildman/buildman -o /tmp -P -W ${BUILDMAN} ${OVERRIDE}
> || ret=$?;
> + if [[ $ret -ne 0 ]]; then
>tools/buildman/buildman -o /tmp -seP ${BUILDMAN};
>exit $ret;
>fi;
> diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
> index 48b90b2ba3..501e3ff3ab 100644
> --- a/.gitlab-ci.yml
> +++ b/.gitlab-ci.yml
> @@ -27,13 +27,12 @@ stages:
>after_script:
> - rm -rf /tmp/uboot-test-hooks /tmp/venv
>script:
> -# From buildman, exit code 129 means warnings only. If we've been asked
> to
> -# use clang only do one configuration.
> +# If we've been asked to use clang only do one configuration.
> - export UBOOT_TRAVIS_BUILD_DIR=/tmp/${TEST_PY_BD}
> - ret=0;
> - tools/buildman/buildman -o ${UBOOT_TRAVIS_BUILD_DIR} -w -E
> + tools/buildman/buildman -o ${UBOOT_TRAVIS_BUILD_DIR} -w -E -W
> --board ${TEST_PY_BD} ${OVERRIDE} || ret=$?;
> - if [[ $ret -ne 0 && $ret -ne 129 ]]; then
> + if [[ $ret -ne 0 ]]; then
> tools/buildman/buildman -o ${UBOOT_TRAVIS_BUILD_DIR} -w -se
> --board ${TEST_PY_BD};
> exit $ret;
> @@ -57,8 +56,8 @@ build all 32bit ARM platforms:
>stage: world build
>script:
> - ret=0;
> - ./tools/buildman/buildman -o /tmp -P -E arm -x aarch64 || ret=$?;
> - if [[ $ret -ne 0 && $ret -ne 129 ]]; then
> + ./tools/buildman/buildman -o /tmp -P -E -W arm -x aarch64 || ret=$?;
> + if [[ $ret -ne 0 ]]; then
> ./tools/buildman/buildman -o /tmp -seP;
> exit $ret;
>fi;
> @@ -71,8 +70,8 @@ build all 64bit ARM platforms:
> - . /tmp/venv/bin/activate
> - pip install pyelftools
> - ret=0;
> - ./tools/buildman/buildman -o /tmp -P -E aarch64 || ret=$?;
> - if [[ $ret -ne 0 && $ret -ne 129 ]]; then
> + ./tools/buildman/buildman -o /tmp -P -E -W aarch64 || ret=$?;
> + if [[ $ret -ne 0 ]]; then
> ./tools/buildman/buildman -o /tmp -seP;
> exit $ret;
>fi;
> @@ -82,8 +81,8 @@ build all PowerPC platforms:
>stage: world build
>script:
> - ret=0;
> - ./tools/buildman/buildman -o /tmp -P -E powerpc || ret=$?;
> - if [[ $ret -ne 0 && $ret -ne 129 ]]; then
> + ./tools/buildman/buildman -o /tmp -P -E -W powerpc || ret=$?;
> + if [[ $ret -ne 0 ]]; then
> ./tools/buildman/buildman -o /tmp -seP;
> exit $ret;
>fi;
> @@ -93,8 +92,8 @@ build all other platforms:
>stage: world build
>script:
> - ret=0;
> - ./tools/buildman/buildman -o /tmp -P -E -x arm,powerpc || ret=$?;
> - if [[ $ret -ne 0 && $ret -ne 129 ]]; then
> + ./tools/buildman/buildman -o /tmp -P -E -W -x arm,powerpc || ret=$?;
> + if [[ $ret -ne 0 ]]; then
> ./tools/buildman/buildman -o /tmp -seP;
>
Re: [PATCH] ARM: dts: stm32: Rename LEDs to match silkscreen on AV96
Hi
On 4/6/20 8:01 PM, Manivannan Sadhasivam wrote:
> On Mon, Apr 06, 2020 at 03:05:58PM +0200, Marek Vasut wrote:
>> The LED labels do not match the silkscreen on the board, fix it.
>>
>> Signed-off-by: Marek Vasut
> Reviewed-by: Manivannan Sadhasivam
>
> Thanks,
> Mani
Applied to u-boot-stm/next
Thanks
Patrice
>> Cc: Manivannan Sadhasivam
>> Cc: Patrick Delaunay
>> Cc: Patrice Chotard
>> Cc: Tom Rini
>> ---
>> arch/arm/dts/stm32mp157a-avenger96.dts | 6 +++---
>> 1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/arm/dts/stm32mp157a-avenger96.dts
>> b/arch/arm/dts/stm32mp157a-avenger96.dts
>> index 1f32395e71..735228a895 100644
>> --- a/arch/arm/dts/stm32mp157a-avenger96.dts
>> +++ b/arch/arm/dts/stm32mp157a-avenger96.dts
>> @@ -36,21 +36,21 @@
>> led {
>> compatible = "gpio-leds";
>> led1 {
>> -label = "green:user1";
>> +label = "green:user0";
>> gpios = <&gpioz 7 GPIO_ACTIVE_HIGH>;
>> linux,default-trigger = "heartbeat";
>> default-state = "off";
>> };
>>
>> led2 {
>> -label = "green:user2";
>> +label = "green:user1";
>> gpios = <&gpiof 3 GPIO_ACTIVE_HIGH>;
>> linux,default-trigger = "mmc0";
>> default-state = "off";
>> };
>>
>> led3 {
>> -label = "green:user3";
>> +label = "green:user2";
>> gpios = <&gpiog 0 GPIO_ACTIVE_HIGH>;
>> linux,default-trigger = "mmc1";
>> default-state = "off";
>> --
>> 2.25.1
>>
Re: [Uboot-stm32] [PATCH] board: stm32mp1: correct CONFIG_IS_ENABLED usage for LED
Hi On 4/14/20 2:53 PM, Patrice CHOTARD wrote: > Hi > > On 4/10/20 7:14 PM, Patrick Delaunay wrote: >> Use the correct macro to test presence CONFIG_LED: >> replace CONFIG_IS_ENABLED(CONFIG_LED) by CONFIG_IS_ENABLED(LED) >> >> Issue see during review unrelated patch >> "board: stm32mp1: update management of boot-led" >> http://patchwork.ozlabs.org/patch/1264823/ >> >> Cc: Marek Vasut >> Cc: Patrice Chotard >> Signed-off-by: Patrick Delaunay >> --- >> >> board/dhelectronics/dh_stm32mp1/board.c | 2 +- >> board/st/stm32mp1/stm32mp1.c| 2 +- >> 2 files changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/board/dhelectronics/dh_stm32mp1/board.c >> b/board/dhelectronics/dh_stm32mp1/board.c >> index 7bcd713a86..3c14d8206d 100644 >> --- a/board/dhelectronics/dh_stm32mp1/board.c >> +++ b/board/dhelectronics/dh_stm32mp1/board.c >> @@ -398,7 +398,7 @@ int board_init(void) >> >> sysconf_init(); >> >> -if (CONFIG_IS_ENABLED(CONFIG_LED)) >> +if (CONFIG_IS_ENABLED(LED)) >> led_default_state(); >> >> return 0; >> diff --git a/board/st/stm32mp1/stm32mp1.c b/board/st/stm32mp1/stm32mp1.c >> index 07f5344ec9..053c5e1f07 100644 >> --- a/board/st/stm32mp1/stm32mp1.c >> +++ b/board/st/stm32mp1/stm32mp1.c >> @@ -647,7 +647,7 @@ int board_init(void) >> >> sysconf_init(); >> >> -if (CONFIG_IS_ENABLED(CONFIG_LED)) >> +if (CONFIG_IS_ENABLED(LED)) >> led_default_state(); >> >> return 0; > Reviewed-by: Patrice Chotard > > Thanks > > Patrice Applied to u-boot-stm/next Thanks Patrice > ___ > Uboot-stm32 mailing list > uboot-st...@st-md-mailman.stormreply.com > https://st-md-mailman.stormreply.com/mailman/listinfo/uboot-stm32
Re: [Uboot-stm32] [PATCH] ARM: stm32: Enable bootd, iminfo, imxtract on ST defconfig
Hi On 4/14/20 2:52 PM, Patrice CHOTARD wrote: > Hi > > On 4/10/20 6:13 PM, Patrick Delaunay wrote: >> Enable these standard U-Boot commands for image manipulation and for >> starting the default boot command using 'boot' command in U-Boot shell. >> >> Cc: Marek Vasut >> Cc: Patrice Chotard >> Signed-off-by: Patrick Delaunay >> --- >> >> configs/stm32mp15_basic_defconfig | 3 --- >> configs/stm32mp15_trusted_defconfig | 3 --- >> 2 files changed, 6 deletions(-) >> >> diff --git a/configs/stm32mp15_basic_defconfig >> b/configs/stm32mp15_basic_defconfig >> index 6d82365348..c8f1780cab 100644 >> --- a/configs/stm32mp15_basic_defconfig >> +++ b/configs/stm32mp15_basic_defconfig >> @@ -21,10 +21,7 @@ CONFIG_SPL_MTD_SUPPORT=y >> CONFIG_SPL_POWER_SUPPORT=y >> CONFIG_SYS_SPI_U_BOOT_OFFS=0x8 >> CONFIG_SYS_PROMPT="STM32MP> " >> -# CONFIG_CMD_BOOTD is not set >> # CONFIG_CMD_ELF is not set >> -# CONFIG_CMD_IMI is not set >> -# CONFIG_CMD_XIMG is not set >> # CONFIG_CMD_EXPORTENV is not set >> # CONFIG_CMD_IMPORTENV is not set >> CONFIG_CMD_MEMINFO=y >> diff --git a/configs/stm32mp15_trusted_defconfig >> b/configs/stm32mp15_trusted_defconfig >> index 6928e9a65c..82a8b709cd 100644 >> --- a/configs/stm32mp15_trusted_defconfig >> +++ b/configs/stm32mp15_trusted_defconfig >> @@ -9,10 +9,7 @@ CONFIG_DISTRO_DEFAULTS=y >> CONFIG_FIT=y >> CONFIG_BOOTCOMMAND="run bootcmd_stm32mp" >> CONFIG_SYS_PROMPT="STM32MP> " >> -# CONFIG_CMD_BOOTD is not set >> # CONFIG_CMD_ELF is not set >> -# CONFIG_CMD_IMI is not set >> -# CONFIG_CMD_XIMG is not set >> # CONFIG_CMD_EXPORTENV is not set >> # CONFIG_CMD_IMPORTENV is not set >> CONFIG_CMD_MEMINFO=y > Reviewed-by: Patrice Chotard > > Thanks > > Patrice Applied to u-boot-stm/next Thanks Patrice > ___ > Uboot-stm32 mailing list > uboot-st...@st-md-mailman.stormreply.com > https://st-md-mailman.stormreply.com/mailman/listinfo/uboot-stm32
Re: [PATCH 1/3] mips: mt76x8: ddr_cal: Rename dqs_test_valid() to dqs_test_error()
Hi Weijie, thanks for reviewing. Could you please also review the latest RFC version of my "generification" of the legacy lzma support as well? I really would like to see some review comments before sending v7 of this patchset to get it (hopefully) accepted in this merge window. http://patchwork.ozlabs.org/project/uboot/patch/20200410110431.12256-1...@denx.de/ http://patchwork.ozlabs.org/project/uboot/patch/20200410110431.12256-2...@denx.de/ http://patchwork.ozlabs.org/project/uboot/patch/20200410110431.12256-2...@denx.de/ Thanks, Stefan On 15.04.20 09:19, Weijie Gao wrote: On Fri, 2020-03-06 at 15:14 +0100, Stefan Roese wrote: This function returns "-1" (true) upon error. So the function name does not match its implementation which is confusing. This patch renames the function to dqs_test_error() which makes the code easier to read. Also change the return type to bool and return "true" or "false". Signed-off-by: Stefan Roese Cc: Weijie Gao Cc: Daniel Schwierzeck --- arch/mips/mach-mtmips/ddr_cal.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) Reviewed-by: Weijie Gao Viele Grüße, Stefan -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk 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: [RFC PATCH] powerpc, qe: add DTS support for parallel I/O ports
On 2020/4/15 12:46 Heiko Schocher
> -Original Message-
> From: Heiko Schocher
> Sent: 2020年4月15日 12:46
> To: Qiang Zhao
> Cc: U-Boot Mailing List ; Holger Brunck
> ; Mario Six ; Wolfgang Denk
> ; Holger Brunck
> Subject: Re: [RFC PATCH] powerpc, qe: add DTS support for parallel I/O ports
>
> Hello Qiang Zhao,
>
> Am 09.04.2020 um 08:58 schrieb Qiang Zhao:
> > On 2020/2/18 17:05, Heiko Schocher mailto:h...@denx.de>>
> wrote:
> >
> >> -Original Message-
> >
> >> From: Heiko Schocher
> >
> >> Sent: 2020年2月18日17:05
> >
> >> To: U-Boot Mailing List
> >
> >> Cc: Heiko Schocher ; Holger Brunck
> >
> >> ; Mario Six ; Qiang
> >> Zhao
> >
> >> ; Wolfgang Denk
> >
> >> Subject: [RFC PATCH] powerpc, qe: add DTS support for parallel I/O
> >> ports
> >
> >>
> >
> >> add DM support for parallel I/O ports on QUICC Engine Block
> >
> >>
> >
> >> Signed-off-by: Heiko Schocher mailto:h...@denx.de>>
> >
> >> ---
> >
> >>
> >
> >>
> >
> >> arch/powerpc/cpu/mpc83xx/cpu_init.c | 8 ++
> >
> >> arch/powerpc/cpu/mpc83xx/qe_io.c | 193
> >
> >> +++-
> >
> >> include/fsl_qe.h | 3 +
> >
> >> 3 files changed, 201 insertions(+), 3 deletions(-)
> >
> >>
> >
> >> diff --git a/arch/powerpc/cpu/mpc83xx/cpu_init.c
> >
> >> b/arch/powerpc/cpu/mpc83xx/cpu_init.c
> >
> >> index af8facad53..cfcc16607c 100644
> >
> >> --- a/arch/powerpc/cpu/mpc83xx/cpu_init.c
> >
> >> +++ b/arch/powerpc/cpu/mpc83xx/cpu_init.c
> >
> > *//*
> >
> > How about mpc85xx?
>
> Yes, this is a Todo (one reason why this patch is RFC). I currently have
> reworked
> this for the mpc83xx based keymile (now abb) boards (which are locally
> running with complete DM/DTS support now).
You mean you have tested RFC patch on your side? That's great!
Would you like to push the dts patch too?
>
> I have one mpx85xx based board I can try, but may others are working on this
> support, so I wanted to post my patches very early, so we can work together on
> it...
>
> As my first question in patch comment is:
>
> may we should move this part to drivers/pinctrl ?
Yes, it is more better to move to drivers/pinctrl.
>
> >> @@ -11,6 +11,9 @@
> >
> >> #ifdef CONFIG_USB_EHCI_FSL
> >
> >> #include
> >
> >> #endif
> >
> >> +#ifdef CONFIG_QE
> >
> >> +#include
> >
> >> +#endif
> >
> > *//*
> >
> > If include this headfile, the function declaration for qe_init and
> > qe_reset in this file should be removed as below:
> >
> > extern void qe_init(uint qe_base);
> >
> > extern void qe_reset(void);
>
> Yes, of course! But this part of code I did not touch... may this needs a
> cleanup
> at all.
Just two lines extern declaration in this file.
>
> >
> >>
> >
> >> #include "lblaw/lblaw.h"
> >
> >> #include "elbc/elbc.h"
> >
> >> @@ -27,6 +30,7 @@ extern void qe_config_iopin(u8 port, u8 pin, int
> >> dir,
> >
> >> extern void qe_init(uint qe_base); extern void qe_reset(void);
> >
> >>
> >
> >> +/**
> >
> >> + * par_io_of_config_node config
> >
> >> + * @dev: pointer to pinctrl device
> >
> >> + * @pio: ofnode of pinconfig property
> >
> >> + */
> >
> >> +static int par_io_of_config_node(struct udevice *dev, ofnode pio) {
> >
> >> + struct qe_io_platdata *plat = dev->platdata;
> >
> >> + volatile qepio83xx_t *par_io = plat->base;
> >
> >> + const unsigned int *pio_map;
> >
> >> + int pio_map_len;
> >
> >> +
> >
> >> + pio_map = ofnode_get_property(pio, "pio-map", &pio_map_len);
> >
> >> + if (pio_map == NULL)
> >
> >> + return -ENOENT;
> >
> >> +
> >
> >> + pio_map_len /= sizeof(unsigned int);
> >
> >> + if ((pio_map_len % 6) != 0) {
> >
> >> + printk(KERN_ERR "pio-map format wrong!\n");
> >
> >> + return -EINVAL;
> >
> >> + }
> >
> >> +
> >
> >> + while (pio_map_len > 0) {
> >
> >> + /*
> >
> >> + * column pio_map[5] from linux (has_irq) not
> >
> >> + * supported in u-boot yet.
> >
> >> + */
> >
> > *//*
> >
> > remove or keep pio_map[5] in uboot dts, which is better?
>
> I think we keep it as it is in linux dts. We simply ignore it (yet) in U-Boot.
That's OK.
>
> >
> >> +
> >
> >> +const struct pinctrl_ops par_io_pinctrl_ops = {
> >
> >> + .set_state = par_io_pinctrl_set_state, };
> >
> >> +
> >
> >> +static const struct udevice_id par_io_pinctrl_match[] = {
> >
> >> + { .compatible = "fsl,mpc8360-par_io"},
> >
> > *//*
> >
> > Why is*//*fsl,mpc8360-par_io, maybe fsl,qe-par-io are more better.*//*
>
> Yes, more common, but in Linux is already:
>
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.kerne
> l.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Ftorvalds%2Flinux.git%2Ftree
> %2Farch%2Fpowerpc%2Fboot%2Fdts%2Fkmeter1.dts%23n133&data=02%
> 7C01%7Cqiang.zhao%40nxp.com%7C783271f84fe043eaf21708d7e0f7df46%7
> C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637225227517025151
> &sdata=5VZsJPI2QwZBnS5bgSDC1cTF1lKh%2BGQXHpP%2FF4jGzCU%3D&
> amp;reserved=0
>
> or
> compati
Re: [RFC PATCH] powerpc, qe: add DTS support for parallel I/O ports
Hello Qiang Zhao,
Am 15.04.2020 um 10:10 schrieb Qiang Zhao:
On 2020/4/15 12:46 Heiko Schocher
-Original Message-
From: Heiko Schocher
Sent: 2020年4月15日 12:46
To: Qiang Zhao
Cc: U-Boot Mailing List ; Holger Brunck
; Mario Six ; Wolfgang Denk
; Holger Brunck
Subject: Re: [RFC PATCH] powerpc, qe: add DTS support for parallel I/O ports
Hello Qiang Zhao,
Am 09.04.2020 um 08:58 schrieb Qiang Zhao:
On 2020/2/18 17:05, Heiko Schocher mailto:h...@denx.de>>
wrote:
-Original Message-
From: Heiko Schocher
Sent: 2020年2月18日17:05
To: U-Boot Mailing List
Cc: Heiko Schocher ; Holger Brunck
; Mario Six ; Qiang
Zhao
; Wolfgang Denk
Subject: [RFC PATCH] powerpc, qe: add DTS support for parallel I/O
ports
add DM support for parallel I/O ports on QUICC Engine Block
Signed-off-by: Heiko Schocher mailto:h...@denx.de>>
---
arch/powerpc/cpu/mpc83xx/cpu_init.c | 8 ++
arch/powerpc/cpu/mpc83xx/qe_io.c | 193
+++-
include/fsl_qe.h | 3 +
3 files changed, 201 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/cpu/mpc83xx/cpu_init.c
b/arch/powerpc/cpu/mpc83xx/cpu_init.c
index af8facad53..cfcc16607c 100644
--- a/arch/powerpc/cpu/mpc83xx/cpu_init.c
+++ b/arch/powerpc/cpu/mpc83xx/cpu_init.c
*//*
How about mpc85xx?
Yes, this is a Todo (one reason why this patch is RFC). I currently have
reworked
this for the mpc83xx based keymile (now abb) boards (which are locally
running with complete DM/DTS support now).
You mean you have tested RFC patch on your side? That's great!
Yes, on the following boards:
"kmcoge5ne tuxx1 kmopti2 kmtegr1 tuge1 kmsupx5"
Not all in mainline (yet)
@Holger: should/could we mainline the missing ones?
This boards work with full DM/DTS support now, and have no compiletime
warnign like:
= WARNING ==
This board does not use CONFIG_DM_ETH (Driver Model
anymore...
Would you like to push the dts patch too?
Yes, but give me some time, until I can test the changed patchset again.
I have one mpx85xx based board I can try, but may others are working on this
support, so I wanted to post my patches very early, so we can work together on
it...
As my first question in patch comment is:
may we should move this part to drivers/pinctrl ?
Yes, it is more better to move to drivers/pinctrl.
Ok, I must look into it.
@@ -11,6 +11,9 @@
#ifdef CONFIG_USB_EHCI_FSL
#include
#endif
+#ifdef CONFIG_QE
+#include
+#endif
*//*
If include this headfile, the function declaration for qe_init and
qe_reset in this file should be removed as below:
extern void qe_init(uint qe_base);
extern void qe_reset(void);
Yes, of course! But this part of code I did not touch... may this needs a
cleanup
at all.
Just two lines extern declaration in this file.
I remove them in seperate patch.
#include "lblaw/lblaw.h"
#include "elbc/elbc.h"
@@ -27,6 +30,7 @@ extern void qe_config_iopin(u8 port, u8 pin, int
dir,
extern void qe_init(uint qe_base); extern void qe_reset(void);
+/**
+ * par_io_of_config_node config
+ * @dev: pointer to pinctrl device
+ * @pio: ofnode of pinconfig property
+ */
+static int par_io_of_config_node(struct udevice *dev, ofnode pio) {
+ struct qe_io_platdata *plat = dev->platdata;
+ volatile qepio83xx_t *par_io = plat->base;
+ const unsigned int *pio_map;
+ int pio_map_len;
+
+ pio_map = ofnode_get_property(pio, "pio-map", &pio_map_len);
+ if (pio_map == NULL)
+ return -ENOENT;
+
+ pio_map_len /= sizeof(unsigned int);
+ if ((pio_map_len % 6) != 0) {
+ printk(KERN_ERR "pio-map format wrong!\n");
+ return -EINVAL;
+ }
+
+ while (pio_map_len > 0) {
+ /*
+ * column pio_map[5] from linux (has_irq) not
+ * supported in u-boot yet.
+ */
*//*
remove or keep pio_map[5] in uboot dts, which is better?
I think we keep it as it is in linux dts. We simply ignore it (yet) in U-Boot.
That's OK.
+
+const struct pinctrl_ops par_io_pinctrl_ops = {
+ .set_state = par_io_pinctrl_set_state, };
+
+static const struct udevice_id par_io_pinctrl_match[] = {
+ { .compatible = "fsl,mpc8360-par_io"},
*//*
Why is*//*fsl,mpc8360-par_io, maybe fsl,qe-par-io are more better.*//*
Yes, more common, but in Linux is already:
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.kerne
l.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Ftorvalds%2Flinux.git%2Ftree
%2Farch%2Fpowerpc%2Fboot%2Fdts%2Fkmeter1.dts%23n133&data=02%
7C01%7Cqiang.zhao%40nxp.com%7C783271f84fe043eaf21708d7e0f7df46%7
C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637225227517025151
&sdata=5VZsJPI2QwZBnS5bgSDC1cTF1lKh%2BGQXHpP%2FF4jGzCU%3D&
amp;reserved=0
or
compa
RE: [RFC PATCH] net, qe: add DM support for QE UEC ethernet
Am 15.04.2020 um 06:57 schrieb Heiko Schocher: > -Original Message- > From: Heiko Schocher > Sent: 2020年4月15日 14:25 > To: Qiang Zhao > Cc: Priyanka Jain ; U-Boot Mailing List > ; Holger Brunck ; Joe > Hershberger ; Mario Six > Subject: Re: [RFC PATCH] net, qe: add DM support for QE UEC ethernet > > Hello Qiang Zhao, > > Am 15.04.2020 um 06:57 schrieb Heiko Schocher: > > Hello Qiang Zhao, > > > > Am 09.04.2020 um 10:00 schrieb Qiang Zhao: > >> On 2020/4/9 13:20, Heiko Schocher wrote: > >> > >> > >>> -Original Message- > >>> From: Heiko Schocher > >>> Sent: 2020年4月9日 13:19 > >>> To: Priyanka Jain > >>> Cc: U-Boot Mailing List ; Holger Brunck > >>> ; Joe Hershberger > >>> ; Mario Six ; Qiang Zhao > >>> > >>> Subject: Re: [RFC PATCH] net, qe: add DM support for QE UEC ethernet > >>> > >>> Hello Priyanka, > >>> > >>> Am 18.02.2020 um 10:05 schrieb Heiko Schocher: > add DM/DTS suppor for the UEC ethernet on QUICC Engine Block. > > Signed-off-by: Heiko Schocher > --- > Travis build: > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ft > rav > > >>> > is-ci.org%2Fhsdenx%2Fu-boot-test%2Fbuilds%2F651400509&data=02%7C > >>> 01 > %7Cqiang.zhao%40nxp.com%7C51477945d03e4b72383708d7dc458e7e > %7C > >>> 686ea1d3b > > >>> > c2b4c6fa92cd99c5c301635%7C0%7C0%7C637220063612830833&sdata > >>> =MALxWjN > kO0lgq1b0gmk646eEI8HWZUXRqTHt6zaOQPk%3D&reserved=0 > > - I let the old none DM based implementation in code > so boards should work with old implementation. > This Code should be removed if all boards are converted > to DM/DTS. > > - add the DM based qe uec driver under drivers/net/qe > > - Therefore copied the files uccf.c uccf.h uec.h from > drivers/qe. So there are a lot of Codingstyle problems > currently. I fix them in next version if this RFC > patch is OK or it needs some changes. > > - The dm based driver code is now under drivers/net/qe/dm_qe_uec.c > Used a lot of functions from drivers/qe/uec.c We need to make sure the old qe uec driver and new dm driver could not be enabled at the same time. > > - seperated the PHY specific code into seperate file > drivers/net/qe/dm_qe_uec_phy.c > >> > > -- > DENX Software Engineering GmbH, Managing Director: Wolfgang Denk > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany > Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: h...@denx.de Best Regards Qiang Zhao
[PATCH 0/7] ddr: altera: arria10: Convert SDRAM driver to DM
This patchset mainly to covert Arria 10 SDRAM driver to device model
and fixes few bugs in driver. It also added RAM size check function
to check valid RAM.
Ley Foon Tan (7):
ddr: altera: arria10: Fix incorrect address for mpu1
ddr: altera: arria10: Move SDRAM driver to DM
ddr: altera: arria10: Change to use reset DM function
arm: socfpga: arria10: Move sdram_arria10.h to drivers/ddr/altera
ddr: altera: arria10: Add RAM size check
ddr: altera: arria10: Change %i to %u for printf
ddr: altera: arria10: Remove call to dram_init_banksize()
arch/arm/dts/socfpga_arria10-u-boot.dtsi | 8 +
.../include/mach/reset_manager_arria10.h | 1 -
arch/arm/mach-socfpga/include/mach/sdram.h| 2 +-
arch/arm/mach-socfpga/misc_arria10.c | 2 +-
arch/arm/mach-socfpga/reset_manager_arria10.c | 7 -
arch/arm/mach-socfpga/spl_a10.c | 14 +-
drivers/ddr/altera/Kconfig| 4 +-
drivers/ddr/altera/sdram_arria10.c| 387 ++
.../ddr/altera}/sdram_arria10.h | 244 +++
9 files changed, 309 insertions(+), 360 deletions(-)
rename {arch/arm/mach-socfpga/include/mach =>
drivers/ddr/altera}/sdram_arria10.h (72%)
--
2.19.0
[PATCH 1/7] ddr: altera: arria10: Fix incorrect address for mpu1
Remove extra "SOCFPGA_SDR_FIREWALL_MPU_FPGA_ADDRESS" in mpu1 address.
Signed-off-by: Ley Foon Tan
---
drivers/ddr/altera/sdram_arria10.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/ddr/altera/sdram_arria10.c
b/drivers/ddr/altera/sdram_arria10.c
index 2fd50b7ae550..e0779b810fdc 100644
--- a/drivers/ddr/altera/sdram_arria10.c
+++ b/drivers/ddr/altera/sdram_arria10.c
@@ -470,7 +470,6 @@ const struct firewall_entry firewall_table[] = {
},
{
"mpu1",
- SOCFPGA_SDR_FIREWALL_MPU_FPGA_ADDRESS +
SOCFPGA_SDR_FIREWALL_MPU_FPGA_ADDRESS_OFFSET(mpuregion1addr),
SOCFPGA_SDR_FIREWALL_MPU_FPGA_ADDRESS_OFFSET(enable),
ALT_NOC_FW_DDR_SCR_EN_MPUREG1EN_SET_MSK
--
2.19.0
[PATCH 2/7] ddr: altera: arria10: Move SDRAM driver to DM
Convert Arria 10 SDRAM driver to device model.
SPL is changed from calling function in SDRAM driver
directly to just probing UCLASS_RAM.
Signed-off-by: Ley Foon Tan
---
arch/arm/dts/socfpga_arria10-u-boot.dtsi | 8 +
.../mach-socfpga/include/mach/sdram_arria10.h | 244 -
arch/arm/mach-socfpga/spl_a10.c | 14 +-
drivers/ddr/altera/Kconfig| 4 +-
drivers/ddr/altera/sdram_arria10.c| 334 ++
5 files changed, 270 insertions(+), 334 deletions(-)
diff --git a/arch/arm/dts/socfpga_arria10-u-boot.dtsi
b/arch/arm/dts/socfpga_arria10-u-boot.dtsi
index 6ff1ea6e5eb7..cb576f5288ea 100644
--- a/arch/arm/dts/socfpga_arria10-u-boot.dtsi
+++ b/arch/arm/dts/socfpga_arria10-u-boot.dtsi
@@ -133,6 +133,14 @@
u-boot,dm-pre-reloc;
};
+&sdr {
+ reg = <0xffcfa000 0x11C>,
+ <0xffcfb000 0x180>,
+ <0xffd12400 0x1030>;
+ resets = <&rst DDRSCH_RESET>;
+ u-boot,dm-pre-reloc;
+};
+
&sysmgr {
u-boot,dm-pre-reloc;
};
diff --git a/arch/arm/mach-socfpga/include/mach/sdram_arria10.h
b/arch/arm/mach-socfpga/include/mach/sdram_arria10.h
index 25b82fb28583..71889ecde9f7 100644
--- a/arch/arm/mach-socfpga/include/mach/sdram_arria10.h
+++ b/arch/arm/mach-socfpga/include/mach/sdram_arria10.h
@@ -6,76 +6,65 @@
#ifndef _SOCFPGA_SDRAM_ARRIA10_H_
#define _SOCFPGA_SDRAM_ARRIA10_H_
-#ifndef __ASSEMBLY__
-int ddr_calibration_sequence(void);
-
-struct socfpga_ecc_hmc {
- u32 ip_rev_id;
- u32 _pad_0x4_0x7;
- u32 ddrioctrl;
- u32 ddrcalstat;
- u32 mpr_0beat1;
- u32 mpr_1beat1;
- u32 mpr_2beat1;
- u32 mpr_3beat1;
- u32 mpr_4beat1;
- u32 mpr_5beat1;
- u32 mpr_6beat1;
- u32 mpr_7beat1;
- u32 mpr_8beat1;
- u32 mpr_0beat2;
- u32 mpr_1beat2;
- u32 mpr_2beat2;
- u32 mpr_3beat2;
- u32 mpr_4beat2;
- u32 mpr_5beat2;
- u32 mpr_6beat2;
- u32 mpr_7beat2;
- u32 mpr_8beat2;
- u32 _pad_0x58_0x5f[2];
- u32 auto_precharge;
- u32 _pad_0x64_0xff[39];
- u32 eccctrl;
- u32 eccctrl2;
- u32 _pad_0x108_0x10f[2];
- u32 errinten;
- u32 errintens;
- u32 errintenr;
- u32 intmode;
- u32 intstat;
- u32 diaginttest;
- u32 modstat;
- u32 derraddra;
- u32 serraddra;
- u32 _pad_0x134_0x137;
- u32 autowb_corraddr;
- u32 serrcntreg;
- u32 autowb_drop_cntreg;
- u32 _pad_0x144_0x147;
- u32 ecc_reg2wreccdatabus;
- u32 ecc_rdeccdata2regbus;
- u32 ecc_reg2rdeccdatabus;
- u32 _pad_0x154_0x15f[3];
- u32 ecc_diagon;
- u32 ecc_decstat;
- u32 _pad_0x168_0x16f[2];
- u32 ecc_errgenaddr_0;
- u32 ecc_errgenaddr_1;
- u32 ecc_errgenaddr_2;
- u32 ecc_errgenaddr_3;
-};
-
-struct socfpga_noc_ddr_scheduler {
- u32 ddr_t_main_scheduler_id_coreid;
- u32 ddr_t_main_scheduler_id_revisionid;
- u32 ddr_t_main_scheduler_ddrconf;
- u32 ddr_t_main_scheduler_ddrtiming;
- u32 ddr_t_main_scheduler_ddrmode;
- u32 ddr_t_main_scheduler_readlatency;
- u32 _pad_0x20_0x34[8];
- u32 ddr_t_main_scheduler_activate;
- u32 ddr_t_main_scheduler_devtodev;
-};
+/* IO48 HMC */
+#define CTRLCFG0 0x28
+#define CTRLCFG1 0x2c
+#define DRAMTIMING00x50
+#define CALTIMING0 0x7c
+#define CALTIMING1 0x80
+#define CALTIMING2 0x84
+#define CALTIMING3 0x88
+#define CALTIMING4 0x8c
+#define CALTIMING9 0xa0
+#define DRAMADDRW 0xa8
+#define DRAMSTS0xec
+#define NIOSRESERVE0 0x110
+#define NIOSRESERVE1 0x114
+#define NIOSRESERVE2 0x118
+
+/* HMC */
+#define DDRIOCTRL 0x8
+#define DDRCALSTAT 0xc
+#define ECCCTRL1 0x100
+#define ECCCTRL2 0x104
+
+/* DDR scheduler */
+#define DDRCONF0x08
+#define DDRTIMING 0x0c
+#define DDRMODE0x10
+#define DDRREADLATENCY 0x14
+#define DDRACTIVATE0x38
+#define DDRDEVTODEV0x3c
+
+/* FW DDR MPU F2S SCR */
+#define FW_DDR_MPU_F2S_SCR_EN 0x00
+#define FW_DDR_MPU_F2S_SCR_MPUR0 0x10
+#define FW_DDR_MPU_F2S_SCR_MPUR1 0x14
+#define FW_DDR_MPU_F2S_SCR_MPUR2 0x18
+#define FW_DDR_MPU_F2S_SCR_MPUR3 0x1c
+#define FW_DDR_MPU_F2S_SCR_F2S0_R0 0x20
+#define FW_DDR_MPU_F2S_SCR_F2S0_R1 0x24
+#define FW_DDR_MPU_F2S_SCR_F2S0_R2 0x28
+#define FW_DDR_MPU_F2S_SCR_F2S0_R3 0x2c
+#define FW_DDR_MPU_F2S_SCR_F2S1_R0 0x30
+#define FW_DDR_MPU_F2S_SCR_F2S1_R1 0x34
+#define FW_DDR_MPU_F2S_SCR_F2S1_R2 0x38
+#define FW_DDR_MPU_F2S_SCR_F2S1_R3 0x3c
+#define FW_DDR_MPU_F2S_SCR_F2S2_R0 0x40
+#define FW_DDR_MPU_F2S_SCR_F2S2_R1 0x44
+#define FW_DDR_MPU_F2S
[PATCH 4/7] arm: socfpga: arria10: Move sdram_arria10.h to drivers/ddr/altera
Move sdram_arria10.h to drivers/ddr/altera directory.
No functionality change.
Signed-off-by: Ley Foon Tan
---
arch/arm/mach-socfpga/include/mach/sdram.h | 2 +-
arch/arm/mach-socfpga/misc_arria10.c | 2 +-
drivers/ddr/altera/sdram_arria10.c | 3 ++-
.../include/mach => drivers/ddr/altera}/sdram_arria10.h| 0
4 files changed, 4 insertions(+), 3 deletions(-)
rename {arch/arm/mach-socfpga/include/mach =>
drivers/ddr/altera}/sdram_arria10.h (100%)
diff --git a/arch/arm/mach-socfpga/include/mach/sdram.h
b/arch/arm/mach-socfpga/include/mach/sdram.h
index 79cb9e6064a2..0a52c1078b5f 100644
--- a/arch/arm/mach-socfpga/include/mach/sdram.h
+++ b/arch/arm/mach-socfpga/include/mach/sdram.h
@@ -10,7 +10,7 @@
#if defined(CONFIG_TARGET_SOCFPGA_GEN5)
#include
#elif defined(CONFIG_TARGET_SOCFPGA_ARRIA10)
-#include
+#include "../../../../../drivers/ddr/altera/sdram_arria10.h"
#endif
#endif
diff --git a/arch/arm/mach-socfpga/misc_arria10.c
b/arch/arm/mach-socfpga/misc_arria10.c
index d56349b7f3ea..1ddffaa0ac55 100644
--- a/arch/arm/mach-socfpga/misc_arria10.c
+++ b/arch/arm/mach-socfpga/misc_arria10.c
@@ -15,7 +15,7 @@
#include
#include
#include
-#include
+#include
#include
#include
#include
diff --git a/drivers/ddr/altera/sdram_arria10.c
b/drivers/ddr/altera/sdram_arria10.c
index 794c13acfa93..6b74423ea789 100644
--- a/drivers/ddr/altera/sdram_arria10.c
+++ b/drivers/ddr/altera/sdram_arria10.c
@@ -16,10 +16,11 @@
#include
#include
#include
-#include
#include
#include
+#include "sdram_arria10.h"
+
DECLARE_GLOBAL_DATA_PTR;
struct altera_sdram_priv {
diff --git a/arch/arm/mach-socfpga/include/mach/sdram_arria10.h
b/drivers/ddr/altera/sdram_arria10.h
similarity index 100%
rename from arch/arm/mach-socfpga/include/mach/sdram_arria10.h
rename to drivers/ddr/altera/sdram_arria10.h
--
2.19.0
[PATCH 6/7] ddr: altera: arria10: Change %i to %u for printf
Tiny printf doesn't support %i, change to %u.
Signed-off-by: Ley Foon Tan
---
drivers/ddr/altera/sdram_arria10.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/ddr/altera/sdram_arria10.c
b/drivers/ddr/altera/sdram_arria10.c
index e3f11984a978..8acf324117af 100644
--- a/drivers/ddr/altera/sdram_arria10.c
+++ b/drivers/ddr/altera/sdram_arria10.c
@@ -195,7 +195,7 @@ static void sdram_init_ecc_bits(u32 size)
dcache_enable();
- printf("DDRCAL: Scrubbing ECC RAM (%i MiB).\n", size >> 20);
+ printf("DDRCAL: Scrubbing ECC RAM (%u MiB).\n", size >> 20);
memset((void *)0x8000, 0, size - 0x8000);
flush_dcache_all();
printf("DDRCAL: Scrubbing ECC RAM done.\n");
--
2.19.0
[PATCH 5/7] ddr: altera: arria10: Add RAM size check
Add call to get_ram_size() function to check memory range
for valid RAM.
Signed-off-by: Ley Foon Tan
---
drivers/ddr/altera/sdram_arria10.c | 25 -
1 file changed, 24 insertions(+), 1 deletion(-)
diff --git a/drivers/ddr/altera/sdram_arria10.c
b/drivers/ddr/altera/sdram_arria10.c
index 6b74423ea789..e3f11984a978 100644
--- a/drivers/ddr/altera/sdram_arria10.c
+++ b/drivers/ddr/altera/sdram_arria10.c
@@ -8,6 +8,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -17,7 +18,7 @@
#include
#include
#include
-#include
+#include
#include "sdram_arria10.h"
@@ -671,6 +672,27 @@ static int ddr_calibration_sequence(struct
altera_sdram_platdata *plat)
return 0;
}
+static void sdram_size_check(struct ram_info *ram)
+{
+ phys_size_t ram_check = 0;
+ phys_size_t size = ram->size;
+ phys_addr_t base = ram->base;
+
+ debug("DDR: Running SDRAM size sanity check\n");
+
+ while (ram_check < size) {
+ ram_check += get_ram_size((void *)(base + ram_check),
+(phys_size_t)SZ_1G);
+ }
+
+ if (ram_check != size) {
+ puts("DDR: SDRAM size check failed!\n");
+ hang();
+ }
+
+ debug("DDR: SDRAM size check passed!\n");
+}
+
static int altera_sdram_ofdata_to_platdata(struct udevice *dev)
{
struct altera_sdram_platdata *plat = dev->platdata;
@@ -715,6 +737,7 @@ static int altera_sdram_probe(struct udevice *dev)
priv->info.base = gd->bd->bi_dram[0].start;
priv->info.size = gd->ram_size;
+ sdram_size_check(&priv->info);
return 0;
failed:
--
2.19.0
[PATCH 3/7] ddr: altera: arria10: Change to use reset DM function
Change to use reset DM function and remove unused
socfpga_reset_deassert_noc_ddr_scheduler().
Signed-off-by: Ley Foon Tan
---
.../include/mach/reset_manager_arria10.h | 1 -
arch/arm/mach-socfpga/reset_manager_arria10.c | 7 --
drivers/ddr/altera/sdram_arria10.c| 25 ++-
3 files changed, 13 insertions(+), 20 deletions(-)
diff --git a/arch/arm/mach-socfpga/include/mach/reset_manager_arria10.h
b/arch/arm/mach-socfpga/include/mach/reset_manager_arria10.h
index 22e4eb33de88..a0fad7c1e2fc 100644
--- a/arch/arm/mach-socfpga/include/mach/reset_manager_arria10.h
+++ b/arch/arm/mach-socfpga/include/mach/reset_manager_arria10.h
@@ -9,7 +9,6 @@
#include
void socfpga_watchdog_disable(void);
-void socfpga_reset_deassert_noc_ddr_scheduler(void);
int socfpga_reset_deassert_bridges_handoff(void);
void socfpga_reset_deassert_osc1wd0(void);
int socfpga_bridges_reset(void);
diff --git a/arch/arm/mach-socfpga/reset_manager_arria10.c
b/arch/arm/mach-socfpga/reset_manager_arria10.c
index aa5299415a74..edfe250ec0bc 100644
--- a/arch/arm/mach-socfpga/reset_manager_arria10.c
+++ b/arch/arm/mach-socfpga/reset_manager_arria10.c
@@ -62,13 +62,6 @@ void socfpga_watchdog_disable(void)
ALT_RSTMGR_PER1MODRST_WD0_SET_MSK);
}
-/* Release NOC ddr scheduler from reset */
-void socfpga_reset_deassert_noc_ddr_scheduler(void)
-{
- clrbits_le32(socfpga_get_rstmgr_addr() + RSTMGR_A10_BRGMODRST,
-ALT_RSTMGR_BRGMODRST_DDRSCH_SET_MSK);
-}
-
static int get_bridge_init_val(const void *blob, int compat_id)
{
int node;
diff --git a/drivers/ddr/altera/sdram_arria10.c
b/drivers/ddr/altera/sdram_arria10.c
index a31d45a5bb8e..794c13acfa93 100644
--- a/drivers/ddr/altera/sdram_arria10.c
+++ b/drivers/ddr/altera/sdram_arria10.c
@@ -10,19 +10,21 @@
#include
#include
#include
+#include
#include
#include
#include
#include
#include
-#include
#include
+#include
#include
DECLARE_GLOBAL_DATA_PTR;
struct altera_sdram_priv {
struct ram_info info;
+ struct reset_ctl_bulk resets;
};
struct altera_sdram_platdata {
@@ -152,7 +154,7 @@ static int emif_reset(struct altera_sdram_platdata *plat)
return 0;
}
-static int ddr_setup(struct altera_sdram_platdata *plat)
+static int sdram_startup(struct altera_sdram_platdata *plat)
{
int i, ret;
@@ -198,16 +200,6 @@ static void sdram_init_ecc_bits(u32 size)
dcache_disable();
}
-/* Function to startup the SDRAM*/
-static int sdram_startup(struct altera_sdram_platdata *plat)
-{
- /* Release NOC ddr scheduler from reset */
- socfpga_reset_deassert_noc_ddr_scheduler();
-
- /* Bringup the DDR (calibration and configuration) */
- return ddr_setup(plat);
-}
-
static u64 sdram_size_calc(struct altera_sdram_platdata *plat)
{
u32 dramaddrw = readl(plat->iohmc + DRAMADDRW);
@@ -703,8 +695,17 @@ static int altera_sdram_ofdata_to_platdata(struct udevice
*dev)
static int altera_sdram_probe(struct udevice *dev)
{
+ int ret;
struct altera_sdram_priv *priv = dev_get_priv(dev);
+ ret = reset_get_bulk(dev, &priv->resets);
+ if (ret) {
+ dev_err(dev, "Can't get reset: %d\n", ret);
+ return -ENODEV;
+ }
+
+ reset_deassert_bulk(&priv->resets);
+
if (ddr_calibration_sequence(dev->platdata) != 0) {
puts("SDRAM init failed.\n");
goto failed;
--
2.19.0
[PATCH 7/7] ddr: altera: arria10: Remove call to dram_init_banksize()
dram_init_banksize() is called in board_init_f() boot sequences
in Uboot, remove it from SDRAM driver.
Signed-off-by: Ley Foon Tan
---
drivers/ddr/altera/sdram_arria10.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/ddr/altera/sdram_arria10.c
b/drivers/ddr/altera/sdram_arria10.c
index 8acf324117af..a7d0eefe9195 100644
--- a/drivers/ddr/altera/sdram_arria10.c
+++ b/drivers/ddr/altera/sdram_arria10.c
@@ -660,9 +660,6 @@ static int ddr_calibration_sequence(struct
altera_sdram_platdata *plat)
else
gd->ram_size = (u32)size;
- /* setup the dram info within bd */
- dram_init_banksize();
-
if (of_sdram_firewall_setup(gd->fdt_blob))
puts("FW: Error Configuring Firewall\n");
--
2.19.0
[PULL] Pull request: u-boot-stm/next =u-boot-stm32-20200415
Hi Tom Please pull the u-boot-stm next branch. CI status: https://gitlab.denx.de/u-boot/custodians/u-boot-stm/pipelines/2759 Thanks Patrice The following changes since commit 142a07f2a44262d76fec609e1fcde51794a456eb: Merge branch 'master' of git://git.denx.de/u-boot-marvell (2020-04-14 08:47:07 -0400) are available in the Git repository at: https://gitlab.denx.de/u-boot/custodians/u-boot-stm tags/u-boot-stm32-20200415 for you to fetch changes up to 71ba2cb0d678d2c29dadd5fcca61ce3942876ee6: board: stm32mp1: correct CONFIG_IS_ENABLED usage for LED (2020-04-15 09:10:12 +0200) - Replace STM32MP1_TRUSTED by TFABOOT flag - Enable bootd, iminfo, imxtract on ST defconfig - Rename LEDs to match silkscreen on AV96 - Add KS8851-16MLL ethernet on FMC2 - Define FMC2 base address - net: dwc_eth_qos: implement reset-gpios for stm32 - net: dwc_eth_qos: implement phy reg and max-speed for stm32 Christophe Roullier (1): net: dwc_eth_qos: implement reset-gpios for stm32 Marek Vasut (3): ARM: dts: stm32: Define FMC2 base address ARM: dts: stm32: Add KS8851-16MLL ethernet on FMC2 ARM: dts: stm32: Rename LEDs to match silkscreen on AV96 Patrick Delaunay (4): net: dwc_eth_qos: implement phy reg and max-speed for stm32 configs: stm32mp1: replace STM32MP1_TRUSTED by TFABOOT ARM: stm32: Enable bootd, iminfo, imxtract on ST defconfig board: stm32mp1: correct CONFIG_IS_ENABLED usage for LED arch/arm/Kconfig | 1 + arch/arm/dts/stm32mp157a-avenger96.dts | 6 +-- arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi | 68 arch/arm/mach-stm32mp/Kconfig | 21 +++-- arch/arm/mach-stm32mp/bsec.c | 18 arch/arm/mach-stm32mp/cpu.c | 10 ++--- arch/arm/mach-stm32mp/include/mach/stm32.h | 1 + board/dhelectronics/dh_stm32mp1/board.c | 58 ++-- board/st/stm32mp1/stm32mp1.c | 6 +-- configs/stm32mp15_basic_defconfig | 3 -- configs/stm32mp15_dhcom_basic_defconfig | 1 + configs/stm32mp15_optee_defconfig | 1 + configs/stm32mp15_trusted_defconfig | 4 +- drivers/clk/clk_stm32mp1.c | 2 +- drivers/net/dwc_eth_qos.c | 72 +- drivers/ram/stm32mp1/stm32mp1_ram.c | 2 +- include/configs/stm32mp1.h | 2 +- 17 files changed, 228 insertions(+), 48 deletions(-)
[PATCH] board: fsl: lx2160a: define gic_lpi_base with CONFIG_GIC_V3_ITS support
define gic_lpi_base variable when CONFIG_GIC_V3_ITS support is enable. This avoids compilation warnings when CONFIG_GIC_V3_ITS is not enabled. Signed-off-by: Wasim Khan --- board/freescale/lx2160a/lx2160a.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/board/freescale/lx2160a/lx2160a.c b/board/freescale/lx2160a/lx2160a.c index 4b20bb4..a8c45b9 100644 --- a/board/freescale/lx2160a/lx2160a.c +++ b/board/freescale/lx2160a/lx2160a.c @@ -670,7 +670,9 @@ int ft_board_setup(void *blob, bd_t *bd) u64 mc_memory_base = 0; u64 mc_memory_size = 0; u16 total_memory_banks; +#ifdef CONFIG_GIC_V3_ITS u64 gic_lpi_base; +#endif ft_cpu_setup(blob, bd); -- 2.7.4
[PATCH 1/2] spl: mmc: Rename spl_boot_mode() to spl_mmc_boot_mode()
The function's name is misleading as one might think it is used
generally to select the boot-mode when in reality it is only used by the
MMC driver to find out in what way it should try reading U-Boot Proper
from a device (either using a filesystem, a raw sector/partition, or an
eMMC boot partition).
Rename it to spl_mmc_boot_mode() to make it more obvious what this
function is about.
Link: https://lists.denx.de/pipermail/u-boot/2020-April/405979.html
Signed-off-by: Harald Seiler
---
include/spl.h | 18 +-
common/spl/spl_mmc.c | 4 ++--
arch/arm/mach-imx/spl.c| 2 +-
arch/arm/mach-k3/am6_init.c| 2 +-
arch/arm/mach-k3/j721e_init.c | 2 +-
arch/arm/mach-omap2/boot-common.c | 2 +-
arch/arm/mach-rockchip/spl.c | 2 +-
arch/arm/mach-socfpga/spl_a10.c| 2 +-
arch/arm/mach-socfpga/spl_agilex.c | 2 +-
arch/arm/mach-socfpga/spl_gen5.c | 2 +-
arch/arm/mach-socfpga/spl_s10.c| 2 +-
arch/arm/mach-stm32mp/spl.c| 2 +-
arch/arm/mach-uniphier/mmc-boot-mode.c | 2 +-
13 files changed, 30 insertions(+), 14 deletions(-)
diff --git a/include/spl.h b/include/spl.h
index 5d8d14dbf5cd..fffcc610bb2b 100644
--- a/include/spl.h
+++ b/include/spl.h
@@ -238,7 +238,23 @@ int spl_load_imx_container(struct spl_image_info
*spl_image,
/* SPL common functions */
void preloader_console_init(void);
u32 spl_boot_device(void);
-u32 spl_boot_mode(const u32 boot_device);
+
+/**
+ * spl_mmc_boot_mode() - Lookup function for the mode of an MMC boot source.
+ * @boot_device: ID of the device which the MMC driver wants to read
+ * from. Common values are e.g. BOOT_DEVICE_MMC1,
+ * BOOT_DEVICE_MMC2, BOOT_DEVICE_MMC2_2.
+ *
+ * This function should return one of MMCSD_MODE_FS, MMCSD_MODE_EMMCBOOT, or
+ * MMCSD_MODE_RAW for each MMC boot source which is defined for the target.
The
+ * boot_device parameter tells which device the MMC driver is interested in.
+ *
+ * If not overridden, it is weakly defined in common/spl/spl_mmc.c.
+ *
+ * Note: It is important to use the boot_device parameter instead of e.g.
+ * spl_boot_device() as U-Boot is not always loaded from the same device as
SPL.
+ */
+u32 spl_mmc_boot_mode(const u32 boot_device);
int spl_boot_partition(const u32 boot_device);
void spl_set_bd(void);
diff --git a/common/spl/spl_mmc.c b/common/spl/spl_mmc.c
index a2ea363e96a9..fb8ad5d54006 100644
--- a/common/spl/spl_mmc.c
+++ b/common/spl/spl_mmc.c
@@ -298,7 +298,7 @@ static int spl_mmc_do_fs_boot(struct spl_image_info
*spl_image, struct mmc *mmc,
}
#endif
-u32 __weak spl_boot_mode(const u32 boot_device)
+u32 __weak spl_mmc_boot_mode(const u32 boot_device)
{
#if defined(CONFIG_SPL_FS_FAT) || defined(CONFIG_SPL_FS_EXT4)
return MMCSD_MODE_FS;
@@ -350,7 +350,7 @@ int spl_mmc_load(struct spl_image_info *spl_image,
}
}
- boot_mode = spl_boot_mode(bootdev->boot_device);
+ boot_mode = spl_mmc_boot_mode(bootdev->boot_device);
err = -EINVAL;
switch (boot_mode) {
case MMCSD_MODE_EMMCBOOT:
diff --git a/arch/arm/mach-imx/spl.c b/arch/arm/mach-imx/spl.c
index 87dbdf3011ee..49bb3b928da1 100644
--- a/arch/arm/mach-imx/spl.c
+++ b/arch/arm/mach-imx/spl.c
@@ -189,7 +189,7 @@ int g_dnl_bind_fixup(struct usb_device_descriptor *dev,
const char *name)
#if defined(CONFIG_SPL_MMC_SUPPORT)
/* called from spl_mmc to see type of boot mode for storage (RAW or FAT) */
-u32 spl_boot_mode(const u32 boot_device)
+u32 spl_mmc_boot_mode(const u32 boot_device)
{
#if defined(CONFIG_MX7) || defined(CONFIG_IMX8M) || defined(CONFIG_IMX8)
switch (get_boot_device()) {
diff --git a/arch/arm/mach-k3/am6_init.c b/arch/arm/mach-k3/am6_init.c
index 3768bccafa63..b692806352c8 100644
--- a/arch/arm/mach-k3/am6_init.c
+++ b/arch/arm/mach-k3/am6_init.c
@@ -199,7 +199,7 @@ void board_init_f(ulong dummy)
#endif
}
-u32 spl_boot_mode(const u32 boot_device)
+u32 spl_mmc_boot_mode(const u32 boot_device)
{
#if defined(CONFIG_SUPPORT_EMMC_BOOT)
u32 devstat = readl(CTRLMMR_MAIN_DEVSTAT);
diff --git a/arch/arm/mach-k3/j721e_init.c b/arch/arm/mach-k3/j721e_init.c
index f34090f9cc99..71fc20c30bfc 100644
--- a/arch/arm/mach-k3/j721e_init.c
+++ b/arch/arm/mach-k3/j721e_init.c
@@ -223,7 +223,7 @@ void board_init_f(ulong dummy)
#endif
}
-u32 spl_boot_mode(const u32 boot_device)
+u32 spl_mmc_boot_mode(const u32 boot_device)
{
switch (boot_device) {
case BOOT_DEVICE_MMC1:
diff --git a/arch/arm/mach-omap2/boot-common.c
b/arch/arm/mach-omap2/boot-common.c
index 734fa9d9e6f7..753852372431 100644
--- a/arch/arm/mach-omap2/boot-common.c
+++ b/arch/arm/mach-omap2/boot-common.c
@@ -187,7 +187,7 @@ u32 spl_boot_device(void)
return gd->arch.omap_boot_device;
}
-u32 spl_boot_mode(const u32 boot_device)
+u32 spl_mmc_boot_mode(const u32 boot_device)
{
r
[PATCH 2/2] spl: mmc: Rename spl_boot_partition() to spl_mmc_boot_partition()
This function is only relevant to the MMC driver so calling it
spl_boot_partition() might be confusing. Rename it to
spl_mmc_boot_partition() to make its purpose more clear (and bring
it in line with spl_mmc_boot_mode()).
Signed-off-by: Harald Seiler
---
include/spl.h | 14 +-
common/spl/spl_mmc.c| 5 ++---
arch/arm/mach-stm32mp/spl.c | 2 +-
3 files changed, 16 insertions(+), 5 deletions(-)
diff --git a/include/spl.h b/include/spl.h
index fffcc610bb2b..8b15cd4914ce 100644
--- a/include/spl.h
+++ b/include/spl.h
@@ -255,7 +255,19 @@ u32 spl_boot_device(void);
* spl_boot_device() as U-Boot is not always loaded from the same device as
SPL.
*/
u32 spl_mmc_boot_mode(const u32 boot_device);
-int spl_boot_partition(const u32 boot_device);
+
+/**
+ * spl_mmc_boot_partition() - MMC partition to load U-Boot from.
+ * @boot_device: ID of the device which the MMC driver wants to load
+ * U-Boot from.
+ *
+ * This function should return the partition number which the SPL
+ * should load U-Boot from (on the given boot_device) when
+ * CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION is set.
+ *
+ * If not overridden, it is weakly defined in common/spl/spl_mmc.c.
+ */
+int spl_mmc_boot_partition(const u32 boot_device);
void spl_set_bd(void);
/**
diff --git a/common/spl/spl_mmc.c b/common/spl/spl_mmc.c
index fb8ad5d54006..a68cdec8dc8f 100644
--- a/common/spl/spl_mmc.c
+++ b/common/spl/spl_mmc.c
@@ -310,8 +310,7 @@ u32 __weak spl_mmc_boot_mode(const u32 boot_device)
}
#ifdef CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION
-__weak
-int spl_boot_partition(const u32 boot_device)
+int __weak spl_mmc_boot_partition(const u32 boot_device)
{
return CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION;
}
@@ -431,7 +430,7 @@ int spl_mmc_load_image(struct spl_image_info *spl_image,
NULL,
#endif
#ifdef CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION
- spl_boot_partition(bootdev->boot_device),
+ spl_mmc_boot_partition(bootdev->boot_device),
#else
0,
#endif
diff --git a/arch/arm/mach-stm32mp/spl.c b/arch/arm/mach-stm32mp/spl.c
index 55ff97de2794..f85391c6af2f 100644
--- a/arch/arm/mach-stm32mp/spl.c
+++ b/arch/arm/mach-stm32mp/spl.c
@@ -49,7 +49,7 @@ u32 spl_mmc_boot_mode(const u32 boot_device)
return MMCSD_MODE_RAW;
}
-int spl_boot_partition(const u32 boot_device)
+int spl_mmc_boot_partition(const u32 boot_device)
{
switch (boot_device) {
case BOOT_DEVICE_MMC1:
--
2.26.0
[PATCH 0/2] Rename spl_boot_mode() and spl_boot_partition()
TL;DR: The two functions are only used in the SPL MMC driver so I think
their names should reflect that.
spl_boot_mode() has caused a bit of trouble to me and others because
some of its implementations miss what it is meant to do in its current
form. This is in part due to history and I suspect in part due to its
name being a bit misleading.
As a quick summary: spl_boot_mode() is solely used by the SPL MMC driver
to check how it should load U-Boot from the currently attempted
boot-source. There are three possibilities:
1. MMCSD_MODE_FS: The MMC device contains a filesystem (FAT or EXT4).
2. MMCSD_MODE_EMMCBOOT: U-Boot should be loaded from an eMMC
boot-partition.
3. MMCSD_MODE_RAW: U-Boot should be loaded from a raw offset or
a partition on the MMC device.
spl_boot_mode() should, for each MMC boot device, return one of those
3 modes. The boot_device parameter tells which device is queried.
Historically, the boot_device parameter did not exist. Because of this,
a lot of implementations relied on checking where SPL was loaded from
(spl_boot_device()) as it is common to load U-Boot from the same device.
However, nowadays it is possible to attempt loading U-Boot from multiple
MMC devices (as a fallback), for example using board_boot_order().
This means, spl_boot_mode() needs to properly tell the MMC driver the
mode of each device. This was the reason for introducing the
boot_device parameter in commit 2b1cdafa9fdd ("common: Pass the boot
device into spl_boot_mode()")).
I am bringing all this up because some existing implementations don't
handle this properly and new code has been merged which also doesn't.
To make it more clear what the function and its cousin,
spl_boot_partition(), are supposed to do, I suggest renaming them to
spl_mmc_boot_mode() and spl_mmc_boot_partition() respectively.
I will also send a second series to fix the implementation which is
affecting me (arch/arm/mach-imx/spl.c).
Harald Seiler (2):
spl: mmc: Rename spl_boot_mode() to spl_mmc_boot_mode()
spl: mmc: Rename spl_boot_partition() to spl_mmc_boot_partition()
include/spl.h | 32 --
common/spl/spl_mmc.c | 9
arch/arm/mach-imx/spl.c| 2 +-
arch/arm/mach-k3/am6_init.c| 2 +-
arch/arm/mach-k3/j721e_init.c | 2 +-
arch/arm/mach-omap2/boot-common.c | 2 +-
arch/arm/mach-rockchip/spl.c | 2 +-
arch/arm/mach-socfpga/spl_a10.c| 2 +-
arch/arm/mach-socfpga/spl_agilex.c | 2 +-
arch/arm/mach-socfpga/spl_gen5.c | 2 +-
arch/arm/mach-socfpga/spl_s10.c| 2 +-
arch/arm/mach-stm32mp/spl.c| 4 ++--
arch/arm/mach-uniphier/mmc-boot-mode.c | 2 +-
13 files changed, 46 insertions(+), 19 deletions(-)
--
2.26.0
Re: [PATCH 0/3] watchdog: honour hw_margin_ms property
On 13.03.20 17:04, Rasmus Villemoes wrote: Some watchdogs must be reset more often than the once-per-second ratelimit used by the generic watchdog_reset function in wdt-uclass.c. There's precedent (from the gpio-wdt driver in linux) for using a property called hw_margin_ms to let the device tree tell the driver how often the device needs resetting. So use that generically. No change in default behaviour. On top of https://patchwork.ozlabs.org/patch/1242772/ . Stefan, something like this? That at least solves half my problems and might be useful to others as well. Then I'll have to figure out the time-stands-still problem in some other way. Rasmus Villemoes (3): watchdog: remove stale ifndef CONFIG_WATCHDOG_TIMEOUT_MSECS from wdt.h watchdog: move initr_watchdog() to wdt-uclass.c watchdog: honour hw_margin_ms DT property drivers/watchdog/wdt-uclass.c | 43 ++- include/wdt.h | 38 +-- 2 files changed, 43 insertions(+), 38 deletions(-) Series applied to u-boot-marvell/master Thanks, Stefan
Re: [PATCH v4 1/1] driver: watchdog: get platform clock from dt file
On 06.04.20 09:59, Rayagonda Kokatanur wrote:
Get the watchdog platform clock from the DTS file
using clk subsystem and use the same for calculating
ticks in msec.
Signed-off-by: Rayagonda Kokatanur
Signed-off-by: Bharat Kumar Reddy Gooty
Applied to u-boot-marvell/master
Thanks,
Stefan
---
Changes from v3:
-Address review comments from Stefan Roese,
Don't return error if clk_get_by_index() fails
becasue all platform may not have clock support.
Changes from v2:
-Address review comments from Stefan Roese,
Use clk subsystem to get the base frequency of device instead
of dt parameter "clk_mhz".
Changes from v1:
-Address review comments from Stefan Roese,
Remove default timeout reading in probe() as it is read in include/wdt.h.
Add paranthesis on multi-line statements.
drivers/watchdog/sp805_wdt.c | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/watchdog/sp805_wdt.c b/drivers/watchdog/sp805_wdt.c
index ca3ccbe76c..65fd2384f1 100644
--- a/drivers/watchdog/sp805_wdt.c
+++ b/drivers/watchdog/sp805_wdt.c
@@ -7,6 +7,7 @@
#include
#include
+#include
#include
#include
#include
@@ -34,6 +35,7 @@ DECLARE_GLOBAL_DATA_PTR;
struct sp805_wdt_priv {
void __iomem *reg;
+ unsigned long clk_rate;
};
static int sp805_wdt_reset(struct udevice *dev)
@@ -63,8 +65,13 @@ static int sp805_wdt_start(struct udevice *dev, u64 timeout,
ulong flags)
* set 120s, the gd->bus_clk is less than 1145MHz, the load_value will
* not overflow.
*/
- load_value = (gd->bus_clk) /
- (2 * 1000 * SYS_FSL_WDT_CLK_DIV) * load_time;
+ if (gd->bus_clk) {
+ load_value = (gd->bus_clk) /
+ (2 * 1000 * SYS_FSL_WDT_CLK_DIV) * load_time;
+ } else {
+ /* platform provide clk */
+ load_value = (timeout / 2) * (priv->clk_rate / 1000);
+ }
writel(UNLOCK, priv->reg + WDTLOCK);
writel(load_value, priv->reg + WDTLOAD);
@@ -105,11 +112,15 @@ static int sp805_wdt_probe(struct udevice *dev)
static int sp805_wdt_ofdata_to_platdata(struct udevice *dev)
{
struct sp805_wdt_priv *priv = dev_get_priv(dev);
+ struct clk clk;
priv->reg = (void __iomem *)dev_read_addr(dev);
if (IS_ERR(priv->reg))
return PTR_ERR(priv->reg);
+ if (!clk_get_by_index(dev, 0, &clk))
+ priv->clk_rate = clk_get_rate(&clk);
+
return 0;
}
Viele Grüße,
Stefan
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
Please pull u-boot-marvell/master (watchdog related)
Hi Tom, please pull the following watchdog related patches: - Common: honour hw_margin_ms property (Rasmus) - sp805_wdt: get platform clock from dt (Rayagonda) Here the Azure build, without any issues: https://dev.azure.com/sr0718/u-boot/_build/results?buildId=4&view=results Thanks, Stefan The following changes since commit 142a07f2a44262d76fec609e1fcde51794a456eb: Merge branch 'master' of git://git.denx.de/u-boot-marvell (2020-04-14 08:47:07 -0400) are available in the Git repository at: g...@gitlab.denx.de:u-boot/custodians/u-boot-marvell.git for you to fetch changes up to 19a159f94ac1532ec12cf14a96c9daf172ade988: watchdog: sp805_wdt: get platform clock from dt file (2020-04-15 08:54:07 +0200) Rasmus Villemoes (3): watchdog: remove stale ifndef CONFIG_WATCHDOG_TIMEOUT_MSECS from wdt.h watchdog: move initr_watchdog() to wdt-uclass.c watchdog: honour hw_margin_ms DT property Rayagonda Kokatanur (1): watchdog: sp805_wdt: get platform clock from dt file drivers/watchdog/sp805_wdt.c | 15 +-- drivers/watchdog/wdt-uclass.c | 44 ++- include/wdt.h | 37 +--- 3 files changed, 57 insertions(+), 39 deletions(-)
Re: [PATCH 0/4] Updates for ClearFog EEPROM
Hi Joel, On 19.01.20 08:10, Joel Johnson wrote: This set of patches applies on top of https://patchwork.ozlabs.org/cover/1200324/, based on testing using the static configuration fallback updates in a related patch series. Joel Johnson (4): cmd: sys_eeprom: add missing implicit header cmd: sys_eeprom reflect I2C dependency in Kconfig arm: mvebu: clearfog: don't set SPL misc arm: mvebu: clearfog: fix compile w/o EEPROM board/solidrun/clearfog/clearfog.c | 26 +++--- cmd/Kconfig| 1 + cmd/sys_eeprom.c | 1 + configs/clearfog_defconfig | 1 - 4 files changed, 17 insertions(+), 12 deletions(-) Is it correct to assume, that this patchset is superseded by the Baruch's work? Can it be dropped? Thanks, Stefan
RE: [PATCH v2] lx2160a : Update eMMC boot environment variables
>-Original Message- >From: U-Boot On Behalf Of Meenakshi >Aggarwal >Sent: Thursday, April 9, 2020 6:58 PM >To: u-boot@lists.denx.de; Priyanka Jain >Cc: Meenakshi Aggarwal >Subject: [PATCH v2] lx2160a : Update eMMC boot environment variables > Please provide the description of what env variables you are updating in this patch Thanks Priyanka >Signed-off-by: Meenakshi Aggarwal > >--- >Changes in V2: > - Reword commit message. >--- > include/configs/lx2160a_common.h | 16 +--- > 1 file changed, 13 insertions(+), 3 deletions(-) > >diff --git a/include/configs/lx2160a_common.h >b/include/configs/lx2160a_common.h >index 1907f93..6c3e647 100644 >--- a/include/configs/lx2160a_common.h >+++ b/include/configs/lx2160a_common.h >@@ -225,6 +225,16 @@ int select_i2c_ch_pca9547_sec(unsigned char ch); > "esbc_validate 0x8068 ;"\ > "fsl_mc start mc 0x80a0 0x80e0\0" > >+#define SD2_MC_INIT_CMD \ >+ "mmc read 0x80a0 0x5000 0x1200;"\ >+ "mmc read 0x80e0 0x7000 0x800;" \ >+ "env exists secureboot && " \ >+ "mmc read 0x8064 0x3200 0x20 && " \ >+ "mmc read 0x8068 0x3400 0x20 && " \ >+ "esbc_validate 0x8064 && " \ >+ "esbc_validate 0x8068 ;"\ >+ "fsl_mc start mc 0x80a0 0x80e0\0" >+ > #define EXTRA_ENV_SETTINGS\ > "hwconfig=fsl_ddr:bank_intlv=auto\0"\ > "ramdisk_addr=0x80\0" \ >@@ -292,11 +302,11 @@ int select_i2c_ch_pca9547_sec(unsigned char ch); > "env exists secureboot && esbc_halt;" > > #define SD2_BOOTCOMMAND \ >- "env exists mcinitcmd && mmcinfo; " \ >+ "mmc dev 1; env exists mcinitcmd && mmcinfo; " \ > "mmc read 0x80d0 0x6800 0x800; "\ > "env exists mcinitcmd && env exists secureboot "\ >- " && mmc read 0x8078 0x3C00 0x20 " \ >- "&& esbc_validate 0x8078;env exists mcinitcmd " \ >+ " && mmc read 0x806C 0x3600 0x20 " \ >+ "&& esbc_validate 0x806C;env exists mcinitcmd " \ > "&& fsl_mc lazyapply dpl 0x80d0;" \ > "run distro_bootcmd;run emmc_bootcmd;" \ > "env exists secureboot && esbc_halt;" >-- >1.9.1
RE: [PATCH] armv8: ls1046ardb: add new 16GB udimm memory support
>-Original Message-
>From: U-Boot On Behalf Of
>andy.t...@nxp.com
>Sent: Friday, April 3, 2020 12:30 PM
>To: Priyanka Jain
>Cc: Mingkai Hu ; Rajesh Bhagat
>; u-boot@lists.denx.de; Andy Tang
>
>Subject: [PATCH] armv8: ls1046ardb: add new 16GB udimm memory support
>
>From: Yuantian Tang
>
>Add this udimm memory support on ls1046ardb board.
What is this?
I see in code, you are adding DIMM specific parameter to support new frequency.
Is this code changes because you are adding a different DIMM or adding support
for new frequency?
If new DIMM, What if someone tried to use the frequency "2133" with the
original dim on board.
Please provide more details in description.
Thanks
Priyanka
>
>Signed-off-by: Yuantian Tang
>---
> board/freescale/ls1046ardb/ddr.h | 1 +
> 1 file changed, 1 insertion(+)
>
>diff --git a/board/freescale/ls1046ardb/ddr.h
>b/board/freescale/ls1046ardb/ddr.h
>index 3b4d44d465..d401daa776 100644
>--- a/board/freescale/ls1046ardb/ddr.h
>+++ b/board/freescale/ls1046ardb/ddr.h
>@@ -32,6 +32,7 @@ static const struct board_specific_parameters udimm0[]
>= {
> {2, 1350, 0, 8, 6, 0x0708090B, 0x0C0D0E09,},
> {2, 1666, 0, 8, 7, 0x08090A0C, 0x0D0F100B,},
> {2, 1900, 0, 8, 7, 0x09090B0D, 0x0E10120B,},
>+ {2, 2133, 0, 4, 7, 0x08090A0E, 0x1011120C,},
> {2, 2300, 0, 8, 9, 0x0A0B0C10, 0x1213140E,},
> {}
> };
>--
>2.17.1
RE: [PATCH] configs: ls1012afrwy: drop env qspi_bootcmd
>-Original Message-
>From: U-Boot On Behalf Of Biwen Li
>Sent: Tuesday, March 31, 2020 1:54 PM
>To: Jagdish Gediya ; Priyanka Jain
>; Pramod Kumar ;
>Shengzhou Liu
>Cc: Alison Wang ; u-boot@lists.denx.de; Jiafei Pan
>; Biwen Li
>Subject: [PATCH] configs: ls1012afrwy: drop env qspi_bootcmd
>
>From: Biwen Li
>
>Drop useless environment variable installer and qspi_bootcmd for
>ls1012afrwy
>
Please explain why these variables are useless
Thanks
Priyanka
>Signed-off-by: Biwen Li
>---
> include/configs/ls1012afrwy.h | 9 -
> 1 file changed, 9 deletions(-)
>
>diff --git a/include/configs/ls1012afrwy.h b/include/configs/ls1012afrwy.h
>index 9007249804..ec071d0606 100644
>--- a/include/configs/ls1012afrwy.h
>+++ b/include/configs/ls1012afrwy.h
>@@ -107,15 +107,6 @@
> "env exists secureboot "\
> "&& esbc_validate ${scripthdraddr};"\
> "source ${scriptaddr}\0" \
>- "installer=load mmc 0:2 $load_addr "\
>- "/flex_installer_arm64.itb; "\
>- "bootm $load_addr#$board\0" \
>- "qspi_bootcmd=pfe stop; echo Trying load from qspi..;" \
>- "sf probe && sf read $load_addr " \
>- "$kernel_addr $kernel_size; env exists secureboot " \
>- "&& sf read $kernelheader_addr_r $kernelheader_addr "
> \
>- "$kernelheader_size && esbc_validate
>${kernelheader_addr_r}; " \
>- "bootm $load_addr#$board\0" \
> "sd_bootcmd=pfe stop; echo Trying load from sd card..;"
> \
> "mmcinfo; mmc read $load_addr " \
> "$kernel_addr_sd $kernel_size_sd ;" \
>--
>2.17.1
RE: [PATCH v2] configs: ls1021a: Append othbootargs to bootargs
>-Original Message- >From: U-Boot On Behalf Of Alison Wang >Sent: Wednesday, March 25, 2020 10:04 AM >To: u-boot@lists.denx.de; Priyanka Jain ; Jagdish >Gediya >Cc: Alison Wang ; Shengzhou Liu > >Subject: [PATCH v2] configs: ls1021a: Append othbootargs to bootargs > >This patch appends CMA configuration to bootargs for LS1021ATWR board. > >Signed-off-by: Shengzhou Liu >Signed-off-by: Alison Wang >--- >Changes for v2: > - Append CMA configuration to bootargs directly > > include/configs/ls1021atwr.h | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) > >diff --git a/include/configs/ls1021atwr.h b/include/configs/ls1021atwr.h index >8e2784b..5f73821 100644 >--- a/include/configs/ls1021atwr.h >+++ b/include/configs/ls1021atwr.h >@@ -297,7 +297,8 @@ > > #ifdef CONFIG_LPUART > #define CONFIG_EXTRA_ENV_SETTINGS \ >- "bootargs=root=/dev/ram0 rw console=ttyLP0,115200\0" \ >+ "bootargs=root=/dev/ram0 rw console=ttyLP0,115200 " \ >+ "cma=64M@0x0-0xb000\0" \ > "initrd_high=0x\0" \ > "fdt_high=0x\0" \ > "fdt_addr=0x64f0\0" \ >@@ -313,7 +314,6 @@ > "kernel_size=0x280\0" \ > "kernel_addr_sd=0x8000\0" \ > "kernel_size_sd=0x14000\0" \ >- "$othbootargs\0"\ > "othbootargs=cma=64M@0x0-0xb000\0" \ > BOOTENV \ > "boot_scripts=ls1021atwr_boot.scr\0"\ >@@ -355,7 +355,8 @@ > "$kernel_size && bootm $load_addr#$board\0" > #else > #define CONFIG_EXTRA_ENV_SETTINGS \ >- "bootargs=root=/dev/ram0 rw console=ttyS0,115200\0" \ >+ "bootargs=root=/dev/ram0 rw console=ttyS0,115200 " \ >+ "cma=64M@0x0-0xb000\0" \ > "initrd_high=0x\0" \ > "fdt_high=0x\0" \ > "fdt_addr=0x64f0\0" \ >@@ -375,7 +376,6 @@ > "kernel_size_sd=0x14000\0" \ > "kernelhdr_addr_sd=0x4000\0"\ > "kernelhdr_size_sd=0x10\0" \ >- "$othbootargs\0"\ > "othbootargs=cma=64M@0x0-0xb000\0" \ > BOOTENV \ > "boot_scripts=ls1021atwr_boot.scr\0"\ >-- >2.9.5 First version was already applied. Please rebase on top and resubmit the delta if significant now. Thanks Priyanka
RE: [PATCHv2 2/9] arm64: fsl-layerscape: Assign addr to resv_ram if enabled RESV_RAM config
>-Original Message- >From: U-Boot On Behalf Of Zhiqiang Hou >Sent: Tuesday, March 24, 2020 1:42 PM >To: u-boot@lists.denx.de; Priyanka Jain ; Biwen Li > >Cc: Z.q. Hou >Subject: [PATCHv2 2/9] arm64: fsl-layerscape: Assign addr to resv_ram if >enabled RESV_RAM config > >From: Hou Zhiqiang > >The initialization of gd->arch.resv_ram pointer should depend on if the >RESV_RAM config is enabled. > >Signed-off-by: Hou Zhiqiang >--- >V2: > - No change. > > arch/arm/cpu/armv8/fsl-layerscape/cpu.c | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) > >diff --git a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c >b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c >index b443894453..1b7729c046 100644 >--- a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c >+++ b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c >@@ -1379,7 +1379,7 @@ static int tfa_dram_init_banksize(void) > if (i > 0) > ret = 0; > >-#if defined(CONFIG_FSL_MC_ENET) && !defined(CONFIG_SPL_BUILD) >+#if defined(CONFIG_RESV_RAM) && !defined(CONFIG_SPL_BUILD) > /* Assign memory for MC */ > #ifdef CONFIG_SYS_DDR_BLOCK3_BASE > if (gd->bd->bi_dram[2].size >= >@@ -1402,7 +1402,7 @@ static int tfa_dram_init_banksize(void) > board_reserve_ram_top(gd->bd- >>bi_dram[0].size); > } > } >-#endif/* CONFIG_FSL_MC_ENET */ >+#endif/* CONFIG_RESV_RAM */ This memory block was intended to be used for MC. That's why earlier check was for "CONFIG_FSL_MC_ENET" Are we planning to use this block for some other purpose as well? Also I see "CONFIG_ RESV_RAM" getting defines later in the series. Will MC will work if the series in applied partially? Regards Priyanka > return ret; > } >@@ -1465,7 +1465,7 @@ int dram_init_banksize(void) > } > #endif/* CONFIG_SYS_MEM_RESERVE_SECURE */ > >-#if defined(CONFIG_FSL_MC_ENET) && !defined(CONFIG_SPL_BUILD) >+#if defined(CONFIG_RESV_RAM) && !defined(CONFIG_SPL_BUILD) > /* Assign memory for MC */ > #ifdef CONFIG_SYS_DDR_BLOCK3_BASE > if (gd->bd->bi_dram[2].size >= >@@ -1488,7 +1488,7 @@ int dram_init_banksize(void) > board_reserve_ram_top(gd->bd- >>bi_dram[0].size); > } > } >-#endif/* CONFIG_FSL_MC_ENET */ >+#endif/* CONFIG_RESV_RAM */ > > #ifdef CONFIG_SYS_DP_DDR_BASE_PHY > #ifdef CONFIG_SYS_DDR_BLOCK3_BASE >-- >2.17.1
efi_loader: SPL build fails with EFI_SECURE_BOOT=y
Hello Takahiro, I tried to run with EFI_SECURE_BOOT enabled on pine64-lts_defconfig. U-Boot does not succeed to move from SPL to main U-Boot. The reason is that the SPL binary grows in size. This is due to EFI_SECURE_BOOT selecting additional code in SPL which of cause in unexpected. This is related to the following settings getting enabled: lib/Makefile:130: obj-$(CONFIG_OID_REGISTRY) += oid_registry.o Symbol: OID_REGISTRY [=y] Type : bool Defined at lib/Kconfig:589 Selected by [y]: - RSA_PUBLIC_KEY_PARSER [=y] && ASYMMETRIC_KEY_TYPE [=y] && ASYMMETRIC_PUBLIC_KEY_SUBTYPE [=y] - X509_CERTIFICATE_PARSER [=y] && ASYMMETRIC_KEY_TYPE [=y] && ASYMMETRIC_PUBLIC_KEY_SUBTYPE [=y] - PKCS7_MESSAGE_PARSER [=y] && ASYMMETRIC_KEY_TYPE [=y] && X509_CERTIFICATE_PARSER [=y] The OID registry is only used in lib/crypto which is never built for SPL. lib/date.c:13: #if defined(CONFIG_LIB_DATE) || defined(CONFIG_TIMESTAMP) lib/date.c:102: #ifdef CONFIG_LIB_DATE Symbol: LIB_DATE [=y] Type : bool Defined at lib/Kconfig:602 Selected by [y]: - X509_CERTIFICATE_PARSER [=y] && ASYMMETRIC_KEY_TYPE [=y] && ASYMMETRIC_PUBLIC_KEY_SUBTYPE [=y] Selected by [n]: - CMD_DATE [=n] - DM_RTC [=n] && DM [=y] There is a symbol CONFIG_SPL_RSA. If this symbol is enabled we probably want to enable LIB_DATE and OID_REGISTRY in SPL but not otherwise. Furthermore common/image-sig.c is built in SPL unnecessarily: Symbol: IMAGE_SIGN_INFO [=y] Type : bool Defined at common/Kconfig:1050 Selects: SHA1 [=y] && SHA256 [=y] Selected by [y]: - EFI_SECURE_BOOT [=y] && EFI_LOADER [=y] Selected by [n]: - FIT_SIGNATURE [=n] && FIT [=y] && DM [=y] - UT_LIB_RSA [=n] && UT_LIB [=n] && RSA [=y] && RSA_VERIFY_WITH_PKEY [=y] I am currently testing a patch series to avoid this: https://gitlab.denx.de/u-boot/custodians/u-boot-efi/-/tree/rsa Best regards Heinrich
Re: [RFC PATCH 3/3] mips: spl: Flush cache before jumping to U-Boot proper
Am 10.04.20 um 13:04 schrieb Stefan Roese:
> This patch adds a MIPS specific jump_to_image_no_args() implementation,
> which flushes the U-Boot proper image loaded from the boot device in
> SPL before jumping to it.
>
> It has been noticed on MT76x8, that this cache flush is needed. Other
> MIPS platforms might need it as well.
>
> Signed-off-by: Stefan Roese
> Cc: Weijie Gao
> Cc: Daniel Schwierzeck
> Cc: Simon Goldschmidt
> ---
> arch/mips/lib/boot.c | 14 ++
> 1 file changed, 14 insertions(+)
>
> diff --git a/arch/mips/lib/boot.c b/arch/mips/lib/boot.c
> index db862f6379..bc620abd9b 100644
> --- a/arch/mips/lib/boot.c
> +++ b/arch/mips/lib/boot.c
> @@ -6,6 +6,7 @@
> #include
> #include
> #include
> +#include
>
> DECLARE_GLOBAL_DATA_PTR;
>
> @@ -21,3 +22,16 @@ unsigned long do_go_exec(ulong (*entry)(int, char * const
> []),
>
> return entry(argc, argv);
> }
> +
> +void __noreturn jump_to_image_no_args(struct spl_image_info *spl_image)
> +{
> + typedef void __noreturn (*image_entry_noargs_t)(void);
> + image_entry_noargs_t image_entry =
> + (image_entry_noargs_t)spl_image->entry_point;
> +
> + /* Flush cache before jumping to application */
> + flush_cache((unsigned long)spl_image->load_addr, spl_image->size);
> +
> + debug("image entry point: 0x%lx\n", spl_image->entry_point);
> + image_entry();
> +}
>
the function itself looks good. But arch/mips/lib/boot.c depends on
CONFIG_CMD_GO (from Makefile: obj-$(CONFIG_CMD_GO) += boot.o)
I think it's better if we establish an arch/mips/lib/spl.c for generic
but MIPS specific SPL stuff and wrap it with CONFIG_SPL_BUILD.
--
- Daniel
Re: [RFC PATCH 1/3] spl: spl_nor: Move legacy image loading into spl_legacy.c
Am 10.04.20 um 13:04 schrieb Stefan Roese:
> Move the legacy image loading into spl_legacy.c. This makes it easier
> to extend the legacy image handling with new features that other
> SPL loaders might use (e.g. spl_spi.c etc).
>
> No functional change intended.
>
> Signed-off-by: Stefan Roese
> Cc: Weijie Gao
> Cc: Daniel Schwierzeck
> Cc: Simon Goldschmidt
> ---
> RFC comment: I'm sendig these 3 patches as RFC and once we've come to an
> agreement on these (Acked etc), I'll integrate them into the mtmips SPL
> patchset from Weijie and will send v7.
>
> Thanks,
> Stefan
>
> common/spl/spl_legacy.c | 20
> common/spl/spl_nor.c| 27 +--
> include/spl.h | 13 +
> 3 files changed, 46 insertions(+), 14 deletions(-)
Reviewed-by: Daniel Schwierzeck
nits below
>
> diff --git a/common/spl/spl_legacy.c b/common/spl/spl_legacy.c
> index 772135193e..7f00fc8885 100644
> --- a/common/spl/spl_legacy.c
> +++ b/common/spl/spl_legacy.c
> @@ -51,3 +51,23 @@ int spl_parse_legacy_header(struct spl_image_info
> *spl_image,
>
> return 0;
> }
> +
> +int spl_load_legacy_img(struct spl_image_info *spl_image,
> + struct spl_load_info *load, ulong header)
> +{
> + struct image_header hdr;
> + int ret;
> +
> + /* Read header into local struct */
> + load->read(load, header, sizeof(hdr), &hdr);
> +
> + ret = spl_parse_image_header(spl_image, &hdr);
> + if (ret)
> + return ret;
> +
> + /* Read image */
> + load->read(load, header + sizeof(hdr), spl_image->size,
> +(void *)(unsigned long)spl_image->load_addr);
> +
> + return 0;
> +}
> diff --git a/common/spl/spl_nor.c b/common/spl/spl_nor.c
> index b1e79b9ded..3f03ffe6a3 100644
> --- a/common/spl/spl_nor.c
> +++ b/common/spl/spl_nor.c
> @@ -24,7 +24,6 @@ unsigned long __weak spl_nor_get_uboot_base(void)
> static int spl_nor_load_image(struct spl_image_info *spl_image,
> struct spl_boot_device *bootdev)
> {
> - int ret;
> __maybe_unused const struct image_header *header;
> __maybe_unused struct spl_load_info load;
>
> @@ -43,6 +42,8 @@ static int spl_nor_load_image(struct spl_image_info
> *spl_image,
> header = (const struct image_header *)CONFIG_SYS_OS_BASE;
> #ifdef CONFIG_SPL_LOAD_FIT
> if (image_get_magic(header) == FDT_MAGIC) {
> + int ret;
> +
> debug("Found FIT\n");
> load.bl_len = 1;
> load.read = spl_nor_load_read;
> @@ -61,6 +62,7 @@ static int spl_nor_load_image(struct spl_image_info
> *spl_image,
> #endif
> if (image_get_os(header) == IH_OS_LINUX) {
> /* happy - was a Linux */
> + int ret;
>
> ret = spl_parse_image_header(spl_image, header);
> if (ret)
> @@ -93,11 +95,9 @@ static int spl_nor_load_image(struct spl_image_info
> *spl_image,
> debug("Found FIT format U-Boot\n");
> load.bl_len = 1;
> load.read = spl_nor_load_read;
> - ret = spl_load_simple_fit(spl_image, &load,
> - spl_nor_get_uboot_base(),
> - (void *)header);
> -
> - return ret;
> + return spl_load_simple_fit(spl_image, &load,
> +spl_nor_get_uboot_base(),
> +(void *)header);
looks like an unrelated optimisation
> }
> #endif
> if (IS_ENABLED(CONFIG_SPL_LOAD_IMX_CONTAINER)) {
> @@ -107,14 +107,13 @@ static int spl_nor_load_image(struct spl_image_info
> *spl_image,
> spl_nor_get_uboot_base());
> }
>
> - ret = spl_parse_image_header(spl_image,
> - (const struct image_header *)spl_nor_get_uboot_base());
> - if (ret)
> - return ret;
> -
> - memcpy((void *)(unsigned long)spl_image->load_addr,
> -(void *)(spl_nor_get_uboot_base() + sizeof(struct image_header)),
> -spl_image->size);
> + /* Legacy image handling */
> + if (IS_ENABLED(CONFIG_SPL_LEGACY_IMAGE_SUPPORT)) {
> + load.bl_len = 1;
> + load.read = spl_nor_load_read;
> + return spl_load_legacy_img(spl_image, &load,
> +spl_nor_get_uboot_base());
> + }
>
> return 0;
> }
> diff --git a/include/spl.h b/include/spl.h
> index 6087cd793c..c6c64b6a72 100644
> --- a/include/spl.h
> +++ b/include/spl.h
> @@ -219,6 +219,19 @@ int spl_load_simple_fit(struct spl_image_info *spl_image,
> #define SPL_COPY_PAYLOAD_ONLY1
> #define SPL_FIT_FOUND2
>
> +/**
> + * spl_load_legacy_img() - Loads a legacy image from a device.
> + * @spl_image: Image descr
Re: [PATCH v4] mmc: zynq: parse dt when probing
Hi Michal,
I just tried to check if the read performance acutally increased when
using an 8-bit data bus. As a quick test, I use the fatload command to
read a chunk of 1 GByte from an eMMC flash (generated with dd from
Linux). However, I don't see any difference at all:
mmc info
Device: mmc@ff16
Manufacturer ID: 9d
OEM: 101
Name: IS016
Bus Speed: 2
Mode: HS200 (200MHz)
Rd Block Len: 512
MMC version 5.0
High Capacity: Yes
Capacity: 14.6 GiB
Bus Width: 4-bit
(...)
fatload mmc 0 ${loadimage} test.img
1070579712 bytes read in 70458 ms (14.5 MiB/s)
With an 8-bit data bus:
mmcinfo
Device: mmc@ff16
Manufacturer ID: 9d
OEM: 101
Name: IS016
Bus Speed: 2
Mode: HS200 (200MHz)
Rd Block Len: 512
MMC version 5.0
High Capacity: Yes
Capacity: 14.6 GiB
Bus Width: 8-bit
(...)
fatload mmc 0 ${loadimage} test.img
1070579712 bytes read in 70551 ms (14.5 MiB/s)
I wonder if the fatload command is the bottleneck here? Unfortunately
I'm working from home right now and don't have an oscilloscope at hand
to verify in hardware. Do you have any inputs on that?
Thanks,
Benedikt
Re: [RFC PATCH 3/3] mips: spl: Flush cache before jumping to U-Boot proper
On 15.04.20 13:43, Daniel Schwierzeck wrote:
Am 10.04.20 um 13:04 schrieb Stefan Roese:
This patch adds a MIPS specific jump_to_image_no_args() implementation,
which flushes the U-Boot proper image loaded from the boot device in
SPL before jumping to it.
It has been noticed on MT76x8, that this cache flush is needed. Other
MIPS platforms might need it as well.
Signed-off-by: Stefan Roese
Cc: Weijie Gao
Cc: Daniel Schwierzeck
Cc: Simon Goldschmidt
---
arch/mips/lib/boot.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/mips/lib/boot.c b/arch/mips/lib/boot.c
index db862f6379..bc620abd9b 100644
--- a/arch/mips/lib/boot.c
+++ b/arch/mips/lib/boot.c
@@ -6,6 +6,7 @@
#include
#include
#include
+#include
DECLARE_GLOBAL_DATA_PTR;
@@ -21,3 +22,16 @@ unsigned long do_go_exec(ulong (*entry)(int, char * const []),
return entry(argc, argv);
}
+
+void __noreturn jump_to_image_no_args(struct spl_image_info *spl_image)
+{
+ typedef void __noreturn (*image_entry_noargs_t)(void);
+ image_entry_noargs_t image_entry =
+ (image_entry_noargs_t)spl_image->entry_point;
+
+ /* Flush cache before jumping to application */
+ flush_cache((unsigned long)spl_image->load_addr, spl_image->size);
+
+ debug("image entry point: 0x%lx\n", spl_image->entry_point);
+ image_entry();
+}
the function itself looks good. But arch/mips/lib/boot.c depends on
CONFIG_CMD_GO (from Makefile: obj-$(CONFIG_CMD_GO) += boot.o)
I think it's better if we establish an arch/mips/lib/spl.c for generic
but MIPS specific SPL stuff and wrap it with CONFIG_SPL_BUILD.
Yes, makes sense. I'll make this change in v7 of the patchset.
Thanks,
Stefan
RE: [PATCH] configs: ls1012afrwy: drop env qspi_bootcmd
>
> >-Original Message-
> >From: U-Boot On Behalf Of Biwen Li
> >Sent: Tuesday, March 31, 2020 1:54 PM
> >To: Jagdish Gediya ; Priyanka Jain
> >; Pramod Kumar ;
> >Shengzhou Liu
> >Cc: Alison Wang ; u-boot@lists.denx.de; Jiafei Pan
> >; Biwen Li
> >Subject: [PATCH] configs: ls1012afrwy: drop env qspi_bootcmd
> >
> >From: Biwen Li
> >
> >Drop useless environment variable installer and qspi_bootcmd for
> >ls1012afrwy
> >
> Please explain why these variables are useless
Only 2 MB nor flash in ls1012afrwy. So cannnot get kernel(30 MB) from the nor
flash.
>
> Thanks
> Priyanka
> >Signed-off-by: Biwen Li
> >---
> > include/configs/ls1012afrwy.h | 9 -
> > 1 file changed, 9 deletions(-)
> >
> >diff --git a/include/configs/ls1012afrwy.h
> >b/include/configs/ls1012afrwy.h index 9007249804..ec071d0606 100644
> >--- a/include/configs/ls1012afrwy.h
> >+++ b/include/configs/ls1012afrwy.h
> >@@ -107,15 +107,6 @@
> > "env exists secureboot "\
> > "&& esbc_validate ${scripthdraddr};"\
> > "source ${scriptaddr}\0" \
> >-"installer=load mmc 0:2 $load_addr "\
> >- "/flex_installer_arm64.itb; "\
> >- "bootm $load_addr#$board\0" \
> >-"qspi_bootcmd=pfe stop; echo Trying load from qspi..;" \
> >-"sf probe && sf read $load_addr " \
> >-"$kernel_addr $kernel_size; env exists secureboot " \
> >-"&& sf read $kernelheader_addr_r $kernelheader_addr "
> > \
> >-"$kernelheader_size && esbc_validate
> >${kernelheader_addr_r}; " \
> >-"bootm $load_addr#$board\0" \
> > "sd_bootcmd=pfe stop; echo Trying load from sd card..;"
> > \
> > "mmcinfo; mmc read $load_addr " \
> > "$kernel_addr_sd $kernel_size_sd ;" \
> >--
> >2.17.1
Re: [RFC PATCH 1/3] spl: spl_nor: Move legacy image loading into spl_legacy.c
On 15.04.20 13:46, Daniel Schwierzeck wrote:
Am 10.04.20 um 13:04 schrieb Stefan Roese:
Move the legacy image loading into spl_legacy.c. This makes it easier
to extend the legacy image handling with new features that other
SPL loaders might use (e.g. spl_spi.c etc).
No functional change intended.
Signed-off-by: Stefan Roese
Cc: Weijie Gao
Cc: Daniel Schwierzeck
Cc: Simon Goldschmidt
---
RFC comment: I'm sendig these 3 patches as RFC and once we've come to an
agreement on these (Acked etc), I'll integrate them into the mtmips SPL
patchset from Weijie and will send v7.
Thanks,
Stefan
common/spl/spl_legacy.c | 20
common/spl/spl_nor.c| 27 +--
include/spl.h | 13 +
3 files changed, 46 insertions(+), 14 deletions(-)
Reviewed-by: Daniel Schwierzeck
nits below
diff --git a/common/spl/spl_legacy.c b/common/spl/spl_legacy.c
index 772135193e..7f00fc8885 100644
--- a/common/spl/spl_legacy.c
+++ b/common/spl/spl_legacy.c
@@ -51,3 +51,23 @@ int spl_parse_legacy_header(struct spl_image_info *spl_image,
return 0;
}
+
+int spl_load_legacy_img(struct spl_image_info *spl_image,
+ struct spl_load_info *load, ulong header)
+{
+ struct image_header hdr;
+ int ret;
+
+ /* Read header into local struct */
+ load->read(load, header, sizeof(hdr), &hdr);
+
+ ret = spl_parse_image_header(spl_image, &hdr);
+ if (ret)
+ return ret;
+
+ /* Read image */
+ load->read(load, header + sizeof(hdr), spl_image->size,
+ (void *)(unsigned long)spl_image->load_addr);
+
+ return 0;
+}
diff --git a/common/spl/spl_nor.c b/common/spl/spl_nor.c
index b1e79b9ded..3f03ffe6a3 100644
--- a/common/spl/spl_nor.c
+++ b/common/spl/spl_nor.c
@@ -24,7 +24,6 @@ unsigned long __weak spl_nor_get_uboot_base(void)
static int spl_nor_load_image(struct spl_image_info *spl_image,
struct spl_boot_device *bootdev)
{
- int ret;
__maybe_unused const struct image_header *header;
__maybe_unused struct spl_load_info load;
@@ -43,6 +42,8 @@ static int spl_nor_load_image(struct spl_image_info *spl_image,
header = (const struct image_header *)CONFIG_SYS_OS_BASE;
#ifdef CONFIG_SPL_LOAD_FIT
if (image_get_magic(header) == FDT_MAGIC) {
+ int ret;
+
debug("Found FIT\n");
load.bl_len = 1;
load.read = spl_nor_load_read;
@@ -61,6 +62,7 @@ static int spl_nor_load_image(struct spl_image_info
*spl_image,
#endif
if (image_get_os(header) == IH_OS_LINUX) {
/* happy - was a Linux */
+ int ret;
ret = spl_parse_image_header(spl_image, header);
if (ret)
@@ -93,11 +95,9 @@ static int spl_nor_load_image(struct spl_image_info
*spl_image,
debug("Found FIT format U-Boot\n");
load.bl_len = 1;
load.read = spl_nor_load_read;
- ret = spl_load_simple_fit(spl_image, &load,
- spl_nor_get_uboot_base(),
- (void *)header);
-
- return ret;
+ return spl_load_simple_fit(spl_image, &load,
+ spl_nor_get_uboot_base(),
+ (void *)header);
looks like an unrelated optimisation
It looks this way. But its related: This is needed, as the if statement
below now results in a warning when the usage of the "ret" variable is
not changed:
common/spl/spl_nor.c:27:6: warning: unused variable 'ret'
[-Wunused-variable]
That's why I removed "ret" completely in this patch.
I could either generate a small patch "before" this one to remove "ret"
or mention this removal in the commit text of this patch.
Thanks,
Stefan
}
#endif
if (IS_ENABLED(CONFIG_SPL_LOAD_IMX_CONTAINER)) {
@@ -107,14 +107,13 @@ static int spl_nor_load_image(struct spl_image_info
*spl_image,
spl_nor_get_uboot_base());
}
- ret = spl_parse_image_header(spl_image,
- (const struct image_header *)spl_nor_get_uboot_base());
- if (ret)
- return ret;
-
- memcpy((void *)(unsigned long)spl_image->load_addr,
- (void *)(spl_nor_get_uboot_base() + sizeof(struct image_header)),
- spl_image->size);
+ /* Legacy image handling */
+ if (IS_ENABLED(CONFIG_SPL_LEGACY_IMAGE_SUPPORT)) {
+ load.bl_len = 1;
+ load.read = spl_nor_load_read;
+ return spl_load_legacy_img(spl_image, &load,
+ spl_nor_get_uboot_base());
+ }
return 0;
}
diff --git a/include/spl.h b/include/spl.h
index 6087cd793c
[PATCH] rockchip: rk3399: enable spl-fifo-mode for sdmmc
adapting commit fa2047c47310 ("rockchip: rk3328: enable spl-fifo-mode
for emmc and sdmmc") for rk3399.
Since mmc to sram can't do dma, add patch to prevent aborts transferring
TF-A parts.
Signed-off-by: Deepak Das
---
arch/arm/dts/rk3399-u-boot.dtsi | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/dts/rk3399-u-boot.dtsi b/arch/arm/dts/rk3399-u-boot.dtsi
index 8b857ccfc7..3ad824450e 100644
--- a/arch/arm/dts/rk3399-u-boot.dtsi
+++ b/arch/arm/dts/rk3399-u-boot.dtsi
@@ -84,6 +84,9 @@
&sdmmc {
u-boot,dm-pre-reloc;
+
+ /* mmc to sram can't do dma, prevent aborts transferring TF-A parts */
+ u-boot,spl-fifo-mode;
};
&spi1 {
--
2.17.1
RE: [PATCH v2 04/14] board: ls1088ardb: transition to DM_ETH
>-Original Message-
>From: Ioana Ciornei
>Sent: Wednesday, March 18, 2020 8:18 PM
>To: Priyanka Jain ; joe.hershber...@ni.com; u-
>b...@lists.denx.de
>Cc: Florin Laurentiu Chiculita ; Ioana
>Ciornei
>Subject: [PATCH v2 04/14] board: ls1088ardb: transition to DM_ETH
>
>In case CONFIG_DM_ETH is enabled, no hardcoding is necessary for
>DPAA2 Ethernet devices. Compile out any unnecessary setup when
>CONFIG_DM_ETH is activated.
>Also, force the PCI devices to be enumerated at probe time.
>
>Signed-off-by: Ioana Ciornei
>---
>Changes in v2:
> - none
>
> board/freescale/ls1088a/eth_ls1088ardb.c | 2 ++
> board/freescale/ls1088a/ls1088a.c| 5 +
> 2 files changed, 7 insertions(+)
>
>diff --git a/board/freescale/ls1088a/eth_ls1088ardb.c
>b/board/freescale/ls1088a/eth_ls1088ardb.c
>index 01f56db0a1bf..f56ce7d9ae8e 100644
>--- a/board/freescale/ls1088a/eth_ls1088ardb.c
>+++ b/board/freescale/ls1088a/eth_ls1088ardb.c
>@@ -18,6 +18,7 @@
> #include
> #include
>
>+#ifndef CONFIG_DM_ETH
> int board_eth_init(bd_t *bis)
> {
> #if defined(CONFIG_FSL_MC_ENET)
>@@ -95,6 +96,7 @@ int board_eth_init(bd_t *bis)
>
> return pci_eth_init(bis);
> }
>+#endif
>
> #if defined(CONFIG_RESET_PHY_R)
> void reset_phy(void)
>diff --git a/board/freescale/ls1088a/ls1088a.c
>b/board/freescale/ls1088a/ls1088a.c
>index 0bd397a0beb6..225e787c7577 100644
>--- a/board/freescale/ls1088a/ls1088a.c
>+++ b/board/freescale/ls1088a/ls1088a.c
>@@ -801,6 +801,11 @@ int board_init(void) #ifdef CONFIG_FSL_LS_PPA
> ppa_init();
> #endif
>+
>+#if !defined(CONFIG_SYS_EARLY_PCI_INIT) && defined(CONFIG_DM_ETH)
>+ pci_init();
>+#endif
>+
Ioana,
Can you please confirm that you have tested e1000 cards to be working fine
after this kind of changes.
Tested
Priyanka
> return 0;
> }
>
>--
>2.17.1
[PATCH] pwm: Add PWM driver for SiFive SoC
Adds a PWM driver for PWM chip present in SiFive's HiFive Unleashed SoC
This driver is simple port of Linux pwm sifive driver.
Signed-off-by: Yash Shah
---
drivers/pwm/Kconfig | 6 ++
drivers/pwm/Makefile | 1 +
drivers/pwm/pwm-sifive.c | 181 +++
3 files changed, 188 insertions(+)
create mode 100644 drivers/pwm/pwm-sifive.c
diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index 1f36fc7..d6ea9ee 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -40,6 +40,12 @@ config PWM_SANDBOX
useful. The PWM can be enabled but is not connected to any outputs
so this is not very useful.
+config PWM_SIFIVE
+ bool "Enable support for SiFive PWM"
+ depends on DM_PWM
+ help
+ This PWM is found SiFive's FU540 and other SoCs.
+
config PWM_TEGRA
bool "Enable support for the Tegra PWM"
depends on DM_PWM
diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
index a837c35..e2d4185 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_DM_PWM) += pwm-uclass.o
obj-$(CONFIG_PWM_EXYNOS) += exynos_pwm.o
obj-$(CONFIG_PWM_IMX) += pwm-imx.o pwm-imx-util.o
+obj-$(CONFIG_PWM_SIFIVE) += pwm-sifive.o
obj-$(CONFIG_PWM_ROCKCHIP) += rk_pwm.o
obj-$(CONFIG_PWM_SANDBOX) += sandbox_pwm.o
obj-$(CONFIG_PWM_TEGRA)+= tegra_pwm.o
diff --git a/drivers/pwm/pwm-sifive.c b/drivers/pwm/pwm-sifive.c
new file mode 100644
index 000..c54297e
--- /dev/null
+++ b/drivers/pwm/pwm-sifive.c
@@ -0,0 +1,181 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2020 SiFive, Inc
+ * For SiFive's PWM IP block documentation please refer Chapter 14 of
+ * Reference Manual : https://static.dev.sifive.com/FU540-C000-v1.0.pdf
+ *
+ * Limitations:
+ * - When changing both duty cycle and period, we cannot prevent in
+ * software that the output might produce a period with mixed
+ * settings (new period length and old duty cycle).
+ * - The hardware cannot generate a 100% duty cycle.
+ * - The hardware generates only inverted output.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* PWMCFG fields */
+#define PWM_SIFIVE_PWMCFG_SCALE GENMASK(3, 0)
+#define PWM_SIFIVE_PWMCFG_STICKYBIT(8)
+#define PWM_SIFIVE_PWMCFG_ZERO_CMP BIT(9)
+#define PWM_SIFIVE_PWMCFG_DEGLITCH BIT(10)
+#define PWM_SIFIVE_PWMCFG_EN_ALWAYS BIT(12)
+#define PWM_SIFIVE_PWMCFG_EN_ONCE BIT(13)
+#define PWM_SIFIVE_PWMCFG_CENTERBIT(16)
+#define PWM_SIFIVE_PWMCFG_GANG BIT(24)
+#define PWM_SIFIVE_PWMCFG_IPBIT(28)
+
+/* PWM_SIFIVE_SIZE_PWMCMP is used to calculate offset for pwmcmpX registers */
+#define PWM_SIFIVE_SIZE_PWMCMP 4
+#define PWM_SIFIVE_CMPWIDTH 16
+
+DECLARE_GLOBAL_DATA_PTR;
+
+struct pwm_sifive_regs {
+ unsigned long cfg;
+ unsigned long cnt;
+ unsigned long pwms;
+ unsigned long cmp0;
+};
+
+struct pwm_sifive_data {
+ struct pwm_sifive_regs regs;
+};
+
+struct pwm_sifive_priv {
+ fdt_addr_t base;
+ ulong freq;
+ const struct pwm_sifive_data *data;
+};
+
+static int pwm_sifive_set_invert(struct udevice *dev, uint channel,
+bool polarity)
+{
+ debug("%s: Do not support polarity\n", __func__);
+
+ return 0;
+}
+
+static int pwm_sifive_set_config(struct udevice *dev, uint channel,
+uint period_ns, uint duty_ns)
+{
+ struct pwm_sifive_priv *priv = dev_get_priv(dev);
+ const struct pwm_sifive_regs *regs = &priv->data->regs;
+ unsigned long scale_pow;
+ unsigned long long num;
+ u32 scale, val = 0, frac;
+
+ debug("%s: period_ns=%u, duty_ns=%u\n", __func__, period_ns, duty_ns);
+
+ /*
+* The PWM unit is used with pwmzerocmp=0, so the only way to modify the
+* period length is using pwmscale which provides the number of bits the
+* counter is shifted before being feed to the comparators. A period
+* lasts (1 << (PWM_SIFIVE_CMPWIDTH + pwmscale)) clock ticks.
+* (1 << (PWM_SIFIVE_CMPWIDTH + scale)) * 10^9/rate = period
+*/
+ scale_pow = lldiv((uint64_t)priv->freq * period_ns, 10);
+ scale = clamp(ilog2(scale_pow) - PWM_SIFIVE_CMPWIDTH, 0, 0xf);
+ val |= FIELD_PREP(PWM_SIFIVE_PWMCFG_SCALE, scale);
+
+ /*
+* The problem of output producing mixed setting as mentioned at top,
+* occurs here. To minimize the window for this problem, we are
+* calculating the register values first and then writing them
+* consecutively
+*/
+ num = (u64)duty_ns * (1U << PWM_SIFIVE_CMPWIDTH);
+ frac = DIV_ROUND_CLOSEST_ULL(num, period_ns);
+ frac = min(frac, (1U << PWM_SIFIVE_CMPWIDTH) - 1);
+
+ writel(val, (void __iomem *)priv->base +
[PATCH] USB: Add USB support in u-boot for OrangePi Win/Plus
From: Maxime Hesling Make USB devices (keyboard, storage...) working in u-boot for OrangePi Win/Plus. --- configs/orangepi_win_defconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/configs/orangepi_win_defconfig b/configs/orangepi_win_defconfig index 047a6b7d84..c7c4c37407 100644 --- a/configs/orangepi_win_defconfig +++ b/configs/orangepi_win_defconfig @@ -7,6 +7,8 @@ CONFIG_MACPWR="PD14" CONFIG_SPL_SPI_SUNXI=y # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set CONFIG_DEFAULT_DEVICE_TREE="sun50i-a64-orangepi-win" +CONFIG_USB0_ID_DET="PH9" +CONFIG_USB1_VBUS_PIN="PD7" CONFIG_PHY_REALTEK=y CONFIG_SUN8I_EMAC=y CONFIG_USB_EHCI_HCD=y -- 2.25.2
Re: [RFC PATCH 2/3] spl: spl_legacy: Add lzma decompression support for legacy image
Am 10.04.20 um 13:04 schrieb Stefan Roese:
> From: Weijie Gao
>
> This patch adds support for decompressing LZMA compressed u-boot payload
> in legacy uImage format.
>
> Using this patch together with u-boot-lzma.img may be useful for some
> platforms as they can reduce the size and load time of u-boot payload.
>
> Signed-off-by: Weijie Gao
> Signed-off-by: Stefan Roese
> Cc: Daniel Schwierzeck
> Cc: Simon Goldschmidt
> ---
> common/spl/spl_legacy.c | 50 +++--
> 1 file changed, 48 insertions(+), 2 deletions(-)
Reviewed-by: Daniel Schwierzeck
nits below
>
> diff --git a/common/spl/spl_legacy.c b/common/spl/spl_legacy.c
> index 7f00fc8885..41734c026f 100644
> --- a/common/spl/spl_legacy.c
> +++ b/common/spl/spl_legacy.c
> @@ -4,8 +4,15 @@
> */
>
> #include
> +#include
> #include
>
> +#include
> +#include
> +#include
> +
> +#define LZMA_LEN (1 << 20)
> +
> int spl_parse_legacy_header(struct spl_image_info *spl_image,
> const struct image_header *header)
> {
> @@ -55,7 +62,10 @@ int spl_parse_legacy_header(struct spl_image_info
> *spl_image,
> int spl_load_legacy_img(struct spl_image_info *spl_image,
> struct spl_load_info *load, ulong header)
> {
> + __maybe_unused SizeT lzma_len;
> + __maybe_unused void *src;
> struct image_header hdr;
> + ulong dataptr;
> int ret;
>
> /* Read header into local struct */
> @@ -65,9 +75,45 @@ int spl_load_legacy_img(struct spl_image_info *spl_image,
> if (ret)
> return ret;
>
> + dataptr = header + sizeof(hdr);
> +
> /* Read image */
> - load->read(load, header + sizeof(hdr), spl_image->size,
> -(void *)(unsigned long)spl_image->load_addr);
> + switch (image_get_comp(&hdr)) {
> + case IH_COMP_NONE:
> + load->read(load, dataptr, spl_image->size,
> +(void *)(unsigned long)spl_image->load_addr);
> + break;
to avoid the little increase of binary footprint due to the extra check
maybe a little wrapper like this could help:
static inline int spl_image_get_comp(const struct image_header *hdr)
{
if (IS_ENABLED(CONFIG_SPL_LZMA) /* ||
IS_ENABLED(CONFIG_SPL_ANOTHER_FANCY_COMPRESSION) */)
return image_get_comp(hdr);
return IH_COMP_NONE;
}
switch (spl_image_get_comp(&hdr)) {
...
}
then the compiler should optimise the switch/case statement away due to
Dead Code Elimination.
> +
> +#if IS_ENABLED(CONFIG_SPL_LZMA)
> + case IH_COMP_LZMA:
> + lzma_len = LZMA_LEN;
> +
> + debug("LZMA: Decompressing %08lx to %08lx\n",
> + dataptr, spl_image->load_addr);
> + src = malloc(spl_image->size);
> + if (!src) {
> + printf("Unable to allocate %d bytes for LZMA\n",
> +spl_image->size);
> + return -ENOMEM;
> + }
> +
> + load->read(load, dataptr, spl_image->size, src);
> + ret = lzmaBuffToBuffDecompress((void *)spl_image->load_addr,
> +&lzma_len, src, spl_image->size);
> + if (ret) {
> + printf("LZMA decompression error: %d\n", ret);
> + return ret;
> + }
> +
> + spl_image->size = lzma_len;
> + break;
> +#endif
> +
> + default:
> + debug("Compression method %s is not supported\n",
> + genimg_get_comp_short_name(image_get_comp(&hdr)));
> + return -EINVAL;
> + }
>
> return 0;
> }
>
--
- Daniel
Re: [PATCH] rockchip: rk3399: enable spl-fifo-mode for sdmmc
> On 15.04.2020, at 05:25, Deepak Das wrote:
>
> adapting commit fa2047c47310 ("rockchip: rk3328: enable spl-fifo-mode
> for emmc and sdmmc") for rk3399.
> Since mmc to sram can't do dma, add patch to prevent aborts transferring
> TF-A parts.
>
> Signed-off-by: Deepak Das
> ---
> arch/arm/dts/rk3399-u-boot.dtsi | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/arch/arm/dts/rk3399-u-boot.dtsi b/arch/arm/dts/rk3399-u-boot.dtsi
> index 8b857ccfc7..3ad824450e 100644
> --- a/arch/arm/dts/rk3399-u-boot.dtsi
> +++ b/arch/arm/dts/rk3399-u-boot.dtsi
> @@ -84,6 +84,9 @@
>
> &sdmmc {
> u-boot,dm-pre-reloc;
> +
> + /* mmc to sram can't do dma, prevent aborts transferring TF-A parts */
> + u-boot,spl-fifo-mode;
Most transfers in SPL mode will occur to RAM (i.e. most of TF-A and the full
U-Boot),
so this is a heavy-handed solution for a problem affecting only some transfers.
Can’t this be solved using bounce buffers?
You will need to check if the target address cross the inaccessible memory
regions
and—if and only if—send these payloads through a bounce buffer...
> };
>
> &spi1 {
> --
> 2.17.1
>
RE: [PATCH v2 10/14] arm: dts: ls2088ardb: add DPMAC and PHY nodes
>-Original Message-
>From: Ioana Ciornei
>Sent: Wednesday, March 18, 2020 8:18 PM
>To: Priyanka Jain ; joe.hershber...@ni.com; u-
>b...@lists.denx.de
>Cc: Florin Laurentiu Chiculita ; Ioana
>Ciornei
>Subject: [PATCH v2 10/14] arm: dts: ls2088ardb: add DPMAC and PHY nodes
>
>In order to maintain compatibility with the Linux DTS, the entire fsl-mc node
>is
>added but instead of being probed by a dedicated bus driver it will be a
>simple-mfd.
>
>Also, annotate the external MDIO nodes and describe the PHYs (4 x AQR405
>and 4 x CS4340). Also, add phy-handles for the dpmacs to their associated
>PHY.
>
>Signed-off-by: Ioana Ciornei
>---
>Changes in v2:
> - none
>
> arch/arm/dts/fsl-ls2080a.dtsi | 75 +--
> arch/arm/dts/fsl-ls2088a-rdb-qspi.dts | 88 +++
> 2 files changed, 157 insertions(+), 6 deletions(-)
>
>diff --git a/arch/arm/dts/fsl-ls2080a.dtsi b/arch/arm/dts/fsl-ls2080a.dtsi
>index
>7ff854caecd5..fb5777e268e4 100644
>--- a/arch/arm/dts/fsl-ls2080a.dtsi
>+++ b/arch/arm/dts/fsl-ls2080a.dtsi
>@@ -50,12 +50,6 @@
> interrupts = <0 32 0x1>; /* edge triggered */
> };
>
>- fsl_mc: fsl-mc@80c00 {
>- compatible = "fsl,qoriq-mc";
>- reg = <0x0008 0x0c00 0 0x40>,/* MC portal
>base */
>-<0x 0x0834 0 0x4>; /* MC control reg */
>- };
>-
> i2c0: i2c@200 {
> status = "disabled";
> compatible = "fsl,vf610-i2c";
>@@ -200,6 +194,75 @@
> status = "disabled";
> };
>
>+ fsl_mc: fsl-mc@80c00 {
>+ compatible = "fsl,qoriq-mc", "simple-mfd";
>+ reg = <0x0008 0x0c00 0 0x40>,/* MC portal base
>*/
>+<0x 0x0834 0 0x4>; /* MC control reg */
>+ #address-cells = <3>;
>+ #size-cells = <1>;
>+
>+ /*
>+ * Region type 0x0 - MC portals
>+ * Region type 0x1 - QBMAN portals
>+ */
>+ ranges = <0x0 0x0 0x0 0x8 0x0c00 0x400
>+ 0x1 0x0 0x0 0x8 0x1800 0x800>;
>+
>+ dpmacs {
>+ compatible = "simple-mfd";
>+ #address-cells = <1>;
>+ #size-cells = <0>;
>+
>+ dpmac1: dpmac@1 {
>+ compatible = "fsl,qoriq-mc-dpmac";
>+ reg = <0x1>;
>+ status = "disabled";
>+ };
>+
>+ dpmac2: dpmac@2 {
>+ compatible = "fsl,qoriq-mc-dpmac";
>+ reg = <0x2>;
>+ status = "disabled";
>+ };
>+
>+ dpmac3: dpmac@3 {
>+ compatible = "fsl,qoriq-mc-dpmac";
>+ reg = <0x3>;
>+ status = "disabled";
>+ };
>+
>+ dpmac4: dpmac@4 {
>+ compatible = "fsl,qoriq-mc-dpmac";
>+ reg = <0x4>;
>+ status = "disabled";
>+ };
>+
>+ dpmac5: dpmac@5 {
>+ compatible = "fsl,qoriq-mc-dpmac";
>+ reg = <0x5>;
>+ status = "disabled";
>+ };
>+
>+ dpmac6: dpmac@6 {
>+ compatible = "fsl,qoriq-mc-dpmac";
>+ reg = <0x6>;
>+ status = "disabled";
>+ };
>+
>+ dpmac7: dpmac@7 {
>+ compatible = "fsl,qoriq-mc-dpmac";
>+ reg = <0x7>;
>+ status = "disabled";
>+ };
>+
>+ dpmac8: dpmac@8 {
>+ compatible = "fsl,qoriq-mc-dpmac";
>+ reg = <0x8>;
>+ status = "disabled";
>+ };
>+ };
>+ };
>+
> emdio1: mdio@8B96000 {
> compatible = "fsl,ls-mdio";
> reg = <0x0 0x8B96000 0x0 0x1000>;
>diff --git a/arch/arm/dts/fsl-ls2088a-rdb-qspi.dts b/arch/arm/dts/fsl-ls2088a-
>rdb-qspi.dts
>index 72b2177b70d9..16b9aeec966c 100644
>--- a/arch/arm/dts/fsl-ls2088a-rdb-qspi.dts
>+++ b/arch/arm/dts/fsl-ls2088a-rdb-qspi.dts
>@@ -21,6 +21,94 @@
> };
> };
>
>+&dpmac1 {
>+ status = "okay";
>+ phy-handle = <&mdio1_phy1>;
>+ phy-connection-type = "xfi";
>+};
>+
>+&dpmac2 {
>+ status = "okay";
>+ phy-handle = <&mdio1_phy2>;
>+ phy-connection-type = "xfi";
>+};
>+
>+&dpmac3 {
>+ status = "okay";
>+ phy-handle = <&mdio1_phy3>;
>+ ph
Re: [RFC PATCH 2/3] spl: spl_legacy: Add lzma decompression support for legacy image
On 15.04.20 14:52, Daniel Schwierzeck wrote:
Am 10.04.20 um 13:04 schrieb Stefan Roese:
From: Weijie Gao
This patch adds support for decompressing LZMA compressed u-boot payload
in legacy uImage format.
Using this patch together with u-boot-lzma.img may be useful for some
platforms as they can reduce the size and load time of u-boot payload.
Signed-off-by: Weijie Gao
Signed-off-by: Stefan Roese
Cc: Daniel Schwierzeck
Cc: Simon Goldschmidt
---
common/spl/spl_legacy.c | 50 +++--
1 file changed, 48 insertions(+), 2 deletions(-)
Reviewed-by: Daniel Schwierzeck
nits below
diff --git a/common/spl/spl_legacy.c b/common/spl/spl_legacy.c
index 7f00fc8885..41734c026f 100644
--- a/common/spl/spl_legacy.c
+++ b/common/spl/spl_legacy.c
@@ -4,8 +4,15 @@
*/
#include
+#include
#include
+#include
+#include
+#include
+
+#define LZMA_LEN (1 << 20)
+
int spl_parse_legacy_header(struct spl_image_info *spl_image,
const struct image_header *header)
{
@@ -55,7 +62,10 @@ int spl_parse_legacy_header(struct spl_image_info *spl_image,
int spl_load_legacy_img(struct spl_image_info *spl_image,
struct spl_load_info *load, ulong header)
{
+ __maybe_unused SizeT lzma_len;
+ __maybe_unused void *src;
struct image_header hdr;
+ ulong dataptr;
int ret;
/* Read header into local struct */
@@ -65,9 +75,45 @@ int spl_load_legacy_img(struct spl_image_info *spl_image,
if (ret)
return ret;
+ dataptr = header + sizeof(hdr);
+
/* Read image */
- load->read(load, header + sizeof(hdr), spl_image->size,
- (void *)(unsigned long)spl_image->load_addr);
+ switch (image_get_comp(&hdr)) {
+ case IH_COMP_NONE:
+ load->read(load, dataptr, spl_image->size,
+ (void *)(unsigned long)spl_image->load_addr);
+ break;
to avoid the little increase of binary footprint due to the extra check
maybe a little wrapper like this could help:
static inline int spl_image_get_comp(const struct image_header *hdr)
{
if (IS_ENABLED(CONFIG_SPL_LZMA) /* ||
IS_ENABLED(CONFIG_SPL_ANOTHER_FANCY_COMPRESSION) */)
return image_get_comp(hdr);
return IH_COMP_NONE;
}
switch (spl_image_get_comp(&hdr)) {
...
}
then the compiler should optimise the switch/case statement away due to
Dead Code Elimination.
Good idea. I was a bit concerned, even about minimal code size increase
in SPL as well. I'll work on this in v7.
Thanks,
Stefan
+
+#if IS_ENABLED(CONFIG_SPL_LZMA)
+ case IH_COMP_LZMA:
+ lzma_len = LZMA_LEN;
+
+ debug("LZMA: Decompressing %08lx to %08lx\n",
+ dataptr, spl_image->load_addr);
+ src = malloc(spl_image->size);
+ if (!src) {
+ printf("Unable to allocate %d bytes for LZMA\n",
+ spl_image->size);
+ return -ENOMEM;
+ }
+
+ load->read(load, dataptr, spl_image->size, src);
+ ret = lzmaBuffToBuffDecompress((void *)spl_image->load_addr,
+ &lzma_len, src, spl_image->size);
+ if (ret) {
+ printf("LZMA decompression error: %d\n", ret);
+ return ret;
+ }
+
+ spl_image->size = lzma_len;
+ break;
+#endif
+
+ default:
+ debug("Compression method %s is not supported\n",
+ genimg_get_comp_short_name(image_get_comp(&hdr)));
+ return -EINVAL;
+ }
return 0;
}
Viele Grüße,
Stefan
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
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 2/7] ddr: altera: arria10: Move SDRAM driver to DM
On 4/15/20 11:00 AM, Ley Foon Tan wrote:
[...]
> +++ b/arch/arm/mach-socfpga/include/mach/sdram_arria10.h
> @@ -6,76 +6,65 @@
[...]
> +/* FW DDR MPU F2S SCR */
> +#define FW_DDR_MPU_F2S_SCR_EN0x00
> +#define FW_DDR_MPU_F2S_SCR_MPUR0 0x10
> +#define FW_DDR_MPU_F2S_SCR_MPUR1 0x14
> +#define FW_DDR_MPU_F2S_SCR_MPUR2 0x18
> +#define FW_DDR_MPU_F2S_SCR_MPUR3 0x1c
These can be:
#define FW_DDR_MPU_F2S_SCR_MPUR(n) (0x10 + (n) * 4)
and the other macros can be reduced in a similar manner.
> +#define FW_DDR_MPU_F2S_SCR_F2S0_R0 0x20
> +#define FW_DDR_MPU_F2S_SCR_F2S0_R1 0x24
> +#define FW_DDR_MPU_F2S_SCR_F2S0_R2 0x28
> +#define FW_DDR_MPU_F2S_SCR_F2S0_R3 0x2c
> +#define FW_DDR_MPU_F2S_SCR_F2S1_R0 0x30
> +#define FW_DDR_MPU_F2S_SCR_F2S1_R1 0x34
> +#define FW_DDR_MPU_F2S_SCR_F2S1_R2 0x38
> +#define FW_DDR_MPU_F2S_SCR_F2S1_R3 0x3c
> +#define FW_DDR_MPU_F2S_SCR_F2S2_R0 0x40
> +#define FW_DDR_MPU_F2S_SCR_F2S2_R1 0x44
> +#define FW_DDR_MPU_F2S_SCR_F2S2_R2 0x48
> +#define FW_DDR_MPU_F2S_SCR_F2S2_R3 0x4c
> +
> +/* FW DDR L3 DDR SCR */
> +#define FW_DDR_L3_SCR_EN 0x00
> +#define FW_DDR_L3_SCR_HPS_R0_ADDR0x0c
> +#define FW_DDR_L3_SCR_HPS_R1_ADDR0x10
> +#define FW_DDR_L3_SCR_HPS_R2_ADDR0x14
> +#define FW_DDR_L3_SCR_HPS_R3_ADDR0x18
> +#define FW_DDR_L3_SCR_HPS_R4_ADDR0x1c
> +#define FW_DDR_L3_SCR_HPS_R5_ADDR0x20
> +#define FW_DDR_L3_SCR_HPS_R6_ADDR0x24
> +#define FW_DDR_L3_SCR_HPS_R7_ADDR0x28
[...]
> +#if CONFIG_IS_ENABLED(ALTERA_SDRAM)
> /* If the IOSSM/full FPGA is already loaded, start DDR */
> - if (is_fpgamgr_early_user_mode() || is_fpgamgr_user_mode())
> - ddr_calibration_sequence();
> + if (is_fpgamgr_early_user_mode() || is_fpgamgr_user_mode()) {
> + ret = uclass_get_device(UCLASS_RAM, 0, &dev);
> + if (ret) {
> + debug("DRAM init failed: %d\n", ret);
This should be printf(), since it's an error, no ?
> + hang();
> + }
> + }
> +#endif
>
> if (!is_fpgamgr_user_mode())
> fpgamgr_program(buf, FPGA_BUFSIZ, 0);
> diff --git a/drivers/ddr/altera/Kconfig b/drivers/ddr/altera/Kconfig
> index 8f590dc5f611..30ee884dcf47 100644
> --- a/drivers/ddr/altera/Kconfig
> +++ b/drivers/ddr/altera/Kconfig
> @@ -2,7 +2,7 @@ config SPL_ALTERA_SDRAM
> bool "SoCFPGA DDR SDRAM driver in SPL"
> depends on SPL
> depends on TARGET_SOCFPGA_GEN5 || TARGET_SOCFPGA_ARRIA10 ||
> TARGET_SOCFPGA_STRATIX10 || TARGET_SOCFPGA_AGILEX
> - select RAM if TARGET_SOCFPGA_GEN5 || TARGET_SOCFPGA_STRATIX10 ||
> TARGET_SOCFPGA_AGILEX
> - select SPL_RAM if TARGET_SOCFPGA_GEN5 || TARGET_SOCFPGA_STRATIX10 ||
> TARGET_SOCFPGA_AGILEX
> + select RAM
> + select SPL_RAM
Shouldn't this be selected for Arria 10 only ?
[...]
Re: [PATCH 3/7] ddr: altera: arria10: Change to use reset DM function
On 4/15/20 11:00 AM, Ley Foon Tan wrote:
> Change to use reset DM function and remove unused
> socfpga_reset_deassert_noc_ddr_scheduler().
>
> Signed-off-by: Ley Foon Tan
> ---
> .../include/mach/reset_manager_arria10.h | 1 -
> arch/arm/mach-socfpga/reset_manager_arria10.c | 7 --
> drivers/ddr/altera/sdram_arria10.c| 25 ++-
> 3 files changed, 13 insertions(+), 20 deletions(-)
>
> diff --git a/arch/arm/mach-socfpga/include/mach/reset_manager_arria10.h
> b/arch/arm/mach-socfpga/include/mach/reset_manager_arria10.h
> index 22e4eb33de88..a0fad7c1e2fc 100644
> --- a/arch/arm/mach-socfpga/include/mach/reset_manager_arria10.h
> +++ b/arch/arm/mach-socfpga/include/mach/reset_manager_arria10.h
> @@ -9,7 +9,6 @@
> #include
>
> void socfpga_watchdog_disable(void);
> -void socfpga_reset_deassert_noc_ddr_scheduler(void);
> int socfpga_reset_deassert_bridges_handoff(void);
> void socfpga_reset_deassert_osc1wd0(void);
> int socfpga_bridges_reset(void);
> diff --git a/arch/arm/mach-socfpga/reset_manager_arria10.c
> b/arch/arm/mach-socfpga/reset_manager_arria10.c
> index aa5299415a74..edfe250ec0bc 100644
> --- a/arch/arm/mach-socfpga/reset_manager_arria10.c
> +++ b/arch/arm/mach-socfpga/reset_manager_arria10.c
> @@ -62,13 +62,6 @@ void socfpga_watchdog_disable(void)
>ALT_RSTMGR_PER1MODRST_WD0_SET_MSK);
> }
>
> -/* Release NOC ddr scheduler from reset */
> -void socfpga_reset_deassert_noc_ddr_scheduler(void)
> -{
> - clrbits_le32(socfpga_get_rstmgr_addr() + RSTMGR_A10_BRGMODRST,
> - ALT_RSTMGR_BRGMODRST_DDRSCH_SET_MSK);
> -}
> -
> static int get_bridge_init_val(const void *blob, int compat_id)
> {
> int node;
> diff --git a/drivers/ddr/altera/sdram_arria10.c
> b/drivers/ddr/altera/sdram_arria10.c
> index a31d45a5bb8e..794c13acfa93 100644
> --- a/drivers/ddr/altera/sdram_arria10.c
> +++ b/drivers/ddr/altera/sdram_arria10.c
> @@ -10,19 +10,21 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> #include
> #include
> -#include
> #include
> +#include
> #include
>
> DECLARE_GLOBAL_DATA_PTR;
>
> struct altera_sdram_priv {
> struct ram_info info;
> + struct reset_ctl_bulk resets;
> };
>
> struct altera_sdram_platdata {
> @@ -152,7 +154,7 @@ static int emif_reset(struct altera_sdram_platdata *plat)
> return 0;
> }
>
> -static int ddr_setup(struct altera_sdram_platdata *plat)
> +static int sdram_startup(struct altera_sdram_platdata *plat)
> {
> int i, ret;
>
> @@ -198,16 +200,6 @@ static void sdram_init_ecc_bits(u32 size)
> dcache_disable();
> }
>
> -/* Function to startup the SDRAM*/
> -static int sdram_startup(struct altera_sdram_platdata *plat)
> -{
> - /* Release NOC ddr scheduler from reset */
> - socfpga_reset_deassert_noc_ddr_scheduler();
> -
> - /* Bringup the DDR (calibration and configuration) */
> - return ddr_setup(plat);
> -}
> -
> static u64 sdram_size_calc(struct altera_sdram_platdata *plat)
> {
> u32 dramaddrw = readl(plat->iohmc + DRAMADDRW);
> @@ -703,8 +695,17 @@ static int altera_sdram_ofdata_to_platdata(struct
> udevice *dev)
>
> static int altera_sdram_probe(struct udevice *dev)
> {
> + int ret;
> struct altera_sdram_priv *priv = dev_get_priv(dev);
>
> + ret = reset_get_bulk(dev, &priv->resets);
> + if (ret) {
> + dev_err(dev, "Can't get reset: %d\n", ret);
> + return -ENODEV;
> + }
> +
> + reset_deassert_bulk(&priv->resets);
> +
> if (ddr_calibration_sequence(dev->platdata) != 0) {
> puts("SDRAM init failed.\n");
> goto failed;
>
I think you need to re-assert the reset in the failed: fail path.
Re: [PATCH 6/7] ddr: altera: arria10: Change %i to %u for printf
On 4/15/20 11:00 AM, Ley Foon Tan wrote:
> Tiny printf doesn't support %i, change to %u.
>
> Signed-off-by: Ley Foon Tan
> ---
> drivers/ddr/altera/sdram_arria10.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/ddr/altera/sdram_arria10.c
> b/drivers/ddr/altera/sdram_arria10.c
> index e3f11984a978..8acf324117af 100644
> --- a/drivers/ddr/altera/sdram_arria10.c
> +++ b/drivers/ddr/altera/sdram_arria10.c
> @@ -195,7 +195,7 @@ static void sdram_init_ecc_bits(u32 size)
>
> dcache_enable();
>
> - printf("DDRCAL: Scrubbing ECC RAM (%i MiB).\n", size >> 20);
> + printf("DDRCAL: Scrubbing ECC RAM (%u MiB).\n", size >> 20);
> memset((void *)0x8000, 0, size - 0x8000);
> flush_dcache_all();
> printf("DDRCAL: Scrubbing ECC RAM done.\n");
>
Yes, sadly, tiny printf is broken so we need to patch code to work
around that breakage.
Re: [PATCH 1/7] ddr: altera: arria10: Fix incorrect address for mpu1
On 4/15/20 11:00 AM, Ley Foon Tan wrote: > Remove extra "SOCFPGA_SDR_FIREWALL_MPU_FPGA_ADDRESS" in mpu1 address. I see what the patch does from the patch itself, but the commit message does not explain _why_ the patch does it. Can you add it ? [...]
Re: [PATCH 5/7] ddr: altera: arria10: Add RAM size check
On 4/15/20 11:00 AM, Ley Foon Tan wrote:
> Add call to get_ram_size() function to check memory range
> for valid RAM.
>
> Signed-off-by: Ley Foon Tan
> ---
> drivers/ddr/altera/sdram_arria10.c | 25 -
> 1 file changed, 24 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/ddr/altera/sdram_arria10.c
> b/drivers/ddr/altera/sdram_arria10.c
> index 6b74423ea789..e3f11984a978 100644
> --- a/drivers/ddr/altera/sdram_arria10.c
> +++ b/drivers/ddr/altera/sdram_arria10.c
> @@ -8,6 +8,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -17,7 +18,7 @@
> #include
> #include
> #include
> -#include
> +#include
>
> #include "sdram_arria10.h"
>
> @@ -671,6 +672,27 @@ static int ddr_calibration_sequence(struct
> altera_sdram_platdata *plat)
> return 0;
> }
>
> +static void sdram_size_check(struct ram_info *ram)
> +{
> + phys_size_t ram_check = 0;
> + phys_size_t size = ram->size;
> + phys_addr_t base = ram->base;
> +
> + debug("DDR: Running SDRAM size sanity check\n");
> +
> + while (ram_check < size) {
> + ram_check += get_ram_size((void *)(base + ram_check),
> + (phys_size_t)SZ_1G);
Why is it running in 1 GiB steps ?
Re: [PATCH v4] dm: uclass: don't assign aliased seq numbers
+Tom Hi, On Sat, 14 Mar 2020 at 14:33, wrote: > > On 03. 03. 20 8:47, Michael Walle wrote: > > If there are aliases for an uclass, set the base for the "dynamically" > > allocated numbers next to the highest alias. > > > > Please note, that this might lead to holes in the sequences, depending > > on the device tree. For example if there is only an alias "ethernet1", > > the next device seq number would be 2. > > > > In particular this fixes a problem with boards which are using ethernet > > aliases but also might have network add-in cards like the E1000. If the > > board is started with the add-in card and depending on the order of the > > drivers, the E1000 might occupy the first ethernet device and mess up > > all the hardware addresses, because the devices are now shifted by one. > > > > Also adapt the test cases to the new handling and add test cases > > checking the holes in the seq numbers. > > > > Signed-off-by: Michael Walle > > Reviewed-by: Alex Marginean > > Tested-by: Alex Marginean > > Acked-by: Vladimir Oltean > > Reviewed-by: Simon Glass > > --- > > changes since v3: > > - dev_read_alias_highest_id() is only available if CONFIG_OF_CONTROL is > >set. Thus added an additional condition "CONFIG_IS_ENABLED(OF_CONTROL)", > >thanks Simon. > > > > changes since v2: > > - adapt/new test cases, thanks Simon > > > > changes since v1: > > - move notice about superfluous commits from commit message to this > >section. > > - fix the comment style > > > > arch/sandbox/dts/test.dts | 4 ++-- > > drivers/core/uclass.c | 21 +++-- > > include/configs/sandbox.h | 6 +++--- > > test/dm/eth.c | 14 +++--- > > test/dm/test-fdt.c| 22 +- > > 5 files changed, 44 insertions(+), 23 deletions(-) > > > Applied to u-boot-dm/next, thanks! Sadly, after applying this was found to break rpi_3. Due to some still-pending patches mine doesn't boot anyway so I didn't notice. The tbot trace is below. The first is the new u-boot-dm/master with two rpi patches, the second is the same with just your patch added. Ethernet seems to go away. $ do-try-int.sh rpi3 HEAD Checking revision eff8ae8810da44bbbad71e617ea80abc7d7cde45 tbot starting ... ├─Parameters: │ rev= 'eff8ae8810da44bbbad71e617ea80abc7d7cde45' │ clean = True ├─Calling uboot_checkout ... │ ├─Builder: rpi_3 │ └─Done. (1.100s) ├─ └─SUCCESS (1.277s) tbot starting ... ├─Parameters: │ clean = False ├─Calling uboot_build_and_flash ... │ ├─POWERON (Raspberry Pi 3b) │ ├─Calling uboot_build ... │ │ ├─Calling uboot_checkout ... │ │ │ ├─Builder: rpi_3 │ │ │ └─Done. (0.135s) │ │ ├─Configuring build ... │ │ ├─Calling uboot_make ... │ │ │ └─Done. (12.614s) │ │ └─Done. (15.038s) │ ├─Calling uboot_flash ... │ │ ├─Calling copy ... │ │ │ └─Done. (0.003s) │ │ └─Done. (3.628s) │ ├─POWEROFF (Raspberry Pi 3b) │ └─Done. (19.594s) ├─ └─SUCCESS (19.771s) tbot starting ... ├─Calling interactive_board ... │ ├─POWERON (Raspberry Pi 3b) │ ├─Entering interactive shell (CTRL+D to exit) ... picocom v2.2 port is: /dev/ttyusb_port1 flowcontrol: none baudrate is: 115200 parity is : none databits are : 8 stopbits are : 1 escape is : C-a local echo is : no noinit is : no noreset is : no nolock is : no send_cmd is: sz -vv receive_cmd is : rz -vv -E imap is: omap is: emap is: crcrlf,delbs, Type [C-a] [C-h] to see available commands Terminal ready U-Boot 2020.04-00305-geff8ae8810 (Apr 15 2020 - 07:40:23 -0600) DRAM: 992 MiB RPI 3 Model B (0xa22082) MMC: mmc@7e202000: 0, sdhci@7e30: 1 Loading Environment from FAT... *** Warning - bad CRC, using default environment In:serial Out: vidconsole Err: vidconsole Net: No ethernet found. starting USB... Bus usb@7e98: scanning bus usb@7e98 for devices... Timeout poll on interrupt endpoint Failed to get keyboard state from device 0c40:8000 4 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Hit any key to stop autoboot: 0 U-Boot> bootp Waiting for Ethernet connection... done. BOOTP broadcast 1 DHCP client bound to address 192.168.4.50 (4 ms) *** Warning: no boot file name; using 'C0A80432.img' Using smsc95xx_eth device TFTP from server 192.168.4.1; our IP address is 192.168.4.50 Filename 'C0A80432.img'. Load address: 0x20 Loading: * Abort U-Boot> │ ├─POWEROFF (Raspberry Pi 3b) │ └─Done. (26.173s) ├─ └─SUCCESS (26.333s) ellesmere:~/u$ gp 8c324ac6faa [dm-push dd18fbdf7ff] dm: uclass: don't assign aliased seq numbers Author: Michael Walle Date: Tue Mar 3 08:47:38 2020 +0100 5 files changed, 45 insertions(+), 23 deletions(-) ellesmere:~/u$ do-try-int.sh rpi3 HEAD Checking revision dd18fbdf7ff915672fb4933a1f82a78f7b
Re: [PATCH v5 01/14] dm: core: Add function to get child count of ofnode or device
On Thu, 9 Apr 2020 at 23:46, Chunfeng Yun wrote: > > This patch add function used to get the child count of > a ofnode or a device > > Signed-off-by: Chunfeng Yun > --- > v4~v5: no changes > > v3: > 1. add non/inline function dev_get_child_count() instead of macro > suggested by Simon > > v2: > 1. move ofnode_get_child_count() into ofnode.c suggested by Simon > 2. add a new macro dev_get_child_count() > --- > drivers/core/ofnode.c | 11 +++ > drivers/core/read.c | 5 + > include/dm/ofnode.h | 8 > include/dm/read.h | 13 + > 4 files changed, 37 insertions(+) > Reviewed-by: Simon Glass
Re: Please pull u-boot/next
Hi Tom, On Sun, 12 Apr 2020 at 14:39, Tom Rini wrote: > > On Fri, Apr 10, 2020 at 02:27:38PM -0600, Simon Glass wrote: > > > Hi Tom, > > > > The following changes since commit 587e4a4296982f85b2a40fc8a704db65079e0aac: > > > > kconfig / kbuild: Re-sync with Linux 4.19 (2020-04-10 11:18:32 -0400) > > > > are available in the Git repository at: > > > > git://git.denx.de/u-boot-dm.git tags/dm-next-pull-10apr20 > > > > for you to fetch changes up to f7553b0e808f38d6303445661db062b74e865de9: > > > > dm: core: Read parent ofdata before children (2020-04-10 13:11:10 -0600) > > > > NAK. Here commit 225caaae81474c49684996f52ce12fddffd7bc69 caused > ethernet (dhcp to start with) to fail on my RPi 3. It's the alias patch. Will drop it for now. Also I pinged you about the two rpi patches. I would like to get these applied as for now I cannot run tests on rpi_3 with mainline. Regards, Simon
Re: [PATCH v3 19/23] travis/gitlab/azure: Use -W to avoid warnings check
Hi Michal,
On Wed, 15 Apr 2020 at 01:31, Michal Simek wrote:
>
> Hi Simon,
>
> st 18. 3. 2020 v 16:48 odesílatel Simon Glass napsal:
> >
> > We can use the -W flag to tell buildman to ignore warnings. Since we also
> > have -E defined, compiler warnings are promoted to errors, so they will
> > still cause a failure. But migration warnings of the form:
> >
> > = WARNING ==
> > This board does not use CONFIG_DM. CONFIG_DM will be
> > compulsory starting with the v2020.01 release.
> > Failure to update may result in board removal.
> > See doc/driver-model/migration.rst for more info.
> >
> > will now be ignored.
> >
> > Signed-off-by: Simon Glass
> > Fixes: 329f5ef51d2 (travis.yml: run buildman with option -E)
> > ---
> >
> > Changes in v3:
> > - Bring back the -E flag and add -W
> > - Rewrite the commit message
> >
> > Changes in v2:
> > - Add Fixes tag
> > - Just drop the -E flag
> > - Update travis, azure also
> >
> > .azure-pipelines.yml | 8
> > .gitlab-ci.yml | 23 +++
> > .travis.yml | 13 ++---
> > 3 files changed, 21 insertions(+), 23 deletions(-)
> >
> > diff --git a/.azure-pipelines.yml b/.azure-pipelines.yml
> > index 50d00fa899..a97a3f8b19 100644
> > --- a/.azure-pipelines.yml
> > +++ b/.azure-pipelines.yml
> > @@ -247,8 +247,8 @@ jobs:
> >cd ${WORK_DIR}
> >export UBOOT_TRAVIS_BUILD_DIR=/tmp/${TEST_PY_BD};
> >ret=0;
> > - tools/buildman/buildman -o ${UBOOT_TRAVIS_BUILD_DIR} -w -E
> > --board ${TEST_PY_BD} ${OVERRIDE} || ret=$?;
> > - if [[ $ret -ne 0 && $ret -ne 129 ]]; then
> > + tools/buildman/buildman -o ${UBOOT_TRAVIS_BUILD_DIR} -w -E -W
> > --board ${TEST_PY_BD} ${OVERRIDE} || ret=$?;
> > + if [[ $ret -ne 0 ]]; then
> >tools/buildman/buildman -o ${UBOOT_TRAVIS_BUILD_DIR} -w -se
> > --board ${TEST_PY_BD};
> >exit $ret;
> >fi
> > @@ -396,8 +396,8 @@ jobs:
> >cat << "EOF" >> build.sh
> >if [[ "${BUILDMAN}" != "" ]]; then
> >ret=0;
> > - tools/buildman/buildman -o /tmp -P -E ${BUILDMAN}
> > ${OVERRIDE} || ret=$?;
> > - if [[ $ret -ne 0 && $ret -ne 129 ]]; then
> > + tools/buildman/buildman -o /tmp -P -W ${BUILDMAN}
> > ${OVERRIDE} || ret=$?;
> > + if [[ $ret -ne 0 ]]; then
> >tools/buildman/buildman -o /tmp -seP ${BUILDMAN};
> >exit $ret;
> >fi;
> > diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
> > index 48b90b2ba3..501e3ff3ab 100644
> > --- a/.gitlab-ci.yml
> > +++ b/.gitlab-ci.yml
> > @@ -27,13 +27,12 @@ stages:
> >after_script:
> > - rm -rf /tmp/uboot-test-hooks /tmp/venv
> >script:
> > -# From buildman, exit code 129 means warnings only. If we've been
> > asked to
> > -# use clang only do one configuration.
> > +# If we've been asked to use clang only do one configuration.
> > - export UBOOT_TRAVIS_BUILD_DIR=/tmp/${TEST_PY_BD}
> > - ret=0;
> > - tools/buildman/buildman -o ${UBOOT_TRAVIS_BUILD_DIR} -w -E
> > + tools/buildman/buildman -o ${UBOOT_TRAVIS_BUILD_DIR} -w -E -W
> > --board ${TEST_PY_BD} ${OVERRIDE} || ret=$?;
> > - if [[ $ret -ne 0 && $ret -ne 129 ]]; then
> > + if [[ $ret -ne 0 ]]; then
> > tools/buildman/buildman -o ${UBOOT_TRAVIS_BUILD_DIR} -w -se
> > --board ${TEST_PY_BD};
> > exit $ret;
> > @@ -57,8 +56,8 @@ build all 32bit ARM platforms:
> >stage: world build
> >script:
> > - ret=0;
> > - ./tools/buildman/buildman -o /tmp -P -E arm -x aarch64 || ret=$?;
> > - if [[ $ret -ne 0 && $ret -ne 129 ]]; then
> > + ./tools/buildman/buildman -o /tmp -P -E -W arm -x aarch64 || ret=$?;
> > + if [[ $ret -ne 0 ]]; then
> > ./tools/buildman/buildman -o /tmp -seP;
> > exit $ret;
> >fi;
> > @@ -71,8 +70,8 @@ build all 64bit ARM platforms:
> > - . /tmp/venv/bin/activate
> > - pip install pyelftools
> > - ret=0;
> > - ./tools/buildman/buildman -o /tmp -P -E aarch64 || ret=$?;
> > - if [[ $ret -ne 0 && $ret -ne 129 ]]; then
> > + ./tools/buildman/buildman -o /tmp -P -E -W aarch64 || ret=$?;
> > + if [[ $ret -ne 0 ]]; then
> > ./tools/buildman/buildman -o /tmp -seP;
> > exit $ret;
> >fi;
> > @@ -82,8 +81,8 @@ build all PowerPC platforms:
> >stage: world build
> >script:
> > - ret=0;
> > - ./tools/buildman/buildman -o /tmp -P -E powerpc || ret=$?;
> > - if [[ $ret -ne 0 && $ret -ne 129 ]]; then
> > + ./tools/buildman/buildman -o /tmp -P -E -W powerpc || ret=$?;
> > + if [[ $ret -ne 0 ]]; then
> > ./tools/buildman/buildman -o /tmp -seP;
> > exit $ret;
> >fi;
> > @@ -93,8 +92,8 @@ build all other platforms:
> >stage: world build
> >script:
> >
Re: [PATCH v5 04/14] test: dm: phy: add a test item for the phy_bulk API
On Thu, 9 Apr 2020 at 23:46, Chunfeng Yun wrote: > > Add a test item for the phy_bulk API > > Signed-off-by: Chunfeng Yun > --- > v5: no changes > > v4: new patch > --- > arch/sandbox/dts/test.dts | 11 +++ > test/dm/phy.c | 29 + > 2 files changed, 40 insertions(+) > Reviewed-by: Simon Glass
Antwort: Re: Re: [PATCH v3 13/29] dts: Add a binding for hid-over-i2c
Hi Andy, -"Andy Shevchenko" schrieb: - > Betreff: Re: Re: [PATCH v3 13/29] dts: Add a binding for hid-over-i2c > > On Wed, Apr 8, 2020 at 11:40 PM Andy Shevchenko > wrote: > > On Wed, Apr 8, 2020 at 10:39 PM Wolfgang Wallner > > wrote: > > > > On Tue, Apr 07, 2020 at 08:58:13PM -0600, Simon Glass wrote: > > > > > On Tue, 31 Mar 2020 at 13:25, Wolfgang Wallner > > > > > wrote: > > > > > > >An: u-boot@lists.denx.de > > > > > > >Von: "Simon Glass" > > > > > > >Datum: 31.03.2020 01:14 > > > > > > >Kopie: "Andy Shevchenko" , > > > > > > >"Wolfgang Wallner" , "Leif > > > > > > >Lindholm" , "Simon Glass" > > > > > > >Betreff: [PATCH v3 14/29] acpi: Add a binding for ACPI settings in > > > > > > >the device tree > > > > > > > > > > The _DSD-method for "PRP0001"-devices in ACPI allows to use > > > > > > Devicetree > > > > > > properties inside ACPI, especially it allows to re-use Devicetree's > > > > > > "compatible"-property. But this is for a different use case (using > > > > > > Devicetree > > > > > > properties inside ACPI, not add ACPI properties in Devicetree). > > > > > > > > Before we are going further with this here is a BIG CAVEAT. > > > > > > > > PRP0001 MUST NOT be used in production devices. > > > > > > > > This has been derived solely for debugging / pre-production testing / > > > > etc > > > > purposes. The real devices must have an official ACPI _HID. > > > > > > Thanks for pointing this out! I was not aware of this. > > > I have tried to understand how the PRP0001 is meant to be used, but could > > > not > > > find sufficient documentation. The best document I could find is > > > Documentation/firmware-guide/acpi/enumeration.rst in the Linux kernel, and > > > as far as I can tell the constraint that you mention is also not described > > > there. > > > > > > Do you know any other resources regarding PRP0001, e.g. some kind of > > > speficiation? > > > > I guess the best one is to ask somebody from UEFI Forum / ASWG. PRP is > > a PNP ID for UEFI Forum. > > Basically last message in [3] from Rafael mentions his view on > PRP0001. I guess there is still no document, although as I noticed the > PRP prefix become official in a mean time. Thanks for the references. I have read them carefully, especially the thread in [3]. My understanding up to now was based on presentations by David Woodhouse, so it matches with his viewpoint in the thread at [3]. And as far as I can tell Rafael Wysocki agrees with him in this thread. What I could not find in either of the references is that PRP0001 is only for debugging, I only know about this constraint from your mail. Could you point me to any source for this? > > > If PRP0001 is only for debugging, then I must also have misunderstood the > > > Linux "device-property" API (define in include/linux/property.h). > > > > Not exactly. > > > > > There are some presentations available on the internet, e.g. [1], that I > > > understand like PRP0001 + "device-property" API provide a way do access > > > data > > > from either Devicetree or ACPI, depending on what kind of platform you > > > are on. > > > > No, these are not hard linked to each other (the relation is that > > PRP0001 is a way to enumerate devices, which don't have dedicated ACPI > > _HID, by using compatible property [1]). The _DSD per se (i.o.w. > > device properties implementation in ACPI) is a different story [2]. > > > > And I put [3] here, interesting to read. However, at that time I was > > quite far from this topic. > > > > [1]: > > https://www.kernel.org/doc/html/latest/firmware-guide/acpi/enumeration.html#device-tree-namespace-link-device-id > > [2]: > > https://uefi.org/sites/default/files/resources/_DSD-implementation-guide-toplevel-1_2-3.htm. > > [3]: https://patchwork.kernel.org/patch/7004241/ > > > > > [1] > > > https://elinux.org/images/2/2d/Device_tree_acpi_compatibility-david_woodhouse-kernel_recipes_2015.pdf > > > > -- > > With Best Regards, > > Andy Shevchenko regards, Wolfgang PS: I only realized now that I had mixed up the email-subject in my first reply and now the complete thread is under the wrong topic. Sorry for that.
[PATCH] ARM: imx6: DHCOM i.MX6 PDK: Convert to DM_ETH
Use DM_ETH instead of legacy networking.
Signed-off-by: Harald Seiler
---
Notes:
I am unsure whether I converted 'enough' of the board_eth_init()
function to DM. I think the reset GPIO in particular could be handled
by the DM driver if I add the following to the device-tree (did not try
it yet):
phy-reset-gpios = <&gpio5 0 GPIO_ACTIVE_LOW>;
phy-reset-duration = <1>;
phy-reset-post-delay = <10>;
Is it preferred to change the device-tree here or should I keep the reset
from board_init() like I have it now? If I should use the dt, is there
a similar way for dealing with VIO?
board/dhelectronics/dh_imx6/dh_imx6.c | 26 +-
configs/dh_imx6_defconfig | 2 ++
2 files changed, 7 insertions(+), 21 deletions(-)
diff --git a/board/dhelectronics/dh_imx6/dh_imx6.c
b/board/dhelectronics/dh_imx6/dh_imx6.c
index 33ce7e8ff115..aafb9f1b341f 100644
--- a/board/dhelectronics/dh_imx6/dh_imx6.c
+++ b/board/dhelectronics/dh_imx6/dh_imx6.c
@@ -28,10 +28,7 @@
#include
#include
#include
-#include
#include
-#include
-#include
#include
#include
@@ -80,31 +77,14 @@ static int setup_fec_clock(void)
return enable_fec_anatop_clock(0, ENET_50MHZ);
}
-int board_eth_init(bd_t *bis)
+static void setup_fec(void)
{
- uint32_t base = IMX_FEC_BASE;
- struct mii_dev *bus = NULL;
- struct phy_device *phydev = NULL;
-
gpio_request(IMX_GPIO_NR(5, 0), "PHY-reset");
gpio_request(IMX_GPIO_NR(1, 7), "VIO");
setup_fec_clock();
eth_phy_reset();
-
- bus = fec_get_miibus(base, -1);
- if (!bus)
- return -EINVAL;
-
- /* Scan PHY 0 */
- phydev = phy_find_by_mask(bus, 0xf, PHY_INTERFACE_MODE_RGMII);
- if (!phydev) {
- printf("Ethernet PHY not found!\n");
- return -EINVAL;
- }
-
- return fec_probe(bis, -1, base, bus, phydev);
}
#endif
@@ -190,6 +170,10 @@ int board_init(void)
setup_dhcom_mac_from_fuse();
+#ifdef CONFIG_FEC_MXC
+ setup_fec();
+#endif
+
return 0;
}
diff --git a/configs/dh_imx6_defconfig b/configs/dh_imx6_defconfig
index cbfc3c394e7d..40de1d82031b 100644
--- a/configs/dh_imx6_defconfig
+++ b/configs/dh_imx6_defconfig
@@ -74,6 +74,8 @@ CONFIG_SPI_FLASH_MTD=y
CONFIG_PHYLIB=y
CONFIG_PHY_MICREL=y
CONFIG_PHY_MICREL_KSZ90X1=y
+CONFIG_DM_ETH=y
+CONFIG_DM_MDIO=y
CONFIG_FEC_MXC=y
CONFIG_MII=y
CONFIG_PINCTRL=y
--
2.26.0
Re: [PATCH] ARM: imx6: DHCOM i.MX6 PDK: Convert to DM_ETH
On 4/15/20 4:01 PM, Harald Seiler wrote:
> Use DM_ETH instead of legacy networking.
>
> Signed-off-by: Harald Seiler
> ---
>
> Notes:
> I am unsure whether I converted 'enough' of the board_eth_init()
> function to DM. I think the reset GPIO in particular could be handled
> by the DM driver if I add the following to the device-tree (did not try
> it yet):
>
> phy-reset-gpios = <&gpio5 0 GPIO_ACTIVE_LOW>;
> phy-reset-duration = <1>;
> phy-reset-post-delay = <10>;
That's how PHY reset should be done, yes.
> Is it preferred to change the device-tree here or should I keep the reset
> from board_init() like I have it now? If I should use the dt, is there
> a similar way for dealing with VIO?
VIO is likely a fixed regulator-always-on regulator for now.
> board/dhelectronics/dh_imx6/dh_imx6.c | 26 +-
> configs/dh_imx6_defconfig | 2 ++
> 2 files changed, 7 insertions(+), 21 deletions(-)
>
> diff --git a/board/dhelectronics/dh_imx6/dh_imx6.c
> b/board/dhelectronics/dh_imx6/dh_imx6.c
> index 33ce7e8ff115..aafb9f1b341f 100644
> --- a/board/dhelectronics/dh_imx6/dh_imx6.c
> +++ b/board/dhelectronics/dh_imx6/dh_imx6.c
> @@ -28,10 +28,7 @@
> #include
> #include
> #include
> -#include
> #include
> -#include
> -#include
> #include
> #include
>
> @@ -80,31 +77,14 @@ static int setup_fec_clock(void)
> return enable_fec_anatop_clock(0, ENET_50MHZ);
> }
>
> -int board_eth_init(bd_t *bis)
> +static void setup_fec(void)
> {
> - uint32_t base = IMX_FEC_BASE;
> - struct mii_dev *bus = NULL;
> - struct phy_device *phydev = NULL;
> -
> gpio_request(IMX_GPIO_NR(5, 0), "PHY-reset");
> gpio_request(IMX_GPIO_NR(1, 7), "VIO");
>
> setup_fec_clock();
>
> eth_phy_reset();
> -
> - bus = fec_get_miibus(base, -1);
> - if (!bus)
> - return -EINVAL;
> -
> - /* Scan PHY 0 */
> - phydev = phy_find_by_mask(bus, 0xf, PHY_INTERFACE_MODE_RGMII);
> - if (!phydev) {
> - printf("Ethernet PHY not found!\n");
> - return -EINVAL;
> - }
> -
> - return fec_probe(bis, -1, base, bus, phydev);
> }
> #endif
>
> @@ -190,6 +170,10 @@ int board_init(void)
>
> setup_dhcom_mac_from_fuse();
>
> +#ifdef CONFIG_FEC_MXC
You probably want to init the clock either way, not only if the FEC is
enabled, so drop the ifdef.
> + setup_fec();
> +#endif
[...]
Re: [PATCH v1 3/3] x86: acpi: Let OS know that console already had been initialized
On Thu, Feb 27, 2020 at 11:22 PM Andy Shevchenko
wrote:
>
> SPCR has no clue if the UART base clock speed is different to
> the default one. However, the SPCR 1.04 defines baud rate 0 as
> a preconfigured state of UART and OS is supposed not to touch
> the configuration of the serial device.
>
> Linux kernel supports that starting from v5.0, see commit
> b413b1abeb21 ("ACPI: SPCR: Consider baud rate 0 as preconfigured state")
> for the details.
>
> Signed-off-by: Andy Shevchenko
> ---
> arch/x86/lib/acpi_table.c | 9 +
> 1 file changed, 9 insertions(+)
>
Reviewed-by: Bin Meng
Re: [PATCH v4] mmc: zynq: parse dt when probing
Hi,
On 15. 04. 20 14:05, Benedikt Grassl wrote:
> Hi Michal,
>
> I just tried to check if the read performance acutally increased when
> using an 8-bit data bus. As a quick test, I use the fatload command to
> read a chunk of 1 GByte from an eMMC flash (generated with dd from
> Linux). However, I don't see any difference at all:
>
> mmc info
> Device: mmc@ff16
> Manufacturer ID: 9d
> OEM: 101
> Name: IS016
> Bus Speed: 2
> Mode: HS200 (200MHz)
> Rd Block Len: 512
> MMC version 5.0
> High Capacity: Yes
> Capacity: 14.6 GiB
> Bus Width: 4-bit
> (...)
>
> fatload mmc 0 ${loadimage} test.img
> 1070579712 bytes read in 70458 ms (14.5 MiB/s)
>
> With an 8-bit data bus:
>
> mmcinfo
> Device: mmc@ff16
> Manufacturer ID: 9d
> OEM: 101
> Name: IS016
> Bus Speed: 2
> Mode: HS200 (200MHz)
> Rd Block Len: 512
> MMC version 5.0
> High Capacity: Yes
> Capacity: 14.6 GiB
> Bus Width: 8-bit
> (...)
>
> fatload mmc 0 ${loadimage} test.img
> 1070579712 bytes read in 70551 ms (14.5 MiB/s)
>
> I wonder if the fatload command is the bottleneck here? Unfortunately
> I'm working from home right now and don't have an oscilloscope at hand
> to verify in hardware. Do you have any inputs on that?
you can do raw write to avoid fat FS which is not optimal.
Thanks,
Michal
Re: [PATCH v1 2/3] serial: ns16550: Provide UART base clock speed in ->getinfo()
On Fri, Feb 28, 2020 at 7:41 AM Simon Glass wrote: > > On Thu, 27 Feb 2020 at 07:22, Andy Shevchenko > wrote: > > > > Some callers may need the UART base clock speed value. > > Provide it in the ->getinfo() callback. > > > > Signed-off-by: Andy Shevchenko > > --- > > drivers/serial/ns16550.c | 1 + > > 1 file changed, 1 insertion(+) > > Reviewed-by: Simon Glass > > > > > diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c > > index 1fcbc35015..386b5e04c8 100644 > > --- a/drivers/serial/ns16550.c > > +++ b/drivers/serial/ns16550.c > > @@ -476,6 +476,7 @@ static int ns16550_serial_getinfo(struct udevice *dev, > > info->reg_width = plat->reg_width; > > info->reg_shift = plat->reg_shift; > > info->reg_offset = plat->reg_offset; > > + info->clock = plat->clock; > > blank line before return I can fix this when applying. > > > return 0; > > } Reviewed-by: Bin Meng
Re: [PATCH v1 1/3] dm: serial: Add clock member to struct serial_device_info
On Fri, Feb 28, 2020 at 7:41 AM Simon Glass wrote: > > On Thu, 27 Feb 2020 at 07:22, Andy Shevchenko > wrote: > > > > Some callers of serial_getinfo() would like to know the UART base > > clock speed in order to make decision what to pass to OS in some > > cases. In particular, ACPI SPCR table expects only certain base > > clock speed and thus we have to act accordingly. > > > > Signed-off-by: Andy Shevchenko > > --- > > drivers/serial/sandbox.c | 1 + > > include/serial.h | 3 +++ > > test/dm/serial.c | 1 + > > 3 files changed, 5 insertions(+) > > Reviewed-by: Simon Glass Reviewed-by: Bin Meng
Re: Re: Re: [PATCH v3 13/29] dts: Add a binding for hid-over-i2c
On Wed, Apr 15, 2020 at 5:00 PM Wolfgang Wallner wrote: > -"Andy Shevchenko" schrieb: - > > Betreff: Re: Re: [PATCH v3 13/29] dts: Add a binding for hid-over-i2c > > > > On Wed, Apr 8, 2020 at 11:40 PM Andy Shevchenko > > wrote: > > > On Wed, Apr 8, 2020 at 10:39 PM Wolfgang Wallner > > > wrote: > > > > > On Tue, Apr 07, 2020 at 08:58:13PM -0600, Simon Glass wrote: > > > > > > On Tue, 31 Mar 2020 at 13:25, Wolfgang Wallner > > > > > > wrote: > > > > > > > >An: u-boot@lists.denx.de > > > > > > > >Von: "Simon Glass" > > > > > > > >Datum: 31.03.2020 01:14 > > > > > > > >Kopie: "Andy Shevchenko" , > > > > > > > >"Wolfgang Wallner" , "Leif > > > > > > > >Lindholm" , "Simon Glass" > > > > > > > >Betreff: [PATCH v3 14/29] acpi: Add a binding for ACPI settings > > > > > > > >in > > > > > > > >the device tree > > > > > > > > > > > > The _DSD-method for "PRP0001"-devices in ACPI allows to use > > > > > > > Devicetree > > > > > > > properties inside ACPI, especially it allows to re-use > > > > > > > Devicetree's > > > > > > > "compatible"-property. But this is for a different use case > > > > > > > (using Devicetree > > > > > > > properties inside ACPI, not add ACPI properties in Devicetree). > > > > > > > > > > Before we are going further with this here is a BIG CAVEAT. > > > > > > > > > > PRP0001 MUST NOT be used in production devices. > > > > > > > > > > This has been derived solely for debugging / pre-production testing / > > > > > etc > > > > > purposes. The real devices must have an official ACPI _HID. > > > > > > > > Thanks for pointing this out! I was not aware of this. > > > > I have tried to understand how the PRP0001 is meant to be used, but > > > > could not > > > > find sufficient documentation. The best document I could find is > > > > Documentation/firmware-guide/acpi/enumeration.rst in the Linux kernel, > > > > and > > > > as far as I can tell the constraint that you mention is also not > > > > described > > > > there. > > > > > > > > Do you know any other resources regarding PRP0001, e.g. some kind of > > > > speficiation? > > > > > > I guess the best one is to ask somebody from UEFI Forum / ASWG. PRP is > > > a PNP ID for UEFI Forum. > > > > Basically last message in [3] from Rafael mentions his view on > > PRP0001. I guess there is still no document, although as I noticed the > > PRP prefix become official in a mean time. > > Thanks for the references. I have read them carefully, especially the thread > in [3]. > > My understanding up to now was based on presentations by David Woodhouse, > so it matches with his viewpoint in the thread at [3]. And as far as I can > tell Rafael Wysocki agrees with him in this thread. > > What I could not find in either of the references is that PRP0001 is only > for debugging, I only know about this constraint from your mail. Could you > point me to any source for this? >From [3], Rafael said: "Let alone the fact that PRP0001 is actually quite useful at the prototyping stage when it is premature to allocate a new device ID just yet. Taking that to the extreme, if someone whittles a board in his or her garage and wants to use it to drive their homemade grass watering system, having to invent a new device ID and put it into the existing driver that otherwise doesn't require any modifications is ... you know what I mean." It implies that the process should have included the allocation of an official ACPI ID. You always can ask ASWG for the clarification. Maybe I learn something new about PRP0001 :-) > > > > If PRP0001 is only for debugging, then I must also have misunderstood > > > > the > > > > Linux "device-property" API (define in include/linux/property.h). > > > > > > Not exactly. > > > > > > > There are some presentations available on the internet, e.g. [1], that I > > > > understand like PRP0001 + "device-property" API provide a way do access > > > > data > > > > from either Devicetree or ACPI, depending on what kind of platform you > > > > are on. > > > > > > No, these are not hard linked to each other (the relation is that > > > PRP0001 is a way to enumerate devices, which don't have dedicated ACPI > > > _HID, by using compatible property [1]). The _DSD per se (i.o.w. > > > device properties implementation in ACPI) is a different story [2]. > > > > > > And I put [3] here, interesting to read. However, at that time I was > > > quite far from this topic. > > > > > > [1]: > > > https://www.kernel.org/doc/html/latest/firmware-guide/acpi/enumeration.html#device-tree-namespace-link-device-id > > > [2]: > > > https://uefi.org/sites/default/files/resources/_DSD-implementation-guide-toplevel-1_2-3.htm. > > > [3]: https://patchwork.kernel.org/patch/7004241/ > > > > > > > [1] > > > > https://elinux.org/images/2/2d/Device_tree_acpi_compatibility-david_woodhouse-kernel_recipes_2015.pdf -- With Best Regards, Andy Shevchenko
Re: [PATCH v5 00/29] dm: Add programmatic generation of ACPI tables (part A)
Hi Bin, On Wed, 8 Apr 2020 at 16:57, Simon Glass wrote: > > This is split from the original series in an attempt to get things applied > in chunks. > > The first 20 or so patches here have been reviewed and the changes here > incorporate those comments. > > Changes in v5: > - Tweak unused naming and comments > - Capitalise ACPI_OPS_PTR since it includes a comma > - Capitalise ACPI_OPS_PTR since it includes a comma > - Update commit message to mention dropping the #ifdef CONFIG_X86 > - Mess with the table ordering a little more > - Add #ifndef CONFIG_SANDBOX to maintain bisectability without merging patches > - Drop bisectability changes > > Changes in v4: > - Fix indentation of unused > - Calculate the padding > - Put 'interrupts-extended' property on one line > - Rename acpi-probed to linux,probed > - Note that linux,probed is an out-of-tree feature > - Move ACPI makefile line outside the ifdef CONFIG_SPL_BUILD > - Add a comment about the MADT table version > - Add SPCR > - Update comment to include tables defined or reserved by ACPI > - Drop ASL_REVISION > - Separate out the log newline > - Update comment in acpi_inc_align() to show the alignment > - Put back cast on table_compute_checksum() > - Rename list_fact() to list_fadt() > - Add a comment to dump_hdr() > > Changes in v3: > Drop acpi,name in example > - Fix indenting error mentioned by Andy Shevchenko > - Fix stray #endif > - Drop 'Intel' from 'Intel ACPI' > - Reword commit message to drop the bit about ACPI being complicated > - Compute ACPI_NAME_MAX from ACPI_NAME_LEN > - Rename acpi_return_name() to acpi_copy_name() > - Use strncpy() instead of strcpy() in acpi_copy_name() > - Split out hid-over-i2c into its own patch > - Drop mention of PRIC > - Rename acpi,desc to acpi,ddn > - Correct description of acpi,probed > - Drop hid-descr-addr > - Just add the device.txt binding file in this patch > - Change the example to ELAN > - Add a pointer to information about acpi,compatible > - Add new patch to move acpi_s3.h to include/acpi/ > - Update commit message to say that we move most of its contents > - Move acpi_table.h to include/acpi > - Add forward declarations for the functions > - Fix file comment for acpi_table.c > - Fix a few typos > - Make use of BIT() > - Fix DMA_ typo > - Add missing error check in acpi_create_dmar() > - Drop duplicate assert > - Add new patch to add hexdump.h to the unit test header > - Rename acpi_align_large() to acpi_align64() > - Fix 'RSDP' typo > - Fix 'XDST' typo > - Move acpi_align_large() out of dm_test_acpi_setup_base_tables() > - Beef up the comment explaining how the unaligned address is used > > Changes in v2: > - Don't bracket the definitions with DM_SPI > - Add trailing commas to enum > - Drop the other comment change since it is already applied > - Drop the Chrome OS pieces > - Rename the 'coreboot' console to 'U-Boot' > - Move LOGC_ACPI definition to this patch > - Fix definition of HID > - Infer hid-over-i2c CID value > - Add the hid-over-i2c binding document > - Add in the acpi_table.h header file to this patch > - Move the sandbox acpi_table.h header file to an earlier patch > - Use #defines for MADT and MCFG version numbers > - Drop two unnecessary __packed > - Move __packed to after struct > - Drop definition of ACPI_TABLE_CREATOR > - Make _acpi_write_dev_tables() static and switch argument order > - Generalise the ACPI function recursion with acpi_recurse_method() > > Simon Glass (29): > cpu: Support querying the address width > spi: Add SPI mode enums > tpm: cr50: Release locality on exit > tpm: cr50: Add a comment for cr50_priv > tpm: cr50: Use the correct GPIO binding > tpm: Don't cleanup unless an error happens > dm: pci: Allow disabling auto-config for a device > x86: Correct wording of coreboot source code > x86: apl: Move p2sb ofdata reading to the correct method > pci: Adjust dm_pci_read_bar32() to return errors correctly > x86: apl: Add Global NVS table header > dm: core: Add basic ACPI support > dts: Add a binding for hid-over-i2c > acpi: Add a binding for ACPI settings in the device tree > acpi: Add a simple sandbox test > x86: Move acpi_s3.h to include/acpi/ > x86: Move acpi_table header to main include/ directory > acpi: Add an __ACPI__ preprocessor symbol > acpi: Add a central location for table version numbers > acpi: Add support for DMAR > test: Add hexdump.h to the unit test header > acpi: Add a method to write tables for a device > acpi: Convert part of acpi_table to use acpi_ctx > x86: Allow devices to write ACPI tables > acpi: Drop code for missing XSDT from acpi_write_rsdp() > acpi: Move acpi_add_table() to generic code > acpi: Put table-setup code in its own function > acpi: Move the xsdt pointer to acpi_ctx > acpi: Add an acpi command > > arch/sandbox/dts/test.dts | 8 + > arch/sandbox/include/asm/acpi_table.h | 9 + > arch/sandbox/include/asm/global_data.h| 1 + > arch/x86/cpu
Re: [PATCH v1 3/3] x86: acpi: Let OS know that console already had been initialized
On Wed, Apr 15, 2020 at 10:20 PM Bin Meng wrote:
>
> On Thu, Feb 27, 2020 at 11:22 PM Andy Shevchenko
> wrote:
> >
> > SPCR has no clue if the UART base clock speed is different to
> > the default one. However, the SPCR 1.04 defines baud rate 0 as
> > a preconfigured state of UART and OS is supposed not to touch
> > the configuration of the serial device.
> >
> > Linux kernel supports that starting from v5.0, see commit
> > b413b1abeb21 ("ACPI: SPCR: Consider baud rate 0 as preconfigured state")
> > for the details.
> >
> > Signed-off-by: Andy Shevchenko
> > ---
> > arch/x86/lib/acpi_table.c | 9 +
> > 1 file changed, 9 insertions(+)
> >
>
> Reviewed-by: Bin Meng
applied to u-boot-x86, thanks!
Re: [PATCH v1 2/3] serial: ns16550: Provide UART base clock speed in ->getinfo()
On Wed, Apr 15, 2020 at 10:19 PM Bin Meng wrote: > > On Fri, Feb 28, 2020 at 7:41 AM Simon Glass wrote: > > > > On Thu, 27 Feb 2020 at 07:22, Andy Shevchenko > > wrote: > > > > > > Some callers may need the UART base clock speed value. > > > Provide it in the ->getinfo() callback. > > > > > > Signed-off-by: Andy Shevchenko > > > --- > > > drivers/serial/ns16550.c | 1 + > > > 1 file changed, 1 insertion(+) > > > > Reviewed-by: Simon Glass > > > > > > > > diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c > > > index 1fcbc35015..386b5e04c8 100644 > > > --- a/drivers/serial/ns16550.c > > > +++ b/drivers/serial/ns16550.c > > > @@ -476,6 +476,7 @@ static int ns16550_serial_getinfo(struct udevice *dev, > > > info->reg_width = plat->reg_width; > > > info->reg_shift = plat->reg_shift; > > > info->reg_offset = plat->reg_offset; > > > + info->clock = plat->clock; > > > > blank line before return > > I can fix this when applying. > > > > > > return 0; > > > } > > Reviewed-by: Bin Meng applied to u-boot-x86, thanks!
Re: [PATCH v1 1/3] dm: serial: Add clock member to struct serial_device_info
On Wed, Apr 15, 2020 at 10:19 PM Bin Meng wrote: > > On Fri, Feb 28, 2020 at 7:41 AM Simon Glass wrote: > > > > On Thu, 27 Feb 2020 at 07:22, Andy Shevchenko > > wrote: > > > > > > Some callers of serial_getinfo() would like to know the UART base > > > clock speed in order to make decision what to pass to OS in some > > > cases. In particular, ACPI SPCR table expects only certain base > > > clock speed and thus we have to act accordingly. > > > > > > Signed-off-by: Andy Shevchenko > > > --- > > > drivers/serial/sandbox.c | 1 + > > > include/serial.h | 3 +++ > > > test/dm/serial.c | 1 + > > > 3 files changed, 5 insertions(+) > > > > Reviewed-by: Simon Glass > > Reviewed-by: Bin Meng applied to u-boot-x86, thanks!
Re: [PATCH v6 12/29] dm: core: Add basic ACPI support
Hi Simon, On Fri, Apr 10, 2020 at 3:36 AM Simon Glass wrote: > > On Thu, 9 Apr 2020 at 11:40, Andy Shevchenko > wrote: > > > > On Thu, Apr 09, 2020 at 10:27:38AM -0600, Simon Glass wrote: > > > ACPI (Advanced Configuration and Power Interface) is a standard for > > > specifying information about a platform. It is a little like device > > > tree but the bindings are part of the specification and it supports an > > > interpreted bytecode language. > > > > > > Driver model does not use ACPI for U-Boot's configuration, but it is > > > convenient to have it support generation of ACPI tables for passing to > > > Linux, etc. > > > > > > As a starting point, add an optional set of ACPI operations to each > > > device. Initially only a single operation is available, to obtain the > > > ACPI name for the device. More operations are added later. > > > > > > Enable ACPI for sandbox to ensure build coverage and so that we can add > > > tests. > > > > > > > Both looks good to me now, thanks! > > > > > Reviewed-by: Bin Meng > > > Reviewed-by: Wolfgang Wallner > > > Signed-off-by: Simon Glass > > > --- > > > > > > Changes in v6: > > > - Use ACPI_NAME_LEN in acpi_copy_name since we add the nul anyway > > > > > > Changes in v5: > > > - Capitalise ACPI_OPS_PTR since it includes a comma > > > > > > Changes in v4: None > > > Changes in v3: > > > - Drop 'Intel' from 'Intel ACPI' > > > - Reword commit message to drop the bit about ACPI being complicated > > > - Compute ACPI_NAME_MAX from ACPI_NAME_LEN > > > - Rename acpi_return_name() to acpi_copy_name() > > > - Use strncpy() instead of strcpy() in acpi_copy_name() > > > > > > Changes in v2: > > > - Move LOGC_ACPI definition to this patch > > > > > > configs/tools-only_defconfig | 1 + > > > drivers/core/Kconfig | 9 + > > > drivers/core/Makefile| 1 + > > > drivers/core/acpi.c | 33 > > > include/dm/acpi.h| 73 > > > include/dm/device.h | 5 +++ > > > include/log.h| 2 + > > > 7 files changed, 124 insertions(+) > > > create mode 100644 drivers/core/acpi.c > > > create mode 100644 include/dm/acpi.h > > Andy let me add your tag. > > Reviewed-by: Andy Shevchenko Do you know what happened to this series? I only see 2 patches in this series showing up on the patchwork. http://patchwork.ozlabs.org/user/todo/uboot/?series=169449 Regards, Bin
Re: [PATCH v5 00/29] dm: Add programmatic generation of ACPI tables (part A)
Hi Simon, On Wed, Apr 15, 2020 at 10:25 PM Simon Glass wrote: > > Hi Bin, > > On Wed, 8 Apr 2020 at 16:57, Simon Glass wrote: > > > > This is split from the original series in an attempt to get things applied > > in chunks. > > > > The first 20 or so patches here have been reviewed and the changes here > > incorporate those comments. > > > > Changes in v5: > > - Tweak unused naming and comments > > - Capitalise ACPI_OPS_PTR since it includes a comma > > - Capitalise ACPI_OPS_PTR since it includes a comma > > - Update commit message to mention dropping the #ifdef CONFIG_X86 > > - Mess with the table ordering a little more > > - Add #ifndef CONFIG_SANDBOX to maintain bisectability without merging > > patches > > - Drop bisectability changes > > > > Changes in v4: > > - Fix indentation of unused > > - Calculate the padding > > - Put 'interrupts-extended' property on one line > > - Rename acpi-probed to linux,probed > > - Note that linux,probed is an out-of-tree feature > > - Move ACPI makefile line outside the ifdef CONFIG_SPL_BUILD > > - Add a comment about the MADT table version > > - Add SPCR > > - Update comment to include tables defined or reserved by ACPI > > - Drop ASL_REVISION > > - Separate out the log newline > > - Update comment in acpi_inc_align() to show the alignment > > - Put back cast on table_compute_checksum() > > - Rename list_fact() to list_fadt() > > - Add a comment to dump_hdr() > > > > Changes in v3: > > Drop acpi,name in example > > - Fix indenting error mentioned by Andy Shevchenko > > - Fix stray #endif > > - Drop 'Intel' from 'Intel ACPI' > > - Reword commit message to drop the bit about ACPI being complicated > > - Compute ACPI_NAME_MAX from ACPI_NAME_LEN > > - Rename acpi_return_name() to acpi_copy_name() > > - Use strncpy() instead of strcpy() in acpi_copy_name() > > - Split out hid-over-i2c into its own patch > > - Drop mention of PRIC > > - Rename acpi,desc to acpi,ddn > > - Correct description of acpi,probed > > - Drop hid-descr-addr > > - Just add the device.txt binding file in this patch > > - Change the example to ELAN > > - Add a pointer to information about acpi,compatible > > - Add new patch to move acpi_s3.h to include/acpi/ > > - Update commit message to say that we move most of its contents > > - Move acpi_table.h to include/acpi > > - Add forward declarations for the functions > > - Fix file comment for acpi_table.c > > - Fix a few typos > > - Make use of BIT() > > - Fix DMA_ typo > > - Add missing error check in acpi_create_dmar() > > - Drop duplicate assert > > - Add new patch to add hexdump.h to the unit test header > > - Rename acpi_align_large() to acpi_align64() > > - Fix 'RSDP' typo > > - Fix 'XDST' typo > > - Move acpi_align_large() out of dm_test_acpi_setup_base_tables() > > - Beef up the comment explaining how the unaligned address is used > > > > Changes in v2: > > - Don't bracket the definitions with DM_SPI > > - Add trailing commas to enum > > - Drop the other comment change since it is already applied > > - Drop the Chrome OS pieces > > - Rename the 'coreboot' console to 'U-Boot' > > - Move LOGC_ACPI definition to this patch > > - Fix definition of HID > > - Infer hid-over-i2c CID value > > - Add the hid-over-i2c binding document > > - Add in the acpi_table.h header file to this patch > > - Move the sandbox acpi_table.h header file to an earlier patch > > - Use #defines for MADT and MCFG version numbers > > - Drop two unnecessary __packed > > - Move __packed to after struct > > - Drop definition of ACPI_TABLE_CREATOR > > - Make _acpi_write_dev_tables() static and switch argument order > > - Generalise the ACPI function recursion with acpi_recurse_method() > > > > Simon Glass (29): > > cpu: Support querying the address width > > spi: Add SPI mode enums > > tpm: cr50: Release locality on exit > > tpm: cr50: Add a comment for cr50_priv > > tpm: cr50: Use the correct GPIO binding > > tpm: Don't cleanup unless an error happens > > dm: pci: Allow disabling auto-config for a device > > x86: Correct wording of coreboot source code > > x86: apl: Move p2sb ofdata reading to the correct method > > pci: Adjust dm_pci_read_bar32() to return errors correctly > > x86: apl: Add Global NVS table header > > dm: core: Add basic ACPI support > > dts: Add a binding for hid-over-i2c > > acpi: Add a binding for ACPI settings in the device tree > > acpi: Add a simple sandbox test > > x86: Move acpi_s3.h to include/acpi/ > > x86: Move acpi_table header to main include/ directory > > acpi: Add an __ACPI__ preprocessor symbol > > acpi: Add a central location for table version numbers > > acpi: Add support for DMAR > > test: Add hexdump.h to the unit test header > > acpi: Add a method to write tables for a device > > acpi: Convert part of acpi_table to use acpi_ctx > > x86: Allow devices to write ACPI tables > > acpi: Drop code for missing XSDT from acpi_write_rsdp() > > acpi: Move acpi_add_table() to generic code > > acpi:
Re: [PATCH v6 12/29] dm: core: Add basic ACPI support
Hi Simon, On Wed, Apr 15, 2020 at 10:31 PM Bin Meng wrote: > > Hi Simon, > > On Fri, Apr 10, 2020 at 3:36 AM Simon Glass wrote: > > > > On Thu, 9 Apr 2020 at 11:40, Andy Shevchenko > > wrote: > > > > > > On Thu, Apr 09, 2020 at 10:27:38AM -0600, Simon Glass wrote: > > > > ACPI (Advanced Configuration and Power Interface) is a standard for > > > > specifying information about a platform. It is a little like device > > > > tree but the bindings are part of the specification and it supports an > > > > interpreted bytecode language. > > > > > > > > Driver model does not use ACPI for U-Boot's configuration, but it is > > > > convenient to have it support generation of ACPI tables for passing to > > > > Linux, etc. > > > > > > > > As a starting point, add an optional set of ACPI operations to each > > > > device. Initially only a single operation is available, to obtain the > > > > ACPI name for the device. More operations are added later. > > > > > > > > Enable ACPI for sandbox to ensure build coverage and so that we can add > > > > tests. > > > > > > > > > > Both looks good to me now, thanks! > > > > > > > Reviewed-by: Bin Meng > > > > Reviewed-by: Wolfgang Wallner > > > > Signed-off-by: Simon Glass > > > > --- > > > > > > > > Changes in v6: > > > > - Use ACPI_NAME_LEN in acpi_copy_name since we add the nul anyway > > > > > > > > Changes in v5: > > > > - Capitalise ACPI_OPS_PTR since it includes a comma > > > > > > > > Changes in v4: None > > > > Changes in v3: > > > > - Drop 'Intel' from 'Intel ACPI' > > > > - Reword commit message to drop the bit about ACPI being complicated > > > > - Compute ACPI_NAME_MAX from ACPI_NAME_LEN > > > > - Rename acpi_return_name() to acpi_copy_name() > > > > - Use strncpy() instead of strcpy() in acpi_copy_name() > > > > > > > > Changes in v2: > > > > - Move LOGC_ACPI definition to this patch > > > > > > > > configs/tools-only_defconfig | 1 + > > > > drivers/core/Kconfig | 9 + > > > > drivers/core/Makefile| 1 + > > > > drivers/core/acpi.c | 33 > > > > include/dm/acpi.h| 73 > > > > include/dm/device.h | 5 +++ > > > > include/log.h| 2 + > > > > 7 files changed, 124 insertions(+) > > > > create mode 100644 drivers/core/acpi.c > > > > create mode 100644 include/dm/acpi.h > > > > Andy let me add your tag. > > > > Reviewed-by: Andy Shevchenko > > Do you know what happened to this series? > > I only see 2 patches in this series showing up on the patchwork. > http://patchwork.ozlabs.org/user/todo/uboot/?series=169449 Or show I replace the 2 patches tagged as v6 in the v5 sereis? http://patchwork.ozlabs.org/user/todo/uboot/?series=169328 Regards, Bin
RE: [PATCHv2 2/9] arm64: fsl-layerscape: Assign addr to resv_ram if enabled RESV_RAM config
Hi Priyanka, Thanks a lot for your comments! > -Original Message- > From: Priyanka Jain (OSS) > Sent: 2020年4月15日 18:28 > To: Z.q. Hou ; u-boot@lists.denx.de; Biwen Li > > Cc: Z.q. Hou > Subject: RE: [PATCHv2 2/9] arm64: fsl-layerscape: Assign addr to resv_ram if > enabled RESV_RAM config > > >-Original Message- > >From: U-Boot On Behalf Of Zhiqiang Hou > >Sent: Tuesday, March 24, 2020 1:42 PM > >To: u-boot@lists.denx.de; Priyanka Jain ; Biwen > >Li > >Cc: Z.q. Hou > >Subject: [PATCHv2 2/9] arm64: fsl-layerscape: Assign addr to resv_ram > >if enabled RESV_RAM config > > > >From: Hou Zhiqiang > > > >The initialization of gd->arch.resv_ram pointer should depend on if the > >RESV_RAM config is enabled. > > > >Signed-off-by: Hou Zhiqiang > >--- > >V2: > > - No change. > > > > arch/arm/cpu/armv8/fsl-layerscape/cpu.c | 8 > > 1 file changed, 4 insertions(+), 4 deletions(-) > > > >diff --git a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c > >b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c > >index b443894453..1b7729c046 100644 > >--- a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c > >+++ b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c > >@@ -1379,7 +1379,7 @@ static int tfa_dram_init_banksize(void) > > if (i > 0) > > ret = 0; > > > >-#if defined(CONFIG_FSL_MC_ENET) && !defined(CONFIG_SPL_BUILD) > >+#if defined(CONFIG_RESV_RAM) && !defined(CONFIG_SPL_BUILD) > > /* Assign memory for MC */ > > #ifdef CONFIG_SYS_DDR_BLOCK3_BASE > > if (gd->bd->bi_dram[2].size >= > >@@ -1402,7 +1402,7 @@ static int tfa_dram_init_banksize(void) > > board_reserve_ram_top(gd->bd- > >>bi_dram[0].size); > > } > > } > >-#endif /* CONFIG_FSL_MC_ENET */ > >+#endif /* CONFIG_RESV_RAM */ > This memory block was intended to be used for MC. That’s why earlier > check was for "CONFIG_FSL_MC_ENET" > Are we planning to use this block for some other purpose as well? > Also I see "CONFIG_ RESV_RAM" getting defines later in the series. > Will MC will work if the series in applied partially? Yes, as you know this will be used for workaround of GICv3 redistributor tables one-way reset issue. The MC will not be affected, since FSL_MC_ENET selected RESV_RAM config. Thanks, Zhiqiang > > Regards > Priyanka > > return ret; > > } > >@@ -1465,7 +1465,7 @@ int dram_init_banksize(void) > > } > > #endif /* CONFIG_SYS_MEM_RESERVE_SECURE */ > > > >-#if defined(CONFIG_FSL_MC_ENET) && !defined(CONFIG_SPL_BUILD) > >+#if defined(CONFIG_RESV_RAM) && !defined(CONFIG_SPL_BUILD) > > /* Assign memory for MC */ > > #ifdef CONFIG_SYS_DDR_BLOCK3_BASE > > if (gd->bd->bi_dram[2].size >= > >@@ -1488,7 +1488,7 @@ int dram_init_banksize(void) > > board_reserve_ram_top(gd->bd- > >>bi_dram[0].size); > > } > > } > >-#endif /* CONFIG_FSL_MC_ENET */ > >+#endif /* CONFIG_RESV_RAM */ > > > > #ifdef CONFIG_SYS_DP_DDR_BASE_PHY > > #ifdef CONFIG_SYS_DDR_BLOCK3_BASE > >-- > >2.17.1
