[U-Boot] [PATCH] fit: Add missing CR in debug output in fit_find_config_node()
Testing has shown that a line-break is missing in one debug line in
fit_find_config_node().
Signed-off-by: Stefan Roese
---
common/common_fit.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/common/common_fit.c b/common/common_fit.c
index c92d675a0b..3d90eef516 100644
--- a/common/common_fit.c
+++ b/common/common_fit.c
@@ -76,7 +76,7 @@ int fit_find_config_node(const void *fdt)
}
if (dflt_conf_node != -ENOENT) {
- debug("Selecting default config '%s'", dflt_conf_desc);
+ debug("Selecting default config '%s'\n", dflt_conf_desc);
return dflt_conf_node;
}
--
2.19.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 2/2] imx: mkimage: add size check to the u-boot.imx make target
[Adding Stefano] On Wed, Nov 7, 2018 at 8:41 PM Marcel Ziswiler wrote: > > From: Marcel Ziswiler > > The make macro to check if the binary exceeds the board size limit is > taken straight from the root Makefile. > > Without this and e.g. enabled EFI Vybrid fails booting as the regular > size limit check does not take the final u-boot.imx binary size into > account which is bigger due to alignment as well as IMX header stuff. > > Signed-off-by: Marcel Ziswiler Reviewed-by: Fabio Estevam Hi Stefano, maybe this could be material for 2018.11? Thanks ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [BUG] efi-x86_app_defconfig does not build with gcc 8.2
On Thu, Nov 8, 2018 at 2:28 AM Bin Meng wrote: > On Thu, Nov 8, 2018 at 2:02 AM Andy Shevchenko > wrote: > > On Mon, Oct 29, 2018 at 10:41:29PM +0800, Bin Meng wrote: > > > Here it is: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87793 > > P.S. Btw, I recommend to read a commit message to a proposed fix. > > Good idea. However I read the fix commit message and have no idea on > how to workaround in the U-Boot codes. Do you have any idea? There is no workaround, just interesting reading in my opinion. He explains what happened there and what he did to mitigate it. Basically for now it means U-Boot can't be built with gcc 8.x for x86. Of course, if you have time to try the patch and build a compiler, and try it... -- With Best Regards, Andy Shevchenko ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [BUG] efi-x86_app_defconfig does not build with gcc 8.2
Hi Andy, On Thu, Nov 8, 2018 at 2:02 AM Andy Shevchenko wrote: > > On Mon, Oct 29, 2018 at 10:41:29PM +0800, Bin Meng wrote: > > On Fri, Oct 26, 2018 at 8:41 PM Andy Shevchenko > > wrote: > > > On Fri, Oct 26, 2018 at 3:23 PM Bin Meng wrote: > > > > On Thu, Oct 25, 2018 at 10:55 PM Bin Meng wrote: > > > > > On Thu, Oct 11, 2018 at 5:36 PM Andy Shevchenko > > > > > wrote: > > > > > > > > > That's what I was suspecting after looking how EFI applications are > > > > > > being built. > > > > > > > > > > > > So, someone familiar with compilers probably needs to check the > > > > > > following and act accordingly: > > > > > > - either new compiler provides new switches to change behaviour as > > > > > > it was in GCC < 8, or > > > > > > - create a small verifiable example with this linked list sections > > > > > > and submit a bug report to GCC, or > > > > > > - U-Boot code (for linked lists) should be reconsidered from new > > > > > > requirements of the compiler, or > > > > > > - EFI U-Boot application should have it's own relocation code (like > > > > > > normal U-Boot does), or > > > > > > - ...anything I missed... > > > > > > > > > > > > The issue from my limited knowledge looks like this: > > > > > > EFI loader relies on the sections that are natural for dynamically > > > > > > linked > > > > > > libraries (AKA .so), while U-Boot (when runs on bare metal) has > > > > > > another > > > > > > approach, i.e. specific code that does a relocation based only on > > > > > > .reloc > > > > > > information. The linked list sections in U-Boot are meant to be > > > > > > statically > > > > > > compiled, which is not the case for EFI by some reason. > > > > > > > > > > > > OTOH, it's clearly a compiler behaviour change, since with -fPIC -g > > > > > > it > > > > > > generates DWARF that can't be translated by its own assembler! > > > > > > (See option 2 in above list) > > > > > > > > Thank you for these useful suggestions! I will see if I can create a > > > > > small test program to trigger this issue. > > > > > > > I created a small test case to trigger this issue. A workaround is to > > > > disable '-Os' so that the test case pass. Of course disabling '-fpic' > > > > also works. To me this looks like a bug when compiling pic codes with > > > > optimization on. I will submit a bug report go GCC. > > > > > > Cool! Please, share the bug link whenever it will be filled, thanks! > > > > > > > Sure, though waited for some time to get my GCC Bugzilla created by the > > admin .. > > > > Here it is: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87793 > > Thanks! > It seems compiler bug has been confirmed! > Yes, the bug is marked as a regression and a patch has been proposed. > P.S. Btw, I recommend to read a commit message to a proposed fix. Good idea. However I read the fix commit message and have no idea on how to workaround in the U-Boot codes. Do you have any idea? Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] Revert "board_f: Use static print_cpuinfo if CONFIG_CPU is active"
Hi Simon, On Thu, Nov 8, 2018 at 1:09 AM Simon Glass wrote: > > On 7 November 2018 at 04:50, Bin Meng wrote: > > > > This reverts commit c0434407b595f785fc7401237896c48c791b45fd. > > > > It turns out commit c0434407b595 broke some boards which have DM CPU > > driver with CONFIG_DISPLAY_CPUINFO option on. These boards just fail > > to boot when print_cpuinfo() is called during boot. > > > > Fixes are already sent to ML and in u-boot-dm/next, however since > > we are getting close to the v2018.11 release, it's safer we revert > > the original commit. > > > > This commit should be reverted after v2018.11 release. > > > > Signed-off-by: Bin Meng > > --- > > > > common/board_f.c | 28 > > include/init.h | 7 --- > > 2 files changed, 35 deletions(-) > > Thanks Bin. I'd like to get u-boot-dm/next set up ready for the merge > window, so I presume in that we need to un-revert these changes and > then pick up your two series? > That is correct. I can help test u-boot-dm/next. > Reviewed-by: Simon Glass Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 1/2] board: toradex: colibri_vf: efi_loader: unset CONFIG_EFI_UNICODE_CAPITALIZATION
On 07.11.18 23:39, Marcel Ziswiler wrote:
> From: Marcel Ziswiler
>
> Unset CONFIG_EFI_UNICODE_CAPITALIZATION on boards with tough size
> restrictions.
>
> This is analogous to commit a90bf07afc43
> ("efi_loader: unset CONFIG_EFI_UNICODE_CAPITALIZATION").
>
> Signed-off-by: Marcel Ziswiler
Reviewed-by: Alexander Graf
Alex
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v1 2/2] imx: mkimage: add size check to the u-boot.imx make target
From: Marcel Ziswiler
The make macro to check if the binary exceeds the board size limit is
taken straight from the root Makefile.
Without this and e.g. enabled EFI Vybrid fails booting as the regular
size limit check does not take the final u-boot.imx binary size into
account which is bigger due to alignment as well as IMX header stuff.
Signed-off-by: Marcel Ziswiler
---
arch/arm/mach-imx/Makefile | 16
1 file changed, 16 insertions(+)
diff --git a/arch/arm/mach-imx/Makefile b/arch/arm/mach-imx/Makefile
index 72fe23a2b9..53d9e5f42b 100644
--- a/arch/arm/mach-imx/Makefile
+++ b/arch/arm/mach-imx/Makefile
@@ -58,6 +58,21 @@ obj-$(CONFIG_CMD_HDMIDETECT) += cmd_hdmidet.o
obj-$(CONFIG_CMD_DEKBLOB) += cmd_dek.o
endif
+ifneq ($(CONFIG_BOARD_SIZE_LIMIT),)
+BOARD_SIZE_CHECK = \
+@actual=`wc -c $@ | awk '{print $$1}'`; \
+limit=`printf "%d" $(CONFIG_BOARD_SIZE_LIMIT)`; \
+if test $$actual -gt $$limit; then \
+echo "$@ exceeds file size limit:" >&2 ; \
+echo " limit: $$limit bytes" >&2 ; \
+echo " actual: $$actual bytes" >&2 ; \
+echo " excess: $$((actual - limit)) bytes" >&2; \
+exit 1; \
+fi
+else
+BOARD_SIZE_CHECK =
+endif
+
PLUGIN = board/$(BOARDDIR)/plugin
ifeq ($(CONFIG_USE_IMXIMG_PLUGIN),y)
@@ -101,6 +116,7 @@ u-boot.imx: MKIMAGEOUTPUT = u-boot.imx.log
u-boot.imx: u-boot.bin u-boot.cfgout $(PLUGIN).bin FORCE
$(call if_changed,mkimage)
+ $(BOARD_SIZE_CHECK)
ifeq ($(CONFIG_OF_SEPARATE),y)
MKIMAGEFLAGS_u-boot-dtb.imx = -n $(filter-out $(PLUGIN).bin $< $(PHONY),$^) \
--
2.14.5
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v1 1/2] board: toradex: colibri_vf: efi_loader: unset CONFIG_EFI_UNICODE_CAPITALIZATION
From: Marcel Ziswiler
Unset CONFIG_EFI_UNICODE_CAPITALIZATION on boards with tough size
restrictions.
This is analogous to commit a90bf07afc43
("efi_loader: unset CONFIG_EFI_UNICODE_CAPITALIZATION").
Signed-off-by: Marcel Ziswiler
---
configs/colibri_vf_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/configs/colibri_vf_defconfig b/configs/colibri_vf_defconfig
index 5854910f7b..38f450c8ed 100644
--- a/configs/colibri_vf_defconfig
+++ b/configs/colibri_vf_defconfig
@@ -72,3 +72,4 @@ CONFIG_VIDEO_FSL_DCU_FB=y
CONFIG_VIDEO=y
CONFIG_SYS_CONSOLE_FG_COL=0x00
CONFIG_OF_LIBFDT_OVERLAY=y
+# CONFIG_EFI_UNICODE_CAPITALIZATION is not set
--
2.14.5
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] Booting i.MX6UL via SPL?
Hi All, I've been trying to boot a i.MX6UL based device I have here using SPL. It doesn't seem to want to work for me. I see there's a number of i.MX6UL ports in U-Boot already, some use a custom DCD to configure the board, others seem to provide both options (DCD and SPL). Interestingly the Freescale i.MX 6UltraLite Evaluation Kit port (via mx6ul_14x14_evk_defconfig) appears to be using the SPL mechanism exclusively. Can someone confirm that the above device boots using this config from SD card? I seem to be able to boot from SD card using a custom DCD (which copies U-Boot into RAM), I'm also able to get the SPL to boot via USB (which copies the SPL to OCRAM). However when I try to boot the SPL from SD card it doesn't boot. If I boot the SPL via USB, insert an SD card and reset the device, it seems to boot from the SPL previously loaded from USB (as in it's still in the OCRAM) but carries on like it's booted from the SD card (looking on the SD card rather than USB for the main U-Boot image). The reason I think it's doing this is that if I rebuild U-Boot and flash a copy with an updated build time to the SD card, when I perform a reset I still see the old build time in the U-Boot banner. It looks to me like for some reason it's unable to copy the SPL to OCRAM, but carries on thinking it has. Anyone got any pointers? Thanks in advance, Martyn ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] error in the make: bad value in the asm-offsets.c file
Hi Ian, Sarah, On Thu, 8 Nov 2018, 6:09 AM Ian Kane Sarah, > > It looks to me from the attached image that the error is related to an > expected, but missing value for the -march flag. > To me, I'd expect to see "-march=ARMv5 switch" instead of "-march= > switch". Make note of the empty space in the second. > > However I defer to anyone else more knowledgeable on the subject, I'm very > new user of the project myself. > Yes you are on the right track. > > Best regards, > - Ian > > From: U-Boot on behalf of Sarah Wicker > > Sent: Wednesday, November 7, 2018 11:19 AM > To: u-boot@lists.denx.de > Subject: [U-Boot] error in the make: bad value in the asm-offsets.c file > > Good Morning, > i am trying to compile u-boot on my pc to use it for a ZedBoard from > Xilinx. > I cloned the repository u-boot-xlnx using this link: > https://github.com/Xilinx/u-boot-xlnx.git > Made the first make to build the U-boot for a ZedBoard, it works well. > Asked for the second make and i received the message that in the file > asm-offsets.c:1:0: error: bad value (armv5) for -march=switch > I opened the file but couldn't see were was this value > > [cid:image001.jpg@01D476BE.1BC339F0] > > For information i am trying to compile on a virtual machine using > Debian9.5.0 > > I thank you in advance for your help > The problem is more than likely that you are using the host compiler, which is probably x86 and doesn know how to generate output for arm. To compile for an embedded target you need a suitable cross compiler. For debian i believe there is a packaged arm compiler so it should just be a matter of sudo apt install gcc-arm-linux-gnueabi export CROSS_COMPILE=gcc-arm-linux-gnueabi make ZedBoard_defconfig make The lastest u-boot does require a fairly up to date gcc for arm. I'm not sure what debian ship. But if you get errors about the cross compiler being too old you might need to grab a more recent compiler from https://www.kernel.org/pub/tools/crosstool/ or the excellent https://toolchains.bootlin.com/ ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] linux/sizes.h: sync from kernel
On Wed, Nov 07, 2018 at 09:40:39AM +0200, Baruch Siach wrote: > The kernel added SZ_4G macro in commit f2b9ba871b (arm64/kernel: kaslr: > reduce module randomization range to 4 GB). > > Include common.h for _AC() instead of the kernel linux/const.h header. > > Drop a local SZ_4G definition in tegra code. > > Cc: Tom Warren > Signed-off-by: Baruch Siach > --- > v2: No change > --- > arch/arm/mach-tegra/tegra186/nvtboot_mem.c | 3 +-- > include/linux/sizes.h | 4 > 2 files changed, 5 insertions(+), 2 deletions(-) > > diff --git a/arch/arm/mach-tegra/tegra186/nvtboot_mem.c > b/arch/arm/mach-tegra/tegra186/nvtboot_mem.c > index 5c9467bfe8be..62142821a595 100644 > --- a/arch/arm/mach-tegra/tegra186/nvtboot_mem.c > +++ b/arch/arm/mach-tegra/tegra186/nvtboot_mem.c > @@ -6,11 +6,10 @@ > #include > #include > #include > +#include > #include > #include > > -#define SZ_4G 0x1ULL > - > /* > * Size of a region that's large enough to hold the relocated U-Boot and all > * other allocations made around it (stack, heap, page tables, etc.) > diff --git a/include/linux/sizes.h b/include/linux/sizes.h > index ce3e8150c174..9f3c13ee459b 100644 > --- a/include/linux/sizes.h > +++ b/include/linux/sizes.h > @@ -8,6 +8,8 @@ > #ifndef __LINUX_SIZES_H__ > #define __LINUX_SIZES_H__ > > +#include > + > #define SZ_1 0x0001 > #define SZ_2 0x0002 > #define SZ_4 0x0004 > @@ -44,4 +46,6 @@ > #define SZ_1G0x4000 > #define SZ_2G0x8000 > > +#define SZ_4G_AC(0x1, ULL) > + > #endif /* __LINUX_SIZES_H__ */ I think this is moving things in the wrong direction. In fact, 2a6713b09b8da58572338abac276aa764bb6eadd took things in the wrong direction. We need to import linux/const.h (and just combine uapi/linux/const.h with linux/const.h) with the _AC macro and then add in SZ_4G. -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/2] image-sig: Ensure that hashed-nodes is null-terminated
From: Konrad Beckmann
A specially crafted FIT image leads to memory corruption in the stack
when using the verified boot feature. The function fit_config_check_sig
has a logic error that makes it possible to write past the end of the
stack allocated array node_inc. This could potentially be used to bypass
the signature check when using verified boot.
This change ensures that the number of strings is correct when counted.
Signed-off-by: Konrad Beckmann
---
common/image-sig.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/common/image-sig.c b/common/image-sig.c
index 5a269d3289bf..5d860e126637 100644
--- a/common/image-sig.c
+++ b/common/image-sig.c
@@ -334,6 +334,11 @@ int fit_config_check_sig(const void *fit, int noffset, int
required_keynode,
return -1;
}
+ if (prop && prop_len > 0 && prop[prop_len - 1] != '\0') {
+ *err_msgp = "hashed-nodes property must be null-terminated";
+ return -1;
+ }
+
/* Add a sanity check here since we are using the stack */
if (count > IMAGE_MAX_HASHED_NODES) {
*err_msgp = "Number of hashed nodes exceeds maximum";
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/2] fdt_region: Ensure that depth never goes below -1
From: Konrad Beckmann A specially crafted FIT image makes it possible to overflow the stack with controlled values when using the verified boot feature. Depending on the memory layout, this could be used to overwrite configuration variables on the heap and setting them to 0, e.g. disable signature verification, thus bypassing it. This change fixes a bug in fdt_find_regions where the fdt structure is parsed. A lower value than -1 of depth can lead to a buffer underflow write on the stack. Signed-off-by: Konrad Beckmann --- lib/libfdt/fdt_region.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/lib/libfdt/fdt_region.c b/lib/libfdt/fdt_region.c index d3b9a60e994f..7e9fa9272e80 100644 --- a/lib/libfdt/fdt_region.c +++ b/lib/libfdt/fdt_region.c @@ -96,6 +96,9 @@ int fdt_find_regions(const void *fdt, char * const inc[], int inc_count, break; case FDT_END_NODE: + /* Depth must never go below -1 */ + if (depth < 0) + return -FDT_ERR_BADSTRUCTURE; include = want; want = stack[depth--]; while (end > path && *--end != '/') -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, 2/2] imx8qxp_mek: Disable CONFIG_DISPLAY_CPUINFO
On Wed, Nov 07, 2018 at 03:50:35AM -0800, Bin Meng wrote: > Due to revert of commit c0434407b595, this board does not build > any more. Disable CONFIG_DISPLAY_CPUINFO for v2018.11 release. > > This commit should be reverted after v2018.11 release. > > Signed-off-by: Bin Meng > Acked-by: Peng Fan > Reviewed-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, 1/2] Revert "board_f: Use static print_cpuinfo if CONFIG_CPU is active"
On Wed, Nov 07, 2018 at 03:50:34AM -0800, Bin Meng wrote: > This reverts commit c0434407b595f785fc7401237896c48c791b45fd. > > It turns out commit c0434407b595 broke some boards which have DM CPU > driver with CONFIG_DISPLAY_CPUINFO option on. These boards just fail > to boot when print_cpuinfo() is called during boot. > > Fixes are already sent to ML and in u-boot-dm/next, however since > we are getting close to the v2018.11 release, it's safer we revert > the original commit. > > This commit should be reverted after v2018.11 release. > > Signed-off-by: Bin Meng > Acked-by: Peng Fan > Reviewed-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [GIT PULL] Xilinx fixes for v2018.11-rc3
On Wed, Nov 07, 2018 at 10:09:42AM +0100, Michal Simek wrote: > Hi Tom, > > please pull this one patch to your tree. > > Thanks, > Michal > > The following changes since commit dd610e616cceda16a81dfa6f9a134877f783548c: > > Merge tag 'u-boot-imx-20181106' of git://git.denx.de/u-boot-imx > (2018-11-06 11:12:00 -0500) > > are available in the git repository at: > > > git://www.denx.de/git/u-boot-microblaze.git tags/xilinx-for-v2018.11-rc3 > > for you to fetch changes up to acb83bb3ec4fd7f52c600244daa5d8caa53a4924: > > arm: zynq: Setup non zero SPL FIT load address (2018-11-07 10:07:31 +0100) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [BUG] efi-x86_app_defconfig does not build with gcc 8.2
On Mon, Oct 29, 2018 at 10:41:29PM +0800, Bin Meng wrote: > On Fri, Oct 26, 2018 at 8:41 PM Andy Shevchenko > wrote: > > On Fri, Oct 26, 2018 at 3:23 PM Bin Meng wrote: > > > On Thu, Oct 25, 2018 at 10:55 PM Bin Meng wrote: > > > > On Thu, Oct 11, 2018 at 5:36 PM Andy Shevchenko > > > > wrote: > > > > > > > That's what I was suspecting after looking how EFI applications are > > > > > being built. > > > > > > > > > > So, someone familiar with compilers probably needs to check the > > > > > following and act accordingly: > > > > > - either new compiler provides new switches to change behaviour as it > > > > > was in GCC < 8, or > > > > > - create a small verifiable example with this linked list sections > > > > > and submit a bug report to GCC, or > > > > > - U-Boot code (for linked lists) should be reconsidered from new > > > > > requirements of the compiler, or > > > > > - EFI U-Boot application should have it's own relocation code (like > > > > > normal U-Boot does), or > > > > > - ...anything I missed... > > > > > > > > > > The issue from my limited knowledge looks like this: > > > > > EFI loader relies on the sections that are natural for dynamically > > > > > linked > > > > > libraries (AKA .so), while U-Boot (when runs on bare metal) has > > > > > another > > > > > approach, i.e. specific code that does a relocation based only on > > > > > .reloc > > > > > information. The linked list sections in U-Boot are meant to be > > > > > statically > > > > > compiled, which is not the case for EFI by some reason. > > > > > > > > > > OTOH, it's clearly a compiler behaviour change, since with -fPIC -g it > > > > > generates DWARF that can't be translated by its own assembler! > > > > > (See option 2 in above list) > > > > > > Thank you for these useful suggestions! I will see if I can create a > > > > small test program to trigger this issue. > > > > > I created a small test case to trigger this issue. A workaround is to > > > disable '-Os' so that the test case pass. Of course disabling '-fpic' > > > also works. To me this looks like a bug when compiling pic codes with > > > optimization on. I will submit a bug report go GCC. > > > > Cool! Please, share the bug link whenever it will be filled, thanks! > > > > Sure, though waited for some time to get my GCC Bugzilla created by the admin > .. > > Here it is: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87793 Thanks! It seems compiler bug has been confirmed! P.S. Btw, I recommend to read a commit message to a proposed fix. -- With Best Regards, Andy Shevchenko ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] sunxi: Fix memory 2-rank initialization for a33 cpu
Hi Jagan On Mon, Nov 5, 2018 at 10:02 AM Maxime Ripard wrote: > > On Wed, Oct 31, 2018 at 08:03:16PM +0100, Michael Trimarchi wrote: > > When we initialize the memory we need to autodetect rank and size > > but this can happen only if we send the proper reset to both > > memory module including cke signal. > > For this reason we need initialize the physical on both channel because > > we need to presume that both are connected. This way let the CLKE to be > > activated at the right time with the memory reset coming from the cpu > > > > Signed-off-by: Michael Trimarchi > > Acked-by: Maxime Ripard > Can you test on a consumer board with A33? I have tested over oscilloscope on my device Michael > Maxime > > -- > Maxime Ripard, Bootlin > Embedded Linux and Kernel engineering > https://bootlin.com -- | Michael Nazzareno Trimarchi Amarula Solutions BV | | COO - Founder Cruquiuskade 47 | | +31(0)851119172 Amsterdam 1018 AM NL | | [`as] http://www.amarulasolutions.com | ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] imx8qxp_mek: Disable CONFIG_DISPLAY_CPUINFO
On 7 November 2018 at 04:50, Bin Meng wrote: > Due to revert of commit c0434407b595, this board does not build > any more. Disable CONFIG_DISPLAY_CPUINFO for v2018.11 release. > > This commit should be reverted after v2018.11 release. > > Signed-off-by: Bin Meng > --- > > configs/imx8qxp_mek_defconfig | 1 + > 1 file changed, 1 insertion(+) > Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 12/25] spl: Correct malloc debugging in board_init_r()
Hi Simon, On 6 November 2018 at 23:22, Simon Goldschmidt wrote: > On Tue, Nov 6, 2018 at 11:22 PM Simon Glass wrote: >> >> SPL does not support %#x in printf() strings so we must write out the 0x >> explicitly. Update the code for this. >> >> Signed-off-by: Simon Glass > > This has already been covered by my patch here: > https://patchwork.ozlabs.org/patch/992555/ > > However, my patch fixes three more places of debug printf formatters > not supported in SPL. > > Anyway: > Reviewed-by: Simon Goldschmidt > Yes, we should grab your one. Will mark this one superseded. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] Revert "board_f: Use static print_cpuinfo if CONFIG_CPU is active"
On 7 November 2018 at 04:50, Bin Meng wrote: > > This reverts commit c0434407b595f785fc7401237896c48c791b45fd. > > It turns out commit c0434407b595 broke some boards which have DM CPU > driver with CONFIG_DISPLAY_CPUINFO option on. These boards just fail > to boot when print_cpuinfo() is called during boot. > > Fixes are already sent to ML and in u-boot-dm/next, however since > we are getting close to the v2018.11 release, it's safer we revert > the original commit. > > This commit should be reverted after v2018.11 release. > > Signed-off-by: Bin Meng > --- > > common/board_f.c | 28 > include/init.h | 7 --- > 2 files changed, 35 deletions(-) Thanks Bin. I'd like to get u-boot-dm/next set up ready for the merge window, so I presume in that we need to un-revert these changes and then pick up your two series? Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] error in the make: bad value in the asm-offsets.c file
Sarah, It looks to me from the attached image that the error is related to an expected, but missing value for the -march flag. To me, I'd expect to see "-march=ARMv5 switch" instead of "-march= switch". Make note of the empty space in the second. However I defer to anyone else more knowledgeable on the subject, I'm very new user of the project myself. Best regards, - Ian From: U-Boot on behalf of Sarah Wicker Sent: Wednesday, November 7, 2018 11:19 AM To: u-boot@lists.denx.de Subject: [U-Boot] error in the make: bad value in the asm-offsets.c file Good Morning, i am trying to compile u-boot on my pc to use it for a ZedBoard from Xilinx. I cloned the repository u-boot-xlnx using this link: https://github.com/Xilinx/u-boot-xlnx.git Made the first make to build the U-boot for a ZedBoard, it works well. Asked for the second make and i received the message that in the file asm-offsets.c:1:0: error: bad value (armv5) for -march=switch I opened the file but couldn't see were was this value [cid:image001.jpg@01D476BE.1BC339F0] For information i am trying to compile on a virtual machine using Debian9.5.0 I thank you in advance for your help Sarah Wicker ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] error in the make: bad value in the asm-offsets.c file
Good Morning, i am trying to compile u-boot on my pc to use it for a ZedBoard from Xilinx. I cloned the repository u-boot-xlnx using this link: https://github.com/Xilinx/u-boot-xlnx.git Made the first make to build the U-boot for a ZedBoard, it works well. Asked for the second make and i received the message that in the file asm-offsets.c:1:0: error: bad value (armv5) for -march=switch I opened the file but couldn't see were was this value [cid:image001.jpg@01D476BE.1BC339F0] For information i am trying to compile on a virtual machine using Debian9.5.0 I thank you in advance for your help Sarah Wicker ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Some tegra cleanups and Kconfig migrations
Peter, The SYS_I2C patch doesn't apply cleanly to TOT u-boot-tegra/master (see below git am spew). Please take a look & let me know when you've resent a fixed patchset and I'll retry. Tom tom@tom-lt2:~/denx/uboot-tegra$ git am -s --whitespace=strip ~/Downloads/bundle-17667-Peter-cleanup-6.mbox Applying: tegra: cleanup dangling comments in include/configs Applying: tegra20: common: fix USB_EHCI_TXFIFO_THRESH value Applying: Kconfig: tegra: Migrate SYS_I2C_TEGRA error: patch failed: configs/apalis-tk1_defconfig:29 error: configs/apalis-tk1_defconfig: patch does not apply error: patch failed: configs/apalis_t30_defconfig:26 error: configs/apalis_t30_defconfig: patch does not apply error: patch failed: configs/beaver_defconfig:26 error: configs/beaver_defconfig: patch does not apply error: patch failed: configs/cardhu_defconfig:23 error: configs/cardhu_defconfig: patch does not apply error: patch failed: configs/cei-tk1-som_defconfig:25 error: configs/cei-tk1-som_defconfig: patch does not apply error: patch failed: configs/colibri_t20_defconfig:33 error: configs/colibri_t20_defconfig: patch does not apply error: patch failed: configs/colibri_t30_defconfig:25 error: configs/colibri_t30_defconfig: patch does not apply error: patch failed: configs/dalmore_defconfig:25 error: configs/dalmore_defconfig: patch does not apply error: patch failed: configs/jetson-tk1_defconfig:26 error: configs/jetson-tk1_defconfig: patch does not apply error: patch failed: configs/nyan-big_defconfig:41 error: configs/nyan-big_defconfig: patch does not apply error: patch failed: configs/p2771--000_defconfig:20 error: configs/p2771--000_defconfig: patch does not apply error: patch failed: configs/p2771--500_defconfig:20 error: configs/p2771--500_defconfig: patch does not apply error: patch failed: configs/seaboard_defconfig:22 error: configs/seaboard_defconfig: patch does not apply error: patch failed: configs/tec-ng_defconfig:23 error: configs/tec-ng_defconfig: patch does not apply error: patch failed: configs/trimslice_defconfig:24 error: configs/trimslice_defconfig: patch does not apply error: patch failed: configs/venice2_defconfig:24 error: configs/venice2_defconfig: patch does not apply Patch failed at 0003 Kconfig: tegra: Migrate SYS_I2C_TEGRA The copy of the patch that failed is found in: /home/tom/denx/uboot-tegra/.git/rebase-apply/patch When you have resolved this problem, run "git am --resolved". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". -Original Message- From: Tom Warren Sent: Wednesday, November 7, 2018 8:17 AM To: Peter Robinson ; u-boot@lists.denx.de; Tom Rini Subject: RE: Some tegra cleanups and Kconfig migrations Sorry, Peter. I missed these. I'll take a look today and get a PR out to Tom before EOW. -Original Message- From: Peter Robinson Sent: Wednesday, November 7, 2018 7:12 AM To: u-boot@lists.denx.de; Tom Warren ; Tom Rini Subject: Re: Some tegra cleanups and Kconfig migrations Tom or Tom, Any chance we could get these reviewed and merged, mostly generic cleanups so I don't think most of them are controversial. Peter On Sun, Sep 16, 2018 at 6:23 PM Peter Robinson wrote: > > The following patches are a few cleanups to dangling comments from > Kconfig cleanups and migrations of SYS_I2C_TEGRA, USB_EHCI_TEGRA and > TEGRA_KEYBOARD. > There's also a couple of other minors fixes and cleanups as well. --- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. --- ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Some tegra cleanups and Kconfig migrations
Sorry, Peter. I missed these. I'll take a look today and get a PR out to Tom before EOW. -Original Message- From: Peter Robinson Sent: Wednesday, November 7, 2018 7:12 AM To: u-boot@lists.denx.de; Tom Warren ; Tom Rini Subject: Re: Some tegra cleanups and Kconfig migrations Tom or Tom, Any chance we could get these reviewed and merged, mostly generic cleanups so I don't think most of them are controversial. Peter On Sun, Sep 16, 2018 at 6:23 PM Peter Robinson wrote: > > The following patches are a few cleanups to dangling comments from > Kconfig cleanups and migrations of SYS_I2C_TEGRA, USB_EHCI_TEGRA and > TEGRA_KEYBOARD. > There's also a couple of other minors fixes and cleanups as well. --- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. --- ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 9/9] ARM: Exynos: Add Exynos5433 based TM2 board support
This patch adds support for Exynos5433 based TM2 and TM2e boards.
u-boot is used to load and decompress kernel image or alternatively
(when 'volume down' button is pressed during boot) provide THOR download
USB feature for flashing kernel and rootfs images.
Based on earlier work done by Lukasz Majewski .
Signed-off-by: Marek Szyprowski
---
arch/arm/dts/Makefile | 3 +
arch/arm/dts/exynos5433-tm2.dts | 37 ++
arch/arm/mach-exynos/Kconfig| 14
board/samsung/tm2/Kconfig | 14
board/samsung/tm2/Makefile | 8 ++
board/samsung/tm2/tm2.c | 127
configs/tm2_defconfig | 52 +
include/configs/tm2.h | 60 +++
8 files changed, 315 insertions(+)
create mode 100644 arch/arm/dts/exynos5433-tm2.dts
create mode 100644 board/samsung/tm2/Kconfig
create mode 100644 board/samsung/tm2/Makefile
create mode 100644 board/samsung/tm2/tm2.c
create mode 100644 configs/tm2_defconfig
create mode 100644 include/configs/tm2.h
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index d36447d18d..f8c671589a 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -25,6 +25,9 @@ dtb-$(CONFIG_EXYNOS5) += exynos5250-arndale.dtb \
exynos5800-peach-pi.dtb \
exynos5422-odroidxu3.dtb
dtb-$(CONFIG_EXYNOS7420) += exynos7420-espresso7420.dtb
+
+dtb-$(CONFIG_TARGET_TM2) += exynos5433-tm2.dtb
+
dtb-$(CONFIG_ARCH_ROCKCHIP) += \
rk3036-sdk.dtb \
rk3128-evb.dtb \
diff --git a/arch/arm/dts/exynos5433-tm2.dts b/arch/arm/dts/exynos5433-tm2.dts
new file mode 100644
index 00..c9b178efdc
--- /dev/null
+++ b/arch/arm/dts/exynos5433-tm2.dts
@@ -0,0 +1,37 @@
+/*
+ * TM2 device tree source
+ *
+ * Copyright (c) 2018 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+/dts-v1/;
+#include "exynos5433.dtsi"
+
+/ {
+ model = "TM2 based on EXYNOS5433";
+ compatible = "samsung,tm2", "samsung,exynos5433";
+
+ aliases {
+ serial0 = &serial_1;
+ console = &serial_1;
+ i2c0 = &i2c;
+ };
+
+ i2c: i2c {
+ compatible = "i2c-gpio";
+ gpios = <&gpb0 0 0>,/* sda */
+ <&gpb0 1 0>;/* scl */
+ i2c-gpio,delay-us = <2>;/* ~100 kHz */
+ };
+};
+
+&mmc_0 {
+ status = "okay";
+};
+
+&serial_1 {
+ status = "okay";
+};
diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index 4a49c8dcc2..cf3bed57f3 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -137,6 +137,19 @@ config TARGET_PEACH_PIT
endchoice
endif
+if ARCH_EXYNOS5433
+
+choice
+ prompt "EXYNOS5433 board select"
+
+config TARGET_TM2
+ bool "TM2 board"
+ select ARM64
+ select OF_CONTROL
+
+endchoice
+endif
+
if ARCH_EXYNOS7
choice
@@ -168,6 +181,7 @@ source "board/samsung/odroid/Kconfig"
source "board/samsung/arndale/Kconfig"
source "board/samsung/smdk5250/Kconfig"
source "board/samsung/smdk5420/Kconfig"
+source "board/samsung/tm2/Kconfig"
source "board/samsung/espresso7420/Kconfig"
config SPL_LDSCRIPT
diff --git a/board/samsung/tm2/Kconfig b/board/samsung/tm2/Kconfig
new file mode 100644
index 00..745faf6a95
--- /dev/null
+++ b/board/samsung/tm2/Kconfig
@@ -0,0 +1,14 @@
+if TARGET_TM2
+
+config SYS_BOARD
+ default "tm2"
+ help
+ TM2 is Exynos5433 SoC based board, Tizen reference board.
+
+config SYS_VENDOR
+ default "samsung"
+
+config SYS_CONFIG_NAME
+ default "tm2"
+
+endif
diff --git a/board/samsung/tm2/Makefile b/board/samsung/tm2/Makefile
new file mode 100644
index 00..53621774dd
--- /dev/null
+++ b/board/samsung/tm2/Makefile
@@ -0,0 +1,8 @@
+#
+# Copyright (c) 2016 Samsung Electronics Co., Ltd. All rights reserved.
+# Lukasz Majewski
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+
+obj-y := tm2.o
diff --git a/board/samsung/tm2/tm2.c b/board/samsung/tm2/tm2.c
new file mode 100644
index 00..31ec8f5641
--- /dev/null
+++ b/board/samsung/tm2/tm2.c
@@ -0,0 +1,127 @@
+/*
+ * (C) Copyright 2018 Samsung
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+DECLARE_GLOBAL_DATA_PTR;
+
+int board_init(void)
+{
+ /* start Multi Core Timer to get ARM Architected Timers working */
+ writel(1 << 8, 0x101c0240);
+ return 0;
+}
+
+int dram_init(void)
+{
+ gd->ram_size = PHYS_SDRAM_1_SIZE;
+ return 0;
+}
+
+int dram_init_banksize(void)
+{
+ gd->bd->bi_dram[0].start = PHYS_SDRAM_1;
+ gd->bd->bi_dram[0].size = PHYS_SDRAM_1_SIZE;
+ return 0;
+}
+
+unsigned long get_uart_clk(int id)
+{
+ return 2;
+}
+
+unsigned long get_mmc_clk(int id)
+{
+ return 1;
+}
+
+unsi
[U-Boot] [PATCH 8/9] ARM: Exynos: Add minimal support for ARM 64bit based Exynos5433 SoC
This patch adds minimal support for Exynos5433 SoC (ARM64 based).
The following devices are supported:
- mmc0 (for eMMC)
- serial1 (for debug/console)
- gpa0..3 and gpb0..2 GPIO banks
Based on earlier work done by Lukasz Majewski .
Signed-off-by: Marek Szyprowski
---
arch/arm/cpu/armv8/Kconfig | 2 +-
arch/arm/dts/exynos5433.dtsi | 84
arch/arm/mach-exynos/Kconfig | 7 +++
arch/arm/mach-exynos/mmu-arm64.c | 24 +
arch/arm/mach-exynos/soc.c | 3 ++
drivers/gpio/s5p_gpio.c | 1 +
scripts/config_whitelist.txt | 1 +
7 files changed, 121 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/dts/exynos5433.dtsi
diff --git a/arch/arm/cpu/armv8/Kconfig b/arch/arm/cpu/armv8/Kconfig
index c8bebabdf6..295cdd4653 100644
--- a/arch/arm/cpu/armv8/Kconfig
+++ b/arch/arm/cpu/armv8/Kconfig
@@ -96,7 +96,7 @@ endmenu
config PSCI_RESET
bool "Use PSCI for reset and shutdown"
default y
- depends on !ARCH_EXYNOS7 && !ARCH_BCM283X && \
+ depends on !ARCH_EXYNOS5433 && !ARCH_EXYNOS7 && !ARCH_BCM283X && \
!TARGET_LS2080A_SIMU && !TARGET_LS2080AQDS && \
!TARGET_LS2080ARDB && !TARGET_LS2080A_EMU && \
!TARGET_LS1088ARDB && !TARGET_LS1088AQDS && \
diff --git a/arch/arm/dts/exynos5433.dtsi b/arch/arm/dts/exynos5433.dtsi
new file mode 100644
index 00..509b39a95f
--- /dev/null
+++ b/arch/arm/dts/exynos5433.dtsi
@@ -0,0 +1,84 @@
+/*
+ * SAMSUNG EXYNOS5433 SoC device tree source
+ *
+ * Copyright (c) 2018 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+/dts-v1/;
+#include "skeleton.dtsi"
+
+/ {
+ mmc_0: mmc@1554 {
+ compatible = "samsung,exynos-dwmmc";
+ reg = <0x0 0x1554 0x0 0x1000>;
+ samsung,bus-width = <8>;
+ samsung,timing = <1 3 3>;
+ samsung,removable = <0>;
+ samsung,pre-init;
+ fifoth_val = <0x201f0020>;
+ status = "disabled";
+ };
+
+ pinctrl_alive: pinctrl@1058 {
+ compatible = "samsung,exynos5433-pinctrl";
+ reg = <0x1058 0x1a20>, <0x1109 0x100>;
+ /* gpa0..3, gpf1..5 */
+
+ gpa0: gpa0 {
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+ gpa1: gpa1 {
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+ gpa2: gpa2 {
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+ gpa3: gpa3 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ };
+ };
+
+ pinctrl_peric: pinctrl@14cc {
+ compatible = "samsung,exynos5433-pinctrl";
+ reg = <0x14cc 0x1100>;
+ /* gpv7, gpb0, gpc0..3, gpg0, gpd0..4,6,8,7, gpg1..3 */
+
+ gpv7: gpv7 {
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+ gpb0: gpb0 {
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+ gpb1: gpb1 {
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+ gpb2: gpb2 {
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+ };
+
+ serial_1: serial@14c2 {
+ compatible = "samsung,exynos4210-uart";
+ reg = <0x14c2 0x100>;
+ id = <1>;
+ status = "disabled";
+ };
+};
diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index ed04369cfa..4a49c8dcc2 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -29,6 +29,13 @@ config ARCH_EXYNOS5
Cortex-A7 CPU in big.LITTLE configuration). There are multiple SoCs
in this family including Exynos5250, Exynos5420 and Exynos5800.
+config ARCH_EXYNOS5433
+ bool "Exynos5433 SoC family"
+ select ARM64
+ help
+ Samsung Exynos5433 SoC family are based on ARM Cortex-A57 CPU and
+ Cortex-A53 CPU (in a big.LITTLE configuration).
+
config ARCH_EXYNOS7
bool "Exynos7 SoC family"
select ARM64
diff --git a/arch/arm/mach-exynos/mmu-arm64.c b/arch/arm/mach-exynos/mmu-arm64.c
index 46b8169d19..a857a7318e 100644
--- a/arch/arm/mach-exynos/mmu-arm64.c
+++ b/arch/arm/mach-exynos/mmu-arm64.c
@@ -29,3 +29,27 @@ static struct mm_region exynos7420_mem_map[] = {
struct mm_region *mem_map = exynos7420_mem_map;
#endif
+
+#ifdef CONFIG_EXYNOS5433
+static struct mm_region exynos5433_mem_map[] = {
+ {
+ .virt = 0xUL,
+
[U-Boot] [PATCH 7/9] arm: armv8: add support for boards with broken/unset counter frequency
Some boards use legacy firmware which doesn't properly configure ARM
architected timer registers. This patch adds a workaround to use the
defined COUNTER_FREQUENCY instead of reading its value from the timer
registers.
Signed-off-by: Marek Szyprowski
---
arch/arm/cpu/armv8/generic_timer.c | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/cpu/armv8/generic_timer.c
b/arch/arm/cpu/armv8/generic_timer.c
index c1706dcec1..5ac62a0a32 100644
--- a/arch/arm/cpu/armv8/generic_timer.c
+++ b/arch/arm/cpu/armv8/generic_timer.c
@@ -15,9 +15,13 @@ DECLARE_GLOBAL_DATA_PTR;
*/
unsigned long get_tbclk(void)
{
+#ifndef COUNTER_FREQUENCY
unsigned long cntfrq;
asm volatile("mrs %0, cntfrq_el0" : "=r" (cntfrq));
return cntfrq;
+#else
+ return COUNTER_FREQUENCY;
+#endif
}
#ifdef CONFIG_SYS_FSL_ERRATUM_A008585
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 6/9] mmc: exynos_dw_mmc: fix compilation on ARM64-based Exynos
From: Lukasz Majewski
Disable some legacy code to let it work on ARM64 based Exynos SoCs.
Signed-off-by: Lukasz Majewski
[extracted from old sources and adapted to mainline u-boot, minor fixes]
Signed-off-by: Marek Szyprowski
---
drivers/mmc/exynos_dw_mmc.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/mmc/exynos_dw_mmc.c b/drivers/mmc/exynos_dw_mmc.c
index 3e9d47538c..c7ba3b6060 100644
--- a/drivers/mmc/exynos_dw_mmc.c
+++ b/drivers/mmc/exynos_dw_mmc.c
@@ -143,6 +143,7 @@ static struct dwmci_host dwmci_host[DWMMC_MAX_CH_NUM];
static int do_dwmci_init(struct dwmci_host *host)
{
+#ifdef CONFIG_CPU_V7A
int flag, err;
flag = host->buswidth == 8 ? PINMUX_FLAG_8BIT_MODE : PINMUX_FLAG_NONE;
@@ -151,6 +152,7 @@ static int do_dwmci_init(struct dwmci_host *host)
printf("DWMMC%d not configure\n", host->dev_index);
return err;
}
+#endif
return exynos_dwmci_core_init(host);
}
@@ -160,10 +162,15 @@ static int exynos_dwmci_get_config(const void *blob, int
node,
struct dwmci_exynos_priv_data *priv)
{
int err = 0;
- u32 base, timing[3];
+ dma_addr_t base;
+ u32 timing[3];
+#ifdef CONFIG_CPU_V7A
/* Extract device id for each mmc channel */
host->dev_id = pinmux_decode_periph_id(blob, node);
+#else
+ host->dev_id = 0;
+#endif
host->dev_index = fdtdec_get_int(blob, node, "index", host->dev_id);
if (host->dev_index == host->dev_id)
@@ -247,19 +254,20 @@ static int exynos_dwmci_process_node(const void *blob,
int exynos_dwmmc_init(const void *blob)
{
int node_list[DWMMC_MAX_CH_NUM];
- int boot_dev_node;
int err = 0, count;
count = fdtdec_find_aliases_for_id(blob, "mmc",
COMPAT_SAMSUNG_EXYNOS_DWMMC, node_list,
DWMMC_MAX_CH_NUM);
+#ifdef CONFIG_CPU_V7A
/* For DWMMC always set boot device as mmc 0 */
if (count >= 3 && get_boot_mode() == BOOT_MODE_SD) {
- boot_dev_node = node_list[2];
+ int boot_dev_node = node_list[2];
node_list[2] = node_list[0];
node_list[0] = boot_dev_node;
}
+#endif
err = exynos_dwmci_process_node(blob, node_list, count);
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 5/9] mmc: dw_mmc: add support for 64bit DMA
From: Lukasz Majewski
DW-MMC module in Samsung Exynos5433 requires 64bit DMA descriptors. This
patch adds code for handling them.
Signed-off-by: Lukasz Majewski
[extracted from old sources and adapted to mainline u-boot, minor fixes]
Signed-off-by: Marek Szyprowski
---
drivers/mmc/dw_mmc.c| 53 ++---
drivers/mmc/exynos_dw_mmc.c | 6 +
include/dwmmc.h | 25 +
3 files changed, 74 insertions(+), 10 deletions(-)
diff --git a/drivers/mmc/dw_mmc.c b/drivers/mmc/dw_mmc.c
index 3c702b3ed8..f50eb29ac9 100644
--- a/drivers/mmc/dw_mmc.c
+++ b/drivers/mmc/dw_mmc.c
@@ -30,8 +30,8 @@ static int dwmci_wait_reset(struct dwmci_host *host, u32
value)
return 0;
}
-static void dwmci_set_idma_desc(struct dwmci_idmac *idmac,
- u32 desc0, u32 desc1, u32 desc2)
+static void dwmci_set_idma_desc_32bit(void *idmac,
+ u32 desc0, u32 desc1, u32 desc2)
{
struct dwmci_idmac *desc = idmac;
@@ -41,11 +41,27 @@ static void dwmci_set_idma_desc(struct dwmci_idmac *idmac,
desc->next_addr = (ulong)desc + sizeof(struct dwmci_idmac);
}
+static void dwmci_set_idma_desc_64bit(void *idmac,
+ u32 desc0, u32 desc1, u32 desc2)
+{
+ struct dwmci_idmac_64addr *desc = idmac;
+
+ desc->flags = desc0;
+ desc->_res1 = 0;
+ desc->cnt = desc1;
+ desc->_res2 = 0;
+ desc->addrl = desc2;
+ desc->addrh = 0;
+ desc->next_addrl = (ulong)desc + sizeof(struct dwmci_idmac_64addr);
+ desc->next_addrh = 0;
+}
+
static void dwmci_prepare_data(struct dwmci_host *host,
struct mmc_data *data,
- struct dwmci_idmac *cur_idmac,
+ struct dwmci_idmac_64addr *cur_idmac64,
void *bounce_buffer)
{
+ struct dwmci_idmac *cur_idmac = (struct dwmci_idmac *)cur_idmac64;
unsigned long ctrl;
unsigned int i = 0, flags, cnt, blk_cnt;
ulong data_start, data_end;
@@ -56,7 +72,12 @@ static void dwmci_prepare_data(struct dwmci_host *host,
dwmci_wait_reset(host, DWMCI_CTRL_FIFO_RESET);
data_start = (ulong)cur_idmac;
- dwmci_writel(host, DWMCI_DBADDR, (ulong)cur_idmac);
+
+ if (host->dma_64bit_address) {
+ dwmci_writel(host, DWMCI_DBADDRU, 0);
+ dwmci_writel(host, DWMCI_DBADDRL, (ulong)cur_idmac64);
+ } else
+ dwmci_writel(host, DWMCI_DBADDR, (ulong)cur_idmac);
do {
flags = DWMCI_IDMAC_OWN | DWMCI_IDMAC_CH ;
@@ -67,17 +88,27 @@ static void dwmci_prepare_data(struct dwmci_host *host,
} else
cnt = data->blocksize * 8;
- dwmci_set_idma_desc(cur_idmac, flags, cnt,
- (ulong)bounce_buffer + (i * PAGE_SIZE));
+ if (host->dma_64bit_address)
+ dwmci_set_idma_desc_64bit(cur_idmac64, flags, cnt,
+(ulong)bounce_buffer +
+ (i * PAGE_SIZE));
+ else
+ dwmci_set_idma_desc_32bit(cur_idmac, flags, cnt,
+ (ulong)bounce_buffer +
+ (i * PAGE_SIZE));
if (blk_cnt <= 8)
break;
blk_cnt -= 8;
cur_idmac++;
+ cur_idmac64++;
i++;
} while(1);
- data_end = (ulong)cur_idmac;
+ if (host->dma_64bit_address)
+ data_end = (ulong)cur_idmac64;
+ else
+ data_end = (ulong)cur_idmac;
flush_dcache_range(data_start, data_end + ARCH_DMA_MINALIGN);
ctrl = dwmci_readl(host, DWMCI_CTRL);
@@ -222,7 +253,7 @@ static int dwmci_send_cmd(struct mmc *mmc, struct mmc_cmd
*cmd,
{
#endif
struct dwmci_host *host = mmc->priv;
- ALLOC_CACHE_ALIGN_BUFFER(struct dwmci_idmac, cur_idmac,
+ ALLOC_CACHE_ALIGN_BUFFER(struct dwmci_idmac_64addr, cur_idmac64,
data ? DIV_ROUND_UP(data->blocks, 8) : 0);
int ret = 0, flags = 0, i;
unsigned int timeout = 500;
@@ -256,7 +287,7 @@ static int dwmci_send_cmd(struct mmc *mmc, struct mmc_cmd
*cmd,
data->blocksize *
data->blocks, GEN_BB_READ);
}
- dwmci_prepare_data(host, data, cur_idmac,
+ dwmci_prepare_data(host, data, cur_idmac64,
bbstate.bounce_buffer);
}
}
@@ -474,7 +505,9 @@ static int dwmci_init(struct mmc *mmc)
dwmci_writel(host, DWMCI_TMOUT, 0x);
- dwmci_writel(host, DWMC
[U-Boot] [PATCH 2/9] gadget: f_thor: properly enable 3rd endpoint defined by the protocol
This is needed to make Windows THOR flash tool happy, because it
starts sending data only when interrupt packet is received on the 3rd
endpoint.
Signed-off-by: Marek Szyprowski
---
drivers/usb/gadget/f_thor.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/usb/gadget/f_thor.c b/drivers/usb/gadget/f_thor.c
index 8b3b19feaf..920fa5279c 100644
--- a/drivers/usb/gadget/f_thor.c
+++ b/drivers/usb/gadget/f_thor.c
@@ -941,6 +941,13 @@ static int thor_eps_setup(struct usb_function *f)
dev->out_req = req;
/* ACM control EP */
ep = dev->int_ep;
+ d = ep_desc(gadget, &hs_int_desc, &fs_int_desc);
+ debug("(d)bEndpointAddress: 0x%x\n", d->bEndpointAddress);
+
+ result = usb_ep_enable(ep, d);
+ if (result)
+ goto err;
+
ep->driver_data = cdev; /* claim */
return 0;
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 4/9] dfu: mmc: add support for in-partition offset
Add possibility to define a part of partition as a separate DFU entity.
This allows to have more than one items on the given partiton.
The real use case for this option is TM2 board. It can use u-boot stored
as Linux kernel on the defined partiton (as RAW data) and load the real
kernel from the same partition, but stored under the certain offset.
Signed-off-by: Marek Szyprowski
---
drivers/dfu/dfu_mmc.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/dfu/dfu_mmc.c b/drivers/dfu/dfu_mmc.c
index b45e6dc54c..826e70ffec 100644
--- a/drivers/dfu/dfu_mmc.c
+++ b/drivers/dfu/dfu_mmc.c
@@ -357,6 +357,7 @@ int dfu_fill_entity_mmc(struct dfu_entity *dfu, char
*devstr, char *s)
struct blk_desc *blk_dev = mmc_get_blk_desc(mmc);
int mmcdev = second_arg;
int mmcpart = third_arg;
+ int offset = 0;
if (part_get_info(blk_dev, mmcpart, &partinfo) != 0) {
pr_err("Couldn't find part #%d on mmc device #%d\n",
@@ -364,9 +365,17 @@ int dfu_fill_entity_mmc(struct dfu_entity *dfu, char
*devstr, char *s)
return -ENODEV;
}
+ /*
+* Check for an extra entry at dfu_alt_info env variable
+* specifying the mmc HW defined partition number
+*/
+ if (s)
+ if (!strcmp(strsep(&s, " "), "offset"))
+ offset = simple_strtoul(s, NULL, 0);
+
dfu->layout = DFU_RAW_ADDR;
- dfu->data.mmc.lba_start = partinfo.start;
- dfu->data.mmc.lba_size = partinfo.size;
+ dfu->data.mmc.lba_start = partinfo.start+offset;
+ dfu->data.mmc.lba_size = partinfo.size-offset;
dfu->data.mmc.lba_blk_size = partinfo.blksz;
} else if (!strcmp(entity_type, "fat")) {
dfu->layout = DFU_FS_FAT;
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 3/9] cmd: thor: select DFU subsystem also for 'thor' download tool
'THOR' download command requires DFU infrastructure to properly flash board images. It can be used without enabling DFU command, so add such dependency to Kconfig. Signed-off-by: Marek Szyprowski --- cmd/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/cmd/Kconfig b/cmd/Kconfig index d66f710ad0..0af08aeab3 100644 --- a/cmd/Kconfig +++ b/cmd/Kconfig @@ -340,6 +340,7 @@ config CMD_FITUPD config CMD_THOR_DOWNLOAD bool "thor - TIZEN 'thor' download" + select DFU help Implements the 'thor' download protocol. This is a way of downloading a software update over USB from an attached host. -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/9] cmd: itest: add support for .q size specifier
Add support for quad (64bits) memory access. Signed-off-by: Marek Szyprowski --- cmd/itest.c | 12 1 file changed, 12 insertions(+) diff --git a/cmd/itest.c b/cmd/itest.c index fd6f4166f1..1813a131d1 100644 --- a/cmd/itest.c +++ b/cmd/itest.c @@ -72,6 +72,11 @@ static long evalexp(char *s, int w) case 4: l = (long)(*(u32 *)buf); break; +#ifdef CONFIG_PHYS_64BIT + case 8: + l = (long)(*(unsigned long *)buf); + break; +#endif } unmap_physmem(buf, w); return l; @@ -185,6 +190,9 @@ static int do_itest(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) case 1: case 2: case 4: +#ifdef CONFIG_PHYS_64BIT + case 8: +#endif value = binary_test (argv[2], argv[1], argv[3], w); break; case -2: @@ -203,5 +211,9 @@ static int do_itest(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) U_BOOT_CMD( itest, 4, 0, do_itest, "return true/false on integer compare", +#ifdef CONFIG_PHYS_64BIT + "[.b, .w, .l, .q, .s] [*]value1 [*]value2" +#else "[.b, .w, .l, .s] [*]value1 [*]value2" +#endif ); -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 0/9] ARM: Exynos: Add TM2 board support
Hi All This patchset adds support for TM2 board. u-boot is used to load and decompress kernel image or alternatively (when 'volume down' button is pressed during boot) provide THOR download USB feature for flashing kernel and rootfs images. To let it work, a few minor changes and enhancements were needed in the DW-MMC, DFU, THOR and a few other drivers. Patches are based on current 'next' u-boot branch. This work is based on the earlier patches developped together with ??ukasz Majewski , when he worked at Samsung in the Tizen project. Best regards Marek Szyprowski Samsung R&D Institute Poland Marek Szyprowski (7): cmd: itest: add support for .q size specifier gadget: f_thor: properly enable 3rd endpoint defined by the protocol cmd: thor: select DFU subsystem also for 'thor' download tool dfu: mmc: add support for in-partition offset arm: armv8: add support for boards with broken/unset counter frequency ARM: Exynos: Add minimal support for ARM 64bit based Exynos5433 SoC ARM: Exynos: Add Exynos5433 based TM2 board support ??ukasz Majewski (2): mmc: dw_mmc: add support for 64bit DMA mmc: exynos_dw_mmc: fix compilation on ARM64-based Exynos arch/arm/cpu/armv8/Kconfig | 2 +- arch/arm/cpu/armv8/generic_timer.c | 4 + arch/arm/dts/Makefile | 3 + arch/arm/dts/exynos5433-tm2.dts| 37 + arch/arm/dts/exynos5433.dtsi | 84 +++ arch/arm/mach-exynos/Kconfig | 21 + arch/arm/mach-exynos/mmu-arm64.c | 24 ++ arch/arm/mach-exynos/soc.c | 3 + board/samsung/tm2/Kconfig | 14 board/samsung/tm2/Makefile | 8 ++ board/samsung/tm2/tm2.c| 127 + cmd/Kconfig| 1 + cmd/itest.c| 12 +++ configs/tm2_defconfig | 52 drivers/dfu/dfu_mmc.c | 13 ++- drivers/gpio/s5p_gpio.c| 1 + drivers/mmc/dw_mmc.c | 53 +--- drivers/mmc/exynos_dw_mmc.c| 20 - drivers/usb/gadget/f_thor.c| 7 ++ include/configs/tm2.h | 60 ++ include/dwmmc.h| 25 ++ scripts/config_whitelist.txt | 1 + 22 files changed, 556 insertions(+), 16 deletions(-) create mode 100644 arch/arm/dts/exynos5433-tm2.dts create mode 100644 arch/arm/dts/exynos5433.dtsi create mode 100644 board/samsung/tm2/Kconfig create mode 100644 board/samsung/tm2/Makefile create mode 100644 board/samsung/tm2/tm2.c create mode 100644 configs/tm2_defconfig create mode 100644 include/configs/tm2.h -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Some tegra cleanups and Kconfig migrations
Tom or Tom, Any chance we could get these reviewed and merged, mostly generic cleanups so I don't think most of them are controversial. Peter On Sun, Sep 16, 2018 at 6:23 PM Peter Robinson wrote: > > The following patches are a few cleanups to dangling comments from Kconfig > cleanups and migrations of SYS_I2C_TEGRA, USB_EHCI_TEGRA and TEGRA_KEYBOARD. > There's also a couple of other minors fixes and cleanups as well. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v6 34/34] imx: add i.MX8QXP MEK board support
> -Original Message- > From: Fabio Estevam [mailto:feste...@gmail.com] > Sent: 2018年11月7日 20:36 > To: Jon Nettleton ; Peng Fan > Cc: thar...@gateworks.com; Fabio Estevam ; > U-Boot-Denx > Subject: Re: [U-Boot] [PATCH v6 34/34] imx: add i.MX8QXP MEK board support > > + Peng > > On Wed, Nov 7, 2018 at 4:58 AM Jon Nettleton wrote: > > > > I have been spending some time on this, at least from the lpddr4 side. > > There is a good amount of this that can be abstracted out and made > > into general initialization routines. This is all well and good and > > you can see that Boundary Devices has already codified some of these > > values here. > > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit > > > hub.com%2Fboundarydevices%2Fu-boot-imx6%2Fblob%2Fboundary-v2018.07% > 2Fb > > > oard%2Fboundary%2Fnitrogen8m%2Fddr%2Fddrphy_train.c&data=02%7C > 01%7 > > > Cpeng.fan%40nxp.com%7C9ed74670423a422dd7f108d644ad89f0%7C686ea1d > 3bc2b4 > > > c6fa92cd99c5c301635%7C0%7C0%7C636771909469703915&sdata=WJtl5 > C4Z5YU > > GLLKZUV6AVfGYjwzFIc7GojsBS8S%2BMWg%3D&reserved=0 > > > > However after you generate the script from the spreadsheet you then > > need to run it through a calibration routine, which is a Windows > > program that takes the values from the spreadsheets and runs them > > against the device and provides some tuned phy values based on the > > device. I don't see a good way to get around just having this chunk > > of code be a board specific function that runs the register settings > > that are spit out by the NXP tool. > > > > As for the initialization I am not sure how much changes depending if > > the board is using DDR3, DDR4 or LPDDR4. It would be great if we > > could come up with some general direction on this and move things > > forward. > > Peng on Cc has been working on this and hopefully will be able to post a new > series soon. Yes, the related patches will be sent out after some test, should be soon. Regards, Peng. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v6 34/34] imx: add i.MX8QXP MEK board support
+ Peng On Wed, Nov 7, 2018 at 4:58 AM Jon Nettleton wrote: > > I have been spending some time on this, at least from the lpddr4 side. > There is a good amount of this that can be abstracted out and made > into general initialization routines. This is all well and good and > you can see that Boundary Devices has already codified some of these > values here. > https://github.com/boundarydevices/u-boot-imx6/blob/boundary-v2018.07/board/boundary/nitrogen8m/ddr/ddrphy_train.c > > However after you generate the script from the spreadsheet you then > need to run it through a calibration routine, which is a Windows > program that takes the values from the spreadsheets and runs them > against the device and provides some tuned phy values based on the > device. I don't see a good way to get around just having this chunk > of code be a board specific function that runs the register settings > that are spit out by the NXP tool. > > As for the initialization I am not sure how much changes depending if > the board is using DDR3, DDR4 or LPDDR4. It would be great if we > could come up with some general direction on this and move things > forward. Peng on Cc has been working on this and hopefully will be able to post a new series soon. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] rockchip: video: mipi: Do not write to the version register
There was a copy and paste error where the data enable setting was written to the version register. Signed-off-by: Richard Röjfors --- drivers/video/rockchip/rk_mipi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/video/rockchip/rk_mipi.c b/drivers/video/rockchip/rk_mipi.c index 4fe8f47441..88bf56ea09 100644 --- a/drivers/video/rockchip/rk_mipi.c +++ b/drivers/video/rockchip/rk_mipi.c @@ -106,7 +106,7 @@ int rk_mipi_dsi_enable(struct udevice *dev, rk_mipi_dsi_write(regs, VSYNC_ACTIVE_LOW, val); val = (timing->flags & DISPLAY_FLAGS_DE_LOW) ? 1 : 0; - rk_mipi_dsi_write(regs, DISPLAY_FLAGS_DE_LOW, val); + rk_mipi_dsi_write(regs, DATAEN_ACTIVE_LOW, val); val = (timing->flags & DISPLAY_FLAGS_PIXDATA_NEGEDGE) ? 1 : 0; rk_mipi_dsi_write(regs, COLORM_ACTIVE_LOW, val); -- 2.19.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] imx8qxp_mek: Disable CONFIG_DISPLAY_CPUINFO
> -Original Message- > From: Bin Meng [mailto:bmeng...@gmail.com] > Sent: 2018年11月7日 19:51 > To: Tom Rini ; Simon Glass ; U-Boot > Mailing List > Cc: Mario Six ; Peng Fan > Subject: [PATCH 2/2] imx8qxp_mek: Disable CONFIG_DISPLAY_CPUINFO > > Due to revert of commit c0434407b595, this board does not build any more. > Disable CONFIG_DISPLAY_CPUINFO for v2018.11 release. > > This commit should be reverted after v2018.11 release. > > Signed-off-by: Bin Meng Acked-by: Peng Fan > --- > > configs/imx8qxp_mek_defconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/configs/imx8qxp_mek_defconfig b/configs/imx8qxp_mek_defconfig > index 1588416..a45f3ba 100644 > --- a/configs/imx8qxp_mek_defconfig > +++ b/configs/imx8qxp_mek_defconfig > @@ -6,6 +6,7 @@ CONFIG_SYS_MALLOC_F_LEN=0x2000 > CONFIG_TARGET_IMX8QXP_MEK=y > CONFIG_NR_DRAM_BANKS=3 > CONFIG_BOOTDELAY=3 > +# CONFIG_DISPLAY_CPUINFO is not set > CONFIG_CMD_CPU=y > # CONFIG_CMD_IMPORTENV is not set > CONFIG_CMD_CLK=y > -- > 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] Revert "board_f: Use static print_cpuinfo if CONFIG_CPU is active"
> -Original Message-
> From: Bin Meng [mailto:bmeng...@gmail.com]
> Sent: 2018年11月7日 19:51
> To: Tom Rini ; Simon Glass ; U-Boot
> Mailing List
> Cc: Mario Six ; Peng Fan
> Subject: [PATCH 1/2] Revert "board_f: Use static print_cpuinfo if CONFIG_CPU
> is
> active"
>
> This reverts commit c0434407b595f785fc7401237896c48c791b45fd.
>
> It turns out commit c0434407b595 broke some boards which have DM CPU
> driver with CONFIG_DISPLAY_CPUINFO option on. These boards just fail to boot
> when print_cpuinfo() is called during boot.
>
> Fixes are already sent to ML and in u-boot-dm/next, however since we are
> getting close to the v2018.11 release, it's safer we revert the original
> commit.
>
> This commit should be reverted after v2018.11 release.
>
> Signed-off-by: Bin Meng
Acked-by: Peng Fan
> ---
>
> common/board_f.c | 28
> include/init.h | 7 ---
> 2 files changed, 35 deletions(-)
>
> diff --git a/common/board_f.c b/common/board_f.c index 213d044..afafec5
> 100644
> --- a/common/board_f.c
> +++ b/common/board_f.c
> @@ -11,7 +11,6 @@
>
> #include
> #include
> -#include
> #include
> #include
> #include
> @@ -166,33 +165,6 @@ static int print_resetinfo(void) } #endif
>
> -#if defined(CONFIG_DISPLAY_CPUINFO) && CONFIG_IS_ENABLED(CPU) -static
> int print_cpuinfo(void) -{
> - struct udevice *dev;
> - char desc[512];
> - int ret;
> -
> - ret = uclass_first_device_err(UCLASS_CPU, &dev);
> - if (ret) {
> - debug("%s: Could not get CPU device (err = %d)\n",
> - __func__, ret);
> - return ret;
> - }
> -
> - ret = cpu_get_desc(dev, desc, sizeof(desc));
> - if (ret) {
> - debug("%s: Could not get CPU description (err = %d)\n",
> - dev->name, ret);
> - return ret;
> - }
> -
> - printf("%s", desc);
> -
> - return 0;
> -}
> -#endif
> -
> static int announce_dram_init(void)
> {
> puts("DRAM: ");
> diff --git a/include/init.h b/include/init.h index afc953d..a58d7a6 100644
> --- a/include/init.h
> +++ b/include/init.h
> @@ -109,14 +109,7 @@ int arch_reserve_stacks(void);
> */
> int init_cache_f_r(void);
>
> -#if !CONFIG_IS_ENABLED(CPU)
> -/**
> - * print_cpuinfo() - Display information about the CPU
> - *
> - * Return: 0 if OK, -ve on error
> - */
> int print_cpuinfo(void);
> -#endif
> int timer_init(void);
> int reserve_mmu(void);
> int misc_init_f(void);
> --
> 2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/2] imx8qxp_mek: Disable CONFIG_DISPLAY_CPUINFO
Due to revert of commit c0434407b595, this board does not build any more. Disable CONFIG_DISPLAY_CPUINFO for v2018.11 release. This commit should be reverted after v2018.11 release. Signed-off-by: Bin Meng --- configs/imx8qxp_mek_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/imx8qxp_mek_defconfig b/configs/imx8qxp_mek_defconfig index 1588416..a45f3ba 100644 --- a/configs/imx8qxp_mek_defconfig +++ b/configs/imx8qxp_mek_defconfig @@ -6,6 +6,7 @@ CONFIG_SYS_MALLOC_F_LEN=0x2000 CONFIG_TARGET_IMX8QXP_MEK=y CONFIG_NR_DRAM_BANKS=3 CONFIG_BOOTDELAY=3 +# CONFIG_DISPLAY_CPUINFO is not set CONFIG_CMD_CPU=y # CONFIG_CMD_IMPORTENV is not set CONFIG_CMD_CLK=y -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/2] Revert "board_f: Use static print_cpuinfo if CONFIG_CPU is active"
This reverts commit c0434407b595f785fc7401237896c48c791b45fd.
It turns out commit c0434407b595 broke some boards which have DM CPU
driver with CONFIG_DISPLAY_CPUINFO option on. These boards just fail
to boot when print_cpuinfo() is called during boot.
Fixes are already sent to ML and in u-boot-dm/next, however since
we are getting close to the v2018.11 release, it's safer we revert
the original commit.
This commit should be reverted after v2018.11 release.
Signed-off-by: Bin Meng
---
common/board_f.c | 28
include/init.h | 7 ---
2 files changed, 35 deletions(-)
diff --git a/common/board_f.c b/common/board_f.c
index 213d044..afafec5 100644
--- a/common/board_f.c
+++ b/common/board_f.c
@@ -11,7 +11,6 @@
#include
#include
-#include
#include
#include
#include
@@ -166,33 +165,6 @@ static int print_resetinfo(void)
}
#endif
-#if defined(CONFIG_DISPLAY_CPUINFO) && CONFIG_IS_ENABLED(CPU)
-static int print_cpuinfo(void)
-{
- struct udevice *dev;
- char desc[512];
- int ret;
-
- ret = uclass_first_device_err(UCLASS_CPU, &dev);
- if (ret) {
- debug("%s: Could not get CPU device (err = %d)\n",
- __func__, ret);
- return ret;
- }
-
- ret = cpu_get_desc(dev, desc, sizeof(desc));
- if (ret) {
- debug("%s: Could not get CPU description (err = %d)\n",
- dev->name, ret);
- return ret;
- }
-
- printf("%s", desc);
-
- return 0;
-}
-#endif
-
static int announce_dram_init(void)
{
puts("DRAM: ");
diff --git a/include/init.h b/include/init.h
index afc953d..a58d7a6 100644
--- a/include/init.h
+++ b/include/init.h
@@ -109,14 +109,7 @@ int arch_reserve_stacks(void);
*/
int init_cache_f_r(void);
-#if !CONFIG_IS_ENABLED(CPU)
-/**
- * print_cpuinfo() - Display information about the CPU
- *
- * Return: 0 if OK, -ve on error
- */
int print_cpuinfo(void);
-#endif
int timer_init(void);
int reserve_mmu(void);
int misc_init_f(void);
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] rockchip: video: mipi: Do not write to the version register
> On 07.11.2018, at 11:34, Richard Röjfors wrote: > > There was a copy and paste error where the data > enable setting was written to the version register. > > Signed-off-by: Richard Röjfors Reviewed-by: Philipp Tomsich Acked-by: Philipp Tomsich ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] arm64: zynqmp: Fix logic in CG/EG/EV detection
From: Siva Durga Prasad Paladugu
The VCU disable bit(8) in IP disable register of efuse
is valid only if PL powered up and hence PL powerup status
has to be considered while determining the CG part also.
This patch considers the PL powerup status and ignores the VCU
disable bit if PL not powered up.
This fixes the issue of "unknown" id for CG parts if PL not powered up
and VCU bit(8) is not set.
Signed-off-by: Siva Durga Prasad Paladugu
Signed-off-by: Michal Simek
---
board/xilinx/zynqmp/zynqmp.c | 48 ++--
1 file changed, 37 insertions(+), 11 deletions(-)
diff --git a/board/xilinx/zynqmp/zynqmp.c b/board/xilinx/zynqmp/zynqmp.c
index af91cde7c894..168cf5c14b45 100644
--- a/board/xilinx/zynqmp/zynqmp.c
+++ b/board/xilinx/zynqmp/zynqmp.c
@@ -72,6 +72,7 @@ static const struct {
.id = 0x20,
.ver = 0x12c,
.name = "5cg",
+ .evexists = 1,
},
{
.id = 0x21,
@@ -88,6 +89,7 @@ static const struct {
.id = 0x21,
.ver = 0x12c,
.name = "4cg",
+ .evexists = 1,
},
{
.id = 0x30,
@@ -104,6 +106,7 @@ static const struct {
.id = 0x30,
.ver = 0x12c,
.name = "7cg",
+ .evexists = 1,
},
{
.id = 0x38,
@@ -234,14 +237,18 @@ int chip_id(unsigned char id)
#define ZYNQMP_VERSION_SIZE9
#define ZYNQMP_PL_STATUS_BIT 9
+#define ZYNQMP_IPDIS_VCU_BIT 8
#define ZYNQMP_PL_STATUS_MASK BIT(ZYNQMP_PL_STATUS_BIT)
#define ZYNQMP_CSU_VERSION_MASK~(ZYNQMP_PL_STATUS_MASK)
+#define ZYNQMP_CSU_VCUDIS_VER_MASK ZYNQMP_CSU_VERSION_MASK & \
+ ~BIT(ZYNQMP_IPDIS_VCU_BIT)
+#define MAX_VARIANTS_EV3
#if defined(CONFIG_FPGA) && defined(CONFIG_FPGA_ZYNQMPPL) && \
!defined(CONFIG_SPL_BUILD)
static char *zynqmp_get_silicon_idcode_name(void)
{
- u32 i, id, ver;
+ u32 i, id, ver, j;
char *buf;
static char name[ZYNQMP_VERSION_SIZE];
@@ -249,24 +256,43 @@ static char *zynqmp_get_silicon_idcode_name(void)
ver = chip_id(IDCODE2);
for (i = 0; i < ARRAY_SIZE(zynqmp_devices); i++) {
- if ((zynqmp_devices[i].id == id) &&
- (zynqmp_devices[i].ver == (ver &
- ZYNQMP_CSU_VERSION_MASK))) {
- strncat(name, "zu", 2);
- strncat(name, zynqmp_devices[i].name,
- ZYNQMP_VERSION_SIZE - 3);
- break;
+ if (zynqmp_devices[i].id == id) {
+ if (zynqmp_devices[i].evexists &&
+ !(ver & ZYNQMP_PL_STATUS_MASK))
+ break;
+ if (zynqmp_devices[i].ver == (ver &
+ ZYNQMP_CSU_VERSION_MASK))
+ break;
}
}
if (i >= ARRAY_SIZE(zynqmp_devices))
return "unknown";
- if (!zynqmp_devices[i].evexists)
+ strncat(name, "zu", 2);
+ if (!zynqmp_devices[i].evexists ||
+ (ver & ZYNQMP_PL_STATUS_MASK)) {
+ strncat(name, zynqmp_devices[i].name,
+ ZYNQMP_VERSION_SIZE - 3);
return name;
+ }
- if (ver & ZYNQMP_PL_STATUS_MASK)
- return name;
+ /*
+* Here we are means, PL not powered up and ev variant
+* exists. So, we need to ignore VCU disable bit(8) in
+* version and findout if its CG or EG/EV variant.
+*/
+ for (j = 0; j < MAX_VARIANTS_EV; j++, i++) {
+ if ((zynqmp_devices[i].ver & ~BIT(ZYNQMP_IPDIS_VCU_BIT)) ==
+ (ver & ZYNQMP_CSU_VCUDIS_VER_MASK)) {
+ strncat(name, zynqmp_devices[i].name,
+ ZYNQMP_VERSION_SIZE - 3);
+ break;
+ }
+ }
+
+ if (j >= MAX_VARIANTS_EV)
+ return "unknown";
if (strstr(name, "eg") || strstr(name, "ev")) {
buf = strstr(name, "e");
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [GIT PULL] Xilinx fixes for v2018.11-rc3
Hi Tom, please pull this one patch to your tree. Thanks, Michal The following changes since commit dd610e616cceda16a81dfa6f9a134877f783548c: Merge tag 'u-boot-imx-20181106' of git://git.denx.de/u-boot-imx (2018-11-06 11:12:00 -0500) are available in the git repository at: git://www.denx.de/git/u-boot-microblaze.git tags/xilinx-for-v2018.11-rc3 for you to fetch changes up to acb83bb3ec4fd7f52c600244daa5d8caa53a4924: arm: zynq: Setup non zero SPL FIT load address (2018-11-07 10:07:31 +0100) Xilinx fixes for v2018.11-rc3 - Fix fit loading address for Zynq Michal Simek (1): arm: zynq: Setup non zero SPL FIT load address include/configs/zynq-common.h | 2 ++ 1 file changed, 2 insertions(+) -- Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Xilinx Microblaze Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP SoCs signature.asc Description: OpenPGP digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
