Re: [U-Boot] [PATCH v2 1/2] arm: dts: rock960: Enable booting from eMMC when using SPL
Hi Manivannan, On Sat, 17 Aug 2019 at 08:53, Manivannan Sadhasivam wrote: > > Hi, > > On Sat, Aug 17, 2019 at 12:23:35AM +0530, Anand Moon wrote: > > Hi All, > > > > On Mon, 5 Aug 2019 at 20:09, Peter Robinson wrote: > > > > > > On Mon, Aug 5, 2019 at 1:54 PM Kever Yang > > > wrote: > > > > > > > > > > > > On 2019/7/29 下午9:52, Manivannan Sadhasivam wrote: > > > > > This commits enables booting from eMMC when using SPL on 96Boards > > > > > Rock960 board by adding SDHCI to boot order. Since the SDHCI driver > > > > > already has the reloc flag, this works straightaway. While we are at > > > > > it, > > > > > let's also include the common u-boot dtsi for rk3399. > > > > > > > > > > Signed-off-by: Manivannan Sadhasivam > > > > > > > > > > > > > Reviewed-by: Kever Yang > > > > > > Tested-by: Peter Robinson > > > > > > > I have with me Rock960 model A board, I could not get the > > board to boot up using SPL image using microSD card. > > > > Build spl image for rock960 > > [1] https://pastebin.com/6gMPyNr1 > > > > Console log of boot failed. > > [2] https://pastebin.com/EvWzjD0y > > > > Could some body share the correct steps to build the spl image > > for Rock960 Model A board for microSD card. > > > > You seems to be using vendor u-boot! Please forward your questions to > 96Boards forum: https://discuss.96boards.org/c/products/rock960 > > Mailing list only covers issues with upstream u-boot. Ok I will post my query over their on the forum. Yes here is the boot log form my latest Non SPL boot from sdcard. [0] https://pastebin.com/thSWWjPv so I am able to boot using latest u-boot. But when I build the u-boot using below steps it fails to boot. [1] https://pastebin.com/6gMPyNr1 Best Regards -Anand ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] arm: dts: rock960: Enable booting from eMMC when using SPL
Hi, On Sat, Aug 17, 2019 at 12:23:35AM +0530, Anand Moon wrote: > Hi All, > > On Mon, 5 Aug 2019 at 20:09, Peter Robinson wrote: > > > > On Mon, Aug 5, 2019 at 1:54 PM Kever Yang wrote: > > > > > > > > > On 2019/7/29 下午9:52, Manivannan Sadhasivam wrote: > > > > This commits enables booting from eMMC when using SPL on 96Boards > > > > Rock960 board by adding SDHCI to boot order. Since the SDHCI driver > > > > already has the reloc flag, this works straightaway. While we are at it, > > > > let's also include the common u-boot dtsi for rk3399. > > > > > > > > Signed-off-by: Manivannan Sadhasivam > > > > > > Reviewed-by: Kever Yang > > > > Tested-by: Peter Robinson > > > > I have with me Rock960 model A board, I could not get the > board to boot up using SPL image using microSD card. > > Build spl image for rock960 > [1] https://pastebin.com/6gMPyNr1 > > Console log of boot failed. > [2] https://pastebin.com/EvWzjD0y > > Could some body share the correct steps to build the spl image > for Rock960 Model A board for microSD card. > You seems to be using vendor u-boot! Please forward your questions to 96Boards forum: https://discuss.96boards.org/c/products/rock960 Mailing list only covers issues with upstream u-boot. Thanks, Mani > Best Regards > -Anand ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3] board: fsl: lx2160a: implement board_fix_fdt
In lx2160a rev2 the pcie controller has been changed.
Therefore, we need to change the device tree nodes of pcie controllers
so that new controller can be probed.
It involves changing the "compatible" field as well as registers names'.
we are keeping same device tree for lx2160a rev1 and rev2, therefore we
change the device tree nodes as part of fdt fixups.
These changes would only be applied if the soc revision is not rev1.
Signed-off-by: Pankaj Bansal
---
Notes:
V3:
-Fix the compilation warning "assignment discards ‘const’ qualifier"
V2:
-explained the patch requirements and patch changes.
board/freescale/lx2160a/lx2160a.c | 68 +
configs/lx2160aqds_tfa_defconfig | 1 +
configs/lx2160ardb_tfa_defconfig | 1 +
3 files changed, 70 insertions(+)
diff --git a/board/freescale/lx2160a/lx2160a.c
b/board/freescale/lx2160a/lx2160a.c
index f3885fa8b7..071b45662e 100644
--- a/board/freescale/lx2160a/lx2160a.c
+++ b/board/freescale/lx2160a/lx2160a.c
@@ -20,6 +20,8 @@
#include
#include
#include
+#include
+#include
#include
#include
#include "../common/qixis.h"
@@ -108,6 +110,72 @@ int board_early_init_f(void)
return 0;
}
+#ifdef CONFIG_OF_BOARD_FIXUP
+int board_fix_fdt(void *fdt)
+{
+ char *reg_names, *reg_name;
+ int names_len, old_name_len, new_name_len, remaining_names_len;
+ struct str_map {
+ char *old_str;
+ char *new_str;
+ } reg_names_map[] = {
+ { "ccsr", "dip" },
+ { "pf_ctrl", "ctrl" }
+ };
+ int off = -1, i;
+
+ if (IS_SVR_REV(get_svr(), 1, 0))
+ return 0;
+
+ off = fdt_node_offset_by_compatible(fdt, -1, "fsl,lx2160a-pcie");
+ while (off != -FDT_ERR_NOTFOUND) {
+ fdt_setprop(fdt, off, "compatible", "fsl,ls-pcie",
+ strlen("fsl,ls-pcie") + 1);
+
+ reg_names = (char *)fdt_getprop(fdt, off, "reg-names",
+ _len);
+ if (!reg_names)
+ continue;
+
+ reg_name = reg_names;
+ remaining_names_len = names_len - (reg_name - reg_names);
+ for (i = 0; (i < ARRAY_SIZE(reg_names_map)) && names_len; i++) {
+ old_name_len = strlen(reg_names_map[i].old_str);
+ new_name_len = strlen(reg_names_map[i].new_str);
+ if (memcmp(reg_name, reg_names_map[i].old_str,
+ old_name_len) == 0) {
+ /* first only leave required bytes for new_str
+* and copy rest of the string after it
+*/
+ memcpy(reg_name + new_name_len,
+ reg_name + old_name_len,
+ remaining_names_len - old_name_len);
+ /* Now copy new_str */
+ memcpy(reg_name, reg_names_map[i].new_str,
+ new_name_len);
+ names_len -= old_name_len;
+ names_len += new_name_len;
+ }
+
+ reg_name = memchr(reg_name, '\0', remaining_names_len);
+ if (!reg_name)
+ break;
+
+ reg_name += 1;
+
+ remaining_names_len = names_len -
+ (reg_name - reg_names);
+ }
+
+ fdt_setprop(fdt, off, "reg-names", reg_names, names_len);
+ off = fdt_node_offset_by_compatible(fdt, off,
+ "fsl,lx2160a-pcie");
+ }
+
+ return 0;
+}
+#endif
+
#if defined(CONFIG_TARGET_LX2160AQDS)
void esdhc_dspi_status_fixup(void *blob)
{
diff --git a/configs/lx2160aqds_tfa_defconfig b/configs/lx2160aqds_tfa_defconfig
index caa411fad0..f98c86d3f4 100644
--- a/configs/lx2160aqds_tfa_defconfig
+++ b/configs/lx2160aqds_tfa_defconfig
@@ -9,6 +9,7 @@ CONFIG_SEC_FIRMWARE_ARMV8_PSCI=y
CONFIG_AHCI=y
CONFIG_FIT_VERBOSE=y
CONFIG_OF_BOARD_SETUP=y
+CONFIG_OF_BOARD_FIXUP=y
CONFIG_OF_STDOUT_VIA_ALIAS=y
CONFIG_BOOTDELAY=10
CONFIG_USE_BOOTARGS=y
diff --git a/configs/lx2160ardb_tfa_defconfig b/configs/lx2160ardb_tfa_defconfig
index 2639f7683c..585a689917 100644
--- a/configs/lx2160ardb_tfa_defconfig
+++ b/configs/lx2160ardb_tfa_defconfig
@@ -10,6 +10,7 @@ CONFIG_SEC_FIRMWARE_ARMV8_PSCI=y
CONFIG_AHCI=y
CONFIG_FIT_VERBOSE=y
CONFIG_OF_BOARD_SETUP=y
+CONFIG_OF_BOARD_FIXUP=y
CONFIG_OF_STDOUT_VIA_ALIAS=y
CONFIG_BOOTDELAY=10
CONFIG_USE_BOOTARGS=y
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] ARM: DRA7: Fixup DPLL clock rate fixup logic for newer kernels
The commit 1b42ab3eda8a ("ARM: DRA7: Fixup DSPEVE, IVA and GPU clock
frequencies based on OPP") updates the kernel device-tree blob to adjust
the DSP, IVA and GPU DPLL clocks based on a one-time OPP choice selected
in U-Boot. All these DPLL clocks are children of the cm_core_aon clocks
DT node.
The hierarchy of this clocks DT node has changed in newer Linux kernels
starting from v5.0, and this results in a failure in ft_fixup_clocks()
function to update the clock rates on these newer kernels. Fix this by
updating the lookup logic to look through both the newer and older
DT hierarchy paths for the cm_core_aon clocks node.
Signed-off-by: Suman Anna
---
arch/arm/mach-omap2/omap5/fdt.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/omap5/fdt.c b/arch/arm/mach-omap2/omap5/fdt.c
index 3626d79199af..8dee555c10c6 100644
--- a/arch/arm/mach-omap2/omap5/fdt.c
+++ b/arch/arm/mach-omap2/omap5/fdt.c
@@ -201,7 +201,9 @@ static int ft_fixup_clocks(void *fdt, const char **names,
u32 *rates, int num)
int offs, node_offs, ret, i;
uint32_t phandle;
- offs = fdt_path_offset(fdt, "/ocp/l4@4a00/cm_core_aon@5000/clocks");
+ offs = fdt_path_offset(fdt,
"/ocp/interconnect@4a00/segment@0/target-module@5000/cm_core_aon@0/clocks");
+ if (offs < 0)
+ offs = fdt_path_offset(fdt,
"/ocp/l4@4a00/cm_core_aon@5000/clocks");
if (offs < 0) {
debug("Could not find cm_core_aon clocks node path offset :
%s\n",
fdt_strerror(offs));
--
2.22.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] configs: Rename environment variable fit_loadaddr to addr_fit
Andrew,
On Mon, Aug 12, 2019 at 03:59:54PM -0400, Andrew F. Davis wrote:
> This is the first part of a larger effort I would like to propose to
> unify and simplify the default set of environment variables.
>
> When many early environment variables were named there were fewer images
> being loaded, usually just a kernel. At this time names like 'loadaddr'
> would suffice. Now we have more images and many more commands that act on
> them, often re-using the same variable for several different uses. The
> contents of a variable are also not immediately known causing one to have
> to look up a chain of variables to understand what a command is actually
> doing. I suggest the following.
>
> To start, all variables containing names should be prefixed with name_
> and addresses with addr_. This is like how K2 already does things and
> allows for simple universal commands like:
>
> get_fdt_nfs=nfs ${addr_fdt} /boot/${name_fdt}
>
> Which is very clear on what is intended here and would work across all
> board that using the this naming convention.
>
> We can do this one variable at a time, start here with addr_fit.
I think this is a good initiative. Just looking at the TI stuff there
seems to be some good opportunity for cleanup and consolidation. One
concern is we need to ensure to not break stuff, which this series from
what I looked at and my limited testing should not (unless somebody does
some custom ENV-side loading tapping into parts of the environment as
part of some of their own ENV config they may have created locally but
there is no way really for us to check that).
Two quick suggestions:
1) The PATCH $SUBJECT lines should more narrowly define the scope in
which changes are made (e.g., "config: ti: *") to help make things
clearer when browsing the commit log,
2) A cover letter would be good to more organically entertain general
discussions around the approach.
For the series...
Acked-by: Andreas Dannenberg
>
> Signed-off-by: Andrew F. Davis
> ---
> include/configs/k2g_evm.h| 2 +-
> include/configs/ti_armv7_common.h| 4 ++--
> include/configs/ti_armv7_keystone2.h | 12 ++--
> 3 files changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/include/configs/k2g_evm.h b/include/configs/k2g_evm.h
> index 3ec5a5acf5..b39e956def 100644
> --- a/include/configs/k2g_evm.h
> +++ b/include/configs/k2g_evm.h
> @@ -69,7 +69,7 @@
> "run run_mon_hs; " \
> "run init_${boot}; "\
> "run get_fit_${boot}; " \
> - "bootm ${fit_loadaddr}#${name_fdt}"
> + "bootm ${addr_fit}#${name_fdt}"
> #endif
>
> /* NAND Configuration */
> diff --git a/include/configs/ti_armv7_common.h
> b/include/configs/ti_armv7_common.h
> index 828fb1b2a5..ece329fc7d 100644
> --- a/include/configs/ti_armv7_common.h
> +++ b/include/configs/ti_armv7_common.h
> @@ -52,9 +52,9 @@
>
> #define DEFAULT_FIT_TI_ARGS \
> "boot_fit=0\0" \
> - "fit_loadaddr=0x9000\0" \
> + "addr_fit=0x9000\0" \
> "fit_bootfile=fitImage\0" \
> - "update_to_fit=setenv loadaddr ${fit_loadaddr}; setenv bootfile
> ${fit_bootfile}\0" \
> + "update_to_fit=setenv loadaddr ${addr_fit}; setenv bootfile
> ${fit_bootfile}\0" \
> "loadfit=run args_mmc; bootm ${loadaddr}#${fdtfile};\0" \
>
> /*
> diff --git a/include/configs/ti_armv7_keystone2.h
> b/include/configs/ti_armv7_keystone2.h
> index b44b51bbd1..401dec4493 100644
> --- a/include/configs/ti_armv7_keystone2.h
> +++ b/include/configs/ti_armv7_keystone2.h
> @@ -240,11 +240,11 @@
> "get_mon_net=dhcp ${addr_mon} ${tftp_root}/${name_mon}\0" \
> "get_mon_nfs=nfs ${addr_mon} ${nfs_root}/boot/${name_mon}\0"\
> "get_mon_ubi=ubifsload ${addr_mon} ${bootdir}/${name_mon}\0"\
> - "get_fit_net=dhcp ${fit_loadaddr} ${tftp_root}" \
> + "get_fit_net=dhcp ${addr_fit} ${tftp_root}" \
> "/${fit_bootfile}\0"\
> - "get_fit_nfs=nfs ${fit_loadaddr} ${nfs_root}/boot/${fit_bootfile}\0"\
> - "get_fit_ubi=ubifsload ${fit_loadaddr} ${bootdir}/${fit_bootfile}\0"\
> - "get_fit_mmc=load mmc ${bootpart} ${fit_loadaddr} " \
> + "get_fit_nfs=nfs ${addr_fit} ${nfs_root}/boot/${fit_bootfile}\0"\
> + "get_fit_ubi=ubifsload ${addr_fit} ${bootdir}/${fit_bootfile}\0"\
> + "get_fit_mmc=load mmc ${bootpart} ${addr_fit} " \
> "${bootdir}/${fit_bootfile}\0" \
> "get_uboot_net=dhcp ${loadaddr} ${tftp_root}/${name_uboot}\0" \
> "get_uboot_nfs=nfs ${loadaddr} ${nfs_root}/boot/${name_uboot}\0" \
> @@ -261,7 +261,7 @@
> "get_fdt_ramfs=dhcp ${fdtaddr} ${tftp_root}/${name_fdt}\0" \
> "get_kern_ramfs=dhcp ${loadaddr} ${tftp_root}/${name_kern}\0" \
> "get_mon_ramfs=dhcp ${addr_mon}
Re: [U-Boot] [PATCH v2 1/2] arm: dts: rock960: Enable booting from eMMC when using SPL
Hi All, On Mon, 5 Aug 2019 at 20:09, Peter Robinson wrote: > > On Mon, Aug 5, 2019 at 1:54 PM Kever Yang wrote: > > > > > > On 2019/7/29 下午9:52, Manivannan Sadhasivam wrote: > > > This commits enables booting from eMMC when using SPL on 96Boards > > > Rock960 board by adding SDHCI to boot order. Since the SDHCI driver > > > already has the reloc flag, this works straightaway. While we are at it, > > > let's also include the common u-boot dtsi for rk3399. > > > > > > Signed-off-by: Manivannan Sadhasivam > > > > Reviewed-by: Kever Yang > > Tested-by: Peter Robinson > I have with me Rock960 model A board, I could not get the board to boot up using SPL image using microSD card. Build spl image for rock960 [1] https://pastebin.com/6gMPyNr1 Console log of boot failed. [2] https://pastebin.com/EvWzjD0y Could some body share the correct steps to build the spl image for Rock960 Model A board for microSD card. Best Regards -Anand ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2] board_f: reserve noncached space below malloc area
Noncached area at present is being initialized to random space after malloc
area. It works in most the cases as it goes to stack area & stack is not
overwriting it being far from it.
Signed-off-by: Vikas Manocha
---
Changes in v2: added blank line before return
common/board_f.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/common/board_f.c b/common/board_f.c
index 59745d5..58529d2 100644
--- a/common/board_f.c
+++ b/common/board_f.c
@@ -439,12 +439,29 @@ static int reserve_uboot(void)
return 0;
}
+#ifdef CONFIG_SYS_NONCACHED_MEMORY
+static int reserve_noncached(void)
+{
+ /* round down to SECTION SIZE (typicaly 1MB) limit */
+ gd->start_addr_sp &= ~(MMU_SECTION_SIZE - 1);
+ gd->start_addr_sp -= CONFIG_SYS_NONCACHED_MEMORY;
+ debug("Reserving %dM for noncached_alloc() at: %08lx\n",
+ CONFIG_SYS_NONCACHED_MEMORY >> 20, gd->start_addr_sp);
+
+ return 0;
+}
+#endif
+
/* reserve memory for malloc() area */
static int reserve_malloc(void)
{
gd->start_addr_sp = gd->start_addr_sp - TOTAL_MALLOC_LEN;
debug("Reserving %dk for malloc() at: %08lx\n",
TOTAL_MALLOC_LEN >> 10, gd->start_addr_sp);
+#ifdef CONFIG_SYS_NONCACHED_MEMORY
+ reserve_noncached();
+#endif
+
return 0;
}
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] mmc: Fix timeout values passed to mmc_wait_dat0()
Hi Sam,
CC: Peng
On Wed, Aug 14, 2019 at 10:52:50PM +0300, Sam Protsenko wrote:
> mmc_wait_dat0() expects timeout argument to be in usec units.
I agree, based on the documentation of wait_dat0() from commit:
https://gitlab.denx.de/u-boot/u-boot/commit/c10b85d6c25f9#5a47a9a1803c0a873c9ec4b91ce244822405d1ec_413_436
> But some
> overlying functions operate on timeout in msec units.
That seems to be also true. The two functions touched in this commit
(mmc_poll_for_busy, __mmc_switch) seem to originate from Linux, where
they clearly accept MS timeout granularity [1-2].
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=716bdb8953c7c
[2]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f90d2e4035d45
> Convert timeout
> from msec to usec when passing it to mmc_wait_dat0().
I've reviewed all the callers of mmc_wait_dat0() and I couldn't find any
other occurrences of passing MS values to this function.
I've run 'ext2load mmc 0:1 0x4800 Image' several times on
H3-Salvator-X w/o noticing any issues.
I agree with the idea of s/timeout/timeout_{us,ms}/ in the second patch
from this series.
>
> This fixes 'avb' commands on BeagleBoard X15, because next chain was
> failing:
>
> get_partition() -> mmc_switch_part() -> __mmc_switch() ->
> mmc_wait_dat0()
>
> when passing incorrect timeout from __mmc_switch() to mmc_wait_dat0().
>
> Fixes: bb98b8c5c06a ("mmc: During a switch, poll on dat0 if available and
> check the final status")
> Signed-off-by: Sam Protsenko
Reviewed-by: Eugeniu Rosca
Tested-by: Eugeniu Rosca
--
Best Regards,
Eugeniu.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] libavb: Fix build warnings after updating the lib
Hi,
As for upstreaming libavb patches, I'd be interested in landing them
upstream... makes it easier for anyone.
Our upstream is AOSP and we use gerrit for code-review:
https://android-review.googlesource.com/q/project:platform%252Fexternal%252Favb
Here's a guide to contributing:
https://source.android.com/setup/contribute/submit-patches ... hope it's
not too painful to use the AOSP process!
Thanks,
David
On Fri, Aug 16, 2019 at 9:35 AM Eugeniu Rosca wrote:
> Hi Sam,
>
> CC: LIBAVB people (w.r.t. libavb fixes in U-Boot)
>
> I can reproduce the compiler warnings myself and I confirm they are
> fixed with this patch. More comments below.
>
> On Thu, Aug 15, 2019 at 11:04:03PM +0300, Sam Protsenko wrote:
> > After updating libavb to most recent version from AOSP/master, two new
> > warnings appear:
> >
> > Warning #1:
> >
> > lib/libavb/avb_cmdline.c: In function 'avb_append_options':
> > lib/libavb/avb_cmdline.c:365:15: warning: 'dm_verity_mode' may be
> > used uninitialized in this function
> > [-Wmaybe-uninitialized]
> > new_ret = avb_replace(
> >^~~~
> > slot_data->cmdline, "$(ANDROID_VERITY_MODE)",
> dm_verity_mode);
> >
> ~
> > lib/libavb/avb_cmdline.c:374:8: warning: 'verity_mode' may be used
> > uninitialized in this function
> > [-Wmaybe-uninitialized]
> >if (!cmdline_append_option(
> > ^~
> >slot_data, "androidboot.veritymode", verity_mode)) {
> >~
> >
> > Warning #2:
> >
> > lib/libavb/avb_slot_verify.c: In function 'avb_slot_verify':
> > lib/libavb/avb_slot_verify.c:1349:23: warning: 'ret' may be used
> > uninitialized in this function
> > [-Wmaybe-uninitialized]
> >AvbSlotVerifyResult ret;
> >^~~
>
> FWIW, few of Linux commits do word-wrapping of ASCII/console dumps for
> the sake of improved readability and git grepping. Recent checkpatch
> versions don't warn on that.
>
> >
> > Fix those by providing default return values to affected functions.
> >
> > Signed-off-by: Sam Protsenko
> > ---
> > lib/libavb/avb_cmdline.c | 3 ++-
> > lib/libavb/avb_slot_verify.c | 2 +-
> > 2 files changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/lib/libavb/avb_cmdline.c b/lib/libavb/avb_cmdline.c
> > index cb5b98e423..684c512bb9 100644
> > --- a/lib/libavb/avb_cmdline.c
> > +++ b/lib/libavb/avb_cmdline.c
> > @@ -357,7 +357,8 @@ AvbSlotVerifyResult avb_append_options(
> > // Should never get here because MANAGED_RESTART_AND_EIO is
> > // remapped by avb_manage_hashtree_error_mode().
> > avb_assert_not_reached();
> > -break;
> > +ret = AVB_SLOT_VERIFY_RESULT_ERROR_INVALID_ARGUMENT;
> > +goto out;
>
> With AVB_ENABLE_DEBUG enabled, PVS-Studio reports:
> lib/libavb/avb_cmdline.c360 warnV779 Unreachable code
> detected. It is possible that an error is present.
>
> How about replacing the 'break' statement with a 'fallthrough' comment?
> It shuts down the warning w/o changing the functionality.
>
> >default:
> > ret = AVB_SLOT_VERIFY_RESULT_ERROR_INVALID_ARGUMENT;
> > goto out;
> > diff --git a/lib/libavb/avb_slot_verify.c b/lib/libavb/avb_slot_verify.c
> > index 5d400b38aa..c0defdf9c9 100644
> > --- a/lib/libavb/avb_slot_verify.c
> > +++ b/lib/libavb/avb_slot_verify.c
> > @@ -1346,7 +1346,7 @@ AvbSlotVerifyResult avb_slot_verify(AvbOps* ops,
> > AvbSlotVerifyFlags flags,
> > AvbHashtreeErrorMode
> hashtree_error_mode,
> > AvbSlotVerifyData** out_data) {
> > - AvbSlotVerifyResult ret;
> > + AvbSlotVerifyResult ret =
> AVB_SLOT_VERIFY_RESULT_ERROR_INVALID_ARGUMENT;
>
> What should we do with these out-of-tree libavb fixes? IMHO they are not
> specific to U-Boot and should be upstream-able. IMHO it is not healthy
> to accumulate too many of them, since this will make future libavb sync
> more painful.
>
> --
> Best Regards,
> Eugeniu.
>
--
David Zeuthen | zeut...@google.com |
Google
| Android Hardware-Backed Security
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 0/1] i.MX8QM ROM 7720 a1 board won't boot
On 16/08/19, Marcel Ziswiler wrote: > Hi Oliver > > On Fri, 2019-08-16 at 12:43 +, Oliver Graute wrote: > > I'am currently working on the following patch to get the imx8qm- > > rom7720-a1 > > That version sounds suspiciously like it may be based on initial alpha > silicon from NXP which as far as I know is not supported anywhere any > more. Not even in downstream. > > If it has alpha silicon my suggestion is to throw it away and move on. > > > board working with recent u-boot v2019.07. > > v2019.07 has long since been released. So what you are talking about > would be any future release like v2020.01 as even the v2019.10 merge > window long since closed. > > > Unfortunaly I get no output on my > > serial line. > > Alpha chips came with different boot ROM requiring completely different > SCFW as far as I know. I have to correct myself. After some investigation I can say that I have the B-Silicium of imx8qm on this board. So should I rename everything from a1 to b1? Best regards, Oliver ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] global_data: Remove comment of reserved arch-specific GD flags
On Fri, 16 Aug 2019 at 10:05, Simon Goldschmidt wrote: > > > > Stefan Roese schrieb am Fr., 16. Aug. 2019, 14:45: >> >> With the removal of the x86 specific GD flags, there are no arch- >> specific GD flags any more. Let's remove the comment about reserving the >> upper 16 bits for arch-specific flags in the common header. This gives >> us more flexibility with the usage of the GD flags. >> >> As a matter of fact, we are already using more than 16 bits for common >> GD flags (with the addition of GD_FLG_WDT_READY). >> >> Signed-off-by: Stefan Roese >> Cc: Bin Meng >> Cc: Simon Glass >> Cc: Tom Rini >> Cc: Simon Goldschmidt > > > Reviewed-by: Simon Goldschmidt Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 0/1] i.MX8QM ROM 7720 a1 board won't boot
On 16/08/19, Marcel Ziswiler wrote: > Hi Oliver > > On Fri, 2019-08-16 at 12:43 +, Oliver Graute wrote: > > I'am currently working on the following patch to get the imx8qm- > > rom7720-a1 > > That version sounds suspiciously like it may be based on initial alpha > silicon from NXP which as far as I know is not supported anywhere any > more. Not even in downstream. yes this board is alpha. But thats all I have right now :-p But with the vendor u-boot-imx the board is booting fine. So I assumed I could port and adapt the files and boot things up with newest released u-boot. > > If it has alpha silicon my suggestion is to throw it away and move on. > > > board working with recent u-boot v2019.07. > > v2019.07 has long since been released. So what you are talking about > would be any future release like v2020.01 as even the v2019.10 merge > window long since closed. I understood that for patch integration it takes some time. > > > Unfortunaly I get no output on my > > serial line. > > Alpha chips came with different boot ROM requiring completely different > SCFW as far as I know. Ok thats important info for me. Which I was not aware of. > > > I'am not sure if something in my patch is just missing or if my > > composition of > > "SCFW + ATF + uboot" which is necessary for this imx8qm board, is not > > working > > the right way. > > I am also wondering whether that hardware really does not require > customised SCFW but rather relies on NXP's ancient since obsolete > validation board one. If so it would need to be more or less fully > identical to that hardware which I seriously doubt. Is that really the > case? > > > Perhaps somebody can guide me in the right direction to debug this > > further. > > To debug this one would probably need access to the SCU's tightly > coupled UART aka SCU.UART0.RX/TX. Plus a special built SCFW that > actually makes use of it. Do you have that? No, currently I don't have the possibility to debug it on this level. > > BTW: NXP's latest SCFWKIT is version 1.2.2 while you still reference > ancient version 1.1. More or less the whole world changed ever since. Ok, I'll ask my vendor which scfwkit I need for my alpha board here. > > > Currently I'am applying the patch and building u-boot this way: > > > > $ export ATF_LOAD_ADDR=0x8000 > > $ export BL33_LOAD_ADDR=0x8002 > > $ make imx8qm_rom7720_a1_4G_defconfig > > $ make flash.bin > > $ dd if=u-boot.itb of=flash.bin bs=512 seek=854 > > $ sudo dd if=flash.bin of=/dev/sd[x] bs=1k seek=32 conv=fsync > > Well, meanwhile at least their MEKs NXP boots now via SPL. However, due > to current incompatibility with their recovery tooling uuu at least we > still boot our hardware without SPL but that would require building it > differently e.g. see here: > > https://gitlab.denx.de/u-boot/u-boot/blob/master/board/toradex/apalis-imx8/README > > You may also be able to recovery boot it via serial downloader but that > depends on fusing/strapping... Thx for you comments, Best regards, Oliver ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] Convert CONFIG_ARCH_CPU_INIT to Kconfig
Hello Adam, On 14.08.19 15:29, Adam Ford wrote: > This converts the following to Kconfig: >CONFIG_ARCH_CPU_INIT > > Signed-off-by: Adam Ford > For the PDU001 board: Tested-by: Felix Brack ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCHv1] imx: support i.MX8QM ROM 7720 a1 board
Add i.MX8QM ROM 7720a1 board support
Signed-off-by: Oliver Graute
Cc: Stefano Babic
Cc: Peng Fan
Cc: Ye Li
Cc: uboot-imx
---
These changes are based on this vendor tree:
https://github.com/ADVANTECH-Corp/uboot-imx6.git
I adapted the files and compared them with code from similar imx8qm-mek board
arch/arm/dts/Makefile | 1 +
arch/arm/dts/imx8qm-rom7720-a1.dts| 373 ++
arch/arm/mach-imx/imx8/Kconfig| 7 +
arch/arm/mach-imx/mkimage_fit_atf.sh | 3 +
board/freescale/imx8qm_rom7720_a1/Kconfig | 14 +
board/freescale/imx8qm_rom7720_a1/MAINTAINERS | 6 +
board/freescale/imx8qm_rom7720_a1/Makefile| 11 +
board/freescale/imx8qm_rom7720_a1/README | 53 +++
.../imx8qm_rom7720_a1/imx8qm_rom7720_a1.c | 181 +
.../freescale/imx8qm_rom7720_a1/imximage.cfg | 21 +
board/freescale/imx8qm_rom7720_a1/spl.c | 228 +++
configs/imx8qm_rom7720_a1_4G_defconfig| 77
include/configs/imx8qm_rom7720.h | 293 ++
13 files changed, 1268 insertions(+)
create mode 100644 arch/arm/dts/imx8qm-rom7720-a1.dts
create mode 100644 board/freescale/imx8qm_rom7720_a1/Kconfig
create mode 100644 board/freescale/imx8qm_rom7720_a1/MAINTAINERS
create mode 100644 board/freescale/imx8qm_rom7720_a1/Makefile
create mode 100644 board/freescale/imx8qm_rom7720_a1/README
create mode 100644 board/freescale/imx8qm_rom7720_a1/imx8qm_rom7720_a1.c
create mode 100644 board/freescale/imx8qm_rom7720_a1/imximage.cfg
create mode 100644 board/freescale/imx8qm_rom7720_a1/spl.c
create mode 100644 configs/imx8qm_rom7720_a1_4G_defconfig
create mode 100644 include/configs/imx8qm_rom7720.h
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 20dbc2ff84..54c1f40085 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -613,6 +613,7 @@ dtb-$(CONFIG_ARCH_MX7ULP) += imx7ulp-evk.dtb
dtb-$(CONFIG_ARCH_IMX8) += \
fsl-imx8qm-apalis.dtb \
fsl-imx8qm-mek.dtb \
+ imx8qm-rom7720-a1.dtb \
fsl-imx8qxp-colibri.dtb \
fsl-imx8qxp-mek.dtb
diff --git a/arch/arm/dts/imx8qm-rom7720-a1.dts
b/arch/arm/dts/imx8qm-rom7720-a1.dts
new file mode 100644
index 00..c9162bc604
--- /dev/null
+++ b/arch/arm/dts/imx8qm-rom7720-a1.dts
@@ -0,0 +1,373 @@
+// SPDX-License-Identifier:GPL-2.0+
+/*
+ * Copyright (C) 2016 Freescale Semiconductor, Inc.
+ * Copyright 2017 NXP
+ */
+
+/dts-v1/;
+
+/* First 128KB is for PSCI ATF. */
+/memreserve/ 0x8000 0x0002;
+
+#include "fsl-imx8qm.dtsi"
+
+/ {
+ model = "Advantech iMX8QM Qseven series";
+ compatible = "fsl,imx8qm-mek", "fsl,imx8qm";
+
+ chosen {
+ bootargs = "console=ttyLP0,115200
earlycon=lpuart32,0x5a06,115200";
+ stdout-path =
+ };
+
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <_gpio_leds>;
+ user {
+ label = "heartbeat";
+ gpios = < 15 0>;
+ default-state = "on";
+ linux,default-trigger = "heartbeat";
+ };
+ };
+
+ regulators {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ reg_usb_otg1_vbus: regulator@0 {
+ compatible = "regulator-fixed";
+ reg = <0>;
+ regulator-name = "usb_otg1_vbus";
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ gpio = < 3 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ reg_usdhc2_vmmc: usdhc2_vmmc {
+ compatible = "regulator-fixed";
+ regulator-name = "sw-3p3-sd1";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ gpio = < 7 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+ };
+};
+
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_hog_1>;
+
+ imx8qm-mek {
+ pinctrl_hog_1: hoggrp-1 {
+ fsl,pins = <
+ SC_P_USB_SS3_TC0_LSIO_GPIO4_IO03
0x0648
+ >;
+ };
+
+ pinctrl_fec1: fec1grp {
+ fsl,pins = <
+ SC_P_COMP_CTL_GPIO_1V8_3V3_ENET_ENETB_PAD
0x14a0
+ SC_P_ENET0_MDC_CONN_ENET0_MDC
0x0648
+ SC_P_ENET0_MDIO_CONN_ENET0_MDIO
0x0648
+ SC_P_ENET0_RGMII_TX_CTL_CONN_ENET0_RGMII_TX_CTL
0x0060
+
[U-Boot] [PATCH 0/1] i.MX8QM ROM 7720 a1 board won't boot
I'am currently working on the following patch to get the imx8qm-rom7720-a1 board working with recent u-boot v2019.07. Unfortunaly I get no output on my serial line. I'am not sure if something in my patch is just missing or if my composition of "SCFW + ATF + uboot" which is necessary for this imx8qm board, is not working the right way. Perhaps somebody can guide me in the right direction to debug this further. Currently I'am applying the patch and building u-boot this way: $ export ATF_LOAD_ADDR=0x8000 $ export BL33_LOAD_ADDR=0x8002 $ make imx8qm_rom7720_a1_4G_defconfig $ make flash.bin $ dd if=u-boot.itb of=flash.bin bs=512 seek=854 $ sudo dd if=flash.bin of=/dev/sd[x] bs=1k seek=32 conv=fsync Then I put the SD card into the board and power it on. But no output ony my serial line. Best Regards, Oliver Graute (1): imx: support i.MX8QM ROM 7720 a1 board arch/arm/dts/Makefile | 1 + arch/arm/dts/imx8qm-rom7720-a1.dts| 373 ++ arch/arm/mach-imx/imx8/Kconfig| 7 + arch/arm/mach-imx/mkimage_fit_atf.sh | 3 + board/freescale/imx8qm_rom7720_a1/Kconfig | 14 + board/freescale/imx8qm_rom7720_a1/MAINTAINERS | 6 + board/freescale/imx8qm_rom7720_a1/Makefile| 11 + board/freescale/imx8qm_rom7720_a1/README | 53 +++ .../imx8qm_rom7720_a1/imx8qm_rom7720_a1.c | 181 + .../freescale/imx8qm_rom7720_a1/imximage.cfg | 21 + board/freescale/imx8qm_rom7720_a1/spl.c | 228 +++ configs/imx8qm_rom7720_a1_4G_defconfig| 77 include/configs/imx8qm_rom7720.h | 293 ++ 13 files changed, 1268 insertions(+) create mode 100644 arch/arm/dts/imx8qm-rom7720-a1.dts create mode 100644 board/freescale/imx8qm_rom7720_a1/Kconfig create mode 100644 board/freescale/imx8qm_rom7720_a1/MAINTAINERS create mode 100644 board/freescale/imx8qm_rom7720_a1/Makefile create mode 100644 board/freescale/imx8qm_rom7720_a1/README create mode 100644 board/freescale/imx8qm_rom7720_a1/imx8qm_rom7720_a1.c create mode 100644 board/freescale/imx8qm_rom7720_a1/imximage.cfg create mode 100644 board/freescale/imx8qm_rom7720_a1/spl.c create mode 100644 configs/imx8qm_rom7720_a1_4G_defconfig create mode 100644 include/configs/imx8qm_rom7720.h -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] global_data: Remove comment of reserved arch-specific GD flags
Stefan Roese schrieb am Fr., 16. Aug. 2019, 14:45:
> With the removal of the x86 specific GD flags, there are no arch-
> specific GD flags any more. Let's remove the comment about reserving the
> upper 16 bits for arch-specific flags in the common header. This gives
> us more flexibility with the usage of the GD flags.
>
> As a matter of fact, we are already using more than 16 bits for common
> GD flags (with the addition of GD_FLG_WDT_READY).
>
> Signed-off-by: Stefan Roese
> Cc: Bin Meng
> Cc: Simon Glass
> Cc: Tom Rini
> Cc: Simon Goldschmidt
>
Reviewed-by: Simon Goldschmidt
---
> include/asm-generic/global_data.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/asm-generic/global_data.h
> b/include/asm-generic/global_data.h
> index 5372d5d8cd..7587ba2ee5 100644
> --- a/include/asm-generic/global_data.h
> +++ b/include/asm-generic/global_data.h
> @@ -150,7 +150,7 @@ typedef struct global_data {
> #endif
>
> /*
> - * Global Data Flags - the top 16 bits are reserved for arch-specific
> flags
> + * Global Data Flags
> */
> #define GD_FLG_RELOC 0x1 /* Code was relocated to RAM
> */
> #define GD_FLG_DEVINIT 0x2 /* Devices have been initialized
> */
> --
> 2.22.1
>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] x86: Remove x86 specific GD flags as they are not referenced at all
Stefan Roese schrieb am Fr., 16. Aug. 2019, 14:45:
> This patch removes the x86 architecture specific GD flags
> (GD_FLG_COLD_BOOT & GD_FLG_WARM_BOOT), as they are not used. Only
> GD_FLG_COLD_BOOT is referenced in coreboot.c but assigned in start16.S.
> But the coreboot target does not use start16.S at all and boots directly
> from the 32-bit start code.
>
> Signed-off-by: Stefan Roese
> Cc: Bin Meng
> Cc: Simon Glass
> Cc: Tom Rini
> Cc: Simon Goldschmidt
>
Reviewed-by: Simon Goldschmidt
---
> arch/x86/cpu/coreboot/coreboot.c | 3 ---
> arch/x86/cpu/start.S | 9 +
> arch/x86/cpu/start16.S | 3 ---
> arch/x86/include/asm/global_data.h | 6 --
> 4 files changed, 1 insertion(+), 20 deletions(-)
>
> diff --git a/arch/x86/cpu/coreboot/coreboot.c
> b/arch/x86/cpu/coreboot/coreboot.c
> index 4c6ed0bfb2..9686f8ed5b 100644
> --- a/arch/x86/cpu/coreboot/coreboot.c
> +++ b/arch/x86/cpu/coreboot/coreboot.c
> @@ -73,9 +73,6 @@ static void board_final_cleanup(void)
>
> int last_stage_init(void)
> {
> - if (gd->flags & GD_FLG_COLD_BOOT)
> - timestamp_add_to_bootstage();
> -
> /* start usb so that usb keyboard can be used as input device */
> if (CONFIG_IS_ENABLED(USB_KEYBOARD))
> usb_init();
> diff --git a/arch/x86/cpu/start.S b/arch/x86/cpu/start.S
> index 71cd70f9cd..3c9bdf2a9d 100644
> --- a/arch/x86/cpu/start.S
> +++ b/arch/x86/cpu/start.S
> @@ -40,9 +40,6 @@ _x86boot_start:
> movl%eax, %cr0
> wbinvd
>
> - /* Tell 32-bit code it is being entered from an in-RAM copy */
> - movl$GD_FLG_WARM_BOOT, %ebx
> -
> /*
> * Zero the BIST (Built-In Self Test) value since we don't have it.
> * It must be 0 or the previous loader would have reported an
> error.
> @@ -55,11 +52,7 @@ _x86boot_start:
> .align 4
> .long 0x12345678
> _start:
> - /*
> -* This is the 32-bit cold-reset entry point, coming from start16.
> -* Set %ebx to GD_FLG_COLD_BOOT to indicate this.
> -*/
> - movl$GD_FLG_COLD_BOOT, %ebx
> + /* This is the 32-bit cold-reset entry point, coming from start16
> */
>
> /* Save BIST */
> movl%eax, %ebp
> diff --git a/arch/x86/cpu/start16.S b/arch/x86/cpu/start16.S
> index dd659278ff..474efe4df5 100644
> --- a/arch/x86/cpu/start16.S
> +++ b/arch/x86/cpu/start16.S
> @@ -23,9 +23,6 @@ start16:
> /* Save BIST */
> movl%eax, %ecx
>
> - /* Set the Cold Boot / Hard Reset flag */
> - movl$GD_FLG_COLD_BOOT, %ebx
> -
> xorl%eax, %eax
> movl%eax, %cr3 /* Invalidate TLB */
>
> diff --git a/arch/x86/include/asm/global_data.h
> b/arch/x86/include/asm/global_data.h
> index 797397e697..17a4d34491 100644
> --- a/arch/x86/include/asm/global_data.h
> +++ b/arch/x86/include/asm/global_data.h
> @@ -137,10 +137,4 @@ static inline __attribute__((no_instrument_function))
> gd_t *get_fs_gd_ptr(void)
>
> #endif
>
> -/*
> - * Our private Global Data Flags
> - */
> -#define GD_FLG_COLD_BOOT 0x1 /* Cold Boot */
> -#define GD_FLG_WARM_BOOT 0x2 /* Warm Boot */
> -
> #endif /* __ASM_GBL_DATA_H */
> --
> 2.22.1
>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] global_data: Remove comment of reserved arch-specific GD flags
On Fri, Aug 16, 2019 at 8:45 PM Stefan Roese wrote: > > With the removal of the x86 specific GD flags, there are no arch- > specific GD flags any more. Let's remove the comment about reserving the > upper 16 bits for arch-specific flags in the common header. This gives > us more flexibility with the usage of the GD flags. > > As a matter of fact, we are already using more than 16 bits for common > GD flags (with the addition of GD_FLG_WDT_READY). > > Signed-off-by: Stefan Roese > Cc: Bin Meng > Cc: Simon Glass > Cc: Tom Rini > Cc: Simon Goldschmidt > --- > include/asm-generic/global_data.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > Reviewed-by: Bin Meng ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] x86: Remove x86 specific GD flags as they are not referenced at all
On Fri, Aug 16, 2019 at 8:45 PM Stefan Roese wrote: > > This patch removes the x86 architecture specific GD flags > (GD_FLG_COLD_BOOT & GD_FLG_WARM_BOOT), as they are not used. Only > GD_FLG_COLD_BOOT is referenced in coreboot.c but assigned in start16.S. > But the coreboot target does not use start16.S at all and boots directly > from the 32-bit start code. > > Signed-off-by: Stefan Roese > Cc: Bin Meng > Cc: Simon Glass > Cc: Tom Rini > Cc: Simon Goldschmidt > --- > arch/x86/cpu/coreboot/coreboot.c | 3 --- > arch/x86/cpu/start.S | 9 + > arch/x86/cpu/start16.S | 3 --- > arch/x86/include/asm/global_data.h | 6 -- > 4 files changed, 1 insertion(+), 20 deletions(-) > Reviewed-by: Bin Meng Tested with U-Boot as coreboot payload, and on Intel MinnowMax Tested-by: Bin Meng ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 6/6] cbfs: Rename camel-case variables
On Thu, Aug 15, 2019 at 9:56 AM Simon Glass wrote: > > Rename some camel-case variables to match U-Boot style. > > Camel case is not generally allowed in U-Boot. Rename this variable to fit > in with the style. > > Signed-off-by: Simon Glass > Reviewed-by: Bin Meng > --- > > Changes in v2: None > > fs/cbfs/cbfs.c | 44 ++-- > 1 file changed, 22 insertions(+), 22 deletions(-) > Tested-by: Bin Meng ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 5/6] cbfs: Add functions to support multiple CBFSs
On Thu, Aug 15, 2019 at 9:56 AM Simon Glass wrote: > > Sometimes an image has multiple CBFS. The current CBFS API is limited to > handling only one at time. Also it keeps track of the CBFS internally in > BSS, which does not work before relocation, for example. > > Add a few new functions to overcome these limitations. > > Signed-off-by: Simon Glass > Reviewed-by: Bin Meng > --- > > Changes in v2: None > > fs/cbfs/cbfs.c | 46 ++ > include/cbfs.h | 22 ++ > 2 files changed, 68 insertions(+) > Tested-by: Bin Meng ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 4/6] cbfs: Move result variable into the struct
On Thu, Aug 15, 2019 at 9:56 AM Simon Glass wrote: > > Move the result variable into the struct also, so that it can be used when > BSS is not available. Add a function to read it. > > Note that all functions sill use the BSS version of the data. > > Signed-off-by: Simon Glass > Reviewed-by: Bin Meng > --- > > Changes in v2: None > > cmd/cbfs.c | 4 ++-- > fs/cbfs/cbfs.c | 48 > include/cbfs.h | 7 +++ > 3 files changed, 37 insertions(+), 22 deletions(-) > Tested-by: Bin Meng ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/6] cbfs: Move static variables into a struct
On Thu, Aug 15, 2019 at 3:18 PM Bin Meng wrote: > > On Thu, Aug 15, 2019 at 9:56 AM Simon Glass wrote: > > > > At present there are a number of static variables in BSS. This cannot work > > with SPL, at least until BSS is available in board_init_r(). > > > > Move the variables into a struct, so it is possible to malloc() it and use > > it before BSS is available. > > > > Signed-off-by: Simon Glass > > --- > > > > Changes in v2: > > - Make cbfs_init() static > > - Move whitespace changes to next patch > > > > Reviewed-by: Bin Meng Tested-by: Bin Meng ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/6] cbfs: Allow CBFS to be used in SPL
On Thu, Aug 15, 2019 at 9:56 AM Simon Glass wrote: > > Add a new Kconfig option to enable CBFS in SPL. This can be useful when > the memory-init code is in CBFS. > > Signed-off-by: Simon Glass > Reviewed-by: Bin Meng > --- > > Changes in v2: > - Fix typo in Kconfig help > > fs/Makefile | 1 + > fs/cbfs/Kconfig | 12 > 2 files changed, 13 insertions(+) > Tested-by: Bin Meng ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/6] cbfs: Move declarations above functions
On Thu, Aug 15, 2019 at 9:56 AM Simon Glass wrote: > > At present this file has a function at the top, above declarations. This > is normally avoided, so fix it. > > Signed-off-by: Simon Glass > Reviewed-by: Bin Meng > --- > > Changes in v2: None > > fs/cbfs/cbfs.c | 14 +- > 1 file changed, 5 insertions(+), 9 deletions(-) > Tested-by: Bin Meng ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] x86: qemu: Fix build warnings with CONFIG_DISTRO_DEFAULTS=n
On Wed, Aug 14, 2019 at 4:23 PM Bin Meng wrote: > > Use DISTRO_BOOTENV to decouple BOOTENV from CONFIG_DISTRO_DEFAULTS. > > Reported-by: Heinrich Schuchardt > Signed-off-by: Bin Meng > --- > > include/configs/x86-common.h | 11 +++ > 1 file changed, 7 insertions(+), 4 deletions(-) > applied to u-boot-x86, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] doc: arch: correct links in x86.rst
On Fri, Aug 16, 2019 at 8:23 AM Bin Meng wrote: > > On Fri, Aug 16, 2019 at 3:21 AM Heinrich Schuchardt > wrote: > > > > Correctly reference uefi/uefi.rst and uefi/u-boot_on_efi.rst. > > > > Signed-off-by: Heinrich Schuchardt > > --- > > doc/arch/x86.rst | 3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > Reviewed-by: Bin Meng > Tested-by: Bin Meng applied to u-boot-x86, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] doc: formatting slimbootloader.rst
On Fri, Aug 16, 2019 at 8:20 AM Bin Meng wrote: > > On Fri, Aug 16, 2019 at 3:02 AM Heinrich Schuchardt > wrote: > > > > Avoid a warning when building the 'make htmldocs' target: > > > > doc/board/intel/slimbootloader.rst:90: WARNING: Title underline too short. > > > > Signed-off-by: Heinrich Schuchardt > > --- > > doc/board/intel/slimbootloader.rst | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > Reviewed-by: Bin Meng > Tested-by: Bin Meng applied to u-boot-x86, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] Revert "net: macb: Fixed reading MII_LPA register"
On Fri, Aug 16, 2019 at 10:46 AM Anup Patel wrote:
>
> On Wed, Aug 14, 2019 at 4:01 PM Bin Meng wrote:
> >
> > This reverts commit 1b0c9914cc75d1570359181ebd493cd5746cb0ed.
> >
> > Commit 1b0c9914cc75 ("net: macb: Fixed reading MII_LPA register")
> > causes 100Mbps does not work any more with SiFive FU540 GEM on the
> > HiFive Unleashed board. Revert it.
> >
> > Signed-off-by: Bin Meng
> > ---
> >
> > drivers/net/macb.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/macb.c b/drivers/net/macb.c
> > index c99cf66..25f7913 100644
> > --- a/drivers/net/macb.c
> > +++ b/drivers/net/macb.c
> > @@ -643,7 +643,7 @@ static int macb_phy_init(struct macb_device *macb,
> > const char *name)
> >
> > /* First check for GMAC and that it is GiB capable */
> > if (gem_is_gigabit_capable(macb)) {
> > - lpa = macb_mdio_read(macb, MII_LPA);
> > + lpa = macb_mdio_read(macb, MII_STAT1000);
>
> You can do this selectively by having boolean flag in macb_config which is
> only set for SiFive Unleashed.
That does not look clean to me. I actually don't understand what the
issue the previous patch was trying to fix.
Maybe until we know that better we need revert to original codes...
Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] libavb: Fix build warnings after updating the lib
Hi Sam,
CC: LIBAVB people (w.r.t. libavb fixes in U-Boot)
I can reproduce the compiler warnings myself and I confirm they are
fixed with this patch. More comments below.
On Thu, Aug 15, 2019 at 11:04:03PM +0300, Sam Protsenko wrote:
> After updating libavb to most recent version from AOSP/master, two new
> warnings appear:
>
> Warning #1:
>
> lib/libavb/avb_cmdline.c: In function 'avb_append_options':
> lib/libavb/avb_cmdline.c:365:15: warning: 'dm_verity_mode' may be
> used uninitialized in this function
> [-Wmaybe-uninitialized]
> new_ret = avb_replace(
>^~~~
> slot_data->cmdline, "$(ANDROID_VERITY_MODE)", dm_verity_mode);
> ~
> lib/libavb/avb_cmdline.c:374:8: warning: 'verity_mode' may be used
> uninitialized in this function
> [-Wmaybe-uninitialized]
>if (!cmdline_append_option(
> ^~
>slot_data, "androidboot.veritymode", verity_mode)) {
>~
>
> Warning #2:
>
> lib/libavb/avb_slot_verify.c: In function 'avb_slot_verify':
> lib/libavb/avb_slot_verify.c:1349:23: warning: 'ret' may be used
> uninitialized in this function
> [-Wmaybe-uninitialized]
>AvbSlotVerifyResult ret;
>^~~
FWIW, few of Linux commits do word-wrapping of ASCII/console dumps for
the sake of improved readability and git grepping. Recent checkpatch
versions don't warn on that.
>
> Fix those by providing default return values to affected functions.
>
> Signed-off-by: Sam Protsenko
> ---
> lib/libavb/avb_cmdline.c | 3 ++-
> lib/libavb/avb_slot_verify.c | 2 +-
> 2 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/lib/libavb/avb_cmdline.c b/lib/libavb/avb_cmdline.c
> index cb5b98e423..684c512bb9 100644
> --- a/lib/libavb/avb_cmdline.c
> +++ b/lib/libavb/avb_cmdline.c
> @@ -357,7 +357,8 @@ AvbSlotVerifyResult avb_append_options(
> // Should never get here because MANAGED_RESTART_AND_EIO is
> // remapped by avb_manage_hashtree_error_mode().
> avb_assert_not_reached();
> -break;
> +ret = AVB_SLOT_VERIFY_RESULT_ERROR_INVALID_ARGUMENT;
> +goto out;
With AVB_ENABLE_DEBUG enabled, PVS-Studio reports:
lib/libavb/avb_cmdline.c360 warnV779 Unreachable code detected.
It is possible that an error is present.
How about replacing the 'break' statement with a 'fallthrough' comment?
It shuts down the warning w/o changing the functionality.
>default:
> ret = AVB_SLOT_VERIFY_RESULT_ERROR_INVALID_ARGUMENT;
> goto out;
> diff --git a/lib/libavb/avb_slot_verify.c b/lib/libavb/avb_slot_verify.c
> index 5d400b38aa..c0defdf9c9 100644
> --- a/lib/libavb/avb_slot_verify.c
> +++ b/lib/libavb/avb_slot_verify.c
> @@ -1346,7 +1346,7 @@ AvbSlotVerifyResult avb_slot_verify(AvbOps* ops,
> AvbSlotVerifyFlags flags,
> AvbHashtreeErrorMode hashtree_error_mode,
> AvbSlotVerifyData** out_data) {
> - AvbSlotVerifyResult ret;
> + AvbSlotVerifyResult ret = AVB_SLOT_VERIFY_RESULT_ERROR_INVALID_ARGUMENT;
What should we do with these out-of-tree libavb fixes? IMHO they are not
specific to U-Boot and should be upstream-able. IMHO it is not healthy
to accumulate too many of them, since this will make future libavb sync
more painful.
--
Best Regards,
Eugeniu.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 0/1] i.MX8QM ROM 7720 a1 board won't boot
Hi Oliver On Fri, 2019-08-16 at 12:43 +, Oliver Graute wrote: > I'am currently working on the following patch to get the imx8qm- > rom7720-a1 That version sounds suspiciously like it may be based on initial alpha silicon from NXP which as far as I know is not supported anywhere any more. Not even in downstream. If it has alpha silicon my suggestion is to throw it away and move on. > board working with recent u-boot v2019.07. v2019.07 has long since been released. So what you are talking about would be any future release like v2020.01 as even the v2019.10 merge window long since closed. > Unfortunaly I get no output on my > serial line. Alpha chips came with different boot ROM requiring completely different SCFW as far as I know. > I'am not sure if something in my patch is just missing or if my > composition of > "SCFW + ATF + uboot" which is necessary for this imx8qm board, is not > working > the right way. I am also wondering whether that hardware really does not require customised SCFW but rather relies on NXP's ancient since obsolete validation board one. If so it would need to be more or less fully identical to that hardware which I seriously doubt. Is that really the case? > Perhaps somebody can guide me in the right direction to debug this > further. To debug this one would probably need access to the SCU's tightly coupled UART aka SCU.UART0.RX/TX. Plus a special built SCFW that actually makes use of it. Do you have that? BTW: NXP's latest SCFWKIT is version 1.2.2 while you still reference ancient version 1.1. More or less the whole world changed ever since. > Currently I'am applying the patch and building u-boot this way: > > $ export ATF_LOAD_ADDR=0x8000 > $ export BL33_LOAD_ADDR=0x8002 > $ make imx8qm_rom7720_a1_4G_defconfig > $ make flash.bin > $ dd if=u-boot.itb of=flash.bin bs=512 seek=854 > $ sudo dd if=flash.bin of=/dev/sd[x] bs=1k seek=32 conv=fsync Well, meanwhile at least their MEKs NXP boots now via SPL. However, due to current incompatibility with their recovery tooling uuu at least we still boot our hardware without SPL but that would require building it differently e.g. see here: https://gitlab.denx.de/u-boot/u-boot/blob/master/board/toradex/apalis-imx8/README You may also be able to recovery boot it via serial downloader but that depends on fusing/strapping... > Then I put the SD card into the board and power it on. But no output > ony my > serial line. > > Best Regards, > > Oliver Graute (1): Cheers Marcel > imx: support i.MX8QM ROM 7720 a1 board > > arch/arm/dts/Makefile | 1 + > arch/arm/dts/imx8qm-rom7720-a1.dts| 373 > ++ > arch/arm/mach-imx/imx8/Kconfig| 7 + > arch/arm/mach-imx/mkimage_fit_atf.sh | 3 + > board/freescale/imx8qm_rom7720_a1/Kconfig | 14 + > board/freescale/imx8qm_rom7720_a1/MAINTAINERS | 6 + > board/freescale/imx8qm_rom7720_a1/Makefile| 11 + > board/freescale/imx8qm_rom7720_a1/README | 53 +++ > .../imx8qm_rom7720_a1/imx8qm_rom7720_a1.c | 181 + > .../freescale/imx8qm_rom7720_a1/imximage.cfg | 21 + > board/freescale/imx8qm_rom7720_a1/spl.c | 228 +++ > configs/imx8qm_rom7720_a1_4G_defconfig| 77 > include/configs/imx8qm_rom7720.h | 293 ++ > 13 files changed, 1268 insertions(+) > create mode 100644 arch/arm/dts/imx8qm-rom7720-a1.dts > create mode 100644 board/freescale/imx8qm_rom7720_a1/Kconfig > create mode 100644 board/freescale/imx8qm_rom7720_a1/MAINTAINERS > create mode 100644 board/freescale/imx8qm_rom7720_a1/Makefile > create mode 100644 board/freescale/imx8qm_rom7720_a1/README > create mode 100644 > board/freescale/imx8qm_rom7720_a1/imx8qm_rom7720_a1.c > create mode 100644 board/freescale/imx8qm_rom7720_a1/imximage.cfg > create mode 100644 board/freescale/imx8qm_rom7720_a1/spl.c > create mode 100644 configs/imx8qm_rom7720_a1_4G_defconfig > create mode 100644 include/configs/imx8qm_rom7720.h ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/2] x86: Remove x86 specific GD flags as they are not referenced at all
This patch removes the x86 architecture specific GD flags
(GD_FLG_COLD_BOOT & GD_FLG_WARM_BOOT), as they are not used. Only
GD_FLG_COLD_BOOT is referenced in coreboot.c but assigned in start16.S.
But the coreboot target does not use start16.S at all and boots directly
from the 32-bit start code.
Signed-off-by: Stefan Roese
Cc: Bin Meng
Cc: Simon Glass
Cc: Tom Rini
Cc: Simon Goldschmidt
---
arch/x86/cpu/coreboot/coreboot.c | 3 ---
arch/x86/cpu/start.S | 9 +
arch/x86/cpu/start16.S | 3 ---
arch/x86/include/asm/global_data.h | 6 --
4 files changed, 1 insertion(+), 20 deletions(-)
diff --git a/arch/x86/cpu/coreboot/coreboot.c b/arch/x86/cpu/coreboot/coreboot.c
index 4c6ed0bfb2..9686f8ed5b 100644
--- a/arch/x86/cpu/coreboot/coreboot.c
+++ b/arch/x86/cpu/coreboot/coreboot.c
@@ -73,9 +73,6 @@ static void board_final_cleanup(void)
int last_stage_init(void)
{
- if (gd->flags & GD_FLG_COLD_BOOT)
- timestamp_add_to_bootstage();
-
/* start usb so that usb keyboard can be used as input device */
if (CONFIG_IS_ENABLED(USB_KEYBOARD))
usb_init();
diff --git a/arch/x86/cpu/start.S b/arch/x86/cpu/start.S
index 71cd70f9cd..3c9bdf2a9d 100644
--- a/arch/x86/cpu/start.S
+++ b/arch/x86/cpu/start.S
@@ -40,9 +40,6 @@ _x86boot_start:
movl%eax, %cr0
wbinvd
- /* Tell 32-bit code it is being entered from an in-RAM copy */
- movl$GD_FLG_WARM_BOOT, %ebx
-
/*
* Zero the BIST (Built-In Self Test) value since we don't have it.
* It must be 0 or the previous loader would have reported an error.
@@ -55,11 +52,7 @@ _x86boot_start:
.align 4
.long 0x12345678
_start:
- /*
-* This is the 32-bit cold-reset entry point, coming from start16.
-* Set %ebx to GD_FLG_COLD_BOOT to indicate this.
-*/
- movl$GD_FLG_COLD_BOOT, %ebx
+ /* This is the 32-bit cold-reset entry point, coming from start16 */
/* Save BIST */
movl%eax, %ebp
diff --git a/arch/x86/cpu/start16.S b/arch/x86/cpu/start16.S
index dd659278ff..474efe4df5 100644
--- a/arch/x86/cpu/start16.S
+++ b/arch/x86/cpu/start16.S
@@ -23,9 +23,6 @@ start16:
/* Save BIST */
movl%eax, %ecx
- /* Set the Cold Boot / Hard Reset flag */
- movl$GD_FLG_COLD_BOOT, %ebx
-
xorl%eax, %eax
movl%eax, %cr3 /* Invalidate TLB */
diff --git a/arch/x86/include/asm/global_data.h
b/arch/x86/include/asm/global_data.h
index 797397e697..17a4d34491 100644
--- a/arch/x86/include/asm/global_data.h
+++ b/arch/x86/include/asm/global_data.h
@@ -137,10 +137,4 @@ static inline __attribute__((no_instrument_function)) gd_t
*get_fs_gd_ptr(void)
#endif
-/*
- * Our private Global Data Flags
- */
-#define GD_FLG_COLD_BOOT 0x1 /* Cold Boot */
-#define GD_FLG_WARM_BOOT 0x2 /* Warm Boot */
-
#endif /* __ASM_GBL_DATA_H */
--
2.22.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/2] global_data: Remove comment of reserved arch-specific GD flags
With the removal of the x86 specific GD flags, there are no arch-
specific GD flags any more. Let's remove the comment about reserving the
upper 16 bits for arch-specific flags in the common header. This gives
us more flexibility with the usage of the GD flags.
As a matter of fact, we are already using more than 16 bits for common
GD flags (with the addition of GD_FLG_WDT_READY).
Signed-off-by: Stefan Roese
Cc: Bin Meng
Cc: Simon Glass
Cc: Tom Rini
Cc: Simon Goldschmidt
---
include/asm-generic/global_data.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/asm-generic/global_data.h
b/include/asm-generic/global_data.h
index 5372d5d8cd..7587ba2ee5 100644
--- a/include/asm-generic/global_data.h
+++ b/include/asm-generic/global_data.h
@@ -150,7 +150,7 @@ typedef struct global_data {
#endif
/*
- * Global Data Flags - the top 16 bits are reserved for arch-specific flags
+ * Global Data Flags
*/
#define GD_FLG_RELOC 0x1 /* Code was relocated to RAM */
#define GD_FLG_DEVINIT 0x2 /* Devices have been initialized */
--
2.22.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 00/13] powerpc: Enable device tree support
> -Original Message- > From: Jagdish Gediya > Sent: 2019年8月16日 16:26 > To: Z.q. Hou ; u-boot@lists.denx.de; > s...@chromium.org; Prabhakar Kushwaha ; > Shengzhou Liu ; bmeng...@gmail.com; Jiafei Pan > ; Priyanka Jain > Subject: RE: [PATCH 00/13] powerpc: Enable device tree support > > Hi Zhiqiang, > > > -Original Message- > > From: Z.q. Hou > > Sent: Friday, August 16, 2019 11:58 AM > > To: Jagdish Gediya ; u-boot@lists.denx.de; > > s...@chromium.org; Prabhakar Kushwaha > ; > > Shengzhou Liu ; bmeng...@gmail.com; Jiafei > Pan > > ; Priyanka Jain > > Subject: RE: [PATCH 00/13] powerpc: Enable device tree support > > > > Hi Jagdish, > > > > Thanks a lot for your comments! > > > > > -Original Message- > > > From: Jagdish Gediya > > > Sent: 2019年8月16日 14:05 > > > To: Z.q. Hou ; u-boot@lists.denx.de; > > > s...@chromium.org; Prabhakar Kushwaha > > ; > > > Shengzhou Liu ; bmeng...@gmail.com; Jiafei > > Pan > > > ; Priyanka Jain > > > Subject: RE: [PATCH 00/13] powerpc: Enable device tree support > > > > > > Hi Zhiqiang, > > > > > > > -Original Message- > > > > From: Z.q. Hou > > > > Sent: Thursday, June 20, 2019 1:49 PM > > > > To: u-boot@lists.denx.de; s...@chromium.org; Prabhakar Kushwaha > > > > ; Shengzhou Liu > > > ; > > > > bmeng...@gmail.com; Jagdish Gediya ; > > > > Jiafei Pan ; Priyanka Jain > > > > > > > > Cc: Z.q. Hou > > > > Subject: [PATCH 00/13] powerpc: Enable device tree support > > > > > > > > From: Hou Zhiqiang > > > > > > > > This patch is to enable device tree support for the Freescale > > > > PowerPC platforms below. > > > > > > > > Hou Zhiqiang (13): > > > > powerpc: Enable device tree support for T2080RDB > > > > powerpc: Enable device tree support for T4240RDB > > > > powerpc: Enable device tree support for T1024RDB > > > > powerpc: Enable device tree support for T1042D4RDB > > > > powerpc: Enable device tree support for P1020RDB > > > > powerpc: Enable device tree support for P2020RDB > > > > powerpc: Enable device tree support for P2041RDB > > > > powerpc: Enable device tree support for P3041DS > > > > powerpc: Enable device tree support for P4080DS > > > > powerpc: Enable device tree support for P5040DS > > > > powerpc: dts: add default definition of > > > CONFIG_RESET_VECTOR_ADDRESS > > > > powerpc: mpc8548cds: extend the reserved length for monitor > > > > powerpc: Enable device tree support for MPC8548CDS > > > > > > > > arch/powerpc/dts/Makefile| 12 +++ > > > > arch/powerpc/dts/e500mc_power_isa.dtsi | 33 ++ > > > > arch/powerpc/dts/e500v2_power_isa.dtsi | 26 + > > > > arch/powerpc/dts/e5500_power_isa.dtsi| 34 +++ > > > > arch/powerpc/dts/mpc8548-post.dtsi | 27 + > > > > arch/powerpc/dts/mpc8548.dtsi| 27 + > > > > arch/powerpc/dts/mpc8548cds.dts | 23 + > > > > arch/powerpc/dts/mpc8548cds_36b.dts | 23 + > > > > arch/powerpc/dts/p1020-post.dtsi | 27 + > > > > arch/powerpc/dts/p1020.dtsi | 31 ++ > > > > arch/powerpc/dts/p1020rdb-pc.dts | 23 + > > > > arch/powerpc/dts/p1020rdb-pc_36b.dts | 23 + > > > > arch/powerpc/dts/p1020rdb-pd.dts | 23 + > > > > arch/powerpc/dts/p2020-post.dtsi | 27 + > > > > arch/powerpc/dts/p2020.dtsi | 31 ++ > > > > arch/powerpc/dts/p2020rdb-pc.dts | 23 + > > > > arch/powerpc/dts/p2020rdb-pc_36b.dts | 23 + > > > > arch/powerpc/dts/p2041.dtsi | 63 > > > > > arch/powerpc/dts/p2041rdb.dts| 18 > > > > arch/powerpc/dts/p3041.dtsi | 63 > > > > > arch/powerpc/dts/p3041ds.dts | 18 > > > > arch/powerpc/dts/p4080.dtsi | 83 > > > +++ > > > > arch/powerpc/dts/p4080ds.dts | 18 > > > > arch/powerpc/dts/p5040.dtsi | 62 > +++ > > > > arch/powerpc/dts/p5040ds.dts | 18 > > > > arch/powerpc/dts/t1024rdb.dts| 17 > > > > arch/powerpc/dts/t102x.dtsi | 52 > ++ > > > > arch/powerpc/dts/t1042d4rdb.dts | 17 > > > > arch/powerpc/dts/t104x.dtsi | 62 > +++ > > > > arch/powerpc/dts/t2080rdb.dts| 17 > > > > arch/powerpc/dts/t4240.dtsi | 102 > > > +++ > > > > arch/powerpc/dts/t4240rdb.dts| 17 > > > > arch/powerpc/dts/u-boot.dtsi | 3 + > > > > board/freescale/p1_p2_rdb_pc/README | 19 > > > > board/freescale/p2041rdb/README | 18 > > > > board/freescale/t102xrdb/README | 19 > > > > board/freescale/t104xrdb/README | 19 > > > > board/freescale/t208xrdb/README
Re: [U-Boot] [PATCH 00/13] powerpc: Enable device tree support
Hi Jagdish, Thanks a lot for your comments! > -Original Message- > From: Jagdish Gediya > Sent: 2019年8月16日 16:26 > To: Z.q. Hou ; u-boot@lists.denx.de; > s...@chromium.org; Prabhakar Kushwaha ; > Shengzhou Liu ; bmeng...@gmail.com; Jiafei Pan > ; Priyanka Jain > Subject: RE: [PATCH 00/13] powerpc: Enable device tree support > > Hi Zhiqiang, > > > -Original Message- > > From: Z.q. Hou > > Sent: Friday, August 16, 2019 11:58 AM > > To: Jagdish Gediya ; u-boot@lists.denx.de; > > s...@chromium.org; Prabhakar Kushwaha > ; > > Shengzhou Liu ; bmeng...@gmail.com; Jiafei > Pan > > ; Priyanka Jain > > Subject: RE: [PATCH 00/13] powerpc: Enable device tree support > > > > Hi Jagdish, > > > > Thanks a lot for your comments! > > > > > -Original Message- > > > From: Jagdish Gediya > > > Sent: 2019年8月16日 14:05 > > > To: Z.q. Hou ; u-boot@lists.denx.de; > > > s...@chromium.org; Prabhakar Kushwaha > > ; > > > Shengzhou Liu ; bmeng...@gmail.com; Jiafei > > Pan > > > ; Priyanka Jain > > > Subject: RE: [PATCH 00/13] powerpc: Enable device tree support > > > > > > Hi Zhiqiang, > > > > > > > -Original Message- > > > > From: Z.q. Hou > > > > Sent: Thursday, June 20, 2019 1:49 PM > > > > To: u-boot@lists.denx.de; s...@chromium.org; Prabhakar Kushwaha > > > > ; Shengzhou Liu > > > ; > > > > bmeng...@gmail.com; Jagdish Gediya ; > > > > Jiafei Pan ; Priyanka Jain > > > > > > > > Cc: Z.q. Hou > > > > Subject: [PATCH 00/13] powerpc: Enable device tree support > > > > > > > > From: Hou Zhiqiang > > > > > > > > This patch is to enable device tree support for the Freescale > > > > PowerPC platforms below. > > > > > > > > Hou Zhiqiang (13): > > > > powerpc: Enable device tree support for T2080RDB > > > > powerpc: Enable device tree support for T4240RDB > > > > powerpc: Enable device tree support for T1024RDB > > > > powerpc: Enable device tree support for T1042D4RDB > > > > powerpc: Enable device tree support for P1020RDB > > > > powerpc: Enable device tree support for P2020RDB > > > > powerpc: Enable device tree support for P2041RDB > > > > powerpc: Enable device tree support for P3041DS > > > > powerpc: Enable device tree support for P4080DS > > > > powerpc: Enable device tree support for P5040DS > > > > powerpc: dts: add default definition of > > > CONFIG_RESET_VECTOR_ADDRESS > > > > powerpc: mpc8548cds: extend the reserved length for monitor > > > > powerpc: Enable device tree support for MPC8548CDS > > > > > > > > arch/powerpc/dts/Makefile| 12 +++ > > > > arch/powerpc/dts/e500mc_power_isa.dtsi | 33 ++ > > > > arch/powerpc/dts/e500v2_power_isa.dtsi | 26 + > > > > arch/powerpc/dts/e5500_power_isa.dtsi| 34 +++ > > > > arch/powerpc/dts/mpc8548-post.dtsi | 27 + > > > > arch/powerpc/dts/mpc8548.dtsi| 27 + > > > > arch/powerpc/dts/mpc8548cds.dts | 23 + > > > > arch/powerpc/dts/mpc8548cds_36b.dts | 23 + > > > > arch/powerpc/dts/p1020-post.dtsi | 27 + > > > > arch/powerpc/dts/p1020.dtsi | 31 ++ > > > > arch/powerpc/dts/p1020rdb-pc.dts | 23 + > > > > arch/powerpc/dts/p1020rdb-pc_36b.dts | 23 + > > > > arch/powerpc/dts/p1020rdb-pd.dts | 23 + > > > > arch/powerpc/dts/p2020-post.dtsi | 27 + > > > > arch/powerpc/dts/p2020.dtsi | 31 ++ > > > > arch/powerpc/dts/p2020rdb-pc.dts | 23 + > > > > arch/powerpc/dts/p2020rdb-pc_36b.dts | 23 + > > > > arch/powerpc/dts/p2041.dtsi | 63 > > > > > arch/powerpc/dts/p2041rdb.dts| 18 > > > > arch/powerpc/dts/p3041.dtsi | 63 > > > > > arch/powerpc/dts/p3041ds.dts | 18 > > > > arch/powerpc/dts/p4080.dtsi | 83 > > > +++ > > > > arch/powerpc/dts/p4080ds.dts | 18 > > > > arch/powerpc/dts/p5040.dtsi | 62 > +++ > > > > arch/powerpc/dts/p5040ds.dts | 18 > > > > arch/powerpc/dts/t1024rdb.dts| 17 > > > > arch/powerpc/dts/t102x.dtsi | 52 > ++ > > > > arch/powerpc/dts/t1042d4rdb.dts | 17 > > > > arch/powerpc/dts/t104x.dtsi | 62 > +++ > > > > arch/powerpc/dts/t2080rdb.dts| 17 > > > > arch/powerpc/dts/t4240.dtsi | 102 > > > +++ > > > > arch/powerpc/dts/t4240rdb.dts| 17 > > > > arch/powerpc/dts/u-boot.dtsi | 3 + > > > > board/freescale/p1_p2_rdb_pc/README | 19 > > > > board/freescale/p2041rdb/README | 18 > > > > board/freescale/t102xrdb/README | 19 > > > > board/freescale/t104xrdb/README | 19 >
Re: [U-Boot] [PATCH 5/6] arm: socfpga: gen5: add readonly clk driver
Marek Vasut schrieb am Fr., 16. Aug. 2019, 13:09: > On 8/15/19 7:42 PM, Simon Goldschmidt wrote: > > Am 15.08.2019 um 19:07 schrieb Marek Vasut: > >> On 8/15/19 6:57 PM, Simon Goldschmidt wrote: > >>> Am 15.08.2019 um 18:34 schrieb Marek Vasut: > On 8/15/19 6:22 PM, Simon Goldschmidt wrote: > > Hi Marek, > > > > Am 24.07.2019 um 09:45 schrieb Simon Goldschmidt: > >> On Wed, Jul 24, 2019 at 9:31 AM Marek Vasut wrote: > >>> > >>> On 7/23/19 10:27 PM, Simon Goldschmidt wrote: > This adds clk-gen5 as a readonly DM_CLK driver that can return > clocks for > the peripherals. > > Further changes are: > - select DM_CLK for gen5 U-Boot and SPL > - add SPL tags to clock nodes in socfpga-common-u-boot.dtsi > - adjust socfpga.dtsi to provide missing src selection registers > - start 'handoff.dtsi' file for socrates (conatains clock speeds > for > now) > >>> > >>> These should likely be separate patches then ? > >> > >> Well, in the end, yes. Especially the handoff.dtsi is required for > >> *all* > >> socfpga_gen5 boards, so I'll need to adapt the 'qts-filter.sh' > >> script to > >> generate it. > >> > >> I'll change that script and separate these patches in v2. > > > > I'm in the process of moving all of the 'qts' header files to > > devicetree > > handoff.dtsi files. CLK and DDR are already working (pinmux/iocsr not > > yet) - but I need to work a bit on DM memory consumption. > > > > So now I'm faced with a question: in which driver do I implement the > > pinmux control? From a DM point of view, it could be a UCLASS_PINCTRL > > driver in 'drivers/pinctrl', but since it's more or less read-only > > unless we'd get more details about the hardware, I'm a bit > > hesistant to > > do it that way. > > > > Also, the registers are in 'sysmgr', which is handled by the standard > > "syscon" driver right now, so it could well get a UCLASS_SYSCON > > driver? > > What do we need read-only pinmux driver for ? I would expect pinmux to > be more write-only, from the hardware perspective that is. > >>> > >>> Well, I don't know. I just need a driver that can parse its dts subtree > >>> for the config instead of loading from the qts wrapper file. Then this > >>> driver needs to be probed at the appropriate place in SPL so that the > >>> pins are initialized. > >> > >> Sounds more like misc driver or something along those lines. > > > > Hmm, probing UCLASS_MISC in SPL to get the pinmux initializes sounds a > > bit strange, but that's probably OK. > > Well it's kinda pinmux, but not really. It's not like you can specify, > in DT, how to program a pin or a range of pins either. But maybe PINCTRL > uclass with some really rudimentary driver is OK. > > I am not sure myself to be honest. > > >>> My future plan is then that such a driver could be re-probed after > >>> loading some kind of dts overlay matching an FPGA image to be > programmed > >>> (as that FPGA image can contain different pin settings, e.g. when using > >>> loan IO). > >> > >> But then it becomes a PINMUX driver. > > > > Well, what I'm writing *is* a writeonly driver controlling the pins. > > However, since we don't know anything about the iocsr part, we can't > > implement all the functions in 'struct pinctrl_ops' (just write the > > given scan chain and that's it). I think PINMUX would fit best, but see > > below... > > Go for it then :) > > >>> I'm just not familiar enough with pinctrl drivers or syscon drivers and > >>> could need some input on which direction to take this... > >>> > >>> Does a syscon driver for that purpose sound better? > >> > >> Isn't syscon driver for system controllers, which provide e.g. regmaps > >> to subdevices ? I think the altera pinmux shouldn't be syscon. > > > > The thing is that 'sysmgr' already *is* a syscon driver: it provides > > access to various control bits (e.g. used by the ethernet driver in > > Linux) but also pinmux registers. > > Maybe you can have a pinctrl driver that is a consumer of the syscon > interface ? > Right, I'll add such a pinctrl as a driver for the scanmgr (which is not yet present in the devicetree) which will use the sysmgr pins via syscon. Thanks for sharing your thoughts on this! Regards, Simon > > Of course, I could add "scanmgr@0xfff02000" as a new node in the > > devicetree that would be the PINMUX driver which accesses the pinmux > > registers in sysmgr via sysycon... That would keep sysmgr's syscon > > behaviour working (for other drivers). > > > > Regards, > > Simon > > > > > -- > Best regards, > Marek Vasut > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 1/4] USB: gadget: Add the cadence USB3 gadget driver
This driver is ported from NXP i.MX U-Boot version imx_v2019.04
and some changes have also been made to adapt to U-Boot.
Add the Cadence USB3 IP(CDNS3) driver for the gadget (device mode).
The CDNS3 gadget driver support DM mode. CONFIG_DM_USB_GADGET should
be enabled when use this driver.
Signed-off-by: Sherry Sun
---
Makefile |1 +
doc/device-tree-bindings/usb/cdns-usb3.txt | 39 +
drivers/usb/Kconfig|2 +
drivers/usb/cdns3/Kconfig | 20 +
drivers/usb/cdns3/Makefile |5 +
drivers/usb/cdns3/cdns3-generic.c | 115 +
drivers/usb/cdns3/cdns3-nxp-reg-def.h | 89 +
drivers/usb/cdns3/core.c | 194 ++
drivers/usb/cdns3/core.h | 118 ++
drivers/usb/cdns3/dev-regs-macro.h | 116 +
drivers/usb/cdns3/dev-regs-map.h | 117 ++
drivers/usb/cdns3/gadget-export.h | 26 +
drivers/usb/cdns3/gadget.c | 2218
drivers/usb/cdns3/gadget.h | 225 ++
drivers/usb/cdns3/io.h | 30 +
drivers/usb/gadget/epautoconf.c|4 +
drivers/usb/gadget/gadget_chips.h |7 +
drivers/usb/gadget/udc/Makefile|1 +
include/linux/usb/gadget.h |3 +
scripts/Makefile.spl |1 +
20 files changed, 3331 insertions(+)
create mode 100644 doc/device-tree-bindings/usb/cdns-usb3.txt
create mode 100644 drivers/usb/cdns3/Kconfig
create mode 100644 drivers/usb/cdns3/Makefile
create mode 100644 drivers/usb/cdns3/cdns3-generic.c
create mode 100644 drivers/usb/cdns3/cdns3-nxp-reg-def.h
create mode 100644 drivers/usb/cdns3/core.c
create mode 100644 drivers/usb/cdns3/core.h
create mode 100644 drivers/usb/cdns3/dev-regs-macro.h
create mode 100644 drivers/usb/cdns3/dev-regs-map.h
create mode 100644 drivers/usb/cdns3/gadget-export.h
create mode 100644 drivers/usb/cdns3/gadget.c
create mode 100644 drivers/usb/cdns3/gadget.h
create mode 100644 drivers/usb/cdns3/io.h
diff --git a/Makefile b/Makefile
index 8513db94e3..fab1220114 100644
--- a/Makefile
+++ b/Makefile
@@ -728,6 +728,7 @@ libs-$(CONFIG_SYS_FSL_DDR) += drivers/ddr/fsl/
libs-$(CONFIG_SYS_FSL_MMDC) += drivers/ddr/fsl/
libs-$(CONFIG_$(SPL_)ALTERA_SDRAM) += drivers/ddr/altera/
libs-y += drivers/serial/
+libs-y += drivers/usb/cdns3/
libs-y += drivers/usb/dwc3/
libs-y += drivers/usb/common/
libs-y += drivers/usb/emul/
diff --git a/doc/device-tree-bindings/usb/cdns-usb3.txt
b/doc/device-tree-bindings/usb/cdns-usb3.txt
new file mode 100644
index 00..0c8710507d
--- /dev/null
+++ b/doc/device-tree-bindings/usb/cdns-usb3.txt
@@ -0,0 +1,39 @@
+* Cadence USB3 Controller
+
+Required properties:
+- compatible: "cdns,usb3";
+- reg: base address and length of the registers
+- interrupts: interrupt for the USB controller
+- interrupt-parent: the interrupt parent for this module
+- clocks: reference to the USB clock
+- clock-names: the name of clocks
+- phys: reference to the USB PHY
+
+Optional properties:
+- dr_mode: One of "host", "peripheral" or "otg". Defaults to "otg"
+- extcon: extcon phandler for cdns3 device
+- power-domains: the power domain for cdns3 controller and phy
+
+Examples:
+
+usbotg3: cdns3@5b11 {
+ compatible = "cdns,usb3";
+ reg = <0x0 0x5B11 0x0 0x1>,
+ <0x0 0x5B13 0x0 0x1>,
+ <0x0 0x5B14 0x0 0x1>,
+ <0x0 0x5B16 0x0 0x4>;
+ interrupt-parent = <>;
+ interrupts = ;
+ clocks = < IMX8QM_USB3_LPM_CLK>,
+ < IMX8QM_USB3_BUS_CLK>,
+ < IMX8QM_USB3_ACLK>,
+ < IMX8QM_USB3_IPG_CLK>,
+ < IMX8QM_USB3_CORE_PCLK>;
+ clock-names = "usb3_lpm_clk", "usb3_bus_clk", "usb3_aclk",
+ "usb3_ipg_clk", "usb3_core_pclk";
+ power-domains = <_conn_usb2>;
+ phys = <>;
+ dr_mode = "otg";
+ extcon = <_ptn5150>;
+ status = "disabled";
+};
diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig
index 3b53bf2c58..98f5e936e5 100644
--- a/drivers/usb/Kconfig
+++ b/drivers/usb/Kconfig
@@ -70,6 +70,8 @@ source "drivers/usb/host/Kconfig"
source "drivers/usb/dwc3/Kconfig"
+source "drivers/usb/cdns3/Kconfig"
+
source "drivers/usb/musb/Kconfig"
source "drivers/usb/musb-new/Kconfig"
diff --git a/drivers/usb/cdns3/Kconfig b/drivers/usb/cdns3/Kconfig
new file mode 100644
index 00..11a7144b05
--- /dev/null
+++ b/drivers/usb/cdns3/Kconfig
@@ -0,0 +1,20 @@
+config USB_CDNS3
+ tristate "Cadence USB3 Dual-Role Controller"
+depends on (USB && USB_GADGET)
+ help
+ Say Y here if your system has a cadence USB3 dual-role controller.
+ It supports: dual-role switch Host-only, and Peripheral-only.
+
+ When compiled dynamically, the module will be called cdns3.ko.
+
+if USB_CDNS3
+
+config USB_CDNS3_GADGET
+ bool
Re: [U-Boot] [PATCH v2] board: fsl: lx2160a: implement board_fix_fdt
Dear Pankaj > -Original Message- > From: Pankaj Bansal > Sent: Wednesday, July 17, 2019 3:54 PM > To: Prabhakar Kushwaha ; Meenakshi > Aggarwal > Cc: Varun Sethi ; u-boot@lists.denx.de > Subject: [PATCH v2] board: fsl: lx2160a: implement board_fix_fdt > > In lx2160a rev2 the pcie controller has been changed. > Therefore, we need to change the device tree nodes of pcie controllers so that > new controller can be probed. > It involves changing the "compatible" field as well as registers names'. > we are keeping same device tree for lx2160a rev1 and rev2, therefore we > change the device tree nodes as part of fdt fixups. > These changes would only be applied if the soc revision is not rev1. > > Signed-off-by: Pankaj Bansal > --- > > Notes: > V2: > - explained the patch requirements and patch changes. > > board/freescale/lx2160a/lx2160a.c | 67 + > configs/lx2160aqds_tfa_defconfig | 1 + configs/lx2160ardb_tfa_defconfig | > 1 > + I am seeing compilation warning with your patch. Please fix it --pk board/freescale/lx2160a/lx2160a.c: In function 'board_fix_fdt': board/freescale/lx2160a/lx2160a.c:143:13: warning: assignment discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers] reg_names = fdt_getprop(fdt, off, "reg-names", _len); ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 2/4] USB: host: Add the USB3 host driver
On 8/16/19 8:10 AM, Sherry Sun wrote:
[...]
> diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
> index ac68aa2d27..cc1dfe463b 100644
> --- a/drivers/usb/host/Kconfig
> +++ b/drivers/usb/host/Kconfig
> @@ -95,6 +95,15 @@ config USB_XHCI_FSL
> depends on !SPL_NO_USB
> help
> Enables support for the on-chip xHCI controller on NXP Layerscape
> SoCs.
> +
> +config USB_XHCI_IMX8
> + bool "XHCI support for imx8"
i.MX8 I guess ?
[...]
> diff --git a/drivers/usb/host/xhci-imx8.c b/drivers/usb/host/xhci-imx8.c
> new file mode 100644
> index 00..0669a05c17
> --- /dev/null
> +++ b/drivers/usb/host/xhci-imx8.c
> @@ -0,0 +1,189 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright 2019 NXP
> + *
> + * NXP i.MX8 USB HOST xHCI Controller (Cadence IP)
> + *
> + * Author: Peter Chen
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
Keep the list sorted
> +#include "xhci.h"
> +
> +/* Declare global data pointer */
> +DECLARE_GLOBAL_DATA_PTR;
> +
> +/* Host registers */
> +#define HCIVERSION_CAPLENGTH 0x1
> +#define USBSTS0x10084
> +
> +/* None-core registers */
> +#define USB3_CORE_CTRL10x00
> +#define USB3_CORE_STATUS 0x0c
> +#define USB3_SSPHY_STATUS 0x4c
> +
> +struct xhci_imx8_data {
> + void __iomem *usb3_ctrl_base;
> + void __iomem *usb3_core_base;
> + struct clk_bulk clks;
> + struct phy phy;
> +};
> +
> +static struct xhci_imx8_data imx8_data;
> +
> +static void imx8_xhci_init(void)
> +{
> + u32 tmp_data;
> + int ret;
> +
> + tmp_data = readl(imx8_data.usb3_ctrl_base + USB3_SSPHY_STATUS);
> + writel(tmp_data, imx8_data.usb3_ctrl_base + USB3_SSPHY_STATUS);
Is this read-write really needed ?
> + tmp_data = readl(imx8_data.usb3_ctrl_base + USB3_SSPHY_STATUS);
> + ret = wait_for_bit_le32(imx8_data.usb3_ctrl_base + USB3_SSPHY_STATUS,
> + 0xf000, true, 100, false);
> + if (ret)
> + printf("clkvld is incorrect\n");
Shouldn't this return ret ?
> + clrsetbits_le32(imx8_data.usb3_ctrl_base + USB3_CORE_CTRL1,
> + 0x7, 0x202);
> + clrbits_le32(imx8_data.usb3_ctrl_base + USB3_CORE_CTRL1, 1 << 26);
> + generic_phy_init(_data.phy);
> +
> + /* clear all sw_rst */
> + clrbits_le32(imx8_data.usb3_ctrl_base + USB3_CORE_CTRL1, 0xFC << 24);
> +
> + debug("wait xhci_power_on_ready\n");
> + ret = wait_for_bit_le32(imx8_data.usb3_ctrl_base + USB3_CORE_STATUS,
> + 0x1000, true, 100, false);
> + if (ret)
> + printf("wait xhci_power_on_ready timeout\n");
return ret on failure ?
> + debug("xhci_power_on_ready\n");
> +
> + debug("waiting CNR 0x%x\n", tmp_data);
> + ret = wait_for_bit_le32(imx8_data.usb3_core_base + USBSTS,
> + 0x800, false, 100, false);
> + if (ret)
> + printf("wait CNR timeout\n");
return ret on failure ?
> + debug("check CNR has finished\n");
> +}
> +
> +static void imx8_xhci_reset(void)
> +{
> + /* Set CORE ctrl to default value, that all rst are hold */
> + writel(0xfc01, imx8_data.usb3_ctrl_base + USB3_CORE_CTRL1);
What are these magic values ? Add macros for them.
> +}
> +
> +static int xhci_imx8_clk_init(struct udevice *dev)
> +{
> + int ret;
> +
> + ret = clk_get_bulk(dev, _data.clks);
> + if (ret)
> + return ret;
> +
> + ret = clk_enable_bulk(_data.clks);
> + if (ret)
> + return ret;
> +
> + return 0;
> +}
> +
> +static int xhci_imx8_get_reg_addr(struct udevice *dev)
> +{
> + imx8_data.usb3_ctrl_base =
> + (void __iomem *)devfdt_get_addr_index(dev, 0);
> + imx8_data.usb3_core_base =
> + (void __iomem *)devfdt_get_addr_index(dev, 4);
> +
> + return 0;
> +}
> +
> +static int xhci_imx8_probe(struct udevice *dev)
> +{
> + struct xhci_hccr *hccr;
> + struct xhci_hcor *hcor;
> + struct udevice usbotg_dev;
> + struct power_domain pd;
> + int usbotg_off;
> + int ret = 0;
> + int len;
> +
> + usbotg_off = fdtdec_lookup_phandle(gd->fdt_blob,
> +dev_of_offset(dev),
> +"cdns3,usb");
> + if (usbotg_off < 0)
> + return -EINVAL;
> + usbotg_dev.node = offset_to_ofnode(usbotg_off);
> + usbotg_dev.parent = dev->parent;
> + xhci_imx8_get_reg_addr(_dev);
> +
> +#if CONFIG_IS_ENABLED(POWER_DOMAIN)
> + if (!power_domain_get(_dev, )) {
> + if (power_domain_on())
> + return -EINVAL;
ret = power_domain_on()
if (ret)
return ret;
[...]
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 5/6] arm: socfpga: gen5: add readonly clk driver
On 8/15/19 7:42 PM, Simon Goldschmidt wrote: > Am 15.08.2019 um 19:07 schrieb Marek Vasut: >> On 8/15/19 6:57 PM, Simon Goldschmidt wrote: >>> Am 15.08.2019 um 18:34 schrieb Marek Vasut: On 8/15/19 6:22 PM, Simon Goldschmidt wrote: > Hi Marek, > > Am 24.07.2019 um 09:45 schrieb Simon Goldschmidt: >> On Wed, Jul 24, 2019 at 9:31 AM Marek Vasut wrote: >>> >>> On 7/23/19 10:27 PM, Simon Goldschmidt wrote: This adds clk-gen5 as a readonly DM_CLK driver that can return clocks for the peripherals. Further changes are: - select DM_CLK for gen5 U-Boot and SPL - add SPL tags to clock nodes in socfpga-common-u-boot.dtsi - adjust socfpga.dtsi to provide missing src selection registers - start 'handoff.dtsi' file for socrates (conatains clock speeds for now) >>> >>> These should likely be separate patches then ? >> >> Well, in the end, yes. Especially the handoff.dtsi is required for >> *all* >> socfpga_gen5 boards, so I'll need to adapt the 'qts-filter.sh' >> script to >> generate it. >> >> I'll change that script and separate these patches in v2. > > I'm in the process of moving all of the 'qts' header files to > devicetree > handoff.dtsi files. CLK and DDR are already working (pinmux/iocsr not > yet) - but I need to work a bit on DM memory consumption. > > So now I'm faced with a question: in which driver do I implement the > pinmux control? From a DM point of view, it could be a UCLASS_PINCTRL > driver in 'drivers/pinctrl', but since it's more or less read-only > unless we'd get more details about the hardware, I'm a bit > hesistant to > do it that way. > > Also, the registers are in 'sysmgr', which is handled by the standard > "syscon" driver right now, so it could well get a UCLASS_SYSCON > driver? What do we need read-only pinmux driver for ? I would expect pinmux to be more write-only, from the hardware perspective that is. >>> >>> Well, I don't know. I just need a driver that can parse its dts subtree >>> for the config instead of loading from the qts wrapper file. Then this >>> driver needs to be probed at the appropriate place in SPL so that the >>> pins are initialized. >> >> Sounds more like misc driver or something along those lines. > > Hmm, probing UCLASS_MISC in SPL to get the pinmux initializes sounds a > bit strange, but that's probably OK. Well it's kinda pinmux, but not really. It's not like you can specify, in DT, how to program a pin or a range of pins either. But maybe PINCTRL uclass with some really rudimentary driver is OK. I am not sure myself to be honest. >>> My future plan is then that such a driver could be re-probed after >>> loading some kind of dts overlay matching an FPGA image to be programmed >>> (as that FPGA image can contain different pin settings, e.g. when using >>> loan IO). >> >> But then it becomes a PINMUX driver. > > Well, what I'm writing *is* a writeonly driver controlling the pins. > However, since we don't know anything about the iocsr part, we can't > implement all the functions in 'struct pinctrl_ops' (just write the > given scan chain and that's it). I think PINMUX would fit best, but see > below... Go for it then :) >>> I'm just not familiar enough with pinctrl drivers or syscon drivers and >>> could need some input on which direction to take this... >>> >>> Does a syscon driver for that purpose sound better? >> >> Isn't syscon driver for system controllers, which provide e.g. regmaps >> to subdevices ? I think the altera pinmux shouldn't be syscon. > > The thing is that 'sysmgr' already *is* a syscon driver: it provides > access to various control bits (e.g. used by the ethernet driver in > Linux) but also pinmux registers. Maybe you can have a pinctrl driver that is a consumer of the syscon interface ? > Of course, I could add "scanmgr@0xfff02000" as a new node in the > devicetree that would be the PINMUX driver which accesses the pinmux > registers in sysmgr via sysycon... That would keep sysmgr's syscon > behaviour working (for other drivers). > > Regards, > Simon > -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] 答复: [PATCH v2 1/4] USB: gadget: Add the cadence USB3 gadget driver
On 8/16/19 6:45 AM, Sherry Sun wrote: > Hi Marek > >> >> On 8/14/19 2:16 PM, sherry sun wrote: >>> From: Sherry Sun >>> >>> This driver is ported from NXP i.MX U-Boot version imx_v2019.04 and >>> some changes have also been made to adapt to U-Boot. >>> >>> Add the Cadence USB3 IP(CDNS3) driver for the gadget (device mode). >>> The CDNS3 gadget driver support DM mode. CONFIG_DM_USB_GADGET >> should >>> be enabled when use this driver. And gadget_is_cdns3 checking is added >>> to provide bcdUSB value in device descriptor. >> >> The cadence core isn't xhci compatible ? Sigh ... >> > > Actually, I'm not very understand what the xhci compatible means? > The cadence core can support usb peripheral and host. But for now, > we just done the gadget part in the core code. If it needed later, we > can add the host part to it. So this is all needed to support gadget on the cadence3 ? ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] libavb: Update libavb to current AOSP master
On Fri, Aug 16, 2019 at 01:59:20PM +0300, Sam Protsenko wrote: [..] > On Fri, Aug 16, 2019 at 1:36 PM Eugeniu Rosca wrote: > > Thanks for the efforts. I get the same result, except the following > > minor difference [*]. The diff is minor and non-functional, but I > > think it's worth staying closer to AOSP. > > I've used most recent commit on master branch of external/avb project > of AOSP, and I can see that avb_div_by_10() is sitting in the end of > file: [1]. Not sure why you have different result... Are you looking > to different branch/commit perhaps? > > [1] > https://android.googlesource.com/platform/external/avb/+/5fbb42a189aabb9a0bb5c3a8df89c9baf828a0d1/libavb/avb_sysdeps_posix.c#84 Small amendment. Since I effectively cherry picked the AOSP commits from AVB into U-Boot (as described in [2]), my result left the avb_div_by_10() function *in place* (as none of the imported AOSP commits does any change to this function). That led to the mismatch between our results. IOW what this patch appears to do *in addition* to importing the list of AOSP commits mentioned in [2] is repositioning the avb_div_by_10() such that it matches the AOSP. I obviously have no concerns about that. [2] https://patchwork.ozlabs.org/patch/1144801/#2235834 Having said that: Reviewed-by: Eugeniu Rosca Thanks! -- Best Regards, Eugeniu. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] libavb: Update libavb to current AOSP master
Hi Eugeniu,
On Fri, Aug 16, 2019 at 1:36 PM Eugeniu Rosca wrote:
>
> Hi Sam,
>
> On Thu, Aug 15, 2019 at 11:04:02PM +0300, Sam Protsenko wrote:
> > Update libavb to commit 5fbb42a189aa in AOSP/master, because new version
> > has support for super partition [1], which we need for implementing
> > Android dynamic partitions. All changes from previous patches for libavb
> > in U-Boot are accounted for in this commit:
> > - commit ecc6f6bea6a2 ("libavb: Handle wrong hashtree_error_mode in
> > avb_append_options()")
> > - commit 897a1d947e7e ("libavb: Update SPDX tag style")
> > - commit d8f9d2af96b3 ("avb2.0: add Android Verified Boot 2.0 library")
> >
> > Tested on X15:
> >
> > ## Android Verified Boot 2.0 version 1.1.0
> > read_is_device_unlocked not supported yet
> > read_rollback_index not supported yet
> > read_is_device_unlocked not supported yet
> > Verification passed successfully
> > AVB verification OK.
> >
> > Unit test passes:
> >
> > $ ./test/py/test.py --bd sandbox --build -k test_avb
> >
> > test/py/tests/test_android/test_avb.py ss..s.
> >
> > [1]
> > https://android.googlesource.com/platform/external/avb/+/49936b4c0109411fdd38bd4ba3a32a01c40439a9
> >
> > Signed-off-by: Sam Protsenko
>
> Thanks for the efforts. I get the same result, except the following
> minor difference [*]. The diff is minor and non-functional, but I
> think it's worth staying closer to AOSP.
>
I've used most recent commit on master branch of external/avb project
of AOSP, and I can see that avb_div_by_10() is sitting in the end of
file: [1]. Not sure why you have different result... Are you looking
to different branch/commit perhaps?
[1]
https://android.googlesource.com/platform/external/avb/+/5fbb42a189aabb9a0bb5c3a8df89c9baf828a0d1/libavb/avb_sysdeps_posix.c#84
> I will post my Reviewed-by signature, once this is addressed. TIA.
>
> [*] diff --git a/lib/libavb/avb_sysdeps_posix.c
> b/lib/libavb/avb_sysdeps_posix.c
> index 4ccf41e42834..74a37a949496 100644
> --- a/lib/libavb/avb_sysdeps_posix.c
> +++ b/lib/libavb/avb_sysdeps_posix.c
> @@ -32,6 +32,12 @@ size_t avb_strlen(const char* str) {
>return strlen(str);
> }
>
> +uint32_t avb_div_by_10(uint64_t* dividend) {
> + uint32_t rem = (uint32_t)(*dividend % 10);
> + *dividend /= 10;
> + return rem;
> +}
> +
> void avb_abort(void) {
>hang();
> }
> @@ -58,9 +64,3 @@ void* avb_malloc_(size_t size) {
> void avb_free(void* ptr) {
>free(ptr);
> }
> -
> -uint32_t avb_div_by_10(uint64_t* dividend) {
> - uint32_t rem = (uint32_t)(*dividend % 10);
> - *dividend /= 10;
> - return rem;
> -}
>
> --
> Best Regards,
> Eugeniu.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] arm: dts: Makefile: clean *dtb_HS
On 16/08/19 2:16 PM, suni...@techveda.org wrote: > From: Suniel Mahesh > > TI HS platforms generate *dtb_HS binary blobs and there is no > rule for cleanup. Added entry for cleanup in clean-files target. > > Signed-off-by: Suniel Mahesh Reviewed-by: Lokesh Vutla Thanks and regards, Lokesh > --- > Changes for v2: > > - changed description to fit the change done. > - As suggested by Lokesh Vutla, moved cleaning process > to dts/Makefile > --- > arch/arm/dts/Makefile | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile > index e021888..5f4e05d 100644 > --- a/arch/arm/dts/Makefile > +++ b/arch/arm/dts/Makefile > @@ -806,4 +806,4 @@ PHONY += dtbs > dtbs: $(addprefix $(obj)/, $(dtb-y)) > @: > > -clean-files := *.dtb > +clean-files := *.dtb *_HS > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] libavb: Update libavb to current AOSP master
Hi Sam,
On Thu, Aug 15, 2019 at 11:04:02PM +0300, Sam Protsenko wrote:
> Update libavb to commit 5fbb42a189aa in AOSP/master, because new version
> has support for super partition [1], which we need for implementing
> Android dynamic partitions. All changes from previous patches for libavb
> in U-Boot are accounted for in this commit:
> - commit ecc6f6bea6a2 ("libavb: Handle wrong hashtree_error_mode in
> avb_append_options()")
> - commit 897a1d947e7e ("libavb: Update SPDX tag style")
> - commit d8f9d2af96b3 ("avb2.0: add Android Verified Boot 2.0 library")
>
> Tested on X15:
>
> ## Android Verified Boot 2.0 version 1.1.0
> read_is_device_unlocked not supported yet
> read_rollback_index not supported yet
> read_is_device_unlocked not supported yet
> Verification passed successfully
> AVB verification OK.
>
> Unit test passes:
>
> $ ./test/py/test.py --bd sandbox --build -k test_avb
>
> test/py/tests/test_android/test_avb.py ss..s.
>
> [1]
> https://android.googlesource.com/platform/external/avb/+/49936b4c0109411fdd38bd4ba3a32a01c40439a9
>
> Signed-off-by: Sam Protsenko
Thanks for the efforts. I get the same result, except the following
minor difference [*]. The diff is minor and non-functional, but I
think it's worth staying closer to AOSP.
I will post my Reviewed-by signature, once this is addressed. TIA.
[*] diff --git a/lib/libavb/avb_sysdeps_posix.c b/lib/libavb/avb_sysdeps_posix.c
index 4ccf41e42834..74a37a949496 100644
--- a/lib/libavb/avb_sysdeps_posix.c
+++ b/lib/libavb/avb_sysdeps_posix.c
@@ -32,6 +32,12 @@ size_t avb_strlen(const char* str) {
return strlen(str);
}
+uint32_t avb_div_by_10(uint64_t* dividend) {
+ uint32_t rem = (uint32_t)(*dividend % 10);
+ *dividend /= 10;
+ return rem;
+}
+
void avb_abort(void) {
hang();
}
@@ -58,9 +64,3 @@ void* avb_malloc_(size_t size) {
void avb_free(void* ptr) {
free(ptr);
}
-
-uint32_t avb_div_by_10(uint64_t* dividend) {
- uint32_t rem = (uint32_t)(*dividend % 10);
- *dividend /= 10;
- return rem;
-}
--
Best Regards,
Eugeniu.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH V2 3/4] clk: support clk tree dump
The previous code only dump the clk list. This patch is
to support clk tree dump, and also dump the enable_cnt.
The code used in patch is similar to dm_dump_all, but
the code here only filter out the UCLASS_CLK devices.
On i.MX8MM, Partial output:
u-boot=> clk dump
Rate Usecnt Name
--
2400 0|-- clock-osc-24m
2400 0| |-- dram_pll_ref_sel
750000| | `-- dram_pll
750000| | `-- dram_pll_bypass
750000| | `-- dram_pll_out
2400 0| |-- arm_pll_ref_sel
12 0| | `-- arm_pll
12 0| | `-- arm_pll_bypass
12 0| | `-- arm_pll_out
12 0| | `-- arm_a53_src
12 0| | `-- arm_a53_cg
12 0| | `-- arm_a53_div
2400 4| |-- sys_pll1_ref_sel
84| | `-- sys_pll1
84| | `-- sys_pll1_bypass
84| | `-- sys_pll1_out
4000 0| | |-- sys_pll1_40m
Signed-off-by: Peng Fan
---
V2:
Improve commit log
cmd/clk.c | 77 ---
1 file changed, 44 insertions(+), 33 deletions(-)
diff --git a/cmd/clk.c b/cmd/clk.c
index 5402c87de7..c0a64ff770 100644
--- a/cmd/clk.c
+++ b/cmd/clk.c
@@ -7,50 +7,61 @@
#include
#if defined(CONFIG_DM) && defined(CONFIG_CLK)
#include
+#include
+#include
#include
+#include
#endif
-int __weak soc_clk_dump(void)
+static void show_clks(struct udevice *dev, int depth, int last_flag)
{
-#if defined(CONFIG_DM) && defined(CONFIG_CLK)
- struct udevice *dev;
- struct uclass *uc;
- struct clk clk;
- int ret;
- ulong rate;
-
- /* Device addresses start at 1 */
- ret = uclass_get(UCLASS_CLK, );
- if (ret)
- return ret;
-
- uclass_foreach_dev(dev, uc) {
- memset(, 0, sizeof(clk));
- ret = device_probe(dev);
- if (ret)
- goto noclk;
+ int i, is_last;
+ struct udevice *child;
+ struct clk *clkp;
+ u32 rate;
+
+ clkp = dev_get_clk_ptr(dev);
+ if (device_get_uclass_id(dev) == UCLASS_CLK && clkp) {
+ rate = clk_get_rate(clkp);
+
+ printf(" %-12u %8d", rate, clkp->enable_count);
+
+ for (i = depth; i >= 0; i--) {
+ is_last = (last_flag >> i) & 1;
+ if (i) {
+ if (is_last)
+ printf("");
+ else
+ printf("| ");
+ } else {
+ if (is_last)
+ printf("`-- ");
+ else
+ printf("|-- ");
+ }
+ }
- ret = clk_request(dev, );
- if (ret)
- goto noclk;
+ printf("%s\n", dev->name);
+ }
- rate = clk_get_rate();
- clk_free();
+ list_for_each_entry(child, >child_head, sibling_node) {
+ is_last = list_is_last(>sibling_node, >child_head);
+ show_clks(child, depth + 1, (last_flag << 1) | is_last);
+ }
+}
- if (rate == -ENODEV)
- goto noclk;
+int __weak soc_clk_dump(void)
+{
+ struct udevice *root;
- printf("%-30.30s : %lu Hz\n", dev->name, rate);
- continue;
- noclk:
- printf("%-30.30s : ? Hz\n", dev->name);
+ root = dm_root();
+ if (root) {
+ printf(" Rate Usecnt Name\n");
+ printf("--\n");
+ show_clks(root, -1, 0);
}
return 0;
-#else
- puts("Not implemented\n");
- return 1;
-#endif
}
static int do_clk_dump(cmd_tbl_t *cmdtp, int flag, int argc,
--
2.16.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH V2 2/4] clk: prograte clk enable/disable to parent
On i.MX8MM, thinking such as clk path
OSC->PLL->PLL GATE->CCM ROOT->CCGR GATE->Device
Only enabling CCGR GATE is not enough, we also need to enable PLL GATE
to make sure the clk path work. So when enabling CCGR GATE,
we could prograte to enabling PLL GATE to make life easier.
Signed-off-by: Peng Fan
---
V2:
Improve commit log
Check enable_count when enable/disable to avoid touch hardware
following Linux
drivers/clk/clk-uclass.c | 77
1 file changed, 71 insertions(+), 6 deletions(-)
diff --git a/drivers/clk/clk-uclass.c b/drivers/clk/clk-uclass.c
index cee4d912b0..d083d43727 100644
--- a/drivers/clk/clk-uclass.c
+++ b/drivers/clk/clk-uclass.c
@@ -449,13 +449,45 @@ int clk_set_parent(struct clk *clk, struct clk *parent)
int clk_enable(struct clk *clk)
{
const struct clk_ops *ops = clk_dev_ops(clk->dev);
+ struct clk *clkp = NULL;
+ int ret;
debug("%s(clk=%p)\n", __func__, clk);
- if (!ops->enable)
- return -ENOSYS;
+ if (CONFIG_IS_ENABLED(CLK_CCF)) {
+ /* Take id 0 as a non-valid clk, such as dummy */
+ if (clk->id && !clk_get_by_id(clk->id, )) {
+ if (clkp->enable_count) {
+ clkp->enable_count++;
+ return 0;
+ }
+ if (clkp->dev->parent &&
+ device_get_uclass_id(clkp->dev) == UCLASS_CLK) {
+ ret =
clk_enable(dev_get_clk_ptr(clkp->dev->parent));
+ if (ret) {
+ printf("Enable %s failed\n",
+ clkp->dev->parent->name);
+ return ret;
+ }
+ }
+ }
- return ops->enable(clk);
+ if (ops->enable) {
+ ret = ops->enable(clk);
+ if (ret) {
+ printf("Enable %s failed\n", clk->dev->name);
+ return ret;
+ }
+ }
+ if (clkp)
+ clkp->enable_count++;
+ } else {
+ if (!ops->enable)
+ return -ENOSYS;
+ return ops->enable(clk);
+ }
+
+ return 0;
}
int clk_enable_bulk(struct clk_bulk *bulk)
@@ -474,13 +506,46 @@ int clk_enable_bulk(struct clk_bulk *bulk)
int clk_disable(struct clk *clk)
{
const struct clk_ops *ops = clk_dev_ops(clk->dev);
+ struct clk *clkp = NULL;
+ int ret;
debug("%s(clk=%p)\n", __func__, clk);
- if (!ops->disable)
- return -ENOSYS;
+ if (CONFIG_IS_ENABLED(CLK_CCF)) {
+ if (clk->id && !clk_get_by_id(clk->id, )) {
+ if (clkp->enable_count == 0) {
+ printf("clk %s already disabled\n",
+ clkp->dev->name);
+ return 0;
+ }
- return ops->disable(clk);
+ if (--clkp->enable_count > 0)
+ return 0;
+ }
+
+ if (ops->disable) {
+ ret = ops->disable(clk);
+ if (ret)
+ return ret;
+ }
+
+ if (clkp && clkp->dev->parent &&
+ device_get_uclass_id(clkp->dev) == UCLASS_CLK) {
+ ret = clk_disable(dev_get_clk_ptr(clkp->dev->parent));
+ if (ret) {
+ printf("Disable %s failed\n",
+ clkp->dev->parent->name);
+ return ret;
+ }
+ }
+ } else {
+ if (!ops->disable)
+ return -ENOSYS;
+
+ return ops->disable(clk);
+ }
+
+ return 0;
}
int clk_disable_bulk(struct clk_bulk *bulk)
--
2.16.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH V2 4/4] sandbox: clk: add clk enable/disable test code
Since we added clk enable_count and prograte clk child enabling
operation to clk parent, so add a new function sandbox_clk_enable_count
to get enable_count for test usage.
And add test code to get the enable_count after we enable/disable
the device clk.
Signed-off-by: Peng Fan
---
V2:
New patch
drivers/clk/clk_sandbox_ccf.c | 15 +++
include/sandbox-clk.h | 3 +++
test/dm/clk_ccf.c | 26 ++
3 files changed, 44 insertions(+)
diff --git a/drivers/clk/clk_sandbox_ccf.c b/drivers/clk/clk_sandbox_ccf.c
index e126f18d8e..9fa27229e1 100644
--- a/drivers/clk/clk_sandbox_ccf.c
+++ b/drivers/clk/clk_sandbox_ccf.c
@@ -25,6 +25,18 @@ struct clk_pllv3 {
u32 div_shift;
};
+int sandbox_clk_enable_count(struct clk *clk)
+{
+ struct clk *clkp = NULL;
+ int ret;
+
+ ret = clk_get_by_id(clk->id, );
+ if (ret)
+ return 0;
+
+ return clkp->enable_count;
+}
+
static ulong clk_pllv3_get_rate(struct clk *clk)
{
unsigned long parent_rate = clk_get_parent_rate(clk);
@@ -254,6 +266,9 @@ static int sandbox_clk_ccf_probe(struct udevice *dev)
sandbox_clk_composite("i2c", i2c_sels, ARRAY_SIZE(i2c_sels),
, 0));
+ clk_dm(SANDBOX_CLK_I2C_ROOT,
+ sandbox_clk_gate2("i2c_root", "i2c", base + 0x7c, 0));
+
return 0;
}
diff --git a/include/sandbox-clk.h b/include/sandbox-clk.h
index f449de1364..296cddfbb0 100644
--- a/include/sandbox-clk.h
+++ b/include/sandbox-clk.h
@@ -20,6 +20,7 @@ enum {
SANDBOX_CLK_USDHC1_SEL,
SANDBOX_CLK_USDHC2_SEL,
SANDBOX_CLK_I2C,
+ SANDBOX_CLK_I2C_ROOT,
};
enum sandbox_pllv3_type {
@@ -74,4 +75,6 @@ static inline struct clk *sandbox_clk_mux(const char *name,
void __iomem *reg,
width, 0);
}
+int sandbox_clk_enable_count(struct clk *clk);
+
#endif /* __SANDBOX_CLK_H__ */
diff --git a/test/dm/clk_ccf.c b/test/dm/clk_ccf.c
index bbc4b500e8..f2a8905af5 100644
--- a/test/dm/clk_ccf.c
+++ b/test/dm/clk_ccf.c
@@ -64,6 +64,32 @@ static int dm_test_clk_ccf(struct unit_test_state *uts)
rate = clk_get_rate(clk);
ut_asserteq(rate, 6000);
+ /* Test clk tree enable/disable */
+ ret = clk_get_by_id(SANDBOX_CLK_I2C_ROOT, );
+ ut_assertok(ret);
+ ut_asserteq_str("i2c_root", clk->dev->name);
+
+ ret = clk_enable(clk);
+ ut_assertok(ret);
+
+ ret = sandbox_clk_enable_count(clk);
+ ut_asserteq(ret, 1);
+
+ ret = clk_get_by_id(SANDBOX_CLK_I2C, );
+ ut_assertok(ret);
+
+ ret = sandbox_clk_enable_count(pclk);
+ ut_asserteq(ret, 1);
+
+ ret = clk_disable(clk);
+ ut_assertok(ret);
+
+ ret = sandbox_clk_enable_count(clk);
+ ut_asserteq(ret, 0);
+
+ ret = sandbox_clk_enable_count(pclk);
+ ut_asserteq(ret, 0);
+
return 1;
}
--
2.16.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH V2 1/4] clk: introduce enable_count
As what Linux Kernel 5.3.0 provides when enable/disable clk,
there is an enable_count in clk_core_disable/enable. Introduce
enable_count to track the clk enable/disable count when
clk_enable/disable for CCF. And Initialize enable_count to 0 when
register the clk.
And clk tree dump with enable_count will be supported, it will
be easy for us to check the clk status with enable_count
Signed-off-by: Peng Fan
---
V2:
Improve commit log
Rename enable_cnt to enable_count following Linux Kernel
drivers/clk/clk.c| 1 +
drivers/clk/clk_fixed_rate.c | 1 +
include/clk.h| 1 +
3 files changed, 3 insertions(+)
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 39b3087067..1cf9987f6c 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -40,6 +40,7 @@ int clk_register(struct clk *clk, const char *drv_name,
return ret;
}
+ clk->enable_count = 0;
/* Store back pointer to clk from udevice */
clk->dev->uclass_priv = clk;
diff --git a/drivers/clk/clk_fixed_rate.c b/drivers/clk/clk_fixed_rate.c
index 08cce0d79b..f51126793e 100644
--- a/drivers/clk/clk_fixed_rate.c
+++ b/drivers/clk/clk_fixed_rate.c
@@ -27,6 +27,7 @@ static int clk_fixed_rate_ofdata_to_platdata(struct udevice
*dev)
/* Make fixed rate clock accessible from higher level struct clk */
dev->uclass_priv = clk;
clk->dev = dev;
+ clk->enable_count = 0;
return 0;
}
diff --git a/include/clk.h b/include/clk.h
index 2ebc905e04..212c249385 100644
--- a/include/clk.h
+++ b/include/clk.h
@@ -61,6 +61,7 @@ struct clk {
struct udevice *dev;
long long rate; /* in HZ */
u32 flags;
+ int enable_count;
/*
* Written by of_xlate. In the future, we might add more fields here.
*/
--
2.16.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4 v5] watchdog: Implement generic watchdog_reset() version
Hi Stefan,
On Fri, Aug 16, 2019 at 1:11 PM Stefan Roese wrote:
>
> Hi Bin,
>
> On 15.08.19 16:19, Bin Meng wrote:
> > Hi Stefan,
> >
> > On Thu, Aug 15, 2019 at 2:07 PM Stefan Roese wrote:
> >>
> >> Hi Simon,
> >>
> >> On 14.08.19 21:35, Simon Glass wrote:
> >>> Hi,
> >>>
> >>> On Wed, 14 Aug 2019 at 00:22, Stefan Roese wrote:
>
> Hi Simon,
>
> (added Simon Glass and Bin to Cc)
>
> On 13.08.19 22:16, Simon Goldschmidt wrote:
> > Am 25.04.2019 um 09:17 schrieb Stefan Roese:
> >> This patch tries to implement a generic watchdog_reset() function that
> >> can be used by all boards that want to service the watchdog device in
> >> U-Boot. This watchdog servicing is enabled via CONFIG_WATCHDOG.
> >>
> >> Without this approach, new boards or platforms needed to implement a
> >> board specific version of this functionality, mostly copy'ing the same
> >> code over and over again into their board or platforms code base.
> >>
> >> With this new generic function, the scattered other functions are now
> >> removed to be replaced by the generic one. The new version also enables
> >> the configuration of the watchdog timeout via the DT "timeout-sec"
> >> property (if enabled via CONFIG_OF_CONTROL).
> >>
> >> This patch also adds a new flag to the GD flags, to flag that the
> >> watchdog is ready to use and adds the pointer to the watchdog device
> >> to the GD. This enables us to remove the global "watchdog_dev"
> >> variable, which was prone to cause problems because of its potentially
> >> very early use in watchdog_reset(), even before the BSS is cleared.
> >>
> >> Signed-off-by: Stefan Roese
> >
> >
> >
> >> --- a/include/asm-generic/global_data.h
> >> +++ b/include/asm-generic/global_data.h
> >> @@ -133,6 +133,9 @@ typedef struct global_data {
> >>struct spl_handoff *spl_handoff;
> >> # endif
> >> #endif
> >> +#if defined(CONFIG_WDT)
> >> +struct udevice *watchdog_dev;
> >> +#endif
> >> } gd_t;
> >> #endif
> >>
> >> @@ -161,5 +164,6 @@ typedef struct global_data {
> >> #define GD_FLG_ENV_DEFAULT0x02000 /* Default variable
> >> flag */
> >> #define GD_FLG_SPL_EARLY_INIT 0x04000 /* Early SPL init is
> >> done */
> >> #define GD_FLG_LOG_READY 0x08000 /* Log system is ready for use
> >>*/
> >> +#define GD_FLG_WDT_READY0x1 /* Watchdog is ready for use
> >> */
> >
> > Sorry to warm up a thread that is more than 4 months old, but I just
> > stumbled accross this line when searching for space in 'gd':
> >
> > The comment some lines above in global_data.h clearly states that the
> > top 16 bits of flags are reserved for arch-specific flags, and your
> > patch here uses the lowest of these 16 arch-specific flags for generic
> > code.
>
> I totally missed this comment.
>
> > Is this a problem? Does any arch code use the upper 16 bits? I would
> > have thought you'd at least need to adjust the comment to reflect your
> > new usage...
>
> As stated above, I did not check about any other (arch-specific)
> GD_FLG_ definitions outside of this file.
>
> > The reason I ask is that I'd need a place to put some (~5?)
> > 'is_initialized' bits for some code running in SPL in the 'board_init_f'
> > code where BSS shouldn't be used. gd->flags would be ideal for that, but
> > I'm hesistant to dive in further into the 'arch-specific' upper 16
> > bits...
>
> And you should be. A quick grep shows that we already have a problem with
> my patch touching the upper bits:
>
> $ git grep "define GD_FLG_"
> arch/x86/include/asm/global_data.h:#define GD_FLG_COLD_BOOT 0x1
> /* Cold Boot */
> arch/x86/include/asm/global_data.h:#define GD_FLG_WARM_BOOT 0x2
> /* Warm Boot */
>
> This should definitely be fixed. I see 3 options right now:
>
> a) Reserve only the upper 8 bits for arch-specific stuff
> b) Use a new variable (gd->flags_arch ?) for this arch
> c) Remove the arch-specific GD_FLG's completely
>
> I can't tell if c) is doable - Bin and / or Simon Glass might know,
> if the x86 GD_FLG_foo_BOOT are really needed in gd->flags. I see that
> both are assigned in the .S files, but only GD_FLG_COLD_BOOT is
> referenced later on:
> >>>
> >>> Probably we can drop warm boot.
> >>
> >> Bin, do you think so as well?
> >>
> >
> > I believe we can drop these 2 flags completely. Currently usage of
> > warm/cold boot flags is only limited to coreboot codes.
> >
> > arch/x86/cpu/coreboot/coreboot.c::last_stage_init()
> >
> > if (gd->flags & GD_FLG_COLD_BOOT)
> > timestamp_add_to_bootstage();
> >
> >
[U-Boot] [PATCH v2] arm: dts: Makefile: clean *dtb_HS
From: Suniel Mahesh TI HS platforms generate *dtb_HS binary blobs and there is no rule for cleanup. Added entry for cleanup in clean-files target. Signed-off-by: Suniel Mahesh --- Changes for v2: - changed description to fit the change done. - As suggested by Lokesh Vutla, moved cleaning process to dts/Makefile --- arch/arm/dts/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile index e021888..5f4e05d 100644 --- a/arch/arm/dts/Makefile +++ b/arch/arm/dts/Makefile @@ -806,4 +806,4 @@ PHONY += dtbs dtbs: $(addprefix $(obj)/, $(dtb-y)) @: -clean-files := *.dtb +clean-files := *.dtb *_HS -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 00/13] powerpc: Enable device tree support
Hi Zhiqiang, > -Original Message- > From: Z.q. Hou > Sent: Friday, August 16, 2019 11:58 AM > To: Jagdish Gediya ; u-boot@lists.denx.de; > s...@chromium.org; Prabhakar Kushwaha ; > Shengzhou Liu ; bmeng...@gmail.com; Jiafei Pan > ; Priyanka Jain > Subject: RE: [PATCH 00/13] powerpc: Enable device tree support > > Hi Jagdish, > > Thanks a lot for your comments! > > > -Original Message- > > From: Jagdish Gediya > > Sent: 2019年8月16日 14:05 > > To: Z.q. Hou ; u-boot@lists.denx.de; > > s...@chromium.org; Prabhakar Kushwaha > ; > > Shengzhou Liu ; bmeng...@gmail.com; Jiafei > Pan > > ; Priyanka Jain > > Subject: RE: [PATCH 00/13] powerpc: Enable device tree support > > > > Hi Zhiqiang, > > > > > -Original Message- > > > From: Z.q. Hou > > > Sent: Thursday, June 20, 2019 1:49 PM > > > To: u-boot@lists.denx.de; s...@chromium.org; Prabhakar Kushwaha > > > ; Shengzhou Liu > > ; > > > bmeng...@gmail.com; Jagdish Gediya ; Jiafei > > > Pan ; Priyanka Jain > > > Cc: Z.q. Hou > > > Subject: [PATCH 00/13] powerpc: Enable device tree support > > > > > > From: Hou Zhiqiang > > > > > > This patch is to enable device tree support for the Freescale > > > PowerPC platforms below. > > > > > > Hou Zhiqiang (13): > > > powerpc: Enable device tree support for T2080RDB > > > powerpc: Enable device tree support for T4240RDB > > > powerpc: Enable device tree support for T1024RDB > > > powerpc: Enable device tree support for T1042D4RDB > > > powerpc: Enable device tree support for P1020RDB > > > powerpc: Enable device tree support for P2020RDB > > > powerpc: Enable device tree support for P2041RDB > > > powerpc: Enable device tree support for P3041DS > > > powerpc: Enable device tree support for P4080DS > > > powerpc: Enable device tree support for P5040DS > > > powerpc: dts: add default definition of > > CONFIG_RESET_VECTOR_ADDRESS > > > powerpc: mpc8548cds: extend the reserved length for monitor > > > powerpc: Enable device tree support for MPC8548CDS > > > > > > arch/powerpc/dts/Makefile| 12 +++ > > > arch/powerpc/dts/e500mc_power_isa.dtsi | 33 ++ > > > arch/powerpc/dts/e500v2_power_isa.dtsi | 26 + > > > arch/powerpc/dts/e5500_power_isa.dtsi| 34 +++ > > > arch/powerpc/dts/mpc8548-post.dtsi | 27 + > > > arch/powerpc/dts/mpc8548.dtsi| 27 + > > > arch/powerpc/dts/mpc8548cds.dts | 23 + > > > arch/powerpc/dts/mpc8548cds_36b.dts | 23 + > > > arch/powerpc/dts/p1020-post.dtsi | 27 + > > > arch/powerpc/dts/p1020.dtsi | 31 ++ > > > arch/powerpc/dts/p1020rdb-pc.dts | 23 + > > > arch/powerpc/dts/p1020rdb-pc_36b.dts | 23 + > > > arch/powerpc/dts/p1020rdb-pd.dts | 23 + > > > arch/powerpc/dts/p2020-post.dtsi | 27 + > > > arch/powerpc/dts/p2020.dtsi | 31 ++ > > > arch/powerpc/dts/p2020rdb-pc.dts | 23 + > > > arch/powerpc/dts/p2020rdb-pc_36b.dts | 23 + > > > arch/powerpc/dts/p2041.dtsi | 63 > > > arch/powerpc/dts/p2041rdb.dts| 18 > > > arch/powerpc/dts/p3041.dtsi | 63 > > > arch/powerpc/dts/p3041ds.dts | 18 > > > arch/powerpc/dts/p4080.dtsi | 83 > > +++ > > > arch/powerpc/dts/p4080ds.dts | 18 > > > arch/powerpc/dts/p5040.dtsi | 62 +++ > > > arch/powerpc/dts/p5040ds.dts | 18 > > > arch/powerpc/dts/t1024rdb.dts| 17 > > > arch/powerpc/dts/t102x.dtsi | 52 ++ > > > arch/powerpc/dts/t1042d4rdb.dts | 17 > > > arch/powerpc/dts/t104x.dtsi | 62 +++ > > > arch/powerpc/dts/t2080rdb.dts| 17 > > > arch/powerpc/dts/t4240.dtsi | 102 > > +++ > > > arch/powerpc/dts/t4240rdb.dts| 17 > > > arch/powerpc/dts/u-boot.dtsi | 3 + > > > board/freescale/p1_p2_rdb_pc/README | 19 > > > board/freescale/p2041rdb/README | 18 > > > board/freescale/t102xrdb/README | 19 > > > board/freescale/t104xrdb/README | 19 > > > board/freescale/t208xrdb/README | 19 > > > configs/MPC8548CDS_36BIT_defconfig | 3 + > > > configs/MPC8548CDS_defconfig | 3 + > > > configs/MPC8548CDS_legacy_defconfig | 3 + > > > configs/P1020RDB-PC_36BIT_NAND_defconfig | 2 + > > > configs/P1020RDB-PC_36BIT_SDCARD_defconfig | 2 + > > > configs/P1020RDB-PC_36BIT_SPIFLASH_defconfig | 2 + > > > configs/P1020RDB-PC_36BIT_defconfig | 3 + > > > configs/P1020RDB-PC_NAND_defconfig | 2 + > > >
Re: [U-Boot] [PATCH 1/3] clk: introduce enable_cnt
Hi Lukasz,
> Subject: Re: [PATCH 1/3] clk: introduce enable_cnt
>
> Hi Peng,
>
> > Introduce enable_cnt to track the clk enable/disable count
>
> As fair as I remember there was no reference counters for Linux original CCF
> (to be precise - they are in devices, but not explicitly used in CCF).
There are prepare and enable count in Linux clk
https://elixir.bootlin.com/linux/latest/source/drivers/clk/clk.c#L1006
>
> As the commit message is very short I would like to explicitly ask what
> problem do you try to solve here (and if the same problem is available on
> Linux)? [*]
On i.MX8MM, the clk tree might be
OSC->PLL->PLL GATE->CCM->CCGR GATE->Device
The current U-Boot implementation only handle CCGR GATE,
It not able to handle PLL GATE unless enable the gate explicitly.
>
> The whole parch series misses a few things:
>
> - Detailed explanation and rationale for this code [*]
>
> - If you introduce new variable/functionality in clk-uclass - there
> shall be a sandbox test code for it. This is missing in this series.
>
>
> Note:
>
> [*] - please write detailed commit messages / readme for your patches (this is
> the note for the whole NXP's u-boot developers' team).
>
> Detailed commit message provides:
>
> - Better understanding of the issue for reviewers from the outset
>
> - It is a very good documentation which stays with the code (in git)
>
> - After e.g. 2 years it is still possible to get the grasp of the
> problem (when bisecting/ fixing bugs) quickly.
Will fix in V2.
Thanks,
Peng.
>
> > when
> > clk_enable/disable for CCF.
> > And Initialize enable_cnt to 0 when register the clk.
> >
> > Signed-off-by: Peng Fan
> > ---
> > drivers/clk/clk.c| 1 +
> > drivers/clk/clk_fixed_rate.c | 1 +
> > include/clk.h| 1 +
> > 3 files changed, 3 insertions(+)
> >
> > diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c index
> > 39b3087067..7effd410ee 100644
> > --- a/drivers/clk/clk.c
> > +++ b/drivers/clk/clk.c
> > @@ -40,6 +40,7 @@ int clk_register(struct clk *clk, const char
> > *drv_name, return ret;
> > }
> >
> > + clk->enable_cnt = 0;
> > /* Store back pointer to clk from udevice */
> > clk->dev->uclass_priv = clk;
> >
> > diff --git a/drivers/clk/clk_fixed_rate.c
> > b/drivers/clk/clk_fixed_rate.c index 08cce0d79b..6b89fad46b 100644
> > --- a/drivers/clk/clk_fixed_rate.c
> > +++ b/drivers/clk/clk_fixed_rate.c
> > @@ -27,6 +27,7 @@ static int clk_fixed_rate_ofdata_to_platdata(struct
> > udevice *dev) /* Make fixed rate clock accessible from higher level
> > struct clk */ dev->uclass_priv = clk;
> > clk->dev = dev;
> > + clk->enable_cnt = 0;
> >
> > return 0;
> > }
> > diff --git a/include/clk.h b/include/clk.h index
> > 2ebc905e04..58e456898f 100644
> > --- a/include/clk.h
> > +++ b/include/clk.h
> > @@ -61,6 +61,7 @@ struct clk {
> > struct udevice *dev;
> > long long rate; /* in HZ */
> > u32 flags;
> > + int enable_cnt;
> > /*
> > * Written by of_xlate. In the future, we might add more fields
> > here. */
>
>
>
> Best regards,
>
> Lukasz Majewski
>
> --
>
> DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email:
> lu...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] clk: introduce enable_cnt
Hi Peng,
> Introduce enable_cnt to track the clk enable/disable count
As fair as I remember there was no reference counters for Linux original
CCF (to be precise - they are in devices, but not explicitly used in
CCF).
As the commit message is very short I would like to explicitly ask
what problem do you try to solve here (and if the same problem is
available on Linux)? [*]
The whole parch series misses a few things:
- Detailed explanation and rationale for this code [*]
- If you introduce new variable/functionality in clk-uclass - there
shall be a sandbox test code for it. This is missing in this series.
Note:
[*] - please write detailed commit messages / readme for your patches
(this is the note for the whole NXP's u-boot developers' team).
Detailed commit message provides:
- Better understanding of the issue for reviewers from the outset
- It is a very good documentation which stays with the code (in git)
- After e.g. 2 years it is still possible to get the grasp of the
problem (when bisecting/ fixing bugs) quickly.
> when
> clk_enable/disable for CCF.
> And Initialize enable_cnt to 0 when register the clk.
>
> Signed-off-by: Peng Fan
> ---
> drivers/clk/clk.c| 1 +
> drivers/clk/clk_fixed_rate.c | 1 +
> include/clk.h| 1 +
> 3 files changed, 3 insertions(+)
>
> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> index 39b3087067..7effd410ee 100644
> --- a/drivers/clk/clk.c
> +++ b/drivers/clk/clk.c
> @@ -40,6 +40,7 @@ int clk_register(struct clk *clk, const char
> *drv_name, return ret;
> }
>
> + clk->enable_cnt = 0;
> /* Store back pointer to clk from udevice */
> clk->dev->uclass_priv = clk;
>
> diff --git a/drivers/clk/clk_fixed_rate.c
> b/drivers/clk/clk_fixed_rate.c index 08cce0d79b..6b89fad46b 100644
> --- a/drivers/clk/clk_fixed_rate.c
> +++ b/drivers/clk/clk_fixed_rate.c
> @@ -27,6 +27,7 @@ static int clk_fixed_rate_ofdata_to_platdata(struct
> udevice *dev) /* Make fixed rate clock accessible from higher level
> struct clk */ dev->uclass_priv = clk;
> clk->dev = dev;
> + clk->enable_cnt = 0;
>
> return 0;
> }
> diff --git a/include/clk.h b/include/clk.h
> index 2ebc905e04..58e456898f 100644
> --- a/include/clk.h
> +++ b/include/clk.h
> @@ -61,6 +61,7 @@ struct clk {
> struct udevice *dev;
> long long rate; /* in HZ */
> u32 flags;
> + int enable_cnt;
> /*
>* Written by of_xlate. In the future, we might add more
> fields here. */
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de
pgpViddtafoSB.pgp
Description: OpenPGP digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 3/3] clk: support clk tree dump
The previous code only dump the clk list. This patch is
to support clk tree dump, and also dump the enable_cnt.
On i.MX8MM, Partial output:
u-boot=> clk dump
Rate Usecnt Name
--
2400 0|-- clock-osc-24m
2400 0| |-- dram_pll_ref_sel
750000| | `-- dram_pll
750000| | `-- dram_pll_bypass
750000| | `-- dram_pll_out
2400 0| |-- arm_pll_ref_sel
12 0| | `-- arm_pll
12 0| | `-- arm_pll_bypass
12 0| | `-- arm_pll_out
12 0| | `-- arm_a53_src
12 0| | `-- arm_a53_cg
12 0| | `-- arm_a53_div
2400 4| |-- sys_pll1_ref_sel
84| | `-- sys_pll1
84| | `-- sys_pll1_bypass
84| | `-- sys_pll1_out
4000 0| | |-- sys_pll1_40m
Signed-off-by: Peng Fan
---
cmd/clk.c | 77 ---
1 file changed, 44 insertions(+), 33 deletions(-)
diff --git a/cmd/clk.c b/cmd/clk.c
index 5402c87de7..4b1f3079ff 100644
--- a/cmd/clk.c
+++ b/cmd/clk.c
@@ -7,50 +7,61 @@
#include
#if defined(CONFIG_DM) && defined(CONFIG_CLK)
#include
+#include
+#include
#include
+#include
#endif
-int __weak soc_clk_dump(void)
+static void show_clks(struct udevice *dev, int depth, int last_flag)
{
-#if defined(CONFIG_DM) && defined(CONFIG_CLK)
- struct udevice *dev;
- struct uclass *uc;
- struct clk clk;
- int ret;
- ulong rate;
-
- /* Device addresses start at 1 */
- ret = uclass_get(UCLASS_CLK, );
- if (ret)
- return ret;
-
- uclass_foreach_dev(dev, uc) {
- memset(, 0, sizeof(clk));
- ret = device_probe(dev);
- if (ret)
- goto noclk;
+ int i, is_last;
+ struct udevice *child;
+ struct clk *clkp;
+ u32 rate;
+
+ clkp = dev_get_clk_ptr(dev);
+ if (device_get_uclass_id(dev) == UCLASS_CLK && clkp) {
+ rate = clk_get_rate(clkp);
+
+ printf(" %-12u %8d", rate, clkp->enable_cnt);
+
+ for (i = depth; i >= 0; i--) {
+ is_last = (last_flag >> i) & 1;
+ if (i) {
+ if (is_last)
+ printf("");
+ else
+ printf("| ");
+ } else {
+ if (is_last)
+ printf("`-- ");
+ else
+ printf("|-- ");
+ }
+ }
- ret = clk_request(dev, );
- if (ret)
- goto noclk;
+ printf("%s\n", dev->name);
+ }
- rate = clk_get_rate();
- clk_free();
+ list_for_each_entry(child, >child_head, sibling_node) {
+ is_last = list_is_last(>sibling_node, >child_head);
+ show_clks(child, depth + 1, (last_flag << 1) | is_last);
+ }
+}
- if (rate == -ENODEV)
- goto noclk;
+int __weak soc_clk_dump(void)
+{
+ struct udevice *root;
- printf("%-30.30s : %lu Hz\n", dev->name, rate);
- continue;
- noclk:
- printf("%-30.30s : ? Hz\n", dev->name);
+ root = dm_root();
+ if (root) {
+ printf(" Rate Usecnt Name\n");
+ printf("--\n");
+ show_clks(root, -1, 0);
}
return 0;
-#else
- puts("Not implemented\n");
- return 1;
-#endif
}
static int do_clk_dump(cmd_tbl_t *cmdtp, int flag, int argc,
--
2.16.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/3] clk: prograte clk enable/disable to parent
When enabling/disabling a clk, also need to enable/disable
the clk's parent. Implement this in clk_enable/disable.
Signed-off-by: Peng Fan
---
drivers/clk/clk-uclass.c | 68 +++-
1 file changed, 62 insertions(+), 6 deletions(-)
diff --git a/drivers/clk/clk-uclass.c b/drivers/clk/clk-uclass.c
index cee4d912b0..208c9b7906 100644
--- a/drivers/clk/clk-uclass.c
+++ b/drivers/clk/clk-uclass.c
@@ -449,13 +449,41 @@ int clk_set_parent(struct clk *clk, struct clk *parent)
int clk_enable(struct clk *clk)
{
const struct clk_ops *ops = clk_dev_ops(clk->dev);
+ struct clk *clkp = NULL;
+ int ret;
debug("%s(clk=%p)\n", __func__, clk);
- if (!ops->enable)
- return -ENOSYS;
+ if (CONFIG_IS_ENABLED(CLK_CCF)) {
+ /* Take id 0 as a non-valid clk, such as dummy */
+ if (clk->id && !clk_get_by_id(clk->id, )) {
+ if (clkp->dev->parent &&
+ device_get_uclass_id(clkp->dev) == UCLASS_CLK) {
+ ret =
clk_enable(dev_get_clk_ptr(clkp->dev->parent));
+ if (ret) {
+ printf("Enable %s failed\n",
+ clkp->dev->parent->name);
+ return ret;
+ }
+ }
+ }
- return ops->enable(clk);
+ if (ops->enable) {
+ ret = ops->enable(clk);
+ if (ret) {
+ printf("Enable %s failed\n", clk->dev->name);
+ return ret;
+ }
+ }
+ if (clkp)
+ clkp->enable_cnt++;
+ } else {
+ if (!ops->enable)
+ return -ENOSYS;
+ return ops->enable(clk);
+ }
+
+ return 0;
}
int clk_enable_bulk(struct clk_bulk *bulk)
@@ -474,13 +502,41 @@ int clk_enable_bulk(struct clk_bulk *bulk)
int clk_disable(struct clk *clk)
{
const struct clk_ops *ops = clk_dev_ops(clk->dev);
+ struct clk *clkp;
+ int ret;
debug("%s(clk=%p)\n", __func__, clk);
- if (!ops->disable)
- return -ENOSYS;
+ if (CONFIG_IS_ENABLED(CLK_CCF)) {
+ if (ops->disable) {
+ ret = ops->disable(clk);
+ if (ret)
+ return ret;
+ }
+
+ if (clk->id && !clk_get_by_id(clk->id, )) {
+ if (clkp->dev->parent &&
+ device_get_uclass_id(clkp->dev) == UCLASS_CLK) {
+ ret =
clk_disable(dev_get_clk_ptr(clkp->dev->parent));
+ if (ret) {
+ printf("Disable %s failed\n",
+ clkp->dev->parent->name);
+ return ret;
+ }
+ }
+ }
+
+ if (clkp)
+ clkp->enable_cnt--;
+ } else {
- return ops->disable(clk);
+ if (!ops->disable)
+ return -ENOSYS;
+
+ return ops->disable(clk);
+ }
+
+ return 0;
}
int clk_disable_bulk(struct clk_bulk *bulk)
--
2.16.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/3] clk: introduce enable_cnt
Introduce enable_cnt to track the clk enable/disable count when
clk_enable/disable for CCF.
And Initialize enable_cnt to 0 when register the clk.
Signed-off-by: Peng Fan
---
drivers/clk/clk.c| 1 +
drivers/clk/clk_fixed_rate.c | 1 +
include/clk.h| 1 +
3 files changed, 3 insertions(+)
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 39b3087067..7effd410ee 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -40,6 +40,7 @@ int clk_register(struct clk *clk, const char *drv_name,
return ret;
}
+ clk->enable_cnt = 0;
/* Store back pointer to clk from udevice */
clk->dev->uclass_priv = clk;
diff --git a/drivers/clk/clk_fixed_rate.c b/drivers/clk/clk_fixed_rate.c
index 08cce0d79b..6b89fad46b 100644
--- a/drivers/clk/clk_fixed_rate.c
+++ b/drivers/clk/clk_fixed_rate.c
@@ -27,6 +27,7 @@ static int clk_fixed_rate_ofdata_to_platdata(struct udevice
*dev)
/* Make fixed rate clock accessible from higher level struct clk */
dev->uclass_priv = clk;
clk->dev = dev;
+ clk->enable_cnt = 0;
return 0;
}
diff --git a/include/clk.h b/include/clk.h
index 2ebc905e04..58e456898f 100644
--- a/include/clk.h
+++ b/include/clk.h
@@ -61,6 +61,7 @@ struct clk {
struct udevice *dev;
long long rate; /* in HZ */
u32 flags;
+ int enable_cnt;
/*
* Written by of_xlate. In the future, we might add more fields here.
*/
--
2.16.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] Makefile: clean *dtb_HS
On 16/08/19 12:32 PM, suni...@techveda.org wrote: > From: Suniel Mahesh > > All TI HS platforms generate HS images/binaries along with > the normal images. These *dtb_HS are generated in dts dir > and there is no rule for cleanup. Added entry for cleanup > in clean and distclean targets. > > Signed-off-by: Suniel Mahesh Instead can you do this in arch/arm/dts/Makefile diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile index 484e21e678..7492a28c1b 100644 --- a/arch/arm/dts/Makefile +++ b/arch/arm/dts/Makefile @@ -586,4 +586,4 @@ PHONY += dtbs dtbs: $(addprefix $(obj)/, $(dtb-y)) @: -clean-files := *.dtb *.dtbo +clean-files := *.dtb *.dtbo *._HS Thanks and regards, Lokesh ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] instruction "xchgb" for x86_64
> > Hi, > > (James please can you use plain-text email for the mailing list?) OK. Thanks Simon for pointing out this. I am using outlook, so most likely will have "newline" difference. Hope can find a way out for this. > > For chromebook_link64 I get: > > output: '/usr/local/google/home/sjg/cosarm/src/third_party/u- > boot/files/arch/x86/include/asm/byteorder.h: > Assembler messages: > /usr/local/google/home/sjg/cosarm/src/third_party/u- > boot/files/arch/x86/include/asm/byteorder.h:22: > Error: register type mismatch for `xchg' > make[2]: *** [/usr/local/google/home/sjg/cosarm/src/third_party/u- > boot/files/scripts/Makefile.build:278: > net/tftp.o] Error 1 > make[2]: *** Waiting for unfinished jobs > /usr/local/google/home/sjg/cosarm/src/third_party/u-boot/files/net/net.c: > In function 'net_process_received_packet': > /usr/local/google/home/sjg/cosarm/src/third_party/u- > boot/files/net/net.c:1324:1: > error: extended registers have no high halves } ^ > /usr/local/google/home/sjg/cosarm/src/third_party/u- > boot/files/arch/x86/include/asm/byteorder.h: > Assembler messages: > /usr/local/google/home/sjg/cosarm/src/third_party/u- > boot/files/arch/x86/include/asm/byteorder.h:22: > Error: register type mismatch for `xchg' > /usr/local/google/home/sjg/cosarm/src/third_party/u- > boot/files/arch/x86/include/asm/byteorder.h:22: > Error: register type mismatch for `xchg' > /usr/local/google/home/sjg/cosarm/src/third_party/u- > boot/files/arch/x86/include/asm/byteorder.h:22: > Error: register type mismatch for `xchg' > make[2]: *** [/usr/local/google/home/sjg/cosarm/src/third_party/u- > boot/files/scripts/Makefile.build:278: > net/net.o] Error 1 > make[1]: *** [/usr/local/google/home/sjg/cosarm/src/third_party/u- > boot/files/Makefile:1588: > net] Error 2 > make[1]: *** Waiting for unfinished jobs > make: *** [Makefile:148: sub-make] Error 2 > > Perhaps there is another way to fix this? > I tested two toolchains: 1. With gcc version 7.3-win32 20180312 (the MinGW-w64 cross compiling), it can assemble the xchgb without error. 2. With gcc version 7.3.0 (Ubuntu 7.3.0-27ubuntu1~18.04), it uses /usr/include/x86_64-linux-gnu/asm/byteorder.h, (not the one in uboot), and that file is only to include the file As the assembler you use reports error for xchgb (no matter what's the cause), we may use ONLY the C version of implementation and remove the assembly version and relevant CONFIG_IS_ENABLED checking (if performance is not critical here)? How do you think, Simon and Bin? Best regards James Wang Jinmin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] Makefile: clean *dtb_HS
From: Suniel Mahesh All TI HS platforms generate HS images/binaries along with the normal images. These *dtb_HS are generated in dts dir and there is no rule for cleanup. Added entry for cleanup in clean and distclean targets. Signed-off-by: Suniel Mahesh --- Makefile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Makefile b/Makefile index 3b0864a..c740fde 100644 --- a/Makefile +++ b/Makefile @@ -1840,7 +1840,7 @@ clean: $(clean-dirs) -o -name '*.symtypes' -o -name 'modules.order' \ -o -name modules.builtin -o -name '.tmp_*.o.*' \ -o -name 'dsdt.aml' -o -name 'dsdt.asl.tmp' -o -name 'dsdt.c' \ - -o -name '*.efi' -o -name '*.gcno' -o -name '*.so' \) \ + -o -name '*.efi' -o -name '*.gcno' -o -name '*.so' -o -name '*_HS' \) \ -type f -print | xargs rm -f \ bl31.c bl31.elf bl31_*.bin image.map @@ -1868,7 +1868,7 @@ distclean: mrproper \( -name '*.orig' -o -name '*.rej' -o -name '*~' \ -o -name '*.bak' -o -name '#*#' -o -name '.*.orig' \ -o -name '.*.rej' -o -name '*%' -o -name 'core' \ - -o -name '*.pyc' \) \ + -o -name '*.pyc' -o -name '*_HS' \) \ -type f -print | xargs rm -f @rm -f boards.cfg CHANGELOG -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 3/4] configs: AST2500 EVB: Enable SD controller
On 15/08/2019 21:29, Eddie James wrote: > Enable the MMC subsystem and the Aspeed SD controller. Also enable the > use of the device tree for probing the controller. > > Signed-off-by: Eddie James Reviewed-by: Cédric Le Goater Thanks, C. > --- > configs/evb-ast2500_defconfig | 8 > 1 file changed, 8 insertions(+) > > diff --git a/configs/evb-ast2500_defconfig b/configs/evb-ast2500_defconfig > index 59d41cb..b47ca5b 100644 > --- a/configs/evb-ast2500_defconfig > +++ b/configs/evb-ast2500_defconfig > @@ -16,6 +16,7 @@ CONFIG_HUSH_PARSER=y > CONFIG_CMD_I2C=y > CONFIG_CMD_DHCP=y > CONFIG_CMD_MII=y > +CONFIG_CMD_MMC=y > CONFIG_CMD_PING=y > CONFIG_DEFAULT_DEVICE_TREE="ast2500-evb" > CONFIG_NET_RANDOM_ETHADDR=y > @@ -36,3 +37,10 @@ CONFIG_SYS_NS16550=y > CONFIG_SYSRESET=y > CONFIG_TIMER=y > CONFIG_WDT=y > +CONFIG_MMC=y > +CONFIG_DM_MMC=y > +CONFIG_MMC_SDHCI=y > +CONFIG_MMC_SDHCI_ASPEED=y > +CONFIG_MMC_VERBOSE=y > +CONFIG_OF_CONTROL=y > +CONFIG_OF_EMBED=y > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 2/4] mmc: Add Aspeed SD controller driver
On 15/08/2019 21:29, Eddie James wrote:
> Add support for the Aspeed SD host controller engine.
>
> Signed-off-by: Eddie James
Reviewed-by: Cédric Le Goater
Thanks,
C.
> ---
> arch/arm/include/asm/gpio.h | 3 +-
> drivers/mmc/Kconfig | 11 ++
> drivers/mmc/Makefile| 1 +
> drivers/mmc/aspeed_sdhci.c | 90
> +
> 4 files changed, 104 insertions(+), 1 deletion(-)
> create mode 100644 drivers/mmc/aspeed_sdhci.c
>
> diff --git a/arch/arm/include/asm/gpio.h b/arch/arm/include/asm/gpio.h
> index 370031f..38a5922 100644
> --- a/arch/arm/include/asm/gpio.h
> +++ b/arch/arm/include/asm/gpio.h
> @@ -1,6 +1,7 @@
> #if !defined(CONFIG_ARCH_UNIPHIER) && !defined(CONFIG_ARCH_STI) && \
> !defined(CONFIG_ARCH_K3) && !defined(CONFIG_ARCH_BCM6858) && \
> - !defined(CONFIG_ARCH_BCM63158) && !defined(CONFIG_ARCH_ROCKCHIP)
> + !defined(CONFIG_ARCH_BCM63158) && !defined(CONFIG_ARCH_ROCKCHIP) && \
> + !defined(CONFIG_ARCH_ASPEED)
> #include
> #endif
> #include
> diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
> index c6812f6..536f66a 100644
> --- a/drivers/mmc/Kconfig
> +++ b/drivers/mmc/Kconfig
> @@ -421,6 +421,17 @@ config SPL_MMC_SDHCI_ADMA
> This enables support for the ADMA (Advanced DMA) defined
> in the SD Host Controller Standard Specification Version 3.00 in SPL.
>
> +config MMC_SDHCI_ASPEED
> + bool "Aspeed SDHCI controller"
> + depends on ARCH_ASPEED
> + depends on DM_MMC
> + depends on MMC_SDHCI
> + help
> + Enables support for the Aspeed SDHCI 2.0 controller present on Aspeed
> + SoCs. This device is compatible with SD 3.0 and/or MMC 4.3
> + specifications. On the AST2600, the device is also compatible with
> + MMC 5.1 and eMMC 3.0.
> +
> config MMC_SDHCI_ATMEL
> bool "Atmel SDHCI controller support"
> depends on ARCH_AT91
> diff --git a/drivers/mmc/Makefile b/drivers/mmc/Makefile
> index 6cc018b..5594195 100644
> --- a/drivers/mmc/Makefile
> +++ b/drivers/mmc/Makefile
> @@ -46,6 +46,7 @@ obj-$(CONFIG_JZ47XX_MMC) += jz_mmc.o
>
> # SDHCI
> obj-$(CONFIG_MMC_SDHCI) += sdhci.o
> +obj-$(CONFIG_MMC_SDHCI_ASPEED) += aspeed_sdhci.o
> obj-$(CONFIG_MMC_SDHCI_ATMEL)+= atmel_sdhci.o
> obj-$(CONFIG_MMC_SDHCI_BCM2835) += bcm2835_sdhci.o
> obj-$(CONFIG_MMC_SDHCI_BCMSTB) += bcmstb_sdhci.o
> diff --git a/drivers/mmc/aspeed_sdhci.c b/drivers/mmc/aspeed_sdhci.c
> new file mode 100644
> index 000..1321ec3
> --- /dev/null
> +++ b/drivers/mmc/aspeed_sdhci.c
> @@ -0,0 +1,90 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright 2019 IBM Corp.
> + * Eddie James
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +struct aspeed_sdhci_plat {
> + struct mmc_config cfg;
> + struct mmc mmc;
> +};
> +
> +static int aspeed_sdhci_probe(struct udevice *dev)
> +{
> + struct mmc_uclass_priv *upriv = dev_get_uclass_priv(dev);
> + struct aspeed_sdhci_plat *plat = dev_get_platdata(dev);
> + struct sdhci_host *host = dev_get_priv(dev);
> + u32 max_clk;
> + struct clk clk;
> + int ret;
> +
> + ret = clk_get_by_index(dev, 0, );
> + if (ret)
> + return ret;
> +
> + ret = clk_enable();
> + if (ret)
> + goto free;
> +
> + host->name = dev->name;
> + host->ioaddr = (void *)devfdt_get_addr(dev);
> +
> + max_clk = clk_get_rate();
> + if (IS_ERR_VALUE(max_clk)) {
> + ret = max_clk;
> + goto err;
> + }
> +
> + host->max_clk = max_clk;
> + host->mmc = >mmc;
> + host->mmc->dev = dev;
> + host->mmc->priv = host;
> + upriv->mmc = host->mmc;
> +
> + ret = sdhci_setup_cfg(>cfg, host, 0, 0);
> + if (ret)
> + goto err;
> +
> + ret = sdhci_probe(dev);
> + if (ret)
> + goto err;
> +
> + return 0;
> +
> +err:
> + clk_disable();
> +free:
> + clk_free();
> + return ret;
> +}
> +
> +static int aspeed_sdhci_bind(struct udevice *dev)
> +{
> + struct aspeed_sdhci_plat *plat = dev_get_platdata(dev);
> +
> + return sdhci_bind(dev, >mmc, >cfg);
> +}
> +
> +static const struct udevice_id aspeed_sdhci_ids[] = {
> + { .compatible = "aspeed,ast2400-sdhci" },
> + { .compatible = "aspeed,ast2500-sdhci" },
> + { .compatible = "aspeed,ast2600-sdhci" },
> + { }
> +};
> +
> +U_BOOT_DRIVER(aspeed_sdhci_drv) = {
> + .name = "aspeed_sdhci",
> + .id = UCLASS_MMC,
> + .of_match = aspeed_sdhci_ids,
> + .ops= _ops,
> + .bind = aspeed_sdhci_bind,
> + .probe = aspeed_sdhci_probe,
> + .priv_auto_alloc_size = sizeof(struct sdhci_host),
> + .platdata_auto_alloc_size = sizeof(struct aspeed_sdhci_plat),
> +};
>
___
U-Boot mailing list
Re: [U-Boot] [PATCH 00/13] powerpc: Enable device tree support
Hi Jagdish, Thanks a lot for your comments! > -Original Message- > From: Jagdish Gediya > Sent: 2019年8月16日 14:05 > To: Z.q. Hou ; u-boot@lists.denx.de; > s...@chromium.org; Prabhakar Kushwaha ; > Shengzhou Liu ; bmeng...@gmail.com; Jiafei Pan > ; Priyanka Jain > Subject: RE: [PATCH 00/13] powerpc: Enable device tree support > > Hi Zhiqiang, > > > -Original Message- > > From: Z.q. Hou > > Sent: Thursday, June 20, 2019 1:49 PM > > To: u-boot@lists.denx.de; s...@chromium.org; Prabhakar Kushwaha > > ; Shengzhou Liu > ; > > bmeng...@gmail.com; Jagdish Gediya ; Jiafei > > Pan ; Priyanka Jain > > Cc: Z.q. Hou > > Subject: [PATCH 00/13] powerpc: Enable device tree support > > > > From: Hou Zhiqiang > > > > This patch is to enable device tree support for the Freescale PowerPC > > platforms below. > > > > Hou Zhiqiang (13): > > powerpc: Enable device tree support for T2080RDB > > powerpc: Enable device tree support for T4240RDB > > powerpc: Enable device tree support for T1024RDB > > powerpc: Enable device tree support for T1042D4RDB > > powerpc: Enable device tree support for P1020RDB > > powerpc: Enable device tree support for P2020RDB > > powerpc: Enable device tree support for P2041RDB > > powerpc: Enable device tree support for P3041DS > > powerpc: Enable device tree support for P4080DS > > powerpc: Enable device tree support for P5040DS > > powerpc: dts: add default definition of > CONFIG_RESET_VECTOR_ADDRESS > > powerpc: mpc8548cds: extend the reserved length for monitor > > powerpc: Enable device tree support for MPC8548CDS > > > > arch/powerpc/dts/Makefile| 12 +++ > > arch/powerpc/dts/e500mc_power_isa.dtsi | 33 ++ > > arch/powerpc/dts/e500v2_power_isa.dtsi | 26 + > > arch/powerpc/dts/e5500_power_isa.dtsi| 34 +++ > > arch/powerpc/dts/mpc8548-post.dtsi | 27 + > > arch/powerpc/dts/mpc8548.dtsi| 27 + > > arch/powerpc/dts/mpc8548cds.dts | 23 + > > arch/powerpc/dts/mpc8548cds_36b.dts | 23 + > > arch/powerpc/dts/p1020-post.dtsi | 27 + > > arch/powerpc/dts/p1020.dtsi | 31 ++ > > arch/powerpc/dts/p1020rdb-pc.dts | 23 + > > arch/powerpc/dts/p1020rdb-pc_36b.dts | 23 + > > arch/powerpc/dts/p1020rdb-pd.dts | 23 + > > arch/powerpc/dts/p2020-post.dtsi | 27 + > > arch/powerpc/dts/p2020.dtsi | 31 ++ > > arch/powerpc/dts/p2020rdb-pc.dts | 23 + > > arch/powerpc/dts/p2020rdb-pc_36b.dts | 23 + > > arch/powerpc/dts/p2041.dtsi | 63 > > arch/powerpc/dts/p2041rdb.dts| 18 > > arch/powerpc/dts/p3041.dtsi | 63 > > arch/powerpc/dts/p3041ds.dts | 18 > > arch/powerpc/dts/p4080.dtsi | 83 > +++ > > arch/powerpc/dts/p4080ds.dts | 18 > > arch/powerpc/dts/p5040.dtsi | 62 +++ > > arch/powerpc/dts/p5040ds.dts | 18 > > arch/powerpc/dts/t1024rdb.dts| 17 > > arch/powerpc/dts/t102x.dtsi | 52 ++ > > arch/powerpc/dts/t1042d4rdb.dts | 17 > > arch/powerpc/dts/t104x.dtsi | 62 +++ > > arch/powerpc/dts/t2080rdb.dts| 17 > > arch/powerpc/dts/t4240.dtsi | 102 > +++ > > arch/powerpc/dts/t4240rdb.dts| 17 > > arch/powerpc/dts/u-boot.dtsi | 3 + > > board/freescale/p1_p2_rdb_pc/README | 19 > > board/freescale/p2041rdb/README | 18 > > board/freescale/t102xrdb/README | 19 > > board/freescale/t104xrdb/README | 19 > > board/freescale/t208xrdb/README | 19 > > configs/MPC8548CDS_36BIT_defconfig | 3 + > > configs/MPC8548CDS_defconfig | 3 + > > configs/MPC8548CDS_legacy_defconfig | 3 + > > configs/P1020RDB-PC_36BIT_NAND_defconfig | 2 + > > configs/P1020RDB-PC_36BIT_SDCARD_defconfig | 2 + > > configs/P1020RDB-PC_36BIT_SPIFLASH_defconfig | 2 + > > configs/P1020RDB-PC_36BIT_defconfig | 3 + > > configs/P1020RDB-PC_NAND_defconfig | 2 + > > configs/P1020RDB-PC_SDCARD_defconfig | 2 + > > configs/P1020RDB-PC_SPIFLASH_defconfig | 2 + > > configs/P1020RDB-PC_defconfig| 3 + > > configs/P1020RDB-PD_NAND_defconfig | 2 + > > configs/P1020RDB-PD_SDCARD_defconfig | 2 + > > configs/P1020RDB-PD_SPIFLASH_defconfig | 2 + > > configs/P1020RDB-PD_defconfig| 3 + > > configs/P2020RDB-PC_36BIT_NAND_defconfig | 2 + > > configs/P2020RDB-PC_36BIT_SDCARD_defconfig | 2 + > >
[U-Boot] [PATCH v3 4/4] USB: gadget: core: introduce ->udc_set_speed() method
This patch was copied from kernel commit: 67fdfda4a99ed.
Sometimes, the gadget driver we want to run has max_speed lower than
what the UDC supports. In such situations, UDC might want to make sure
we don't try to connect on speeds not supported by the gadget
driver because that will just fail.
So here introduce a new optional ->udc_set_speed() method which can be
implemented by interested UDC drivers to achieve this purpose.
Signed-off-by: Sherry Sun
---
drivers/usb/gadget/udc/udc-core.c | 23 +++
include/linux/usb/gadget.h| 2 ++
2 files changed, 25 insertions(+)
diff --git a/drivers/usb/gadget/udc/udc-core.c
b/drivers/usb/gadget/udc/udc-core.c
index 62b47781dd..8d1d90e3e3 100644
--- a/drivers/usb/gadget/udc/udc-core.c
+++ b/drivers/usb/gadget/udc/udc-core.c
@@ -267,6 +267,27 @@ EXPORT_SYMBOL_GPL(usb_del_gadget_udc);
/* - */
+/**
+ * usb_gadget_udc_set_speed - tells usb device controller speed supported by
+ *current driver
+ * @udc: The device we want to set maximum speed
+ * @speed: The maximum speed to allowed to run
+ *
+ * This call is issued by the UDC Class driver before calling
+ * usb_gadget_udc_start() in order to make sure that we don't try to
+ * connect on speeds the gadget driver doesn't support.
+ */
+static inline void usb_gadget_udc_set_speed(struct usb_udc *udc,
+ enum usb_device_speed speed)
+{
+ if (udc->gadget->ops->udc_set_speed) {
+ enum usb_device_speed s;
+
+ s = min(speed, udc->gadget->max_speed);
+ udc->gadget->ops->udc_set_speed(udc->gadget, s);
+ }
+}
+
static int udc_bind_to_driver(struct usb_udc *udc, struct usb_gadget_driver
*driver)
{
int ret;
@@ -276,6 +297,8 @@ static int udc_bind_to_driver(struct usb_udc *udc, struct
usb_gadget_driver *dri
udc->driver = driver;
+ usb_gadget_udc_set_speed(udc, driver->speed);
+
ret = driver->bind(udc->gadget);
if (ret)
goto err1;
diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
index a34f3478f3..78e245a1b5 100644
--- a/include/linux/usb/gadget.h
+++ b/include/linux/usb/gadget.h
@@ -450,6 +450,8 @@ struct usb_gadget_ops {
int (*match_ep)(struct usb_gadget *gadget,
struct usb_ep *ep,
struct usb_endpoint_descriptor *desc);
+ void(*udc_set_speed)(struct usb_gadget *gadget,
+enum usb_device_speed);
};
/**
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 2/4] USB: host: Add the USB3 host driver
Add the USB3 host driver for NXP imx8 platform, and the
cadence IP is in it. The USB3 host driver support DM
mode, it will probe USB3 host node in dts.
Signed-off-by: Sherry Sun
---
drivers/usb/host/Kconfig | 9 ++
drivers/usb/host/Makefile| 1 +
drivers/usb/host/xhci-imx8.c | 189 +++
3 files changed, 199 insertions(+)
create mode 100644 drivers/usb/host/xhci-imx8.c
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index ac68aa2d27..cc1dfe463b 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -95,6 +95,15 @@ config USB_XHCI_FSL
depends on !SPL_NO_USB
help
Enables support for the on-chip xHCI controller on NXP Layerscape
SoCs.
+
+config USB_XHCI_IMX8
+ bool "XHCI support for imx8"
+ depends on ARCH_IMX8
+ default y
+ help
+ Enables support for the on-chip xHCI controller on imx8qm and
+ imx8qxp SoCs.
+
endif # USB_XHCI_HCD
config USB_EHCI_HCD
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index 6aa574f6f7..e5a0a4ea5a 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -55,6 +55,7 @@ obj-$(CONFIG_USB_XHCI_OMAP) += xhci-omap.o
obj-$(CONFIG_USB_XHCI_PCI) += xhci-pci.o
obj-$(CONFIG_USB_XHCI_RCAR) += xhci-rcar.o
obj-$(CONFIG_USB_XHCI_STI) += dwc3-sti-glue.o
+obj-$(CONFIG_USB_XHCI_IMX8) += xhci-imx8.o
# designware
obj-$(CONFIG_USB_DWC2) += dwc2.o
diff --git a/drivers/usb/host/xhci-imx8.c b/drivers/usb/host/xhci-imx8.c
new file mode 100644
index 00..0669a05c17
--- /dev/null
+++ b/drivers/usb/host/xhci-imx8.c
@@ -0,0 +1,189 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2019 NXP
+ *
+ * NXP i.MX8 USB HOST xHCI Controller (Cadence IP)
+ *
+ * Author: Peter Chen
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "xhci.h"
+
+/* Declare global data pointer */
+DECLARE_GLOBAL_DATA_PTR;
+
+/* Host registers */
+#define HCIVERSION_CAPLENGTH 0x1
+#define USBSTS0x10084
+
+/* None-core registers */
+#define USB3_CORE_CTRL10x00
+#define USB3_CORE_STATUS 0x0c
+#define USB3_SSPHY_STATUS 0x4c
+
+struct xhci_imx8_data {
+ void __iomem *usb3_ctrl_base;
+ void __iomem *usb3_core_base;
+ struct clk_bulk clks;
+ struct phy phy;
+};
+
+static struct xhci_imx8_data imx8_data;
+
+static void imx8_xhci_init(void)
+{
+ u32 tmp_data;
+ int ret;
+
+ tmp_data = readl(imx8_data.usb3_ctrl_base + USB3_SSPHY_STATUS);
+ writel(tmp_data, imx8_data.usb3_ctrl_base + USB3_SSPHY_STATUS);
+ tmp_data = readl(imx8_data.usb3_ctrl_base + USB3_SSPHY_STATUS);
+ ret = wait_for_bit_le32(imx8_data.usb3_ctrl_base + USB3_SSPHY_STATUS,
+ 0xf000, true, 100, false);
+ if (ret)
+ printf("clkvld is incorrect\n");
+
+ clrsetbits_le32(imx8_data.usb3_ctrl_base + USB3_CORE_CTRL1,
+ 0x7, 0x202);
+ clrbits_le32(imx8_data.usb3_ctrl_base + USB3_CORE_CTRL1, 1 << 26);
+ generic_phy_init(_data.phy);
+
+ /* clear all sw_rst */
+ clrbits_le32(imx8_data.usb3_ctrl_base + USB3_CORE_CTRL1, 0xFC << 24);
+
+ debug("wait xhci_power_on_ready\n");
+ ret = wait_for_bit_le32(imx8_data.usb3_ctrl_base + USB3_CORE_STATUS,
+ 0x1000, true, 100, false);
+ if (ret)
+ printf("wait xhci_power_on_ready timeout\n");
+ debug("xhci_power_on_ready\n");
+
+ debug("waiting CNR 0x%x\n", tmp_data);
+ ret = wait_for_bit_le32(imx8_data.usb3_core_base + USBSTS,
+ 0x800, false, 100, false);
+ if (ret)
+ printf("wait CNR timeout\n");
+ debug("check CNR has finished\n");
+}
+
+static void imx8_xhci_reset(void)
+{
+ /* Set CORE ctrl to default value, that all rst are hold */
+ writel(0xfc01, imx8_data.usb3_ctrl_base + USB3_CORE_CTRL1);
+}
+
+static int xhci_imx8_clk_init(struct udevice *dev)
+{
+ int ret;
+
+ ret = clk_get_bulk(dev, _data.clks);
+ if (ret)
+ return ret;
+
+ ret = clk_enable_bulk(_data.clks);
+ if (ret)
+ return ret;
+
+ return 0;
+}
+
+static int xhci_imx8_get_reg_addr(struct udevice *dev)
+{
+ imx8_data.usb3_ctrl_base =
+ (void __iomem *)devfdt_get_addr_index(dev, 0);
+ imx8_data.usb3_core_base =
+ (void __iomem *)devfdt_get_addr_index(dev, 4);
+
+ return 0;
+}
+
+static int xhci_imx8_probe(struct udevice *dev)
+{
+ struct xhci_hccr *hccr;
+ struct xhci_hcor *hcor;
+ struct udevice usbotg_dev;
+ struct power_domain pd;
+ int usbotg_off;
+ int ret = 0;
+ int len;
+
+ usbotg_off = fdtdec_lookup_phandle(gd->fdt_blob,
+
[U-Boot] [PATCH v3 3/4] phy: Add USB PHY driver for the cadence USB3
The cdns3-usb-phy driver supports both host and peripheral mode of usb driver which use cadence usb3 IP. Signed-off-by: Sherry Sun --- drivers/phy/Kconfig | 8 ++ drivers/phy/Makefile| 1 + drivers/phy/cdns3-usb-phy.c | 243 3 files changed, 252 insertions(+) create mode 100644 drivers/phy/cdns3-usb-phy.c diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig index 957efb3984..6e50365d90 100644 --- a/drivers/phy/Kconfig +++ b/drivers/phy/Kconfig @@ -190,4 +190,12 @@ config MT76X8_USB_PHY This PHY is found on MT76x8 devices supporting USB. +config CDNS3_USB_PHY + bool "Support CDNS3 USB PHY" + depends on PHY + help + Support for the USB PHY in CDNS3 IP. + + This PHY is found on CDNS3 IP devices supporting USB. + endmenu diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile index 90646ca55b..d9933e0439 100644 --- a/drivers/phy/Makefile +++ b/drivers/phy/Makefile @@ -21,3 +21,4 @@ obj-$(CONFIG_MSM8916_USB_PHY) += msm8916-usbh-phy.o obj-$(CONFIG_OMAP_USB2_PHY) += omap-usb2-phy.o obj-$(CONFIG_KEYSTONE_USB_PHY) += keystone-usb-phy.o obj-$(CONFIG_MT76X8_USB_PHY) += mt76x8-usb-phy.o +obj-$(CONFIG_CDNS3_USB_PHY) += cdns3-usb-phy.o diff --git a/drivers/phy/cdns3-usb-phy.c b/drivers/phy/cdns3-usb-phy.c new file mode 100644 index 00..b060db3c14 --- /dev/null +++ b/drivers/phy/cdns3-usb-phy.c @@ -0,0 +1,243 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * Copyright 2019 NXP + * + * Cadence3 USB PHY driver + * + * Author: Sherry Sun + */ + +#include +#include +#include +#include +#include +#include +#include + +/* PHY registers */ +#define PHY_PMA_CMN_CTRL1 (0xC800 * 4) +#define TB_ADDR_CMN_DIAG_HSCLK_SEL (0x01e0 * 4) +#define TB_ADDR_CMN_PLL0_VCOCAL_INIT_TMR (0x0084 * 4) +#define TB_ADDR_CMN_PLL0_VCOCAL_ITER_TMR (0x0085 * 4) +#define TB_ADDR_CMN_PLL0_INTDIV(0x0094 * 4) +#define TB_ADDR_CMN_PLL0_FRACDIV (0x0095 * 4) +#define TB_ADDR_CMN_PLL0_HIGH_THR (0x0096 * 4) +#define TB_ADDR_CMN_PLL0_SS_CTRL1 (0x0098 * 4) +#define TB_ADDR_CMN_PLL0_SS_CTRL2 (0x0099 * 4) +#define TB_ADDR_CMN_PLL0_DSM_DIAG (0x0097 * 4) +#define TB_ADDR_CMN_DIAG_PLL0_OVRD (0x01c2 * 4) +#define TB_ADDR_CMN_DIAG_PLL0_FBH_OVRD (0x01c0 * 4) +#define TB_ADDR_CMN_DIAG_PLL0_FBL_OVRD (0x01c1 * 4) +#define TB_ADDR_CMN_DIAG_PLL0_V2I_TUNE (0x01C5 * 4) +#define TB_ADDR_CMN_DIAG_PLL0_CP_TUNE (0x01C6 * 4) +#define TB_ADDR_CMN_DIAG_PLL0_LF_PROG (0x01C7 * 4) +#define TB_ADDR_CMN_DIAG_PLL0_TEST_MODE(0x01c4 * 4) +#define TB_ADDR_CMN_PSM_CLK_CTRL (0x0061 * 4) +#define TB_ADDR_XCVR_DIAG_RX_LANE_CAL_RST_TMR (0x40ea * 4) +#define TB_ADDR_XCVR_PSM_RCTRL (0x4001 * 4) +#define TB_ADDR_TX_PSC_A0 (0x4100 * 4) +#define TB_ADDR_TX_PSC_A1 (0x4101 * 4) +#define TB_ADDR_TX_PSC_A2 (0x4102 * 4) +#define TB_ADDR_TX_PSC_A3 (0x4103 * 4) +#define TB_ADDR_TX_DIAG_ECTRL_OVRD (0x41f5 * 4) +#define TB_ADDR_TX_PSC_CAL (0x4106 * 4) +#define TB_ADDR_TX_PSC_RDY (0x4107 * 4) +#define TB_ADDR_RX_PSC_A0 (0x8000 * 4) +#define TB_ADDR_RX_PSC_A1 (0x8001 * 4) +#define TB_ADDR_RX_PSC_A2 (0x8002 * 4) +#define TB_ADDR_RX_PSC_A3 (0x8003 * 4) +#define TB_ADDR_RX_PSC_CAL (0x8006 * 4) +#define TB_ADDR_RX_PSC_RDY (0x8007 * 4) +#define TB_ADDR_TX_TXCC_MGNLS_MULT_000 (0x4058 * 4) +#define TB_ADDR_TX_DIAG_BGREF_PREDRV_DELAY (0x41e7 * 4) +#define TB_ADDR_RX_SLC_CU_ITER_TMR (0x80e3 * 4) +#define TB_ADDR_RX_SIGDET_HL_FILT_TMR (0x8090 * 4) +#define TB_ADDR_RX_SAMP_DAC_CTRL (0x8058 * 4) +#define TB_ADDR_RX_DIAG_SIGDET_TUNE(0x81dc * 4) +#define TB_ADDR_RX_DIAG_LFPSDET_TUNE2 (0x81df * 4) +#define TB_ADDR_RX_DIAG_BS_TM (0x81f5 * 4) +#define TB_ADDR_RX_DIAG_DFE_CTRL1 (0x81d3 * 4) +#define TB_ADDR_RX_DIAG_ILL_IQE_TRIM4 (0x81c7 * 4) +#define TB_ADDR_RX_DIAG_ILL_E_TRIM0(0x81c2 * 4) +#define TB_ADDR_RX_DIAG_ILL_IQ_TRIM0 (0x81c1 * 4) +#define TB_ADDR_RX_DIAG_ILL_IQE_TRIM6 (0x81c9 * 4) +#define TB_ADDR_RX_DIAG_RXFE_TM3 (0x81f8 * 4) +#define TB_ADDR_RX_DIAG_RXFE_TM4 (0x81f9 * 4) +#define TB_ADDR_RX_DIAG_LFPSDET_TUNE (0x81dd * 4) +#define TB_ADDR_RX_DIAG_DFE_CTRL3 (0x81d5 * 4) +#define TB_ADDR_RX_DIAG_SC2C_DELAY (0x81e1 * 4) +#define TB_ADDR_RX_REE_VGA_GAIN_NODFE (0x81bf * 4) +#define TB_ADDR_XCVR_PSM_CAL_TMR (0x4002 * 4) +#define TB_ADDR_XCVR_PSM_A0BYP_TMR (0x4004 * 4) +#define
[U-Boot] [PATCH v3 0/4] USB: Add cadence USB3 gadget/host/phy driver
These patches introduce new Cadence driver to U-Boot. The first patch is to add the Cadence USB3 IP(CDNS3) core and driver for the usb gadget. The second patch introduce the xhci-imx8 usb host driver separately. The third patch introduce the cdns3 phy driver which can be used for both cdns3 host driver and gadget driver. The cdns3 usb gadget/host/phy driver are all used DM mode. The current driver has been validated on i.MX8 platform. If someone want to test it, please note that the additional dts nodes/ config macros/clock driver are also essential. You can also get my test patches at https://github.com/sherrysun1/u-boot-imx.git to start your test quickly. Changes in v3: - Changed all compatible from "Cadence,usb3" to "cdns,usb3". - Use wait_for_bit_le32() and clrsetbits_le32() globally. - Use u32 instead of unint_32 globally. - Split cdns3_set_role() into two functions: cdns3_host_role_set() and cdns3_gadget_role_set(). Sherry Sun (4): USB: gadget: Add the cadence USB3 gadget driver USB: host: Add the USB3 host driver phy: Add USB PHY driver for the cadence USB3 USB: gadget: core: introduce ->udc_set_speed() method Makefile |1 + doc/device-tree-bindings/usb/cdns-usb3.txt | 39 + drivers/phy/Kconfig|8 + drivers/phy/Makefile |1 + drivers/phy/cdns3-usb-phy.c| 243 +++ drivers/usb/Kconfig|2 + drivers/usb/cdns3/Kconfig | 20 + drivers/usb/cdns3/Makefile |5 + drivers/usb/cdns3/cdns3-generic.c | 115 + drivers/usb/cdns3/cdns3-nxp-reg-def.h | 89 + drivers/usb/cdns3/core.c | 194 ++ drivers/usb/cdns3/core.h | 118 ++ drivers/usb/cdns3/dev-regs-macro.h | 116 + drivers/usb/cdns3/dev-regs-map.h | 117 ++ drivers/usb/cdns3/gadget-export.h | 26 + drivers/usb/cdns3/gadget.c | 2218 drivers/usb/cdns3/gadget.h | 225 ++ drivers/usb/cdns3/io.h | 30 + drivers/usb/gadget/epautoconf.c|4 + drivers/usb/gadget/gadget_chips.h |7 + drivers/usb/gadget/udc/Makefile|1 + drivers/usb/gadget/udc/udc-core.c | 23 + drivers/usb/host/Kconfig |9 + drivers/usb/host/Makefile |1 + drivers/usb/host/xhci-imx8.c | 189 ++ include/linux/usb/gadget.h |5 + scripts/Makefile.spl |1 + 27 files changed, 3807 insertions(+) create mode 100644 doc/device-tree-bindings/usb/cdns-usb3.txt create mode 100644 drivers/phy/cdns3-usb-phy.c create mode 100644 drivers/usb/cdns3/Kconfig create mode 100644 drivers/usb/cdns3/Makefile create mode 100644 drivers/usb/cdns3/cdns3-generic.c create mode 100644 drivers/usb/cdns3/cdns3-nxp-reg-def.h create mode 100644 drivers/usb/cdns3/core.c create mode 100644 drivers/usb/cdns3/core.h create mode 100644 drivers/usb/cdns3/dev-regs-macro.h create mode 100644 drivers/usb/cdns3/dev-regs-map.h create mode 100644 drivers/usb/cdns3/gadget-export.h create mode 100644 drivers/usb/cdns3/gadget.c create mode 100644 drivers/usb/cdns3/gadget.h create mode 100644 drivers/usb/cdns3/io.h create mode 100644 drivers/usb/host/xhci-imx8.c -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 00/13] powerpc: Enable device tree support
Hi Zhiqiang, > -Original Message- > From: Z.q. Hou > Sent: Thursday, June 20, 2019 1:49 PM > To: u-boot@lists.denx.de; s...@chromium.org; Prabhakar Kushwaha > ; Shengzhou Liu > ; bmeng...@gmail.com; Jagdish Gediya > ; Jiafei Pan ; Priyanka Jain > > Cc: Z.q. Hou > Subject: [PATCH 00/13] powerpc: Enable device tree support > > From: Hou Zhiqiang > > This patch is to enable device tree support for the Freescale PowerPC > platforms below. > > Hou Zhiqiang (13): > powerpc: Enable device tree support for T2080RDB > powerpc: Enable device tree support for T4240RDB > powerpc: Enable device tree support for T1024RDB > powerpc: Enable device tree support for T1042D4RDB > powerpc: Enable device tree support for P1020RDB > powerpc: Enable device tree support for P2020RDB > powerpc: Enable device tree support for P2041RDB > powerpc: Enable device tree support for P3041DS > powerpc: Enable device tree support for P4080DS > powerpc: Enable device tree support for P5040DS > powerpc: dts: add default definition of CONFIG_RESET_VECTOR_ADDRESS > powerpc: mpc8548cds: extend the reserved length for monitor > powerpc: Enable device tree support for MPC8548CDS > > arch/powerpc/dts/Makefile| 12 +++ > arch/powerpc/dts/e500mc_power_isa.dtsi | 33 ++ > arch/powerpc/dts/e500v2_power_isa.dtsi | 26 + > arch/powerpc/dts/e5500_power_isa.dtsi| 34 +++ > arch/powerpc/dts/mpc8548-post.dtsi | 27 + > arch/powerpc/dts/mpc8548.dtsi| 27 + > arch/powerpc/dts/mpc8548cds.dts | 23 + > arch/powerpc/dts/mpc8548cds_36b.dts | 23 + > arch/powerpc/dts/p1020-post.dtsi | 27 + > arch/powerpc/dts/p1020.dtsi | 31 ++ > arch/powerpc/dts/p1020rdb-pc.dts | 23 + > arch/powerpc/dts/p1020rdb-pc_36b.dts | 23 + > arch/powerpc/dts/p1020rdb-pd.dts | 23 + > arch/powerpc/dts/p2020-post.dtsi | 27 + > arch/powerpc/dts/p2020.dtsi | 31 ++ > arch/powerpc/dts/p2020rdb-pc.dts | 23 + > arch/powerpc/dts/p2020rdb-pc_36b.dts | 23 + > arch/powerpc/dts/p2041.dtsi | 63 > arch/powerpc/dts/p2041rdb.dts| 18 > arch/powerpc/dts/p3041.dtsi | 63 > arch/powerpc/dts/p3041ds.dts | 18 > arch/powerpc/dts/p4080.dtsi | 83 +++ > arch/powerpc/dts/p4080ds.dts | 18 > arch/powerpc/dts/p5040.dtsi | 62 +++ > arch/powerpc/dts/p5040ds.dts | 18 > arch/powerpc/dts/t1024rdb.dts| 17 > arch/powerpc/dts/t102x.dtsi | 52 ++ > arch/powerpc/dts/t1042d4rdb.dts | 17 > arch/powerpc/dts/t104x.dtsi | 62 +++ > arch/powerpc/dts/t2080rdb.dts| 17 > arch/powerpc/dts/t4240.dtsi | 102 +++ > arch/powerpc/dts/t4240rdb.dts| 17 > arch/powerpc/dts/u-boot.dtsi | 3 + > board/freescale/p1_p2_rdb_pc/README | 19 > board/freescale/p2041rdb/README | 18 > board/freescale/t102xrdb/README | 19 > board/freescale/t104xrdb/README | 19 > board/freescale/t208xrdb/README | 19 > configs/MPC8548CDS_36BIT_defconfig | 3 + > configs/MPC8548CDS_defconfig | 3 + > configs/MPC8548CDS_legacy_defconfig | 3 + > configs/P1020RDB-PC_36BIT_NAND_defconfig | 2 + > configs/P1020RDB-PC_36BIT_SDCARD_defconfig | 2 + > configs/P1020RDB-PC_36BIT_SPIFLASH_defconfig | 2 + > configs/P1020RDB-PC_36BIT_defconfig | 3 + > configs/P1020RDB-PC_NAND_defconfig | 2 + > configs/P1020RDB-PC_SDCARD_defconfig | 2 + > configs/P1020RDB-PC_SPIFLASH_defconfig | 2 + > configs/P1020RDB-PC_defconfig| 3 + > configs/P1020RDB-PD_NAND_defconfig | 2 + > configs/P1020RDB-PD_SDCARD_defconfig | 2 + > configs/P1020RDB-PD_SPIFLASH_defconfig | 2 + > configs/P1020RDB-PD_defconfig| 3 + > configs/P2020RDB-PC_36BIT_NAND_defconfig | 2 + > configs/P2020RDB-PC_36BIT_SDCARD_defconfig | 2 + > configs/P2020RDB-PC_36BIT_SPIFLASH_defconfig | 2 + > configs/P2020RDB-PC_36BIT_defconfig | 3 + > configs/P2020RDB-PC_NAND_defconfig | 2 + > configs/P2020RDB-PC_SDCARD_defconfig | 2 + > configs/P2020RDB-PC_SPIFLASH_defconfig | 2 + > configs/P2020RDB-PC_defconfig| 3 + > configs/P2041RDB_NAND_defconfig | 3 + > configs/P2041RDB_SDCARD_defconfig| 3 + > configs/P2041RDB_SPIFLASH_defconfig | 3 + >
