[PATCH 8/8] sunxi: a64: Add a defconfig for the PinePhone
The PinePhone is a smartphone produced by Pine64, with an A64 SoC, 2 or 3 GiB LPDDR3 RAM, 16 or 32 GiB eMMC, 720x1440 MIPI-DSI panel, and Quectel EG25-G modem. There are two main board revisions: 1.1 for early adopters, and 1.2 for mass production. Since there is code to detect the board revision at boot, one config/image can support both boards. Signed-off-by: Samuel Holland --- configs/pinephone_defconfig | 12 1 file changed, 12 insertions(+) create mode 100644 configs/pinephone_defconfig diff --git a/configs/pinephone_defconfig b/configs/pinephone_defconfig new file mode 100644 index 000..e7833f9dd8d --- /dev/null +++ b/configs/pinephone_defconfig @@ -0,0 +1,12 @@ +CONFIG_ARM=y +CONFIG_ARCH_SUNXI=y +CONFIG_SPL=y +CONFIG_MACH_SUN50I=y +CONFIG_SUNXI_DRAM_LPDDR3_STOCK=y +CONFIG_DRAM_CLK=552 +CONFIG_DRAM_ZQ=3881949 +CONFIG_MMC_SUNXI_SLOT_EXTRA=2 +CONFIG_PINEPHONE_DT_SELECTION=y +# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set +CONFIG_DEFAULT_DEVICE_TREE="sun50i-a64-pinephone-1.2" +CONFIG_OF_LIST="sun50i-a64-pinephone-1.1 sun50i-a64-pinephone-1.2" -- 2.26.2
[PATCH 1/8] sunxi: board: Use a more descriptive variable name
The variable "cmp_str" always leaves me wondering if it is the DT name
of the current board (yes) or DT name in the FIT config entry (no).
In preparation for expanding the functionality here, rename it to
something that obviously means "this is the DT name we are looking for".
Signed-off-by: Samuel Holland
---
board/sunxi/board.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/board/sunxi/board.c b/board/sunxi/board.c
index 71e2b758a3e..674e6816d2d 100644
--- a/board/sunxi/board.c
+++ b/board/sunxi/board.c
@@ -892,14 +892,14 @@ int ft_board_setup(void *blob, struct bd_info *bd)
int board_fit_config_name_match(const char *name)
{
struct boot_file_head *spl = get_spl_header(SPL_DT_HEADER_VERSION);
- const char *cmp_str = (const char *)spl;
+ const char *best_dt_name = (const char *)spl;
/* Check if there is a DT name stored in the SPL header and use that. */
if (spl != INVALID_SPL_HEADER && spl->dt_name_offset) {
- cmp_str += spl->dt_name_offset;
+ best_dt_name += spl->dt_name_offset;
} else {
#ifdef CONFIG_DEFAULT_DEVICE_TREE
- cmp_str = CONFIG_DEFAULT_DEVICE_TREE;
+ best_dt_name = CONFIG_DEFAULT_DEVICE_TREE;
#else
return 0;
#endif
@@ -907,15 +907,15 @@ int board_fit_config_name_match(const char *name)
#ifdef CONFIG_PINE64_DT_SELECTION
/* Differentiate the two Pine64 board DTs by their DRAM size. */
- if (strstr(name, "-pine64") && strstr(cmp_str, "-pine64")) {
+ if (strstr(name, "-pine64") && strstr(best_dt_name, "-pine64")) {
if ((gd->ram_size > 512 * 1024 * 1024))
return !strstr(name, "plus");
else
return !!strstr(name, "plus");
} else {
- return strcmp(name, cmp_str);
+ return strcmp(name, best_dt_name);
}
#endif
- return strcmp(name, cmp_str);
+ return strcmp(name, best_dt_name);
}
#endif
--
2.26.2
[PATCH 0/8] PinePhone automatic device tree selection
All, This patch series implements a feature to automatically choose the right PinePhone device tree by probing the hardware. It then extends the functionality to pass the chosen DTB name to the boot command. Finally, I add device trees and a defconfig for the PinePhone. I'm aware that Andre has concerns about updating the device tree files. It would be unfortunate for this to block new hardware support. Since the device trees are primarily maintained in the Linux repository, and only copied here, I believe compatibility concerns should be directed there, not here. In any case, the first 6 patches can be merged independently, so I request that they be merged even if patches 7-8 are not. I am mainly including the last two patches for ease of testing. Samuel Holland (8): sunxi: board: Use a more descriptive variable name sunxi: board: Add a helper to get the SPL DT name sunxi: board: Simplify Pine A64 DT selection logic sunxi: board: Add PinePhone DT selection logic sunxi: board: Save the chosen DT name in the SPL header sunxi: board: Set fdtfile to match the DT chosen by SPL sunxi: DT: A64: update device tree files sunxi: a64: Add a defconfig for the PinePhone arch/arm/dts/Makefile | 4 + arch/arm/dts/axp803.dtsi | 82 +-- arch/arm/dts/sun50i-a64-amarula-relic.dts | 109 +++- arch/arm/dts/sun50i-a64-bananapi-m64.dts | 118 ++-- arch/arm/dts/sun50i-a64-cpu-opp.dtsi | 75 +++ arch/arm/dts/sun50i-a64-nanopi-a64.dts| 70 +-- .../dts/sun50i-a64-oceanic-5205-5inmfd.dts| 31 +- arch/arm/dts/sun50i-a64-olinuxino-emmc.dts| 12 +- arch/arm/dts/sun50i-a64-olinuxino.dts | 113 ++-- arch/arm/dts/sun50i-a64-orangepi-win.dts | 127 +++-- arch/arm/dts/sun50i-a64-pine64-lts.dts| 7 +- arch/arm/dts/sun50i-a64-pine64-plus.dts | 52 +- arch/arm/dts/sun50i-a64-pine64.dts| 97 ++-- arch/arm/dts/sun50i-a64-pinebook-u-boot.dtsi | 17 - arch/arm/dts/sun50i-a64-pinebook.dts | 237 ++-- arch/arm/dts/sun50i-a64-pinephone-1.0.dts | 11 + arch/arm/dts/sun50i-a64-pinephone-1.1.dts | 30 + arch/arm/dts/sun50i-a64-pinephone-1.2.dts | 40 ++ arch/arm/dts/sun50i-a64-pinephone.dtsi| 429 ++ arch/arm/dts/sun50i-a64-pinetab.dts | 460 +++ arch/arm/dts/sun50i-a64-sopine-baseboard.dts | 113 ++-- arch/arm/dts/sun50i-a64-sopine.dtsi | 69 +-- arch/arm/dts/sun50i-a64-teres-i-u-boot.dtsi | 41 -- arch/arm/dts/sun50i-a64-teres-i.dts | 138 - arch/arm/dts/sun50i-a64.dtsi | 532 ++ arch/arm/mach-sunxi/Kconfig | 7 + board/sunxi/board.c | 97 +++- configs/pinephone_defconfig | 12 + include/dt-bindings/clock/sun50i-a64-ccu.h| 4 +- include/dt-bindings/clock/sun8i-de2.h | 3 + include/dt-bindings/reset/sun8i-de2.h | 1 + 31 files changed, 2488 insertions(+), 650 deletions(-) create mode 100644 arch/arm/dts/sun50i-a64-cpu-opp.dtsi delete mode 100644 arch/arm/dts/sun50i-a64-pinebook-u-boot.dtsi create mode 100644 arch/arm/dts/sun50i-a64-pinephone-1.0.dts create mode 100644 arch/arm/dts/sun50i-a64-pinephone-1.1.dts create mode 100644 arch/arm/dts/sun50i-a64-pinephone-1.2.dts create mode 100644 arch/arm/dts/sun50i-a64-pinephone.dtsi create mode 100644 arch/arm/dts/sun50i-a64-pinetab.dts delete mode 100644 arch/arm/dts/sun50i-a64-teres-i-u-boot.dtsi create mode 100644 configs/pinephone_defconfig -- 2.26.2
[PATCH 6/8] sunxi: board: Set fdtfile to match the DT chosen by SPL
Previously, fdtfile was always the value in CONFIG_DEFAULT_DEVICE_TREE.
This meant that, regardless of the DT chosen by SPL (either by changing
the header in the image or by the selection code at runtime), Linux
always used the default DT.
By using the name from the SPL header (which, because of the previous
commit, always matches the DT used by U-Boot proper), Linux also sees
the same board as U-Boot/SPL, even if the boot script later loads a DT
from disk.
Signed-off-by: Samuel Holland
---
board/sunxi/board.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/board/sunxi/board.c b/board/sunxi/board.c
index eaa40a1ea96..5457b28e135 100644
--- a/board/sunxi/board.c
+++ b/board/sunxi/board.c
@@ -870,6 +870,7 @@ static void setup_environment(const void *fdt)
int misc_init_r(void)
{
+ const char *spl_dt_name;
uint boot;
env_set("fel_booted", NULL);
@@ -888,6 +889,16 @@ int misc_init_r(void)
env_set("mmc_bootdev", "1");
}
+ /* Set fdtfile to match the FIT configuration chosen in SPL. */
+ spl_dt_name = get_spl_dt_name();
+ if (spl_dt_name) {
+ char *prefix = IS_ENABLED(CONFIG_ARM64) ? "allwinner/" : "";
+ char str[64];
+
+ snprintf(str, sizeof(str), "%s%s.dtb", prefix, spl_dt_name);
+ env_set("fdtfile", str);
+ }
+
setup_environment(gd->fdt_blob);
#ifdef CONFIG_USB_ETHER
--
2.26.2
[PATCH 5/8] sunxi: board: Save the chosen DT name in the SPL header
This overwrites the name loaded from the SPL image. It will be different
if there was previously no name provided, or if a more accurate name was
determined by the board variant selection logic. This means that the DT
name in the SPL header now always matches the DT appended to U-Boot.
Signed-off-by: Samuel Holland
---
board/sunxi/board.c | 27 ++-
1 file changed, 26 insertions(+), 1 deletion(-)
diff --git a/board/sunxi/board.c b/board/sunxi/board.c
index 3d64ed18664..eaa40a1ea96 100644
--- a/board/sunxi/board.c
+++ b/board/sunxi/board.c
@@ -331,6 +331,21 @@ static const char *get_spl_dt_name(void)
return NULL;
}
+static void set_spl_dt_name(const char *name)
+{
+ struct boot_file_head *spl = get_spl_header(SPL_ENV_HEADER_VERSION);
+
+ if (spl == INVALID_SPL_HEADER)
+ return;
+
+ /* Promote the header version for U-Boot proper, if needed. */
+ if (spl->spl_signature[3] < SPL_DT_HEADER_VERSION)
+ spl->spl_signature[3] = SPL_DT_HEADER_VERSION;
+
+ strcpy((char *)>string_pool, name);
+ spl->dt_name_offset = offsetof(struct boot_file_head, string_pool);
+}
+
int dram_init(void)
{
struct boot_file_head *spl = get_spl_header(SPL_DRAM_HEADER_VERSION);
@@ -904,6 +919,7 @@ int ft_board_setup(void *blob, struct bd_info *bd)
int board_fit_config_name_match(const char *name)
{
const char *best_dt_name = get_spl_dt_name();
+ int ret;
#ifdef CONFIG_DEFAULT_DEVICE_TREE
if (best_dt_name == NULL)
@@ -941,6 +957,15 @@ int board_fit_config_name_match(const char *name)
}
#endif
- return strcmp(name, best_dt_name);
+ ret = strcmp(name, best_dt_name);
+
+ /*
+* If one of the FIT configurations matches the most accurate DT name,
+* update the SPL header to provide that DT name to U-Boot proper.
+*/
+ if (ret == 0)
+ set_spl_dt_name(best_dt_name);
+
+ return ret;
}
#endif
--
2.26.2
[PATCH 3/8] sunxi: board: Simplify Pine A64 DT selection logic
Instead of using an entirely separate matching algorithm, simply update
the name of the DT we want to match. Enabling this logic does not depend
on the FIT config name, only on the initial guess of the board name.
Importantly, the initial guess must be "sun50i-a64-pine64-plus", because
otherwise the logic would trigger when "sun50i-a64-pine64-lts" was
written to the SPL header.
Signed-off-by: Samuel Holland
---
board/sunxi/board.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/board/sunxi/board.c b/board/sunxi/board.c
index 5c9b811f27a..fb0d5bf4743 100644
--- a/board/sunxi/board.c
+++ b/board/sunxi/board.c
@@ -914,14 +914,10 @@ int board_fit_config_name_match(const char *name)
return 0;
}
#ifdef CONFIG_PINE64_DT_SELECTION
-/* Differentiate the two Pine64 board DTs by their DRAM size. */
- if (strstr(name, "-pine64") && strstr(best_dt_name, "-pine64")) {
- if ((gd->ram_size > 512 * 1024 * 1024))
- return !strstr(name, "plus");
- else
- return !!strstr(name, "plus");
- } else {
- return strcmp(name, best_dt_name);
+ else if (strstr(best_dt_name, "-pine64-plus")) {
+ /* Differentiate the Pine A64 boards by their DRAM size. */
+ if ((gd->ram_size == 512 * 1024 * 1024))
+ best_dt_name = "sun50i-a64-pine64";
}
#endif
return strcmp(name, best_dt_name);
--
2.26.2
[PATCH 4/8] sunxi: board: Add PinePhone DT selection logic
There are two different publicly-released revisions of the PinePhone
hardware, versions 1.1 and 1.2; and they need different device trees.
Since some GPIO pins were rerouted, we can use that to distinguish
between them.
Signed-off-by: Samuel Holland
---
arch/arm/mach-sunxi/Kconfig | 7 +++
board/sunxi/board.c | 21 +
2 files changed, 28 insertions(+)
diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
index be0822bfb7d..8421f3b6854 100644
--- a/arch/arm/mach-sunxi/Kconfig
+++ b/arch/arm/mach-sunxi/Kconfig
@@ -1010,4 +1010,11 @@ config PINE64_DT_SELECTION
option, the device tree selection code specific to Pine64 which
utilizes the DRAM size will be enabled.
+config PINEPHONE_DT_SELECTION
+ bool "Enable PinePhone device tree selection code"
+ depends on MACH_SUN50I
+ help
+ Enable this option to automatically select the device tree for the
+ correct PinePhone hardware revision during boot.
+
endif
diff --git a/board/sunxi/board.c b/board/sunxi/board.c
index fb0d5bf4743..3d64ed18664 100644
--- a/board/sunxi/board.c
+++ b/board/sunxi/board.c
@@ -27,6 +27,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -920,6 +921,26 @@ int board_fit_config_name_match(const char *name)
best_dt_name = "sun50i-a64-pine64";
}
#endif
+#ifdef CONFIG_PINEPHONE_DT_SELECTION
+ else if (strstr(best_dt_name, "-pinephone")) {
+ /* Differentiate the PinePhone revisions by GPIO inputs. */
+ prcm_apb0_enable(PRCM_APB0_GATE_PIO);
+ sunxi_gpio_set_pull(SUNXI_GPL(6), SUNXI_GPIO_PULL_UP);
+ sunxi_gpio_set_cfgpin(SUNXI_GPL(6), SUNXI_GPIO_INPUT);
+ udelay(100);
+
+ /* PL6 is pulled low by the modem on v1.2. */
+ if (gpio_get_value(SUNXI_GPL(6)) == 0)
+ best_dt_name = "sun50i-a64-pinephone-1.2";
+ else
+ best_dt_name = "sun50i-a64-pinephone-1.1";
+
+ sunxi_gpio_set_cfgpin(SUNXI_GPL(6), SUNXI_GPIO_DISABLE);
+ sunxi_gpio_set_pull(SUNXI_GPL(6), SUNXI_GPIO_PULL_DISABLE);
+ prcm_apb0_disable(PRCM_APB0_GATE_PIO);
+ }
+#endif
+
return strcmp(name, best_dt_name);
}
#endif
--
2.26.2
[PATCH 2/8] sunxi: board: Add a helper to get the SPL DT name
This moves the validity checking and typecasts all to one place away
from the string comparison logic, and it detangles the compile-time
and runtime control flow.
The new helper will also be used by U-Boot proper in a future commit.
Signed-off-by: Samuel Holland
---
board/sunxi/board.c | 26 +-
1 file changed, 17 insertions(+), 9 deletions(-)
diff --git a/board/sunxi/board.c b/board/sunxi/board.c
index 674e6816d2d..5c9b811f27a 100644
--- a/board/sunxi/board.c
+++ b/board/sunxi/board.c
@@ -319,6 +319,17 @@ static struct boot_file_head * get_spl_header(uint8_t
req_version)
return spl;
}
+static const char *get_spl_dt_name(void)
+{
+ struct boot_file_head *spl = get_spl_header(SPL_DT_HEADER_VERSION);
+
+ /* Check if there is a DT name stored in the SPL header. */
+ if (spl != INVALID_SPL_HEADER && spl->dt_name_offset)
+ return (char *)spl + spl->dt_name_offset;
+
+ return NULL;
+}
+
int dram_init(void)
{
struct boot_file_head *spl = get_spl_header(SPL_DRAM_HEADER_VERSION);
@@ -891,20 +902,17 @@ int ft_board_setup(void *blob, struct bd_info *bd)
#ifdef CONFIG_SPL_LOAD_FIT
int board_fit_config_name_match(const char *name)
{
- struct boot_file_head *spl = get_spl_header(SPL_DT_HEADER_VERSION);
- const char *best_dt_name = (const char *)spl;
+ const char *best_dt_name = get_spl_dt_name();
- /* Check if there is a DT name stored in the SPL header and use that. */
- if (spl != INVALID_SPL_HEADER && spl->dt_name_offset) {
- best_dt_name += spl->dt_name_offset;
- } else {
#ifdef CONFIG_DEFAULT_DEVICE_TREE
+ if (best_dt_name == NULL)
best_dt_name = CONFIG_DEFAULT_DEVICE_TREE;
-#else
- return 0;
#endif
- };
+ if (best_dt_name == NULL) {
+ /* No DT name was provided, so accept the first config. */
+ return 0;
+ }
#ifdef CONFIG_PINE64_DT_SELECTION
/* Differentiate the two Pine64 board DTs by their DRAM size. */
if (strstr(name, "-pine64") && strstr(best_dt_name, "-pine64")) {
--
2.26.2
Re: [PATCH v2 7/7] riscv: Update SiFive device tree for new CLINT driver
On Thu, Sep 3, 2020 at 8:19 AM Bin Meng wrote:
>
> Hi Anup,
>
> On Thu, Sep 3, 2020 at 10:46 AM Anup Patel wrote:
> >
> > On Thu, Sep 3, 2020 at 7:32 AM Bin Meng wrote:
> > >
> > > Hi Anup,
> > >
> > > On Tue, Aug 18, 2020 at 6:03 PM Sean Anderson wrote:
> > > >
> > > > On 8/18/20 5:22 AM, Bin Meng wrote:
> > > > > +Anup Patel
> > > > >
> > > > > On Wed, Jul 29, 2020 at 5:57 PM Sean Anderson
> > > > > wrote:
> > > > >>
> > > > >> We may need to add a clock-frequency binding like for the K210.
> > > > >>
> > > > >> Signed-off-by: Sean Anderson
> > > > >> ---
> > > > >> This patch builds but has NOT been tested.
> > > > >>
> > > > >> Changes in v2:
> > > > >> - Fix SiFive CLINT not getting tick-rate from rtcclk
> > > > >>
> > > > >> arch/riscv/dts/fu540-c000-u-boot.dtsi | 8 ++--
> > > > >> arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi | 4
> > > > >> 2 files changed, 10 insertions(+), 2 deletions(-)
> > > > >>
> > > > >> diff --git a/arch/riscv/dts/fu540-c000-u-boot.dtsi
> > > > >> b/arch/riscv/dts/fu540-c000-u-boot.dtsi
> > > > >> index afdb4f4402..f126d3e0b3 100644
> > > > >> --- a/arch/riscv/dts/fu540-c000-u-boot.dtsi
> > > > >> +++ b/arch/riscv/dts/fu540-c000-u-boot.dtsi
> > > > >> @@ -53,9 +53,13 @@
> > > > >> reg = <0x0 0x1007 0x0 0x1000>;
> > > > >> fuse-count = <0x1000>;
> > > > >> };
> > > > >> - clint@200 {
> > > > >> + clint: clint@200 {
> > > > >> compatible = "riscv,clint0";
> > > > >> - interrupts-extended = <_intc 3
> > > > >> _intc 7 _intc 3 _intc 7 _intc 3 _intc 7
> > > > >> _intc 3 _intc 7 _intc 3 _intc 7>;
> > > > >> + interrupts-extended = <_intc 3
> > > > >> _intc 7
> > > > >> + _intc 3
> > > > >> _intc 7
> > > > >> + _intc 3
> > > > >> _intc 7
> > > > >> + _intc 3
> > > > >> _intc 7
> > > > >> + _intc 3
> > > > >> _intc 7>;
> > > > >> reg = <0x0 0x200 0x0 0xc>;
> > > > >> u-boot,dm-spl;
> > > > >> };
> > > > >> diff --git a/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi
> > > > >> b/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi
> > > > >> index e037150520..3275bb1f12 100644
> > > > >> --- a/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi
> > > > >> +++ b/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi
> > > > >> @@ -26,6 +26,10 @@
> > > > >>
> > > > >> };
> > > > >>
> > > > >> + {
> > > > >> + clocks = <>;
> > > > >> +};
> > > > >
> > > > > Can we consider making this property a standard property by the kernel
> > > > > upstream? How does the kernel CLINT timer driver determine its running
> > > > > frequency?
> > > >
> > > > Currently it gets it from /cpus/timebase-frequency.
> > >
> > > What's your comment on this? I think this should go upstream to the
> > > standard bindings.
> >
> > My apologies for delay. Too many mailing list to track.
> >
> > I think "clocks" should be an optional DT property for CLINT driver (both
> > Linux and U-Boot). If "clocks" is not available then we should fallback to
> > "/cpus/timebase-frequency"
> >
>
> Agreed. The question is whether this should be mentioned in the DT
> bindings doc in the kernel tree?
Yes, the "clocks" DT property should be updated in kernel DT bindings doc
and kernel CLINT driver should also prefer "clocks" DT property when available.
Regards,
Anup
>
> > Please note in any case the "/cpus/timebase-frequency" will remain
> > mandatory for generic RISC-V timer (both Linux and U-Boot).
>
> Regards,
> Bin
RE: [PATCH v2 1/4] mmc: pic32: Refresh PIC32 MMC driver
> Am Montag, den 31.08.2020, 18:04 + schrieb John Robertson:
> > The existing driver is not compatible with the Driver Model.
> >
> > This patch makes the necessary changes while also removing obsolescent
> > calls/properties as follows:
> >
> > - fdtdec_* calls replaced with dev_read_* equivalents;
> > - 'clock-freq-min-max' property replaced by querying the frequency of
> > the source clock 'base_clk';
> > - The card detect erratum workaround is applied during probe rather than
> > overriding get_cd.
> >
> > The card detect workaround (Microchip ref. DS8736E, erratum #15)
> > is not needed if the SDCD signal is properly connected on the board
> > and so can be disabled using a vendor specific DT property.
> >
> > Signed-off-by: John Robertson
> > ---
> > Changes in v2:
> > - Split patch;
> > - Fix compilation failure after 'make pic32mzdask_defconfig'.
> >
> > drivers/mmc/pic32_sdhci.c | 77
> > ---
> > 1 file changed, 48 insertions(+), 29 deletions(-)
> >
> > diff --git a/drivers/mmc/pic32_sdhci.c b/drivers/mmc/pic32_sdhci.c
> > index 029e0fbc2b..93f0532ad6 100644
> > --- a/drivers/mmc/pic32_sdhci.c
> > +++ b/drivers/mmc/pic32_sdhci.c
> > @@ -9,62 +9,78 @@
> > #include
> > #include
> > #include
> > -#include
> > -#include
> > +#include
> >
> > DECLARE_GLOBAL_DATA_PTR;
>
> also remove this and common.h as this is not needed with the dev_* API
>
Fixed in v3.
> >
> > -static int pic32_sdhci_get_cd(struct sdhci_host *host) -{
> > - /* PIC32 SDHCI CD errata:
> > -* - set CD_TEST and clear CD_TEST_INS bit
> > -*/
> > - sdhci_writeb(host, SDHCI_CTRL_CD_TEST, SDHCI_HOST_CONTROL);
> > -
> > - return 0;
> > -}
> > -
> > -static const struct sdhci_ops pic32_sdhci_ops = {
> > - .get_cd = pic32_sdhci_get_cd,
> > +struct pic32_sdhci_plat {
> > + struct mmc_config cfg;
> > + struct mmc mmc;
> > };
> >
> > static int pic32_sdhci_probe(struct udevice *dev) {
> > + struct mmc_uclass_priv *upriv = dev_get_uclass_priv(dev);
> > + struct pic32_sdhci_plat *plat = dev_get_platdata(dev);
> > struct sdhci_host *host = dev_get_priv(dev);
> > - const void *fdt = gd->fdt_blob;
> > - u32 f_min_max[2];
> > +
> > fdt_addr_t addr;
> > fdt_size_t size;
> > + struct clk clk;
> > + ulong clk_rate;
> > int ret;
> >
> > - addr = fdtdec_get_addr_size(fdt, dev_of_offset(dev), "reg", );
> > + addr = dev_read_addr_size(dev, "reg", );
> > if (addr == FDT_ADDR_T_NONE)
> > return -EINVAL;
> >
> > + ret = clk_get_by_name(dev, "base_clk", );
> > + if (ret)
> > + return ret;
> > +
> > + clk_rate = clk_get_rate();
> > + clk_free();
> > +
> > + if (IS_ERR_VALUE(clk_rate))
> > + return clk_rate;
> > +
> > host->ioaddr= ioremap(addr, size);
>
> use dev_remap_addr() instead of dev_read_addr_size() + ioremap()
>
Agreed. Done in v3.
> > host->name = dev->name;
> > host->quirks= SDHCI_QUIRK_NO_HISPD_BIT;
> > - host->bus_width = fdtdec_get_int(gd->fdt_blob,
> dev_of_offset(dev),
> > - "bus-width", 4);
> > - host->ops = _sdhci_ops;
> > -
> > - ret = fdtdec_get_int_array(gd->fdt_blob, dev_of_offset(dev),
> > - "clock-freq-min-max", f_min_max, 2);
> > - if (ret) {
> > - printf("sdhci: clock-freq-min-max not found\n");
> > + host->bus_width = dev_read_u32_default(dev, "bus-width",
> 4);
> > + host->max_clk = clk_rate;
> > +
> > + host->mmc = >mmc;
> > + host->mmc->dev = dev;
> > +
> > + ret = sdhci_setup_cfg(>cfg, host, 0, 0);
> > + if (ret)
> > return ret;
> > - }
> >
> > - host->max_clk = f_min_max[1];
> > + host->mmc->priv = host;
> > + upriv->mmc = host->mmc;
> >
> > - ret = add_sdhci(host, 0, f_min_max[0]);
> > + ret = sdhci_probe(dev);
> > if (ret)
> > return ret;
> > - host->mmc->dev = dev;
> > +
> > + if (!dev_read_bool(dev, "microchip,use-sdcd")) {
> > + // Use workaround 1 for erratum #15 by default
> > + u8 ctrl = sdhci_readb(host, SDHCI_HOST_CONTROL);
> > + ctrl = (ctrl & ~SDHCI_CTRL_CD_TEST_INS) |
> SDHCI_CTRL_CD_TEST;
> > + sdhci_writeb(host, ctrl, SDHCI_HOST_CONTROL);
> > + }
> >
> > return 0;
> > }
> >
> > +static int pic32_sdhci_bind(struct udevice *dev) {
> > + struct pic32_sdhci_plat *plat = dev_get_platdata(dev);
> > +
> > + return sdhci_bind(dev, >mmc, >cfg); }
> > +
> > static const struct udevice_id pic32_sdhci_ids[] = {
> > { .compatible = "microchip,pic32mzda-sdhci" },
> > { }
> > @@ -74,6 +90,9 @@ U_BOOT_DRIVER(pic32_sdhci_drv) = {
> > .name = "pic32_sdhci",
> > .id = UCLASS_MMC,
> > .of_match = pic32_sdhci_ids,
> > + .ops= _ops,
> > + .bind = pic32_sdhci_bind,
> > .probe = pic32_sdhci_probe,
> > .priv_auto_alloc_size
RE: [PATCH v2 4/4] mmc: pic32: Refresh PIC32 MMC driver
> Am Montag, den 31.08.2020, 18:04 + schrieb John Robertson: > > CONFIG_BLK needs to be enabled by default to allow U-Boot to compile > > after a 'make pic32mzdask_defconfig'. > > > > Signed-off-by: John Robertson > > --- > > > > configs/pic32mzdask_defconfig | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/configs/pic32mzdask_defconfig > > b/configs/pic32mzdask_defconfig index 7bf61e2d8d..f5c88737b9 100644 > > --- a/configs/pic32mzdask_defconfig > > +++ b/configs/pic32mzdask_defconfig > > @@ -27,7 +27,7 @@ CONFIG_CMD_EXT4_WRITE=y # > CONFIG_EFI_PARTITION is > > not set CONFIG_SYS_RELOC_GD_ENV_ADDR=y > CONFIG_NET_RANDOM_ETHADDR=y > > -# CONFIG_BLK is not set > > +CONFIG_BLK is not set > > this looks hand-crafted and should be CONFIG_BLK=y > > simply run "make savedefconfig && cp defconfig > configs/pic32mzdask_defconfig" to automatically update the defconfig file > after changing something with "make menuconfig" You're right, of course. 'make savedefconfig' removes that line completely; fixed in v3. > > > CONFIG_CLK=y > > CONFIG_MMC=y > > CONFIG_DM_MMC=y > -- > - Daniel
Re: [PATCH v2 7/7] riscv: Update SiFive device tree for new CLINT driver
Hi Anup,
On Thu, Sep 3, 2020 at 10:46 AM Anup Patel wrote:
>
> On Thu, Sep 3, 2020 at 7:32 AM Bin Meng wrote:
> >
> > Hi Anup,
> >
> > On Tue, Aug 18, 2020 at 6:03 PM Sean Anderson wrote:
> > >
> > > On 8/18/20 5:22 AM, Bin Meng wrote:
> > > > +Anup Patel
> > > >
> > > > On Wed, Jul 29, 2020 at 5:57 PM Sean Anderson wrote:
> > > >>
> > > >> We may need to add a clock-frequency binding like for the K210.
> > > >>
> > > >> Signed-off-by: Sean Anderson
> > > >> ---
> > > >> This patch builds but has NOT been tested.
> > > >>
> > > >> Changes in v2:
> > > >> - Fix SiFive CLINT not getting tick-rate from rtcclk
> > > >>
> > > >> arch/riscv/dts/fu540-c000-u-boot.dtsi | 8 ++--
> > > >> arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi | 4
> > > >> 2 files changed, 10 insertions(+), 2 deletions(-)
> > > >>
> > > >> diff --git a/arch/riscv/dts/fu540-c000-u-boot.dtsi
> > > >> b/arch/riscv/dts/fu540-c000-u-boot.dtsi
> > > >> index afdb4f4402..f126d3e0b3 100644
> > > >> --- a/arch/riscv/dts/fu540-c000-u-boot.dtsi
> > > >> +++ b/arch/riscv/dts/fu540-c000-u-boot.dtsi
> > > >> @@ -53,9 +53,13 @@
> > > >> reg = <0x0 0x1007 0x0 0x1000>;
> > > >> fuse-count = <0x1000>;
> > > >> };
> > > >> - clint@200 {
> > > >> + clint: clint@200 {
> > > >> compatible = "riscv,clint0";
> > > >> - interrupts-extended = <_intc 3 _intc
> > > >> 7 _intc 3 _intc 7 _intc 3 _intc 7 _intc 3
> > > >> _intc 7 _intc 3 _intc 7>;
> > > >> + interrupts-extended = <_intc 3 _intc
> > > >> 7
> > > >> + _intc 3 _intc
> > > >> 7
> > > >> + _intc 3 _intc
> > > >> 7
> > > >> + _intc 3 _intc
> > > >> 7
> > > >> + _intc 3 _intc
> > > >> 7>;
> > > >> reg = <0x0 0x200 0x0 0xc>;
> > > >> u-boot,dm-spl;
> > > >> };
> > > >> diff --git a/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi
> > > >> b/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi
> > > >> index e037150520..3275bb1f12 100644
> > > >> --- a/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi
> > > >> +++ b/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi
> > > >> @@ -26,6 +26,10 @@
> > > >>
> > > >> };
> > > >>
> > > >> + {
> > > >> + clocks = <>;
> > > >> +};
> > > >
> > > > Can we consider making this property a standard property by the kernel
> > > > upstream? How does the kernel CLINT timer driver determine its running
> > > > frequency?
> > >
> > > Currently it gets it from /cpus/timebase-frequency.
> >
> > What's your comment on this? I think this should go upstream to the
> > standard bindings.
>
> My apologies for delay. Too many mailing list to track.
>
> I think "clocks" should be an optional DT property for CLINT driver (both
> Linux and U-Boot). If "clocks" is not available then we should fallback to
> "/cpus/timebase-frequency"
>
Agreed. The question is whether this should be mentioned in the DT
bindings doc in the kernel tree?
> Please note in any case the "/cpus/timebase-frequency" will remain
> mandatory for generic RISC-V timer (both Linux and U-Boot).
Regards,
Bin
Re: [PATCH v2 7/7] riscv: Update SiFive device tree for new CLINT driver
On Thu, Sep 3, 2020 at 7:32 AM Bin Meng wrote:
>
> Hi Anup,
>
> On Tue, Aug 18, 2020 at 6:03 PM Sean Anderson wrote:
> >
> > On 8/18/20 5:22 AM, Bin Meng wrote:
> > > +Anup Patel
> > >
> > > On Wed, Jul 29, 2020 at 5:57 PM Sean Anderson wrote:
> > >>
> > >> We may need to add a clock-frequency binding like for the K210.
> > >>
> > >> Signed-off-by: Sean Anderson
> > >> ---
> > >> This patch builds but has NOT been tested.
> > >>
> > >> Changes in v2:
> > >> - Fix SiFive CLINT not getting tick-rate from rtcclk
> > >>
> > >> arch/riscv/dts/fu540-c000-u-boot.dtsi | 8 ++--
> > >> arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi | 4
> > >> 2 files changed, 10 insertions(+), 2 deletions(-)
> > >>
> > >> diff --git a/arch/riscv/dts/fu540-c000-u-boot.dtsi
> > >> b/arch/riscv/dts/fu540-c000-u-boot.dtsi
> > >> index afdb4f4402..f126d3e0b3 100644
> > >> --- a/arch/riscv/dts/fu540-c000-u-boot.dtsi
> > >> +++ b/arch/riscv/dts/fu540-c000-u-boot.dtsi
> > >> @@ -53,9 +53,13 @@
> > >> reg = <0x0 0x1007 0x0 0x1000>;
> > >> fuse-count = <0x1000>;
> > >> };
> > >> - clint@200 {
> > >> + clint: clint@200 {
> > >> compatible = "riscv,clint0";
> > >> - interrupts-extended = <_intc 3 _intc 7
> > >> _intc 3 _intc 7 _intc 3 _intc 7 _intc 3
> > >> _intc 7 _intc 3 _intc 7>;
> > >> + interrupts-extended = <_intc 3 _intc 7
> > >> + _intc 3 _intc 7
> > >> + _intc 3 _intc 7
> > >> + _intc 3 _intc 7
> > >> + _intc 3 _intc
> > >> 7>;
> > >> reg = <0x0 0x200 0x0 0xc>;
> > >> u-boot,dm-spl;
> > >> };
> > >> diff --git a/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi
> > >> b/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi
> > >> index e037150520..3275bb1f12 100644
> > >> --- a/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi
> > >> +++ b/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi
> > >> @@ -26,6 +26,10 @@
> > >>
> > >> };
> > >>
> > >> + {
> > >> + clocks = <>;
> > >> +};
> > >
> > > Can we consider making this property a standard property by the kernel
> > > upstream? How does the kernel CLINT timer driver determine its running
> > > frequency?
> >
> > Currently it gets it from /cpus/timebase-frequency.
>
> What's your comment on this? I think this should go upstream to the
> standard bindings.
My apologies for delay. Too many mailing list to track.
I think "clocks" should be an optional DT property for CLINT driver (both
Linux and U-Boot). If "clocks" is not available then we should fallback to
"/cpus/timebase-frequency"
Please note in any case the "/cpus/timebase-frequency" will remain
mandatory for generic RISC-V timer (both Linux and U-Boot).
Regards,
Anup
Re: [PATCH] buildman: Use git worktrees instead of git clones
Hi Alper, On Wed, 2 Sep 2020 at 16:21, Alper Nebi Yasak wrote: > > On 02/09/2020 20:07, Simon Glass wrote: > > It looks like that version of git was not in Ubuntu 14.04 but appeared > > in 16.04. I've just done some patches to make patman work in 14.04, so > > I'd prefer to keep buildman working for that also. > > I'll keep that in mind. Looks like Ubuntu 14.04 has python v3.4 and git > v1.9. I'm used to more recent versions so maybe I'll take the time to > set up a VM to test things in. > > > So I think we should have an option to keep the old behaviour, or > > perhaps detect when 'git worktree' is not available and fall back. > > I can check whether 'git worktree list' succeeds, it should have no > effect on the repo but would give a 'not a git command' error if things > wouldn't work; in which case buildman could fall back to cloning. I'll > implement and send a v2 with something like that. OK thanks. If it helps, on 14.04: $ git worktree git: 'worktree' is not a git command. See 'git --help'. echo $? 1 Regards, Simon
Re: [PATCH v2 7/7] riscv: Update SiFive device tree for new CLINT driver
Hi Anup,
On Tue, Aug 18, 2020 at 6:03 PM Sean Anderson wrote:
>
> On 8/18/20 5:22 AM, Bin Meng wrote:
> > +Anup Patel
> >
> > On Wed, Jul 29, 2020 at 5:57 PM Sean Anderson wrote:
> >>
> >> We may need to add a clock-frequency binding like for the K210.
> >>
> >> Signed-off-by: Sean Anderson
> >> ---
> >> This patch builds but has NOT been tested.
> >>
> >> Changes in v2:
> >> - Fix SiFive CLINT not getting tick-rate from rtcclk
> >>
> >> arch/riscv/dts/fu540-c000-u-boot.dtsi | 8 ++--
> >> arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi | 4
> >> 2 files changed, 10 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/arch/riscv/dts/fu540-c000-u-boot.dtsi
> >> b/arch/riscv/dts/fu540-c000-u-boot.dtsi
> >> index afdb4f4402..f126d3e0b3 100644
> >> --- a/arch/riscv/dts/fu540-c000-u-boot.dtsi
> >> +++ b/arch/riscv/dts/fu540-c000-u-boot.dtsi
> >> @@ -53,9 +53,13 @@
> >> reg = <0x0 0x1007 0x0 0x1000>;
> >> fuse-count = <0x1000>;
> >> };
> >> - clint@200 {
> >> + clint: clint@200 {
> >> compatible = "riscv,clint0";
> >> - interrupts-extended = <_intc 3 _intc 7
> >> _intc 3 _intc 7 _intc 3 _intc 7 _intc 3
> >> _intc 7 _intc 3 _intc 7>;
> >> + interrupts-extended = <_intc 3 _intc 7
> >> + _intc 3 _intc 7
> >> + _intc 3 _intc 7
> >> + _intc 3 _intc 7
> >> + _intc 3 _intc 7>;
> >> reg = <0x0 0x200 0x0 0xc>;
> >> u-boot,dm-spl;
> >> };
> >> diff --git a/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi
> >> b/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi
> >> index e037150520..3275bb1f12 100644
> >> --- a/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi
> >> +++ b/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi
> >> @@ -26,6 +26,10 @@
> >>
> >> };
> >>
> >> + {
> >> + clocks = <>;
> >> +};
> >
> > Can we consider making this property a standard property by the kernel
> > upstream? How does the kernel CLINT timer driver determine its running
> > frequency?
>
> Currently it gets it from /cpus/timebase-frequency.
What's your comment on this? I think this should go upstream to the
standard bindings.
Regards,
Bin
Re: [PATCH v3 2/7] riscv: Rework Andes PLMT as a UCLASS_TIMER driver
>
> This converts the PLMT driver from the riscv-specific timer interface to be
> a DM-based UCLASS_TIMER driver.
>
> The clock-frequency/clocks properties are preferred over timebase-frequency
> for two reasons. First, properties which affect a device should be located
> near its binding in the device tree. Using timebase-frequency only really
> makes sense when the cpu itself is the timer device. This is the case when
> we read the time from a CSR, but not when there is a separate device.
> Second, it lets the device use the clock subsystem which adds flexibility.
> If the device is configured for a different clock speed, the timer can
> adjust itself.
>
> Signed-off-by: Sean Anderson
> ---
> This patch builds but has NOT been tested.
>
> (no changes since v1)
>
> arch/riscv/Kconfig | 4 ---
> arch/riscv/dts/ae350_32.dts | 1 +
> arch/riscv/dts/ae350_64.dts | 1 +
> arch/riscv/include/asm/global_data.h | 3 --
> arch/riscv/lib/andes_plmt.c | 42 +---
> 5 files changed, 22 insertions(+), 29 deletions(-)
>
> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> index 21e6690f4d..d9155b9bab 100644
> --- a/arch/riscv/Kconfig
> +++ b/arch/riscv/Kconfig
> @@ -177,10 +177,6 @@ config ANDES_PLIC
> config ANDES_PLMT
> bool
> depends on RISCV_MMODE || SPL_RISCV_MMODE
> - select REGMAP
> - select SYSCON
> - select SPL_REGMAP if SPL
> - select SPL_SYSCON if SPL
> help
> The Andes PLMT block holds memory-mapped mtime register
> associated with timer tick.
> diff --git a/arch/riscv/dts/ae350_32.dts b/arch/riscv/dts/ae350_32.dts
> index 3f8525fe56..afcb9cfbbf 100644
> --- a/arch/riscv/dts/ae350_32.dts
> +++ b/arch/riscv/dts/ae350_32.dts
> @@ -162,6 +162,7 @@
> _intc 7
> _intc 7>;
> reg = <0xe600 0x10>;
> + clock-frequency = <6000>;
> };
> };
>
> diff --git a/arch/riscv/dts/ae350_64.dts b/arch/riscv/dts/ae350_64.dts
> index 482c707503..1c37879049 100644
> --- a/arch/riscv/dts/ae350_64.dts
> +++ b/arch/riscv/dts/ae350_64.dts
> @@ -162,6 +162,7 @@
> _intc 7
> _intc 7>;
> reg = <0x0 0xe600 0x0 0x10>;
> + clock-frequency = <6000>;
> };
> };
>
> diff --git a/arch/riscv/include/asm/global_data.h
> b/arch/riscv/include/asm/global_data.h
> index 2eb14815bc..0dec5e669e 100644
> --- a/arch/riscv/include/asm/global_data.h
> +++ b/arch/riscv/include/asm/global_data.h
> @@ -24,9 +24,6 @@ struct arch_global_data {
> #ifdef CONFIG_ANDES_PLIC
> void __iomem *plic; /* plic base address */
> #endif
> -#ifdef CONFIG_ANDES_PLMT
> - void __iomem *plmt; /* plmt base address */
> -#endif
> #if CONFIG_IS_ENABLED(SMP)
> struct ipi_data ipi[CONFIG_NR_CPUS];
> #endif
> diff --git a/arch/riscv/lib/andes_plmt.c b/arch/riscv/lib/andes_plmt.c
> index a7e90ca992..b0245d0b52 100644
> --- a/arch/riscv/lib/andes_plmt.c
> +++ b/arch/riscv/lib/andes_plmt.c
> @@ -1,6 +1,7 @@
> // SPDX-License-Identifier: GPL-2.0+
> /*
> * Copyright (C) 2019, Rick Chen
> + * Copyright (C) 2020, Sean Anderson
> *
> * U-Boot syscon driver for Andes's Platform Level Machine Timer (PLMT).
> * The PLMT block holds memory-mapped mtime register
> @@ -9,46 +10,43 @@
>
> #include
> #include
> -#include
> -#include
> +#include
> #include
> -#include
> #include
>
> /* mtime register */
> #define MTIME_REG(base)((ulong)(base))
>
> -DECLARE_GLOBAL_DATA_PTR;
> -
> -#define PLMT_BASE_GET(void)\
> - do {\
> - long *ret; \
> - \
> - if (!gd->arch.plmt) { \
> - ret = syscon_get_first_range(RISCV_SYSCON_PLMT); \
> - if (IS_ERR(ret))\
> - return PTR_ERR(ret);\
> - gd->arch.plmt = ret;\
> - } \
> - } while (0)
> -
> -int riscv_get_time(u64 *time)
> +static int andes_plmt_get_count(struct udevice *dev, u64 *count)
> {
> - PLMT_BASE_GET();
> + *count = readq((void __iomem *)MTIME_REG(dev->priv));
>
> - *time = readq((void __iomem *)MTIME_REG(gd->arch.plmt));
> + return 0;
> +}
> +
> +static const struct timer_ops andes_plmt_ops = {
> + .get_count = andes_plmt_get_count,
> +};
> +
> +static int andes_plmt_probe(struct udevice
Re: [PATCH v3 1/7] riscv: Rework riscv timer driver to only support S-mode
> > The riscv-timer driver currently serves as a shim for several riscv timer > drivers. This is not too desirable because it bypasses the usual timer > selection via the driver model. There is no easy way to specify an > alternate timing driver, or have the tick rate depend on the cpu's > configured frequency. The timer drivers also do not have device structs, > and so have to rely on storing parameters in gd_t. Lastly, there is no > initialization call, so driver init is done in the same function which > reads the time. This can result in confusing error messages. To a user, it > looks like the driver failed when trying to read the time, whereas it may > have failed while initializing. > > This patch removes the shim functionality from the riscv-timer driver, and > has it instead implement the former rdtime.c timer driver. This is because > existing u-boot users who pass in a device tree (e.g. qemu) do not create a > timer device for S-mode u-boot. The existing behavior of creating the > riscv-timer device in the riscv cpu driver must be kept. The actual reading > of the CSRs has been redone in the style of Linux's get_cycles64. > > Signed-off-by: Sean Anderson > Reviewed-by: Bin Meng > --- > > (no changes since v2) > > Changes in v2: > - Remove RISCV_RDTIME KConfig option > > arch/riscv/Kconfig | 8 > arch/riscv/lib/Makefile | 1 - > arch/riscv/lib/rdtime.c | 38 > drivers/timer/Kconfig | 6 +++--- > drivers/timer/riscv_timer.c | 39 +++-- > 5 files changed, 23 insertions(+), 69 deletions(-) > delete mode 100644 arch/riscv/lib/rdtime.c > Reviewed-by: Rick Chen
Re: [PATCH 0/3] RISC-V tracing support
> From: Pragnesh Patel [mailto:pragnesh.pa...@sifive.com] > Sent: Monday, August 24, 2020 10:44 PM > To: u-boot@lists.denx.de; atish.pa...@wdc.com; bmeng...@gmail.com; > anup.pa...@wdc.com; sagar.ka...@sifive.com; Rick Jian-Zhi Chen(陳建志) > Cc: paul.walms...@sifive.com; Pragnesh Patel > Subject: [PATCH 0/3] RISC-V tracing support > > This series add a support of tracing for RISC-V arch. > > This series is also available here [1] for testing. > Series depends on [2]. > > [1] https://github.com/pragnesh26992/u-boot/tree/trace > [2] > https://patchwork.ozlabs.org/project/uboot/cover/20200729095636.1077054-1-sean...@gmail.com/ > > How to test this patch: > 1) Enable tracing in "configs/sifive_fu540_defconfig" > CONFIG_TRACE=y > CONFIG_TRACE_BUFFER_SIZE=0x0100 > CONFIG_TRACE_CALL_DEPTH_LIMIT=15 > CONFIG_CMD_TRACE=y > > 2) make FTRACE=1 sifive_fu540_defconfig > 3) make FTRACE=1 > > Following are the boot messages on FU540 five cores SMP platform: > > U-Boot 2020.10-rc1-02837-g8613dc2e66 (Aug 24 2020 - 20:03:47 +0530) > > CPU: rv64imac > Model: SiFive HiFive Unleashed A00 > DRAM: 8 GiB > trace: enabled > MMC: spi@1005:mmc@0: 0 > Loading Environment from SPIFlash... SF: Detected is25wp256 with page size > 256 Bytes, erase size 4 KiB, total 32 MiB > OK > In:serial@1001 > Out: serial@1001 > Err: serial@1001 > Board serial number should not be 0 !! > Net: > Warning: ethernet@1009 (eth0) using random MAC address - 92:a1:a7:02:5a:14 > eth0: ethernet@1009 > Hit any key to stop autoboot: 0 > => trace stats > 177,722 function sites > 37,057,350 function calls > 1 untracked function calls > 1,279,612 traced function calls (36015585 dropped due to overflow) > 19 maximum observed call depth > 15 call depth limit > 37,055,565 calls not traced due to depth > => > > > Pragnesh Patel (3): > riscv: Add timer_get_us() for tracing > riscv: Mark riscv_timer_get_count() and sifive_clint_get_count() with > 'notrace' > riscv: Mark andes_plmt_get_count() with 'notrace' > > arch/riscv/lib/Makefile | 1 + > arch/riscv/lib/andes_plmt.c | 2 +- > arch/riscv/lib/sifive_clint.c | 2 +- > arch/riscv/lib/timer.c| 50 +++ > drivers/timer/riscv_timer.c | 2 +- > 5 files changed, 54 insertions(+), 3 deletions(-) > create mode 100644 arch/riscv/lib/timer.c > > -- Tested-by: Rick Chen I have verified it in AE350 platfom as below: U-Boot 2020.10-rc1-05918-g658fb7e-dirty (Sep 03 2020 - 08:08:28 +0800) DRAM: 1 GiB trace: enabled Flash: 64 MiB MMC: mmc@f0e0: 0 Loading Environment from SPIFlash... SF: Detected mx25u1635e with page size 256 Bytes, erase size 4 KiB, total 2 MiB OK In:serial@f030 Out: serial@f030 Err: serial@f030 Net: no alias for ethernet0 Warning: mac@e010 (eth0) using random MAC address - 2a:6c:3c:57:4b:30 eth0: mac@e010 Hit any key to stop autoboot: 0 RISC-V # RISC-V # trace stats 166,074 function sites 1,071,417 function calls 1 untracked function calls 1,030,665 traced function calls 19 maximum observed call depth 15 call depth limit 1,145,728 calls not traced due to depth RISC-V # trace stats 166,074 function sites 2,552,905 function calls 1 untracked function calls 1,287,378 traced function calls (958047 dropped due to overflow) 19 maximum observed call depth 15 call depth limit 2,900,311 calls not traced due to depth RISC-V # Thanks, Rick
[PATCH] configs: powerpc: Don't set CONFIG_ENV_ADDR for T2080RDB_SPIFLASH
Setting CONFIG_ENV_ADDR to something other than 0 stops gd->env_addr from being allocated dynamically. When the environment is in SPI we need it to be allocated as we can't use a direct memory mapped address. Signed-off-by: Chris Packham --- configs/T2080RDB_SPIFLASH_defconfig | 1 - 1 file changed, 1 deletion(-) diff --git a/configs/T2080RDB_SPIFLASH_defconfig b/configs/T2080RDB_SPIFLASH_defconfig index 62cbab1f0734..ba4ac1010502 100644 --- a/configs/T2080RDB_SPIFLASH_defconfig +++ b/configs/T2080RDB_SPIFLASH_defconfig @@ -50,7 +50,6 @@ CONFIG_MTDPARTS_DEFAULT="mtdparts=fe800.nor:1m(uboot),5m(kernel),128k(dtb),9 CONFIG_OF_CONTROL=y CONFIG_ENV_OVERWRITE=y CONFIG_ENV_IS_IN_SPI_FLASH=y -CONFIG_ENV_ADDR=0xFFFC9000 CONFIG_DM=y CONFIG_FSL_CAAM=y CONFIG_DM_I2C=y -- 2.28.0
[PATCH v1] armv8: MMU: Fix the memory map for RAM
From: Marek Bykowski
The objective of this patch is to impose the correct attributes to
the RAM memory for the ARM CPU, as shown in the diagram below:
--
Non-Cached || Read-Write
Ordered | Peripherals |Not-Executable
-|
|| Read-Write
Cacheable | Data |Not-Executable
-|
|| Read-Only
Cacheable | Code |Not-Executable
-|
|Non-U-Boot image| Read-Write
Cacheable |eg. efi | Executable
--
U-Boot adheres into attributing the peripheral region/s into Read-Write,
Not-Executable but it actually fails attributing the RAM correctly.
It combines the whole RAM into Read-Write, Executable, in which the Code
should be Read-Only, Executable and the Data - Read-Write, Non-Executable.
Also the (optional) Non-U-Boot region/s, eg. EFI, PSCI, holding
the Code and Data need updating but it is left to the developers of
the image/s to do so, if needed. Generally any new mapping introduced
should take account of the appropriate attributes for
the Instructions and Data.
The reason it is important is that these attrributes control how
the processor interacts with a location. Such as, if a location the ARM CPU
is accessing is Executable (translation table descriptor Execute-Never
attribute bit cleared) then the ARM CPU fetches a number of instructions
from that location, all at the same time. For example, Cortex-A57 can
source up to 128 bits per fetch depending on an alignment. If the CPU
mispredicts to the Execute-Never region, it creates the memory fault but
it actually never uses the instructions mispredicted. The CPU branches
away elsewhere.
Therefore, as long as the MMU is programmed correctly these mispredictions
will only affect the performance. But if we fail programming the MMU
correctly and if the instruction fetch logic mispredicts to
the non-instruction memory it may eventually perturb it, eg. corrupt
the FIFO, the control registers, or load the unified cache with
the instructions the data side memory system hits into subsequently.
Following an application of the memory map as per-diagram above
an attempt to execute an instruction fetched from the Non-Executable memory
creates an Instruction Abort. Similarly, an attempt to Write to an address
marked as Read-Only will result in with a Data Abort. Both aborts are
labelled as Permission Faults and are easy to catch by the processor.
Signed-off-by: Marek Bykowski
---
Changes in PATCH v1:
- now it re-maps the whole RAM to the proper attributes,
- took account of other images, eg. PSCI, EFI that need a separate attention
- it has been tested on qemu arm 64 and two of my armv8 boards, one is Axxia
series of the processor, the other is so early that the name cannot be
revealed yet
arch/arm/cpu/armv8/cache_v8.c| 103 +++
arch/arm/cpu/armv8/u-boot.lds| 39 ++--
arch/arm/include/asm/armv8/mmu.h | 6 ++
arch/arm/lib/sections.c | 19 --
include/asm-generic/sections.h | 9 +++
5 files changed, 164 insertions(+), 12 deletions(-)
diff --git a/arch/arm/cpu/armv8/cache_v8.c b/arch/arm/cpu/armv8/cache_v8.c
index 7c31d98a6f..4d8843d05e 100644
--- a/arch/arm/cpu/armv8/cache_v8.c
+++ b/arch/arm/cpu/armv8/cache_v8.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
DECLARE_GLOBAL_DATA_PTR;
@@ -364,6 +365,100 @@ __weak u64 get_page_table_size(void)
return size;
}
+__weak void force_remaping_ram(void)
+{
+ int i = 0;
+
+ if (!(gd->flags & GD_FLG_RELOC))
+ return;
+
+ struct mm_region mem_map_ram[] = {
+ /*
+* Re-map the whole RAM to Read-Write, Non-Executable, and
+* then .text section/s to Read-Only, Executable.
+*/
+ {
+ .virt = (u64)gd->ram_base,
+ .phys = (u64)gd->ram_base,
+ .size = (u64)gd->ram_size,
+ .attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
+PTE_BLOCK_INNER_SHARE |
+PTE_BLOCK_UXN
+ },
+#if IS_ENABLED(CONFIG_EFI_LOADER)
+ {
+ .virt = (u64)__efi_runtime_start_section,
+ .phys = (u64)__efi_runtime_start_section,
+ .size = (u64)(__efi_runtime_stop_section -
+ __efi_runtime_start_section),
+ .attrs = (PTE_BLOCK_MEMTYPE(MT_NORMAL) |
+ PTE_BLOCK_INNER_SHARE) & ~PTE_BLOCK_UXN
+ },
+ {
+ .virt =
Re: u-boot crash on T2080RDB_SPIFLASH
On Wed, Sep 2, 2020 at 5:22 PM Chris Packham wrote: > > Hi, > > Just tried out v2020.10-rc3 on my T2080RDB and I've got the following > splat. Haven't had a chance to decode it yet (pointers on how to > translate the addresses for powerpc welcome) but I figured I'd get > this out just in case anyone was looking at the T2080RDB. > > SPI boot... > Initializingusing SPD > 2 GiB left unmapped > Loading second stage boot loader > . > > U-Boot 2020.10-rc3-00052-g502f0489f125 (Sep 02 2020 - 16:58:30 +1200) > > CPU0: T2080E, Version: 1.1, (0x85380011) > Core: e6500, Version: 2.0, (0x80400120) > Clock Configuration: >CPU0:1799.820 MHz, CPU1:1799.820 MHz, CPU2:1799.820 MHz, > CPU3:1799.820 MHz, >CCB:599.940 MHz, >DDR:933.310 MHz (1866.620 MT/s data rate) (Asynchronous), IFC:599.940 > MHz >FMAN1: 699.930 MHz >QMAN: 299.970 MHz >PME: 599.940 MHz > L1:D-cache 32 KiB enabled >I-cache 32 KiB enabled > Reset Configuration Word (RCW): >: 1207001b 1500 >0010: 66150002 58104000 c100 >0020: 0080 000307fc >0030: 0004 > Model: fsl,T2080RDB > Board: T2080RDB, Board rev: 0x01 CPLD ver: 0x03, boot from SPI > SERDES Reference Clocks: > SD1_CLK1=156.25MHZ, SD1_CLK2=100.00MHZ > SD2_CLK1=100.00MHZ, SD2_CLK2=100.00MHZ > DRAM: Detected UDIMM D3XP56082XL10AA > 2 GiB left unmapped > 2 GiB (DDR3, 64-bit, CL=13, ECC on) >DDR Chip-Select Interleaving Mode: CS0+CS1 > VID: Could not find voltage regulator on I2C. > Warning: Adjusting core voltage failed. > Flash: 128 MiB > L2:2 MiB enabled > Corenet Platform Cache: 512 KiB enabled > Using SERDES1 Protocol: 102 (0x66) > Using SERDES2 Protocol: 21 (0x15) > WARN: pls set popts->cpo_sample = 0x54 in /ddr.c to optimize cpo > SEC0: RNG instantiated > MMC: FSL_SDHC: 0 > Loading Environment from SPIFlash... SF: Detected n25q512ax3 with page > size 256 Bytes, erase size 4 KiB, total 64 MiB > Bad trap at PC: 7ff7c9ec, SR: 21200, vector=d00 > NIP: 7FF7C9EC XER: LR: 7FF4942C REGS: 7fb2c8b0 TRAP: 0d00 DAR: > FFFC9004 > MSR: 00021200 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 00 > > GPR00: 7FF49570 7FB2C9A0 7FB2DE80 7FB2DEFC 0020 7FB2CB04 7FFB1B64 > GPR08: 0008 FFFC9004 0001 7FB2CB20 42002004 0003 7FF9F738 > GPR16: 7FB2CB90 7FB2CB78 7FB2CB68 0800 7FB30B58 > GPR24: 0C94 7FB2DEFC 7FF9C695 0020 7FFABA14 7FB337F8 > Call backtrace: > 7FF49570 7FF7D714 7FF8BE58 7FF8C8B8 7FF7C6FC 7FF7D8C4 > 7FF7CA88 7FF4C59C 7FF4C864 7FF31040 > Exception in kernel pc 7ff7c9ec signal 0 > ### ERROR ### Please RESET the board ### Now I've got access to the system with a JTAG debugger, I can see that the crash is in the env_load() path. The problem appears to be that gd->env_addr is pointing to 0xfffc9004 which was valid at some point (possibly a local address mapping of the SPI) but by the time env_load() is run it's no longer valid.
Re: [PATCHv4 0/9] Introduce B1x5v2 support
Hi Sebastian, On Wed, Sep 2, 2020 at 2:31 PM Sebastian Reichel wrote: > > This series introduces support for a new i.MX6DL based GE patient > monitor series. > > Patch 1: Add support for storing bootcount in SPI-flash > Patch 2+3: Improve M41T62 RTC driver's reset routine. > PATCH 4: Support disable_ldb_di_clock_sources for i.MX6DL > Patch 5: Add poweroff-gpio support > Patch 6-8: restructure common GE code > Patch 9: Add the actual board, using SPL and DM > > Changes since PATCHv3 [0]: > * Dropped patch for reading DR for i.MX GPIOs and set >SION pinmux bits in B1x5v2 output GPIOs instead > * Rebased to v2020.10-rc3 Thanks for the respin. This version looks good: Reviewed-by: Fabio Estevam
Re: [PATCH] buildman: Use git worktrees instead of git clones
On 02/09/2020 20:07, Simon Glass wrote: > It looks like that version of git was not in Ubuntu 14.04 but appeared > in 16.04. I've just done some patches to make patman work in 14.04, so > I'd prefer to keep buildman working for that also. I'll keep that in mind. Looks like Ubuntu 14.04 has python v3.4 and git v1.9. I'm used to more recent versions so maybe I'll take the time to set up a VM to test things in. > So I think we should have an option to keep the old behaviour, or > perhaps detect when 'git worktree' is not available and fall back. I can check whether 'git worktree list' succeeds, it should have no effect on the repo but would give a 'not a git command' error if things wouldn't work; in which case buildman could fall back to cloning. I'll implement and send a v2 with something like that.
Re: [PATCH v5 10/11] riscv: Add pinmux and gpio bindings for Kendryte K210
On 9/2/20 2:04 PM, Heinrich Schuchardt wrote:
> On 15.08.20 17:52, Sean Anderson wrote:
>> This patch adds the necessary device tree bindings.
>>
>> Signed-off-by: Sean Anderson
>> Reviewed-by: Simon Glass
>> ---
>>
>> (no changes since v2)
>>
>> Changes in v2:
>> - Convert to use pinmux property
>> - Don't hog ISP on boot
>> - Re-order GPIOs to match the defaults more closely
>>
>> arch/riscv/dts/k210-maix-bit.dts | 104 +++
>> arch/riscv/dts/k210.dtsi | 12
>> 2 files changed, 116 insertions(+)
>>
>> diff --git a/arch/riscv/dts/k210-maix-bit.dts
>> b/arch/riscv/dts/k210-maix-bit.dts
>> index 5b32c5fd5f..e840e04ada 100644
>> --- a/arch/riscv/dts/k210-maix-bit.dts
>> +++ b/arch/riscv/dts/k210-maix-bit.dts
>> @@ -17,6 +17,22 @@
>> stdout-path = "serial0:115200";
>> };
>>
>> +gpio-leds {
>> +compatible = "gpio-leds";
>> +
>> +green {
>> +gpios = <_0 4 GPIO_ACTIVE_LOW>;
>> +};
>> +
>> +red {
>> +gpios = <_0 5 GPIO_ACTIVE_LOW>;
>> +};
>> +
>> +blue {
>> +gpios = <_0 6 GPIO_ACTIVE_LOW>;
>> +};
>> +};
>> +
>> sound {
>> compatible = "simple-audio-card";
>> simple-audio-card,format = "i2s";
>> @@ -39,9 +55,97 @@
>> };
>>
>> {
>> +pinctrl-0 = <_uarths>;
>> +pinctrl-names = "default";
>> +status = "okay";
>> +};
>> +
>> + {
>> +pinctrl-0 = <_gpiohs>;
>> +pinctrl-names = "default";
>> +status = "okay";
>> +};
>> +
>> + {
>> +pinctrl-0 = <_gpio>;
>> +pinctrl-names = "default";
>> status = "okay";
>> };
>>
>> {
>> #sound-dai-cells = <1>;
>> +pinctrl-0 = <_i2s0>;
>> +pinctrl-names = "default";
>> +};
>> +
>> + {
>> +status = "okay";
>> +
>> +fpioa_uarths: uarths {
>> +pinmux = ,
>> + ;
>> +};
>> +
>> +fpioa_gpio: gpio {
>> +pinmux = ,
>> + ,
>> + ,
>> + ,
>> + ,
>> + ,
>> + ,
>> + ;
>
> On the Maixduino the K210 package pins IO_6 - IO_9, IO_25 - IO_29 serve
> as interface to the ESP32 which is used for WLAN. In the schema for the
> Maixduino the naming is:
>
> IO_6 - ESP32_TX
> IO_7 - ESP32_RX
> IO_8 - ESP32_EN
> IO_9 - ESP32_READY
>
> IO_6 and IO_7 are not mapped in reset state and in a Python example I
> found for connecting to a WLAN these lines were not used.
>
> If the usage of IO_8 and IO_9 differs between the Maixduino and the Maix
> Bit, shouldn't they be mapped in k210-maix-bit.dts instead of k210.dtsi?
These *are* in k210-maix-bit.dts.
>
> According to https://github.com/sipeed/MaixPy/issues/127 one of the SPI
> interfaces is switched between SD-card and WLAN. The ESP32 connection
> uses gpiohs while the SD card does not.
>
>> +};
>> +
>> +fpioa_gpiohs: gpiohs {
>> +pinmux = ,
>
> IO_16 is connected to the boot button on the Maixduino and Maix Fit
> boards. So I guess we should add an entry compatible = "gpio-keys" for
> it and add a comment here.
I saw you created a patch for this [1]. Would you like to keep that
separate, or should I add it to this series?
[1]
https://patchwork.ozlabs.org/project/uboot/patch/20200902201159.98034-1-xypron.g...@gmx.de/
>> + ,
>> + ,
>> + ,
>> + ,
>> + ,
>> + ,
>> + ,
>> + ,
>> + ,
>> + ,
>> + ,
>> + ;
>> +};
>> +
>> +fpioa_i2s0: i2s0 {
>> +pinmux = ,
>> + ,
>> + ;
>> +};
>> +
>> +fpioa_dvp: dvp {
>> +pinmux = ,
>
> DVP_SDA in 'Maix-Bit-V2.0(Pin assignment table.xlsx'
>
>> + ,
>
> DVP_SCL
>
>> + ,
>
> DVP_RST
>
>> + ,
>
> DVP_VSYNC
>
>> + ,
>
> DVP_PWDN
>
>> + ,
>
> DVP_HSYNC
>
>> + ,
>
> DVP_XCLK
>
>> + ;
>
> DVP_PCLK
>
>> +};
>> +
>> +fpioa_spi0: spi0 {
>> +pinmux = , /* cs */
>
> LCD_CS in 'Maix-Bit-V2.0(Pin assignment table.xlsx'
>
>> + , /* rst */
>
> LCD_RST
>
>> + , /* dc */
>
> LCD_DC
>
>> + ; /* wr */
>
> LCD_WR
>
> Should the comments be updated to reflect the connection to LCD?
Sure.
>> +};
>> +
>> +fpioa_spi1: spi1 {
>> +pinmux = ,
>
> SPI0 MISO in 'Maix-Bit-V2.0(Pin assignment table.xlsx'
>
>> + ,
>
> SPI0 SCLK
>
>> + ,
>
> SPI0 MOSI
>
>> + ;
>
> SPI0_CS0
>
> Should we add comments?
I will
[PATCH 1/1] riscv: add DT binding for BOOT button on Maix board
Add a device tree binding for the BOOT button on the Maix board.
Signed-off-by: Heinrich Schuchardt
---
Together with
[PATCH 1/1] cmd/button: return button status
https://lists.denx.de/pipermail/u-boot/2020-September/425221.html
we can use the button status to decide which program to boot.
---
arch/riscv/dts/k210-maix-bit.dts | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/riscv/dts/k210-maix-bit.dts b/arch/riscv/dts/k210-maix-bit.dts
index e840e04ada..c2beec602c 100644
--- a/arch/riscv/dts/k210-maix-bit.dts
+++ b/arch/riscv/dts/k210-maix-bit.dts
@@ -8,6 +8,7 @@
#include "k210.dtsi"
#include
+#include
/ {
model = "Sipeed Maix Bit 2.0";
@@ -33,6 +34,16 @@
};
};
+ gpio-keys {
+ compatible = "gpio-keys";
+
+ boot {
+ label = "BOOT";
+ linux,code = ;
+ gpios = < 0 GPIO_ACTIVE_LOW>;
+ };
+ };
+
sound {
compatible = "simple-audio-card";
simple-audio-card,format = "i2s";
--
2.28.0
[PATCH 1/1] cmd/button: return button status
To make the button command useful in a shell script it should return the status of the button: * 0 (true) - pressed, on * 1 (false) - not pressed, off The button command takes only one argument. Correct maxargs. Signed-off-by: Heinrich Schuchardt --- cmd/button.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/cmd/button.c b/cmd/button.c index 84ad1653c7..64c5a8fa04 100644 --- a/cmd/button.c +++ b/cmd/button.c @@ -75,11 +75,11 @@ int do_button(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[]) ret = show_button_state(dev); - return 0; + return !ret; } U_BOOT_CMD( - button, 4, 1, do_button, + button, 2, 1, do_button, "manage buttons", " \tGet button state\n" "button list\t\tShow a list of buttons" -- 2.28.0
Re: [PATCHv4 9/9] board: ge: b1x5v2: Add GE B1x5v2 and B1x5Pv2
On Wed, Sep 02, 2020 at 07:31:46PM +0200, Sebastian Reichel wrote: > GE B1x5v2 patient monitor series is similar to the CARESCAPE Monitor > series (GE Bx50). It consists of a carrier PCB used in combination > with a Congatec QMX6 SoM. This adds U-Boot support using device model > everywhere and SPL for memory initialization. > > Proper configuration is provided as 'ge_b1x5v2_defconfig' and the > combined image u-boot-with-spi.imx can be flashed directly to 1024 > byte offset to /dev/mtdblock0. Alternatively SPL and u-boot.imx can > be loaded separately via USB-OTG using e.g. imx_usb. > > Signed-off-by: Sebastian Reichel As I went checking for a good sized gap between kernel and dtb, and I see it's got I was looking for: Reviewed-by: Tom Rini -- Tom signature.asc Description: PGP signature
Re: [PATCH] arm64: Add support for bigger u-boot when CONFIG_POSITION_INDEPENDENT=y
On 02/09/2020 16:25, Edgar E. Iglesias wrote: > On Wed, Sep 02, 2020 at 04:18:48PM +0100, Andr� Przywara wrote: >> On 02/09/2020 15:53, Edgar E. Iglesias wrote: >>> On Wed, Sep 02, 2020 at 03:43:08PM +0100, Andr� Przywara wrote: On 02/09/2020 12:15, Michal Simek wrote: >> >> Hi, >> > From: "Edgar E. Iglesias" > > When U-Boot binary exceeds 1MB with CONFIG_POSITION_INDEPENDENT=y > compilation error is shown: > /mnt/disk/u-boot/arch/arm/cpu/armv8/start.S:71:(.text+0x3c): relocation > truncated to fit: R_AARCH64_ADR_PREL_LO21 against symbol `__rel_dyn_end' > defined in .bss_start section in u-boot. > > It is caused by adr instruction which permits the calculation of any byte > address within +- 1MB of the current PC. > Because U-Boot is bigger then 1MB calculation is failing. > > The patch is using adrp/add instructions where adrp shifts a signed, > 21-bit > immediate left by 12 bits (4k page), adds it to the value of the program > counter with the bottom 12 bits cleared to zero. Then add instruction > provides the lower 12 bits which is offset within 4k page. > These two instructions together compose full 32bit offset which should be > more then enough to cover the whole u-boot size. > > Signed-off-by: Edgar E. Iglesias > Signed-off-by: Michal Simek It's a bit scary that you need more than 1MB, but indeed what you do below is the canonical pattern to get the full range of PC relative addressing (this is used heavily in Trusted Firmware, for instance). The only thing to keep in mind is that this assumes that the load address of the binary is 4K aligned, so that the low 12 bits of the symbol stay the same. I wonder if we should enforce this somehow? But the load address is not controlled by the build process (the whole purpose of PIE), so that's not doable just in the build system? >>> >>> There shouldn't be any need for 4K alignment. Could you elaborate on >>> why you think there is? >> >> That seems to be slightly tricky, and I tried to get some confirmation, >> but here goes my reasoning. Maybe you can confirm this: >> >> - adrp takes the relative offset, but only of the upper 20 bits (because >> that's all we can encode). It clears the lower 12 bits of the register. >> - the "add" is not PC relative anymore, so it just takes the lower 12 >> bits of the "absolute" linker symbol. > > I was under the impression that this would use a PC-relative lower 12bit > relocation but you are correct. I dissasembled the result: > > 40: 9142add x2, x2, #0x0 > 40: R_AARCH64_ADD_ABS_LO12_NC __rel_dyn_start > > > > > >> So this assumes that the lower 12 bits of the actual address in memory >> and the lower 12 bits of the linker's view match. >> An example: >> 00024: adrp x0, SYMBOL >> 00028: add x0, x0, :lo12:SYMBOL >> >> SYMBOL: >> 42058: ... >> >> The toolchain will generate: >> adrp x0, #0x42; add x0, x0, #0x058 >> >> Now you load the code to 0x8000.0800 (NOT 4K aligned). SYMBOL is now at >> 0x80042858. >> The adrp will use the PC (0x8000.0824) & ~0xfff + offs => 0x8004.2000. >> The add will just add 0x58, so you end up with x0 being 0x80042058, >> which is not the right address. >> >> Does this make sense? > > > Yes, it makes sense. > >> >>> Perhaps the commit message is a little confusing. The toolchain will >>> compute the pc-relative offset from this particular location to the >>> symbol and apply the relocations accordingly. >> >> Yes, but the PC relative offset applies only to the upper 20 bits, >> because it's only adrp that has PC relative semantics. >> >> Shall we at least document this? I guess typical load address are actually quite well aligned, so it might not be an issue in practice. > > Yes, probably worth documenting and perhaps an early bail-out if it's not > the case... Documenting sounds good, Kconfig might be a good place, as Michal suggested. Bail out: I thought about that, it's very easy to detect at runtime, but what then? This is really early, so you could just enter a WFI loop, and hope for someone to connect the dots? Or can you think of any other way of communicating with the user? Cheers, Andre
Re: [PATCH v5 10/11] riscv: Add pinmux and gpio bindings for Kendryte K210
On 15.08.20 17:52, Sean Anderson wrote:
> This patch adds the necessary device tree bindings.
>
> Signed-off-by: Sean Anderson
> Reviewed-by: Simon Glass
> ---
>
> (no changes since v2)
>
> Changes in v2:
> - Convert to use pinmux property
> - Don't hog ISP on boot
> - Re-order GPIOs to match the defaults more closely
>
> arch/riscv/dts/k210-maix-bit.dts | 104 +++
> arch/riscv/dts/k210.dtsi | 12
> 2 files changed, 116 insertions(+)
>
> diff --git a/arch/riscv/dts/k210-maix-bit.dts
> b/arch/riscv/dts/k210-maix-bit.dts
> index 5b32c5fd5f..e840e04ada 100644
> --- a/arch/riscv/dts/k210-maix-bit.dts
> +++ b/arch/riscv/dts/k210-maix-bit.dts
> @@ -17,6 +17,22 @@
> stdout-path = "serial0:115200";
> };
>
> + gpio-leds {
> + compatible = "gpio-leds";
> +
> + green {
> + gpios = <_0 4 GPIO_ACTIVE_LOW>;
> + };
> +
> + red {
> + gpios = <_0 5 GPIO_ACTIVE_LOW>;
> + };
> +
> + blue {
> + gpios = <_0 6 GPIO_ACTIVE_LOW>;
> + };
> + };
> +
> sound {
> compatible = "simple-audio-card";
> simple-audio-card,format = "i2s";
> @@ -39,9 +55,97 @@
> };
>
> {
> + pinctrl-0 = <_uarths>;
> + pinctrl-names = "default";
> + status = "okay";
> +};
> +
> + {
> + pinctrl-0 = <_gpiohs>;
> + pinctrl-names = "default";
> + status = "okay";
> +};
> +
> + {
> + pinctrl-0 = <_gpio>;
> + pinctrl-names = "default";
> status = "okay";
> };
>
> {
> #sound-dai-cells = <1>;
> + pinctrl-0 = <_i2s0>;
> + pinctrl-names = "default";
> +};
> +
> + {
> + status = "okay";
> +
> + fpioa_uarths: uarths {
> + pinmux = ,
> + ;
> + };
> +
> + fpioa_gpio: gpio {
> + pinmux = ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ;
On the Maixduino the K210 package pins IO_6 - IO_9, IO_25 - IO_29 serve
as interface to the ESP32 which is used for WLAN. In the schema for the
Maixduino the naming is:
IO_6 - ESP32_TX
IO_7 - ESP32_RX
IO_8 - ESP32_EN
IO_9 - ESP32_READY
IO_6 and IO_7 are not mapped in reset state and in a Python example I
found for connecting to a WLAN these lines were not used.
If the usage of IO_8 and IO_9 differs between the Maixduino and the Maix
Bit, shouldn't they be mapped in k210-maix-bit.dts instead of k210.dtsi?
According to https://github.com/sipeed/MaixPy/issues/127 one of the SPI
interfaces is switched between SD-card and WLAN. The ESP32 connection
uses gpiohs while the SD card does not.
> + };
> +
> + fpioa_gpiohs: gpiohs {
> + pinmux = ,
IO_16 is connected to the boot button on the Maixduino and Maix Fit
boards. So I guess we should add an entry compatible = "gpio-keys" for
it and add a comment here.
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ;
> + };
> +
> + fpioa_i2s0: i2s0 {
> + pinmux = ,
> + ,
> + ;
> + };
> +
> + fpioa_dvp: dvp {
> + pinmux = ,
DVP_SDA in 'Maix-Bit-V2.0(Pin assignment table.xlsx'
> + ,
DVP_SCL
> + ,
DVP_RST
> + ,
DVP_VSYNC
> + ,
DVP_PWDN
> + ,
DVP_HSYNC
> + ,
DVP_XCLK
> + ;
DVP_PCLK
> + };
> +
> + fpioa_spi0: spi0 {
> + pinmux = , /* cs */
LCD_CS in 'Maix-Bit-V2.0(Pin assignment table.xlsx'
> + , /* rst */
LCD_RST
> + , /* dc */
LCD_DC
> + ; /* wr */
LCD_WR
Should the comments be updated to reflect the connection to LCD?
> + };
> +
> + fpioa_spi1: spi1 {
> + pinmux = ,
SPI0 MISO in 'Maix-Bit-V2.0(Pin assignment table.xlsx'
> + ,
SPI0 SCLK
> + ,
SPI0 MOSI
> + ;
SPI0_CS0
Should we add comments?
Best regards
Heinrich
> + };
> +};
> +
> + {
> + pinctrl-0 = <_dvp>;
> + pinctrl-names = "default";
> };
> diff --git a/arch/riscv/dts/k210.dtsi b/arch/riscv/dts/k210.dtsi
> index 2546c7d4e0..fc7986b326 100644
> --- a/arch/riscv/dts/k210.dtsi
> +++ b/arch/riscv/dts/k210.dtsi
> @@ -5,6 +5,7 @@
>
> #include
> #include
> +#include
> #include
>
> / {
> @@ -367,7 +368,18 @@
> reg = <0x502B 0x100>;
> clocks = <
Re: [PATCH] travis-ci: Add SH4 r2dplus machine with various PCI ethernet options
On 8/5/20 3:26 PM, Marek Vasut wrote: > Add SH4 R2Dplus machine configured to test various U-Boot PCI ethernet > options -- RTL8139, EEPRO100, AMD PCnet, DEC Tulip. Sorry for the delay. I've applied this now.
[PATCHv4 7/9] board: ge: common: add config option for RTC and VPD feature
While this code is being used by all GE platforms its useful to have it behind a config option for hardware bringup of new platforms. Signed-off-by: Sebastian Reichel --- board/ge/bx50v3/Kconfig | 2 ++ board/ge/common/Kconfig | 7 +++ board/ge/common/Makefile | 3 ++- board/ge/mx53ppd/Kconfig | 2 ++ 4 files changed, 13 insertions(+), 1 deletion(-) create mode 100644 board/ge/common/Kconfig diff --git a/board/ge/bx50v3/Kconfig b/board/ge/bx50v3/Kconfig index 993b0559302b..05938560abda 100644 --- a/board/ge/bx50v3/Kconfig +++ b/board/ge/bx50v3/Kconfig @@ -15,4 +15,6 @@ config SYS_SOC config SYS_CONFIG_NAME default "ge_bx50v3" +source "board/ge/common/Kconfig" + endif diff --git a/board/ge/common/Kconfig b/board/ge/common/Kconfig new file mode 100644 index ..323ed1f99607 --- /dev/null +++ b/board/ge/common/Kconfig @@ -0,0 +1,7 @@ +config GE_VPD + bool "Enable GE VPD Support" + default y + +config GE_RTC + bool "Enable GE RTC Support" + default y diff --git a/board/ge/common/Makefile b/board/ge/common/Makefile index 36bedb198077..8bd44e3c8a0f 100644 --- a/board/ge/common/Makefile +++ b/board/ge/common/Makefile @@ -2,4 +2,5 @@ # # Copyright 2017 General Electric Company -obj-y := vpd_reader.o ge_rtc.o +obj-$(CONFIG_GE_VPD) += vpd_reader.o +obj-$(CONFIG_GE_RTC) += ge_rtc.o diff --git a/board/ge/mx53ppd/Kconfig b/board/ge/mx53ppd/Kconfig index 6dc3818cb7bb..bebb2fab0173 100644 --- a/board/ge/mx53ppd/Kconfig +++ b/board/ge/mx53ppd/Kconfig @@ -13,4 +13,6 @@ config SYS_SOC config SYS_CONFIG_NAME default "mx53ppd" +source "board/ge/common/Kconfig" + endif -- 2.28.0
[PATCHv4 9/9] board: ge: b1x5v2: Add GE B1x5v2 and B1x5Pv2
GE B1x5v2 patient monitor series is similar to the CARESCAPE Monitor
series (GE Bx50). It consists of a carrier PCB used in combination
with a Congatec QMX6 SoM. This adds U-Boot support using device model
everywhere and SPL for memory initialization.
Proper configuration is provided as 'ge_b1x5v2_defconfig' and the
combined image u-boot-with-spi.imx can be flashed directly to 1024
byte offset to /dev/mtdblock0. Alternatively SPL and u-boot.imx can
be loaded separately via USB-OTG using e.g. imx_usb.
Signed-off-by: Sebastian Reichel
---
arch/arm/dts/Makefile | 1 +
arch/arm/dts/imx6dl-b1x5v2.dts | 654 ++
arch/arm/mach-imx/mx6/Kconfig | 9 +
board/ge/b1x5v2/Kconfig| 14 +
board/ge/b1x5v2/Makefile | 6 +
board/ge/b1x5v2/b1x5v2.c | 698 +
board/ge/b1x5v2/spl.c | 587 +++
configs/ge_b1x5v2_defconfig| 137 +++
include/configs/ge_b1x5v2.h| 127 ++
9 files changed, 2233 insertions(+)
create mode 100644 arch/arm/dts/imx6dl-b1x5v2.dts
create mode 100644 board/ge/b1x5v2/Kconfig
create mode 100644 board/ge/b1x5v2/Makefile
create mode 100644 board/ge/b1x5v2/b1x5v2.c
create mode 100644 board/ge/b1x5v2/spl.c
create mode 100644 configs/ge_b1x5v2_defconfig
create mode 100644 include/configs/ge_b1x5v2.h
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index f8f529435bf1..db0b2bdaf505 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -975,6 +975,7 @@ dtb-$(CONFIG_TARGET_GE_BX50V3) += \
imx6q-b650v3.dtb \
imx6q-b450v3.dtb
+dtb-$(CONFIG_TARGET_GE_B1X5V2) += imx6dl-b1x5v2.dtb
dtb-$(CONFIG_TARGET_MX53PPD) += imx53-ppd.dtb
dtb-$(CONFIG_TARGET_VEXPRESS_CA5X2) += vexpress-v2p-ca5s.dtb
diff --git a/arch/arm/dts/imx6dl-b1x5v2.dts b/arch/arm/dts/imx6dl-b1x5v2.dts
new file mode 100644
index ..78baec1e73a1
--- /dev/null
+++ b/arch/arm/dts/imx6dl-b1x5v2.dts
@@ -0,0 +1,654 @@
+/*
+ * GE B1x5v2 Patient Monitor
+ *
+ * Copyright 2018-2020 GE Inc.
+ * Copyright 2018-2020 Collabora Ltd.
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+/dts-v1/;
+
+#include "imx6dl.dtsi"
+#include
+
+/ {
+ compatible = "ge,imx6dl-b1x5v2", "congatec,qmx6", "fsl,imx6dl";
+
+ chosen {
+ bootargs = "console=ttymxc2,115200";
+ stdout-path =
+ };
+
+ reg_3p3v: 3p3v {
+ compatible = "regulator-fixed";
+ regulator-name = "3P3V";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ regulator-always-on;
+ };
+
+ reg_5v: regulator-5v {
+ compatible = "regulator-fixed";
+ regulator-name = "5V";
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ regulator-always-on;
+ };
+
+ reg_5v0_audio: regulator-5v0-audio {
+ compatible = "regulator-fixed";
+ regulator-name = "5V0_AUDIO";
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ vin-supply = <_5v>;
+
+ gpio = < 16 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+
+ /*
+* This must be always-on for da7212, which has some not
properly
+* documented dependencies for it's speaker supply pin. The
issue
+* manifests as speaker volume being very low.
+*/
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ reg_lcd: regulator-lcd {
+ compatible = "regulator-fixed";
+ regulator-name = "LED_VCC";
+ regulator-min-microvolt = <1200>;
+ regulator-max-microvolt = <1200>;
+
+ pinctrl-0 = <_q7_lcd_power>;
+ pinctrl-names = "default";
+ gpio = < 7 GPIO_ACTIVE_HIGH>; // LCDPWR
+ enable-active-high;
+ };
+
+ usb_power: regulator-usb-power {
+ compatible = "regulator-fixed";
+ regulator-name = "USB POWER";
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ vin-supply = <_5v>;
+ };
+
+ backlight: backlight {
+ compatible = "pwm-backlight";
+ pinctrl-names = "default";
+ pinctrl-0 = <_q7_backlight_enable>;
+ power-supply = <_lcd>;
+ pwms = < 0 500>;
+ brightness-levels = <0 4 8 16 32 64 128 255>;
+ default-brightness-level = <7>;
+ enable-gpios = < 9 GPIO_ACTIVE_HIGH>;
+ };
+
+ panel {
+ compatible = "simple-panel";
+ backlight = <>;
+
+ port {
+ panel_in: endpoint {
+
[PATCHv4 8/9] board: ge: common: vpd: separate I2C specific code
This separates the I2C specific code from the generic
GE vital product data code, so that the generic parts
can be used on hardware with VPD stored in SPI flash
memory.
Signed-off-by: Sebastian Reichel
---
board/ge/bx50v3/bx50v3.c | 2 +-
board/ge/common/vpd_reader.c | 12 ++--
board/ge/common/vpd_reader.h | 23 +++
board/ge/mx53ppd/mx53ppd.c | 2 +-
4 files changed, 27 insertions(+), 12 deletions(-)
diff --git a/board/ge/bx50v3/bx50v3.c b/board/ge/bx50v3/bx50v3.c
index c6b0af8c776a..8a38ac5d4e4c 100644
--- a/board/ge/bx50v3/bx50v3.c
+++ b/board/ge/bx50v3/bx50v3.c
@@ -429,7 +429,7 @@ static void set_confidx(const struct vpd_cache* vpd)
int board_init(void)
{
- if (!read_vpd(, vpd_callback)) {
+ if (!read_i2c_vpd(, vpd_callback)) {
int ret, rescan;
vpd.is_read = true;
diff --git a/board/ge/common/vpd_reader.c b/board/ge/common/vpd_reader.c
index d42b00da2fe6..421fee592291 100644
--- a/board/ge/common/vpd_reader.c
+++ b/board/ge/common/vpd_reader.c
@@ -110,9 +110,9 @@ static const size_t HEADER_BLOCK_ECC_LEN = 4;
static const u8 ECC_BLOCK_ID = 0xFF;
-static int vpd_reader(size_t size, u8 *data, struct vpd_cache *userdata,
- int (*fn)(struct vpd_cache *, u8 id, u8 version, u8 type,
- size_t size, u8 const *data))
+int vpd_reader(size_t size, u8 *data, struct vpd_cache *userdata,
+ int (*fn)(struct vpd_cache *, u8 id, u8 version, u8 type,
+size_t size, u8 const *data))
{
if (size < HEADER_BLOCK_LEN || !data || !fn)
return -EINVAL;
@@ -200,9 +200,9 @@ static int vpd_reader(size_t size, u8 *data, struct
vpd_cache *userdata,
}
}
-int read_vpd(struct vpd_cache *cache,
-int (*process_block)(struct vpd_cache *, u8 id, u8 version,
- u8 type, size_t size, u8 const *data))
+int read_i2c_vpd(struct vpd_cache *cache,
+int (*process_block)(struct vpd_cache *, u8 id, u8 version,
+ u8 type, size_t size, u8 const *data))
{
struct udevice *dev;
int ret;
diff --git a/board/ge/common/vpd_reader.h b/board/ge/common/vpd_reader.h
index 3045b7e21e22..0c51dc57e902 100644
--- a/board/ge/common/vpd_reader.h
+++ b/board/ge/common/vpd_reader.h
@@ -16,7 +16,22 @@ struct vpd_cache;
*
* Returns Non-zero on error. Negative numbers encode errno.
*/
-int read_vpd(struct vpd_cache *cache,
-int (*process_block)(struct vpd_cache *,
- u8 id, u8 version, u8 type,
- size_t size, u8 const *data));
+int read_i2c_vpd(struct vpd_cache *cache,
+int (*process_block)(struct vpd_cache *, u8 id, u8 version,
+ u8 type, size_t size, u8 const *data));
+
+/*
+ * Read VPD from given data, verify content, call callback for each vital
+ * product data block.
+ *
+ * size: size of the raw VPD data in bytes
+ * data: raw VPD data read from device
+ * cache: structure used by process block to store VPD information
+ * process_block: callback called for each VPD data block
+ *
+ * Returns Non-zero on error. Negative numbers encode errno.
+ */
+
+int vpd_reader(size_t size, u8 *data, struct vpd_cache *cache,
+ int (*process_block)(struct vpd_cache *, u8 id, u8 version, u8
type,
+ size_t size, u8 const *data));
diff --git a/board/ge/mx53ppd/mx53ppd.c b/board/ge/mx53ppd/mx53ppd.c
index 2e9d389850a2..ef689733c41d 100644
--- a/board/ge/mx53ppd/mx53ppd.c
+++ b/board/ge/mx53ppd/mx53ppd.c
@@ -225,7 +225,7 @@ int board_late_init(void)
struct vpd_cache vpd;
memset(, 0, sizeof(vpd));
- res = read_vpd(, vpd_callback);
+ res = read_i2c_vpd(, vpd_callback);
if (!res)
process_vpd();
else
--
2.28.0
[PATCHv4 5/9] sysreset: Add poweroff-gpio driver
Add GPIO poweroff driver, which is based on the Linux
driver and uses the same DT binding.
Reviewed-by: Simon Glass
Signed-off-by: Sebastian Reichel
---
drivers/sysreset/Kconfig | 7 +++
drivers/sysreset/Makefile| 1 +
drivers/sysreset/poweroff_gpio.c | 92
3 files changed, 100 insertions(+)
create mode 100644 drivers/sysreset/poweroff_gpio.c
diff --git a/drivers/sysreset/Kconfig b/drivers/sysreset/Kconfig
index 6ebc90e1d33b..bf042f32c848 100644
--- a/drivers/sysreset/Kconfig
+++ b/drivers/sysreset/Kconfig
@@ -43,6 +43,13 @@ config SYSRESET_CMD_POWEROFF
endif
+config POWEROFF_GPIO
+ bool "Enable support for GPIO poweroff driver"
+ select DM_GPIO
+ help
+ Support for system poweroff using a GPIO pin. This can be used
+ for systems having a single GPIO to trigger a system poweroff.
+
config SYSRESET_GPIO
bool "Enable support for GPIO reset driver"
select DM_GPIO
diff --git a/drivers/sysreset/Makefile b/drivers/sysreset/Makefile
index df2293b8489d..90a9b26abef4 100644
--- a/drivers/sysreset/Makefile
+++ b/drivers/sysreset/Makefile
@@ -7,6 +7,7 @@ obj-$(CONFIG_ARCH_ASPEED) += sysreset_ast.o
obj-$(CONFIG_ARCH_ROCKCHIP) += sysreset_rockchip.o
obj-$(CONFIG_ARCH_STI) += sysreset_sti.o
obj-$(CONFIG_SANDBOX) += sysreset_sandbox.o
+obj-$(CONFIG_POWEROFF_GPIO) += poweroff_gpio.o
obj-$(CONFIG_SYSRESET_GPIO) += sysreset_gpio.o
obj-$(CONFIG_SYSRESET_MPC83XX) += sysreset_mpc83xx.o
obj-$(CONFIG_SYSRESET_MICROBLAZE) += sysreset_microblaze.o
diff --git a/drivers/sysreset/poweroff_gpio.c b/drivers/sysreset/poweroff_gpio.c
new file mode 100644
index ..ac482c37f48f
--- /dev/null
+++ b/drivers/sysreset/poweroff_gpio.c
@@ -0,0 +1,92 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Toggles a GPIO pin to power down a device
+ *
+ * Created using the Linux driver as reference, which
+ * has been written by:
+ *
+ * Jamie Lentin
+ * Andrew Lunn
+ *
+ * Copyright (C) 2012 Jamie Lentin
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+struct poweroff_gpio_info {
+ struct gpio_desc gpio;
+ u32 active_delay_ms;
+ u32 inactive_delay_ms;
+ u32 timeout_ms;
+};
+
+static int poweroff_gpio_request(struct udevice *dev, enum sysreset_t type)
+{
+ struct poweroff_gpio_info *priv = dev_get_priv(dev);
+ int r;
+
+ if (type != SYSRESET_POWER_OFF)
+ return -ENOSYS;
+
+ debug("GPIO poweroff\n");
+
+ /* drive it active, also inactive->active edge */
+ r = dm_gpio_set_value(>gpio, 1);
+ if (r < 0)
+ return r;
+ mdelay(priv->active_delay_ms);
+
+ /* drive inactive, also active->inactive edge */
+ r = dm_gpio_set_value(>gpio, 0);
+ if (r < 0)
+ return r;
+ mdelay(priv->inactive_delay_ms);
+
+ /* drive it active, also inactive->active edge */
+ r = dm_gpio_set_value(>gpio, 1);
+ if (r < 0)
+ return r;
+
+ /* give it some time */
+ mdelay(priv->timeout_ms);
+
+ return -EINPROGRESS;
+}
+
+static int poweroff_gpio_probe(struct udevice *dev)
+{
+ struct poweroff_gpio_info *priv = dev_get_priv(dev);
+ int flags;
+
+ flags = dev_read_bool(dev, "input") ? GPIOD_IS_IN : GPIOD_IS_OUT;
+ priv->active_delay_ms = dev_read_u32_default(dev, "active-delay-ms",
100);
+ priv->inactive_delay_ms = dev_read_u32_default(dev,
"inactive-delay-ms", 100);
+ priv->timeout_ms = dev_read_u32_default(dev, "timeout-ms", 3000);
+
+ return gpio_request_by_name(dev, "gpios", 0, >gpio, flags);
+}
+
+static struct sysreset_ops poweroff_gpio_ops = {
+ .request = poweroff_gpio_request,
+};
+
+static const struct udevice_id poweroff_gpio_ids[] = {
+ { .compatible = "gpio-poweroff", },
+ {},
+};
+
+U_BOOT_DRIVER(poweroff_gpio) = {
+ .name = "poweroff-gpio",
+ .id = UCLASS_SYSRESET,
+ .ops= _gpio_ops,
+ .probe = poweroff_gpio_probe,
+ .priv_auto_alloc_size = sizeof(struct poweroff_gpio_info),
+ .of_match = poweroff_gpio_ids,
+};
--
2.28.0
[PATCHv4 0/9] Introduce B1x5v2 support
This series introduces support for a new i.MX6DL based GE patient
monitor series.
Patch 1: Add support for storing bootcount in SPI-flash
Patch 2+3: Improve M41T62 RTC driver's reset routine.
PATCH 4: Support disable_ldb_di_clock_sources for i.MX6DL
Patch 5: Add poweroff-gpio support
Patch 6-8: restructure common GE code
Patch 9: Add the actual board, using SPL and DM
Changes since PATCHv3 [0]:
* Dropped patch for reading DR for i.MX GPIOs and set
SION pinmux bits in B1x5v2 output GPIOs instead
* Rebased to v2020.10-rc3
Changes since PATCHv2:
* PATCH 10: Fixed network phy mode ("rgmii" -> "rgmii-id")
* PATCH 6: Fixed nits reported by Simon Glass and added is
Reviewed-by Tag.
Changes since PATCHv1:
* Rebased to v2020.10-rc2
* Original patch 1 (support for DM_SPI_FLASH with non-DM SPL)
has been dropped, since a similar patch has been merged
in the meantime
* poweroff-gpio support is now added using sysreset uclass
instead of introducing a new poweroff uclass
* B1x5v2 patch has been updated to follow recent U-Boot
changes and to add USB mass storage support
[0] http://patchwork.ozlabs.org/project/uboot/list/?series=196979
-- Sebastian
Sebastian Reichel (9):
bootcount: add a DM SPI flash backing store for bootcount
rtc: m41t62: reset SQW in m41t62_rtc_reset
rtc: m41t62: add oscillator fail bit reset support
imx6: allow usage of disable_ldb_di_clock_sources for CONFIG_MX6QDL
sysreset: Add poweroff-gpio driver
board: ge: common: rename ge_common.c to ge_rtc.c
board: ge: common: add config option for RTC and VPD feature
board: ge: common: vpd: separate I2C specific code
board: ge: b1x5v2: Add GE B1x5v2 and B1x5Pv2
arch/arm/dts/Makefile | 1 +
arch/arm/dts/imx6dl-b1x5v2.dts| 654
arch/arm/mach-imx/mx6/Kconfig | 9 +
arch/arm/mach-imx/mx6/clock.c | 2 +-
board/ge/b1x5v2/Kconfig | 14 +
board/ge/b1x5v2/Makefile | 6 +
board/ge/b1x5v2/b1x5v2.c | 698 ++
board/ge/b1x5v2/spl.c | 587 ++
board/ge/bx50v3/Kconfig | 2 +
board/ge/bx50v3/bx50v3.c | 4 +-
board/ge/common/Kconfig | 7 +
board/ge/common/Makefile | 3 +-
board/ge/common/{ge_common.c => ge_rtc.c} | 0
board/ge/common/{ge_common.h => ge_rtc.h} | 0
board/ge/common/vpd_reader.c | 12 +-
board/ge/common/vpd_reader.h | 23 +-
board/ge/mx53ppd/Kconfig | 2 +
board/ge/mx53ppd/mx53ppd.c| 4 +-
configs/ge_b1x5v2_defconfig | 137 +
drivers/bootcount/Kconfig | 10 +
drivers/bootcount/Makefile| 1 +
drivers/bootcount/spi-flash.c | 125
drivers/rtc/m41t62.c | 139 -
drivers/sysreset/Kconfig | 7 +
drivers/sysreset/Makefile | 1 +
drivers/sysreset/poweroff_gpio.c | 92 +++
include/configs/ge_b1x5v2.h | 127
27 files changed, 2645 insertions(+), 22 deletions(-)
create mode 100644 arch/arm/dts/imx6dl-b1x5v2.dts
create mode 100644 board/ge/b1x5v2/Kconfig
create mode 100644 board/ge/b1x5v2/Makefile
create mode 100644 board/ge/b1x5v2/b1x5v2.c
create mode 100644 board/ge/b1x5v2/spl.c
create mode 100644 board/ge/common/Kconfig
rename board/ge/common/{ge_common.c => ge_rtc.c} (100%)
rename board/ge/common/{ge_common.h => ge_rtc.h} (100%)
create mode 100644 configs/ge_b1x5v2_defconfig
create mode 100644 drivers/bootcount/spi-flash.c
create mode 100644 drivers/sysreset/poweroff_gpio.c
create mode 100644 include/configs/ge_b1x5v2.h
--
2.28.0
[PATCHv4 4/9] imx6: allow usage of disable_ldb_di_clock_sources for CONFIG_MX6QDL
Allow using disable_ldb_di_clock_sources with just the combined
CONFIG_MX6QDL being enabled.
Signed-off-by: Sebastian Reichel
---
arch/arm/mach-imx/mx6/clock.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-imx/mx6/clock.c b/arch/arm/mach-imx/mx6/clock.c
index fb5e5b6f05c4..cb9d629be408 100644
--- a/arch/arm/mach-imx/mx6/clock.c
+++ b/arch/arm/mach-imx/mx6/clock.c
@@ -1341,7 +1341,7 @@ int do_mx6_showclocks(struct cmd_tbl *cmdtp, int flag,
int argc,
}
#if defined(CONFIG_MX6Q) || defined(CONFIG_MX6D) || defined(CONFIG_MX6DL) || \
- defined(CONFIG_MX6S)
+ defined(CONFIG_MX6S) || defined(CONFIG_MX6QDL)
static void disable_ldb_di_clock_sources(void)
{
struct mxc_ccm_reg *mxc_ccm = (struct mxc_ccm_reg *)CCM_BASE_ADDR;
--
2.28.0
[PATCHv4 6/9] board: ge: common: rename ge_common.c to ge_rtc.c
The file only contains RTC related code, so let's name
it accordingly.
Signed-off-by: Sebastian Reichel
---
board/ge/bx50v3/bx50v3.c | 2 +-
board/ge/common/Makefile | 2 +-
board/ge/common/{ge_common.c => ge_rtc.c} | 0
board/ge/common/{ge_common.h => ge_rtc.h} | 0
board/ge/mx53ppd/mx53ppd.c| 2 +-
5 files changed, 3 insertions(+), 3 deletions(-)
rename board/ge/common/{ge_common.c => ge_rtc.c} (100%)
rename board/ge/common/{ge_common.h => ge_rtc.h} (100%)
diff --git a/board/ge/bx50v3/bx50v3.c b/board/ge/bx50v3/bx50v3.c
index cf76cf7a3387..c6b0af8c776a 100644
--- a/board/ge/bx50v3/bx50v3.c
+++ b/board/ge/bx50v3/bx50v3.c
@@ -35,7 +35,7 @@
#include
#include
#include
-#include "../common/ge_common.h"
+#include "../common/ge_rtc.h"
#include "../common/vpd_reader.h"
#include "../../../drivers/net/e1000.h"
#include
diff --git a/board/ge/common/Makefile b/board/ge/common/Makefile
index 8a21dcb8b533..36bedb198077 100644
--- a/board/ge/common/Makefile
+++ b/board/ge/common/Makefile
@@ -2,4 +2,4 @@
#
# Copyright 2017 General Electric Company
-obj-y := vpd_reader.o ge_common.o
+obj-y := vpd_reader.o ge_rtc.o
diff --git a/board/ge/common/ge_common.c b/board/ge/common/ge_rtc.c
similarity index 100%
rename from board/ge/common/ge_common.c
rename to board/ge/common/ge_rtc.c
diff --git a/board/ge/common/ge_common.h b/board/ge/common/ge_rtc.h
similarity index 100%
rename from board/ge/common/ge_common.h
rename to board/ge/common/ge_rtc.h
diff --git a/board/ge/mx53ppd/mx53ppd.c b/board/ge/mx53ppd/mx53ppd.c
index 7627e9c370fb..2e9d389850a2 100644
--- a/board/ge/mx53ppd/mx53ppd.c
+++ b/board/ge/mx53ppd/mx53ppd.c
@@ -36,7 +36,7 @@
#include
#include "ppd_gpio.h"
#include
-#include "../../ge/common/ge_common.h"
+#include "../../ge/common/ge_rtc.h"
#include "../../ge/common/vpd_reader.h"
DECLARE_GLOBAL_DATA_PTR;
--
2.28.0
[PATCHv4 3/9] rtc: m41t62: add oscillator fail bit reset support
In case of empty battery or glitches the oscillator fail
bit might be set. This will reset the bit in the reset
routine.
Signed-off-by: Sebastian Reichel
---
drivers/rtc/m41t62.c | 50
1 file changed, 50 insertions(+)
diff --git a/drivers/rtc/m41t62.c b/drivers/rtc/m41t62.c
index 85d6eb02593f..0a4e12d69827 100644
--- a/drivers/rtc/m41t62.c
+++ b/drivers/rtc/m41t62.c
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
#define M41T62_REG_SSEC0
#define M41T62_REG_SEC 1
@@ -48,6 +49,7 @@
#define M41T62_ALMON_SQWE (1 << 6)/* SQWE: SQW Enable Bit */
#define M41T62_ALHOUR_HT (1 << 6)/* HT: Halt Update Bit */
#define M41T62_FLAGS_AF(1 << 6)/* AF: Alarm Flag Bit */
+#define M41T62_FLAGS_OF(1 << 2)/* OF: Oscillator Flag
Bit */
#define M41T62_FLAGS_BATT_LOW (1 << 4)/* BL: Battery Low Bit */
#define M41T62_WDAY_SQW_FREQ_MASK 0xf0
@@ -193,6 +195,50 @@ static int m41t62_sqw_set_rate(struct udevice *dev,
unsigned int rate)
return dm_i2c_write(dev, M41T62_REG_WDAY, , sizeof(newval));
}
+static int m41t62_rtc_restart_osc(struct udevice *dev)
+{
+ u8 val;
+ int ret;
+
+ /* 0. check if oscillator failure happened */
+ ret = dm_i2c_read(dev, M41T62_REG_FLAGS, , sizeof(val));
+ if (ret)
+ return ret;
+ if (!(val & M41T62_FLAGS_OF))
+ return 0;
+
+ ret = dm_i2c_read(dev, M41T62_REG_SEC, , sizeof(val));
+ if (ret)
+ return ret;
+
+ /* 1. Set stop bit */
+ val |= M41T62_SEC_ST;
+ ret = dm_i2c_write(dev, M41T62_REG_ALARM_HOUR, , sizeof(val));
+ if (ret)
+ return ret;
+
+ /* 2. Clear stop bit */
+ val &= ~M41T62_SEC_ST;
+ ret = dm_i2c_write(dev, M41T62_REG_ALARM_HOUR, , sizeof(val));
+ if (ret)
+ return ret;
+
+ /* 3. wait 4 seconds */
+ mdelay(4000);
+
+ ret = dm_i2c_read(dev, M41T62_REG_FLAGS, , sizeof(val));
+ if (ret)
+ return ret;
+
+ /* 4. clear M41T62_FLAGS_OF bit */
+ val &= ~M41T62_FLAGS_OF;
+ ret = dm_i2c_write(dev, M41T62_REG_FLAGS, , sizeof(val));
+ if (ret)
+ return ret;
+
+ return 0;
+}
+
static int m41t62_rtc_clear_ht(struct udevice *dev)
{
u8 val;
@@ -218,6 +264,10 @@ static int m41t62_rtc_reset(struct udevice *dev)
{
int ret;
+ ret = m41t62_rtc_restart_osc(dev);
+ if (ret)
+ return ret;
+
ret = m41t62_rtc_clear_ht(dev);
if (ret)
return ret;
--
2.28.0
[PATCHv4 2/9] rtc: m41t62: reset SQW in m41t62_rtc_reset
This takes care of resetting the 32kHz square wave, which is
used by some boards as clock source for the SoC.
Signed-off-by: Sebastian Reichel
---
drivers/rtc/m41t62.c | 89 +---
1 file changed, 83 insertions(+), 6 deletions(-)
diff --git a/drivers/rtc/m41t62.c b/drivers/rtc/m41t62.c
index 94a6b523aab3..85d6eb02593f 100644
--- a/drivers/rtc/m41t62.c
+++ b/drivers/rtc/m41t62.c
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
#define M41T62_REG_SSEC0
#define M41T62_REG_SEC 1
@@ -49,6 +50,11 @@
#define M41T62_FLAGS_AF(1 << 6)/* AF: Alarm Flag Bit */
#define M41T62_FLAGS_BATT_LOW (1 << 4)/* BL: Battery Low Bit */
+#define M41T62_WDAY_SQW_FREQ_MASK 0xf0
+#define M41T62_WDAY_SQW_FREQ_SHIFT 4
+
+#define M41T62_SQW_MAX_FREQ32768
+
#define M41T62_FEATURE_HT (1 << 0)
#define M41T62_FEATURE_BL (1 << 1)
@@ -139,21 +145,92 @@ static int m41t62_rtc_set(struct udevice *dev, const
struct rtc_time *tm)
return 0;
}
-static int m41t62_rtc_reset(struct udevice *dev)
+static int m41t62_sqw_enable(struct udevice *dev, bool enable)
+{
+ u8 val;
+ int ret;
+
+ ret = dm_i2c_read(dev, M41T62_REG_ALARM_MON, , sizeof(val));
+ if (ret)
+ return ret;
+
+ if (enable)
+ val |= M41T62_ALMON_SQWE;
+ else
+ val &= ~M41T62_ALMON_SQWE;
+
+ return dm_i2c_write(dev, M41T62_REG_ALARM_MON, , sizeof(val));
+}
+
+static int m41t62_sqw_set_rate(struct udevice *dev, unsigned int rate)
+{
+ u8 val, newval, sqwrateval;
+ int ret;
+
+ if (rate >= M41T62_SQW_MAX_FREQ)
+ sqwrateval = 1;
+ else if (rate >= M41T62_SQW_MAX_FREQ / 4)
+ sqwrateval = 2;
+ else if (rate)
+ sqwrateval = 15 - ilog2(rate);
+
+ ret = dm_i2c_read(dev, M41T62_REG_WDAY, , sizeof(val));
+ if (ret)
+ return ret;
+
+ newval = val;
+ newval &= ~M41T62_WDAY_SQW_FREQ_MASK;
+ newval |= (sqwrateval << M41T62_WDAY_SQW_FREQ_SHIFT);
+
+ /*
+* Try to avoid writing unchanged values. Writing to this register
+* will reset the internal counter pipeline and thus affect system
+* time.
+*/
+ if (newval == val)
+ return 0;
+
+ return dm_i2c_write(dev, M41T62_REG_WDAY, , sizeof(newval));
+}
+
+static int m41t62_rtc_clear_ht(struct udevice *dev)
{
u8 val;
+ int ret;
/*
* M41T82: Make sure HT (Halt Update) bit is cleared.
* This bit is 0 in M41T62 so its save to clear it always.
*/
- int ret = dm_i2c_read(dev, M41T62_REG_ALARM_HOUR, , sizeof(val));
-
+ ret = dm_i2c_read(dev, M41T62_REG_ALARM_HOUR, , sizeof(val));
+ if (ret)
+ return ret;
val &= ~M41T80_ALHOUR_HT;
- ret |= dm_i2c_write(dev, M41T62_REG_ALARM_HOUR, , sizeof(val));
+ ret = dm_i2c_write(dev, M41T62_REG_ALARM_HOUR, , sizeof(val));
+ if (ret)
+ return ret;
+
+ return 0;
+}
- return ret;
+static int m41t62_rtc_reset(struct udevice *dev)
+{
+ int ret;
+
+ ret = m41t62_rtc_clear_ht(dev);
+ if (ret)
+ return ret;
+
+ /*
+* Some boards feed the square wave as clock input into
+* the SoC. This enables a 32.768kHz square wave, which is
+* also the hardware default after power-loss.
+*/
+ ret = m41t62_sqw_set_rate(dev, 32768);
+ if (ret)
+ return ret;
+ return m41t62_sqw_enable(dev, true);
}
/*
@@ -162,7 +239,7 @@ static int m41t62_rtc_reset(struct udevice *dev)
*/
static int m41t62_rtc_probe(struct udevice *dev)
{
- return m41t62_rtc_reset(dev);
+ return m41t62_rtc_clear_ht(dev);
}
static const struct rtc_ops m41t62_rtc_ops = {
--
2.28.0
[PATCHv4 1/9] bootcount: add a DM SPI flash backing store for bootcount
This driver allows to use SPI flash as backing store for
boot counter values with DM enabled.
Signed-off-by: Sebastian Reichel
---
drivers/bootcount/Kconfig | 10 +++
drivers/bootcount/Makefile| 1 +
drivers/bootcount/spi-flash.c | 125 ++
3 files changed, 136 insertions(+)
create mode 100644 drivers/bootcount/spi-flash.c
diff --git a/drivers/bootcount/Kconfig b/drivers/bootcount/Kconfig
index c8e6fa7f8925..b5ccea0d9c20 100644
--- a/drivers/bootcount/Kconfig
+++ b/drivers/bootcount/Kconfig
@@ -108,6 +108,16 @@ config DM_BOOTCOUNT_I2C_EEPROM
pointing to the underlying i2c eeprom device) and an optional 'offset'
property are supported.
+config DM_BOOTCOUNT_SPI_FLASH
+ bool "Support SPI flash devices as a backing store for bootcount"
+ depends on DM_SPI_FLASH
+ help
+ Enabled reading/writing the bootcount in a DM SPI flash device.
+ The wrapper device is to be specified with the compatible string
+ 'u-boot,bootcount-spi-flash' and the 'spi-flash'-property (a phandle
+ pointing to the underlying SPI flash device) and an optional 'offset'
+ property are supported.
+
config BOOTCOUNT_MEM
bool "Support memory based bootcounter"
help
diff --git a/drivers/bootcount/Makefile b/drivers/bootcount/Makefile
index 059d40d16b0c..51d860b00e18 100644
--- a/drivers/bootcount/Makefile
+++ b/drivers/bootcount/Makefile
@@ -12,3 +12,4 @@ obj-$(CONFIG_BOOTCOUNT_EXT) += bootcount_ext.o
obj-$(CONFIG_DM_BOOTCOUNT) += bootcount-uclass.o
obj-$(CONFIG_DM_BOOTCOUNT_RTC) += rtc.o
obj-$(CONFIG_DM_BOOTCOUNT_I2C_EEPROM) += i2c-eeprom.o
+obj-$(CONFIG_DM_BOOTCOUNT_SPI_FLASH) += spi-flash.o
diff --git a/drivers/bootcount/spi-flash.c b/drivers/bootcount/spi-flash.c
new file mode 100644
index ..7cd388e6616c
--- /dev/null
+++ b/drivers/bootcount/spi-flash.c
@@ -0,0 +1,125 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2019 Collabora
+ * (C) Copyright 2019 GE
+ */
+
+#include
+#include
+#include
+#include
+
+static const u8 bootcount_magic = 0xbc;
+
+struct bootcount_spi_flash_priv {
+ struct udevice *spi_flash;
+ u32 offset;
+};
+
+static int bootcount_spi_flash_update(struct udevice *dev, u32 offset, u32
len, const void *buf)
+{
+ struct spi_flash *flash = dev_get_uclass_priv(dev);
+ u32 sector_size = flash->sector_size;
+ u32 sector_offset = offset % sector_size;
+ u32 sector = offset - sector_offset;
+ int err = 0;
+
+ /* code only supports updating a single sector */
+ if (sector_offset + len > sector_size)
+ return -ENOSYS;
+
+ u8 *buffer = malloc(sector_size);
+ if (!buffer)
+ return -ENOMEM;
+
+ err = spi_flash_read_dm(dev, sector, sector_size, buffer);
+ if (err < 0)
+ goto out;
+
+ memcpy(buffer + sector_offset, buf, len);
+
+ err = spi_flash_erase_dm(dev, sector, sector_size);
+ if (err < 0)
+ goto out;
+
+ err = spi_flash_write_dm(dev, sector, sector_size, buffer);
+ if (err < 0)
+ goto out;
+
+out:
+ free(buffer);
+ return err;
+}
+
+static int bootcount_spi_flash_set(struct udevice *dev, const u32 a)
+{
+ struct bootcount_spi_flash_priv *priv = dev_get_priv(dev);
+ const u16 val = bootcount_magic << 8 | (a & 0xff);
+
+ if (bootcount_spi_flash_update(priv->spi_flash, priv->offset, 2, )
< 0) {
+ debug("%s: write failed\n", __func__);
+ return -EIO;
+ }
+
+ return 0;
+}
+
+static int bootcount_spi_flash_get(struct udevice *dev, u32 *a)
+{
+ struct bootcount_spi_flash_priv *priv = dev_get_priv(dev);
+ u16 val;
+
+ if (spi_flash_read_dm(priv->spi_flash, priv->offset, 2, ) < 0) {
+ debug("%s: read failed\n", __func__);
+ return -EIO;
+ }
+
+ if (val >> 8 == bootcount_magic) {
+ *a = val & 0xff;
+ return 0;
+ }
+
+ debug("%s: bootcount magic does not match on %04x\n", __func__, val);
+ return -EIO;
+}
+
+static int bootcount_spi_flash_probe(struct udevice *dev)
+{
+ struct ofnode_phandle_args phandle_args;
+ struct bootcount_spi_flash_priv *priv = dev_get_priv(dev);
+ struct udevice *spi_flash;
+
+ if (dev_read_phandle_with_args(dev, "spi-flash", NULL, 0, 0,
_args)) {
+ debug("%s: spi-flash backing device not specified\n",
dev->name);
+ return -ENOENT;
+ }
+
+ if (uclass_get_device_by_ofnode(UCLASS_SPI_FLASH, phandle_args.node,
_flash)) {
+ debug("%s: could not get backing device\n", dev->name);
+ return -ENODEV;
+ }
+
+ priv->spi_flash = spi_flash;
+ priv->offset = dev_read_u32_default(dev, "offset", 0);
+
+ return 0;
+}
+
+static const struct bootcount_ops bootcount_spi_flash_ops = {
+
Re: [PATCH v3 00/12] binman: Add support for generating more complex FITs
Hi Michal,
On Wed, 2 Sep 2020 at 04:27, Michal Simek wrote:
>
> Hi Simon,
>
> On 01. 09. 20 13:13, Simon Glass wrote:
> > This series allows binman to generate FITs that include multiple DTB
> > images and the configuration to use them.
> >
> > It is then possible to remove the sunxi FIT generator script, so this
> > series handles that also.
> >
> > With this, sunxi is fully converted to use binman.
> >
> > Note: This series is available at u-boot-dm/binman-working and is based
> > on u-boot-dm/testing
>
> I continue on testing this series on ZynqMP and reach one issue. One of
> our usecase is to put u-boot on memory above 32bit address space.
> To be accurate to this memory range.
> reg = <0x8 0x 0x0 0x8000>;
>
> One way to get there is to setup TEXT_BASE to for example 0x80800.
> Then u-boot.itb fragment for binmap looks like this.
>
> u-boot-itb {
> filename = "u-boot.itb";
> fit {
> description = "FIT image with ATF support";
> fit,fdt-list = "of-list";
> #address-cells = <2>;
>
> images {
> uboot {
> description = "U-Boot (64-bit)";
> type = "firmware";
> os = "u-boot";
> arch = "arm64";
> compression = "none";
> load = <8 0x800>;
> entry = <8 0x800>;
> u-boot-nodtb {
> };
> };
> ...
> The key properties are load/entry. In example above I have address-cells
> = 2 and entries written by hand and it works fine.
> But I want to use CONFIG_SYS_TEXT_BASE there which is already in 64bit
> format.
>
> When this is used I get
> Error: arch/arm/dts/zynqmp-u-boot.dtsi:31.14-25 Value out of range for
> 32-bit array element
> Error: arch/arm/dts/zynqmp-u-boot.dtsi:32.15-26 Value out of range for
> 32-bit array element
>
> Which is understandable but my question is how to handle 64bit addresses
> which are properly filled via Kconfig?
If I understand the problem correctly, you can add 64-bit values like this:
load = /bits/ 64 ;
>
> I have the same issue with one more DT property.
>
> Thanks,
> Michal
>
>
>
Re: [PATCH] buildman: Use git worktrees instead of git clones
Hi Alper, On Wed, 2 Sep 2020 at 06:36, Alper Nebi Yasak wrote: > > This patch makes buildman create linked working trees instead of clones > of the source repository, but keeps updating the older clones of the > repository that might already exist. These worktrees share "everything > except working directory specific files such as HEAD, index, etc." with > the source repository. See the git-worktree(1) manual page for more > information. > > Signed-off-by: Alper Nebi Yasak > --- > The git-worktree is available since about 2015 (git v2.5), but its > manual page mentions this in its BUGS section: > >Multiple checkout in general is still experimental, and the >support for submodules is incomplete. It is NOT recommended to >make multiple checkouts of a superproject. > > I think it'll be fine since U-Boot doesn't use submodules, but still > wanted to let you know. I'd really like to do this as it cuts the disk space alot, particularly with a 30-core machine. I tried to do something similar with symlinks when I first wrote buildman, but it did not seem to be possible without copying files and doing things under the hood that I didn't like. It looks like that version of git was not in Ubuntu 14.04 but appeared in 16.04. I've just done some patches to make patman work in 14.04, so I'd prefer to keep buildman working for that also. So I think we should have an option to keep the old behaviour, or perhaps detect when 'git worktree' is not available and fall back. > > tools/buildman/builder.py | 36 > tools/buildman/func_test.py | 2 ++ > tools/patman/gitutil.py | 28 > 3 files changed, 54 insertions(+), 12 deletions(-) > Regards, Simon
Re: [PATCH] arm64: Add support for bigger u-boot when CONFIG_POSITION_INDEPENDENT=y
On 9/2/20 5:15 AM, Michal Simek wrote: > From: "Edgar E. Iglesias" > > When U-Boot binary exceeds 1MB with CONFIG_POSITION_INDEPENDENT=y > compilation error is shown: > /mnt/disk/u-boot/arch/arm/cpu/armv8/start.S:71:(.text+0x3c): relocation > truncated to fit: R_AARCH64_ADR_PREL_LO21 against symbol `__rel_dyn_end' > defined in .bss_start section in u-boot. > > It is caused by adr instruction which permits the calculation of any byte > address within +- 1MB of the current PC. > Because U-Boot is bigger then 1MB calculation is failing. > > The patch is using adrp/add instructions where adrp shifts a signed, 21-bit > immediate left by 12 bits (4k page), adds it to the value of the program > counter with the bottom 12 bits cleared to zero. Then add instruction > provides the lower 12 bits which is offset within 4k page. > These two instructions together compose full 32bit offset which should be > more then enough to cover the whole u-boot size. > diff --git a/arch/arm/cpu/armv8/start.S b/arch/arm/cpu/armv8/start.S > @@ -67,8 +67,10 @@ pie_fixup: > adr x0, _start /* x0 <- Runtime value of _start */ > ldr x1, _TEXT_BASE /* x1 <- Linked value of _start */ > sub x9, x0, x1 /* x9 <- Run-vs-link offset */ > - adr x2, __rel_dyn_start /* x2 <- Runtime &__rel_dyn_start */ > - adr x3, __rel_dyn_end /* x3 <- Runtime &__rel_dyn_end */ > + adrpx2, __rel_dyn_start /* x2 <- Runtime &__rel_dyn_start */ > + add x2, x2, #:lo12:__rel_dyn_start > + adrpx3, __rel_dyn_end /* x3 <- Runtime &__rel_dyn_end */ > + add x3, x3, #:lo12:__rel_dyn_end > pie_fix_loop: > ldp x0, x1, [x2], #16 /* (x0, x1) <- (Link location, fixup) */ > ldr x4, [x2], #8/* x4 <- addend */ There are likely a bunch of other places in the code that need updating too; take a look at commit 49e93875a62f "arm64: support running at addr other than linked to" (which introduced the code above) to find other places with similar instruction sequences that almost certainly need updating.
Re: [PATCH v5 11/11] riscv: Add FPIOA and GPIO support for Kendryte K210
On 9/2/20 8:26 AM, Heinrich Schuchardt wrote: > On 01.09.20 03:19, Rick Chen wrote: >> Hi Sean >> >>> On 8/20/20 4:47 AM, Rick Chen wrote: Hi Sean > Hi Sean > >> On 8/18/20 11:48 PM, Rick Chen wrote: >>> Hi Tom >>> This patch adds the necessary configs and docs for FPIOA and GPIO support on the K210. The board does not boot unless CONSOLE_LOGLEVEL is set to a non-default value . It also boots when the tree is dirty (and CONSOLE_LOGLEVEL is not changed). It also boots when changes are made to the device tree and then committed. I don't know why this happens. These breakages only occur after bf2fb81ad3. Signed-off-by: Sean Anderson --- Changes in v5: - Increase CONSOLE_LOGLEVEL to 5 as a hack to get the board booting again - Patch 05/12 "gpio: sifive: Use generic reg read function" has been superseded by commit 2548493ab4. >>> >>> Would you like to pick up this series, [PATCH v5 00/11] riscv: Add >>> FPIOA and GPIO support for Kendryte K210 ? >>> Or maybe it is better to figure out what is wrong here and find the >>> root cause why it need to Increase CONSOLE_LOGLEVEL to 5 as a hack ? >> >> As an additional note, *CONFIG_LOGLEVEL (whoops) can also be decreased >> for the same effect. In addition, there are several other ways I found >> to "fix" this bug (as noted in the commit message). If you would like to >> test this out, I have two trees [1, 2] where this series (actually a >> slightly >> earlier version of this series) is applied just before and just after >> bf2fb81ad3. The original patch is located at [3]. >> >> --Sean >> >> [1] https://github.com/Forty-Bot/u-boot/tree/maix_gpio_good >> [2] https://github.com/Forty-Bot/u-boot/tree/maix_gpio_bad >> [3] >> https://patchwork.ozlabs.org/project/uboot/patch/20200724111225.12513-15-ovidiu.pan...@windriver.com/ > > I don't have a K210 board for verification. > But it is OK to run in AE350 board after applying your series. > > After check about this commit "common/board_r: Remove initr_serial > wrapper", it seem shall not affect anything. > It just change to call serial_initialize directly. > Only I can think about maybe it is a cache problem. > Just like sometime we add a printf, then the problem will be walk around. Can you dig in to find the root cause ? For code stability, it is better not to have any unknown issue. Yo can dirty hack and work around currently, but it may crash again after several commits. >>> >>> Ok, so I did some further digging, but I was unable to pin down the >>> cause of the bug. My efforts to determine a cause have been primarily >>> thwarted because the bug disappears after any change to initialization >>> code. Adding any function to init_sequence_f or init_sequence_r, even a >>> no-op function which just returns 0, causes the board to boot normally. >>> In addition, adding a nop() to any function in those sequences will >>> cause the board to boot normally. The board seems to fail to boot only >>> with a very specific boot sequence and timing. >> >> If you modify any code and the result will change, then you shall >> debug it via debugger(GDB) without any code modification. >> >>> >>> When the board fails to boot, it hangs in a manner similar to when the >> >> Maybe you can try to set a break and access the bus, if the bus access >> fail, then you re-set a break a bit ahead until the bus access NOT >> fail. Yeah, I was investigating that, however I was unable to get the k210 to break at 0x8000. I suspect this may be a problem with openocd, as the k210 port is rather buggy (e.g. it can cause address misaligned errors, and sometimes leaves the pc in the debug dection of memory). I *can* get it to break in the otp (0x8800), so perhaps I just need to identify the address before it jumps to U-Boot. >> To see if this way can pin down which instruction or the crucial code >> to cause the bus hang problem. And guess what maybe the root-cause. >> >> If you can find the instruction which may cause the bus hang, you can >> info all-registers and compare the differences between NG and OK. And >> guess what maybe the root-cause. > > Trying to narrow down on the problem I found the following: > > The system hangs before arch_cpu_init_dm() is called. This is not always the case. On most boots, the following output is present: U-Boot 2020.10-rc3-00045-g7532b003f0 (Sep 02 2020 - 11:09:16 -0400) DRAM: 8 MiB which means at least everything up to dram_init gets called. > > After adding some debug functions the error appeared and disappeared > when changing the code in function panic(). So my guess is that there is > some alignment problem in the static data
Re: [PATCH] travis-ci: Add SH4 r2dplus machine with various PCI ethernet options
On 9/2/20 9:42 AM, Tom Rini wrote: > On Tue, Aug 18, 2020 at 06:50:06PM +0200, Marek Vasut wrote: > >> On 8/5/20 11:26 PM, Marek Vasut wrote: >>> Add SH4 R2Dplus machine configured to test various U-Boot PCI ethernet >>> options -- RTL8139, EEPRO100, AMD PCnet, DEC Tulip. >>> >> >> Bump ? > > Stephen? Oh, this was marked as travis-ci not u-boot-test-hooks so I didn't realize it was for me. I'll try and look at it soon.
Re: [PATCH] travis-ci: Add SH4 r2dplus machine with various PCI ethernet options
On Tue, Aug 18, 2020 at 06:50:06PM +0200, Marek Vasut wrote: > On 8/5/20 11:26 PM, Marek Vasut wrote: > > Add SH4 R2Dplus machine configured to test various U-Boot PCI ethernet > > options -- RTL8139, EEPRO100, AMD PCnet, DEC Tulip. > > > > Bump ? Stephen? -- Tom signature.asc Description: PGP signature
Re: [PATCH v5 02/11] pinctrl: Reformat documentation in dm/pinctrl.h
On 9/2/20 11:17 AM, Heinrich Schuchardt wrote:
> On 02.09.20 16:56, Sean Anderson wrote:
>>
>> On 9/2/20 8:26 AM, Heinrich Schuchardt wrote:
>>> On 15.08.20 17:52, Sean Anderson wrote:
This normalizes the documentatation to conform to kernel-doc style [1]. It
>>>
>>> Nits:
>>> %s/documentatation/documentation/
>>>
also moves the documentation for pinctrl_ops inline, and adds argument and
return-value documentation. I have kept the usual function style for these
comments. I could not find any existing examples of function documentation
inside structs.
[1] https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html
Signed-off-by: Sean Anderson
Reviewed-by: Simon Glass
>>>
>>>
>>> Before and after this patch the documentation format is incorrect. See
>>> output below for the situation after the patch.
>>>
>>> Please include include/dm/pinctrl.h into doc/api/index.rst via a new
>>> file doc/api/pnctrl.rst.
>>>
>>> A documentation style accepted by 'make htmldocs' is:
>>>
>>> struct pinctrl_ops {
>>> /**
>>> * @get_pins_count: Get the number of selectable pins
>>> *
>>> * @get_pins_count.dev: Pinctrl device to use
>>> *
>>> * This function is necessary to parse the "pins" property
>>> * in DTS.
>>> *
>>> * @get_pins_count.Return:number of selectable named pins
>>> *available in this driver
>>> */
>>> int (*get_pins_count)(struct udevice *dev);
>>>
>>> See the nested structures in
>>>
>>> https://www.kernel.org/doc/html/v5.7/doc-guide/kernel-doc.html#in-line-member-documentation-comments
>>> and
>>> https://www.kernel.org/doc/html/v5.7/doc-guide/kernel-doc.html#nested-structs-unions
>>
>> Thanks for suggesting those changes. This works better. As far as I can
>> tell, fully-qualified members are only necessary when documenting nested
>> structs at the top-level. When using in-line documentation, members are
>> automatically nested. With that in mind, I am using the following format
>>
>> /**
>> * @pinmux_property_set: Enable a pinmux group
>> *
>> * @dev: Pinctrl device to use
>> *
>> * @pinmux_group: A u32 representing the pin identifier and mux
>> *settings. The exact format of a pinmux group is left
>> *up to the driver.
>> *
>> * Mux a single pin to a single function based on a driver-specific
>> * pinmux group. This function is necessary for parsing the "pinmux"
>> * property in DTS, and for pin-muxing against a pinmux group.
>> *
>> * @Return:
>> * Pin selector for the muxed pin if OK, or negative error code on
>> * failure
>> */
>> int (*pinmux_property_set)(struct udevice *dev, u32 pinmux_group);
>>
>> However, I am having some problems with multi-line descriptions. In the
>> example above, the desciption for @pinmux_group has the first line
>> bolded and the rest of the description is typeset as normal, but is
>> indented. The generated html is
>
> Use fully qualified names and you are fine.
I also experienced this issue when using fully-qualified names.
>
> Best regards
>
> Heinrich
>
>>
>>
>> pinmux_group: A u32 representing the pin identifier
>> and mux
>> settings. The exact format of a pinmux group is left up to the
>> driver.
>>
>>
>> However, it should be something like
>>
>> pinmux_group: A u32 representing the pin identifier
>> and mux settings. The exact format of a pinmux group is left up to the
>> driver.
>>
>> I have also tried an alternate style, as shown for @Return. However,
>> this too generated the wrong html:
>>
>>
>> Return:
>> Pin selector for the muxed pin if OK, or negative error code on
>> failure
>>
>>
>> where it should generate something like
>>
>> Return: Pin selector for the muxed pin
>> if OK, or negative error code on failure
>>
>> Do you have any suggestions for generating the latter forms? My current
>> work is at [1].
>>
>> --Sean
>>
>> [1]
>> https://github.com/Forty-Bot/u-boot/commit/e835cf9552dc96438699806731a208b40daead7b
>>
>
Re: [PATCH] arm64: Add support for bigger u-boot when CONFIG_POSITION_INDEPENDENT=y
On Wed, Sep 02, 2020 at 04:18:48PM +0100, André Przywara wrote: > On 02/09/2020 15:53, Edgar E. Iglesias wrote: > > On Wed, Sep 02, 2020 at 03:43:08PM +0100, Andr� Przywara wrote: > >> On 02/09/2020 12:15, Michal Simek wrote: > > Hi, > > >> > >>> From: "Edgar E. Iglesias" > >>> > >>> When U-Boot binary exceeds 1MB with CONFIG_POSITION_INDEPENDENT=y > >>> compilation error is shown: > >>> /mnt/disk/u-boot/arch/arm/cpu/armv8/start.S:71:(.text+0x3c): relocation > >>> truncated to fit: R_AARCH64_ADR_PREL_LO21 against symbol `__rel_dyn_end' > >>> defined in .bss_start section in u-boot. > >>> > >>> It is caused by adr instruction which permits the calculation of any byte > >>> address within +- 1MB of the current PC. > >>> Because U-Boot is bigger then 1MB calculation is failing. > >>> > >>> The patch is using adrp/add instructions where adrp shifts a signed, > >>> 21-bit > >>> immediate left by 12 bits (4k page), adds it to the value of the program > >>> counter with the bottom 12 bits cleared to zero. Then add instruction > >>> provides the lower 12 bits which is offset within 4k page. > >>> These two instructions together compose full 32bit offset which should be > >>> more then enough to cover the whole u-boot size. > >>> > >>> Signed-off-by: Edgar E. Iglesias > >>> Signed-off-by: Michal Simek > >> > >> It's a bit scary that you need more than 1MB, but indeed what you do > >> below is the canonical pattern to get the full range of PC relative > >> addressing (this is used heavily in Trusted Firmware, for instance). > >> > >> The only thing to keep in mind is that this assumes that the load > >> address of the binary is 4K aligned, so that the low 12 bits of the > >> symbol stay the same. I wonder if we should enforce this somehow? But > >> the load address is not controlled by the build process (the whole > >> purpose of PIE), so that's not doable just in the build system? > > > > There shouldn't be any need for 4K alignment. Could you elaborate on > > why you think there is? > > That seems to be slightly tricky, and I tried to get some confirmation, > but here goes my reasoning. Maybe you can confirm this: > > - adrp takes the relative offset, but only of the upper 20 bits (because > that's all we can encode). It clears the lower 12 bits of the register. > - the "add" is not PC relative anymore, so it just takes the lower 12 > bits of the "absolute" linker symbol. I was under the impression that this would use a PC-relative lower 12bit relocation but you are correct. I dissasembled the result: 40: 9142add x2, x2, #0x0 40: R_AARCH64_ADD_ABS_LO12_NC __rel_dyn_start > So this assumes that the lower 12 bits of the actual address in memory > and the lower 12 bits of the linker's view match. > An example: > 00024: adrp x0, SYMBOL > 00028: add x0, x0, :lo12:SYMBOL > > SYMBOL: > 42058: ... > > The toolchain will generate: > adrp x0, #0x42; add x0, x0, #0x058 > > Now you load the code to 0x8000.0800 (NOT 4K aligned). SYMBOL is now at > 0x80042858. > The adrp will use the PC (0x8000.0824) & ~0xfff + offs => 0x8004.2000. > The add will just add 0x58, so you end up with x0 being 0x80042058, > which is not the right address. > > Does this make sense? Yes, it makes sense. > > > Perhaps the commit message is a little confusing. The toolchain will > > compute the pc-relative offset from this particular location to the > > symbol and apply the relocations accordingly. > > Yes, but the PC relative offset applies only to the upper 20 bits, > because it's only adrp that has PC relative semantics. > > > >> > >> Shall we at least document this? I guess typical load address are > >> actually quite well aligned, so it might not be an issue in practice. > >> Yes, probably worth documenting and perhaps an early bail-out if it's not the case... Thanks, Edgar
Re: [PATCH] arm64: Add support for bigger u-boot when CONFIG_POSITION_INDEPENDENT=y
On 02/09/2020 15:53, Edgar E. Iglesias wrote: > On Wed, Sep 02, 2020 at 03:43:08PM +0100, Andr� Przywara wrote: >> On 02/09/2020 12:15, Michal Simek wrote: Hi, >> >>> From: "Edgar E. Iglesias" >>> >>> When U-Boot binary exceeds 1MB with CONFIG_POSITION_INDEPENDENT=y >>> compilation error is shown: >>> /mnt/disk/u-boot/arch/arm/cpu/armv8/start.S:71:(.text+0x3c): relocation >>> truncated to fit: R_AARCH64_ADR_PREL_LO21 against symbol `__rel_dyn_end' >>> defined in .bss_start section in u-boot. >>> >>> It is caused by adr instruction which permits the calculation of any byte >>> address within +- 1MB of the current PC. >>> Because U-Boot is bigger then 1MB calculation is failing. >>> >>> The patch is using adrp/add instructions where adrp shifts a signed, 21-bit >>> immediate left by 12 bits (4k page), adds it to the value of the program >>> counter with the bottom 12 bits cleared to zero. Then add instruction >>> provides the lower 12 bits which is offset within 4k page. >>> These two instructions together compose full 32bit offset which should be >>> more then enough to cover the whole u-boot size. >>> >>> Signed-off-by: Edgar E. Iglesias >>> Signed-off-by: Michal Simek >> >> It's a bit scary that you need more than 1MB, but indeed what you do >> below is the canonical pattern to get the full range of PC relative >> addressing (this is used heavily in Trusted Firmware, for instance). >> >> The only thing to keep in mind is that this assumes that the load >> address of the binary is 4K aligned, so that the low 12 bits of the >> symbol stay the same. I wonder if we should enforce this somehow? But >> the load address is not controlled by the build process (the whole >> purpose of PIE), so that's not doable just in the build system? > > There shouldn't be any need for 4K alignment. Could you elaborate on > why you think there is? That seems to be slightly tricky, and I tried to get some confirmation, but here goes my reasoning. Maybe you can confirm this: - adrp takes the relative offset, but only of the upper 20 bits (because that's all we can encode). It clears the lower 12 bits of the register. - the "add" is not PC relative anymore, so it just takes the lower 12 bits of the "absolute" linker symbol. So this assumes that the lower 12 bits of the actual address in memory and the lower 12 bits of the linker's view match. An example: 00024: adrp x0, SYMBOL 00028: add x0, x0, :lo12:SYMBOL SYMBOL: 42058: ... The toolchain will generate: adrp x0, #0x42; add x0, x0, #0x058 Now you load the code to 0x8000.0800 (NOT 4K aligned). SYMBOL is now at 0x80042858. The adrp will use the PC (0x8000.0824) & ~0xfff + offs => 0x8004.2000. The add will just add 0x58, so you end up with x0 being 0x80042058, which is not the right address. Does this make sense? > Perhaps the commit message is a little confusing. The toolchain will > compute the pc-relative offset from this particular location to the > symbol and apply the relocations accordingly. Yes, but the PC relative offset applies only to the upper 20 bits, because it's only adrp that has PC relative semantics. Cheers, Andre >> >> Shall we at least document this? I guess typical load address are >> actually quite well aligned, so it might not be an issue in practice. >> >> Cheers, >> Andre >> >>> --- >>> >>> arch/arm/cpu/armv8/start.S | 6 -- >>> 1 file changed, 4 insertions(+), 2 deletions(-) >>> >>> diff --git a/arch/arm/cpu/armv8/start.S b/arch/arm/cpu/armv8/start.S >>> index 002698b501c3..52cf1230c205 100644 >>> --- a/arch/arm/cpu/armv8/start.S >>> +++ b/arch/arm/cpu/armv8/start.S >>> @@ -67,8 +67,10 @@ pie_fixup: >>> adr x0, _start /* x0 <- Runtime value of _start */ >>> ldr x1, _TEXT_BASE /* x1 <- Linked value of _start */ >>> sub x9, x0, x1 /* x9 <- Run-vs-link offset */ >>> - adr x2, __rel_dyn_start /* x2 <- Runtime &__rel_dyn_start */ >>> - adr x3, __rel_dyn_end /* x3 <- Runtime &__rel_dyn_end */ >>> + adrpx2, __rel_dyn_start /* x2 <- Runtime &__rel_dyn_start */ >>> + add x2, x2, #:lo12:__rel_dyn_start >>> + adrpx3, __rel_dyn_end /* x3 <- Runtime &__rel_dyn_end */ >>> + add x3, x3, #:lo12:__rel_dyn_end >>> pie_fix_loop: >>> ldp x0, x1, [x2], #16 /* (x0, x1) <- (Link location, fixup) */ >>> ldr x4, [x2], #8/* x4 <- addend */ >>> >>
Re: [PATCH v5 02/11] pinctrl: Reformat documentation in dm/pinctrl.h
On 02.09.20 16:56, Sean Anderson wrote:
>
> On 9/2/20 8:26 AM, Heinrich Schuchardt wrote:
>> On 15.08.20 17:52, Sean Anderson wrote:
>>> This normalizes the documentatation to conform to kernel-doc style [1]. It
>>
>> Nits:
>> %s/documentatation/documentation/
>>
>>> also moves the documentation for pinctrl_ops inline, and adds argument and
>>> return-value documentation. I have kept the usual function style for these
>>> comments. I could not find any existing examples of function documentation
>>> inside structs.
>>>
>>> [1] https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html
>>>
>>> Signed-off-by: Sean Anderson
>>> Reviewed-by: Simon Glass
>>
>>
>> Before and after this patch the documentation format is incorrect. See
>> output below for the situation after the patch.
>>
>> Please include include/dm/pinctrl.h into doc/api/index.rst via a new
>> file doc/api/pnctrl.rst.
>>
>> A documentation style accepted by 'make htmldocs' is:
>>
>> struct pinctrl_ops {
>> /**
>> * @get_pins_count: Get the number of selectable pins
>> *
>> * @get_pins_count.dev: Pinctrl device to use
>> *
>> * This function is necessary to parse the "pins" property
>> * in DTS.
>> *
>> * @get_pins_count.Return:number of selectable named pins
>> *available in this driver
>> */
>> int (*get_pins_count)(struct udevice *dev);
>>
>> See the nested structures in
>>
>> https://www.kernel.org/doc/html/v5.7/doc-guide/kernel-doc.html#in-line-member-documentation-comments
>> and
>> https://www.kernel.org/doc/html/v5.7/doc-guide/kernel-doc.html#nested-structs-unions
>
> Thanks for suggesting those changes. This works better. As far as I can
> tell, fully-qualified members are only necessary when documenting nested
> structs at the top-level. When using in-line documentation, members are
> automatically nested. With that in mind, I am using the following format
>
> /**
>* @pinmux_property_set: Enable a pinmux group
>*
>* @dev: Pinctrl device to use
>*
>* @pinmux_group: A u32 representing the pin identifier and mux
>*settings. The exact format of a pinmux group is left
>*up to the driver.
>*
>* Mux a single pin to a single function based on a driver-specific
>* pinmux group. This function is necessary for parsing the "pinmux"
>* property in DTS, and for pin-muxing against a pinmux group.
>*
>* @Return:
>* Pin selector for the muxed pin if OK, or negative error code on
>* failure
>*/
> int (*pinmux_property_set)(struct udevice *dev, u32 pinmux_group);
>
> However, I am having some problems with multi-line descriptions. In the
> example above, the desciption for @pinmux_group has the first line
> bolded and the rest of the description is typeset as normal, but is
> indented. The generated html is
Use fully qualified names and you are fine.
Best regards
Heinrich
>
>
> pinmux_group: A u32 representing the pin identifier
> and mux
> settings. The exact format of a pinmux group is left up to the
> driver.
>
>
> However, it should be something like
>
> pinmux_group: A u32 representing the pin identifier
> and mux settings. The exact format of a pinmux group is left up to the
> driver.
>
> I have also tried an alternate style, as shown for @Return. However,
> this too generated the wrong html:
>
>
> Return:
> Pin selector for the muxed pin if OK, or negative error code on
> failure
>
>
> where it should generate something like
>
> Return: Pin selector for the muxed pin
> if OK, or negative error code on failure
>
> Do you have any suggestions for generating the latter forms? My current
> work is at [1].
>
> --Sean
>
> [1]
> https://github.com/Forty-Bot/u-boot/commit/e835cf9552dc96438699806731a208b40daead7b
>
Re: [PATCH] Dockerfile: Remove high UID/GID
On Wed, Sep 02, 2020 at 02:33:22PM +0200, Harm Berntsen wrote: > When running Docker with user namespace remapping, the UID/GID of the > files must be in the 0 - 65535 range. One toolchain's tar file included > files outside of that range and thus I could not run the image on my > GitLab runners. This patch fixes that and the U-Boot CI completes just > fine in my environment. > > Signed-off-by: Harm Berntsen > CC: Tom Rini Applied to gitlab-ci-runner/master, thanks! -- Tom signature.asc Description: PGP signature
spl_ll_find_loader() function in common/spl/spl.c is returning NULL
Hi, We have an imx.6 based custom board and we have emmc, SD card and SPI NOR Flash(MX66L51235FZ2i-10g from Macronix) as boot devices on our board based on imx6 (MC imx6D7CVT08AE) processor. our requirement is to boot SPL + U-boot from the SPI NOR Flash and then load the linux kernel from emmc interface. we are able to boot the board (SPL + U-boot + Linux) through SD-card and emmc interface. we have flashed SPL at offset value of 0x400 in Flash address using following command: dd if=/boot/SPL of=/dev/mtd0 bs=1K seek=1 and flashed U-boot.img at offset value 0f 0x11400 using the following command: dd if=/boot/u-boot.img of=/dev/mtd0 bs=1K seek=69 After configuring the board boot settings to load from the SPI NOR Flash when we Power on the board we are getting following message: U-Boot SPL 2018.01-02296-g457cdd6-dirty (Aug 27 2020 - 10:22:07) >>spl:board_init_r() SPL: Unsupported Boot Device! Trying to boot from USB SDP SDP: initialize... After further debugging found that spl_ll_find_loader() function in file "u-boot\common\spl\spl.c" is unable to find the loader. spl_ll_find_loader() is returning "0" when the board is configured to boot from SPI NOR Flash. Following are the debug trace messages from the board when it is booted through SPI NOR Flash: U-Boot SPL 2018.01-02296-g457cdd6-dirty (Aug 27 2020 - 10:22:07) Entering spl_boot_device() bmode(sbmr2):570425345 Board boot order:8 spl_ll_find_loader() returning NULL boot_from_devices() : loader:0 SPL: Unsupported Boot Device! spl_boot_list[1]:12 inside boot_from_devices() : loader:9528148 Trying to boot from USB SDP spl_load_image():bootdev.boot_device:12 SDP: initialize... Please let us know why spl_ll_find_loader() function in file "u-boot\common\spl\spl.c" is unable To return valid loader address when the board is configured to boot from SPI NOR Flash. Are we missing any specific configuration ? Thanks in Advance, N.V.Murali Krishna, murali.krish...@tcs.com =-=-= Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you
Re: [PATCH v5 02/11] pinctrl: Reformat documentation in dm/pinctrl.h
On 9/2/20 8:26 AM, Heinrich Schuchardt wrote:
> On 15.08.20 17:52, Sean Anderson wrote:
>> This normalizes the documentatation to conform to kernel-doc style [1]. It
>
> Nits:
> %s/documentatation/documentation/
>
>> also moves the documentation for pinctrl_ops inline, and adds argument and
>> return-value documentation. I have kept the usual function style for these
>> comments. I could not find any existing examples of function documentation
>> inside structs.
>>
>> [1] https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html
>>
>> Signed-off-by: Sean Anderson
>> Reviewed-by: Simon Glass
>
>
> Before and after this patch the documentation format is incorrect. See
> output below for the situation after the patch.
>
> Please include include/dm/pinctrl.h into doc/api/index.rst via a new
> file doc/api/pnctrl.rst.
>
> A documentation style accepted by 'make htmldocs' is:
>
> struct pinctrl_ops {
> /**
> * @get_pins_count: Get the number of selectable pins
> *
> * @get_pins_count.dev: Pinctrl device to use
> *
> * This function is necessary to parse the "pins" property
> * in DTS.
> *
> * @get_pins_count.Return:number of selectable named pins
> *available in this driver
> */
> int (*get_pins_count)(struct udevice *dev);
>
> See the nested structures in
>
> https://www.kernel.org/doc/html/v5.7/doc-guide/kernel-doc.html#in-line-member-documentation-comments
> and
> https://www.kernel.org/doc/html/v5.7/doc-guide/kernel-doc.html#nested-structs-unions
Thanks for suggesting those changes. This works better. As far as I can
tell, fully-qualified members are only necessary when documenting nested
structs at the top-level. When using in-line documentation, members are
automatically nested. With that in mind, I am using the following format
/**
* @pinmux_property_set: Enable a pinmux group
*
* @dev: Pinctrl device to use
*
* @pinmux_group: A u32 representing the pin identifier and mux
*settings. The exact format of a pinmux group is left
*up to the driver.
*
* Mux a single pin to a single function based on a driver-specific
* pinmux group. This function is necessary for parsing the "pinmux"
* property in DTS, and for pin-muxing against a pinmux group.
*
* @Return:
* Pin selector for the muxed pin if OK, or negative error code on
* failure
*/
int (*pinmux_property_set)(struct udevice *dev, u32 pinmux_group);
However, I am having some problems with multi-line descriptions. In the
example above, the desciption for @pinmux_group has the first line
bolded and the rest of the description is typeset as normal, but is
indented. The generated html is
pinmux_group: A u32 representing the pin identifier
and mux
settings. The exact format of a pinmux group is left up to the
driver.
However, it should be something like
pinmux_group: A u32 representing the pin identifier
and mux settings. The exact format of a pinmux group is left up to the
driver.
I have also tried an alternate style, as shown for @Return. However,
this too generated the wrong html:
Return:
Pin selector for the muxed pin if OK, or negative error code on
failure
where it should generate something like
Return: Pin selector for the muxed pin
if OK, or negative error code on failure
Do you have any suggestions for generating the latter forms? My current
work is at [1].
--Sean
[1]
https://github.com/Forty-Bot/u-boot/commit/e835cf9552dc96438699806731a208b40daead7b
Re: [PATCH] arm64: Add support for bigger u-boot when CONFIG_POSITION_INDEPENDENT=y
On Wed, Sep 02, 2020 at 03:43:08PM +0100, André Przywara wrote: > On 02/09/2020 12:15, Michal Simek wrote: > > Hi, Hi Andre, > > > From: "Edgar E. Iglesias" > > > > When U-Boot binary exceeds 1MB with CONFIG_POSITION_INDEPENDENT=y > > compilation error is shown: > > /mnt/disk/u-boot/arch/arm/cpu/armv8/start.S:71:(.text+0x3c): relocation > > truncated to fit: R_AARCH64_ADR_PREL_LO21 against symbol `__rel_dyn_end' > > defined in .bss_start section in u-boot. > > > > It is caused by adr instruction which permits the calculation of any byte > > address within +- 1MB of the current PC. > > Because U-Boot is bigger then 1MB calculation is failing. > > > > The patch is using adrp/add instructions where adrp shifts a signed, 21-bit > > immediate left by 12 bits (4k page), adds it to the value of the program > > counter with the bottom 12 bits cleared to zero. Then add instruction > > provides the lower 12 bits which is offset within 4k page. > > These two instructions together compose full 32bit offset which should be > > more then enough to cover the whole u-boot size. > > > > Signed-off-by: Edgar E. Iglesias > > Signed-off-by: Michal Simek > > It's a bit scary that you need more than 1MB, but indeed what you do > below is the canonical pattern to get the full range of PC relative > addressing (this is used heavily in Trusted Firmware, for instance). > > The only thing to keep in mind is that this assumes that the load > address of the binary is 4K aligned, so that the low 12 bits of the > symbol stay the same. I wonder if we should enforce this somehow? But > the load address is not controlled by the build process (the whole > purpose of PIE), so that's not doable just in the build system? There shouldn't be any need for 4K alignment. Could you elaborate on why you think there is? Perhaps the commit message is a little confusing. The toolchain will compute the pc-relative offset from this particular location to the symbol and apply the relocations accordingly. Best regards, Edgar > > Shall we at least document this? I guess typical load address are > actually quite well aligned, so it might not be an issue in practice. > > Cheers, > Andre > > > --- > > > > arch/arm/cpu/armv8/start.S | 6 -- > > 1 file changed, 4 insertions(+), 2 deletions(-) > > > > diff --git a/arch/arm/cpu/armv8/start.S b/arch/arm/cpu/armv8/start.S > > index 002698b501c3..52cf1230c205 100644 > > --- a/arch/arm/cpu/armv8/start.S > > +++ b/arch/arm/cpu/armv8/start.S > > @@ -67,8 +67,10 @@ pie_fixup: > > adr x0, _start /* x0 <- Runtime value of _start */ > > ldr x1, _TEXT_BASE /* x1 <- Linked value of _start */ > > sub x9, x0, x1 /* x9 <- Run-vs-link offset */ > > - adr x2, __rel_dyn_start /* x2 <- Runtime &__rel_dyn_start */ > > - adr x3, __rel_dyn_end /* x3 <- Runtime &__rel_dyn_end */ > > + adrpx2, __rel_dyn_start /* x2 <- Runtime &__rel_dyn_start */ > > + add x2, x2, #:lo12:__rel_dyn_start > > + adrpx3, __rel_dyn_end /* x3 <- Runtime &__rel_dyn_end */ > > + add x3, x3, #:lo12:__rel_dyn_end > > pie_fix_loop: > > ldp x0, x1, [x2], #16 /* (x0, x1) <- (Link location, fixup) */ > > ldr x4, [x2], #8/* x4 <- addend */ > > >
Re: [PATCH] arm64: Add support for bigger u-boot when CONFIG_POSITION_INDEPENDENT=y
Hi, On 02. 09. 20 16:43, André Przywara wrote: > On 02/09/2020 12:15, Michal Simek wrote: > > Hi, > >> From: "Edgar E. Iglesias" >> >> When U-Boot binary exceeds 1MB with CONFIG_POSITION_INDEPENDENT=y >> compilation error is shown: >> /mnt/disk/u-boot/arch/arm/cpu/armv8/start.S:71:(.text+0x3c): relocation >> truncated to fit: R_AARCH64_ADR_PREL_LO21 against symbol `__rel_dyn_end' >> defined in .bss_start section in u-boot. >> >> It is caused by adr instruction which permits the calculation of any byte >> address within +- 1MB of the current PC. >> Because U-Boot is bigger then 1MB calculation is failing. >> >> The patch is using adrp/add instructions where adrp shifts a signed, 21-bit >> immediate left by 12 bits (4k page), adds it to the value of the program >> counter with the bottom 12 bits cleared to zero. Then add instruction >> provides the lower 12 bits which is offset within 4k page. >> These two instructions together compose full 32bit offset which should be >> more then enough to cover the whole u-boot size. >> >> Signed-off-by: Edgar E. Iglesias >> Signed-off-by: Michal Simek > > It's a bit scary that you need more than 1MB, but indeed what you do > below is the canonical pattern to get the full range of PC relative > addressing (this is used heavily in Trusted Firmware, for instance). We have generic u-boot where we are enabling all features which you can use and it is up to everybody to disable what they don't need. We are at 1MB limit that's why I spot this issue and trying to solve it. > > The only thing to keep in mind is that this assumes that the load > address of the binary is 4K aligned, so that the low 12 bits of the > symbol stay the same. I wonder if we should enforce this somehow? But > the load address is not controlled by the build process (the whole > purpose of PIE), so that's not doable just in the build system? That's more question to you if we can enforce is somehow. :-) > Shall we at least document this? I guess typical load address are > actually quite well aligned, so it might not be an issue in practice. maybe note this in Kconfig help for POSITION_INDEPENDENT? Any other location? Thanks, Michal
Re: [PATCH] arm64: Add support for bigger u-boot when CONFIG_POSITION_INDEPENDENT=y
On 02/09/2020 12:15, Michal Simek wrote: Hi, > From: "Edgar E. Iglesias" > > When U-Boot binary exceeds 1MB with CONFIG_POSITION_INDEPENDENT=y > compilation error is shown: > /mnt/disk/u-boot/arch/arm/cpu/armv8/start.S:71:(.text+0x3c): relocation > truncated to fit: R_AARCH64_ADR_PREL_LO21 against symbol `__rel_dyn_end' > defined in .bss_start section in u-boot. > > It is caused by adr instruction which permits the calculation of any byte > address within +- 1MB of the current PC. > Because U-Boot is bigger then 1MB calculation is failing. > > The patch is using adrp/add instructions where adrp shifts a signed, 21-bit > immediate left by 12 bits (4k page), adds it to the value of the program > counter with the bottom 12 bits cleared to zero. Then add instruction > provides the lower 12 bits which is offset within 4k page. > These two instructions together compose full 32bit offset which should be > more then enough to cover the whole u-boot size. > > Signed-off-by: Edgar E. Iglesias > Signed-off-by: Michal Simek It's a bit scary that you need more than 1MB, but indeed what you do below is the canonical pattern to get the full range of PC relative addressing (this is used heavily in Trusted Firmware, for instance). The only thing to keep in mind is that this assumes that the load address of the binary is 4K aligned, so that the low 12 bits of the symbol stay the same. I wonder if we should enforce this somehow? But the load address is not controlled by the build process (the whole purpose of PIE), so that's not doable just in the build system? Shall we at least document this? I guess typical load address are actually quite well aligned, so it might not be an issue in practice. Cheers, Andre > --- > > arch/arm/cpu/armv8/start.S | 6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/arch/arm/cpu/armv8/start.S b/arch/arm/cpu/armv8/start.S > index 002698b501c3..52cf1230c205 100644 > --- a/arch/arm/cpu/armv8/start.S > +++ b/arch/arm/cpu/armv8/start.S > @@ -67,8 +67,10 @@ pie_fixup: > adr x0, _start /* x0 <- Runtime value of _start */ > ldr x1, _TEXT_BASE /* x1 <- Linked value of _start */ > sub x9, x0, x1 /* x9 <- Run-vs-link offset */ > - adr x2, __rel_dyn_start /* x2 <- Runtime &__rel_dyn_start */ > - adr x3, __rel_dyn_end /* x3 <- Runtime &__rel_dyn_end */ > + adrpx2, __rel_dyn_start /* x2 <- Runtime &__rel_dyn_start */ > + add x2, x2, #:lo12:__rel_dyn_start > + adrpx3, __rel_dyn_end /* x3 <- Runtime &__rel_dyn_end */ > + add x3, x3, #:lo12:__rel_dyn_end > pie_fix_loop: > ldp x0, x1, [x2], #16 /* (x0, x1) <- (Link location, fixup) */ > ldr x4, [x2], #8/* x4 <- addend */ >
Re: [RESEND PATCH v2 01/11] usb: xhci: add a member hci_version in xhci_ctrl struct
On Wed, Sep 2, 2020 at 6:38 PM Marek Vasut wrote:
>
> On 9/2/20 8:13 AM, Frank Wunderlich wrote:
> > From: Chunfeng Yun
> >
> > Add a member to save xHCI version, it's used some times.
> >
> > Signed-off-by: Chunfeng Yun
> > ---
> > drivers/usb/host/xhci-ring.c | 4 ++--
> > drivers/usb/host/xhci.c | 1 +
> > include/usb/xhci.h | 1 +
> > 3 files changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
> > index 092ed6eaf1..79bfc349f4 100644
> > --- a/drivers/usb/host/xhci-ring.c
> > +++ b/drivers/usb/host/xhci-ring.c
> > @@ -682,7 +682,7 @@ int xhci_bulk_tx(struct usb_device *udev, unsigned long
> > pipe,
> > field |= TRB_ISP;
> >
> > /* Set the TRB length, TD size, and interrupter fields. */
> > - if (HC_VERSION(xhci_readl(>hccr->cr_capbase)) < 0x100)
> > + if (ctrl->hci_version < 0x100)
> > remainder = xhci_td_remainder(length - running_total);
> > else
> > remainder = xhci_v1_0_td_remainder(running_total,
> > @@ -830,7 +830,7 @@ int xhci_ctrl_tx(struct usb_device *udev, unsigned long
> > pipe,
> > field |= 0x1;
> >
> > /* xHCI 1.0 6.4.1.2.1: Transfer Type field */
> > - if (HC_VERSION(xhci_readl(>hccr->cr_capbase)) >= 0x100) {
> > + if (ctrl->hci_version >= 0x100) {
> > if (length > 0) {
> > if (req->requesttype & USB_DIR_IN)
> > field |= (TRB_DATA_IN << TRB_TX_TYPE_SHIFT);
> > diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
> > index 126dabc11b..4be1411243 100644
> > --- a/drivers/usb/host/xhci.c
> > +++ b/drivers/usb/host/xhci.c
> > @@ -1283,6 +1283,7 @@ static int xhci_lowlevel_init(struct xhci_ctrl *ctrl)
> >
> > reg = HC_VERSION(xhci_readl(>cr_capbase));
> > printf("USB XHCI %x.%02x\n", reg >> 8, reg & 0xff);
> > + ctrl->hci_version = reg;
> >
> > return 0;
> > }
> > diff --git a/include/usb/xhci.h b/include/usb/xhci.h
> > index 7d34103fd5..a3e5914b10 100644
> > --- a/include/usb/xhci.h
> > +++ b/include/usb/xhci.h
> > @@ -1227,6 +1227,7 @@ struct xhci_ctrl {
> > struct xhci_scratchpad *scratchpad;
> > struct xhci_virt_device *devs[MAX_HC_SLOTS];
> > int rootdev;
> > + u16 hci_version;
> > };
> >
> > unsigned long trb_addr(struct xhci_segment *seg, union xhci_trb *trb);
> >
> +CC Bin
Thanks Marek. Will take a look at this series soon.
Regards,
Bin
[PATCH 01/11] board/freescale: Remove p1023rdb board support
Remove NXP powerpc p1023rdb board support as it is no
longer maintained.
Signed-off-by: Priyanka Jain
---
arch/powerpc/cpu/mpc85xx/Kconfig | 8 -
board/freescale/p1023rdb/Kconfig | 12 -
board/freescale/p1023rdb/MAINTAINERS | 6 -
board/freescale/p1023rdb/Makefile| 8 -
board/freescale/p1023rdb/ddr.c | 85 ---
board/freescale/p1023rdb/law.c | 17 --
board/freescale/p1023rdb/p1023rdb.c | 160 -
board/freescale/p1023rdb/tlb.c | 98
configs/P1023RDB_defconfig | 50
include/configs/P1023RDB.h | 338 ---
10 files changed, 782 deletions(-)
delete mode 100644 board/freescale/p1023rdb/Kconfig
delete mode 100644 board/freescale/p1023rdb/MAINTAINERS
delete mode 100644 board/freescale/p1023rdb/Makefile
delete mode 100644 board/freescale/p1023rdb/ddr.c
delete mode 100644 board/freescale/p1023rdb/law.c
delete mode 100644 board/freescale/p1023rdb/p1023rdb.c
delete mode 100644 board/freescale/p1023rdb/tlb.c
delete mode 100644 configs/P1023RDB_defconfig
delete mode 100644 include/configs/P1023RDB.h
diff --git a/arch/powerpc/cpu/mpc85xx/Kconfig b/arch/powerpc/cpu/mpc85xx/Kconfig
index 753d0750b2..0707beebf8 100644
--- a/arch/powerpc/cpu/mpc85xx/Kconfig
+++ b/arch/powerpc/cpu/mpc85xx/Kconfig
@@ -109,13 +109,6 @@ config TARGET_P1010RDB_PB
imply CMD_SATA
imply PANIC_HANG
-config TARGET_P1023RDB
- bool "Support P1023RDB"
- select ARCH_P1023
- select FSL_DDR_INTERACTIVE
- imply CMD_EEPROM
- imply PANIC_HANG
-
config TARGET_P1020MBG
bool "Support P1020MBG-PC"
select SUPPORT_SPL
@@ -1506,7 +1499,6 @@ source "board/freescale/mpc8568mds/Kconfig"
source "board/freescale/mpc8569mds/Kconfig"
source "board/freescale/mpc8572ds/Kconfig"
source "board/freescale/p1010rdb/Kconfig"
-source "board/freescale/p1023rdb/Kconfig"
source "board/freescale/p1_p2_rdb_pc/Kconfig"
source "board/freescale/p2041rdb/Kconfig"
source "board/freescale/qemu-ppce500/Kconfig"
diff --git a/board/freescale/p1023rdb/Kconfig b/board/freescale/p1023rdb/Kconfig
deleted file mode 100644
index 1e4cd10c6c..00
--- a/board/freescale/p1023rdb/Kconfig
+++ /dev/null
@@ -1,12 +0,0 @@
-if TARGET_P1023RDB
-
-config SYS_BOARD
- default "p1023rdb"
-
-config SYS_VENDOR
- default "freescale"
-
-config SYS_CONFIG_NAME
- default "P1023RDB"
-
-endif
diff --git a/board/freescale/p1023rdb/MAINTAINERS
b/board/freescale/p1023rdb/MAINTAINERS
deleted file mode 100644
index c06bac6d0d..00
--- a/board/freescale/p1023rdb/MAINTAINERS
+++ /dev/null
@@ -1,6 +0,0 @@
-P1023RDB BOARD
-#M:-
-S: Maintained
-F: board/freescale/p1023rdb/
-F: include/configs/P1023RDB.h
-F: configs/P1023RDB_defconfig
diff --git a/board/freescale/p1023rdb/Makefile
b/board/freescale/p1023rdb/Makefile
deleted file mode 100644
index 78dc5d595a..00
--- a/board/freescale/p1023rdb/Makefile
+++ /dev/null
@@ -1,8 +0,0 @@
-# SPDX-License-Identifier: GPL-2.0+
-#
-# Copyright 2013 Freescale Semiconductor, Inc.
-
-obj-y += p1023rdb.o
-obj-y += ddr.o
-obj-y += law.o
-obj-y += tlb.o
diff --git a/board/freescale/p1023rdb/ddr.c b/board/freescale/p1023rdb/ddr.c
deleted file mode 100644
index dc7a909e03..00
--- a/board/freescale/p1023rdb/ddr.c
+++ /dev/null
@@ -1,85 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0+
-/*
- * Copyright 2013 Freescale Semiconductor, Inc.
- */
-
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-
-/* CONFIG_SYS_DDR_RAW_TIMING */
-/*
- * Hynix H5TQ1G83TFR-H9C
- */
-dimm_params_t ddr_raw_timing = {
- .n_ranks = 1,
- .rank_density = 536870912u,
- .capacity = 536870912u,
- .primary_sdram_width = 32,
- .ec_sdram_width = 0,
- .registered_dimm = 0,
- .mirrored_dimm = 0,
- .n_row_addr = 14,
- .n_col_addr = 10,
- .n_banks_per_sdram_device = 8,
- .edc_config = 0,
- .burst_lengths_bitmask = 0x0c,
-
- .tckmin_x_ps = 1875,
- .caslat_x = 0x1e << 4, /* 5,6,7,8 */
- .taa_ps = 13125,
- .twr_ps = 18000,
- .trcd_ps = 13125,
- .trrd_ps = 7500,
- .trp_ps = 13125,
- .tras_ps = 37500,
- .trc_ps = 50625,
- .trfc_ps = 16,
- .twtr_ps = 7500,
- .trtp_ps = 7500,
- .refresh_rate_ps = 780,
- .tfaw_ps = 37500,
-};
-
-int fsl_ddr_get_dimm_params(dimm_params_t *pdimm,
- unsigned int controller_number,
- unsigned int dimm_number)
-{
- const char dimm_model[] = "Fixed DDR on board";
-
- if ((controller_number == 0) && (dimm_number == 0)) {
- memcpy(pdimm, _raw_timing, sizeof(dimm_params_t));
- memset(pdimm->mpart, 0, sizeof(pdimm->mpart));
- memcpy(pdimm->mpart, dimm_model, sizeof(dimm_model) - 1);
- }
-
- return 0;
-}
-
-void fsl_ddr_board_options(memctl_options_t *popts,
-
[PATCH] Dockerfile: Remove high UID/GID
When running Docker with user namespace remapping, the UID/GID of the files must be in the 0 - 65535 range. One toolchain's tar file included files outside of that range and thus I could not run the image on my GitLab runners. This patch fixes that and the U-Boot CI completes just fine in my environment. Signed-off-by: Harm Berntsen CC: Tom Rini --- Dockerfile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Dockerfile b/Dockerfile index 3bcd4b9..247122e 100644 --- a/Dockerfile +++ b/Dockerfile @@ -29,7 +29,7 @@ RUN wget -O - https://mirrors.edge.kernel.org/pub/tools/crosstool/files/bin/x86_ # Manually install other toolchains RUN wget -O - https://github.com/foss-xtensa/toolchain/releases/download/2018.02/x86_64-2018.02-xtensa-dc233c-elf.tar.gz | tar -C /opt -xz -RUN wget -O - https://github.com/foss-for-synopsys-dwc-arc-processors/toolchain/releases/download/arc-2019.09-release/arc_gnu_2019.09_prebuilt_uclibc_le_archs_linux_install.tar.gz | tar -C /opt -xz +RUN wget -O - https://github.com/foss-for-synopsys-dwc-arc-processors/toolchain/releases/download/arc-2019.09-release/arc_gnu_2019.09_prebuilt_uclibc_le_archs_linux_install.tar.gz | tar --no-same-owner -C /opt -xz RUN wget -O - https://github.com/vincentzwc/prebuilt-nds32-toolchain/releases/download/20180521/nds32le-linux-glibc-v3-upstream.tar.gz | tar -C /opt -xz # Update and install things from apt now -- 2.28.0
[PATCH] buildman: Use git worktrees instead of git clones
This patch makes buildman create linked working trees instead of clones
of the source repository, but keeps updating the older clones of the
repository that might already exist. These worktrees share "everything
except working directory specific files such as HEAD, index, etc." with
the source repository. See the git-worktree(1) manual page for more
information.
Signed-off-by: Alper Nebi Yasak
---
The git-worktree is available since about 2015 (git v2.5), but its
manual page mentions this in its BUGS section:
Multiple checkout in general is still experimental, and the
support for submodules is incomplete. It is NOT recommended to
make multiple checkouts of a superproject.
I think it'll be fine since U-Boot doesn't use submodules, but still
wanted to let you know.
tools/buildman/builder.py | 36
tools/buildman/func_test.py | 2 ++
tools/patman/gitutil.py | 28
3 files changed, 54 insertions(+), 12 deletions(-)
diff --git a/tools/buildman/builder.py b/tools/buildman/builder.py
index dbb75b35c1..9cb65c15a8 100644
--- a/tools/buildman/builder.py
+++ b/tools/buildman/builder.py
@@ -1540,31 +1540,38 @@ class Builder:
def _PrepareThread(self, thread_num, setup_git):
"""Prepare the working directory for a thread.
-This clones or fetches the repo into the thread's work directory.
+This adds a git worktree for the repo into the thread's work
+directory or fetches the repo into a clone that might already
+exist there.
Args:
thread_num: Thread number (0, 1, ...)
-setup_git: True to set up a git repo clone
+setup_git: True to set up a git worktree
"""
thread_dir = self.GetThreadDir(thread_num)
builderthread.Mkdir(thread_dir)
git_dir = os.path.join(thread_dir, '.git')
-# Clone the repo if it doesn't already exist
-# TODO(sjg@chromium): Perhaps some git hackery to symlink instead, so
-# we have a private index but uses the origin repo's contents?
+# Create a worktree for this thread if it (or a git repo clone)
+# doesn't already exist
if setup_git and self.git_dir:
src_dir = os.path.abspath(self.git_dir)
-if os.path.exists(git_dir):
+if not os.path.exists(git_dir):
+Print('\rChecking out worktree for thread %d' % thread_num,
+ newline=False)
+gitutil.AddWorktree(src_dir, thread_dir)
+terminal.PrintClear()
+elif os.path.isdir(git_dir):
+# Older versions cloned the src_dir repo, we can keep using
+# the clones but need to fetch from src_dir.
Print('\rFetching repo for thread %d' % thread_num,
newline=False)
gitutil.Fetch(git_dir, thread_dir)
terminal.PrintClear()
-else:
-Print('\rCloning repo for thread %d' % thread_num,
- newline=False)
-gitutil.Clone(src_dir, thread_dir)
-terminal.PrintClear()
+elif os.path.isfile(git_dir):
+# This is a worktree of the src_dir repo, we don't need to
+# create it again.
+pass
def _PrepareWorkingSpace(self, max_threads, setup_git):
"""Prepare the working directory for use.
@@ -1573,9 +1580,14 @@ class Builder:
Args:
max_threads: Maximum number of threads we expect to need.
-setup_git: True to set up a git repo clone
+setup_git: True to set up a git worktree
"""
builderthread.Mkdir(self._working_dir)
+if setup_git and self.git_dir:
+# If we previously added a worktree but the directory for it
+# got deleted, we need to prune its files from the repo so
+# that we can check out another in its place.
+gitutil.PruneWorktrees(os.path.abspath(self.git_dir))
for thread in range(max_threads):
self._PrepareThread(thread, setup_git)
diff --git a/tools/buildman/func_test.py b/tools/buildman/func_test.py
index 418677f9cc..3dd2e6ee5b 100644
--- a/tools/buildman/func_test.py
+++ b/tools/buildman/func_test.py
@@ -319,6 +319,8 @@ class TestFunctional(unittest.TestCase):
return command.CommandResult(return_code=0)
elif sub_cmd == 'checkout':
return command.CommandResult(return_code=0)
+elif sub_cmd == 'worktree':
+return command.CommandResult(return_code=0)
# Not handled, so abort
print('git', git_args, sub_cmd, args)
diff --git a/tools/patman/gitutil.py b/tools/patman/gitutil.py
index 192d8e69b3..354884a79d 100644
--- a/tools/patman/gitutil.py
+++ b/tools/patman/gitutil.py
@@ -259,6 +259,34 @@ def Fetch(git_dir=None, work_tree=None):
if
Re: [PATCH 2/2] pcie: pcie_advk: move setting of reference clock to the pcie driver
On Wed, 2 Sep 2020 09:11:52 +0200 Andre Heider wrote: > On 31/08/2020 09:52, Pali Rohár wrote: > > On Monday 31 August 2020 05:25:38 Andre Heider wrote: > >> From: Grzegorz Jaszczyk > >> > >> The settings of reference clock is done via pcie address space and > >> not comphy address space - move the settings in appropriate place. > >> > >> This aligns hw initialization of pcie advk with Linux and also > >> will allow to get rid of not comphy related operation from the > >> comphy driver. > >> > >> Change-Id: I9cc2e8f3e415a880dfb01d10cc8db73b7e81a605 > >> Signed-off-by: Grzegorz Jaszczyk > >> Reviewed-on: http://vgitil04.il.marvell.com:8080/59619 > >> Reviewed-by: Igal Liberman > >> Tested-by: iSoC Platform CI > >> [a.heider: adapt to mainline] > >> Signed-off-by: Andre Heider > >> --- > >> Missing downstream patch, noticed while diffing branches: > >> https://github.com/MarvellEmbeddedProcessors/u-boot-marvell/commit/e3d9c015d434f755578a86a4b6b3acd17d69238a > >> > > > > It looks like this patch only moves initialization code from one > > file to another. It is fixing some issue? I have tested PCIe on > > both MOX and Espressobin and it worked fine. If there is no issue I > > would rather wait for Marek comphy patches which should completely > > remove current marvell comphy driver from u-boot. > > I just found out that Marek's patches cover this, so this patch can > be dropped: > https://patchwork.ozlabs.org/project/uboot/patch/20200419154850.25868-8-marek.be...@nic.cz/ > > Thanks, > Andre Hi, that patch series wasn't accepted though, it needs some work. I will try to this ASAP. Marek
Re: [PATCH v5 11/11] riscv: Add FPIOA and GPIO support for Kendryte K210
On 01.09.20 03:19, Rick Chen wrote: > Hi Sean > >> On 8/20/20 4:47 AM, Rick Chen wrote: >>> Hi Sean >>> Hi Sean > On 8/18/20 11:48 PM, Rick Chen wrote: >> Hi Tom >> >>> This patch adds the necessary configs and docs for FPIOA and GPIO >>> support >>> on the K210. >>> >>> The board does not boot unless CONSOLE_LOGLEVEL is set to a non-default >>> value . It also boots when the tree is dirty (and CONSOLE_LOGLEVEL is >>> not >>> changed). It also boots when changes are made to the device tree and >>> then >>> committed. I don't know why this happens. These breakages only occur >>> after >>> bf2fb81ad3. >>> >>> Signed-off-by: Sean Anderson >>> --- >>> >>> Changes in v5: >>> - Increase CONSOLE_LOGLEVEL to 5 as a hack to get the board booting >>> again >>> - Patch 05/12 "gpio: sifive: Use generic reg read function" has been >>> superseded >>> by commit 2548493ab4. >> >> Would you like to pick up this series, [PATCH v5 00/11] riscv: Add >> FPIOA and GPIO support for Kendryte K210 ? >> Or maybe it is better to figure out what is wrong here and find the >> root cause why it need to Increase CONSOLE_LOGLEVEL to 5 as a hack ? > > As an additional note, *CONFIG_LOGLEVEL (whoops) can also be decreased > for the same effect. In addition, there are several other ways I found > to "fix" this bug (as noted in the commit message). If you would like to > test this out, I have two trees [1, 2] where this series (actually a > slightly > earlier version of this series) is applied just before and just after > bf2fb81ad3. The original patch is located at [3]. > > --Sean > > [1] https://github.com/Forty-Bot/u-boot/tree/maix_gpio_good > [2] https://github.com/Forty-Bot/u-boot/tree/maix_gpio_bad > [3] > https://patchwork.ozlabs.org/project/uboot/patch/20200724111225.12513-15-ovidiu.pan...@windriver.com/ I don't have a K210 board for verification. But it is OK to run in AE350 board after applying your series. After check about this commit "common/board_r: Remove initr_serial wrapper", it seem shall not affect anything. It just change to call serial_initialize directly. Only I can think about maybe it is a cache problem. Just like sometime we add a printf, then the problem will be walk around. >>> >>> Can you dig in to find the root cause ? >>> For code stability, it is better not to have any unknown issue. >>> Yo can dirty hack and work around currently, but it may crash again >>> after several commits. >> >> Ok, so I did some further digging, but I was unable to pin down the >> cause of the bug. My efforts to determine a cause have been primarily >> thwarted because the bug disappears after any change to initialization >> code. Adding any function to init_sequence_f or init_sequence_r, even a >> no-op function which just returns 0, causes the board to boot normally. >> In addition, adding a nop() to any function in those sequences will >> cause the board to boot normally. The board seems to fail to boot only >> with a very specific boot sequence and timing. > > If you modify any code and the result will change, then you shall > debug it via debugger(GDB) without any code modification. > >> >> When the board fails to boot, it hangs in a manner similar to when the > > Maybe you can try to set a break and access the bus, if the bus access > fail, then you re-set a break a bit ahead until the bus access NOT > fail. > To see if this way can pin down which instruction or the crucial code > to cause the bus hang problem. And guess what maybe the root-cause. > > If you can find the instruction which may cause the bus hang, you can > info all-registers and compare the differences between NG and OK. And > guess what maybe the root-cause. Trying to narrow down on the problem I found the following: The system hangs before arch_cpu_init_dm() is called. After adding some debug functions the error appeared and disappeared when changing the code in function panic(). So my guess is that there is some alignment problem in the static data section. Best regards Heinrich > > Thanks, > Rick > >> airam is accessed: the bus appears to hang. Just as when airam is >> accessed, a debugger cannot read registers or memory until the cpu is >> reset. This may be a separate issue which hangs the bus, or it could >> also be caused by an inadvertent access to airam. The puzzling thing is >> still the manner of triggering the bug. It's almost as if it was >> specifically designed to be impossible to debug by disappearing whenever >> one makes an attempt... >> >> --Sean
Re: [PATCH v5 02/11] pinctrl: Reformat documentation in dm/pinctrl.h
On 15.08.20 17:52, Sean Anderson wrote:
> This normalizes the documentatation to conform to kernel-doc style [1]. It
Nits:
%s/documentatation/documentation/
> also moves the documentation for pinctrl_ops inline, and adds argument and
> return-value documentation. I have kept the usual function style for these
> comments. I could not find any existing examples of function documentation
> inside structs.
>
> [1] https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html
>
> Signed-off-by: Sean Anderson
> Reviewed-by: Simon Glass
Before and after this patch the documentation format is incorrect. See
output below for the situation after the patch.
Please include include/dm/pinctrl.h into doc/api/index.rst via a new
file doc/api/pnctrl.rst.
A documentation style accepted by 'make htmldocs' is:
struct pinctrl_ops {
/**
* @get_pins_count: Get the number of selectable pins
*
* @get_pins_count.dev: Pinctrl device to use
*
* This function is necessary to parse the "pins" property
* in DTS.
*
* @get_pins_count.Return: number of selectable named pins
* available in this driver
*/
int (*get_pins_count)(struct udevice *dev);
See the nested structures in
https://www.kernel.org/doc/html/v5.7/doc-guide/kernel-doc.html#in-line-member-documentation-comments
and
https://www.kernel.org/doc/html/v5.7/doc-guide/kernel-doc.html#nested-structs-unions
The generated doc looks like this:
Members
get_pins_count
Get the number of selectable pins
get_pins_count.dev: Pinctrl device to use
This function is necessary to parse the “pins” property in DTS.
get_pins_count.Return: number of selectable named pins
available in this driver
Best regards
Heinrich
./include/dm/pinctrl.h:38: warning: Incorrect use of kernel-doc format:
* get_pins_count() - Get the number of selectable pins
./include/dm/pinctrl.h:48: warning: Incorrect use of kernel-doc format:
* get_pin_name() - Get the name of a pin
./include/dm/pinctrl.h:61: warning: Incorrect use of kernel-doc format:
* get_groups_count() - Get the number of selectable groups
./include/dm/pinctrl.h:71: warning: Incorrect use of kernel-doc format:
* get_group_name() - Get the name of a group
./include/dm/pinctrl.h:84: warning: Incorrect use of kernel-doc format:
* get_functions_count() - Get the number of selectable functions
./include/dm/pinctrl.h:94: warning: Incorrect use of kernel-doc format:
* get_function_name() - Get the name of a function
./include/dm/pinctrl.h:108: warning: Incorrect use of kernel-doc format:
* pinmux_set() - Mux a pin to a function
./include/dm/pinctrl.h:123: warning: Incorrect use of kernel-doc format:
* pinmux_set() - Mux a group of pins to a function
./include/dm/pinctrl.h:138: warning: Incorrect use of kernel-doc format:
* pinmux_property_set() - Enable a pinmux group
./include/dm/pinctrl.h:168: warning: Incorrect use of kernel-doc format:
* pinconf_set() - configure an individual pin with a parameter
./include/dm/pinctrl.h:183: warning: Incorrect use of kernel-doc format:
* pinconf_group_set() - configure all pins in a group with a
parameter
./include/dm/pinctrl.h:198: warning: Incorrect use of kernel-doc format:
* set_state() - Configure a pinctrl device
./include/dm/pinctrl.h:211: warning: Incorrect use of kernel-doc format:
* set_state_simple() - Configure a pinctrl device
./include/dm/pinctrl.h:223: warning: Incorrect use of kernel-doc format:
* request() - Request a particular pinctrl function
./include/dm/pinctrl.h:234: warning: Incorrect use of kernel-doc format:
* get_periph_id() - get the peripheral ID for a device
./include/dm/pinctrl.h:248: warning: Incorrect use of kernel-doc format:
* get_gpio_mux() - get the mux value for a particular GPIO
./include/dm/pinctrl.h:264: warning: Incorrect use of kernel-doc format:
* get_pin_muxing() - show pin muxing
./include/dm/pinctrl.h:281: warning: Incorrect use of kernel-doc format:
* gpio_request_enable() - request and enable GPIO on a certain pin.
./include/dm/pinctrl.h:296: warning: Incorrect use of kernel-doc format:
* gpio_disable_free() - free up GPIO muxing on a certain pin.
./include/dm/pinctrl.h:305: warning: Function parameter or member
'get_pins_count' not described in 'pinctrl_ops'
./include/dm/pinctrl.h:305: warning: Function parameter or member
'get_pin_name' not described in 'pinctrl_ops'
./include/dm/pinctrl.h:305: warning: Function parameter or member
'get_groups_count' not described in 'pinctrl_ops'
./include/dm/pinctrl.h:305: warning: Function parameter or member
'get_group_name' not described in 'pinctrl_ops'
./include/dm/pinctrl.h:305: warning: Function parameter or member
'get_functions_count' not described in 'pinctrl_ops'
./include/dm/pinctrl.h:305: warning: Function parameter or
[PATCH v2] arm: dts: lx2160a: Add IO range
Add IO range property to fix below error on uboot
PCI: Failed autoconfig bar 18
Signed-off-by: Wasim Khan
---
Changes in v2:
- Updated commit subject
arch/arm/dts/fsl-lx2160a.dtsi | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/arch/arm/dts/fsl-lx2160a.dtsi b/arch/arm/dts/fsl-lx2160a.dtsi
index dee1e2f..70efbbf 100644
--- a/arch/arm/dts/fsl-lx2160a.dtsi
+++ b/arch/arm/dts/fsl-lx2160a.dtsi
@@ -297,7 +297,8 @@
#size-cells = <2>;
device_type = "pci";
bus-range = <0x0 0xff>;
- ranges = <0x8200 0x0 0x4000 0x80 0x4000 0x0
0x4000>;
+ ranges = <0x8100 0x0 0x 0x80 0x0002 0x0
0x0001 /* downstream I/O */
+ 0x8200 0x0 0x4000 0x80 0x4000 0x0
0x4000>; /* non-prefetchable memory */
};
pcie@350 {
@@ -312,7 +313,8 @@
device_type = "pci";
num-lanes = <2>;
bus-range = <0x0 0xff>;
- ranges = <0x8200 0x0 0x4000 0x88 0x4000 0x0
0x4000>;
+ ranges = <0x8100 0x0 0x 0x88 0x0002 0x0
0x0001 /* downstream I/O */
+ 0x8200 0x0 0x4000 0x88 0x4000 0x0
0x4000>; /* non-prefetchable memory */
};
pcie@360 {
@@ -326,7 +328,8 @@
#size-cells = <2>;
device_type = "pci";
bus-range = <0x0 0xff>;
- ranges = <0x8200 0x0 0x4000 0x90 0x4000 0x0
0x4000>;
+ ranges = <0x8100 0x0 0x 0x90 0x0002 0x0
0x0001 /* downstream I/O */
+ 0x8200 0x0 0x4000 0x90 0x4000 0x0
0x4000>; /* non-prefetchable memory */
};
pcie@370 {
@@ -340,7 +343,8 @@
#size-cells = <2>;
device_type = "pci";
bus-range = <0x0 0xff>;
- ranges = <0x8200 0x0 0x4000 0x98 0x4000 0x0
0x4000>;
+ ranges = <0x8100 0x0 0x 0x98 0x0002 0x0
0x0001 /* downstream I/O */
+ 0x8200 0x0 0x4000 0x98 0x4000 0x0
0x4000>; /* non-prefetchable memory */
};
pcie@380 {
@@ -354,7 +358,8 @@
#size-cells = <2>;
device_type = "pci";
bus-range = <0x0 0xff>;
- ranges = <0x8200 0x0 0x4000 0xa0 0x4000 0x0
0x4000>;
+ ranges = <0x8100 0x0 0x 0xa0 0x0002 0x0
0x0001 /* downstream I/O */
+ 0x8200 0x0 0x4000 0xa0 0x4000 0x0
0x4000>; /* non-prefetchable memory */
};
pcie@390 {
@@ -368,7 +373,8 @@
#size-cells = <2>;
device_type = "pci";
bus-range = <0x0 0xff>;
- ranges = <0x8200 0x0 0x4000 0xa8 0x4000 0x0
0x4000>;
+ ranges = <0x8100 0x0 0x 0xa8 0x0002 0x0
0x0001 /* downstream I/O */
+ 0x8200 0x0 0x4000 0xa8 0x4000 0x0
0x4000>; /* non-prefetchable memory */
};
fsl_mc: fsl-mc@80c00 {
--
2.7.4
[PATCH 5/5] arm: mach-omap2: am33xx: Add device structure for spi
Add platform data and a device structure for the spi device
present on am335x-icev2. This requires moving all omap3_spi
platform data structures and symbols to an omap3_spi.h so that
the board file can access them.
Signed-off-by: Faiz Abbas
---
arch/arm/mach-omap2/am33xx/board.c | 12 +
drivers/spi/omap3_spi.c| 70 +--
include/configs/am335x_evm.h | 4 ++
include/omap3_spi.h| 78 ++
4 files changed, 95 insertions(+), 69 deletions(-)
create mode 100644 include/omap3_spi.h
diff --git a/arch/arm/mach-omap2/am33xx/board.c
b/arch/arm/mach-omap2/am33xx/board.c
index a7b56b6bb3..2c2b38721f 100644
--- a/arch/arm/mach-omap2/am33xx/board.c
+++ b/arch/arm/mach-omap2/am33xx/board.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -142,6 +143,17 @@ U_BOOT_DEVICES(am33xx_gpios) = {
#endif
};
#endif
+#if CONFIG_IS_ENABLED(DM_SPI) && !CONFIG_IS_ENABLED(OF_CONTROL)
+static const struct omap3_spi_plat omap3_spi_pdata = {
+ .regs = (struct mcspi *)AM33XX_SPI_OFFSET,
+ .pin_dir = MCSPI_PINDIR_D0_IN_D1_OUT,
+};
+
+U_BOOT_DEVICE(am33xx_spi) = {
+ .name = "omap3_spi",
+ .platdata = _spi_pdata,
+};
+#endif
#endif
#if !CONFIG_IS_ENABLED(DM_GPIO)
diff --git a/drivers/spi/omap3_spi.c b/drivers/spi/omap3_spi.c
index 08daacf6f0..56cb217486 100644
--- a/drivers/spi/omap3_spi.c
+++ b/drivers/spi/omap3_spi.c
@@ -22,82 +22,14 @@
#include
#include
#include
+#include
DECLARE_GLOBAL_DATA_PTR;
-#define OMAP4_MCSPI_REG_OFFSET 0x100
-
struct omap2_mcspi_platform_config {
unsigned int regs_offset;
};
-/* per-register bitmasks */
-#define OMAP3_MCSPI_SYSCONFIG_SMARTIDLE (2 << 3)
-#define OMAP3_MCSPI_SYSCONFIG_ENAWAKEUP BIT(2)
-#define OMAP3_MCSPI_SYSCONFIG_AUTOIDLE BIT(0)
-#define OMAP3_MCSPI_SYSCONFIG_SOFTRESET BIT(1)
-
-#define OMAP3_MCSPI_SYSSTATUS_RESETDONE BIT(0)
-
-#define OMAP3_MCSPI_MODULCTRL_SINGLE BIT(0)
-#define OMAP3_MCSPI_MODULCTRL_MS BIT(2)
-#define OMAP3_MCSPI_MODULCTRL_STESTBIT(3)
-
-#define OMAP3_MCSPI_CHCONF_PHA BIT(0)
-#define OMAP3_MCSPI_CHCONF_POL BIT(1)
-#define OMAP3_MCSPI_CHCONF_CLKD_MASK GENMASK(5, 2)
-#define OMAP3_MCSPI_CHCONF_EPOLBIT(6)
-#define OMAP3_MCSPI_CHCONF_WL_MASK GENMASK(11, 7)
-#define OMAP3_MCSPI_CHCONF_TRM_RX_ONLY BIT(12)
-#define OMAP3_MCSPI_CHCONF_TRM_TX_ONLY BIT(13)
-#define OMAP3_MCSPI_CHCONF_TRM_MASKGENMASK(13, 12)
-#define OMAP3_MCSPI_CHCONF_DMAWBIT(14)
-#define OMAP3_MCSPI_CHCONF_DMARBIT(15)
-#define OMAP3_MCSPI_CHCONF_DPE0BIT(16)
-#define OMAP3_MCSPI_CHCONF_DPE1BIT(17)
-#define OMAP3_MCSPI_CHCONF_IS BIT(18)
-#define OMAP3_MCSPI_CHCONF_TURBO BIT(19)
-#define OMAP3_MCSPI_CHCONF_FORCE BIT(20)
-
-#define OMAP3_MCSPI_CHSTAT_RXS BIT(0)
-#define OMAP3_MCSPI_CHSTAT_TXS BIT(1)
-#define OMAP3_MCSPI_CHSTAT_EOT BIT(2)
-
-#define OMAP3_MCSPI_CHCTRL_EN BIT(0)
-#define OMAP3_MCSPI_CHCTRL_DIS (0 << 0)
-
-#define OMAP3_MCSPI_WAKEUPENABLE_WKEN BIT(0)
-#define MCSPI_PINDIR_D0_IN_D1_OUT 0
-#define MCSPI_PINDIR_D0_OUT_D1_IN 1
-
-#define OMAP3_MCSPI_MAX_FREQ 4800
-#define SPI_WAIT_TIMEOUT 10
-
-/* OMAP3 McSPI registers */
-struct mcspi_channel {
- unsigned int chconf;/* 0x2C, 0x40, 0x54, 0x68 */
- unsigned int chstat;/* 0x30, 0x44, 0x58, 0x6C */
- unsigned int chctrl;/* 0x34, 0x48, 0x5C, 0x70 */
- unsigned int tx;/* 0x38, 0x4C, 0x60, 0x74 */
- unsigned int rx;/* 0x3C, 0x50, 0x64, 0x78 */
-};
-
-struct mcspi {
- unsigned char res1[0x10];
- unsigned int sysconfig; /* 0x10 */
- unsigned int sysstatus; /* 0x14 */
- unsigned int irqstatus; /* 0x18 */
- unsigned int irqenable; /* 0x1C */
- unsigned int wakeupenable; /* 0x20 */
- unsigned int syst; /* 0x24 */
- unsigned int modulctrl; /* 0x28 */
- struct mcspi_channel channel[4];
- /* channel0: 0x2C - 0x3C, bus 0 & 1 & 2 & 3 */
- /* channel1: 0x40 - 0x50, bus 0 & 1 */
- /* channel2: 0x54 - 0x64, bus 0 & 1 */
- /* channel3: 0x68 - 0x78, bus 0 */
-};
-
struct omap3_spi_priv {
struct mcspi *regs;
unsigned int cs;
diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h
index 9c4ef369c5..db1a89ad30 100644
--- a/include/configs/am335x_evm.h
+++ b/include/configs/am335x_evm.h
@@ -281,6 +281,10 @@
#endif
/* SPI flash. */
+#if CONFIG_IS_ENABLED(DM_SPI)
+#define AM33XX_SPI_BASE0x4803
+#define AM33XX_SPI_OFFSET (AM33XX_SPI_BASE + OMAP4_MCSPI_REG_OFFSET)
+#endif
/* Network. */
/* Enable Atheros phy driver */
diff --git a/include/omap3_spi.h b/include/omap3_spi.h
new file mode
[PATCH 4/5] spi: omap3_spi: Read platform data in ofdata_to_platdata()
Add an ofdata_to_platdata() callback to access dts in U-boot and
access all platform data in it. This prepares the driver for supporting
both device tree as well as static platform data structures in SPL.
Signed-off-by: Faiz Abbas
---
drivers/spi/omap3_spi.c | 37 ++---
1 file changed, 26 insertions(+), 11 deletions(-)
diff --git a/drivers/spi/omap3_spi.c b/drivers/spi/omap3_spi.c
index fbf9575851..08daacf6f0 100644
--- a/drivers/spi/omap3_spi.c
+++ b/drivers/spi/omap3_spi.c
@@ -482,17 +482,10 @@ static int omap3_spi_set_wordlen(struct udevice *dev,
unsigned int wordlen)
static int omap3_spi_probe(struct udevice *dev)
{
struct omap3_spi_priv *priv = dev_get_priv(dev);
- const void *blob = gd->fdt_blob;
- int node = dev_of_offset(dev);
+ struct omap3_spi_plat *plat = dev_get_platdata(dev);
- struct omap2_mcspi_platform_config* data =
- (struct omap2_mcspi_platform_config*)dev_get_driver_data(dev);
-
- priv->regs = (struct mcspi *)(dev_read_addr(dev) + data->regs_offset);
- if (fdtdec_get_bool(blob, node, "ti,pindir-d0-out-d1-in"))
- priv->pin_dir = MCSPI_PINDIR_D0_OUT_D1_IN;
- else
- priv->pin_dir = MCSPI_PINDIR_D0_IN_D1_OUT;
+ priv->regs = plat->regs;
+ priv->pin_dir = plat->pin_dir;
priv->wordlen = SPI_DEFAULT_WORDLEN;
spi_reset(priv->regs);
@@ -544,6 +537,7 @@ static const struct dm_spi_ops omap3_spi_ops = {
*/
};
+#if CONFIG_IS_ENABLED(OF_CONTROL) && !CONFIG_IS_ENABLED(OF_PLATDATA)
static struct omap2_mcspi_platform_config omap2_pdata = {
.regs_offset = 0,
};
@@ -552,16 +546,37 @@ static struct omap2_mcspi_platform_config omap4_pdata = {
.regs_offset = OMAP4_MCSPI_REG_OFFSET,
};
+static int omap3_spi_ofdata_to_platdata(struct udevice *dev)
+{
+ struct omap2_mcspi_platform_config *data =
+ (struct omap2_mcspi_platform_config *)dev_get_driver_data(dev);
+ struct omap3_spi_plat *plat = dev_get_platdata(dev);
+
+ plat->regs = (struct mcspi *)(dev_read_addr(dev) + data->regs_offset);
+
+ if (dev_read_bool(dev, "ti,pindir-d0-out-d1-in"))
+ plat->pin_dir = MCSPI_PINDIR_D0_OUT_D1_IN;
+ else
+ plat->pin_dir = MCSPI_PINDIR_D0_IN_D1_OUT;
+
+ return 0;
+}
+
static const struct udevice_id omap3_spi_ids[] = {
{ .compatible = "ti,omap2-mcspi", .data = (ulong)_pdata },
{ .compatible = "ti,omap4-mcspi", .data = (ulong)_pdata },
{ }
};
-
+#endif
U_BOOT_DRIVER(omap3_spi) = {
.name = "omap3_spi",
.id = UCLASS_SPI,
+ .flags = DM_FLAG_PRE_RELOC,
+#if CONFIG_IS_ENABLED(OF_CONTROL) && !CONFIG_IS_ENABLED(OF_PLATDATA)
.of_match = omap3_spi_ids,
+ .ofdata_to_platdata = omap3_spi_ofdata_to_platdata,
+ .platdata_auto_alloc_size = sizeof(struct omap3_spi_plat),
+#endif
.probe = omap3_spi_probe,
.ops= _spi_ops,
.priv_auto_alloc_size = sizeof(struct omap3_spi_priv),
--
2.17.1
[PATCH 3/5] spi: spi-uclass: Block dm_scan_fdt_dev with OF_CONTROL to prevent build failures
There are devices which don't use OF_CONTROL or OF_PLATDATA but instead
rely on statically defined platdata. Block dm_scan_fdt_dev() with both
configs to avoid build failures under this condition.
Signed-off-by: Faiz Abbas
---
drivers/spi/spi-uclass.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/spi/spi-uclass.c b/drivers/spi/spi-uclass.c
index cffd9cf0b0..55a8eed890 100644
--- a/drivers/spi/spi-uclass.c
+++ b/drivers/spi/spi-uclass.c
@@ -497,7 +497,7 @@ UCLASS_DRIVER(spi) = {
.id = UCLASS_SPI,
.name = "spi",
.flags = DM_UC_FLAG_SEQ_ALIAS,
-#if !CONFIG_IS_ENABLED(OF_PLATDATA)
+#if CONFIG_IS_ENABLED(OF_CONTROL) && !CONFIG_IS_ENABLED(OF_PLATDATA)
.post_bind = dm_scan_fdt_dev,
#endif
.post_probe = spi_post_probe,
--
2.17.1
[PATCH 2/5] configs: Add spiboot support for am335x
am335x internal SRAM is too small to support the addition of
SPI bootmode to the default defconfig. Add a separate spiboot_defconfig
Signed-off-by: Faiz Abbas
---
configs/am335x_evm_spiboot_defconfig | 93
1 file changed, 93 insertions(+)
create mode 100644 configs/am335x_evm_spiboot_defconfig
diff --git a/configs/am335x_evm_spiboot_defconfig
b/configs/am335x_evm_spiboot_defconfig
new file mode 100644
index 00..d71a7ce75c
--- /dev/null
+++ b/configs/am335x_evm_spiboot_defconfig
@@ -0,0 +1,93 @@
+CONFIG_ARM=y
+CONFIG_ARCH_CPU_INIT=y
+CONFIG_ARCH_OMAP2PLUS=y
+CONFIG_TI_COMMON_CMD_OPTIONS=y
+CONFIG_ENV_OFFSET=0x10
+CONFIG_SYS_SPI_U_BOOT_OFFS=0x2
+CONFIG_SPL_DM_SPI=y
+CONFIG_AM33XX=y
+# CONFIG_SPL_MMC_SUPPORT is not set
+CONFIG_SPL=y
+CONFIG_SPL_SPI_FLASH_SUPPORT=y
+CONFIG_SPL_SPI_SUPPORT=y
+CONFIG_DEFAULT_DEVICE_TREE="am335x-evm"
+CONFIG_DISTRO_DEFAULTS=y
+CONFIG_SPL_LOAD_FIT=y
+CONFIG_OF_BOARD_SETUP=y
+CONFIG_BOOTCOMMAND="if test ${boot_fit} -eq 1; then run update_to_fit; fi; run
findfdt; run init_console; run envboot; run distro_bootcmd"
+CONFIG_LOGLEVEL=3
+CONFIG_SYS_CONSOLE_INFO_QUIET=y
+CONFIG_VERSION_VARIABLE=y
+CONFIG_ARCH_MISC_INIT=y
+CONFIG_SPL_FIT_IMAGE_TINY=y
+# CONFIG_SPL_FS_EXT4 is not set
+CONFIG_SPL_MTD_SUPPORT=y
+# CONFIG_SPL_NAND_SUPPORT is not set
+CONFIG_SPL_DM_SPI_FLASH=y
+CONFIG_SPL_SPI_LOAD=y
+CONFIG_CMD_SPL=y
+# CONFIG_CMD_FLASH is not set
+CONFIG_CMD_NAND=y
+# CONFIG_CMD_SETEXPR is not set
+CONFIG_BOOTP_DNS2=y
+CONFIG_CMD_MTDPARTS=y
+# CONFIG_SPL_EFI_PARTITION is not set
+CONFIG_OF_CONTROL=y
+CONFIG_OF_LIST="am335x-evm am335x-bone am335x-boneblack am335x-evmsk
am335x-bonegreen am335x-icev2 am335x-pocketbeagle"
+CONFIG_ENV_OVERWRITE=y
+# CONFIG_ENV_IS_IN_FAT is not set
+CONFIG_ENV_IS_IN_SPI_FLASH=y
+CONFIG_SYS_RELOC_GD_ENV_ADDR=y
+CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y
+CONFIG_SPL_ENV_IS_NOWHERE=y
+CONFIG_BOOTP_SEND_HOSTNAME=y
+CONFIG_BOOTCOUNT_LIMIT=y
+CONFIG_CLK=y
+CONFIG_CLK_CDCE9XX=y
+CONFIG_DFU_TFTP=y
+CONFIG_DFU_MMC=y
+CONFIG_DFU_NAND=y
+CONFIG_DFU_RAM=y
+CONFIG_USB_FUNCTION_FASTBOOT=y
+CONFIG_FASTBOOT_FLASH=y
+CONFIG_FASTBOOT_FLASH_MMC_DEV=1
+CONFIG_FASTBOOT_CMD_OEM_FORMAT=y
+CONFIG_DM_I2C=y
+CONFIG_MISC=y
+CONFIG_DM_MMC=y
+# CONFIG_SPL_DM_MMC is not set
+# CONFIG_MMC_HW_PARTITIONING is not set
+CONFIG_MMC_OMAP_HS=y
+CONFIG_MTD=y
+CONFIG_MTD_RAW_NAND=y
+# CONFIG_SPL_NAND_AM33XX_BCH is not set
+CONFIG_DM_SPI_FLASH=y
+CONFIG_SF_DEFAULT_SPEED=2400
+CONFIG_SPI_FLASH_WINBOND=y
+CONFIG_PHY_ATHEROS=y
+CONFIG_PHY_SMSC=y
+CONFIG_DM_ETH=y
+CONFIG_MII=y
+CONFIG_DRIVER_TI_CPSW=y
+CONFIG_SPI=y
+CONFIG_DM_SPI=y
+CONFIG_OMAP3_SPI=y
+CONFIG_TIMER=y
+CONFIG_OMAP_TIMER=y
+CONFIG_USB=y
+CONFIG_DM_USB=y
+CONFIG_DM_USB_GADGET=y
+CONFIG_USB_MUSB_HOST=y
+CONFIG_USB_MUSB_GADGET=y
+CONFIG_USB_MUSB_TI=y
+CONFIG_USB_GADGET=y
+CONFIG_USB_GADGET_MANUFACTURER="Texas Instruments"
+CONFIG_USB_GADGET_VENDOR_NUM=0x0451
+CONFIG_USB_GADGET_PRODUCT_NUM=0xd022
+CONFIG_USB_ETHER=y
+CONFIG_WDT=y
+# CONFIG_SPL_WDT is not set
+CONFIG_DYNAMIC_CRC_TABLE=y
+CONFIG_RSA=y
+CONFIG_LZO=y
+# CONFIG_OF_LIBFDT_OVERLAY is not set
--
2.17.1
[PATCH 0/5] Add spi boot support to am335x-icev2
The following patches add spi boot support to TI's am335x-icev2 platform Faiz Abbas (5): arm: dts: am335x-icev2: Add spi node configs: Add spiboot support for am335x spi: spi-uclass: Block dm_scan_fdt_dev with OF_CONTROL to prevent build failures spi: omap3_spi: Read platform data in ofdata_to_platdata() arm: mach-omap2: am33xx: Add device structure for spi arch/arm/dts/am335x-icev2.dts| 50 + arch/arm/mach-omap2/am33xx/board.c | 12 +++ configs/am335x_evm_spiboot_defconfig | 93 +++ drivers/spi/omap3_spi.c | 107 +++ drivers/spi/spi-uclass.c | 2 +- include/configs/am335x_evm.h | 4 + include/omap3_spi.h | 78 +++ 7 files changed, 265 insertions(+), 81 deletions(-) create mode 100644 configs/am335x_evm_spiboot_defconfig create mode 100644 include/omap3_spi.h -- 2.17.1
[PATCH 1/5] arm: dts: am335x-icev2: Add spi node
Add spi and spi nor flash nodes for am335x-icev2.
Signed-off-by: Faiz Abbas
---
arch/arm/dts/am335x-icev2.dts | 50 +++
1 file changed, 50 insertions(+)
diff --git a/arch/arm/dts/am335x-icev2.dts b/arch/arm/dts/am335x-icev2.dts
index 37484cb6f5..2a1b3a53e9 100644
--- a/arch/arm/dts/am335x-icev2.dts
+++ b/arch/arm/dts/am335x-icev2.dts
@@ -436,3 +436,53 @@
reg = <3>;
};
};
+
+ {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins_default>;
+
+ sn65hvs882@1 {
+ compatible = "pisosr-gpio";
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ load-gpios = < 18 GPIO_ACTIVE_LOW>;
+
+ reg = <1>;
+ spi-max-frequency = <100>;
+ spi-cpol;
+ };
+
+ spi_nor: flash@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "winbond,w25q64", "jedec,spi-nor";
+ spi-max-frequency = <8000>;
+ m25p,fast-read;
+ reg = <0>;
+
+ partition@0 {
+ label = "u-boot-spl";
+ reg = <0x0 0x8>;
+ read-only;
+ };
+
+ partition@1 {
+ label = "u-boot";
+ reg = <0x8 0x10>;
+ read-only;
+ };
+
+ partition@2 {
+ label = "u-boot-env";
+ reg = <0x18 0x2>;
+ read-only;
+ };
+
+ partition@3 {
+ label = "misc";
+ reg = <0x1A 0x66>;
+ };
+ };
+};
--
2.17.1
[PATCH] arm64: Add support for bigger u-boot when CONFIG_POSITION_INDEPENDENT=y
From: "Edgar E. Iglesias" When U-Boot binary exceeds 1MB with CONFIG_POSITION_INDEPENDENT=y compilation error is shown: /mnt/disk/u-boot/arch/arm/cpu/armv8/start.S:71:(.text+0x3c): relocation truncated to fit: R_AARCH64_ADR_PREL_LO21 against symbol `__rel_dyn_end' defined in .bss_start section in u-boot. It is caused by adr instruction which permits the calculation of any byte address within +- 1MB of the current PC. Because U-Boot is bigger then 1MB calculation is failing. The patch is using adrp/add instructions where adrp shifts a signed, 21-bit immediate left by 12 bits (4k page), adds it to the value of the program counter with the bottom 12 bits cleared to zero. Then add instruction provides the lower 12 bits which is offset within 4k page. These two instructions together compose full 32bit offset which should be more then enough to cover the whole u-boot size. Signed-off-by: Edgar E. Iglesias Signed-off-by: Michal Simek --- arch/arm/cpu/armv8/start.S | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/arch/arm/cpu/armv8/start.S b/arch/arm/cpu/armv8/start.S index 002698b501c3..52cf1230c205 100644 --- a/arch/arm/cpu/armv8/start.S +++ b/arch/arm/cpu/armv8/start.S @@ -67,8 +67,10 @@ pie_fixup: adr x0, _start /* x0 <- Runtime value of _start */ ldr x1, _TEXT_BASE /* x1 <- Linked value of _start */ sub x9, x0, x1 /* x9 <- Run-vs-link offset */ - adr x2, __rel_dyn_start /* x2 <- Runtime &__rel_dyn_start */ - adr x3, __rel_dyn_end /* x3 <- Runtime &__rel_dyn_end */ + adrpx2, __rel_dyn_start /* x2 <- Runtime &__rel_dyn_start */ + add x2, x2, #:lo12:__rel_dyn_start + adrpx3, __rel_dyn_end /* x3 <- Runtime &__rel_dyn_end */ + add x3, x3, #:lo12:__rel_dyn_end pie_fix_loop: ldp x0, x1, [x2], #16 /* (x0, x1) <- (Link location, fixup) */ ldr x4, [x2], #8/* x4 <- addend */ -- 2.28.0
[PATCH] dfu: Fix handling of UBI partitions in MTD backend
For UBI partitions ("partubi" in dfu_alt_info), dfu_fill_entity_mtd sets
the mtd.ubi flag; however other functions incorrectly check for nand.ubi
instead. Fix this by checking for the correct flag.
Signed-off-by: Guillermo Rodriguez
Cc: Lukasz Majewski
---
drivers/dfu/dfu_mtd.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/dfu/dfu_mtd.c b/drivers/dfu/dfu_mtd.c
index 36cd4e945b..2811ae8463 100644
--- a/drivers/dfu/dfu_mtd.c
+++ b/drivers/dfu/dfu_mtd.c
@@ -190,7 +190,7 @@ static int dfu_flush_medium_mtd(struct dfu_entity *dfu)
int ret;
/* in case of ubi partition, erase rest of the partition */
- if (dfu->data.nand.ubi) {
+ if (dfu->data.mtd.ubi) {
struct erase_info erase_op = {};
erase_op.mtd = dfu->data.mtd.info;
@@ -228,7 +228,7 @@ static unsigned int dfu_polltimeout_mtd(struct dfu_entity
*dfu)
* ubi partition, as sectors which are not used need
* to be erased
*/
- if (dfu->data.nand.ubi)
+ if (dfu->data.mtd.ubi)
return DFU_MANIFEST_POLL_TIMEOUT;
return DFU_DEFAULT_POLL_TIMEOUT;
--
2.21.0
[PATCH v3 3/9] mips: octeon Add cvmx/cvmx-lmcx-defs.h header
From: Aaron Williams This header will be used by the DDR driver (lmc). Its ported from the 2013 Cavium / Marvell U-Boot repository. Signed-off-by: Aaron Williams Signed-off-by: Stefan Roese --- Changes in v3: - Remove "https://spdx.org/licenses; line Changes in v2: - Some unsupported Octeon families removed (only Octeon 2 & 3 supported in general) .../include/mach/cvmx/cvmx-lmcx-defs.h| 4574 + 1 file changed, 4574 insertions(+) create mode 100644 arch/mips/mach-octeon/include/mach/cvmx/cvmx-lmcx-defs.h diff --git a/arch/mips/mach-octeon/include/mach/cvmx/cvmx-lmcx-defs.h b/arch/mips/mach-octeon/include/mach/cvmx/cvmx-lmcx-defs.h new file mode 100644 index 00..3b4cba9241 --- /dev/null +++ b/arch/mips/mach-octeon/include/mach/cvmx/cvmx-lmcx-defs.h @@ -0,0 +1,4574 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +/* + * Copyright (C) 2020 Marvell International Ltd. + */ + +#ifndef __CVMX_LMCX_DEFS_H__ +#define __CVMX_LMCX_DEFS_H__ + +#define CVMX_LMCX_BANK_CONFLICT1(offs) \ + ((0x000360ull) + ((offs) & 3) * 0x100ull) +#define CVMX_LMCX_BANK_CONFLICT2(offs) \ + ((0x000368ull) + ((offs) & 3) * 0x100ull) +#define CVMX_LMCX_BIST_RESULT(offs)\ + ((0xF8ull) + ((offs) & 1) * 0x6000ull) +#define CVMX_LMCX_CHAR_CTL(offs) \ + ((0x000220ull) + ((offs) & 3) * 0x100ull) +#define CVMX_LMCX_CHAR_DQ_ERR_COUNT(offs) \ + ((0x40ull) + ((offs) & 3) * 0x100ull) +#define CVMX_LMCX_CHAR_MASK0(offs) \ + ((0x000228ull) + ((offs) & 3) * 0x100ull) +#define CVMX_LMCX_CHAR_MASK1(offs) \ + ((0x000230ull) + ((offs) & 3) * 0x100ull) +#define CVMX_LMCX_CHAR_MASK2(offs) \ + ((0x000238ull) + ((offs) & 3) * 0x100ull) +#define CVMX_LMCX_CHAR_MASK3(offs) \ + ((0x000240ull) + ((offs) & 3) * 0x100ull) +#define CVMX_LMCX_CHAR_MASK4(offs) \ + ((0x000318ull) + ((offs) & 3) * 0x100ull) +#define CVMX_LMCX_COMP_CTL(offs) \ + ((0x28ull) + ((offs) & 1) * 0x6000ull) +#define CVMX_LMCX_COMP_CTL2(offs) \ + ((0x0001B8ull) + ((offs) & 3) * 0x100ull) +#define CVMX_LMCX_CONFIG(offs) \ + ((0x000188ull) + ((offs) & 3) * 0x100ull) +#define CVMX_LMCX_CONTROL(offs)\ + ((0x000190ull) + ((offs) & 3) * 0x100ull) +#define CVMX_LMCX_CTL(offs)\ + ((0x10ull) + ((offs) & 1) * 0x6000ull) +#define CVMX_LMCX_CTL1(offs) \ + ((0x90ull) + ((offs) & 1) * 0x6000ull) +#define CVMX_LMCX_DBTRAIN_CTL(offs)\ + ((0x0003F8ull) + ((offs) & 3) * 0x100ull) +#define CVMX_LMCX_DCLK_CNT(offs) \ + ((0x0001E0ull) + ((offs) & 3) * 0x100ull) +#define CVMX_LMCX_DCLK_CNT_HI(offs)\ + ((0x70ull) + ((offs) & 1) * 0x6000ull) +#define CVMX_LMCX_DCLK_CNT_LO(offs)\ + ((0x68ull) + ((offs) & 1) * 0x6000ull) +#define CVMX_LMCX_DCLK_CTL(offs) \ + ((0xB8ull) + ((offs) & 1) * 0x6000ull) +#define CVMX_LMCX_DDR2_CTL(offs) \ + ((0x18ull) + ((offs) & 1) * 0x6000ull) +#define CVMX_LMCX_DDR4_DIMM_CTL(offs) \ + ((0x0003F0ull) + ((offs) & 3) * 0x100ull) +#define CVMX_LMCX_DDR_PLL_CTL(offs)\ + ((0x000258ull) + ((offs) & 3) * 0x100ull) +#define CVMX_LMCX_DELAY_CFG(offs) \ + ((0x88ull) + ((offs) & 1) * 0x6000ull) +#define CVMX_LMCX_DIMMX_DDR4_PARAMS0(offs, id) \ + ((0xD0ull) + (((offs) & 1) + ((id) & 3) * 0x20ull) * 8) +#define CVMX_LMCX_DIMMX_DDR4_PARAMS1(offs, id) \ + ((0x000140ull) + (((offs) & 1) + ((id) & 3) * 0x20ull) * 8) +#define CVMX_LMCX_DIMMX_PARAMS(offs, id) \ + ((0x000270ull) + (((offs) & 1) + ((id) & 3) * 0x20ull) * 8) +#define CVMX_LMCX_DIMM_CTL(offs) \ + ((0x000310ull) + ((offs) & 3) * 0x100ull) +#define CVMX_LMCX_DLL_CTL(offs)\ + ((0xC0ull) + ((offs) & 1) * 0x6000ull) +#define CVMX_LMCX_DLL_CTL2(offs) \ + ((0x0001C8ull) + ((offs) & 3) * 0x100ull) +#define CVMX_LMCX_DLL_CTL3(offs) \ + ((0x000218ull) + ((offs) & 3) * 0x100ull) +#define CVMX_LMCX_ECC_PARITY_TEST(offs)\ + ((0x000108ull) + ((offs) & 3) * 0x100ull) +#define CVMX_LMCX_EXT_CONFIG(offs) \ + ((0x30ull) + ((offs) & 3) * 0x100ull) +#define CVMX_LMCX_EXT_CONFIG2(offs)\ +
Re: [RESEND PATCH v2 01/11] usb: xhci: add a member hci_version in xhci_ctrl struct
On 9/2/20 8:13 AM, Frank Wunderlich wrote:
> From: Chunfeng Yun
>
> Add a member to save xHCI version, it's used some times.
>
> Signed-off-by: Chunfeng Yun
> ---
> drivers/usb/host/xhci-ring.c | 4 ++--
> drivers/usb/host/xhci.c | 1 +
> include/usb/xhci.h | 1 +
> 3 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
> index 092ed6eaf1..79bfc349f4 100644
> --- a/drivers/usb/host/xhci-ring.c
> +++ b/drivers/usb/host/xhci-ring.c
> @@ -682,7 +682,7 @@ int xhci_bulk_tx(struct usb_device *udev, unsigned long
> pipe,
> field |= TRB_ISP;
>
> /* Set the TRB length, TD size, and interrupter fields. */
> - if (HC_VERSION(xhci_readl(>hccr->cr_capbase)) < 0x100)
> + if (ctrl->hci_version < 0x100)
> remainder = xhci_td_remainder(length - running_total);
> else
> remainder = xhci_v1_0_td_remainder(running_total,
> @@ -830,7 +830,7 @@ int xhci_ctrl_tx(struct usb_device *udev, unsigned long
> pipe,
> field |= 0x1;
>
> /* xHCI 1.0 6.4.1.2.1: Transfer Type field */
> - if (HC_VERSION(xhci_readl(>hccr->cr_capbase)) >= 0x100) {
> + if (ctrl->hci_version >= 0x100) {
> if (length > 0) {
> if (req->requesttype & USB_DIR_IN)
> field |= (TRB_DATA_IN << TRB_TX_TYPE_SHIFT);
> diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
> index 126dabc11b..4be1411243 100644
> --- a/drivers/usb/host/xhci.c
> +++ b/drivers/usb/host/xhci.c
> @@ -1283,6 +1283,7 @@ static int xhci_lowlevel_init(struct xhci_ctrl *ctrl)
>
> reg = HC_VERSION(xhci_readl(>cr_capbase));
> printf("USB XHCI %x.%02x\n", reg >> 8, reg & 0xff);
> + ctrl->hci_version = reg;
>
> return 0;
> }
> diff --git a/include/usb/xhci.h b/include/usb/xhci.h
> index 7d34103fd5..a3e5914b10 100644
> --- a/include/usb/xhci.h
> +++ b/include/usb/xhci.h
> @@ -1227,6 +1227,7 @@ struct xhci_ctrl {
> struct xhci_scratchpad *scratchpad;
> struct xhci_virt_device *devs[MAX_HC_SLOTS];
> int rootdev;
> + u16 hci_version;
> };
>
> unsigned long trb_addr(struct xhci_segment *seg, union xhci_trb *trb);
>
+CC Bin
Re: [PATCH v3 00/12] binman: Add support for generating more complex FITs
Hi Simon,
On 01. 09. 20 13:13, Simon Glass wrote:
> This series allows binman to generate FITs that include multiple DTB
> images and the configuration to use them.
>
> It is then possible to remove the sunxi FIT generator script, so this
> series handles that also.
>
> With this, sunxi is fully converted to use binman.
>
> Note: This series is available at u-boot-dm/binman-working and is based
> on u-boot-dm/testing
I continue on testing this series on ZynqMP and reach one issue. One of
our usecase is to put u-boot on memory above 32bit address space.
To be accurate to this memory range.
reg = <0x8 0x 0x0 0x8000>;
One way to get there is to setup TEXT_BASE to for example 0x80800.
Then u-boot.itb fragment for binmap looks like this.
u-boot-itb {
filename = "u-boot.itb";
fit {
description = "FIT image with ATF support";
fit,fdt-list = "of-list";
#address-cells = <2>;
images {
uboot {
description = "U-Boot (64-bit)";
type = "firmware";
os = "u-boot";
arch = "arm64";
compression = "none";
load = <8 0x800>;
entry = <8 0x800>;
u-boot-nodtb {
};
};
...
The key properties are load/entry. In example above I have address-cells
= 2 and entries written by hand and it works fine.
But I want to use CONFIG_SYS_TEXT_BASE there which is already in 64bit
format.
When this is used I get
Error: arch/arm/dts/zynqmp-u-boot.dtsi:31.14-25 Value out of range for
32-bit array element
Error: arch/arm/dts/zynqmp-u-boot.dtsi:32.15-26 Value out of range for
32-bit array element
Which is understandable but my question is how to handle 64bit addresses
which are properly filled via Kconfig?
I have the same issue with one more DT property.
Thanks,
Michal
RE: [PATCH 1/2] armv8: lx2162a: Add Soc changes to support LX2162A
> -Original Message-
> From: Priyanka Jain
> Sent: Wednesday, September 2, 2020 12:49 PM
> To: Meenakshi Aggarwal ; u-
> b...@lists.denx.de
> Cc: Varun Sethi
> Subject: RE: [PATCH 1/2] armv8: lx2162a: Add Soc changes to support
> LX2162A
>
>
>
> >-Original Message-
> >From: Meenakshi Aggarwal
> >Sent: Tuesday, September 1, 2020 3:03 PM
> >To: u-boot@lists.denx.de; Priyanka Jain
> >Cc: Varun Sethi ; Meenakshi Aggarwal
> >
> >Subject: [PATCH 1/2] armv8: lx2162a: Add Soc changes to support LX2162A
> >
> >From: Meenakshi Aggarwal
> >
> >LX2162 is LX2160 based SoC, it has same die as of LX2160 with different
> >packaging.
> >LX2162A support 4GB ddr memory, i2c, micro-click module, microSD card,
> >serial console, qspi nor flash, qsgmii, sgmii, 25g, 40g, 50g network
> >interface,one usb 3.0 and serdes interface to support three x1 gen3
> >pcie interface.
> Are these Soc features or board features, please check. Similar description is
> used for both Soc and board patch
> >
> >Signed-off-by: Meenakshi Aggarwal
> >---
> > arch/arm/cpu/armv8/Kconfig | 2 +-
> > arch/arm/cpu/armv8/fsl-layerscape/cpu.c| 5 -
> > arch/arm/cpu/armv8/fsl-layerscape/lx2160a_serdes.c | 19
> >++-
> > arch/arm/include/asm/arch-fsl-layerscape/soc.h | 5 -
> > drivers/pci/pcie_layerscape_ep.c | 4 +++-
> > drivers/pci/pcie_layerscape_fixup_common.c | 5 -
> > 6 files changed, 34 insertions(+), 6 deletions(-)
> >
> >diff --git a/arch/arm/cpu/armv8/Kconfig b/arch/arm/cpu/armv8/Kconfig
> >index 3655990..f247441 100644
> >--- a/arch/arm/cpu/armv8/Kconfig
> >+++ b/arch/arm/cpu/armv8/Kconfig
> >@@ -115,7 +115,7 @@ config PSCI_RESET
> >!TARGET_LS1046ARDB && !TARGET_LS1046AQDS && \
> >!TARGET_LS1046AFRWY && \
> >!TARGET_LS2081ARDB && !TARGET_LX2160ARDB && \
> >- !TARGET_LX2160AQDS && \
> >+ !TARGET_LX2160AQDS && !TARGET_LX2162AQDS && \
> >!ARCH_UNIPHIER && !TARGET_S32V234EVB
> > help
> > Most armv8 systems have PSCI support enabled in EL3, either
> through
> >diff --git a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
> >b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
> >index 8a2f404..4fb222a 100644
> >--- a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
> >+++ b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
> >@@ -1,6 +1,6 @@
> > // SPDX-License-Identifier: GPL-2.0+
> > /*
> >- * Copyright 2017-2019 NXP
> >+ * Copyright 2017-2020 NXP
> > * Copyright 2014-2015 Freescale Semiconductor, Inc.
> > */
> >
> >@@ -79,6 +79,9 @@ static struct cpu_type cpu_type_list[] = {
> > CPU_TYPE_ENTRY(LX2160A, LX2160A, 16),
> > CPU_TYPE_ENTRY(LX2120A, LX2120A, 12),
> > CPU_TYPE_ENTRY(LX2080A, LX2080A, 8),
> >+CPU_TYPE_ENTRY(LX2162A, LX2162A, 16),
> >+CPU_TYPE_ENTRY(LX2122A, LX2122A, 12),
> >+CPU_TYPE_ENTRY(LX2082A, LX2082A, 8),
> > };
> >
> > #define EARLY_PGTABLE_SIZE 0x5000
> >diff --git a/arch/arm/cpu/armv8/fsl-layerscape/lx2160a_serdes.c
> >b/arch/arm/cpu/armv8/fsl-layerscape/lx2160a_serdes.c
> >index a04a370..b4dea80 100644
> >--- a/arch/arm/cpu/armv8/fsl-layerscape/lx2160a_serdes.c
> >+++ b/arch/arm/cpu/armv8/fsl-layerscape/lx2160a_serdes.c
> >@@ -1,6 +1,6 @@
> > // SPDX-License-Identifier: GPL-2.0+
> > /*
> >- * Copyright 2018 NXP
> >+ * Copyright 2018, 2020 NXP
> > */
> >
> > #include
> >@@ -11,6 +11,22 @@ struct serdes_config {
> > u8 lanes[SRDS_MAX_LANES];
> > };
> >
> >+#ifdef CONFIG_TARGET_LX2162AQDS
> Board change
These are SoC changes but as LX2162 is LX2160 bases so I didn't define a
separate config for LX2162A,
Rather used CONFIG_TARGET_LX2162AQDS.
Suggest if I should define one for LX2162A SOC?
> >+static struct serdes_config serdes1_cfg_tbl[] = {
> >+/* SerDes 1 */
> >+{0x01, {PCIE1, PCIE1, PCIE1, PCIE1 } },
> >+{0x02, {SGMII6, SGMII5, SGMII4, SGMII3 } },
> >+{0x03, {XFI6, XFI5, XFI4, XFI3 } },
> >+{0x09, {SGMII6, SGMII5, SGMII4, PCIE1 } },
> >+{0x0B, {SGMII6, SGMII5, PCIE1, PCIE1 } },
> >+{0x0F, {_50GE2, _50GE2, _50GE1, _50GE1 } },
> >+{0x10, {_25GE6, _25GE5, _50GE1, _50GE1 } },
> >+{0x11, {_25GE6, _25GE5, _25GE4, _25GE3 } },
> >+{0x12, {_25GE6, _25GE5, XFI4, XFI3 } },
> >+{0x14, {_40GE1, _40GE1, _40GE1, _40GE1 } },
> >+{}
> >+};
> >+#else
> > static struct serdes_config serdes1_cfg_tbl[] = {
> > /* SerDes 1 */
> > {0x01, {PCIE2, PCIE2, PCIE2, PCIE2, PCIE1, PCIE1, PCIE1, PCIE1 } },
> >@@ -
> >48,6 +64,7 @@ static struct serdes_config serdes1_cfg_tbl[] = {
> > {0x16, {XFI10, XFI9, PCIE2, PCIE2, XFI6, XFI5, XFI4, XFI3 } },
> > {}
> > };
> >+#endif
> >
> > static struct serdes_config serdes2_cfg_tbl[] = {
> > /* SerDes 2 */
> >diff --git a/arch/arm/include/asm/arch-fsl-layerscape/soc.h
> >b/arch/arm/include/asm/arch-fsl-layerscape/soc.h
> >index 020548a..cbca43f 100644
> >--- a/arch/arm/include/asm/arch-fsl-layerscape/soc.h
> >+++
RE: Missing BMP 565RGB video support
Anatolij, > Did you define CONFIG_BMP_24BPP in your board config file? Yes. Without this define the command "bmp display " does not do anything if the given BMP is a 24BPP BMP. With this define the a 24 BPP BMP I displayed but with wrong colors because the framebuffer of my (i.MX6) board expects 56RGB encoded colors. The issue is that the video_priv struct does not have sufficient information to describe all the properties of the associated framebuffer. Current it only knows the BPP (defined by the field bpix) but not the required encoding. This could be fixe to the video_fb.h "gdfIndex" rather than the video.h "bpix" in the video_priv struct. Kees. -Original Message- From: Anatolij Gustschin [mailto:ag...@denx.de] Sent: 01 September 2020 13:08 To: Trommel, Kees (Contractor) Cc: u-boot@lists.denx.de Subject: Re: Missing BMP 565RGB video support Hi, On Fri, 28 Aug 2020 10:44:55 + Trommel, Kees (Contractor) kees.trommel.contrac...@draeger.com wrote: > Hi Agust, > > The latest version of the U-Boot does not support conversion from > 24BPP BMP to a 16BPP 565RGB encoded frame buffer. It uses always > 555RGB encoding (see function video_bmp_display in video_bmp.c). > Older versions of the U-Boot (e.g. 2015.04) supported this because the > platform specific device driver passed not only the BPP but also the > encoding. in recent U-Boot we do not use old cfb_console driver which supported 24bpp bitmaps. The DM video console driver still dosn't support some framebuffer/bitmap BPP combinations, or maybe your board config file does not define CONFIG_BMP_24BPP. > Do you know whether this lost support was done on purpose or lost by > accident? This is probably due to DM video conversion, not all BPP variants have been implemented with this yet. > I encountered this issue when trying to display a 24BPP BMP splash > screen at an i.MX6 platform. Did you define CONFIG_BMP_24BPP in your board config file? If not, could you do so and test the result? Thanks. -- Anatolij --- This communication contains confidential information. If you are not the intended recipient please return this email to the sender and delete it from your records. Diese Nachricht enthaelt vertrauliche Informationen. Sollten Sie nicht der beabsichtigte Empfaenger dieser E-mail sein, senden Sie bitte diese an den Absender zurueck und loeschen Sie die E-mail aus Ihrem System.
Re: [RFC PATCH 0/1] Anti rollback protection for FIT Images
On 01/09/2020 22.48, Thirupathaiah Annapureddy wrote:
> Anti rollback protection is required when there is a need to retire
> previous versions of FIT images due to security flaws in them.
> Currently U-Boot Verified boot does not have rollback protection to
> protect against known security flaws.
This is definitely something we've had on our todo-list/wishlist. But we
haven't had the time to sit down and work out the semantics and
implementation, so thanks for doing this.
I think most of this cover letter should be in the commit log instead.
> This RFC introduces a proposal to add anti-rollback protection for
> FIT images. This protection feature prevents U-Boot from accepting
> an image if it has ever successfully loaded an image with a larger
> anti-rollback version number.
>
> Each sub-image node inside /images node has an
> anti-rollback version number(arbvn) similar to rollback_index in
> Android Verified Boot. This version number is part of signed data and
> it is incremented as security flaws are discovered and fixed.
> U-Boot stores the last seen arbvn for a given image type in platform
> specific tamper-evident storage.
Hmm. What is the purpose of per-image-type version numbers? That seems
to be wrong. For example, we use the the "loadables" property in the
U-Boot FIT to get the SPL to load some firmware blob to a known memory
address where U-Boot proper then knows it to be. If we happened to have
two such blobs for different pieces of hardware, they'd have the same
"type" in the FIT image, but that doesn't mean they should follow the
same versioning.
The way I imagined rollback protection to work (but I really haven't
given this too much thought) was to have an extra property in the
configuration:
configurations {
default = "conf-1";
conf-1 {
description = "...";
kernel = "kernel-1";
fdt = "fdt-1";
ramdisk = "ramdisk-1";
arvbn = "arvbn"; /* <-- */
hash-1 {
algo = "sha1";
};
signature-foo {
algo = "sha1,rsa2048";
sign-images = "kernel", "fdt", "ramdisk",
"arvbn";
key-name-hint = "foo";
};
};
};
with arvbn simply being a small extra "image" node
arvbn {
description = "BSP version";
data = <0x02 0x03 0x01>;
}
(which should of course not be loaded to memory). This requires use of
signed configurations rather than individually signed images, but that's
anyway required for proper security.
The board callbacks would simply be given a pointer to the data part of
that node; that would make the versioning scheme rather flexible instead
of being limited to a single monotonically increasing u32 (hence also
the comparison logic should be in the board callbacks, instead of a
"get/set" interface). For example, one could have a version composed as
$major.$minor;$security, the board logic could prevent both downgrading
to another major version and another security version. I.e., suppose
we've had several BSP releases (in chronological order):
1.0;0
1.1;0
2.0;0
1.2;0
2.1;0
1.3;1
2.2;1
2.3;1
1.4;1
2.4;2
1.5;2
With this, a user on 1.3 cannot update to 2.0; he must go at least to
2.2, or he would expose himself to a flaw that had already been fixed.
On the other hand, there should be nothing wrong with downgrading from
1.2 to 1.0. A user on 2.0 must not downgrade to 1.x because the old
major version cannot read the data written by the 2.0 application.
This sort of thing is hard to implement with just a single rollback
number: At the time 2.0 is released, what rollback number should it get?
If we give it 10, we can only produce fixes for nine security bugs in
the 1.x series before that series ends up with a rollback version larger
than the 2.0 one, after which a user on 2.0 would wrongly be able to
downgrade to 1.12.
tl;dr: I'd like this to not only be about rollback protection for
security bugs, but also be able to set other policies for rollback. And
therefore I'd also like it simply to be known as "version" instead of
the somewhat odd arvbn acronym. Nothing prevents the board developer
from just putting a single u32 in the version field and use that as a
single monotonically increasing version.
> As part of signature verification, U-Boot enfroces arvbn based
> protection if enabled. arvbn stored in secure storage is validated with
> arbvn in the sub-image node. If the counter in the FIT image is lower than
> the counter in platform secure storage, image validation has failed
> i.e. verified boot failed. If both counters match or the image counter is
> higher than that in the platform secure storage, the image
RE: [PATCH 2/2] armv8: lx2162aqds: Add support for LX2162AQDS platform
>-Original Message-
>From: Meenakshi Aggarwal
>Sent: Tuesday, September 1, 2020 3:03 PM
>To: u-boot@lists.denx.de; Priyanka Jain
>Cc: Varun Sethi ; Meenakshi Aggarwal
>; Ioana Ciornei ;
>Qiang Zhao ; Hui Song ;
>Manish Tomar ; Vikas Singh
>
>Subject: [PATCH 2/2] armv8: lx2162aqds: Add support for LX2162AQDS
>platform
>
>From: Meenakshi Aggarwal
>
>This patch add base support for LX2162AQDS board.
>LX2162 is LX2160 based SoC, it has same die as of LX2160
>with different packaging.
No need to mention soc details. May be just mention that LX2162AQDS uses LX2162
SoC
>LX2162A support 4GB ddr memory, i2c, micro-click module, microSD card,
>serial console, qspi nor flash, qsgmii, sgmii, 25g, 40g, 50g network
>interface,one usb 3.0 and serdes interface to support three x1gen3
>pcie interface.
>
Please check if board feature or soc feature
>Signed-off-by: Ioana Ciornei
>Signed-off-by: Zhao Qiang
>Signed-off-by: hui.song
>Signed-off-by: Manish Tomar
>Signed-off-by: Vikas Singh
>Signed-off-by: Meenakshi Aggarwal
>---
> arch/arm/Kconfig | 12 +
> arch/arm/dts/Makefile | 6 +-
> arch/arm/dts/fsl-lx2160a-qds.dtsi | 16 +-
> arch/arm/dts/fsl-lx2162a-qds-17-x.dts | 17 +
> arch/arm/dts/fsl-lx2162a-qds-18-x.dts | 17 +
> arch/arm/dts/fsl-lx2162a-qds-20-x.dts | 17 +
> arch/arm/dts/fsl-lx2162a-qds-sd1-17.dtsi | 58 ++
> arch/arm/dts/fsl-lx2162a-qds-sd1-18.dtsi | 61 ++
> arch/arm/dts/fsl-lx2162a-qds-sd1-20.dtsi | 26 +
> arch/arm/dts/fsl-lx2162a-qds.dts | 36 +
> board/freescale/lx2160a/Kconfig| 16 +
> board/freescale/lx2160a/MAINTAINERS| 12 +-
> board/freescale/lx2160a/Makefile | 1 +
> board/freescale/lx2160a/eth_lx2162aqds.c | 974
>+
> board/freescale/lx2160a/lx2160a.c | 42 +-
> configs/lx2162aqds_tfa_SECURE_BOOT_defconfig | 97 +++
> configs/lx2162aqds_tfa_defconfig | 95 +++
> configs/lx2162aqds_tfa_verified_boot_defconfig | 102 +++
> include/configs/lx2160a_common.h | 2 +
> include/configs/lx2162aqds.h | 169 +
> 20 files changed, 1753 insertions(+), 23 deletions(-)
> create mode 100644 arch/arm/dts/fsl-lx2162a-qds-17-x.dts
> create mode 100644 arch/arm/dts/fsl-lx2162a-qds-18-x.dts
> create mode 100644 arch/arm/dts/fsl-lx2162a-qds-20-x.dts
> create mode 100644 arch/arm/dts/fsl-lx2162a-qds-sd1-17.dtsi
> create mode 100644 arch/arm/dts/fsl-lx2162a-qds-sd1-18.dtsi
> create mode 100644 arch/arm/dts/fsl-lx2162a-qds-sd1-20.dtsi
> create mode 100644 arch/arm/dts/fsl-lx2162a-qds.dts
> create mode 100644 board/freescale/lx2160a/eth_lx2162aqds.c
> create mode 100644 configs/lx2162aqds_tfa_SECURE_BOOT_defconfig
> create mode 100644 configs/lx2162aqds_tfa_defconfig
> create mode 100644 configs/lx2162aqds_tfa_verified_boot_defconfig
> create mode 100644 include/configs/lx2162aqds.h
>
>diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
>index 80702c2..4bcbcc5 100644
>--- a/arch/arm/Kconfig
>+++ b/arch/arm/Kconfig
>@@ -1321,6 +1321,18 @@ config TARGET_LX2160AQDS
> is a high-performance development platform that supports the
> QorIQ LX2160A/LX2120A/LX2080A Layerscape Architecture processor.
>
>+config TARGET_LX2162AQDS
>+ bool "Support lx2162aqds"
>+ select ARCH_LX2160A
>+ select ARCH_MISC_INIT
>+ select ARM64
>+ select ARMV8_MULTIENTRY
>+ select ARCH_SUPPORT_TFABOOT
>+ select BOARD_LATE_INIT
>+ help
>+Support for NXP LX2162AQDS platform.
>+The lx2162aqds support is based on LX2160A Layerscape Architecture
>processor.
>+
> config TARGET_HIKEY
> bool "Support HiKey 96boards Consumer Edition Platform"
> select ARM64
>diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
>index f8f5294..a34a56e 100644
>--- a/arch/arm/dts/Makefile
>+++ b/arch/arm/dts/Makefile
>@@ -409,7 +409,11 @@ dtb-$(CONFIG_FSL_LSCH3) += fsl-ls2080a-qds.dtb \
> fsl-lx2160a-qds-19-x-x.dtb \
> fsl-lx2160a-qds-19-11-x.dtb \
> fsl-lx2160a-qds-20-x-x.dtb \
>- fsl-lx2160a-qds-20-11-x.dtb
>+ fsl-lx2160a-qds-20-11-x.dtb \
>+ fsl-lx2162a-qds.dtb\
>+ fsl-lx2162a-qds-17-x.dtb\
>+ fsl-lx2162a-qds-18-x.dtb\
>+ fsl-lx2162a-qds-20-x.dtb
> dtb-$(CONFIG_FSL_LSCH2) += fsl-ls1043a-qds-duart.dtb \
> fsl-ls1043a-qds-lpuart.dtb \
> fsl-ls1043a-rdb.dtb \
>diff --git a/arch/arm/dts/fsl-lx2160a-qds.dtsi b/arch/arm/dts/fsl-lx2160a-
>qds.dtsi
>index 96c9800..370f116 100644
>--- a/arch/arm/dts/fsl-lx2160a-qds.dtsi
>+++ b/arch/arm/dts/fsl-lx2160a-qds.dtsi
>@@ -2,7 +2,7 @@
> /*
> * NXP LX2160AQDS common device tree source
> *
>- * Copyright 2018-2019 NXP
>+ * Copyright 2018-2020 NXP
> *
> */
>
>@@ -251,6 +251,20 @@
> };
> };
>
>+ {
>+ status = "okay";
>+
>+ mt35xu512aba0: flash@0 {
>+ #address-cells = <1>;
>+ #size-cells =
RE: [PATCH 1/2] armv8: lx2162a: Add Soc changes to support LX2162A
>-Original Message-
>From: Meenakshi Aggarwal
>Sent: Tuesday, September 1, 2020 3:03 PM
>To: u-boot@lists.denx.de; Priyanka Jain
>Cc: Varun Sethi ; Meenakshi Aggarwal
>
>Subject: [PATCH 1/2] armv8: lx2162a: Add Soc changes to support LX2162A
>
>From: Meenakshi Aggarwal
>
>LX2162 is LX2160 based SoC, it has same die as of LX2160 with different
>packaging.
>LX2162A support 4GB ddr memory, i2c, micro-click module, microSD card,
>serial console, qspi nor flash, qsgmii, sgmii, 25g, 40g, 50g network
>interface,one usb 3.0 and serdes interface to support three x1 gen3 pcie
>interface.
Are these Soc features or board features, please check. Similar description is
used for both Soc and board patch
>
>Signed-off-by: Meenakshi Aggarwal
>---
> arch/arm/cpu/armv8/Kconfig | 2 +-
> arch/arm/cpu/armv8/fsl-layerscape/cpu.c| 5 -
> arch/arm/cpu/armv8/fsl-layerscape/lx2160a_serdes.c | 19
>++-
> arch/arm/include/asm/arch-fsl-layerscape/soc.h | 5 -
> drivers/pci/pcie_layerscape_ep.c | 4 +++-
> drivers/pci/pcie_layerscape_fixup_common.c | 5 -
> 6 files changed, 34 insertions(+), 6 deletions(-)
>
>diff --git a/arch/arm/cpu/armv8/Kconfig b/arch/arm/cpu/armv8/Kconfig
>index 3655990..f247441 100644
>--- a/arch/arm/cpu/armv8/Kconfig
>+++ b/arch/arm/cpu/armv8/Kconfig
>@@ -115,7 +115,7 @@ config PSCI_RESET
> !TARGET_LS1046ARDB && !TARGET_LS1046AQDS && \
> !TARGET_LS1046AFRWY && \
> !TARGET_LS2081ARDB && !TARGET_LX2160ARDB && \
>- !TARGET_LX2160AQDS && \
>+ !TARGET_LX2160AQDS && !TARGET_LX2162AQDS && \
> !ARCH_UNIPHIER && !TARGET_S32V234EVB
> help
> Most armv8 systems have PSCI support enabled in EL3, either
>through diff --git a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
>b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
>index 8a2f404..4fb222a 100644
>--- a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
>+++ b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
>@@ -1,6 +1,6 @@
> // SPDX-License-Identifier: GPL-2.0+
> /*
>- * Copyright 2017-2019 NXP
>+ * Copyright 2017-2020 NXP
> * Copyright 2014-2015 Freescale Semiconductor, Inc.
> */
>
>@@ -79,6 +79,9 @@ static struct cpu_type cpu_type_list[] = {
> CPU_TYPE_ENTRY(LX2160A, LX2160A, 16),
> CPU_TYPE_ENTRY(LX2120A, LX2120A, 12),
> CPU_TYPE_ENTRY(LX2080A, LX2080A, 8),
>+ CPU_TYPE_ENTRY(LX2162A, LX2162A, 16),
>+ CPU_TYPE_ENTRY(LX2122A, LX2122A, 12),
>+ CPU_TYPE_ENTRY(LX2082A, LX2082A, 8),
> };
>
> #define EARLY_PGTABLE_SIZE 0x5000
>diff --git a/arch/arm/cpu/armv8/fsl-layerscape/lx2160a_serdes.c
>b/arch/arm/cpu/armv8/fsl-layerscape/lx2160a_serdes.c
>index a04a370..b4dea80 100644
>--- a/arch/arm/cpu/armv8/fsl-layerscape/lx2160a_serdes.c
>+++ b/arch/arm/cpu/armv8/fsl-layerscape/lx2160a_serdes.c
>@@ -1,6 +1,6 @@
> // SPDX-License-Identifier: GPL-2.0+
> /*
>- * Copyright 2018 NXP
>+ * Copyright 2018, 2020 NXP
> */
>
> #include
>@@ -11,6 +11,22 @@ struct serdes_config {
> u8 lanes[SRDS_MAX_LANES];
> };
>
>+#ifdef CONFIG_TARGET_LX2162AQDS
Board change
>+static struct serdes_config serdes1_cfg_tbl[] = {
>+ /* SerDes 1 */
>+ {0x01, {PCIE1, PCIE1, PCIE1, PCIE1 } },
>+ {0x02, {SGMII6, SGMII5, SGMII4, SGMII3 } },
>+ {0x03, {XFI6, XFI5, XFI4, XFI3 } },
>+ {0x09, {SGMII6, SGMII5, SGMII4, PCIE1 } },
>+ {0x0B, {SGMII6, SGMII5, PCIE1, PCIE1 } },
>+ {0x0F, {_50GE2, _50GE2, _50GE1, _50GE1 } },
>+ {0x10, {_25GE6, _25GE5, _50GE1, _50GE1 } },
>+ {0x11, {_25GE6, _25GE5, _25GE4, _25GE3 } },
>+ {0x12, {_25GE6, _25GE5, XFI4, XFI3 } },
>+ {0x14, {_40GE1, _40GE1, _40GE1, _40GE1 } },
>+ {}
>+};
>+#else
> static struct serdes_config serdes1_cfg_tbl[] = {
> /* SerDes 1 */
> {0x01, {PCIE2, PCIE2, PCIE2, PCIE2, PCIE1, PCIE1, PCIE1, PCIE1 } }, @@ -
>48,6 +64,7 @@ static struct serdes_config serdes1_cfg_tbl[] = {
> {0x16, {XFI10, XFI9, PCIE2, PCIE2, XFI6, XFI5, XFI4, XFI3 } },
> {}
> };
>+#endif
>
> static struct serdes_config serdes2_cfg_tbl[] = {
> /* SerDes 2 */
>diff --git a/arch/arm/include/asm/arch-fsl-layerscape/soc.h
>b/arch/arm/include/asm/arch-fsl-layerscape/soc.h
>index 020548a..cbca43f 100644
>--- a/arch/arm/include/asm/arch-fsl-layerscape/soc.h
>+++ b/arch/arm/include/asm/arch-fsl-layerscape/soc.h
>@@ -1,6 +1,6 @@
> /* SPDX-License-Identifier: GPL-2.0+ */
> /*
>- * Copyright 2017-2019 NXP
>+ * Copyright 2017-2020 NXP
> * Copyright 2015 Freescale Semiconductor
> */
>
>@@ -106,6 +106,9 @@ enum boot_src get_boot_src(void);
> #define SVR_LX2160A 0x873600
> #define SVR_LX2120A 0x873620
> #define SVR_LX2080A 0x873602
>+#define SVR_LX2162A 0x873608
>+#define SVR_LX2122A 0x873628
>+#define SVR_LX2082A 0x87360A
>
> #define SVR_MAJ(svr) (((svr) >> 4) & 0xf)
> #define SVR_MIN(svr) (((svr) >> 0) & 0xf)
>diff --git
Re: [PATCH 2/2] pcie: pcie_advk: move setting of reference clock to the pcie driver
On 31/08/2020 09:52, Pali Rohár wrote: On Monday 31 August 2020 05:25:38 Andre Heider wrote: From: Grzegorz Jaszczyk The settings of reference clock is done via pcie address space and not comphy address space - move the settings in appropriate place. This aligns hw initialization of pcie advk with Linux and also will allow to get rid of not comphy related operation from the comphy driver. Change-Id: I9cc2e8f3e415a880dfb01d10cc8db73b7e81a605 Signed-off-by: Grzegorz Jaszczyk Reviewed-on: http://vgitil04.il.marvell.com:8080/59619 Reviewed-by: Igal Liberman Tested-by: iSoC Platform CI [a.heider: adapt to mainline] Signed-off-by: Andre Heider --- Missing downstream patch, noticed while diffing branches: https://github.com/MarvellEmbeddedProcessors/u-boot-marvell/commit/e3d9c015d434f755578a86a4b6b3acd17d69238a It looks like this patch only moves initialization code from one file to another. It is fixing some issue? I have tested PCIe on both MOX and Espressobin and it worked fine. If there is no issue I would rather wait for Marek comphy patches which should completely remove current marvell comphy driver from u-boot. I just found out that Marek's patches cover this, so this patch can be dropped: https://patchwork.ozlabs.org/project/uboot/patch/20200419154850.25868-8-marek.be...@nic.cz/ Thanks, Andre
Re: [PATCH] efi_loader: consider no-map property of reserved memory
On 31.08.20 20:08, Atish Patra wrote:
> On Thu, Aug 27, 2020 at 9:16 AM Heinrich Schuchardt
> wrote:
>>
>> If a reserved memory node in the device tree has the property no-map,
>> remove it from the UEFI memory map provided by GetMemoryMap().
>>
>> Signed-off-by: Heinrich Schuchardt
In the mail-thread starting a
[PATCH 1/1] EBBR: GetMemoryMap(), handling of no-map DT property
https://lists.linaro.org/pipermail/boot-architecture/2020-September/001389.html
the issue has been discussed. The conclusion was that we should not
change the current behavior.
Best regards
Heinrich
>> ---
>> cmd/bootefi.c | 34 --
>> include/efi.h | 3 +++
>> lib/efi_loader/efi_memory.c | 7 +--
>> 3 files changed, 36 insertions(+), 8 deletions(-)
>>
>> diff --git a/cmd/bootefi.c b/cmd/bootefi.c
>> index 40d5ef2b3a..f173105251 100644
>> --- a/cmd/bootefi.c
>> +++ b/cmd/bootefi.c
>> @@ -135,12 +135,29 @@ done:
>> return ret;
>> }
>>
>> -static void efi_reserve_memory(u64 addr, u64 size)
>> +/**
>> + * efi_reserve_memory() - add reserved memory to memory map
>> + *
>> + * @addr: start address of the reserved memory range
>> + * @size: size of the reserved memory range
>> + * @nomap: indicates that the memory range shall be hidden from the
>> memory
>> + * map
>> + */
>> +static void efi_reserve_memory(u64 addr, u64 size, bool nomap)
>> {
>> + int type;
>> + efi_uintn_t ret;
>> +
>> /* Convert from sandbox address space. */
>> addr = (uintptr_t)map_sysmem(addr, 0);
>> - if (efi_add_memory_map(addr, size,
>> - EFI_RESERVED_MEMORY_TYPE) != EFI_SUCCESS)
>> +
>> + if (nomap)
>> + type = EFI_NO_MAP_MEMORY;
>> + else
>> + type = EFI_RESERVED_MEMORY_TYPE;
>> +
>> + ret = efi_add_memory_map(addr, size, type);
>> + if (ret != EFI_SUCCESS)
>> log_err("Reserved memory mapping failed addr %llx size
>> %llx\n",
>> addr, size);
>> }
>> @@ -166,7 +183,7 @@ static void efi_carve_out_dt_rsv(void *fdt)
>> for (i = 0; i < nr_rsv; i++) {
>> if (fdt_get_mem_rsv(fdt, i, , ) != 0)
>> continue;
>> - efi_reserve_memory(addr, size);
>> + efi_reserve_memory(addr, size, false);
>> }
>>
>> /* process reserved-memory */
>> @@ -186,8 +203,13 @@ static void efi_carve_out_dt_rsv(void *fdt)
>> * a size instead of a reg property.
>> */
>> if (fdt_addr != FDT_ADDR_T_NONE &&
>> - fdtdec_get_is_enabled(fdt, subnode))
>> - efi_reserve_memory(fdt_addr, fdt_size);
>> + fdtdec_get_is_enabled(fdt, subnode)) {
>> + bool nomap;
>> +
>> + nomap = !!fdt_getprop(fdt, subnode, "no-map",
>> + NULL);
>> + efi_reserve_memory(fdt_addr, fdt_size,
>> nomap);
>> + }
>> subnode = fdt_next_subnode(fdt, subnode);
>> }
>> }
>> diff --git a/include/efi.h b/include/efi.h
>> index f986aad877..50190021ef 100644
>> --- a/include/efi.h
>> +++ b/include/efi.h
>> @@ -181,6 +181,9 @@ enum efi_mem_type {
>>
>> EFI_MAX_MEMORY_TYPE,
>> EFI_TABLE_END, /* For efi_build_mem_table() */
>> +
>> + /* Memory that shall not be mapped */
>> + EFI_NO_MAP_MEMORY,
>
> Should it be named as EFI_NO_MAP_RSVD_MEMORY to avoid ambiguity ?
>
>> };
>>
>> /* Attribute values */
>> diff --git a/lib/efi_loader/efi_memory.c b/lib/efi_loader/efi_memory.c
>> index 7be756e370..d156b9533c 100644
>> --- a/lib/efi_loader/efi_memory.c
>> +++ b/lib/efi_loader/efi_memory.c
>> @@ -251,7 +251,7 @@ static efi_status_t efi_add_memory_map_pg(u64 start, u64
>> pages,
>> EFI_PRINT("%s: 0x%llx 0x%llx %d %s\n", __func__,
>> start, pages, memory_type, overlap_only_ram ? "yes" :
>> "no");
>>
>> - if (memory_type >= EFI_MAX_MEMORY_TYPE)
>> + if (memory_type >= EFI_MAX_MEMORY_TYPE && memory_type !=
>> EFI_NO_MAP_MEMORY)
>> return EFI_INVALID_PARAMETER;
>>
>> if (!pages)
>> @@ -327,7 +327,10 @@ static efi_status_t efi_add_memory_map_pg(u64 start,
>> u64 pages,
>> }
>>
>> /* Add our new map */
>> -list_add_tail(>link, _mem);
>> + if (memory_type == EFI_NO_MAP_MEMORY)
>> + free(newlist);
>> + else
>> + list_add_tail(>link, _mem);
>>
>> /* And make sure memory is listed in descending order */
>> efi_mem_sort();
>> --
>> 2.28.0
>>
>
>
[PATCH v3 7/9] ram: octeon: Add MIPS Octeon3 DDR4 support (part 3/3)
From: Aaron Williams
This Octeon 3 DDR driver is ported from the 2013 Cavium / Marvell U-Boot
repository. It currently supports DDR4 on Octeon 3. It can be later
extended to support also DDR3 and Octeon 2 platforms.
Part 3 includes the DIMM SPD handling code and the Kconfig / Makefile
integration.
Signed-off-by: Aaron Williams
Signed-off-by: Stefan Roese
---
Changes in v3:
- Remove "https://spdx.org/licenses; line
- Remove inclusion of "common.h"
drivers/ram/Kconfig | 1 +
drivers/ram/Makefile | 2 +
drivers/ram/octeon/Kconfig | 17 ++
drivers/ram/octeon/Makefile | 8 +
drivers/ram/octeon/dimm_spd_eeprom.c | 407 +++
5 files changed, 435 insertions(+)
create mode 100644 drivers/ram/octeon/Kconfig
create mode 100644 drivers/ram/octeon/Makefile
create mode 100644 drivers/ram/octeon/dimm_spd_eeprom.c
diff --git a/drivers/ram/Kconfig b/drivers/ram/Kconfig
index 7e6e981897..a0e859afd6 100644
--- a/drivers/ram/Kconfig
+++ b/drivers/ram/Kconfig
@@ -76,3 +76,4 @@ config IMXRT_SDRAM
source "drivers/ram/rockchip/Kconfig"
source "drivers/ram/sifive/Kconfig"
source "drivers/ram/stm32mp1/Kconfig"
+source "drivers/ram/octeon/Kconfig"
diff --git a/drivers/ram/Makefile b/drivers/ram/Makefile
index 769c9d6218..d685a579a0 100644
--- a/drivers/ram/Makefile
+++ b/drivers/ram/Makefile
@@ -19,3 +19,5 @@ obj-$(CONFIG_K3_J721E_DDRSS) += k3-j721e/
obj-$(CONFIG_IMXRT_SDRAM) += imxrt_sdram.o
obj-$(CONFIG_RAM_SIFIVE) += sifive/
+
+obj-$(CONFIG_ARCH_OCTEON) += octeon/
diff --git a/drivers/ram/octeon/Kconfig b/drivers/ram/octeon/Kconfig
new file mode 100644
index 00..eb5a1208ed
--- /dev/null
+++ b/drivers/ram/octeon/Kconfig
@@ -0,0 +1,17 @@
+config RAM_OCTEON
+ bool "Ram drivers for Octeon SoCs"
+ depends on RAM && ARCH_OCTEON
+ default n
+ help
+This enables support for RAM drivers for Octeon SoCs.
+
+if RAM_OCTEON
+
+config RAM_OCTEON_DDR4
+ bool "Octeon III DDR4 RAM support"
+ default n
+ help
+This enables support for DDR4 RAM suppoort for Octeon III. This does
+not include support for Octeon CN70XX.
+
+endif # RAM_OCTEON
diff --git a/drivers/ram/octeon/Makefile b/drivers/ram/octeon/Makefile
new file mode 100644
index 00..27649d1e6f
--- /dev/null
+++ b/drivers/ram/octeon/Makefile
@@ -0,0 +1,8 @@
+# SPDX-License-Identifier: GPL-2.0
+#
+# Copyright (c) 2020 Marvell, Inc.
+#
+
+obj-$(CONFIG_RAM_OCTEON_DDR4) += octeon_ddr.o
+obj-$(CONFIG_RAM_OCTEON_DDR4) += octeon3_lmc.o
+obj-y += dimm_spd_eeprom.o
diff --git a/drivers/ram/octeon/dimm_spd_eeprom.c
b/drivers/ram/octeon/dimm_spd_eeprom.c
new file mode 100644
index 00..30db54804c
--- /dev/null
+++ b/drivers/ram/octeon/dimm_spd_eeprom.c
@@ -0,0 +1,407 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2020 Marvell International Ltd.
+ */
+
+#include
+#include
+
+#include
+
+#define DEVICE_TYPEDDR4_SPD_KEY_BYTE_DEVICE_TYPE // same for DDR3 and DDR4
+#define MODULE_TYPEDDR4_SPD_KEY_BYTE_MODULE_TYPE // same for DDR3 and DDR4
+#define BUS_WIDTH(t) (((t) == DDR4_DRAM) ? \
+DDR4_SPD_MODULE_MEMORY_BUS_WIDTH : \
+DDR3_SPD_MEMORY_BUS_WIDTH)
+
+/*
+ * Allow legacy code to encode bus number in the upper bits of the address
+ * These are only supported in read_spd()
+ */
+#define OCTEON_TWSI_BUS_IN_ADDR_BIT 12
+#define OCTEON_TWSI_BUS_IN_ADDR_MASK (15 << OCTEON_TWSI_BUS_IN_ADDR_BIT)
+#define OCTEON_TWSI_GET_BUS(addr) \
+ (((addr) >> OCTEON_TWSI_BUS_IN_ADDR_BIT) & 0xf)
+
+const char *ddr3_dimm_types[] = {
+ /* */ "Undefined",
+ /* 0001 */ "RDIMM",
+ /* 0010 */ "UDIMM",
+ /* 0011 */ "SO-DIMM",
+ /* 0100 */ "Micro-DIMM",
+ /* 0101 */ "Mini-RDIMM",
+ /* 0110 */ "Mini-UDIMM",
+ /* 0111 */ "Mini-CDIMM",
+ /* 1000 */ "72b-SO-UDIMM",
+ /* 1001 */ "72b-SO-RDIMM",
+ /* 1010 */ "72b-SO-CDIMM"
+ /* 1011 */ "LRDIMM",
+ /* 1100 */ "16b-SO-DIMM",
+ /* 1101 */ "32b-SO-DIMM",
+ /* 1110 */ "Reserved",
+ /* */ "Reserved"
+};
+
+const char *ddr4_dimm_types[] = {
+ /* */ "Extended",
+ /* 0001 */ "RDIMM",
+ /* 0010 */ "UDIMM",
+ /* 0011 */ "SO-DIMM",
+ /* 0100 */ "LRDIMM",
+ /* 0101 */ "Mini-RDIMM",
+ /* 0110 */ "Mini-UDIMM",
+ /* 0111 */ "Reserved",
+ /* 1000 */ "72b-SO-RDIMM",
+ /* 1001 */ "72b-SO-UDIMM",
+ /* 1010 */ "Reserved",
+ /* 1011 */ "Reserved",
+ /* 1100 */ "16b-SO-DIMM",
+ /* 1101 */ "32b-SO-DIMM",
+ /* 1110 */ "Reserved",
+ /* */ "Reserved"
+};
+
+static u16 ddr3_crc16(u8 *ptr, int count)
+{
+ /* From DDR3 SPD specification */
+ int crc, i;
+
+ crc = 0;
+ while (--count >= 0) {
+ crc = crc ^ (int)*ptr++ << 8;
+ for (i = 0; i < 8; ++i)
[PATCH v3 9/9] mips: octeon: octeon_ebb7304: Add DDR4 support
This patch adds the board specific configuration (struct) for the
Octeon 3 EBB7304 EVK. This struct is ported from the 2013er Cavium /
Marvell U-Boot repository. Also, the Octeon RAM driver is enabled in
the board defconfig for its usage.
Tested with one and two DIMMs on the EBB7304 EVK (8 & 16 GiB).
Signed-off-by: Stefan Roese
---
(no changes since v1)
board/Marvell/octeon_ebb7304/board.c | 25 +-
board/Marvell/octeon_ebb7304/board_ddr.h | 447 +++
configs/octeon_ebb7304_defconfig | 3 +
include/configs/octeon_common.h | 11 +-
4 files changed, 479 insertions(+), 7 deletions(-)
create mode 100644 board/Marvell/octeon_ebb7304/board_ddr.h
diff --git a/board/Marvell/octeon_ebb7304/board.c
b/board/Marvell/octeon_ebb7304/board.c
index 56e50a9063..611b18fa6a 100644
--- a/board/Marvell/octeon_ebb7304/board.c
+++ b/board/Marvell/octeon_ebb7304/board.c
@@ -3,7 +3,24 @@
* Copyright (C) 2020 Stefan Roese
*/
-/*
- * Nothing included right now. Code will be added in follow-up
- * patches.
- */
+#include
+#include
+#include
+
+#include
+
+#include "board_ddr.h"
+
+#define EBB7304_DEF_DRAM_FREQ 800
+
+static struct ddr_conf board_ddr_conf[] = {
+OCTEON_EBB7304_DDR_CONFIGURATION
+};
+
+struct ddr_conf *octeon_ddr_conf_table_get(int *count, int *def_ddr_freq)
+{
+ *count = ARRAY_SIZE(board_ddr_conf);
+ *def_ddr_freq = EBB7304_DEF_DRAM_FREQ;
+
+ return board_ddr_conf;
+}
diff --git a/board/Marvell/octeon_ebb7304/board_ddr.h
b/board/Marvell/octeon_ebb7304/board_ddr.h
new file mode 100644
index 00..f2f3419e5b
--- /dev/null
+++ b/board/Marvell/octeon_ebb7304/board_ddr.h
@@ -0,0 +1,447 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (C) 2020 Marvell International Ltd.
+ *
+ * https://spdx.org/licenses
+ */
+
+#ifndef __BOARD_DDR_H__
+#define __BOARD_DDR_H__
+
+#define OCTEON_EBB7304_DRAM_SOCKET_CONFIGURATION0 \
+ { {0x1050, 0x0}, {NULL, NULL} }, { {0x1051, 0x0}, {NULL, NULL} }
+#define OCTEON_EBB7304_DRAM_SOCKET_CONFIGURATION1 \
+ { {0x1052, 0x0}, {NULL, NULL} }, { {0x1053, 0x0}, {NULL, NULL} }
+
+#define OCTEON_EBB7304_BOARD_EEPROM_TWSI_ADDR 0x56
+
+/*
+ * Local copy of these parameters to allow for customization for this
+ * board design. The generic version resides in lib_octeon_shared.h.
+ */
+
+/* LMC0_MODEREG_PARAMS1 */
+#define OCTEON_EBB7304_MODEREG_PARAMS1_1RANK_1SLOT \
+ { \
+ .cn78xx = { \
+ .pasr_00= 0,\
+ .asr_00 = 0,\
+ .srt_00 = 0,\
+ .rtt_wr_00 = ddr4_rttwr_80ohm & 3, \
+ .rtt_wr_00_ext = (ddr4_rttwr_80ohm >> 2) & 1, \
+ .dic_00 = ddr4_dic_34ohm, \
+ .rtt_nom_00 = 0,\
+ .pasr_01= 0,\
+ .asr_01 = 0,\
+ .srt_01 = 0,\
+ .rtt_wr_01 = 0,\
+ .dic_01 = ddr4_dic_34ohm, \
+ .rtt_nom_01 = 0,\
+ .pasr_10= 0,\
+ .asr_10 = 0,\
+ .srt_10 = 0,\
+ .rtt_wr_10 = 0,\
+ .dic_10 = ddr4_dic_34ohm, \
+ .rtt_nom_10 = 0,\
+ .pasr_11= 0,\
+ .asr_11 = 0,\
+ .srt_11 = 0,\
+ .rtt_wr_11 = 0,\
+ .dic_11 = ddr4_dic_34ohm, \
+ .rtt_nom_11 = 0,\
+ } \
+ }
+
+#define OCTEON_EBB7304_MODEREG_PARAMS1_1RANK_2SLOT \
+ { \
+ .cn78xx = { \
+ .pasr_00= 0,\
+ .asr_00 = 0,\
+ .srt_00 = 0,\
+ .rtt_wr_00 = ddr4_rttwr_80ohm & 3, \
+ .rtt_wr_00_ext = (ddr4_rttwr_80ohm >> 2) & 1, \
+ .dic_00 = ddr4_dic_34ohm, \
+ .rtt_nom_00 = 0,
[PATCH v3 5/9] ram: octeon: Add MIPS Octeon3 DDR4 support (part 1/3)
From: Aaron Williams
This Octeon 3 DDR driver is ported from the 2013 Cavium / Marvell U-Boot
repository. It currently supports DDR4 on Octeon 3. It can be later
extended to support also DDR3 and Octeon 2 platforms.
Part 1 adds the base U-Boot RAM driver, which will be instantiated by
the DT based probing.
Signed-off-by: Aaron Williams
Signed-off-by: Stefan Roese
---
Changes in v3:
- Remove "https://spdx.org/licenses; line
- Remove inclusion of "common.h"
Changes in v2:
- Don't re-init after relocation
- Some unsupported Octeon families removed (only Octeon 2 & 3 supported
in general)
drivers/ram/octeon/octeon_ddr.c | 2728 +++
1 file changed, 2728 insertions(+)
create mode 100644 drivers/ram/octeon/octeon_ddr.c
diff --git a/drivers/ram/octeon/octeon_ddr.c b/drivers/ram/octeon/octeon_ddr.c
new file mode 100644
index 00..757436b9d3
--- /dev/null
+++ b/drivers/ram/octeon/octeon_ddr.c
@@ -0,0 +1,2728 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2020 Marvell International Ltd.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+#include
+
+#define CONFIG_REF_HERTZ 5000
+
+DECLARE_GLOBAL_DATA_PTR;
+
+/* Sign of an integer */
+static s64 _sign(s64 v)
+{
+ return (v < 0);
+}
+
+#ifndef DDR_NO_DEBUG
+char *lookup_env(struct ddr_priv *priv, const char *format, ...)
+{
+ char *s;
+ unsigned long value;
+ va_list args;
+ char buffer[64];
+
+ va_start(args, format);
+ vsnprintf(buffer, sizeof(buffer), format, args);
+ va_end(args);
+
+ s = ddr_getenv_debug(priv, buffer);
+ if (s) {
+ value = simple_strtoul(s, NULL, 0);
+ printf("Parameter found in environment %s=\"%s\" 0x%lx (%ld)\n",
+ buffer, s, value, value);
+ }
+
+ return s;
+}
+
+char *lookup_env_ull(struct ddr_priv *priv, const char *format, ...)
+{
+ char *s;
+ u64 value;
+ va_list args;
+ char buffer[64];
+
+ va_start(args, format);
+ vsnprintf(buffer, sizeof(buffer), format, args);
+ va_end(args);
+
+ s = ddr_getenv_debug(priv, buffer);
+ if (s) {
+ value = simple_strtoull(s, NULL, 0);
+ printf("Parameter found in environment. %s = 0x%016llx\n",
+ buffer, value);
+ }
+
+ return s;
+}
+#else
+char *lookup_env(struct ddr_priv *priv, const char *format, ...)
+{
+ return NULL;
+}
+
+char *lookup_env_ull(struct ddr_priv *priv, const char *format, ...)
+{
+ return NULL;
+}
+#endif
+
+/* Number of L2C Tag-and-data sections (TADs) that are connected to LMC. */
+#define CVMX_L2C_TADS ((OCTEON_IS_MODEL(OCTEON_CN68XX) || \
+OCTEON_IS_MODEL(OCTEON_CN73XX) || \
+OCTEON_IS_MODEL(OCTEON_CNF75XX)) ? 4 : \
+ (OCTEON_IS_MODEL(OCTEON_CN78XX)) ? 8 : 1)
+
+/* Number of L2C IOBs connected to LMC. */
+#define CVMX_L2C_IOBS ((OCTEON_IS_MODEL(OCTEON_CN68XX) || \
+OCTEON_IS_MODEL(OCTEON_CN78XX) || \
+OCTEON_IS_MODEL(OCTEON_CN73XX) || \
+OCTEON_IS_MODEL(OCTEON_CNF75XX)) ? 2 : 1)
+
+#define CVMX_L2C_MAX_MEMSZ_ALLOWED (OCTEON_IS_OCTEON2() ? \
+ (32 * CVMX_L2C_TADS) : \
+ (OCTEON_IS_MODEL(OCTEON_CN70XX) ? \
+512 : (OCTEON_IS_OCTEON3() ? 1024 : 0)))
+
+/**
+ * Initialize the BIG address in L2C+DRAM to generate proper error
+ * on reading/writing to an non-existent memory location.
+ *
+ * @param node OCX CPU node number
+ * @param mem_size Amount of DRAM configured in MB.
+ * @param mode Allow/Disallow reporting errors L2C_INT_SUM[BIGRD,BIGWR].
+ */
+static void cvmx_l2c_set_big_size(struct ddr_priv *priv, u64 mem_size, int
mode)
+{
+ if ((OCTEON_IS_OCTEON2() || OCTEON_IS_OCTEON3()) &&
+ !OCTEON_IS_MODEL(OCTEON_CN63XX_PASS1_X)) {
+ union cvmx_l2c_big_ctl big_ctl;
+ int bits = 0, zero_bits = 0;
+ u64 mem;
+
+ if (mem_size > (CVMX_L2C_MAX_MEMSZ_ALLOWED * 1024ull)) {
+ printf("WARNING: Invalid memory size(%lld) requested,
should be <= %lld\n",
+ mem_size,
+ (u64)CVMX_L2C_MAX_MEMSZ_ALLOWED * 1024);
+ mem_size = CVMX_L2C_MAX_MEMSZ_ALLOWED * 1024;
+ }
+
+ mem = mem_size;
+ while (mem) {
+ if ((mem & 1) == 0)
+ zero_bits++;
+ bits++;
+ mem >>= 1;
+ }
+
+ if ((bits - zero_bits) != 1 || (bits - 9) <= 0) {
+
[PATCH v3 4/9] mips: octeon: Add octeon_ddr.h header
From: Aaron Williams
This header will be used by the DDR driver (lmc). Its ported from the
2013 Cavium / Marvell U-Boot repository.
Signed-off-by: Aaron Williams
Signed-off-by: Stefan Roese
---
Changes in v3:
- Remove "https://spdx.org/licenses; line
- Remove inclusion of "common.h"
- Remove duplicate comment line
- Remove "test-only" comment (leftover after cleanup)
Changes in v2:
- Use readq/writeq in cvmx_read64_uint64/cvmx_write64_uint64 instead of
readl/writel
.../mach-octeon/include/mach/octeon_ddr.h | 982 ++
1 file changed, 982 insertions(+)
create mode 100644 arch/mips/mach-octeon/include/mach/octeon_ddr.h
diff --git a/arch/mips/mach-octeon/include/mach/octeon_ddr.h
b/arch/mips/mach-octeon/include/mach/octeon_ddr.h
new file mode 100644
index 00..4473be4d44
--- /dev/null
+++ b/arch/mips/mach-octeon/include/mach/octeon_ddr.h
@@ -0,0 +1,982 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (C) 2020 Marvell International Ltd.
+ */
+
+#ifndef __OCTEON_DDR_H_
+#define __OCTEON_DDR_H_
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* Mapping is done starting from 0x11800.8000 */
+#define CVMX_L2C_CTL 0x0080
+#define CVMX_L2C_BIG_CTL 0x00800030
+#define CVMX_L2C_TADX_INT(i) (0x00a00028 + (((i) & 7) * 0x4))
+#define CVMX_L2C_MCIX_INT(i) (0x00c00028 + (((i) & 3) * 0x4))
+
+/* Some "external" (non-LMC) registers */
+#define CVMX_IPD_CLK_COUNT 0x00014F000338
+#define CVMX_FPA_CLK_COUNT 0x000128F0
+
+#define CVMX_NODE_MEM_SHIFT40
+
+#define DDR_INTERFACE_MAX 4
+
+/* Private data struct */
+struct ddr_priv {
+ void __iomem *lmc_base;
+ void __iomem *l2c_base;
+
+ bool ddr_clock_initialized[DDR_INTERFACE_MAX];
+ bool ddr_memory_preserved;
+ u32 flags;
+
+ struct ram_info info;
+};
+
+/* Short cut to convert a number to megabytes */
+#define MB(X) ((u64)(X) * (u64)(1024 * 1024))
+
+#define octeon_is_cpuid(x) (__OCTEON_IS_MODEL_COMPILE__(x, read_c0_prid()))
+
+#define strtoull simple_strtoull
+
+/* Access LMC registers */
+static inline u64 lmc_rd(struct ddr_priv *priv, u64 addr)
+{
+ return ioread64(priv->lmc_base + addr);
+}
+
+static inline void lmc_wr(struct ddr_priv *priv, u64 addr, u64 val)
+{
+ iowrite64(val, priv->lmc_base + addr);
+}
+
+/* Access L2C registers */
+static inline u64 l2c_rd(struct ddr_priv *priv, u64 addr)
+{
+ return ioread64(priv->l2c_base + addr);
+}
+
+static inline void l2c_wr(struct ddr_priv *priv, u64 addr, u64 val)
+{
+ iowrite64(val, priv->l2c_base + addr);
+}
+
+/* Access other CSR registers not located inside the LMC address space */
+static inline u64 csr_rd(u64 addr)
+{
+ void __iomem *base;
+
+ base = ioremap_nocache(addr, 0x100);
+ return ioread64(base);
+}
+
+static inline void csr_wr(u64 addr, u64 val)
+{
+ void __iomem *base;
+
+ base = ioremap_nocache(addr, 0x100);
+ return iowrite64(val, base);
+}
+
+/* "Normal" access, without any offsets and/or mapping */
+static inline u64 cvmx_read64_uint64(u64 addr)
+{
+ return readq((void *)addr);
+}
+
+static inline void cvmx_write64_uint64(u64 addr, u64 val)
+{
+ writeq(val, (void *)addr);
+}
+
+/* Failsafe mode */
+#define FLAG_FAILSAFE_MODE 0x01000
+/* Note that the DDR clock initialized flags must be contiguous */
+/* Clock for DDR 0 initialized */
+#define FLAG_DDR0_CLK_INITIALIZED 0x02000
+/* Clock for DDR 1 initialized */
+#define FLAG_DDR1_CLK_INITIALIZED 0x04000
+/* Clock for DDR 2 initialized */
+#define FLAG_DDR2_CLK_INITIALIZED 0x08000
+/* Clock for DDR 3 initialized */
+#define FLAG_DDR3_CLK_INITIALIZED 0x1
+/* Loaded into RAM externally */
+#define FLAG_RAM_RESIDENT 0x2
+/* Verbose DDR information */
+#define FLAG_DDR_VERBOSE 0x4
+/* Check env. for DDR variables */
+#define FLAG_DDR_DEBUG 0x8
+#define FLAG_DDR_TRACE_INIT0x10
+#define FLAG_MEMORY_PRESERVED 0x20
+#define FLAG_DFM_VERBOSE 0x40
+#define FLAG_DFM_TRACE_INIT0x80
+/* DFM memory clock initialized */
+#define FLAG_DFM_CLK_INITIALIZED 0x100
+/* EEPROM clock descr. missing */
+#define FLAG_CLOCK_DESC_MISSING0x200
+/* EEPROM board descr. missing */
+#define FLAG_BOARD_DESC_MISSING0x400
+#define FLAG_DDR_PROMPT0x800
+
+#ifndef DDR_NO_DEBUG
+static inline int ddr_verbose(struct ddr_priv *priv)
+{
+ return !!(priv->flags & FLAG_DDR_VERBOSE);
+}
+
+static inline char *ddr_getenv_debug(struct ddr_priv *priv, char *name)
+{
+ if (priv->flags & FLAG_FAILSAFE_MODE)
+ return NULL;
+
+ if (priv->flags & FLAG_DDR_DEBUG)
+ return env_get(name);
+
+ return NULL;
+}
+#else
+static inline int
[PATCH v3 0/9] mips: Add Octeon DDR4 init code
This patch adds the DDR4 init code. It is ported from the 2013 Cavium /
Marvell U-Boot version with no functional change. This was done
intentionally, as this code is very large and complex and is known to
work on many boards "as-is". So any functional change might have
introduced (hidden) incompatibilities.
Please note that the code has undergone many hours (read many days) of
code cleanup and restructuring. Unfortunately its still not 100%
checkpatch clean, as some warnings and checks can practically not be
removed / addresses, like these here:
CHECK: Prefer kernel type 's8' over 'int8_t'
-> 's8' can't be used on MIPS platforms, as its a register macro
or:
WARNING: Too many leading tabs - consider code refactoring
+ while (xor != 0) {
-> I've restructured the code already and its very hard to remove all
these "Too many leading tabs" warnings.
or other warnings / checks.
But compared to the original code in much better shape (checkpatch
wise). I would have liked to include a checkpatch summary in this cover-
letter, showing the "before" (original code) and "after" (this code)
numbers, but unfortunately currently running checkpatch on the really
big file (octeon3_lmc.c) leads to many false errors. I can only suspect
that checkpatch has an issue handling this big file because of its size.
This code is tested on the Octeon3 EBB7304 EVK and works without any
known issues with 1 or 2 DDR4 DIMM configurations (8 & 16 GiB).
Thanks,
Stefan
Changes in v3:
- Remove "https://spdx.org/licenses; line
- Move multiple comment blocks into one
- Remove "https://spdx.org/licenses; line
- Remove "https://spdx.org/licenses; line
- Remove inclusion of "common.h"
- Remove duplicate comment line
- Remove "test-only" comment (leftover after cleanup)
- Remove "https://spdx.org/licenses; line
- Remove inclusion of "common.h"
- Remove all internal defines that resulted in dead code, as they have
never been changed via external config files or Kconfig. This results
in a smaller (~13KiB of source code saved, > 450 lines removed) and
much cleaner code base.
- Remove "https://spdx.org/licenses; line
- Remove "https://spdx.org/licenses; line
- Remove inclusion of "common.h"
Changes in v2:
- Some unsupported Octeon families removed (only Octeon 2 & 3 supported
in general)
- Some unsupported Octeon families removed (only Octeon 2 & 3 supported
in general)
- Use readq/writeq in cvmx_read64_uint64/cvmx_write64_uint64 instead of
readl/writel
- Don't re-init after relocation
- Some unsupported Octeon families removed (only Octeon 2 & 3 supported
in general)
- Only map 256MiB of RAM in U-Boot and print total size as well
- Add year to copyright line
Aaron Williams (6):
mips: octeon: Add octeon-model.h header
mips: octeon Add cvmx/cvmx-lmcx-defs.h header
mips: octeon: Add octeon_ddr.h header
ram: octeon: Add MIPS Octeon3 DDR4 support (part 1/3)
ram: octeon: Add MIPS Octeon3 DDR4 support (part 2/3)
ram: octeon: Add MIPS Octeon3 DDR4 support (part 3/3)
Stefan Roese (3):
mips: octeon: dts: mrvl,cn73xx.dtsi: Add memory controller DT node
mips: octeon: dram.c: Add RAM driver support
mips: octeon: octeon_ebb7304: Add DDR4 support
arch/mips/dts/mrvl,cn73xx.dtsi|17 +
arch/mips/mach-octeon/dram.c |72 +-
.../include/mach/cvmx/cvmx-lmcx-defs.h| 4574 +++
.../mach-octeon/include/mach/octeon-model.h | 313 +
.../mach-octeon/include/mach/octeon_ddr.h | 982 ++
board/Marvell/octeon_ebb7304/board.c |25 +-
board/Marvell/octeon_ebb7304/board_ddr.h | 447 +
configs/octeon_ebb7304_defconfig | 3 +
drivers/ram/Kconfig | 1 +
drivers/ram/Makefile | 2 +
drivers/ram/octeon/Kconfig|17 +
drivers/ram/octeon/Makefile | 8 +
drivers/ram/octeon/dimm_spd_eeprom.c | 407 +
drivers/ram/octeon/octeon3_lmc.c | 11030
drivers/ram/octeon/octeon_ddr.c | 2728
include/configs/octeon_common.h |11 +-
16 files changed, 20622 insertions(+), 15 deletions(-)
create mode 100644 arch/mips/mach-octeon/include/mach/cvmx/cvmx-lmcx-defs.h
create mode 100644 arch/mips/mach-octeon/include/mach/octeon-model.h
create mode 100644 arch/mips/mach-octeon/include/mach/octeon_ddr.h
create mode 100644 board/Marvell/octeon_ebb7304/board_ddr.h
create mode 100644 drivers/ram/octeon/Kconfig
create mode 100644 drivers/ram/octeon/Makefile
create mode 100644 drivers/ram/octeon/dimm_spd_eeprom.c
create mode 100644 drivers/ram/octeon/octeon3_lmc.c
create mode 100644 drivers/ram/octeon/octeon_ddr.c
--
2.28.0
[PATCH v3 1/9] mips: octeon: dts: mrvl, cn73xx.dtsi: Add memory controller DT node
This patch adds the memory controller (LMC) DT node to the Octeon 3 dtsi
file. It also adds the L2C DT node, as this is referenced by the DDR
driver.
Signed-off-by: Stefan Roese
---
(no changes since v1)
arch/mips/dts/mrvl,cn73xx.dtsi | 17 +
1 file changed, 17 insertions(+)
diff --git a/arch/mips/dts/mrvl,cn73xx.dtsi b/arch/mips/dts/mrvl,cn73xx.dtsi
index f5ad4a6213..44a5a03014 100644
--- a/arch/mips/dts/mrvl,cn73xx.dtsi
+++ b/arch/mips/dts/mrvl,cn73xx.dtsi
@@ -72,6 +72,23 @@
<0x0300e 4>, <0x0300f 4>;
};
+ l2c: l2c@118008000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "cavium,octeon-7xxx-l2c";
+ reg = <0x11800 0x8000 0x0 0x0100>;
+ u-boot,dm-pre-reloc;
+ };
+
+ lmc: lmc@118008800 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "cavium,octeon-7xxx-ddr4";
+ reg = <0x11800 0x8800 0x0 0x0200>; // 2 IFs
+ u-boot,dm-pre-reloc;
+ l2c-handle = <>;
+ };
+
reset: reset@1180006001600 {
compatible = "mrvl,cn7xxx-rst";
reg = <0x11800 0x06001600 0x0 0x200>;
--
2.28.0
[PATCH v3 2/9] mips: octeon: Add octeon-model.h header
From: Aaron Williams This header is used by the upcoming DDR driver and potentially by other drivers ported from the 2013 Cavium / Marvell U-Boot repository. Signed-off-by: Aaron Williams Signed-off-by: Stefan Roese --- Changes in v3: - Remove "https://spdx.org/licenses; line - Move multiple comment blocks into one Changes in v2: - Some unsupported Octeon families removed (only Octeon 2 & 3 supported in general) .../mach-octeon/include/mach/octeon-model.h | 313 ++ 1 file changed, 313 insertions(+) create mode 100644 arch/mips/mach-octeon/include/mach/octeon-model.h diff --git a/arch/mips/mach-octeon/include/mach/octeon-model.h b/arch/mips/mach-octeon/include/mach/octeon-model.h new file mode 100644 index 00..a346b3472b --- /dev/null +++ b/arch/mips/mach-octeon/include/mach/octeon-model.h @@ -0,0 +1,313 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +/* + * Copyright (C) 2020 Marvell International Ltd. + */ + +#ifndef __OCTEON_MODEL_H__ +#define __OCTEON_MODEL_H__ + +/* + * NOTE: These must match what is checked in common-config.mk + * Defines to represent the different versions of Octeon. + * + * IMPORTANT: When the default pass is updated for an Octeon Model, + * the corresponding change must also be made in the oct-sim script. + * + * The defines below should be used with the OCTEON_IS_MODEL() macro to + * determine what model of chip the software is running on. Models ending + * in 'XX' match multiple models (families), while specific models match only + * that model. If a pass (revision) is specified, then only that revision + * will be matched. Care should be taken when checking for both specific + * models and families that the specific models are checked for first. + * While these defines are similar to the processor ID, they are not intended + * to be used by anything other that the OCTEON_IS_MODEL framework, and + * the values are subject to change at anytime without notice. + * + * NOTE: only the OCTEON_IS_MODEL() macro/function and the OCTEON_CN* macros + * should be used outside of this file. All other macros are for internal + * use only, and may change without notice. + */ + +#define OCTEON_FAMILY_MASK 0x0000 +#define OCTEON_PRID_MASK 0x00ff + +/* Flag bits in top byte */ +/* Ignores revision in model checks */ +#define OM_IGNORE_REVISION0x0100 +/* Check submodels */ +#define OM_CHECK_SUBMODEL 0x0200 +/* Match all models previous than the one specified */ +#define OM_MATCH_PREVIOUS_MODELS 0x0400 +/* Ignores the minor revison on newer parts */ +#define OM_IGNORE_MINOR_REVISION 0x0800 +#define OM_FLAG_MASK 0xff00 + +/* Match all cn5XXX Octeon models. */ +#define OM_MATCH_5XXX_FAMILY_MODELS 0x2000 +/* Match all cn6XXX Octeon models. */ +#define OM_MATCH_6XXX_FAMILY_MODELS 0x4000 +/* Match all cnf7XXX Octeon models. */ +#define OM_MATCH_F7XXX_FAMILY_MODELS0x8000 +/* Match all cn7XXX Octeon models. */ +#define OM_MATCH_7XXX_FAMILY_MODELS 0x1000 +#define OM_MATCH_FAMILY_MODELS (OM_MATCH_5XXX_FAMILY_MODELS | \ +OM_MATCH_6XXX_FAMILY_MODELS | \ +OM_MATCH_F7XXX_FAMILY_MODELS | \ +OM_MATCH_7XXX_FAMILY_MODELS) + +/* + * CN7XXX models with new revision encoding + */ + +#define OCTEON_CNF75XX_PASS1_0 0x000d9800 +#define OCTEON_CNF75XX_PASS1_2 0x000d9802 +#define OCTEON_CNF75XX_PASS1_3 0x000d9803 +#define OCTEON_CNF75XX (OCTEON_CNF75XX_PASS1_0 | OM_IGNORE_REVISION) +#define OCTEON_CNF75XX_PASS1_X \ + (OCTEON_CNF75XX_PASS1_0 | OM_IGNORE_MINOR_REVISION) + +#define OCTEON_CN73XX_PASS1_0 0x000d9700 +#define OCTEON_CN73XX_PASS1_1 0x000d9701 +#define OCTEON_CN73XX_PASS1_2 0x000d9702 +#define OCTEON_CN73XX_PASS1_3 0x000d9703 +#define OCTEON_CN73XX (OCTEON_CN73XX_PASS1_0 | OM_IGNORE_REVISION) +#define OCTEON_CN73XX_PASS1_X \ + (OCTEON_CN73XX_PASS1_0 | OM_IGNORE_MINOR_REVISION) + +#define OCTEON_CN72XX OCTEON_CN73XX + +#define OCTEON_CN23XX OCTEON_CN73XX +#define OCTEON_CN23XX_PASS1_2 OCTEON_CN73XX_PASS1_2 +#define OCTEON_CN23XX_PASS1_3 OCTEON_CN73XX_PASS1_3 + +#define OCTEON_CN70XX_PASS1_0 0x000d9600 +#define OCTEON_CN70XX_PASS1_1 0x000d9601 +#define OCTEON_CN70XX_PASS1_2 0x000d9602 + +#define OCTEON_CN70XX_PASS2_0 0x000d9608 + +#define OCTEON_CN70XX (OCTEON_CN70XX_PASS1_0 | OM_IGNORE_REVISION) +#define OCTEON_CN70XX_PASS1_X \ + (OCTEON_CN70XX_PASS1_0 | OM_IGNORE_MINOR_REVISION) +#define OCTEON_CN70XX_PASS2_X \ + (OCTEON_CN70XX_PASS2_0 | OM_IGNORE_MINOR_REVISION) + +#define OCTEON_CN71XX OCTEON_CN70XX + +#define OCTEON_CN78XX_PASS1_0 0x000d9500 +#define OCTEON_CN78XX_PASS1_1 0x000d9501 +#define
[PATCH v3 8/9] mips: octeon: dram.c: Add RAM driver support
This patch adds the initialization call for the Octeon RAM driver to
the Octeon platforms code. So if enabled via Kconfig, the DDR driver
will be called and the RAM will be configured and used. If the RAM
driver is not enabled, the L2 cache is still used as RAM.
Signed-off-by: Stefan Roese
---
(no changes since v2)
Changes in v2:
- Only map 256MiB of RAM in U-Boot and print total size as well
- Add year to copyright line
arch/mips/mach-octeon/dram.c | 72
1 file changed, 64 insertions(+), 8 deletions(-)
diff --git a/arch/mips/mach-octeon/dram.c b/arch/mips/mach-octeon/dram.c
index ff7a59f2ab..6dc08e19da 100644
--- a/arch/mips/mach-octeon/dram.c
+++ b/arch/mips/mach-octeon/dram.c
@@ -1,28 +1,84 @@
// SPDX-License-Identifier: GPL-2.0+
/*
- * Copyright (C) Stefan Roese
+ * Copyright (C) 2020 Stefan Roese
*/
+#include
#include
#include
#include
#include
+#include
DECLARE_GLOBAL_DATA_PTR;
+#define UBOOT_RAM_SIZE_MAX 0x1000ULL
+
int dram_init(void)
{
- /*
-* No DDR init yet -> run in L2 cache
-*/
- gd->ram_size = (4 << 20);
- gd->bd->bi_dram[0].size = gd->ram_size;
- gd->bd->bi_dram[1].size = 0;
+ if (IS_ENABLED(CONFIG_RAM_OCTEON)) {
+ struct ram_info ram;
+ struct udevice *dev;
+ int ret;
+
+ ret = uclass_get_device(UCLASS_RAM, 0, );
+ if (ret) {
+ debug("DRAM init failed: %d\n", ret);
+ return ret;
+ }
+
+ ret = ram_get_info(dev, );
+ if (ret) {
+ debug("Cannot get DRAM size: %d\n", ret);
+ return ret;
+ }
+
+ gd->ram_size = min_t(size_t, ram.size, UBOOT_RAM_SIZE_MAX);
+ debug("SDRAM base=%lx, size=%lx\n",
+ (unsigned long)ram.base, (unsigned long)ram.size);
+ } else {
+ /*
+* No DDR init yet -> run in L2 cache
+*/
+ gd->ram_size = (4 << 20);
+ gd->bd->bi_dram[0].size = gd->ram_size;
+ gd->bd->bi_dram[1].size = 0;
+ }
return 0;
}
+void board_add_ram_info(int use_default)
+{
+ if (IS_ENABLED(CONFIG_RAM_OCTEON)) {
+ struct ram_info ram;
+ struct udevice *dev;
+ int ret;
+
+ ret = uclass_get_device(UCLASS_RAM, 0, );
+ if (ret) {
+ debug("DRAM init failed: %d\n", ret);
+ return;
+ }
+
+ ret = ram_get_info(dev, );
+ if (ret) {
+ debug("Cannot get DRAM size: %d\n", ret);
+ return;
+ }
+
+ printf(" (");
+ print_size(ram.size, " total)");
+ }
+}
+
ulong board_get_usable_ram_top(ulong total_size)
{
- return gd->ram_top;
+ if (IS_ENABLED(CONFIG_RAM_OCTEON)) {
+ /* Map a maximum of 256MiB - return not size but address */
+ return CONFIG_SYS_SDRAM_BASE + min(gd->ram_size,
+ UBOOT_RAM_SIZE_MAX);
+ } else {
+ return gd->ram_top;
+ }
}
--
2.28.0
[RESEND PATCH v2 11/11] usb: xhci: convert to readx_poll_sleep_timeout()
From: Chunfeng Yun
Use readx_poll_sleep_timeout() to poll the register status
Change-Id: If05a68baf52c54ab30029279e349be6076f1d0ca
Signed-off-by: Chunfeng Yun
---
drivers/usb/host/xhci.c | 25 +++--
1 file changed, 11 insertions(+), 14 deletions(-)
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index fe30101d93..3547a9bad1 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -33,6 +33,7 @@
#include
#include
#include
+#include
#include
#ifndef CONFIG_USB_MAX_CONTROLLER_COUNT
@@ -143,23 +144,19 @@ struct xhci_ctrl *xhci_get_ctrl(struct usb_device *udev)
* @param usec time to wait till
* @return 0 if handshake is success else < 0 on failure
*/
-static int handshake(uint32_t volatile *ptr, uint32_t mask,
- uint32_t done, int usec)
+static int
+handshake(uint32_t volatile *ptr, uint32_t mask, uint32_t done, int usec)
{
uint32_t result;
+ int ret;
+
+ ret = readx_poll_sleep_timeout(xhci_readl, ptr, result,
+(result & mask) == done || result == U32_MAX,
+1, usec);
+ if (result == U32_MAX) /* card removed */
+ return -ENODEV;
- do {
- result = xhci_readl(ptr);
- if (result == ~(uint32_t)0)
- return -ENODEV;
- result &= mask;
- if (result == done)
- return 0;
- usec--;
- udelay(1);
- } while (usec > 0);
-
- return -ETIMEDOUT;
+ return ret;
}
/**
--
2.25.1
[RESEND PATCH v2 10/11] usb: xhci: use macros with parameter to fill ep_info2
From: Chunfeng Yun
Use macros with parameter to fill ep_info2, then some macros
for MASK and SHIFT can be removed
Signed-off-by: Chunfeng Yun
---
drivers/usb/host/xhci-mem.c | 13 -
drivers/usb/host/xhci.c | 3 +--
include/usb/xhci.h | 5 -
3 files changed, 5 insertions(+), 16 deletions(-)
diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index 6292542210..0b49614995 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -830,20 +830,17 @@ void xhci_setup_addressable_virt_dev(struct xhci_ctrl
*ctrl,
switch (speed) {
case USB_SPEED_SUPER:
- ep0_ctx->ep_info2 |= cpu_to_le32(((512 & MAX_PACKET_MASK) <<
- MAX_PACKET_SHIFT));
+ ep0_ctx->ep_info2 |= cpu_to_le32(MAX_PACKET(512));
debug("Setting Packet size = 512bytes\n");
break;
case USB_SPEED_HIGH:
/* USB core guesses at a 64-byte max packet first for FS devices */
case USB_SPEED_FULL:
- ep0_ctx->ep_info2 |= cpu_to_le32(((64 & MAX_PACKET_MASK) <<
- MAX_PACKET_SHIFT));
+ ep0_ctx->ep_info2 |= cpu_to_le32(MAX_PACKET(64));
debug("Setting Packet size = 64bytes\n");
break;
case USB_SPEED_LOW:
- ep0_ctx->ep_info2 |= cpu_to_le32(((8 & MAX_PACKET_MASK) <<
- MAX_PACKET_SHIFT));
+ ep0_ctx->ep_info2 |= cpu_to_le32(MAX_PACKET(8));
debug("Setting Packet size = 8bytes\n");
break;
default:
@@ -852,9 +849,7 @@ void xhci_setup_addressable_virt_dev(struct xhci_ctrl *ctrl,
}
/* EP 0 can handle "burst" sizes of 1, so Max Burst Size field is 0 */
- ep0_ctx->ep_info2 |=
- cpu_to_le32(((0 & MAX_BURST_MASK) << MAX_BURST_SHIFT) |
- ((3 & ERROR_COUNT_MASK) << ERROR_COUNT_SHIFT));
+ ep0_ctx->ep_info2 |= cpu_to_le32(MAX_BURST(0) | ERROR_COUNT(3));
trb_64 = virt_to_phys(virt_dev->eps[0].ring->first_seg->trbs);
ep0_ctx->deq = cpu_to_le64(trb_64 | virt_dev->eps[0].ring->cycle_state);
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 6244f25c33..fe30101d93 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -831,8 +831,7 @@ int xhci_check_maxpacket(struct usb_device *udev)
ctrl->devs[slot_id]->out_ctx, ep_index);
in_ctx = ctrl->devs[slot_id]->in_ctx;
ep_ctx = xhci_get_ep_ctx(ctrl, in_ctx, ep_index);
- ep_ctx->ep_info2 &= cpu_to_le32(~((0x & MAX_PACKET_MASK)
- << MAX_PACKET_SHIFT));
+ ep_ctx->ep_info2 &= cpu_to_le32(~MAX_PACKET(MAX_PACKET_MASK));
ep_ctx->ep_info2 |= cpu_to_le32(MAX_PACKET(max_packet_size));
/*
diff --git a/include/usb/xhci.h b/include/usb/xhci.h
index c534297cc0..e1d382369a 100644
--- a/include/usb/xhci.h
+++ b/include/usb/xhci.h
@@ -632,8 +632,6 @@ struct xhci_ep_ctx {
*/
#defineFORCE_EVENT (0x1)
#define ERROR_COUNT(p) (((p) & 0x3) << 1)
-#define ERROR_COUNT_SHIFT (1)
-#define ERROR_COUNT_MASK (0x3)
#define CTX_TO_EP_TYPE(p) (((p) >> 3) & 0x7)
#define EP_TYPE(p) ((p) << 3)
#define ISOC_OUT_EP1
@@ -646,13 +644,10 @@ struct xhci_ep_ctx {
/* bit 6 reserved */
/* bit 7 is Host Initiate Disable - for disabling stream selection */
#define MAX_BURST(p) (((p)&0xff) << 8)
-#define MAX_BURST_MASK (0xff)
-#define MAX_BURST_SHIFT(8)
#define CTX_TO_MAX_BURST(p)(((p) >> 8) & 0xff)
#define MAX_PACKET(p) (((p)&0x) << 16)
#define MAX_PACKET_MASK(0x)
#define MAX_PACKET_DECODED(p) (((p) >> 16) & 0x)
-#define MAX_PACKET_SHIFT (16)
/* Get max packet size from ep desc. Bit 10..0 specify the max packet size.
* USB2.0 spec 9.6.6.
--
2.25.1
[RESEND PATCH v2 09/11] usb: xhci: convert to EP_TYPE()
From: Chunfeng Yun
Use EP_TYPE(type) macro instead of ((type) << EP_TYPE_SHIFT)
Signed-off-by: Chunfeng Yun
---
drivers/usb/host/xhci-mem.c | 2 +-
drivers/usb/host/xhci.c | 3 +--
include/usb/xhci.h | 1 -
3 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index d627aa..6292542210 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -825,7 +825,7 @@ void xhci_setup_addressable_virt_dev(struct xhci_ctrl *ctrl,
/* Step 4 - ring already allocated */
/* Step 5 */
- ep0_ctx->ep_info2 = cpu_to_le32(CTRL_EP << EP_TYPE_SHIFT);
+ ep0_ctx->ep_info2 = cpu_to_le32(EP_TYPE(CTRL_EP));
debug("SPEED = %d\n", speed);
switch (speed) {
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 5f3a0fba4b..6244f25c33 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -618,8 +618,7 @@ static int xhci_set_configuration(struct usb_device *udev)
cpu_to_le32(EP_MAX_ESIT_PAYLOAD_HI(max_esit_payload) |
EP_INTERVAL(interval) | EP_MULT(mult));
- ep_ctx[ep_index]->ep_info2 =
- cpu_to_le32(ep_type << EP_TYPE_SHIFT);
+ ep_ctx[ep_index]->ep_info2 = cpu_to_le32(EP_TYPE(ep_type));
ep_ctx[ep_index]->ep_info2 |=
cpu_to_le32(MAX_PACKET
(get_unaligned(_desc->wMaxPacketSize)));
diff --git a/include/usb/xhci.h b/include/usb/xhci.h
index 07b1aebc69..c534297cc0 100644
--- a/include/usb/xhci.h
+++ b/include/usb/xhci.h
@@ -636,7 +636,6 @@ struct xhci_ep_ctx {
#define ERROR_COUNT_MASK (0x3)
#define CTX_TO_EP_TYPE(p) (((p) >> 3) & 0x7)
#define EP_TYPE(p) ((p) << 3)
-#define EP_TYPE_SHIFT (3)
#define ISOC_OUT_EP1
#define BULK_OUT_EP2
#define INT_OUT_EP 3
--
2.25.1
[RESEND PATCH v2 04/11] usb: xhci: convert to HCS_MAX_PORTS()
From: Chunfeng Yun
Use HCS_MAX_PORTS(p) instead of
((p & HCS_MAX_PORTS_MASK) >> HCS_MAX_PORTS_SHIFT)
Signed-off-by: Chunfeng Yun
---
drivers/usb/host/xhci.c | 3 +--
include/usb/xhci.h | 2 --
2 files changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 51edeb22c1..5f3a0fba4b 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -1257,8 +1257,7 @@ static int xhci_lowlevel_init(struct xhci_ctrl *ctrl)
return -ENOMEM;
reg = xhci_readl(>cr_hcsparams1);
- descriptor.hub.bNbrPorts = ((reg & HCS_MAX_PORTS_MASK) >>
- HCS_MAX_PORTS_SHIFT);
+ descriptor.hub.bNbrPorts = HCS_MAX_PORTS(reg);
printf("Register %x NbrPorts %d\n", reg, descriptor.hub.bNbrPorts);
/* Port Indicators */
diff --git a/include/usb/xhci.h b/include/usb/xhci.h
index 3de46cd95e..cf4c0208b2 100644
--- a/include/usb/xhci.h
+++ b/include/usb/xhci.h
@@ -101,8 +101,6 @@ struct xhci_hccr {
/* bits 8:18, Max Interrupters */
#define HCS_MAX_INTRS(p) (((p) >> 8) & 0x7ff)
/* bits 24:31, Max Ports - max value is 0x7F = 127 ports */
-#define HCS_MAX_PORTS_SHIFT24
-#define HCS_MAX_PORTS_MASK (0xff << HCS_MAX_PORTS_SHIFT)
#define HCS_MAX_PORTS(p) (((p) >> 24) & 0xff)
/* HCSPARAMS2 - hcs_params2 - bitmasks */
--
2.25.1
[RESEND PATCH v2 08/11] usb: xhci: convert to TRB_TX_TYPE()
From: Chunfeng Yun
Use TRB_TX_TYPE() instead of (TRB_DATA_OUT/IN << TRB_TX_TYPE_SHIFT)
Signed-off-by: Chunfeng Yun
---
drivers/usb/host/xhci-ring.c | 4 ++--
include/usb/xhci.h | 1 -
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 99c84f95b3..ccf2a35b9f 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -830,9 +830,9 @@ int xhci_ctrl_tx(struct usb_device *udev, unsigned long
pipe,
if (ctrl->hci_version >= 0x100 || ctrl->quirks & XHCI_MTK_HOST) {
if (length > 0) {
if (req->requesttype & USB_DIR_IN)
- field |= (TRB_DATA_IN << TRB_TX_TYPE_SHIFT);
+ field |= TRB_TX_TYPE(TRB_DATA_IN);
else
- field |= (TRB_DATA_OUT << TRB_TX_TYPE_SHIFT);
+ field |= TRB_TX_TYPE(TRB_DATA_OUT);
}
}
diff --git a/include/usb/xhci.h b/include/usb/xhci.h
index 35c66042ba..07b1aebc69 100644
--- a/include/usb/xhci.h
+++ b/include/usb/xhci.h
@@ -879,7 +879,6 @@ struct xhci_event_cmd {
/* Control transfer TRB specific fields */
#define TRB_DIR_IN (1<<16)
#defineTRB_TX_TYPE(p) ((p) << 16)
-#defineTRB_TX_TYPE_SHIFT (16)
#defineTRB_DATA_OUT2
#defineTRB_DATA_IN 3
--
2.25.1
[RESEND PATCH v2 06/11] usb: xhci: convert to TRB_INTR_TARGET()
From: Chunfeng Yun
Use TRB_INTR_TARGET(x) instead of
(((x) & TRB_INTR_TARGET_MASK) << TRB_INTR_TARGET_SHIFT)
Signed-off-by: Chunfeng Yun
---
drivers/usb/host/xhci-ring.c | 10 --
include/usb/xhci.h | 2 --
2 files changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 87891fdb58..16d2e02cfa 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -690,8 +690,7 @@ int xhci_bulk_tx(struct usb_device *udev, unsigned long
pipe,
length_field = ((trb_buff_len & TRB_LEN_MASK) |
TRB_TD_SIZE(remainder) |
- ((0 & TRB_INTR_TARGET_MASK) <<
- TRB_INTR_TARGET_SHIFT));
+ TRB_INTR_TARGET(0));
trb_fields[0] = lower_32_bits(addr);
trb_fields[1] = upper_32_bits(addr);
@@ -849,8 +848,7 @@ int xhci_ctrl_tx(struct usb_device *udev, unsigned long
pipe,
trb_fields[1] = le16_to_cpu(req->index) |
le16_to_cpu(req->length) << 16;
/* TRB_LEN | (TRB_INTR_TARGET) */
- trb_fields[2] = (8 | ((0 & TRB_INTR_TARGET_MASK) <<
- TRB_INTR_TARGET_SHIFT));
+ trb_fields[2] = (8 | TRB_INTR_TARGET(0));
/* Immediate data in pointer */
trb_fields[3] = field;
queue_trb(ctrl, ep_ring, true, trb_fields);
@@ -867,7 +865,7 @@ int xhci_ctrl_tx(struct usb_device *udev, unsigned long
pipe,
remainder = xhci_td_remainder(ctrl, 0, length, length,
usb_maxpacket(udev, pipe), 1);
length_field = (length & TRB_LEN_MASK) | TRB_TD_SIZE(remainder) |
- ((0 & TRB_INTR_TARGET_MASK) << TRB_INTR_TARGET_SHIFT);
+ TRB_INTR_TARGET(0);
debug("length_field = %d, length = %d,"
"xhci_td_remainder(length) = %d , TRB_INTR_TARGET(0) = %d\n",
length_field, (length & TRB_LEN_MASK),
@@ -901,7 +899,7 @@ int xhci_ctrl_tx(struct usb_device *udev, unsigned long
pipe,
trb_fields[0] = 0;
trb_fields[1] = 0;
- trb_fields[2] = ((0 & TRB_INTR_TARGET_MASK) << TRB_INTR_TARGET_SHIFT);
+ trb_fields[2] = TRB_INTR_TARGET(0);
/* Event on completion */
trb_fields[3] = field | TRB_IOC |
TRB_TYPE(TRB_STATUS) | ep_ring->cycle_state;
diff --git a/include/usb/xhci.h b/include/usb/xhci.h
index bdba51df59..ca3d99b954 100644
--- a/include/usb/xhci.h
+++ b/include/usb/xhci.h
@@ -851,8 +851,6 @@ struct xhci_event_cmd {
/* TD Size, packets remaining in this TD, bits 21:17 (5 bits, so max 31) */
#define TRB_TD_SIZE(p) (min((p), (u32)31) << 17)
/* Interrupter Target - which MSI-X vector to target the completion event at */
-#defineTRB_INTR_TARGET_SHIFT (22)
-#defineTRB_INTR_TARGET_MASK(0x3ff)
#define TRB_INTR_TARGET(p) (((p) & 0x3ff) << 22)
#define GET_INTR_TARGET(p) (((p) >> 22) & 0x3ff)
#define TRB_TBC(p) (((p) & 0x3) << 7)
--
2.25.1
[RESEND PATCH v2 07/11] usb: xhci: convert to TRB_LEN()
From: Chunfeng Yun
Use TRB_LEN(x) instead of ((x) & TRB_LEN_MASK)
Signed-off-by: Chunfeng Yun
---
drivers/usb/host/xhci-ring.c | 8
include/usb/xhci.h | 1 -
2 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 16d2e02cfa..99c84f95b3 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -688,7 +688,7 @@ int xhci_bulk_tx(struct usb_device *udev, unsigned long
pipe,
length, maxpacketsize,
more_trbs_coming);
- length_field = ((trb_buff_len & TRB_LEN_MASK) |
+ length_field = (TRB_LEN(trb_buff_len) |
TRB_TD_SIZE(remainder) |
TRB_INTR_TARGET(0));
@@ -848,7 +848,7 @@ int xhci_ctrl_tx(struct usb_device *udev, unsigned long
pipe,
trb_fields[1] = le16_to_cpu(req->index) |
le16_to_cpu(req->length) << 16;
/* TRB_LEN | (TRB_INTR_TARGET) */
- trb_fields[2] = (8 | TRB_INTR_TARGET(0));
+ trb_fields[2] = (TRB_LEN(8) | TRB_INTR_TARGET(0));
/* Immediate data in pointer */
trb_fields[3] = field;
queue_trb(ctrl, ep_ring, true, trb_fields);
@@ -864,11 +864,11 @@ int xhci_ctrl_tx(struct usb_device *udev, unsigned long
pipe,
remainder = xhci_td_remainder(ctrl, 0, length, length,
usb_maxpacket(udev, pipe), 1);
- length_field = (length & TRB_LEN_MASK) | TRB_TD_SIZE(remainder) |
+ length_field = TRB_LEN(length) | TRB_TD_SIZE(remainder) |
TRB_INTR_TARGET(0);
debug("length_field = %d, length = %d,"
"xhci_td_remainder(length) = %d , TRB_INTR_TARGET(0) = %d\n",
- length_field, (length & TRB_LEN_MASK),
+ length_field, TRB_LEN(length),
TRB_TD_SIZE(remainder), 0);
if (length > 0) {
diff --git a/include/usb/xhci.h b/include/usb/xhci.h
index ca3d99b954..35c66042ba 100644
--- a/include/usb/xhci.h
+++ b/include/usb/xhci.h
@@ -847,7 +847,6 @@ struct xhci_event_cmd {
/* Normal TRB fields */
/* transfer_len bitmasks - bits 0:16 */
#defineTRB_LEN(p) ((p) & 0x1)
-#defineTRB_LEN_MASK(0x1)
/* TD Size, packets remaining in this TD, bits 21:17 (5 bits, so max 31) */
#define TRB_TD_SIZE(p) (min((p), (u32)31) << 17)
/* Interrupter Target - which MSI-X vector to target the completion event at */
--
2.25.1
[RESEND PATCH v2 02/11] usb: xhci: create one unified function to calculate TRB TD remainder.
From: Chunfeng Yun
xhci versions 1.0 and later report the untransferred data remaining in a
TD a bit differently than older hosts.
We used to have separate functions for these, and needed to check host
version before calling the right function.
Now Mediatek host has an additional quirk on how it uses the TD Size
field for remaining data. To prevent yet another function for calculating
remainder we instead want to make one quirk friendly unified function.
Porting from the Linux:
c840d6ce772d("xhci: create one unified function to calculate TRB TD remainder.")
124c39371114("xhci: use boolean to indicate last trb in td remainder
calculation")
Signed-off-by: Chunfeng Yun
---
drivers/usb/host/xhci-ring.c | 105 +--
include/usb/xhci.h | 2 +
2 files changed, 52 insertions(+), 55 deletions(-)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 79bfc349f4..0f86b011f3 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -298,55 +298,52 @@ void xhci_queue_command(struct xhci_ctrl *ctrl, u8 *ptr,
u32 slot_id,
xhci_writel(>dba->doorbell[0], DB_VALUE_HOST);
}
-/**
- * The TD size is the number of bytes remaining in the TD (including this TRB),
- * right shifted by 10.
- * It must fit in bits 21:17, so it can't be bigger than 31.
+/*
+ * For xHCI 1.0 host controllers, TD size is the number of max packet sized
+ * packets remaining in the TD (*not* including this TRB).
*
- * @param remainderremaining packets to be sent
- * @return remainder if remainder is less than max else max
- */
-static u32 xhci_td_remainder(unsigned int remainder)
-{
- u32 max = (1 << (21 - 17 + 1)) - 1;
-
- if ((remainder >> 10) >= max)
- return max << 17;
- else
- return (remainder >> 10) << 17;
-}
-
-/**
- * Finds out the remanining packets to be sent
+ * Total TD packet count = total_packet_count =
+ * DIV_ROUND_UP(TD size in bytes / wMaxPacketSize)
+ *
+ * Packets transferred up to and including this TRB = packets_transferred =
+ * rounddown(total bytes transferred including this TRB / wMaxPacketSize)
+ *
+ * TD size = total_packet_count - packets_transferred
*
- * @param running_totaltotal size sent so far
+ * For xHCI 0.96 and older, TD size field should be the remaining bytes
+ * including this TRB, right shifted by 10
+ *
+ * For all hosts it must fit in bits 21:17, so it can't be bigger than 31.
+ * This is taken care of in the TRB_TD_SIZE() macro
+ *
+ * The last TRB in a TD must have the TD size set to zero.
+ *
+ * @param ctrl host controller data structure
+ * @param transferred total size sent so far
* @param trb_buff_len length of the TRB Buffer
- * @param total_packet_count total packet count
- * @param maxpacketsizemax packet size of current pipe
- * @param num_trbs_leftnumber of TRBs left to be processed
- * @return 0 if running_total or trb_buff_len is 0, else remainder
+ * @param td_total_len total packet count
+ * @param maxp max packet size of current pipe
+ * @param more_trbs_coming indicate last trb in TD
+ * @return remainder
*/
-static u32 xhci_v1_0_td_remainder(int running_total,
- int trb_buff_len,
- unsigned int total_packet_count,
- int maxpacketsize,
- unsigned int num_trbs_left)
+static u32 xhci_td_remainder(struct xhci_ctrl *ctrl, int transferred,
+int trb_buff_len, unsigned int td_total_len,
+int maxp, bool more_trbs_coming)
{
- int packets_transferred;
+ u32 total_packet_count;
+
+ if (ctrl->hci_version < 0x100)
+ return ((td_total_len - transferred) >> 10);
/* One TRB with a zero-length data packet. */
- if (num_trbs_left == 0 || (running_total == 0 && trb_buff_len == 0))
+ if (!more_trbs_coming || (transferred == 0 && trb_buff_len == 0) ||
+ trb_buff_len == td_total_len)
return 0;
- /*
-* All the TRB queueing functions don't count the current TRB in
-* running_total.
-*/
- packets_transferred = (running_total + trb_buff_len) / maxpacketsize;
+ total_packet_count = DIV_ROUND_UP(td_total_len, maxp);
- if ((total_packet_count - packets_transferred) > 31)
- return 31 << 17;
- return (total_packet_count - packets_transferred) << 17;
+ /* Queueing functions don't count the current TRB into transferred */
+ return (total_packet_count - ((transferred + trb_buff_len) / maxp));
}
/**
@@ -572,7 +569,7 @@ int xhci_bulk_tx(struct usb_device *udev, unsigned long
pipe,
union xhci_trb *event;
int running_total, trb_buff_len;
- unsigned int total_packet_count;
+ bool more_trbs_coming = true;
int maxpacketsize;
u64
[RESEND PATCH v2 05/11] usb: xhci: convert to TRB_TYPE()
From: Chunfeng Yun
Use TRB_TYPE(p) instead of ((p) << TRB_TYPE_SHIFT)
Signed-off-by: Chunfeng Yun
---
drivers/usb/host/xhci-mem.c | 3 +--
drivers/usb/host/xhci-ring.c | 11 +--
include/usb/xhci.h | 1 -
3 files changed, 6 insertions(+), 9 deletions(-)
diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index 1da0524aa0..d627aa 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -236,8 +236,7 @@ static void xhci_link_segments(struct xhci_segment *prev,
*/
val = le32_to_cpu(prev->trbs[TRBS_PER_SEGMENT-1].link.control);
val &= ~TRB_TYPE_BITMASK;
- val |= (TRB_LINK << TRB_TYPE_SHIFT);
-
+ val |= TRB_TYPE(TRB_LINK);
prev->trbs[TRBS_PER_SEGMENT-1].link.control = cpu_to_le32(val);
}
}
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index cf8b9d2362..87891fdb58 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -696,7 +696,7 @@ int xhci_bulk_tx(struct usb_device *udev, unsigned long
pipe,
trb_fields[0] = lower_32_bits(addr);
trb_fields[1] = upper_32_bits(addr);
trb_fields[2] = length_field;
- trb_fields[3] = field | (TRB_NORMAL << TRB_TYPE_SHIFT);
+ trb_fields[3] = field | TRB_TYPE(TRB_NORMAL);
queue_trb(ctrl, ring, (num_trbs > 1), trb_fields);
@@ -823,7 +823,7 @@ int xhci_ctrl_tx(struct usb_device *udev, unsigned long
pipe,
/* Queue setup TRB - see section 6.4.1.2.1 */
/* FIXME better way to translate setup_packet into two u32 fields? */
field = 0;
- field |= TRB_IDT | (TRB_SETUP << TRB_TYPE_SHIFT);
+ field |= TRB_IDT | TRB_TYPE(TRB_SETUP);
if (start_cycle == 0)
field |= 0x1;
@@ -860,9 +860,9 @@ int xhci_ctrl_tx(struct usb_device *udev, unsigned long
pipe,
/* If there's data, queue data TRBs */
/* Only set interrupt on short packet for IN endpoints */
if (usb_pipein(pipe))
- field = TRB_ISP | (TRB_DATA << TRB_TYPE_SHIFT);
+ field = TRB_ISP | TRB_TYPE(TRB_DATA);
else
- field = (TRB_DATA << TRB_TYPE_SHIFT);
+ field = TRB_TYPE(TRB_DATA);
remainder = xhci_td_remainder(ctrl, 0, length, length,
usb_maxpacket(udev, pipe), 1);
@@ -904,8 +904,7 @@ int xhci_ctrl_tx(struct usb_device *udev, unsigned long
pipe,
trb_fields[2] = ((0 & TRB_INTR_TARGET_MASK) << TRB_INTR_TARGET_SHIFT);
/* Event on completion */
trb_fields[3] = field | TRB_IOC |
- (TRB_STATUS << TRB_TYPE_SHIFT) |
- ep_ring->cycle_state;
+ TRB_TYPE(TRB_STATUS) | ep_ring->cycle_state;
queue_trb(ctrl, ep_ring, false, trb_fields);
diff --git a/include/usb/xhci.h b/include/usb/xhci.h
index cf4c0208b2..bdba51df59 100644
--- a/include/usb/xhci.h
+++ b/include/usb/xhci.h
@@ -903,7 +903,6 @@ union xhci_trb {
/* TRB bit mask */
#defineTRB_TYPE_BITMASK(0xfc00)
#define TRB_TYPE(p)((p) << 10)
-#define TRB_TYPE_SHIFT (10)
#define TRB_FIELD_TO_TYPE(p) (((p) & TRB_TYPE_BITMASK) >> 10)
/* TRB type IDs */
--
2.25.1
[RESEND PATCH v2 01/11] usb: xhci: add a member hci_version in xhci_ctrl struct
From: Chunfeng Yun
Add a member to save xHCI version, it's used some times.
Signed-off-by: Chunfeng Yun
---
drivers/usb/host/xhci-ring.c | 4 ++--
drivers/usb/host/xhci.c | 1 +
include/usb/xhci.h | 1 +
3 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 092ed6eaf1..79bfc349f4 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -682,7 +682,7 @@ int xhci_bulk_tx(struct usb_device *udev, unsigned long
pipe,
field |= TRB_ISP;
/* Set the TRB length, TD size, and interrupter fields. */
- if (HC_VERSION(xhci_readl(>hccr->cr_capbase)) < 0x100)
+ if (ctrl->hci_version < 0x100)
remainder = xhci_td_remainder(length - running_total);
else
remainder = xhci_v1_0_td_remainder(running_total,
@@ -830,7 +830,7 @@ int xhci_ctrl_tx(struct usb_device *udev, unsigned long
pipe,
field |= 0x1;
/* xHCI 1.0 6.4.1.2.1: Transfer Type field */
- if (HC_VERSION(xhci_readl(>hccr->cr_capbase)) >= 0x100) {
+ if (ctrl->hci_version >= 0x100) {
if (length > 0) {
if (req->requesttype & USB_DIR_IN)
field |= (TRB_DATA_IN << TRB_TX_TYPE_SHIFT);
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 126dabc11b..4be1411243 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -1283,6 +1283,7 @@ static int xhci_lowlevel_init(struct xhci_ctrl *ctrl)
reg = HC_VERSION(xhci_readl(>cr_capbase));
printf("USB XHCI %x.%02x\n", reg >> 8, reg & 0xff);
+ ctrl->hci_version = reg;
return 0;
}
diff --git a/include/usb/xhci.h b/include/usb/xhci.h
index 7d34103fd5..a3e5914b10 100644
--- a/include/usb/xhci.h
+++ b/include/usb/xhci.h
@@ -1227,6 +1227,7 @@ struct xhci_ctrl {
struct xhci_scratchpad *scratchpad;
struct xhci_virt_device *devs[MAX_HC_SLOTS];
int rootdev;
+ u16 hci_version;
};
unsigned long trb_addr(struct xhci_segment *seg, union xhci_trb *trb);
--
2.25.1
