Re: [U-Boot] Sense of soc bus? (was: [PATCH] base: soc: Export soc_device_to_device() helper)
Am 14.11.19 um 23:09 schrieb Rob Herring: > On Tue, Nov 12, 2019 at 4:47 AM Andreas Färber wrote: >> On the other hand, one might argue that such information should just be >> parsed by EBBR-conformant bootloaders and be passed to the kernel via >> standard UEFI interfaces and DMI tables. But I'm not aware of Barebox >> having implemented any of that yet, and even for U-Boot (e.g., Realtek >> based consumer devices...) not everyone has the GPL sources or tools to >> update their bootloader. So, having the kernel we control gather >> information relevant to kernel developers does make some sense to me. > > UEFI and DMI are orthogonal, right. You can't expect DMI on a UEFI+DT system. Not sure, that's why I CC'ed the EBBR folks for input. If it's not mandatory today, the next revision of EBBR could just require it - if that's the unified way between SBBR and EBBR. Little point in doing it only for EBBR. On my UEFI+DT based Raspberry Pi 3 Model B I do see it, note the non-filled Processor Information delivered by U-Boot: raspi3:~ # dmidecode # dmidecode 3.2 Getting SMBIOS data from sysfs. SMBIOS 3.0 present. 7 structures occupying 253 bytes. Table at 0x3CB3E020. Handle 0x, DMI type 0, 24 bytes BIOS Information Vendor: U-Boot Version: 2019.10 Release Date: 10/26/2019 ROM Size: 64 kB Characteristics: PCI is supported BIOS is upgradeable Selectable boot is supported I2O boot is supported Targeted content distribution is supported Handle 0x0001, DMI type 1, 27 bytes System Information Manufacturer: raspberrypi Product Name: rpi Version: Not Specified Serial Number: UUID: 30303030-3030-3030-6437-62346133 Wake-up Type: Reserved SKU Number: Not Specified Family: Not Specified Handle 0x0002, DMI type 2, 14 bytes Base Board Information Manufacturer: raspberrypi Product Name: rpi Version: Not Specified Serial Number: Not Specified Asset Tag: Not Specified Features: Board is a hosting board Location In Chassis: Not Specified Chassis Handle: 0x Type: Motherboard Handle 0x0003, DMI type 3, 21 bytes Chassis Information Manufacturer: raspberrypi Type: Desktop Lock: Not Present Version: Not Specified Serial Number: Not Specified Asset Tag: Not Specified Boot-up State: Safe Power Supply State: Safe Thermal State: Safe Security Status: None OEM Information: 0x Height: Unspecified Number Of Power Cords: Unspecified Contained Elements: 0 Handle 0x0004, DMI type 4, 48 bytes Processor Information Socket Designation: Not Specified Type: Central Processor Family: Unknown Manufacturer: Unknown ID: 00 00 00 00 00 00 00 00 Version: Unknown Voltage: Unknown External Clock: Unknown Max Speed: Unknown Current Speed: Unknown Status: Unpopulated Upgrade: None L1 Cache Handle: Not Provided L2 Cache Handle: Not Provided L3 Cache Handle: Not Provided Serial Number: Not Specified Asset Tag: Not Specified Part Number: Not Specified Characteristics: None Handle 0x0005, DMI type 32, 11 bytes System Boot Information Status: No errors detected Handle 0x0006, DMI type 127, 4 bytes End Of Table Regards, Andreas -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer HRB 36809 (AG Nürnberg) ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] arm: Handle .gnu.hash section in ldscripts
Avoids "could not find output section .gnu.hash" ld.bfd errors on openSUSE.
Cc: Albert Aribaud
Cc: Tom Rini
Signed-off-by: Andreas Färber
---
More changes like this may be needed, but these I compile-tested with
v2014.01 (regression from v2013.10). colibri_t20_iris was runtime-tested.
GCC 4.8.2 r206511, binutils 2.24
arch/arm/cpu/u-boot.lds| 1 +
board/ti/am335x/u-boot.lds | 1 +
2 files changed, 2 insertions(+)
diff --git a/arch/arm/cpu/u-boot.lds b/arch/arm/cpu/u-boot.lds
index 4da5d24..fb8bfaf 100644
--- a/arch/arm/cpu/u-boot.lds
+++ b/arch/arm/cpu/u-boot.lds
@@ -97,6 +97,7 @@ SECTIONS
.dynamic : { *(.dynamic*) }
.plt : { *(.plt*) }
.interp : { *(.interp*) }
+ .gnu.hash : { *(.gnu.hash) }
.gnu : { *(.gnu*) }
.ARM.exidx : { *(.ARM.exidx*) }
.gnu.linkonce.armexidx : { *(.gnu.linkonce.armexidx.*) }
diff --git a/board/ti/am335x/u-boot.lds b/board/ti/am335x/u-boot.lds
index 6a734b3..fec4ccf 100644
--- a/board/ti/am335x/u-boot.lds
+++ b/board/ti/am335x/u-boot.lds
@@ -113,6 +113,7 @@ SECTIONS
.dynstr : { *(.dynstr*) }
.dynamic : { *(.dynamic*) }
.hash : { *(.hash*) }
+ .gnu.hash : { *(.gnu.hash) }
.plt : { *(.plt*) }
.interp : { *(.interp*) }
.gnu : { *(.gnu*) }
--
1.8.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: Handle .gnu.hash section in ldscripts
Hello, Am 27.01.2014 15:24, schrieb Wolfgang Denk: > In message <1390798091-24747-1-git-send-email-afaer...@suse.de> you wrote: >> Avoids "could not find output section .gnu.hash" ld.bfd errors on openSUSE. >> >> Cc: Albert Aribaud >> Cc: Tom Rini >> Signed-off-by: Andreas Färber >> --- >> More changes like this may be needed, but these I compile-tested with >> v2014.01 (regression from v2013.10). colibri_t20_iris was runtime-tested. >> GCC 4.8.2 r206511, binutils 2.24 >> >> arch/arm/cpu/u-boot.lds| 1 + >> board/ti/am335x/u-boot.lds | 1 + >> 2 files changed, 2 insertions(+) > > Is this an ARM specific issue, or other architectures affected as > well? I figured out that the section was apparently not caught by the .gnu* wildcard and this patch fixed our build for the following ARM configs: am335x_evm arndale colibri_t20_iris cubieboard highbank hyundai_a7hd mele_a1000 mx53loco omap3_beagle omap4_panda paz00 rpi_b My guess was that this could be related to the arm-only commit: http://git.denx.de/?p=u-boot.git;a=commit;h=47ed5dd031d7d2c587e6afd386e79ccec1a1b7f7 (which touches on a few more .lds files than mine) But I see nothing ARM-specific in .gnu.hash sections, so other architectures might in theory be affected as well. Cf. http://sourceware.org/ml/binutils/2006-10/msg00377.html I did read your post for ELDK pointing someone to an FAQ entry on not using gcc-specific flags with ld, but for one I did not spot such a thing in the ld command line, and for another our toolchain did not change and v2013.10 builds succeed whereas v2014.01 builds failed without the patch. I could try to git-bisect the offending change if necessary. Best regards, Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: Handle .gnu.hash section in ldscripts
Dear Wolfgang Denk, Am 27.01.2014 20:11, schrieb Wolfgang Denk: > In message <52e6a96b.1080...@suse.de> you wrote: >> >> I figured out that the section was apparently not caught by the .gnu* >> wildcard and this patch fixed our build for the following ARM configs: > > Do I understand you correctly that this fixes a _build_ error? So we > can assume as long as the other archtiectures build fine, they are not > affected by this? Affirmative. :) Best regards, Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: bcm2835: config.mk isn't needed
Hi, Am 29.01.2014 06:42, schrieb Stephen Warren: > The entries in config.mk were needed so that U-Boot could be built > with an old version of the Raspberry Pi Foundation's toolchain. Without > them, the build would error out with: > > ...-ld: error: .../libgcc.a(_bswapsi2.o) uses VFP register arguments, > u-boot does not > > However, none of the 3 toolchains in the latest version of their > tools.git, nor the Ubuntu/Linaro ARM compilers in at least Ubuntu Quantal > or Saucy, need these options set in order to compile a working U-Boot. > Hence, remove the options for simplicity. > > Reported-by: Tom Rini > Signed-off-by: Stephen Warren > --- > arch/arm/cpu/arm1176/bcm2835/config.mk | 19 --- > 1 file changed, 19 deletions(-) > delete mode 100644 arch/arm/cpu/arm1176/bcm2835/config.mk No objection against the patch, but why was arch/arm/config.mk using -msoft-float in the first place? It's been changed from hardcoded to $(call cc-option ...)-wrapped [1], which may explain your experimental results, but IIUC it will still prefer -msoft-float if the compiler supports it [2] rather than if the SoC needs it, right? tegra20 for instance does support the hard-float ABI, too. Regards, Andreas [1] http://git.denx.de/?p=u-boot.git;a=commit;h=0ae7653128c80a4f2920cbe9b124792c2fd9d9e0 [2] http://git.denx.de/?p=u-boot.git;a=blob;f=config.mk;h=b824bb3469dd577909ad804d655f29d56f0b14cd;hb=HEAD#l103 > diff --git a/arch/arm/cpu/arm1176/bcm2835/config.mk > b/arch/arm/cpu/arm1176/bcm2835/config.mk > deleted file mode 100644 > index b87ce24..000 > --- a/arch/arm/cpu/arm1176/bcm2835/config.mk > +++ /dev/null > @@ -1,19 +0,0 @@ > -# > -# (C) Copyright 2012 Stephen Warren > -# > -# See file CREDITS for list of people who contributed to this > -# project. > -# > -# This program is free software; you can redistribute it and/or > -# modify it under the terms of the GNU General Public License > -# version 2 as published by the Free Software Foundation. > -# > -# This program is distributed in the hope that it will be useful, but > -# WITHOUT ANY WARRANTY; without even the implied warranty of > -# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > -# GNU General Public License for more details. > - > -# Don't attempt to override the target CPU/ABI options; > -# the Raspberry Pi toolchain does the right thing by default. > -PLATFORM_RELFLAGS := $(filter-out -msoft-float,$(PLATFORM_RELFLAGS)) > -PLATFORM_CPPFLAGS := $(filter-out -march=armv5t,$(PLATFORM_CPPFLAGS)) -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: bcm2835: config.mk isn't needed
Am 29.01.2014 19:38, schrieb Stephen Warren: > On 01/29/2014 02:22 AM, Andreas Färber wrote: >> Am 29.01.2014 06:42, schrieb Stephen Warren: >>> The entries in config.mk were needed so that U-Boot could be built >>> with an old version of the Raspberry Pi Foundation's toolchain. Without >>> them, the build would error out with: >>> >>> ...-ld: error: .../libgcc.a(_bswapsi2.o) uses VFP register arguments, >>> u-boot does not >>> >>> However, none of the 3 toolchains in the latest version of their >>> tools.git, nor the Ubuntu/Linaro ARM compilers in at least Ubuntu Quantal >>> or Saucy, need these options set in order to compile a working U-Boot. >>> Hence, remove the options for simplicity. >>> >>> Reported-by: Tom Rini >>> Signed-off-by: Stephen Warren >>> --- >>> arch/arm/cpu/arm1176/bcm2835/config.mk | 19 --- >>> 1 file changed, 19 deletions(-) >>> delete mode 100644 arch/arm/cpu/arm1176/bcm2835/config.mk >> >> No objection against the patch, but why was arch/arm/config.mk using >> -msoft-float in the first place? > > It wasn't. It was filtering -msoft-float out of the compiler flags, > which then left the ABI up to the toolchain default, which was hardfp > for one of the Raspberry Pi Foundation's toolchains - the same one that > caused the error messages quoted above unless -msoft-float was removed > from the compiler options. You seem to have misread my question, it was not about bcm2835/config.mk but about arm/config.mk, which bcm2835 was filtering. I didn't quite get Tom's response about U-Boot being soft-float. It is what I compile it to be, no? If I compile it with an hardfp toolchain such as openSUSE's, without -msoft-float it is going to be hardfp IIUC. softfp is for compatibility with non-VFP hardware I thought, but U-Boot is clearly built with a per-board config, so it's not portable anyway. Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: bcm2835: config.mk isn't needed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 29.01.2014 20:47, schrieb Tom Rini: > On 01/29/2014 02:41 PM, Andreas Färber wrote: >> Am 29.01.2014 19:38, schrieb Stephen Warren: >>> On 01/29/2014 02:22 AM, Andreas Färber wrote: >>>> Am 29.01.2014 06:42, schrieb Stephen Warren: >>>>> The entries in config.mk were needed so that U-Boot could >>>>> be built with an old version of the Raspberry Pi >>>>> Foundation's toolchain. Without them, the build would error >>>>> out with: >>>>> >>>>> ...-ld: error: .../libgcc.a(_bswapsi2.o) uses VFP register >>>>> arguments, u-boot does not >>>>> >>>>> However, none of the 3 toolchains in the latest version of >>>>> their tools.git, nor the Ubuntu/Linaro ARM compilers in at >>>>> least Ubuntu Quantal or Saucy, need these options set in >>>>> order to compile a working U-Boot. Hence, remove the >>>>> options for simplicity. >>>>> >>>>> Reported-by: Tom Rini Signed-off-by: >>>>> Stephen Warren --- >>>>> arch/arm/cpu/arm1176/bcm2835/config.mk | 19 >>>>> --- 1 file changed, 19 deletions(-) delete >>>>> mode 100644 arch/arm/cpu/arm1176/bcm2835/config.mk >>>> >>>> No objection against the patch, but why was >>>> arch/arm/config.mk using -msoft-float in the first place? >>> >>> It wasn't. It was filtering -msoft-float out of the compiler >>> flags, which then left the ABI up to the toolchain default, >>> which was hardfp for one of the Raspberry Pi Foundation's >>> toolchains - the same one that caused the error messages quoted >>> above unless -msoft-float was removed from the compiler >>> options. > >> You seem to have misread my question, it was not about >> bcm2835/config.mk but about arm/config.mk, which bcm2835 was >> filtering. > > No, I know what you said. Tom, I didn't dispute that. But Stephen's statement above was clearly wrong if you look at v2013.10: http://git.denx.de/?p=u-boot.git;a=blob;f=arch/arm/config.mk;h=bdabcf407e2c7cf783e4e73b05acec2031d2189c;hb=183acb700378a8cfc5d50a01a65de93fb2c24586#l19 It was in fact using -msoft-float, as you confirm below, and bcm2835 was the one filtering it out. In v2014.01 -msoft-float gets compile-tested before usage and therefore the bcm2835-specific filtering here can be dropped. >> I didn't quite get Tom's response about U-Boot being soft-float. >> It is what I compile it to be, no? If I compile it with an >> hardfp toolchain such as openSUSE's, without -msoft-float it is >> going to be hardfp IIUC. softfp is for compatibility with non-VFP >> hardware I thought, but U-Boot is clearly built with a per-board >> config, so it's not portable anyway. > > This isn't quite correct. U-Boot is like the kernel. We say how > we're built and like the kernel, we are soft float (and unless the > board says we need it, we aren't thumb/thumb2 either). That's why > arch/arm/config.mk (like arch/arm/Makefile in the kernel) enforces > -msoft-float. OK, thanks for explaining. Our v2013.10 package was carrying a patch dropping the hardcoded -msoft-float for our armv7hl toolchain and it worked okay as far as I could tell. I've dropped that patch now for v2014.01 and things at least still build for me. Question solved and FWIW Reviewed-by: Andreas Färber Cheers, Andreas - -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJS6flZAAoJEPou0S0+fgE/9AwP/Rq50Ch6Aqso/jBEdAZRAnCI P9hZGe1YpQOsajd4AN2V6VO/FOwu58jZNTfh2y/pPYHWqhYoXZh7OeUz/Oyj1PK5 Ltq/vjjF4RLTW94MhXHzgegxxBoyO2gGzpojY0bpzLCv6NQJPtRFiudoLy4x6kRc kEJi2sJgegaOQbKzDhjxUse7HsQPc6FObH4iHsH5iYO8wSvgPXDx2//J0S4MopHj jxGMEmPaB1mm5of/Qw8//W2+2Lir17eVG0Lu9f1HVxZXqNEYVTG2VmWKvCpE92U/ 1VhcNshmL6cNvr7k8eTThrR1i6zizBw4bBd81JW3zd/cTCxCkNh8cWyy8Zy3sM8y 4rUhPXgN+L1k70YpPjHlh29Lb7Zd15yCiIshElBb0aOkNkd8qOpWOvy5iPxbPZ5u w2ClZTl8jiChxMqWHe8YNLEV4Pwe9PgIRFHkhBzaR2be0uWuwnxVLmTdre2A/aQH SvtBVbt0+sJgxDTUaLCPNMIxydrPZDiSwrBrrB+8fcxKBayHWQJm5n5MMda8teiT dBAPXo+qCqpXjajEfz9jbW9/xJEQAUzlJCBgBHCmq1Ljbuei74ovVuM6yjAd5uEV Y71IaXgWZ8aHmJHl6zhp5B46O6j4aSfi4HzoyC9ggq2l7GJkMAONn2JNQi6gAT97 cv8lTM1Xo0W3hLQRIqpm =Bgtl -END PGP SIGNATURE- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V3 2/3] ARM: tegra: rework boot scripts
Am 04.02.2014 23:59, schrieb Stephen Warren:
> From: Stephen Warren
>
> Update the common Tegra boot scripts in the default environment to
>
> a) Make use of the new "exists" shell command to avoid some error
>messges.
"messages"; and "exists" became "test -e"
>
> b) Allow booting using the sysboot command and extlinux.conf. This
>allows easy creation of boot menus, and provides a simple interface
>for distros to parameterize/configure the boot process.
>
> Signed-off-by: Stephen Warren
> ---
> v3: s/exists/test -e/ in shell commands.
> v2: No change.
> ---
> include/configs/tegra-common-post.h | 39
> -
> 1 file changed, 30 insertions(+), 9 deletions(-)
>
> diff --git a/include/configs/tegra-common-post.h
> b/include/configs/tegra-common-post.h
> index e1a3bbc62636..5acbdc3a1890 100644
> --- a/include/configs/tegra-common-post.h
> +++ b/include/configs/tegra-common-post.h
> @@ -69,20 +69,41 @@
> #define BOOTCMDS_COMMON \
> "rootpart=1\0" \
> \
> + "do_script_boot=" \
> + "load ${devtype} ${devnum}:${rootpart} " \
> + "${scriptaddr} ${prefix}${script}; " \
> + "source ${scriptaddr}\0" \
> + \
> "script_boot="\
> - "if load ${devtype} ${devnum}:${rootpart} " \
> - "${scriptaddr} ${prefix}${script}; then " \
> - "echo ${script} found! Executing ...;"\
> - "source ${scriptaddr};" \
> - "fi;\0" \
> + "for script in ${boot_scripts}; do " \
> + "if test -e ${devtype} ${devnum}:${rootpart} "\
> + "${prefix}${script}; then " \
> + "echo Found U-Boot script " \
> + "${prefix}${script}; "\
> + "run do_script_boot;" \
> + "echo SCRIPT FAILED; continuing...; " \
This is not going to work, "continuing..." would be treated as command.
> + "fi; "\
> + "done\0" \
> + \
> + "do_sysboot_boot="\
> + "sysboot ${devtype} ${devnum}:${rootpart} any " \
> + "${scriptaddr} ${prefix}extlinux.conf\0" \
> + \
> + "sysboot_boot=" \
> + "if test -e ${devtype} ${devnum}:${rootpart} "\
> + "${prefix}extlinux.conf; then " \
> + "echo Found extlinux config " \
> + "${prefix}extlinux.conf; "\
> + "run do_sysboot_boot;"\
> + "echo SCRIPT FAILED; continuing...; " \
Dito. Also note that there's no space before either echo.
Cheers,
Andreas
> + "fi\0"\
> \
> "scan_boot=" \
> "echo Scanning ${devtype} ${devnum}...; " \
> "for prefix in ${boot_prefixes}; do " \
> - "for script in ${boot_scripts}; do " \
> - "run script_boot; " \
> - "done; " \
> - "done;\0" \
> + "run script_boot; " \
> + "run sysboot_boot; " \
> + "done\0" \
> \
> "boot_targets=" \
> BOOT_TARGETS_MMC " " \
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: Handle .gnu.hash section in ldscripts
Hi Albert, Am 02.03.2014 20:15, schrieb Albert ARIBAUD: > Hi Andreas, > > On Sun, 02 Mar 2014 18:57:14 +0100, Andreas Färber > wrote: > >> Hi Albert, >> >> Am 22.02.2014 14:27, schrieb Albert ARIBAUD: >>> On Thu, 13 Feb 2014 12:39:07 +0100, Albert ARIBAUD >>> wrote: >>> >>>> Can you point me to the toolchain you are using, and if you are not >>>> building mainline code, can you make this code available to me somehow? [...] >> Our latest GCC 4.8.2 can be found here: >> https://build.opensuse.org/package/show/openSUSE:Factory:ARM/gcc48 >> >> Matching binutils 2.24 are here: >> https://build.opensuse.org/package/show/openSUSE:Factory:ARM/binutils >> >> Our latest U-Boot tarball and patches: >> https://build.opensuse.org/package/show/Base:System/u-boot >> Build logs can be found in the u-boot-* packages in the same project, >> with underscores stripped, e.g.: >> https://build.opensuse.org/package/show/Base:System/u-boot-am335xevm > > Thanks for your reply. Apparently, the problem does not appear for the > boards in mainline U-Boot which I listed above with the source code > from our v2014.01 tag and using gcc 4.8.1 from Linaro. I can install > 4.8.2, but meanwhile, can you try to build v2014.01 for these boards > with your setup? > > am335x_evm colibri_t20_iris highbank mx53loco omap3_beagle > omap4_panda paz00 rpi_b I have commented out the patch in: https://build.opensuse.org/project/show/home:a_faerber:branches:Base:System While there are apparently frequent rebuilds scheduled ATM, it seemed like the colibri_t20_iris config intermittently built OK without it. Maybe some gcc 4.8 stable branch update [1] resolved it ... will keep an eye on the build status to confirm. If everything builds, I'm happy. Amicalement, Andreas [1] https://build.opensuse.org/package/view_file/openSUSE:Factory:ARM/gcc48/gcc48.changes?expand=1 -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: Handle .gnu.hash section in ldscripts
Hi Albert, Am 22.02.2014 14:27, schrieb Albert ARIBAUD: > Hi Albert, > > On Thu, 13 Feb 2014 12:39:07 +0100, Albert ARIBAUD > wrote: > >> Hi Andreas, >> >> On Mon, 27 Jan 2014 19:46:03 +0100, Andreas Färber >> wrote: >> >>> Hello, >>> >>> Am 27.01.2014 15:24, schrieb Wolfgang Denk: >>>> In message <1390798091-24747-1-git-send-email-afaer...@suse.de> you wrote: >>>>> Avoids "could not find output section .gnu.hash" ld.bfd errors on >>>>> openSUSE. >>>>> >>>>> Cc: Albert Aribaud >>>>> Cc: Tom Rini >>>>> Signed-off-by: Andreas Färber >>>>> --- >>>>> More changes like this may be needed, but these I compile-tested with >>>>> v2014.01 (regression from v2013.10). colibri_t20_iris was runtime-tested. >>>>> GCC 4.8.2 r206511, binutils 2.24 >>>>> >>>>> arch/arm/cpu/u-boot.lds| 1 + >>>>> board/ti/am335x/u-boot.lds | 1 + >>>>> 2 files changed, 2 insertions(+) >>>> >>>> Is this an ARM specific issue, or other architectures affected as >>>> well? >>> >>> I figured out that the section was apparently not caught by the .gnu* >>> wildcard and this patch fixed our build for the following ARM configs: >>> >>> am335x_evm >>> arndale >>> colibri_t20_iris >>> cubieboard >>> highbank >>> hyundai_a7hd >>> mele_a1000 >>> mx53loco >>> omap3_beagle >>> omap4_panda >>> paz00 >>> rpi_b >>> >>> My guess was that this could be related to the arm-only commit: >>> http://git.denx.de/?p=u-boot.git;a=commit;h=47ed5dd031d7d2c587e6afd386e79ccec1a1b7f7 >>> (which touches on a few more .lds files than mine) >>> >>> But I see nothing ARM-specific in .gnu.hash sections, so other >>> architectures might in theory be affected as well. >>> Cf. http://sourceware.org/ml/binutils/2006-10/msg00377.html >>> >>> I did read your post for ELDK pointing someone to an FAQ entry on not >>> using gcc-specific flags with ld, but for one I did not spot such a >>> thing in the ld command line, and for another our toolchain did not >>> change and v2013.10 builds succeed whereas v2014.01 builds failed >>> without the patch. I could try to git-bisect the offending change if >>> necessary. >> >> Using gcc version 4.8.1 (Ubuntu/Linaro 4.8.1-10ubuntu7), I cannot see >> any issues on these boards: >> >> am335x_evm >> colibri_t20_iris >> highbank >> mx53loco >> omap3_beagle >> omap4_panda >> paz00 >> rpi_b >> >> On arndale, issues are due to warnings unrelated to linking. >> >> Cubieboard, hyundai_a7hd, mele_a1000 are not in mainline AFAICT (but I'd >> like to see mele_a1000 in, as this might mean mele_a1000g could >> follow. :) ) Sorry, missed that. I had merged v2014.01 into the sunxi tree and updated our downstream patch from it (v2014.01-sunxi.patch). It did not seem to touch on Makefile or ldscript in an interfering way. Cf. https://github.com/afaerber/u-boot/commits/sunxi Other downstream changes include forcing ext4 support for SPL and tweaking boot.scr vs. boot.scr.uimg filename inconsistencies. >> Can you point me to the toolchain you are using, and if you are not >> building mainline code, can you make this code available to me somehow? > > Ping. Somehow I did not receive the previous message... Our latest GCC 4.8.2 can be found here: https://build.opensuse.org/package/show/openSUSE:Factory:ARM/gcc48 Matching binutils 2.24 are here: https://build.opensuse.org/package/show/openSUSE:Factory:ARM/binutils Our latest U-Boot tarball and patches: https://build.opensuse.org/package/show/Base:System/u-boot Build logs can be found in the u-boot-* packages in the same project, with underscores stripped, e.g.: https://build.opensuse.org/package/show/Base:System/u-boot-am335xevm Amicalement, Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: Handle .gnu.hash section in ldscripts
Am 02.03.2014 21:57, schrieb Andreas Färber: > Hi Albert, > > Am 02.03.2014 20:15, schrieb Albert ARIBAUD: >> Hi Andreas, >> >> On Sun, 02 Mar 2014 18:57:14 +0100, Andreas Färber >> wrote: >> >>> Hi Albert, >>> >>> Am 22.02.2014 14:27, schrieb Albert ARIBAUD: >>>> On Thu, 13 Feb 2014 12:39:07 +0100, Albert ARIBAUD >>>> wrote: >>>> >>>>> Can you point me to the toolchain you are using, and if you are not >>>>> building mainline code, can you make this code available to me somehow? > [...] >>> Our latest GCC 4.8.2 can be found here: >>> https://build.opensuse.org/package/show/openSUSE:Factory:ARM/gcc48 >>> >>> Matching binutils 2.24 are here: >>> https://build.opensuse.org/package/show/openSUSE:Factory:ARM/binutils >>> >>> Our latest U-Boot tarball and patches: >>> https://build.opensuse.org/package/show/Base:System/u-boot >>> Build logs can be found in the u-boot-* packages in the same project, >>> with underscores stripped, e.g.: >>> https://build.opensuse.org/package/show/Base:System/u-boot-am335xevm >> >> Thanks for your reply. Apparently, the problem does not appear for the >> boards in mainline U-Boot which I listed above with the source code >> from our v2014.01 tag and using gcc 4.8.1 from Linaro. I can install >> 4.8.2, but meanwhile, can you try to build v2014.01 for these boards >> with your setup? >> >> am335x_evm colibri_t20_iris highbank mx53loco omap3_beagle >> omap4_panda paz00 rpi_b > > I have commented out the patch in: > https://build.opensuse.org/project/show/home:a_faerber:branches:Base:System > > While there are apparently frequent rebuilds scheduled ATM, it seemed > like the colibri_t20_iris config intermittently built OK without it. > Maybe some gcc 4.8 stable branch update [1] resolved it ... will keep an > eye on the build status to confirm. If everything builds, I'm happy. Nah, still fails without the patch: [ 178s] gcc -E -g -Os -ffunction-sections -fdata-sections -fno-common -ffixed-r9 -msoft-float -D__KERNEL__ -DCONFIG_SYS_TEXT_BASE=0x0010E000 -I/home/abuild/rpmbuild/BUILD/u-boot-2014.01/include -I/home/abuild/rpmbuild/BUILD/u-boot-2014.01/arch/arm/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/lib/gcc/armv7hl-suse-linux-gnueabi/4.8/include -pipe -DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux -mword-relocations -march=armv7-a -include /home/abuild/rpmbuild/BUILD/u-boot-2014.01/include/u-boot/u-boot.lds.h -DCPUDIR=arch/arm/cpu/armv7 -ansi -D__ASSEMBLY__ -P - u-boot.lds [ 178s] cd /home/abuild/rpmbuild/BUILD/u-boot-2014.01 && ld.bfd -pie -T u-boot.lds --gc-sections -Bstatic -Ttext 0x0010E000 arch/arm/cpu/armv7/start.o --start-group arch/arm/cpu/armv7/built-in.o arch/arm/cpu/armv7/tegra20/built-in.o arch/arm/cpu/built-in.o arch/arm/lib/built-in.o board/toradex/colibri_t20_iris/built-in.o common/built-in.o disk/built-in.o drivers/built-in.o drivers/dma/built-in.o drivers/gpio/built-in.o drivers/i2c/built-in.o drivers/input/built-in.o drivers/mmc/built-in.o drivers/mtd/built-in.o drivers/mtd/nand/built-in.o drivers/mtd/onenand/built-in.o drivers/mtd/spi/built-in.o drivers/net/built-in.o drivers/net/phy/built-in.o drivers/pci/built-in.o drivers/power/battery/built-in.o drivers/power/built-in.o drivers/power/fuel_gauge/built-in.o drivers/power/mfd/built-in.o drivers/power/pmic/built-in.o drivers/serial/built-in.o drivers/spi/built-in.o drivers/usb/eth/built-in.o drivers/usb/gadget/built-in.o drivers/usb/host/built-in.o drivers/usb/musb-new/built-in.o drivers/usb/musb/built-in.o drivers/usb/phy/built-in.o drivers/usb/ulpi/built-in.o fs/built-in.o lib/built-in.o lib/libfdt/built-in.o net/built-in.o test/built-in.o --end-group /home/abuild/rpmbuild/BUILD/u-boot-2014.01/arch/arm/lib/eabi_compat.o -L /usr/lib/gcc/armv7hl-suse-linux-gnueabi/4.8 -lgcc -Map u-boot.map -o u-boot [ 178s] ld.bfd: u-boot: could not find output section .gnu.hash [ 178s] ld.bfd: final link failed: Nonrepresentable section on output [ 178s] Makefile:556: recipe for target 'u-boot' failed [ 178s] make: *** [u-boot] Error 1 https://build.opensuse.org/package/live_build_log/home:a_faerber:branches:Base:System/u-boot-colibrit20iris/openSUSE_Factory_ARM/armv7l Regards, Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: Handle .gnu.hash section in ldscripts
Am 09.03.2014 21:05, schrieb Albert ARIBAUD: > On Mon, 3 Mar 2014 08:00:52 +0100, Albert ARIBAUD > wrote: > >> Hi Andreas, >> >> (seems an answer from me yesterday didn't make it out of the NSA >> interceptors...) >> >> On Sun, 02 Mar 2014 23:00:19 +0100, Andreas Färber >> wrote: >> >>> Am 02.03.2014 21:57, schrieb Andreas Färber: >>>> Hi Albert, >>>> >>>> Am 02.03.2014 20:15, schrieb Albert ARIBAUD: >>>>> Hi Andreas, >>>>> >>>>> On Sun, 02 Mar 2014 18:57:14 +0100, Andreas Färber >>>>> wrote: >>>>> >>>>>> Hi Albert, >>>>>> >>>>>> Am 22.02.2014 14:27, schrieb Albert ARIBAUD: >>>>>>> On Thu, 13 Feb 2014 12:39:07 +0100, Albert ARIBAUD >>>>>>> wrote: >>>>>>> >>>>>>>> Can you point me to the toolchain you are using, and if you are not >>>>>>>> building mainline code, can you make this code available to me somehow? >>>> [...] >>>>>> Our latest GCC 4.8.2 can be found here: >>>>>> https://build.opensuse.org/package/show/openSUSE:Factory:ARM/gcc48 >>>>>> >>>>>> Matching binutils 2.24 are here: >>>>>> https://build.opensuse.org/package/show/openSUSE:Factory:ARM/binutils >>>>>> >>>>>> Our latest U-Boot tarball and patches: >>>>>> https://build.opensuse.org/package/show/Base:System/u-boot >>>>>> Build logs can be found in the u-boot-* packages in the same project, >>>>>> with underscores stripped, e.g.: >>>>>> https://build.opensuse.org/package/show/Base:System/u-boot-am335xevm >>>>> >>>>> Thanks for your reply. Apparently, the problem does not appear for the >>>>> boards in mainline U-Boot which I listed above with the source code >>>>> from our v2014.01 tag and using gcc 4.8.1 from Linaro. I can install >>>>> 4.8.2, but meanwhile, can you try to build v2014.01 for these boards >>>>> with your setup? >>>>> >>>>> am335x_evm colibri_t20_iris highbank mx53loco omap3_beagle >>>>> omap4_panda paz00 rpi_b >>>> >>>> I have commented out the patch in: >>>> https://build.opensuse.org/project/show/home:a_faerber:branches:Base:System >>>> >>>> While there are apparently frequent rebuilds scheduled ATM, it seemed >>>> like the colibri_t20_iris config intermittently built OK without it. >>>> Maybe some gcc 4.8 stable branch update [1] resolved it ... will keep an >>>> eye on the build status to confirm. If everything builds, I'm happy. >>> >>> Nah, still fails without the patch: >>> >>> [ 178s] gcc -E -g -Os -ffunction-sections -fdata-sections >>> -fno-common -ffixed-r9 -msoft-float -D__KERNEL__ >>> -DCONFIG_SYS_TEXT_BASE=0x0010E000 >>> -I/home/abuild/rpmbuild/BUILD/u-boot-2014.01/include >>> -I/home/abuild/rpmbuild/BUILD/u-boot-2014.01/arch/arm/include >>> -fno-builtin -ffreestanding -nostdinc -isystem >>> /usr/lib/gcc/armv7hl-suse-linux-gnueabi/4.8/include -pipe -DCONFIG_ARM >>> -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux >>> -mword-relocations -march=armv7-a -include >>> /home/abuild/rpmbuild/BUILD/u-boot-2014.01/include/u-boot/u-boot.lds.h >>> -DCPUDIR=arch/arm/cpu/armv7 -ansi -D__ASSEMBLY__ -P - >>> >>> u-boot.lds >>> [ 178s] cd /home/abuild/rpmbuild/BUILD/u-boot-2014.01 && ld.bfd -pie >>> -T u-boot.lds --gc-sections -Bstatic -Ttext 0x0010E000 >>> arch/arm/cpu/armv7/start.o --start-group arch/arm/cpu/armv7/built-in.o >>> arch/arm/cpu/armv7/tegra20/built-in.o arch/arm/cpu/built-in.o >>> arch/arm/lib/built-in.o board/toradex/colibri_t20_iris/built-in.o >>> common/built-in.o disk/built-in.o drivers/built-in.o >>> drivers/dma/built-in.o drivers/gpio/built-in.o drivers/i2c/built-in.o >>> drivers/input/built-in.o drivers/mmc/built-in.o drivers/mtd/built-in.o >>> drivers/mtd/nand/built-in.o drivers/mtd/onenand/built-in.o >>> drivers/mtd/spi/built-in.o drivers/net/built-in.o >>> drivers/net/phy/built-in.o drivers/pci/built-in.o >>> drivers/power/battery/built-in.o drivers/power/built-in.o >>> drivers/power/fuel_gauge/built-in.o drivers/power/mfd/built-in.o >>> drivers/power/pmic/built-in.o drivers/serial/built-in.o >>> drivers/spi/built-in.o dri
Re: [U-Boot] [PATCH] arm: Handle .gnu.hash section in ldscripts
Hi, Am 09.03.2014 21:34, schrieb Albert ARIBAUD: > On Sun, 09 Mar 2014 21:22:34 +0100, Andreas Färber > wrote: >> Am 09.03.2014 21:05, schrieb Albert ARIBAUD: >>> On Mon, 3 Mar 2014 08:00:52 +0100, Albert ARIBAUD >>> wrote: >>>> On Sun, 02 Mar 2014 23:00:19 +0100, Andreas Färber >>>> wrote: >>>>> Am 02.03.2014 21:57, schrieb Andreas Färber: >>>>>> Am 02.03.2014 20:15, schrieb Albert ARIBAUD: >>>>>>> On Sun, 02 Mar 2014 18:57:14 +0100, Andreas Färber >>>>>>> wrote: >>>>>>>> Am 22.02.2014 14:27, schrieb Albert ARIBAUD: >>>>>>>>> On Thu, 13 Feb 2014 12:39:07 +0100, Albert ARIBAUD >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Can you point me to the toolchain you are using, and if you are not >>>>>>>>>> building mainline code, can you make this code available to me >>>>>>>>>> somehow? >>>>>> [...] >>>>>>>> Our latest GCC 4.8.2 can be found here: >>>>>>>> https://build.opensuse.org/package/show/openSUSE:Factory:ARM/gcc48 >>>>>>>> >>>>>>>> Matching binutils 2.24 are here: >>>>>>>> https://build.opensuse.org/package/show/openSUSE:Factory:ARM/binutils >>>>>>>> >>>>>>>> Our latest U-Boot tarball and patches: >>>>>>>> https://build.opensuse.org/package/show/Base:System/u-boot >>>>>>>> Build logs can be found in the u-boot-* packages in the same project, >>>>>>>> with underscores stripped, e.g.: >>>>>>>> https://build.opensuse.org/package/show/Base:System/u-boot-am335xevm >>>>>>> >>>>>>> Thanks for your reply. Apparently, the problem does not appear for the >>>>>>> boards in mainline U-Boot which I listed above with the source code >>>>>>> from our v2014.01 tag and using gcc 4.8.1 from Linaro. I can install >>>>>>> 4.8.2, but meanwhile, can you try to build v2014.01 for these boards >>>>>>> with your setup? >>>>>>> >>>>>>> am335x_evm colibri_t20_iris highbank mx53loco omap3_beagle >>>>>>> omap4_panda paz00 rpi_b >>>>>> >>>>>> I have commented out the patch in: >>>>>> https://build.opensuse.org/project/show/home:a_faerber:branches:Base:System >>>>>> >>>>>> While there are apparently frequent rebuilds scheduled ATM, it seemed >>>>>> like the colibri_t20_iris config intermittently built OK without it. >>>>>> Maybe some gcc 4.8 stable branch update [1] resolved it ... will keep an >>>>>> eye on the build status to confirm. If everything builds, I'm happy. >>>>> >>>>> Nah, still fails without the patch: >>>>> >>>>> [ 178s] gcc -E -g -Os -ffunction-sections -fdata-sections >>>>> -fno-common -ffixed-r9 -msoft-float -D__KERNEL__ >>>>> -DCONFIG_SYS_TEXT_BASE=0x0010E000 >>>>> -I/home/abuild/rpmbuild/BUILD/u-boot-2014.01/include >>>>> -I/home/abuild/rpmbuild/BUILD/u-boot-2014.01/arch/arm/include >>>>> -fno-builtin -ffreestanding -nostdinc -isystem >>>>> /usr/lib/gcc/armv7hl-suse-linux-gnueabi/4.8/include -pipe -DCONFIG_ARM >>>>> -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux >>>>> -mword-relocations -march=armv7-a -include >>>>> /home/abuild/rpmbuild/BUILD/u-boot-2014.01/include/u-boot/u-boot.lds.h >>>>> -DCPUDIR=arch/arm/cpu/armv7 -ansi -D__ASSEMBLY__ -P - >>>>> >>>>> u-boot.lds >>>>> [ 178s] cd /home/abuild/rpmbuild/BUILD/u-boot-2014.01 && ld.bfd -pie >>>>> -T u-boot.lds --gc-sections -Bstatic -Ttext 0x0010E000 >>>>> arch/arm/cpu/armv7/start.o --start-group arch/arm/cpu/armv7/built-in.o >>>>> arch/arm/cpu/armv7/tegra20/built-in.o arch/arm/cpu/built-in.o >>>>> arch/arm/lib/built-in.o board/toradex/colibri_t20_iris/built-in.o >>>>> common/built-in.o disk/built-in.o drivers/built-in.o >>>>> drivers/dma/built-in.o drivers/gpio/built-in.o drivers/i2c/built-in.o >>>>> drivers/input/built-in.o drivers/mmc/built-in.o drivers/mtd/built-in.o >>>>> drivers/mtd/nand/built-in.o drivers/mtd/one
Re: [U-Boot] [PATCH] ARM: enable ARMv7 virt support for the Arndale board
Hi, Am 01.08.2014 13:35, schrieb Christoffer Dall: > From: Andre Przywara > > To enable hypervisors utilizing the ARMv7 virtualization extension > on the Arndale board, add the simple SMP pen address writer function > and add the required configuration variables to switch all cores to > HYP mode before launching the OS. > This allows booting KVM and Xen directly from u-boot. > > Reviewed-by: Christoffer Dall > Signed-off-by: Andre Przywara You forgot to sign off the patch. But nice to see progress on this! Cheers, Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: enable ARMv7 virt support for the Arndale board
Am 01.08.2014 15:29, schrieb Andre Przywara: > On 01/08/14 14:02, Christoffer Dall wrote: >> On 1 August 2014 14:59, Andre Przywara wrote: >>> On 01/08/14 13:53, Christoffer Dall wrote: >>>> On 1 August 2014 14:46, Andreas Färber wrote: >>>>> Hi, >>>>> >>>>> Am 01.08.2014 13:35, schrieb Christoffer Dall: >>>>>> From: Andre Przywara >>>>>> >>>>>> To enable hypervisors utilizing the ARMv7 virtualization extension >>>>>> on the Arndale board, add the simple SMP pen address writer function >>>>>> and add the required configuration variables to switch all cores to >>>>>> HYP mode before launching the OS. >>>>>> This allows booting KVM and Xen directly from u-boot. >>>>>> >>>>>> Reviewed-by: Christoffer Dall >>>>>> Signed-off-by: Andre Przywara >>>>> >>>>> You forgot to sign off the patch. >>>>> >>>>> But nice to see progress on this! >>>>> >>>> Can you just add when applying the patch? >>>> >>>> Signed-off-by: Christoffer Dall >>> >>> Andreas, >>> >>> I wonder if you could change (or add) my new address, as my Linaro >>> address does not work any more (just tested). >>> >>> Signed-off-by: Andre Przywara >>> >> So I actually did not know the policy here, given that you did the >> work under your linaro.org address, so I decided to keep this as they >> were and just cc your arm address. If you're fine with using the >> @arm.com address I can respin the patch with the right addresses and >> signed-off-by's. > > I don't know about the policy either - actually I hoped you could help > here ;-) I am perfectly fine with giving Linaro as a sponsor credit for > this, but I am just concerned about potential feedback, which would > bounce and at best annoy people. As long as a post goes to a list also I > catch it, but private only email would be stuck. > This said I am fine both ways - maybe we keep both addresses for > reference in? > > Andreas, > could you just add Christoffer's Signed-off-by and my Signed-off-by > @arm.com without a respin? Guys, I just reacted to this patch because I spotted "virt" and we have a small farm of Arndale boards for OBS. Please take a look at http://www.denx.de/wiki/U-Boot/Custodians, which lists Albert for ARM and Minkyu for Samsung (CC'ed). Regards, Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] ARM: Add ARMv7-M support
Am 05.03.2015 um 16:32 schrieb Tom Rini: > On Sun, Mar 01, 2015 at 12:44:39PM +0100, Kamil Lulko wrote: > >> Signed-off-by: Kamil Lulko > [snip] >> diff --git a/arch/arm/lib/crt0.S b/arch/arm/lib/crt0.S > [snip] >> @@ -66,15 +69,30 @@ ENTRY(_main) >> #else >> ldr sp, =(CONFIG_SYS_INIT_SP_ADDR) >> #endif >> +#if defined(CONFIG_CPU_V7M) /* v7M forbids using SP as BIC destination */ >> +mov r3, sp >> +bic r3, r3, #7 >> +mov sp, r3 >> +#else >> bic sp, sp, #7 /* 8-byte alignment for ABI compliance */ >> +#endif > > There's 4 places where this change comes in. Albert, what do you think > about always just doing this in 3 instructions with a comment in the > first instance about v7-M support? I remember running into problems like these when working on STM32F429 support late last year and I adopted some helper macros from Linux, I believe. The same problem existed in U-Boot's private libgcc code. Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton; HRB 21284 (AG Nürnberg) signature.asc Description: OpenPGP digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] spi:ls102xqds:Support for compatibility for QSPI and DSPI modules drivers
Hi,
Am 26.09.2014 um 09:56 schrieb Chao Fu:
> From: Chao Fu
>
> Useage:
> For exmaple(ls1021 ls1021aqds):
>
> SPI bus defination can be find in
> arch/arm/include/asm/arch-ls102xa/config.h
>
> SPI_BUS_FSL_QSPI0
> SPI_BUS_FSL_DSPI1 1
> SPI_BUS_FSL_DSPI2 2
>
> and SPI devices info:
> AT45DB021 is on spi bus 1 cs 0
> S25FL064 is on spi bus 2 cs 0
> S25FL128S is on spi bus 0 cs 0
>
> Before using any SPI bus and SPI flash, execute sf probe bus:cs in
> uboot cmdline
> Such as use S25FL064, sf probe 2:0
This could use some spellchecking... (usage, example, definition, found)
>
> Signed-off-by: Chao Fu
> ---
> arch/arm/include/asm/arch-ls102xa/config.h | 5 +-
> board/freescale/ls1021aqds/ls1021aqds.c| 33
> drivers/spi/Makefile | 1 +
> drivers/spi/fsl_dspi.c | 78 +++--
> drivers/spi/fsl_qspi.c | 35 ++--
> drivers/spi/fsl_spi_interface.c| 267
> +
> 6 files changed, 339 insertions(+), 80 deletions(-)
> create mode 100644 drivers/spi/fsl_spi_interface.c
[...]
> diff --git a/board/freescale/ls1021aqds/ls1021aqds.c
> b/board/freescale/ls1021aqds/ls1021aqds.c
> index 12e83f7..5db2126 100644
> --- a/board/freescale/ls1021aqds/ls1021aqds.c
> +++ b/board/freescale/ls1021aqds/ls1021aqds.c
> @@ -230,6 +230,39 @@ int board_init(void)
> return 0;
> }
>
> +int board_spi_find_bus(unsigned int bus, unsigned int cs)
> +{
> + switch (bus) {
> + case SPI_BUS_FSL_DSPI1:
> + case SPI_BUS_FSL_DSPI2:
> + case SPI_BUS_FSL_QSPI:
> + break;
> + default:
> + return -1;
> + }
> +
> + switch (bus) {
> + case SPI_BUS_FSL_DSPI1:
> + if (cs == 0)
> + return 0;
> + case SPI_BUS_FSL_DSPI2:
> + if (cs == 0)
> + return 0;
> + case SPI_BUS_FSL_QSPI:
> + if (cs == 0)
> + return 0;
> + default:
> + return -1;
> + }
> +}
[snip]
This code is both redundant and potentially dangerous. In the cs != 0
case, it falls through to the next case label, where the same if is
being executed - no harm done, but someone might want to touch that code
in the future. Why not simply move a single if+return into the first switch?
Regards,
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/2] ARM: tegra: enable GPU DT node
Salut Alexandre, Am 09.07.2015 um 09:32 schrieb Alexandre Courbot: > Tegra124 requires the bootloader to perform VPR initialization, otherwise the > GPU cannot be used by the system. Since using the GPU without that > initialization results in a hang, the GPU DT node is left disabled, and it is > the task of the bootloader to enable it after ensuring it is safe to use the > GPU. > > VPR init is already performed since patch df3443dfa449, but the device tree > was > left untouched. This patch series performs this last step and prepares the GPU > intialization code to receive more code for newer chips. Tested-by: Andreas Färber I've tested this patchset on v2015.07 with 4.2.0-rc3-00115-gc5dfd65 - with these two patches I get a console login on HDMI again. However, I'm still having trouble with X11... Should that be working with linux.git? (haven't tried linux-next.git yet) Among other errors, it seems that nouveau is looking for firmware nouveau/nvea_fuc409c and nouveau/fuc409c - who should be providing that? It's not in linux-firmware.git [1], and I see no /dev/mmcblk0p* to check whether the original system has such a file (which I doubt, given the nouveau naming). It then falls back to the tegra drm iiuc. With -rc2 I've seen the system freeze, with -rc3 just not behaving as expected when starting X (with ssh/serial remaining usable). [2.841626] [drm] Initialized drm 1.1.0 20060810 [2.846621] 5700.gpu supply vdd not found, using dummy regulator [2.853089] nouveau 5700.gpu: cannot initialize IOMMU MM [2.860518] [drm] not a PCI device; no HDMI [2.864814] nouveau [ DEVICE][5700.gpu] BOOT0 : 0x0ea000a1 [2.870932] nouveau [ DEVICE][5700.gpu] Chipset: GK20A (NVEA) [2.877211] nouveau [ DEVICE][5700.gpu] Family : NVE0 [2.916829] nouveau [ INSTMEM][5700.gpu] using DMA API [2.923392] nouveau [VOLT][5700.gpu] The default voltage is -22uV [2.930297] nouveau [ CLK][5700.gpu] parent clock rate: 12 Mhz [2.938662] nouveau [ CLK][5700.gpu] --: core 198 MHz [3.037837] nouveau [ PGRAPH][5700.gpu] using external firmware [3.044493] nouveau 5700.gpu: Direct firmware load for nouveau/nvea_fuc409c failed with error -2 [3.053843] nouveau 5700.gpu: Direct firmware load for nouveau/fuc409c failed with error -2 [3.062549] nouveau E[ PGRAPH][5700.gpu] failed to load fuc409c [3.069497] [TTM] Zone kernel: Available graphics memory: 373624 kiB [3.075927] [TTM] Zone highmem: Available graphics memory: 1032568 kiB [3.082480] [TTM] Initializing pool allocator [3.086923] [TTM] Initializing DMA pool allocator [3.091737] nouveau [ DRM] VRAM: 0 MiB [3.095914] nouveau [ DRM] GART: 1048576 MiB [3.191777] nouveau E[ PFIFO][5700.gpu] unsupported engines 0x0030 [3.269831] nouveau E[ DRM] failed to create ce channel, -22 [3.365874] nouveau E[ PFIFO][5700.gpu] unsupported engines 0x0001 [3.443902] nouveau E[ DRM] failed to create kernel channel, -22 [3.452322] tegra-hdmi 5428.hdmi: failed to get HDMI regulator [...] [6.817669] +5V_HDMI_CON: supplied by +5V_SYS [6.822215] +1.05V_RUN_AVDD_HDMI_PLL: supplied by +1.05V_RUN [6.828102] +3.3V_RUN: supplied by +3.3V_SYS [6.832438] +3.3V_AVDD_HDMI_AP_GATED: supplied by +3.3V_RUN [6.841657] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [6.848317] [drm] No driver support for vblank timestamp query. [6.926989] Console: switching to colour frame buffer device 160x64 [6.945437] drm drm: fb0: frame buffer device [6.949894] drm drm: registered panic notifier [6.976420] [drm] Initialized tegra 0.0.0 20120330 on minor 1 Regards, Andreas [1] https://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/tree -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton; HRB 21284 (AG Nürnberg) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Correct License and Copyright information on few files
Hi, Am 23.07.2015 um 16:10 schrieb Ruchika Gupta: > Signed-off-by: Ruchika Gupta [...] > diff --git a/drivers/crypto/fsl/Makefile b/drivers/crypto/fsl/Makefile > index 4aa91e4..fd736cf 100644 > --- a/drivers/crypto/fsl/Makefile > +++ b/drivers/crypto/fsl/Makefile > @@ -1,9 +1,7 @@ > # > # Copyright 2014 Freescale Semiconductor, Inc. > # > -# This program is free software; you can redistribute it and/or > -# modify it under the terms of the GNU General Public License > -# Version 2 as published by the Free Software Foundation. > +# SPDX-License-Identifier: GPL-2.0+ Is this change of license intentional? (GPL-2.0 vs. GPL-2.0+) If so, would've been helpful to explain that in the commit message. > # > > obj-y += sec.o [snip] Cheers, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton; HRB 21284 (AG Nürnberg) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/2] ARM: tegra: enable GPU DT node
Am 23.07.2015 um 13:46 schrieb Andreas Färber: > Salut Alexandre, > > Am 09.07.2015 um 09:32 schrieb Alexandre Courbot: >> Tegra124 requires the bootloader to perform VPR initialization, otherwise the >> GPU cannot be used by the system. Since using the GPU without that >> initialization results in a hang, the GPU DT node is left disabled, and it is >> the task of the bootloader to enable it after ensuring it is safe to use the >> GPU. >> >> VPR init is already performed since patch df3443dfa449, but the device tree >> was >> left untouched. This patch series performs this last step and prepares the >> GPU >> intialization code to receive more code for newer chips. > > Tested-by: Andreas Färber > > I've tested this patchset on v2015.07 with 4.2.0-rc3-00115-gc5dfd65 - > with these two patches I get a console login on HDMI again. > > However, I'm still having trouble with X11... Should that be working > with linux.git? (haven't tried linux-next.git yet) Not much better with next-20150723, it finds the IOMMU now but otherwise mostly unchanged: [2.843264] [drm] Initialized drm 1.1.0 20060810 [2.850224] tegra-hdmi 5428.hdmi: failed to get HDMI regulator [...] [6.310099] [drm] not a PCI device; no HDMI [6.314401] nouveau [ DEVICE][5700.gpu] BOOT0 : 0x0ea000a1 [6.320540] nouveau [ DEVICE][5700.gpu] Chipset: GK20A (NVEA) [6.326847] nouveau [ DEVICE][5700.gpu] Family : NVE0 [6.366513] nouveau [ INSTMEM][5700.gpu] using IOMMU [6.372805] nouveau [VOLT][5700.gpu] The default voltage is 100uV [6.380046] nouveau [VOLT][5700.gpu] GPU voltage: 1015000uv [6.386400] nouveau [ CLK][5700.gpu] parent clock rate: 12 Mhz [6.394768] nouveau [ CLK][5700.gpu] --: core 198 MHz [6.494884] nouveau [ PGRAPH][5700.gpu] using external firmware [6.501553] nouveau 5700.gpu: Direct firmware load for nouveau/nvea_fuc409c failed with error -2 [6.510923] nouveau 5700.gpu: Direct firmware load for nouveau/fuc409c failed with error -2 [6.519661] nouveau E[ PGRAPH][5700.gpu] failed to load fuc409c [6.526664] [TTM] Zone kernel: Available graphics memory: 373640 kiB [6.533201] [TTM] Zone highmem: Available graphics memory: 1032584 kiB [6.539797] [TTM] Initializing pool allocator [6.544232] [TTM] Initializing DMA pool allocator [6.549118] nouveau [ DRM] VRAM: 0 MiB [6.553295] nouveau [ DRM] GART: 1048576 MiB [6.649608] nouveau E[ PFIFO][5700.gpu] unsupported engines 0x0030 [6.729044] nouveau E[ DRM] failed to create ce channel, -22 [6.825300] nouveau E[ PFIFO][5700.gpu] unsupported engines 0x0001 [6.904234] nouveau E[ DRM] failed to create kernel channel, -22 [6.910976] +5V_HDMI_CON: supplied by +5V_SYS [6.915525] +1.05V_RUN_AVDD_HDMI_PLL: supplied by +1.05V_RUN [6.921424] +3.3V_RUN: supplied by +3.3V_SYS [6.925762] +3.3V_AVDD_HDMI_AP_GATED: supplied by +3.3V_RUN [6.934748] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [6.941397] [drm] No driver support for vblank timestamp query. [7.020224] Console: switching to colour frame buffer device 160x64 [7.038895] drm drm: fb0: frame buffer device [7.066961] [drm] Initialized tegra 0.0.0 20120330 on minor 1 Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton; HRB 21284 (AG Nürnberg) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/2] ARM: tegra: enable GPU DT node
Am 23.07.2015 um 13:46 schrieb Andreas Färber: > Am 09.07.2015 um 09:32 schrieb Alexandre Courbot: >> Tegra124 requires the bootloader to perform VPR initialization, otherwise the >> GPU cannot be used by the system. Since using the GPU without that >> initialization results in a hang, the GPU DT node is left disabled, and it is >> the task of the bootloader to enable it after ensuring it is safe to use the >> GPU. >> >> VPR init is already performed since patch df3443dfa449, but the device tree >> was >> left untouched. This patch series performs this last step and prepares the >> GPU >> intialization code to receive more code for newer chips. > > Tested-by: Andreas Färber > > I've tested this patchset on v2015.07 with 4.2.0-rc3-00115-gc5dfd65 - > with these two patches I get a console login on HDMI again. Ping! Independent of the Linux and X11 discussions this thread has drifted off into, these two patches are still missing in v2015.10-rc1 and don't apply any more (as reported by Guillaume). Can you please rebase and merge them? Thanks, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton; HRB 21284 (AG Nürnberg) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] api_storage: Fix non-first storage device enumeration
When enabling CONFIG_API and chain-loading GRUB2 on jetson-tk1, only the
eMMC would show up as (hd0), but not the SD card, leading to GRUB not
finding its configuration and modules, falling back to a rescue shell.
This is because enum_ended would get set for !more after returning a
cookie for the first MMC device in group 3.
Fix this by properly setting the "more" argument also in the case of the
first storage device of a group.
Signed-off-by: Andreas Färber
---
api/api_storage.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/api/api_storage.c b/api/api_storage.c
index b76b07d..ec92ae4 100644
--- a/api/api_storage.c
+++ b/api/api_storage.c
@@ -112,6 +112,11 @@ static int dev_stor_get(int type, int first, int *more,
struct device_info *di)
else
found = 1;
+ /* provide hint if there are more devices in
+* this group to enumerate */
+ if (1 < specs[type].max_dev)
+ *more = 1;
+
} else {
for (i = 0; i < specs[type].max_dev; i++)
if (di->cookie == (void *)get_dev(specs[type].name, i))
{
--
2.1.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] sunxi configs break with CONFIG_API in v2015.10-rc4
Hi, For at least Bananapi, Cubieboard, Cubieboard2, Cubietruck, Mele_A1000, A10-OLinuXino-Lime, A13-OLinuXino, A20-OLinuXino-Lime2 and probably other sunxi boards, enabling CONFIG_API in the distro defaults header leads to build failures like this one: [ 105s] CC api/api_net.o [ 105s] api/api_net.c: In function 'dev_enum_net': [ 105s] api/api_net.c:61:35: warning: initialization from incompatible pointer type [-Wincompatible-pointer-types] [ 105s] struct eth_device *eth_current = eth_get_dev(); [ 105s]^ [ 105s] api/api_net.c:68:39: error: dereferencing pointer to incomplete type 'struct eth_device' [ 105s] memcpy(di->di_net.hwaddr, eth_current->enetaddr, 6); [ 105s]^ [ 105s] scripts/Makefile.build:277: recipe for target 'api/api_net.o' failed [ 105s] make[1]: *** [api/api_net.o] Error 1 [ 105s] Makefile:1191: recipe for target 'api' failed [ 105s] make: *** [api] Error 2 Could you please check on why that is? By comparison, this is working fine for jetson-tk1; arndale, snow and possibly others are lacking a define for the maximum number of MMCs (preparing a patch). Thanks, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton; HRB 21284 (AG Nürnberg) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot malloc implementation on arm - problem after relocation
Hi Marcin, Am 07.10.2015 um 15:58 schrieb Marcin Krzemiński: > Since I use qemu it > is very hard to debug with gdb u-boot after relocation( or I do not know > how to do it), so I am almost blind. QEMU has a built-in gdb stub that you can just connect to as gdb remote target, similar to how you would connect to a JTAG adapter's gdb server. See documentation of qemu-system-arm -gdb and -s options. It should behave the same as with a physical remote target, otherwise please report to qemu-devel or a suitable bug tracker. Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton; HRB 21284 (AG Nürnberg) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/9] efi_loader: Add boot time services
Am 22.12.2015 um 14:57 schrieb Alexander Graf: > diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c > new file mode 100644 > index 000..ed95962 > --- /dev/null > +++ b/lib/efi_loader/efi_boottime.c [...] > +/* > + * The "gd" pointer lives in a register on ARM and AArch64 that we declare > + * fixed when compiling U-Boot. However, the payload does now know about that "does not"? > + * restriction so we need to manually swap its and our view of that register > on > + * EFI callback entry/exit. > + */ > +static volatile void *efi_gd, *app_gd; [snip] Cheers, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton; HRB 21284 (AG Nürnberg) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 8/9] efi_loader: Add "bootefi" command
Am 25.12.2015 um 10:02 schrieb Alexander Graf: [snip] > The reason I implemented "bootefi" was really because it's the natural > fit into how U-Boot handles all other formats today. I don't think this > is going to be the last patch set around EFI support. I think what Matwey was suggesting is integrating your "bootefi" into the standard "distro" boot sequence environment, so that it probes each device for an EFI binary and if it finds one runs load and bootefi, without the need for any boot.scr. That would be a follow-up patch. It however conflicts with your idea of having some potentially board-specific code mess with "fdt addr" command before running "bootefi". My solution would be to give boot.scr preference over *.efi, so that the user has a way to load dtb and run "bootefi" on his own, and otherwise fall back to just "bootefi" which'll spit a warning about lack of fdt if I read that correctly. Cheers, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton; HRB 21284 (AG Nürnberg) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/9] EFI payload / application support
Am 04.01.2016 um 17:56 schrieb Tom Rini: > Please note that with the generic distro framework U-Boot will grok > https://wiki.freedesktop.org/www/Specifications/BootLoaderSpec/ and > things Just Work. I setup a bunch of SD cards with Debian and Fedora > over holiday so I can drop them in whatever board and boot up Linux as a > sanity test. > > I certainly can see a usecase for kicking off an EFI binary as part of > fitting into existing work-flows. But we do already have a something > for getting rid of that particular pain-point and it's working :) No, as I explained before, you are not addressing that particular pain-point: extlinux is still something new to implement for us as distro, you provide no tools to help us, while on x86, ppc, s390 and some aarch64 we have converged on grub2 as a standard, and just recently the YaST devs decided to only support grub2 going forward. For extlinux (which BTW to my eye looked slightly different from the freedesktop.org spec that you guys keep referencing?!), distro-specific code needs to be written [1] so that on kernel installation the /boot/extlinux/extlinux.conf file is regenerated - for grub2 such tools simply exist as part of GRUB and this proposed EFI interface for U-Boot will avoid having to implement any new, e.g., perl-Bootloader code. So the open conflict is that you tell us that extlinux.conf is your "distro" mechanism that we should be using, and our distro people are telling us that grub2 is their preferred solution after having accumulated bootloader code for some two decades and just got rid of it. Standards are not created through publishing some spec, they are created through adoption, and today I don't see anyone at SUSE moving an inch towards adopting extlinux.conf as a generic boot mechanism for all architectures. That leaves our ARM community at a loss, booting a single kernel through a symlink. No one has suggested to dump extlinux.conf or boot.scr, they can all simply co-exist, with the difference that, from the looks of it, Alex' EFI code could get enabled by default to allow users to choose using it, unlike the disabled CONFIG_API code that I reported got broken by DM migration and for many other boards was lacking defines and is in need of a board-specific rather than generic second bootloader on the distro side. This patchset is a cute middle ground where for U-Boot it's mostly just an additional command, our distro people will be content, and our ARM users will be happy too, not having to handcraft extlinux.conf files and benefiting from the vibrant U-Boot community as opposed to the much more fragmented Tianocore forks out there. Thus I'm hoping we can sort out some of the technical issues Leif pointed out and stop circling back to this unhelpful oh-but-extlinux.conf-is-the-mechanism point. Regards, Andreas [1] https://github.com/openSUSE/perl-bootloader/pull/81 -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton; HRB 21284 (AG Nürnberg) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/9] EFI payload / application support
Am 04.01.2016 um 19:03 schrieb Andreas Färber: > Am 04.01.2016 um 17:56 schrieb Tom Rini: >> Please note that with the generic distro framework U-Boot will grok >> https://wiki.freedesktop.org/www/Specifications/BootLoaderSpec/ and >> things Just Work. I setup a bunch of SD cards with Debian and Fedora >> over holiday so I can drop them in whatever board and boot up Linux as a >> sanity test. >> >> I certainly can see a usecase for kicking off an EFI binary as part of >> fitting into existing work-flows. But we do already have a something >> for getting rid of that particular pain-point and it's working :) > [snip] Executive summary: https://xkcd.com/927/ Cheers, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton; HRB 21284 (AG Nürnberg) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SDRAM
Hi, Am 28.05.2015 um 23:49 schrieb Naitik Amin: > I am using Altera SOC, under my includes, I have a file called > /include/configs/socfpga_common.h > > In this file, I have #define as below. > #define PHYS_SDRAM_1_SIZE 0x2000 > > If this #define is set to 0x2000, and uboot is compiled and loaded, > the system when boots up into Linux, issuing free command under linux > shows 512 MB. Which is *correct*. If I change that #define to 0x4000, > upon executing free command, linux shows 1G. > > My questions, is how does this info from uboot reach kernel ? That will depend on your boot environment. :) The new mechanism would be the Device Tree node /memory, if you are passing a .dtb file to bootm/bootz. The legacy mechanism is so-called atags. HTH, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton; HRB 21284 (AG Nürnberg) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [ANN] git server, FTP server
Dear Wolfgang, Am 15.07.2015 um 14:51 schrieb Wolfgang Denk: > In message <593aef6c47f46446852b067021a273d6fbc78...@mucse037.lantiq.com> you > wrote: >> >> I tried to find a way to download a file with wget or a similar tool, which >> would be used by a distribution builder (like Yocto, Buildroot, OpenWrt, >> ...). > > Why would any build environment use tarballs? can you not just > reference the git repository? This is much more efficient, IMHO. Open Build Service uses tarballs, too. We usually specify full URLs in the RPM .spec file [1] both for documentation of origin and so that the mirrored tarball can be verified via gpg or checksum where available. As the actual build is intentionally done offline, at some point a tarball is needed. The URL could happily be a redirect to some mirror. When developing, Git is great of course. Regards, Andreas [1] https://build.opensuse.org/package/view_file/Base:System/u-boot/u-boot.spec.in?expand=1 -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton; HRB 21284 (AG Nürnberg) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [ANN] U-Boot v2015.10-rc5 released
Hi Tom, Am 12.10.2015 um 17:18 schrieb Tom Rini: > If you have a regression, speak up. For -rc4 I had reported that CONFIG_API is broken for sunxi among others. I was told this was fallout of the new Driver Model. Has anyone thought about how to fix this? Is that already a lost cause for 2015.10? Improving test coverage for such off-by-default features will also be helpful going forward. For instance, Simon's brand-new rk3288 code was lacking some MMC define for CONFIG_API to build iirc - that part is trivial to fix when actually build-testing. I'll see if I can polish some of my fixes in time. I had also tried building the qemu-ppce500 target and got lots of linker errors with our native gcc 5.x on ppc (duplicate function definitions with arch/powerpc/include/asm/byteorder.h). My first try of a ppc target, haven't found time to investigate further yet, so not sure if a regression or just compiler-dependent. https://build.opensuse.org/package/live_build_log/home:a_faerber:u-boot:ppc/u-boot-qemu-ppce500/openSUSE_Factory_PowerPC/ppc Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton; HRB 21284 (AG Nürnberg) signature.asc Description: OpenPGP digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [ANN] U-Boot v2015.10-rc5 released
Am 15.10.2015 um 02:40 schrieb Tom Rini: > On Thu, Oct 15, 2015 at 02:28:34AM +0200, Andreas Färber wrote: >> Am 12.10.2015 um 17:18 schrieb Tom Rini: >>> If you have a regression, speak up. >> >> For -rc4 I had reported that CONFIG_API is broken for sunxi among >> others. I was told this was fallout of the new Driver Model. Has anyone >> thought about how to fix this? Is that already a lost cause for 2015.10? >> >> Improving test coverage for such off-by-default features will also be >> helpful going forward. For instance, Simon's brand-new rk3288 code was >> lacking some MMC define for CONFIG_API to build iirc - that part is >> trivial to fix when actually build-testing. I'll see if I can polish >> some of my fixes in time. > > I'm just not sure what to do about CONFIG_API some days. I know one use > case is for GRUB but I'd like to move away from that if possible > (distros should be doing the generic distro bits and extlinux.conf). > After that, I'm only hazily aware of the real use-cases. The problem is that no other platform uses those. On x86_64, ppc64le, s390x, aarch64, etc. we always use GRUB2. Whether it's boot.scr, extlinux.conf or anything else, it'll require changes to distro tools that end up being special-cased to 32-bit arm. With more and more server vendors adopting UEFI and aarch64, that seems a waste of effort. A boot.scr is easy to generate once for an installation image, and I see Guillaume has been helping to make it usable where necessary, but as long as that points to a single zImage / initrd / dtb (ext4 symlinks pointing to the latest), after the user installs a new kernel package, things might simply become unbootable for the average user. That's where GRUB is handy in offering a selection of multiple kernels to go back to a previously working state. I'm not particularly attached to CONFIG_API myself - if the same can be achieved either in GRUB without CONFIG_API or inside U-Boot with scripts and without GRUB, I'd be happy to hear about it. :) Regarding GRUB, I've mainly tested it on jetson-tk1 (adjusting grub's hardcoded RAM offsets), and I've found it to load unreliably, as if there's garbage in memory. Might be our 2.02~beta2 is missing some backports. bootz works fine, so I guess bootm is not to blame there. Anyway, I think it's valid to say that we should either fix CONFIG_API to build okay, or drop it completely, but not carry it around in decaying state. ;) BTW some api example failed to link for some targets, too. According to my spec file, that was with snow, spring and odroid-xu3 (in -rc4), running into an undefined memset (link order maybe?). Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton; HRB 21284 (AG Nürnberg) signature.asc Description: OpenPGP digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/6] Add support for MIPS Creator CI20
Hi Ezequiel, Am 10.12.18 um 21:35 schrieb Ezequiel Garcia: > Please note that I've added Paul's SOB to all the patches > he authored, to make the authorship chain more clear. That's only permitted if Paul agreed to that beforehand - did he? Never add other people's Signed-off-by if their patches didn't have it! https://www.kernel.org/doc/html/latest/process/submitting-patches.html#sign-your-work-the-developer-s-certificate-of-origin As far as the authorship chain goes, you re-did all my forward-porting, that I'm not being credited with Signed-off-by in MMC/SoC/defconfig patches or verbally anywhere? Also this is surely not a v1 patch! Marek had posted CI20 before, so this should be v2 (doesn't look like I posted mine as v2, it didn't fully build yet) and thus your next iteration should be v3 please. Further, it would be very helpful - given the history of this patchset - to indicate which toolchain and version you used for building this. Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 0/6] Add support for MIPS Creator CI20
Am 10.12.18 um 22:31 schrieb Ezequiel Garcia: > On Mon, 2018-12-10 at 22:00 +0100, Andreas Färber wrote: >> Also this is surely not a v1 patch! Marek had posted CI20 before, so >> this should be v2 (doesn't look like I posted mine as v2, it didn't >> fully build yet) and thus your next iteration should be v3 please. > > Well, I couldn't find Marek's cover letter, and I've decided to start from > scratch. That's OK, you did mention your changes in the cover letter. > Two years have passed, we have a new try at getting this merged so I think > it deserves it's own set of integers. The patches need to be distinguishable in Patchwork and inboxes if the subjects remained the same, no matter how much time passed. Thanks, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] efi_loader: Rename sections to allow for implicit data
Am 23.08.2018 um 18:31 schrieb Simon Glass:
> On 23 August 2018 at 07:58, Tom Rini wrote:
>> OK, now I'm trying to see what we need to do next. Regardless of Alex's
>> current EFI PR, we have 7e21fbca26d1 ("efi_loader: Rename sections to
>> allow for implicit data") in master. Looking at the PR, I see that it
>> does turn on -fdata-sections on x86, and that Bin reviewed/tested it.
>> So I'm going to push the PR there shortly.
>>
>> If, for sandbox you want to backout --gc-sections now (the commit
>> message does spell out that we need -ffunction/data-sections and what
>> for) and re-introduce that for the next release please post the patches
>> and I'll grab the backout one and apply it (or post it then PR it if
>> you'd rather, that's fine too).
>
> I'd like to back out all of the compilel/link flag changes:
>
> Here is my patch:
>
> http://patchwork.ozlabs.org/patch/954875/
If you go down that path, please align the subject of that commit with
what it does, e.g., s/Revert/Partially revert/. Otherwise it is terribly
confusing for users that don't care about sandbox.
Regards,
Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] rockchip: make_fit_atf.py depends on u-boot
u-boot.itb depends on u-boot-nodtb.bin, which in turn depends on u-boot.
u-boot.its from Rockchip make_fit_atf.py (used by {evb,firefly}-rk3399)
wants to read u-boot but is lacking this dependency, so that u-boot.itb
cannot be built in one go. Detect its use and add the missing dependency.
Reported-by: Yousaf Kaukab
Signed-off-by: Andreas Färber
---
Makefile | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/Makefile b/Makefile
index f31ee60e4c..3723346c4f 100644
--- a/Makefile
+++ b/Makefile
@@ -1051,7 +1051,10 @@ U_BOOT_ITS = $(subst ",,$(CONFIG_SPL_FIT_SOURCE))
else
ifneq ($(CONFIG_SPL_FIT_GENERATOR),"")
U_BOOT_ITS := u-boot.its
-$(U_BOOT_ITS): FORCE
+ifeq ($(CONFIG_SPL_FIT_GENERATOR),"arch/arm/mach-rockchip/make_fit_atf.py")
+U_BOOT_ITS_DEPS += u-boot
+endif
+$(U_BOOT_ITS): $(U_BOOT_ITS_DEPS) FORCE
$(srctree)/$(CONFIG_SPL_FIT_GENERATOR) \
$(patsubst %,arch/$(ARCH)/dts/%.dtb,$(subst ",,$(CONFIG_OF_LIST))) > $@
endif
--
2.16.3
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] arm: timer: factor out FSL arch timer erratum workaround
Am 02.07.2018 um 10:01 schrieb Jagan Teki: > On Wed, Jun 27, 2018 at 6:12 AM, Andre Przywara > wrote: >> At the moment we have the workaround for the Freescale arch timer >> erratum A-008585 merged into the generic timer_read_counter() routine. >> Split those two up, so that we can add other errata workaround more >> easily. Also add an explaining comment on the way. >> >> Signed-off-by: Andre Przywara >> --- > > Applied both patches, to u-boot-sunxi/master Tested both on top of v2018.07-rc2, fixes the boot for me. Thanks, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] arm: timer: factor out FSL arch timer erratum workaround
Am 03.07.2018 um 01:08 schrieb Andreas Färber: > Am 02.07.2018 um 10:01 schrieb Jagan Teki: >> On Wed, Jun 27, 2018 at 6:12 AM, Andre Przywara >> wrote: >>> At the moment we have the workaround for the Freescale arch timer >>> erratum A-008585 merged into the generic timer_read_counter() routine. >>> Split those two up, so that we can add other errata workaround more >>> easily. Also add an explaining comment on the way. >>> >>> Signed-off-by: Andre Przywara >>> --- >> >> Applied both patches, to u-boot-sunxi/master > > Tested both on top of v2018.07-rc2, fixes the boot for me. Actually I saw it again just now, without having touched U-Boot at all. Unplugged power, retried, worked. So it seems we've reduced the likelihood, but something might still be astray... Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v7 0/4] Amlogic Meson GXBaby and ODROID-C2 support
Hi, Am 08.05.2016 um 08:30 schrieb Beniamino Galvani: > this series adds a very basic support for Amlogic S905 SoC (GXBaby) > and for the ODROID-C2 board [1], and is based on u-boot sources > available from the board vendor [2]. At the moment the only supported > devices are the integrated UART and Ethernet adapter. On current master with these four patches merged, should I expect to see any output after BL31? o.O Note that the README is outdated in that Hardkernel now has sources for fip_create and no binary any more. I've verified that the behavior is the same when using the binary and the self-compiled tool. Last output: NOTICE: BL3-1: v1.0(debug):4d2e34d NOTICE: BL3-1: Built : 17:08:35, Oct 29 2015 INFO:BL3-1: Initializing runtime services INFO:BL3-1: Preparing for EL3 exit to normal world INFO:BL3-1: Next image address = 0x100 INFO:BL3-1: Next image spsr = 0x3c9 I.e., no U-Boot SPL output on serial. Regards, Andreas P.S. The upstream arm-trusted-firmware fip_create tool doesn't know about --bl30 and --bl301 btw, anyone any insights? -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v7 0/4] Amlogic Meson GXBaby and ODROID-C2 support
Am 11.07.2016 um 06:23 schrieb Peter Robinson: > On Mon, Jul 11, 2016 at 4:57 AM, Andreas Färber wrote: >> P.S. The upstream arm-trusted-firmware fip_create tool doesn't know >> about --bl30 and --bl301 btw, anyone any insights? > > If you find details on the upstream ATF support I'd love a link for more > details https://github.com/ARM-software/arm-trusted-firmware/tree/master/tools/fip_create I found a commit renaming BL3-0 to SCP_BL2, but no mention of BL3-0-1 beyond Hardkernel and this patchset. https://github.com/ARM-software/arm-trusted-firmware/commit/f59821d51255f14e0ac00eef7bc98ef75c686876 $ make -C u-boot-hardkernel fip_create $ ./u-boot-hardkernel/tools/fip_create/fip_create --dump fip.bin Firmware Image Package ToC: --- - SCP Firmware BL3-0: offset=0x4000, size=0x9E88 - SCP Firmware BL3-0-1: offset=0x1, size=0x1758 - EL3 Runtime Firmware BL3-1: offset=0x14000, size=0x110D0 - Non-Trusted Firmware BL3-3: offset=0x28000, size=0x36AF6 --- $ make -C arm-trusted-firmware fiptool $ ./arm-trusted-firmware/tools/fip_create/fip_create --dump fip.bin Firmware Image Package ToC: --- - SCP Firmware SCP_BL2: offset=0xD8, size=0x9E88 - Unknown entry: offset=0x9F60, size=0x1758 - EL3 Runtime Firmware BL31: offset=0xB6B8, size=0x110D0 - Non-Trusted Firmware BL33: offset=0x1C788, size=0x36AF6 --- Note that the offsets for BL30[1] are shown differently. Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v7 0/4] Amlogic Meson GXBaby and ODROID-C2 support
Am 11.07.2016 um 21:48 schrieb Beniamino Galvani: > On Mon, Jul 11, 2016 at 05:23:15AM +0100, Peter Robinson wrote: >> On Mon, Jul 11, 2016 at 4:57 AM, Andreas Färber wrote: >>> Last output: >>> >>> NOTICE: BL3-1: v1.0(debug):4d2e34d >>> NOTICE: BL3-1: Built : 17:08:35, Oct 29 2015 >>> INFO:BL3-1: Initializing runtime services >>> INFO:BL3-1: Preparing for EL3 exit to normal world >>> INFO:BL3-1: Next image address = 0x100 >>> INFO:BL3-1: Next image spsr = 0x3c9 >>> >>> I.e., no U-Boot SPL output on serial. >> >> I see similar on Pine64 with 2016.07rc3 > > Here the first non-booting commit is: > > commit d73718f3236c520a92efa401084c658e6cc067f3 > Author: Mingkai Hu > Date: Thu Jul 7 12:22:12 2016 +0800 > > armv8: Enable CPUECTLR.SMPEN for coherency Thanks! With that reverted I get: [...] NOTICE: BL3-1: v1.0(debug):4d2e34d NOTICE: BL3-1: Built : 17:08:35, Oct 29 2015 INFO:BL3-1: Initializing runtime services INFO:BL3-1: Preparing for EL3 exit to normal world INFO:BL3-1: Next image address = 0x100 INFO:BL3-1: Next image spsr = 0x3c9 No match for driver 'eth_designware' Some drivers were not found U-Boot 2016.07-1-g10a9e48 (Jul 11 2016 - 21:58:13 +0200) odroid-c2 DRAM: 2 GiB No maUsing default environment In:serial@4c0 Out: serial@4c0 Err: serial@4c0 Net: No ethernet found. => The eth_designware line (twice, if counting "No ma") is due to what Tom mentioned wrt DM GPIO, I guess. Shouldn't we get a version line from SPL, too? A serial driver issue? Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v7 0/4] Amlogic Meson GXBaby and ODROID-C2 support
Am 11.07.2016 um 22:36 schrieb Carlo Caione: > On Mon, Jul 11, 2016 at 10:15 PM, Andreas Färber wrote: >> [...] >> NOTICE: BL3-1: v1.0(debug):4d2e34d >> NOTICE: BL3-1: Built : 17:08:35, Oct 29 2015 >> INFO:BL3-1: Initializing runtime services >> INFO:BL3-1: Preparing for EL3 exit to normal world >> INFO:BL3-1: Next image address = 0x100 >> INFO:BL3-1: Next image spsr = 0x3c9 >> No match for driver 'eth_designware' >> Some drivers were not found >> >> >> U-Boot 2016.07-1-g10a9e48 (Jul 11 2016 - 21:58:13 +0200) odroid-c2 >> >> DRAM: 2 GiB >> No maUsing default environment >> >> In:serial@4c0 >> Out: serial@4c0 >> Err: serial@4c0 >> Net: No ethernet found. >> => >> >> The eth_designware line (twice, if counting "No ma") is due to what Tom >> mentioned wrt DM GPIO, I guess. >> >> Shouldn't we get a version line from SPL, too? A serial driver issue? > > AFAIKT there is no SPL. U-Boot is loaded by BL3-1 also in the U-Boot > shipped by amlogic. You're right, Hardkernel's version is without SPL, too. Still I wonder about that "No ma" (after the DRAM line). Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v7 0/4] Amlogic Meson GXBaby and ODROID-C2 support
Am 12.07.2016 um 00:52 schrieb Carlo Caione:
> On Mon, Jul 11, 2016 at 11:38 PM, Andreas Färber wrote:
>> Am 11.07.2016 um 22:36 schrieb Carlo Caione:
>>> On Mon, Jul 11, 2016 at 10:15 PM, Andreas Färber wrote:
>
> [...]
>
>>>>
>>>> DRAM: 2 GiB
>>>> No maUsing default environment
>>>>
>>>> In:serial@4c0
>>>> Out: serial@4c0
>>>> Err: serial@4c0
>>>> Net: No ethernet found.
>>>> =>
>>>>
>>>> The eth_designware line (twice, if counting "No ma") is due to what Tom
>>>> mentioned wrt DM GPIO, I guess.
>>>>
>>>> Shouldn't we get a version line from SPL, too? A serial driver issue?
>>>
>>> AFAIKT there is no SPL. U-Boot is loaded by BL3-1 also in the U-Boot
>>> shipped by amlogic.
>>
>> You're right, Hardkernel's version is without SPL, too.
>>
>> Still I wonder about that "No ma" (after the DRAM line).
>
> drivers/core/lists.c: dm_warn("No match for driver
> '%s'\n", entry->name);
>
> :)
How does that explain the incomplete "No ma"?
Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] dragonboard410c: prefer sdcard boot over emmc
Am 03.07.2016 um 18:59 schrieb Ricardo Salveti: > Make the external devices the preferred ones when booting the system > (usb is already the first option). This allows users to easily boot > custom distributions without requiring them to reflash/customize u-boot. > > Cc: Mateusz Kulikowski > Signed-off-by: Ricardo Salveti Reviewed-by: Andreas Färber Tested-by: Andreas Färber Thanks, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/6] efi_loader: Cosmetic distro script cleanups
Fix a macro line break whose alignment slipped in commit fba5f93.
Be consistent in having trailing spaces after semicolon.
While at it, drop a duplicate white line.
Cc: Alexander Graf
Signed-off-by: Andreas Färber
---
include/config_distro_bootcmd.h | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h
index 9ecaf38..b1c9d36 100644
--- a/include/config_distro_bootcmd.h
+++ b/include/config_distro_bootcmd.h
@@ -113,15 +113,14 @@
#define BOOTENV_EFI_SET_FDTFILE_FALLBACK
#endif
-
#define BOOTENV_SHARED_EFI\
"boot_efi_binary="\
"load ${devtype} ${devnum}:${distro_bootpart} " \
"${kernel_addr_r} efi/boot/"BOOTEFI_NAME"; " \
"if fdt addr ${fdt_addr_r}; then "\
- "bootefi ${kernel_addr_r} ${fdt_addr_r};" \
- "else "\
- "bootefi ${kernel_addr_r} ${fdtcontroladdr};" \
+ "bootefi ${kernel_addr_r} ${fdt_addr_r}; "\
+ "else " \
+ "bootefi ${kernel_addr_r} ${fdtcontroladdr}; "\
"fi\0"\
\
"load_efi_dtb=" \
@@ -137,8 +136,8 @@
"${devnum}:${distro_bootpart} " \
"${prefix}${efi_fdtfile}; then " \
"run load_efi_dtb; " \
- "fi;" \
- "done;" \
+ "fi; "\
+ "done; " \
"if test -e ${devtype} ${devnum}:${distro_bootpart} " \
"efi/boot/"BOOTEFI_NAME"; then " \
"echo Found EFI removable media binary " \
--
2.6.6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/6] efi_loader: Respect $boot_prefixes for EFI .dtb search
Just like boot configs or scripts, .dtb files may be in /boot.
Search $efi_dtb_prefixes for all $boot_prefixes.
Cc: Alexander Graf
Signed-off-by: Andreas Färber
---
include/config_distro_bootcmd.h | 24 +++-
1 file changed, 15 insertions(+), 9 deletions(-)
diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h
index b1c9d36..087f576 100644
--- a/include/config_distro_bootcmd.h
+++ b/include/config_distro_bootcmd.h
@@ -125,19 +125,25 @@
\
"load_efi_dtb=" \
"load ${devtype} ${devnum}:${distro_bootpart} " \
- "${fdt_addr_r} ${prefix}${efi_fdtfile}\0" \
+ "${fdt_addr_r} " \
+ "${prefix}${dtb_prefix}${efi_fdtfile}\0" \
\
- "efi_dtb_prefixes=/ /dtb/ /dtb/current/\0"\
+ "efi_dtb_prefixes=\"\" dtb/ dtb/current/\0" \
+ "scan_dev_for_efi_fdt=" \
+ "for prefix in ${boot_prefixes}; do " \
+ "for dtb_prefix in ${efi_dtb_prefixes}; do " \
+ "if test -e ${devtype} " \
+ "${devnum}:${distro_bootpart} " \
+ "${prefix}${dtb_prefix}" \
+ "${efi_fdtfile}; then " \
+ "run load_efi_dtb; " \
+ "fi; "\
+ "done; " \
+ "done\0" \
"scan_dev_for_efi=" \
"setenv efi_fdtfile ${fdtfile}; " \
BOOTENV_EFI_SET_FDTFILE_FALLBACK \
- "for prefix in ${efi_dtb_prefixes}; do " \
- "if test -e ${devtype} " \
- "${devnum}:${distro_bootpart} " \
- "${prefix}${efi_fdtfile}; then " \
- "run load_efi_dtb; " \
- "fi; "\
- "done; " \
+ "run scan_dev_for_efi_fdt; " \
"if test -e ${devtype} ${devnum}:${distro_bootpart} " \
"efi/boot/"BOOTEFI_NAME"; then " \
"echo Found EFI removable media binary " \
--
2.6.6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/6] efi_loader: Search .dtb on non-EFI partitions
A UEFI setup will typically have an EFI FAT partition, but device trees
are more likely to be located on, e.g., Linux volumes. By convention the
EFI partition will usually be placed first, so that we would find the
EFI removable media binary and enter it without device tree from disk.
Therefore after finding an EFI removable media binary, probe other
partitions on the same device for .dtb files.
In the default case the behavior will be unchanged in that only the
first partition is searched.
In the case that there are two partitions marked bootable and the first
being EFI, we will first check the first partition, then the second
partition for the .dtb.
Duplicate loading will only result from non-first EFI partition order.
Cc: Alexander Graf
Signed-off-by: Andreas Färber
---
include/config_distro_bootcmd.h | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h
index 087f576..eadec2e 100644
--- a/include/config_distro_bootcmd.h
+++ b/include/config_distro_bootcmd.h
@@ -124,8 +124,7 @@
"fi\0"\
\
"load_efi_dtb=" \
- "load ${devtype} ${devnum}:${distro_bootpart} " \
- "${fdt_addr_r} " \
+ "load ${devtype} ${devnum}:${efi_bootpart} ${fdt_addr_r} "\
"${prefix}${dtb_prefix}${efi_fdtfile}\0" \
\
"efi_dtb_prefixes=\"\" dtb/ dtb/current/\0" \
@@ -133,7 +132,7 @@
"for prefix in ${boot_prefixes}; do " \
"for dtb_prefix in ${efi_dtb_prefixes}; do " \
"if test -e ${devtype} " \
- "${devnum}:${distro_bootpart} " \
+ "${devnum}:${efi_bootpart} " \
"${prefix}${dtb_prefix}" \
"${efi_fdtfile}; then " \
"run load_efi_dtb; " \
@@ -143,13 +142,22 @@
"scan_dev_for_efi=" \
"setenv efi_fdtfile ${fdtfile}; " \
BOOTENV_EFI_SET_FDTFILE_FALLBACK \
- "run scan_dev_for_efi_fdt; " \
"if test -e ${devtype} ${devnum}:${distro_bootpart} " \
"efi/boot/"BOOTEFI_NAME"; then " \
"echo Found EFI removable media binary " \
"efi/boot/"BOOTEFI_NAME"; " \
+ "for efi_bootpart in ${devplist}; do "\
+ "echo Scanning for device tree " \
+ "on ${devtype} ${devnum}" \
+ ":${efi_bootpart}...; " \
+ "run scan_dev_for_efi_fdt; " \
+ "done; " \
"run boot_efi_binary; " \
"echo EFI LOAD FAILED: continuing...; " \
+ "else " \
+ "setenv efi_bootpart ${distro_bootpart}; "\
+ "run scan_dev_for_efi_fdt; " \
+ "setenv efi_bootpart; " \
"fi; "\
"setenv efi_fdtfile\0"
#define SCAN_DEV_FOR_EFI "run scan_dev_for_efi;"
--
2.6.6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 5/6] dragonboard410c: Set soc_vendor
Signed-off-by: Andreas Färber --- include/configs/dragonboard410c.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/configs/dragonboard410c.h b/include/configs/dragonboard410c.h index 74a827d..8b019e9 100644 --- a/include/configs/dragonboard410c.h +++ b/include/configs/dragonboard410c.h @@ -124,6 +124,7 @@ REFLASH(dragonboard/u-boot.img, 8)\ "linux_image=Image\0" \ "kernel_addr_r=0x8100\0"\ "fdtfile=apq8016-sbc.dtb\0" \ + "soc_vendor=qcom\0" \ "fdt_addr_r=0x8300\0"\ "ramdisk_addr_r=0x8400\0"\ BOOTENV -- 2.6.6 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/6] efi_loader: Improve .dtb search for arm64
On arm64 Linux device trees are organized by SoC vendor. Therefore we
need to search the vendor subdirectory as well.
Since the SoC vendor may be different from ${vendor}, introduce a new
${soc_vendor}. If this is not set, the behavior remains unchanged.
Cc: Alexander Graf
Signed-off-by: Andreas Färber
---
include/config_distro_bootcmd.h | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h
index eadec2e..8f14457 100644
--- a/include/config_distro_bootcmd.h
+++ b/include/config_distro_bootcmd.h
@@ -113,6 +113,15 @@
#define BOOTENV_EFI_SET_FDTFILE_FALLBACK
#endif
+#if defined(CONFIG_ARM64)
+#define BOOTENV_EFI_SET_FDTFILE_VENDOR\
+ "if test -n \"${soc_vendor}\"; then " \
+ "setenv efi_dtb_vendor_prefix ${soc_vendor}/; " \
+ "fi; "
+#else
+#define BOOTENV_EFI_SET_FDTFILE_VENDOR
+#endif
+
#define BOOTENV_SHARED_EFI\
"boot_efi_binary="\
"load ${devtype} ${devnum}:${distro_bootpart} " \
@@ -125,18 +134,25 @@
\
"load_efi_dtb=" \
"load ${devtype} ${devnum}:${efi_bootpart} ${fdt_addr_r} "\
- "${prefix}${dtb_prefix}${efi_fdtfile}\0" \
+ "${prefix}${dtb_prefix}${dtb_vendor_prefix}" \
+ "${efi_fdtfile}\0"\
\
"efi_dtb_prefixes=\"\" dtb/ dtb/current/\0" \
"scan_dev_for_efi_fdt=" \
"for prefix in ${boot_prefixes}; do " \
"for dtb_prefix in ${efi_dtb_prefixes}; do " \
+ BOOTENV_EFI_SET_FDTFILE_VENDOR\
+ "for dtb_vendor_prefix in \"\" " \
+ "${efi_dtb_vendor_prefix}; do " \
"if test -e ${devtype} " \
"${devnum}:${efi_bootpart} " \
"${prefix}${dtb_prefix}" \
+ "${dtb_vendor_prefix}"\
"${efi_fdtfile}; then " \
"run load_efi_dtb; " \
"fi; "\
+ "done; " \
+ "setenv efi_dtb_vendor_prefix; " \
"done; " \
"done\0" \
"scan_dev_for_efi=" \
--
2.6.6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/6] efi_loader: Improvements to .dtb handling
Hi,
This series modifies the distro boot scripts to better cope with real-world
.dtb scenarios. In particular openSUSE images have the EFI GRUB2 and optional
.dtb files on separate partitions (fat vs. ext4) and installed to /boot/dtb-foo
symlink, which may be /dtb or /boot/dtb for U-Boot. The goal is to obsolete
less sophisticated openSUSE patches and to improve the testing experience.
Further, while testing on the DragonBoard 410c, I ran into U-Boot vs. Linux
naming inconsistencies once again and suggest a workaround: ${soc_vendor}.
For easier review a cleanup patch is prepended.
Regards,
Andreas
Cc: Alexander Graf
Cc: Tom Rini
Cc: Stephen Warren
Andreas Färber (6):
efi_loader: Cosmetic distro script cleanups
efi_loader: Respect $boot_prefixes for EFI .dtb search
efi_loader: Search .dtb on non-EFI partitions
efi_loader: Improve .dtb search for arm64
dragonboard410c: Set soc_vendor
efi_loader: Display which .dtb we found
include/config_distro_bootcmd.h | 59 ++-
include/configs/dragonboard410c.h | 1 +
2 files changed, 47 insertions(+), 13 deletions(-)
--
2.6.6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 6/6] efi_loader: Display which .dtb we found
We do so for the EFI binary already and it aids debugging.
Cc: Alexander Graf
Signed-off-by: Andreas Färber
---
include/config_distro_bootcmd.h | 4
1 file changed, 4 insertions(+)
diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h
index 8f14457..0cf74e2 100644
--- a/include/config_distro_bootcmd.h
+++ b/include/config_distro_bootcmd.h
@@ -149,6 +149,10 @@
"${prefix}${dtb_prefix}" \
"${dtb_vendor_prefix}"\
"${efi_fdtfile}; then " \
+ "echo Found ${prefix}"\
+ "${dtb_prefix}" \
+ "${dtb_vendor_prefix}"\
+ "${efi_fdtfile}; "\
"run load_efi_dtb; " \
"fi; "\
"done; " \
--
2.6.6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4] rockchip: add option to change method of loading u-boot
Am 12.07.2016 um 05:18 schrieb Ziyuan Xu: > From: Xu Ziyuan > > If we would like to boot from SD card, we have to implement mmc driver > in SPL stage, and get a slightly large SPL binrary. Rockchip SoC's "binary" > bootrom code has the ability to load spl and u-boot, then boot. > > If CONFIG_ROCKCHIP_SPL_BACK_TO_BROM is enabled, the spl will return to > tbootrom in board_init_f(), then bootrom load u-boot binrary. "the bootrom", "the bootrom loads", "binary" > > This patch does that. Redundant? > > Loading sequence after rework: > bootrom ==> spl ==> bootrom ==> u-boot > > Signed-off-by: Ziyuan Xu > Acked-by: Simon Glass Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/6] efi_loader: Search .dtb on non-EFI partitions
Am 12.07.2016 um 09:25 schrieb Alexander Graf:
>
>
> On 12.07.16 06:21, Andreas Färber wrote:
>> A UEFI setup will typically have an EFI FAT partition, but device trees
>> are more likely to be located on, e.g., Linux volumes. By convention the
>> EFI partition will usually be placed first, so that we would find the
>> EFI removable media binary and enter it without device tree from disk.
>>
>> Therefore after finding an EFI removable media binary, probe other
>> partitions on the same device for .dtb files.
>>
>> In the default case the behavior will be unchanged in that only the
>> first partition is searched.
>> In the case that there are two partitions marked bootable and the first
>> being EFI, we will first check the first partition, then the second
>> partition for the .dtb.
>> Duplicate loading will only result from non-first EFI partition order.
>>
>> Cc: Alexander Graf
>> Signed-off-by: Andreas Färber
>> ---
>> include/config_distro_bootcmd.h | 16
>> 1 file changed, 12 insertions(+), 4 deletions(-)
>>
>> diff --git a/include/config_distro_bootcmd.h
>> b/include/config_distro_bootcmd.h
>> index 087f576..eadec2e 100644
>> --- a/include/config_distro_bootcmd.h
>> +++ b/include/config_distro_bootcmd.h
>> @@ -124,8 +124,7 @@
>> "fi\0"\
>> \
>> "load_efi_dtb=" \
>> -"load ${devtype} ${devnum}:${distro_bootpart} " \
>> -"${fdt_addr_r} " \
>> +"load ${devtype} ${devnum}:${efi_bootpart} ${fdt_addr_r} "\
>> "${prefix}${dtb_prefix}${efi_fdtfile}\0" \
>> \
>> "efi_dtb_prefixes=\"\" dtb/ dtb/current/\0" \
>> @@ -133,7 +132,7 @@
>> "for prefix in ${boot_prefixes}; do " \
>> "for dtb_prefix in ${efi_dtb_prefixes}; do " \
>> "if test -e ${devtype} " \
>> -"${devnum}:${distro_bootpart} " \
>> +"${devnum}:${efi_bootpart} " \
>> "${prefix}${dtb_prefix}" \
>> "${efi_fdtfile}; then " \
>> "run load_efi_dtb; " \
>> @@ -143,13 +142,22 @@
>> "scan_dev_for_efi=" \
>> "setenv efi_fdtfile ${fdtfile}; " \
>> BOOTENV_EFI_SET_FDTFILE_FALLBACK \
>> -"run scan_dev_for_efi_fdt; " \
>> "if test -e ${devtype} ${devnum}:${distro_bootpart} " \
>> "efi/boot/"BOOTEFI_NAME"; then " \
>> "echo Found EFI removable media binary " \
>> "efi/boot/"BOOTEFI_NAME"; " \
>> +"for efi_bootpart in ${devplist}; do "\
>> +"echo Scanning for device tree " \
>> +"on ${devtype} ${devnum}" \
>> +":${efi_bootpart}...; " \
>
> Printing can be quite slow on certain devices (think LCDs with uncached
> vram access), but have a *lot* of partitions (think Android partition
> scheme). I don't think we should print out every partition we're
> searching in, only the ones we find something at.
>
> Maybe something like
>
> Found EFI removable media binary in efi/boot/bootaa64.efi.
> Searching for dtb on mmc 0 ...
> Found dtb on mmc 0:1 boot/dtb/foobar.dtb
>
> would be a sensible amount of debug output :).
No, please read again! I am not printing every partition we're
searching, only in the new inner loop, which will likely be exactly
twice, once for FAT, once for ext.
For the "else" below we already get that output from the regular distro
framework.
In particular "mmc 0" is not enough and absolutely not helping. I need
to see that we're searching the right partition if we don&#
Re: [U-Boot] [PATCH 4/6] efi_loader: Improve .dtb search for arm64
Am 12.07.2016 um 09:29 schrieb Alexander Graf:
> On 12.07.16 06:21, Andreas Färber wrote:
>> On arm64 Linux device trees are organized by SoC vendor. Therefore we
>> need to search the vendor subdirectory as well.
>>
>> Since the SoC vendor may be different from ${vendor}, introduce a new
>> ${soc_vendor}. If this is not set, the behavior remains unchanged.
>>
>> Cc: Alexander Graf
>> Signed-off-by: Andreas Färber
>
> Stephen had pretty strong opinions on the naming, mostly because "pxe
> boot" uses the same naming scheme. So we should either change it there
> as well to stay consistent or just make the implicit ruling always work :).
>
> I guess the best case would be to fix up the path names of boards so
> that $vendor is always $soc_vendor. Do you have an example where that
> wouldn't work?
AFAIU for U-Boot $vendor is often the board vendor and matches the
board/ subdirectory, so there may be plenty vendors. I didn't see any
code setting this value, so I assume this comes from .config options.
My $soc_vendor is the SoC vendor instead and only for the environment.
And because there were opinions on how to form the 32-bit efi_fdtfile,
both Tom and Stephen were CC'ed on the cover letter. :)
On the dragonboard410c:
CONFIG_SYS_SOC="snapdragon"
CONFIG_SYS_VENDOR="qualcomm"
CONFIG_SYS_BOARD="dragonboard410c"
CONFIG_SYS_CONFIG_NAME="dragonboard410c"
soc=snapdragon
vendor=qualcomm
board=dragonboard410c
board_name=dragonboard410c
=> Therefore my previous patch setting fdtfile to apq8016-sbc.dtb,
because it is absolutely different. This patch allows searching qcom/
for our dtb-qcom aarch64 openSUSE package.
On the odroid-c2:
CONFIG_SYS_SOC="meson"
CONFIG_SYS_VENDOR="amlogic"
CONFIG_SYS_BOARD="odroid-c2"
CONFIG_SYS_CONFIG_NAME="odroid-c2"
board=odroid-c2
board_name=odroid-c2
soc=meson
vendor=amlogic
=> Here $vendor would match Linux' dts subdirectory, but $soc and $board
are wrong, I need fdtfile=meson-gxbb-odroidc2.dtb.
But maybe I'm just not understanding what all those configs are good for
and how deeply they're tied to board/ subdirectories and mach-foo? If we
can clean them up to match Linux then all the better. If that were
intended, I wonder why no one flagged that during review.
Anyway, maybe add an else clause to this patch and reuse $vendor if
$soc_vendor is unavailable?
Regards,
Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 6/6] efi_loader: Display which .dtb we found
Am 12.07.2016 um 09:30 schrieb Alexander Graf:
> On 12.07.16 06:21, Andreas Färber wrote:
>> We do so for the EFI binary already and it aids debugging.
>>
>> Cc: Alexander Graf
>> Signed-off-by: Andreas Färber
>> ---
>> include/config_distro_bootcmd.h | 4
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/include/config_distro_bootcmd.h
>> b/include/config_distro_bootcmd.h
>> index 8f14457..0cf74e2 100644
>> --- a/include/config_distro_bootcmd.h
>> +++ b/include/config_distro_bootcmd.h
>> @@ -149,6 +149,10 @@
>> "${prefix}${dtb_prefix}" \
>> "${dtb_vendor_prefix}"\
>> "${efi_fdtfile}; then " \
>> +"echo Found ${prefix}"\
>
> As mentioned in the other reply, I think this message is very useful,
> but should contain the target device name as well, so that we don't need
> to print out a message for every single partition we scan :).
I originally had it that way, but remember that issues like with patches
4 and 5 will not lead to any Found message at all. Therefore I still
prefer decoupling the two.
Btw where does the "reading efi/boot/bootaa64.efi" message come from?
That one could be dropped as duplicate instead! :)
Regards,
Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/6] efi_loader: Improve .dtb search for arm64
Am 12.07.2016 um 14:38 schrieb Andreas Färber:
> Am 12.07.2016 um 09:29 schrieb Alexander Graf:
>> On 12.07.16 06:21, Andreas Färber wrote:
>>> On arm64 Linux device trees are organized by SoC vendor. Therefore we
>>> need to search the vendor subdirectory as well.
>>>
>>> Since the SoC vendor may be different from ${vendor}, introduce a new
>>> ${soc_vendor}. If this is not set, the behavior remains unchanged.
>>>
>>> Cc: Alexander Graf
>>> Signed-off-by: Andreas Färber
>>
>> Stephen had pretty strong opinions on the naming, mostly because "pxe
>> boot" uses the same naming scheme. So we should either change it there
>> as well to stay consistent or just make the implicit ruling always work :).
>>
>> I guess the best case would be to fix up the path names of boards so
>> that $vendor is always $soc_vendor. Do you have an example where that
>> wouldn't work?
>
> AFAIU for U-Boot $vendor is often the board vendor and matches the
> board/ subdirectory, so there may be plenty vendors. I didn't see any
> code setting this value, so I assume this comes from .config options.
>
> My $soc_vendor is the SoC vendor instead and only for the environment.
>
> And because there were opinions on how to form the 32-bit efi_fdtfile,
> both Tom and Stephen were CC'ed on the cover letter. :)
>
> On the dragonboard410c:
> CONFIG_SYS_SOC="snapdragon"
> CONFIG_SYS_VENDOR="qualcomm"
> CONFIG_SYS_BOARD="dragonboard410c"
> CONFIG_SYS_CONFIG_NAME="dragonboard410c"
> soc=snapdragon
> vendor=qualcomm
> board=dragonboard410c
> board_name=dragonboard410c
> => Therefore my previous patch setting fdtfile to apq8016-sbc.dtb,
> because it is absolutely different. This patch allows searching qcom/
> for our dtb-qcom aarch64 openSUSE package.
>
> On the odroid-c2:
> CONFIG_SYS_SOC="meson"
> CONFIG_SYS_VENDOR="amlogic"
> CONFIG_SYS_BOARD="odroid-c2"
> CONFIG_SYS_CONFIG_NAME="odroid-c2"
> board=odroid-c2
> board_name=odroid-c2
> soc=meson
> vendor=amlogic
> => Here $vendor would match Linux' dts subdirectory, but $soc and $board
> are wrong, I need fdtfile=meson-gxbb-odroidc2.dtb.
Adding a 32-bit example:
On the firefly-rk3288:
CONFIG_SYS_SOC="rockchip"
CONFIG_SYS_VENDOR="firefly"
CONFIG_SYS_BOARD="firefly-rk3288"
CONFIG_SYS_CONFIG_NAME="firefly-rk3288"
board=firefly-rk3288
board_name=firefly-rk3288
soc=rockchip
vendor=firefly
=> $vendor is not the SoC vendor, it's the board vendor. My point.
=> $soc is not rk3288, as needed for the ${soc}-${board}${boardrev}.dtb
formula. We either need to fix $soc or define $fdtfile.
Further, I have an early board that needs rk3288-firefly-beta.dtb
instead of rk3288-firefly.dtb. No hits for `git grep firefly-beta`, so
there doesn't seem to be any auto-detection...
Note that ~2016.07 seemed to be completely busted on this board, see the
multiple discussions about disabling EFI_LOADER and other random options
as workaround. Not even bootz succeeded for me any more.
Having a default way to load some uboot.env or uEnv.txt file might help
the user set $fdtfile and similar options while still using the default
boot mechanism.
>
> But maybe I'm just not understanding what all those configs are good for
> and how deeply they're tied to board/ subdirectories and mach-foo? If we
> can clean them up to match Linux then all the better. If that were
> intended, I wonder why no one flagged that during review.
>
> Anyway, maybe add an else clause to this patch and reuse $vendor if
> $soc_vendor is unavailable?
>
> Regards,
> Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 6/6] efi_loader: Display which .dtb we found
Am 12.07.2016 um 16:25 schrieb Alexander Graf:
> On 12.07.16 14:45, Andreas Färber wrote:
>> Am 12.07.2016 um 09:30 schrieb Alexander Graf:
>>> On 12.07.16 06:21, Andreas Färber wrote:
>>>> We do so for the EFI binary already and it aids debugging.
>>>>
>>>> Cc: Alexander Graf
>>>> Signed-off-by: Andreas Färber
>>>> ---
>>>> include/config_distro_bootcmd.h | 4
>>>> 1 file changed, 4 insertions(+)
>>>>
>>>> diff --git a/include/config_distro_bootcmd.h
>>>> b/include/config_distro_bootcmd.h
>>>> index 8f14457..0cf74e2 100644
>>>> --- a/include/config_distro_bootcmd.h
>>>> +++ b/include/config_distro_bootcmd.h
>>>> @@ -149,6 +149,10 @@
>>>>"${prefix}${dtb_prefix}" \
>>>>"${dtb_vendor_prefix}"\
>>>>"${efi_fdtfile}; then " \
>>>> + "echo Found ${prefix}"\
>>>
>>> As mentioned in the other reply, I think this message is very useful,
>>> but should contain the target device name as well, so that we don't need
>>> to print out a message for every single partition we scan :).
>>
>> I originally had it that way, but remember that issues like with patches
>> 4 and 5 will not lead to any Found message at all. Therefore I still
>> prefer decoupling the two.
>
> We do detect the case where we don't have a working fdt loaded already,
> so we could probably print out the search paths there if we don't find a
> working fdt?
Feel free to make a follow-up patch...
>> Btw where does the "reading efi/boot/bootaa64.efi" message come from?
>> That one could be dropped as duplicate instead! :)
>
> Phew. The "load" command maybe?
Then why isn't it printing the same for the .dtb files? :)
Maybe it's some FAT debug thing?
Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/6] efi_loader: Improve .dtb search for arm64
Am 12.07.2016 um 16:50 schrieb Tom Rini:
> On Tue, Jul 12, 2016 at 06:21:45AM +0200, Andreas Färber wrote:
>
>> On arm64 Linux device trees are organized by SoC vendor. Therefore we
>> need to search the vendor subdirectory as well.
>>
>> Since the SoC vendor may be different from ${vendor}, introduce a new
>> ${soc_vendor}. If this is not set, the behavior remains unchanged.
>>
>> Cc: Alexander Graf
>> Signed-off-by: Andreas Färber
>> ---
>> include/config_distro_bootcmd.h | 18 +-
>> 1 file changed, 17 insertions(+), 1 deletion(-)
>>
>> diff --git a/include/config_distro_bootcmd.h
>> b/include/config_distro_bootcmd.h
>> index eadec2e..8f14457 100644
>> --- a/include/config_distro_bootcmd.h
>> +++ b/include/config_distro_bootcmd.h
>> @@ -113,6 +113,15 @@
>> #define BOOTENV_EFI_SET_FDTFILE_FALLBACK
>> #endif
>>
>> +#if defined(CONFIG_ARM64)
>> +#define BOOTENV_EFI_SET_FDTFILE_VENDOR\
>> +"if test -n \"${soc_vendor}\"; then " \
>> +"setenv efi_dtb_vendor_prefix ${soc_vendor}/; " \
>> +"fi; "
>> +#else
>
> OK. Looking at the current Linux kernel, it's a given that for arm64 a
> DTB will be in a subdirectory, always. Perhaps we should fix this in
> Kconfig and have... CONFIG_FDTFILE_VENDOR_DIRECTORY and set this
> correctly per vendor (and yes, eventually there will be some "fun" as
> NXP boards will sometimes be in freescale/ and sometimes nxp/ so maybe
> try and futureproof ourselves so that we loop over this variable) ?
Yes, it's a given that in the kernel the .dts is always in a vendor
subdirectory - as listed in an earlier thread also for mips etc.
And yes, it's also true that due to our scripted openSUSE packaging we
therefore install .dtb to /boot/dtb-foo/vendor/ - but that's not
guaranteed for other distros and users, is it? Therefore I include "" in
the loop further down.
Anyway, adding a config option sounds good. Will you look into that
yourself or should I do that as part of this series?
I had considered the ambiguous vendor case and am iterating over
$efi_dtb_vendor_prefix in a list of vendors already below, only the
addition of the trailing slash above is limiting us to one currently. Do
you have a concrete suggestion of how to make that more flexible?
Cheers,
Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
signature.asc
Description: OpenPGP digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] How to support ATF on u-boot
Hi Kever, Am 20.06.2016 um 04:59 schrieb Kever Yang: > I want to upstream a new SoC named RK3399 from Rockchip which is > AARCH64/ARMv8, we need to support Arm Trust Firmware base on U-boot. > > Right now we are using a miniloader(just like SPL in U-boot) to load > ATF/U-boot, > and PC jump from miniloader to ATF and then to U-boot(with CPU change to > EL2 mode or nsEL1), > then U-boot load kernel/rootfs as usual. > > The ATF support for RK3399 has already upstream > Could you give your opinion on how to support ATF on U-boot upstream? > When I asked Simon Glass offline, he suggest if we can build ATF as part > of the > U-boot build process, perhaps with a script in U-boot tree, > > Perhaps something like: > > make rk3399_board_defconfig > make > ./scripts/build-atf-image rk3399_board > ^^ new script > > In any case, a good README would help. I've started looking into RK3368 for my GeekBox, which raises a similar issue. Are you working on that as well or just RK3399? Personally I think that the approach the HiKey has taken is the best, i.e. decouple U-Boot from ATF and just supply a README for how to make it work with U-Boot as ATF payload. Obviously it would help to integrate your loaderimage tool into mkimage. Also, what is the difference between your trust_merger tool and ATF's fip_create / fiptool? Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] How to support ATF on u-boot
Hi, Am 13.07.2016 um 14:45 schrieb Andre Przywara: > On 13/07/16 13:27, Andreas Färber wrote: >> Am 20.06.2016 um 04:59 schrieb Kever Yang: >>> I want to upstream a new SoC named RK3399 from Rockchip which is >>> AARCH64/ARMv8, we need to support Arm Trust Firmware base on U-boot. >>> >>> Right now we are using a miniloader(just like SPL in U-boot) to load >>> ATF/U-boot, >>> and PC jump from miniloader to ATF and then to U-boot(with CPU change to >>> EL2 mode or nsEL1), >>> then U-boot load kernel/rootfs as usual. >>> >>> The ATF support for RK3399 has already upstream >>> Could you give your opinion on how to support ATF on U-boot upstream? >>> When I asked Simon Glass offline, he suggest if we can build ATF as part >>> of the >>> U-boot build process, perhaps with a script in U-boot tree, >>> >>> Perhaps something like: >>> >>> make rk3399_board_defconfig >>> make >>> ./scripts/build-atf-image rk3399_board >>> ^^ new script > > I am not sure we should trigger an ATF build on building U-Boot. In my > build process for the Pine64 I just point to the compiled binary and > leave it up to the user to take care of compiling that. ATF builds are > really easy and fast, for the Pine64 it's just: "make PLAT=sun50iw1p1 > bl31" for instance and takes only a few seconds. > >>> In any case, a good README would help. >> >> I've started looking into RK3368 for my GeekBox, which raises a similar >> issue. Are you working on that as well or just RK3399? >> >> Personally I think that the approach the HiKey has taken is the best, >> i.e. decouple U-Boot from ATF and just supply a README for how to make >> it work with U-Boot as ATF payload. > > Interestingly ATF itself considers U-Boot a payload, as it provides its > own bootstrapping parts which take a similar role as U-Boot's SPL. > So the official ATF build process (at least for Juno) lets you specify > the location of the U-Boot binary to be included in their FIP image. > > OTOH, some boards (like the Pine64) only use the runtime component of > ATF, so including it in U-Boot makes more sense (see below). I guess > this is similar for Rockchip? As a distro, like you say above, I wouldn't want to rebuild any components of ATF each time U-Boot changes. It also complicates modeling package dependencies. So I would want to build ATF and U-Boot separately and then combine them in a third step when building an actual board image. Supplying a script wouldn't hurt, while integration into `make` would be problematic. The other issue I see is who would take care of mirroring ATF updates into U-Boot. By keeping the repos separate it will be easier for users to follow arm-trusted-firmware.git master branch or to use forks/patches where necessary. Too many vendors are missing in mainline ATF, so a single git submodule wouldn't handle the potential diversity. Do you have any ATF code from Allwinner that could be integrated into mainline? For Amlogic S905 I only have blobs unfortunately and have been discussing with Dan Handley how to adapt at least the mainline tools to handle their quirks for avoiding per-vendor fip_create tools. Cheers, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] rockchip: Clean up CPU selection
In preparation for RK3368 and RK3399, which need to select ARM64, don't select CPU_V7 at the ARCH_ROCKCHIP level but at the SoC level instead. Cc: Kever Yang Signed-off-by: Andreas Färber --- arch/arm/Kconfig | 1 - arch/arm/mach-rockchip/Kconfig | 2 ++ 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 3237a74..124ee21 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -841,7 +841,6 @@ config ARCH_ROCKCHIP select SUPPORT_SPL select SPL select OF_CONTROL - select CPU_V7 select DM config TARGET_THUNDERX_88XX diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig index 2a8afac..d3f5ffd 100644 --- a/arch/arm/mach-rockchip/Kconfig +++ b/arch/arm/mach-rockchip/Kconfig @@ -2,6 +2,7 @@ if ARCH_ROCKCHIP config ROCKCHIP_RK3288 bool "Support Rockchip RK3288" + select CPU_V7 help The Rockchip RK3288 is a ARM-based SoC with a quad-core Cortex-A17 including NEON and GPU, 1MB L2 cache, Mali-T7 graphics, two @@ -11,6 +12,7 @@ config ROCKCHIP_RK3288 config ROCKCHIP_RK3036 bool "Support Rockchip RK3036" + select CPU_V7 help The Rockchip RK3036 is a ARM-based SoC with a dual-core Cortex-A7 including NEON and GPU, Mali-400 graphics, several DDR3 options -- 2.6.6 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] rockchip: Exclude rk_timer for ARM64
It conflicts with the generic_timer. Cc: Kever Yang Signed-off-by: Andreas Färber --- arch/arm/mach-rockchip/Makefile | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/mach-rockchip/Makefile b/arch/arm/mach-rockchip/Makefile index 55567cb..b8046bc 100644 --- a/arch/arm/mach-rockchip/Makefile +++ b/arch/arm/mach-rockchip/Makefile @@ -10,6 +10,8 @@ obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036-board-spl.o else obj-$(CONFIG_ROCKCHIP_RK3288) += board.o endif +ifndef CONFIG_ARM64 obj-y += rk_timer.o +endif obj-$(CONFIG_ROCKCHIP_RK3288) += rk3288/ obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036/ -- 2.6.6 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mkimage: rockchip: add suport for rk33 serial
Am 14.07.2016 um 05:51 schrieb Kever Yang:
> Add support for rockchip rk33 series Soc like rk3368 and rk3399
>
> Signed-off-by: Kever Yang
> ---
>
> tools/rkcommon.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/tools/rkcommon.c b/tools/rkcommon.c
> index 72621fd..9ec7eb2 100644
> --- a/tools/rkcommon.c
> +++ b/tools/rkcommon.c
> @@ -56,6 +56,7 @@ struct spl_info {
> static struct spl_info spl_infos[] = {
> { "rk3036", "RK30", 0x1000 },
> { "rk3288", "RK32", 0x8000 },
> + { "rk33xx", "RK33", 0x2 },
Is xx really future-safe or would it be better to have two lines with
the exact model names as before?
Cheers,
Andreas
> };
>
> static unsigned char rc4_key[16] = {
>
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/2] efi_loader: Implement reset on RPi
Hi Alex, Am 05.06.2016 um 23:17 schrieb Alexander Graf: > If Linux finds an EFI implementation it always uses the EFI reset handler to > reboot or power down the system. Hm, I thought my powerdown issues on the Jetson TK1 were for lack of CONFIG_AS3277_RESET - sounds like it could be due to EFI instead? > Unfortunately we haven't implemented that one yet. In fact, while we prepared > for RTS handling, we never actually implemented a single user. > > This is going to change today. This simple patch set enables RTS reset support > for the RPi systems, allowing you to reboot and shut down the rpi if booted > via EFI. > > It also lays the groundwork to show how to implement that functionality at > all, > so I expect more boards to follow. > > Alexander Graf (2): > efi_loader: Allow boards to implement get_time and reset_system > ARM: bcm283x: Implement EFI RTS reset_system > > arch/arm/mach-bcm283x/include/mach/wdog.h | 2 +- > arch/arm/mach-bcm283x/reset.c | 59 +++-- > cmd/bootefi.c | 4 ++ > include/efi_loader.h | 18 ++ > lib/efi_loader/efi_runtime.c | 101 > ++ > 5 files changed, 166 insertions(+), 18 deletions(-) This all looks very non-generic and would mean that every board will need to be patched individually, which is unrealistic to be tested by just the two of us. Can't you patch the reset_cpu() declaration (common.h/sysreset.h) instead of all its implementations? We might still need to patch individual implementations but I don't see why any reset_cpu() implementation should be in a different section than others. Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/9] cosmetic: rockchip: sort socs according to numbers
Am 16.07.2016 um 00:17 schrieb Heiko Stuebner: > Having some sort of ordering proofed helpful in a lot of other places "proved" > already. So for a larger number of rockchip socs it might be helpful > as well instead of an ever increasing unsorted list. > > Signed-off-by: Heiko Stuebner > --- > arch/arm/mach-rockchip/Kconfig| 20 ++-- > arch/arm/mach-rockchip/Makefile | 4 ++-- > drivers/pinctrl/Kconfig | 16 > drivers/pinctrl/rockchip/Makefile | 2 +- > 4 files changed, 21 insertions(+), 21 deletions(-) Makes perfect sense to me, Reviewed-by: Andreas Färber Thanks, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] armv8: spl: Call board_init_r from crt0_64 in SPL
Am 16.07.2016 um 00:21 schrieb Jeremy Hunt: > As part of the startup process for boards using the SPL, the > meaning of board_init_f changed such that it should return normally > rather than calling board_init_r directly. (see > db910353a126d84fe8dff7a694ea792f50fcfb6a ) > This was fixed in 32-bit arm, but broke when SPL was added to > 64 bit arm. This fixes crt0_64 so that it calls board_init_r > durring the SPL and removes the direct call from board_init_f "during" > from the arm SPL example. > > Signed-off-by: Jeremy Hunt > > Acked-by: Simon Glass Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mkimage: rockchip: add suport for rk33 serial
Simon,
Am 15.07.2016 um 05:56 schrieb Simon Glass:
> On 14 July 2016 at 21:20, Simon Glass wrote:
>> On 13 July 2016 at 21:51, Kever Yang wrote:
>>> Add support for rockchip rk33 series Soc like rk3368 and rk3399
>>>
>>> Signed-off-by: Kever Yang
>>> ---
>>>
>>> tools/rkcommon.c | 1 +
>>> 1 file changed, 1 insertion(+)
>>>
>>> diff --git a/tools/rkcommon.c b/tools/rkcommon.c
>>> index 72621fd..9ec7eb2 100644
>>> --- a/tools/rkcommon.c
>>> +++ b/tools/rkcommon.c
>>> @@ -56,6 +56,7 @@ struct spl_info {
>>> static struct spl_info spl_infos[] = {
>>> { "rk3036", "RK30", 0x1000 },
>>> { "rk3288", "RK32", 0x8000 },
>>> + { "rk33xx", "RK33", 0x2 },
>>> };
>>>
>>> static unsigned char rc4_key[16] = {
>>> --
>>> 1.9.1
>>>
>>>
>>
>> Acked-by: Simon Glass
>
> Applied to u-boot-rockchip, thanks!
Didn't he just reply that it should be 3399 instead of 33xx because 3368
needs a different third column?
Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-sunxi master
Am 16.07.2016 um 15:52 schrieb Tom Rini: > +(pine64_plus)himport_r(&env_htab, (char *)spl->fel_script_address, > +(pine64_plus) ^ > w+(pine64_plus) ../board/sunxi/board.c: In function ‘parse_spl_header’: > w+(pine64_plus) ../board/sunxi/board.c:601:24: warning: cast to pointer from > integer of > different size [-Wint-to-pointer-cast] > > It's not obvious to me what's going on in what's passed over to us in > this case when it is a 64bit target, so I'm just going to allow the > warning for now. Sounds like trying to cast int to char*, which requires inserting a uintptr_t cast first. Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) signature.asc Description: OpenPGP digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] PCIe bridges on Jetson TK1
Hi, When I boot my Jetson TK1, by default I get this from lspci: 00:02.0 PCI bridge: NVIDIA Corporation TegraK1 PCIe x1 Bridge (rev a1) 01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 0c) If however I plug some mini PCIe card, I get this instead: 00:01.0 PCI bridge: NVIDIA Corporation TegraK1 PCIe x4 Bridge (rev a1) 00:02.0 PCI bridge: NVIDIA Corporation TegraK1 PCIe x1 Bridge (rev a1) 01:00.0 Network controller: MEDIATEK Corp. Device 7612 02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 0c) I.e., there is a new Tegra PCIe x4 bridge and the number of the previous x1 bridge changed. That is ugly because it changes the ID of the on-board PCI NIC from 01:00.0 to 02:00.0, which on openSUSE renames the network interface from enp1s0 to enp2s0, so that my /etc/sysconfig/network/ifcfg-enp1s0 does not take effect and the network interface doesn't come up. Tested with U-Boot v2016.05 and v2016.07 and kernel 4.6.2 and 4.7-rc6. Shouldn't U-Boot or the kernel driver always configure the PCIe ports the same way (both bridges available) since the slot is always there on this board? Thanks, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] efi_loader: Add debug output for efi_add_memory_map()
Tracing the arguments has been helpful for pinpointing overflows.
Cc: Alexander Graf
Signed-off-by: Andreas Färber
---
lib/efi_loader/efi_memory.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/lib/efi_loader/efi_memory.c b/lib/efi_loader/efi_memory.c
index df2381e..df3547c 100644
--- a/lib/efi_loader/efi_memory.c
+++ b/lib/efi_loader/efi_memory.c
@@ -130,6 +130,9 @@ uint64_t efi_add_memory_map(uint64_t start, uint64_t pages,
int memory_type,
bool carve_again;
uint64_t carved_pages = 0;
+ debug("%s: 0x%" PRIx64 " 0x%" PRIx64 " %d %s\n", __func__,
+ start, pages, memory_type, overlap_only_ram ? "yes" : "no");
+
if (!pages)
return start;
--
2.6.6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] efi_loader: Add debug output for efi_add_memory_map()
Am 17.07.2016 um 06:57 schrieb Andreas Färber:
> Tracing the arguments has been helpful for pinpointing overflows.
>
> Cc: Alexander Graf
> Signed-off-by: Andreas Färber
> ---
> lib/efi_loader/efi_memory.c | 3 +++
> 1 file changed, 3 insertions(+)
v2 uses debug(), rebased on the DEBUG_EFI cleanup, requested by Tom.
>
> diff --git a/lib/efi_loader/efi_memory.c b/lib/efi_loader/efi_memory.c
> index df2381e..df3547c 100644
> --- a/lib/efi_loader/efi_memory.c
> +++ b/lib/efi_loader/efi_memory.c
> @@ -130,6 +130,9 @@ uint64_t efi_add_memory_map(uint64_t start, uint64_t
> pages, int memory_type,
> bool carve_again;
> uint64_t carved_pages = 0;
>
> + debug("%s: 0x%" PRIx64 " 0x%" PRIx64 " %d %s\n", __func__,
> + start, pages, memory_type, overlap_only_ram ? "yes" : "no");
> +
> if (!pages)
> return start;
>
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 2/5] ARM64: rockchip: add support for rk3399 SoC based evb-board
Am 15.07.2016 um 10:42 schrieb Kever Yang: > diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig > index d3f5ffd..8499692 100644 > --- a/arch/arm/mach-rockchip/Kconfig > +++ b/arch/arm/mach-rockchip/Kconfig > @@ -9,6 +9,10 @@ config ROCKCHIP_RK3288 > video interfaces supporting HDMI and eDP, several DDR3 options > and video codec support. Peripherals include Gigabit Ethernet, > USB2 host and OTG, SDIO, I2S, UART,s, SPI, I2C and PWMs. > + select CPU_V7 This is duplicating the select I added above. Please move them all to above help. Same below. > + select RK_TIMER > + select SUPPORT_SPL > + select SPL > > config ROCKCHIP_RK3036 > bool "Support Rockchip RK3036" > @@ -18,6 +22,21 @@ config ROCKCHIP_RK3036 > including NEON and GPU, Mali-400 graphics, several DDR3 options > and video codec support. Peripherals include Gigabit Ethernet, > USB2 host and OTG, SDIO, I2S, UART, SPI, I2C and PWMs. > + select CPU_V7 > + select RK_TIMER > + select SUPPORT_SPL > + select SPL > + > +config ROCKCHIP_RK3399 > + bool "Support Rockchip RK3399" > + help > + The Rockchip RK3399 is a ARM-based SoC with a dual-core Cortex-A72 > + and qual-core Cortex-A53. > + including NEON and GPU, 1MB L2 cache, Mali-T7 graphics, two > + video interfaces supporting HDMI and eDP, several DDR3 options > + and video codec support. Peripherals include Gigabit Ethernet, > + USB2 host and OTG, SDIO, I2S, UART,s, SPI, I2C and PWMs. > + select ARM64 > > config SYS_MALLOC_F > default y [snip] Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 2/5] ARM64: rockchip: add support for rk3399 SoC based evb-board
Am 15.07.2016 um 10:42 schrieb Kever Yang:
> diff --git a/board/rockchip/evb_rk3399/evb-rk3399.c
> b/board/rockchip/evb_rk3399/evb-rk3399.c
> new file mode 100644
> index 000..357b08b
> --- /dev/null
> +++ b/board/rockchip/evb_rk3399/evb-rk3399.c
> @@ -0,0 +1,41 @@
> +/*
> + * (C) Copyright 2016 Rockchip Electronics Co., Ltd
> + *
> + * SPDX-License-Identifier: GPL-2.0+
> + */
> +#include
> +#include
> +#include
> +
> +DECLARE_GLOBAL_DATA_PTR;
> +
> +static struct mm_region rk3399_mem_map[] = {
> + {
> + .base = 0x0UL,
> + .size = 0x8000UL,
> + .attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
> + PTE_BLOCK_INNER_SHARE
> + }, {
> + .base = 0xf000UL,
> + .size = 0x1000UL,
> + .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
> + PTE_BLOCK_NON_SHARE |
> + PTE_BLOCK_PXN | PTE_BLOCK_UXN
> + }, {
> + /* List terminator */
> + 0,
> + }
> +};
> +
> +struct mm_region *mem_map = rk3399_mem_map;
[snip]
Why have this at board level? Wouldn't this be better kept in mach-rockchip?
Regards,
Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/5] dts: add support for rkchichip rk3399 soc
Am 15.07.2016 um 10:42 schrieb Kever Yang: > These files are from kernel upstream with some modification > need by uboot: > - chosen with stdout-path to uart2. Please also mention: - clock-frequency for uart2 Cost me quite some time to figure out this was necessary... Regards, Andreas > > Signed-off-by: Kever Yang [snip] -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 2/5] ARM64: rockchip: add support for rk3399 SoC based evb-board
Hi, Isn't evb short for evaluation board? That makes board board then. ;) Am 15.07.2016 um 10:42 schrieb Kever Yang: > RK3399 is a SoC from Rockchip with dual-core Cortex-A72 > and qual-core Cortex-A53 CPU. It supports two USB3.0 quad-core > type-C ports and two USB2.0 EHCI ports. Other interfaces > are very like RK3288, the DRAM are 32bit width address "very much like" or "very similar to" > and support address from 0 to 4GB-128MB range. > > Signed-off-by: Kever Yang > --- > > Changes in v3: > Rebase on patch from Andreas: > [PATCH] rockchip: Exclude rk_timer for ARM64 > [PATCH] rockchip: Clean up CPU selection > > Changes in v2: > fix description error on board Kconfig > > arch/arm/Kconfig | 2 - > arch/arm/mach-rockchip/Kconfig | 22 - > arch/arm/mach-rockchip/rk3399/Kconfig | 14 ++ > arch/arm/mach-rockchip/rk3399/Makefile | 5 ++ > board/rockchip/evb_rk3399/Kconfig | 15 ++ > board/rockchip/evb_rk3399/MAINTAINERS | 0 > board/rockchip/evb_rk3399/Makefile | 7 +++ > board/rockchip/evb_rk3399/evb-rk3399.c | 41 + > include/configs/evb_rk3399.h | 24 ++ > include/configs/rk3399_common.h| 84 > ++ > 10 files changed, 211 insertions(+), 3 deletions(-) > create mode 100644 arch/arm/mach-rockchip/rk3399/Kconfig > create mode 100644 arch/arm/mach-rockchip/rk3399/Makefile > create mode 100644 board/rockchip/evb_rk3399/Kconfig > create mode 100644 board/rockchip/evb_rk3399/MAINTAINERS > create mode 100644 board/rockchip/evb_rk3399/Makefile > create mode 100644 board/rockchip/evb_rk3399/evb-rk3399.c > create mode 100644 include/configs/evb_rk3399.h > create mode 100644 include/configs/rk3399_common.h > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > index a262145..6e4d78a 100644 > --- a/arch/arm/Kconfig > +++ b/arch/arm/Kconfig > @@ -846,8 +846,6 @@ config STM32 > > config ARCH_ROCKCHIP > bool "Support Rockchip SoCs" > - select SUPPORT_SPL > - select SPL > select OF_CONTROL > select DM > > diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig > index d3f5ffd..8499692 100644 > --- a/arch/arm/mach-rockchip/Kconfig > +++ b/arch/arm/mach-rockchip/Kconfig > @@ -9,6 +9,10 @@ config ROCKCHIP_RK3288 > video interfaces supporting HDMI and eDP, several DDR3 options > and video codec support. Peripherals include Gigabit Ethernet, > USB2 host and OTG, SDIO, I2S, UART,s, SPI, I2C and PWMs. > + select CPU_V7 > + select RK_TIMER You no longer define RK_TIMER - either please do (I liked it) or drop the selection, it leads to warnings on, e.g., firefly-rk3288_defconfig otherwise. > + select SUPPORT_SPL > + select SPL > > config ROCKCHIP_RK3036 > bool "Support Rockchip RK3036" > @@ -18,6 +22,21 @@ config ROCKCHIP_RK3036 > including NEON and GPU, Mali-400 graphics, several DDR3 options > and video codec support. Peripherals include Gigabit Ethernet, > USB2 host and OTG, SDIO, I2S, UART, SPI, I2C and PWMs. > + select CPU_V7 > + select RK_TIMER > + select SUPPORT_SPL > + select SPL > + > +config ROCKCHIP_RK3399 > + bool "Support Rockchip RK3399" > + help > + The Rockchip RK3399 is a ARM-based SoC with a dual-core Cortex-A72 > + and qual-core Cortex-A53. quad-core > + including NEON and GPU, 1MB L2 cache, Mali-T7 graphics, two > + video interfaces supporting HDMI and eDP, several DDR3 options > + and video codec support. Peripherals include Gigabit Ethernet, > + USB2 host and OTG, SDIO, I2S, UART,s, SPI, I2C and PWMs. UARTs > + select ARM64 > > config SYS_MALLOC_F > default y > @@ -44,8 +63,9 @@ config DM_GPIO > default y > > config BLK > - default y > + default y if CPU_V7 Needs rebasing onto u-boot-rockchip.git. > > source "arch/arm/mach-rockchip/rk3288/Kconfig" > source "arch/arm/mach-rockchip/rk3036/Kconfig" > +source "arch/arm/mach-rockchip/rk3399/Kconfig" > endif > diff --git a/arch/arm/mach-rockchip/rk3399/Kconfig > b/arch/arm/mach-rockchip/rk3399/Kconfig > new file mode 100644 > index 000..923a6de > --- /dev/null > +++ b/arch/arm/mach-rockchip/rk3399/Kconfig > @@ -0,0 +1,14 @@ > +if ROCKCHIP_RK3399 > + > +config TARGET_EVB_RK3399 > + bool "RK3399 evb board" Should this be enclosed in a choice section for futureproofness? > + > +config SYS_SOC > + default "rockchip" > + > +config SYS_MALLOC_F_LEN > + default 0x0800 > + > +source "board/rockchip/evb_rk3399/Kconfig" > + > +endif > diff --git a/arch/arm/mach-rockchip/rk3399/Makefile > b/arch/arm/mach-rockchip/rk3399/Makefile > new file mode 100644 > index 000..ca69207 > --- /dev/null > +++ b/arch/arm/mach-rockchip/rk3399/Makefile > @@ -0,0 +1,5 @@ > +# > +# Copyright (C) 2016 Rockchip Electronics Co., Ltd > +# > +# SPDX-License-Identifier: GPL-2.0+ > +# Needed? > d
[U-Boot] [PATCH 0/2] rockchip: Initial RK3368 and GeekBox support
Hi, This series adds initial support for RK3368 SoC and GeekBox. For more details see the commit message. Will need to be rebased onto Heiko's cleanups and Kever's RK3399 series. Regards, Andreas Cc: Simon Glass Cc: Kever Yang Cc: Heiko Stübner Andreas Färber (2): dts: Import rk3368-geekbox.dts ARM64: rockchip: Add initial support for RK3368 based GeekBox arch/arm/Kconfig |4 - arch/arm/dts/Makefile |3 +- arch/arm/dts/rk3368-geekbox.dts| 319 ++ arch/arm/dts/rk3368.dtsi | 1082 arch/arm/mach-rockchip/Kconfig | 14 + arch/arm/mach-rockchip/Makefile|1 + arch/arm/mach-rockchip/rk3368/Kconfig | 14 + arch/arm/mach-rockchip/rk3368/Makefile |7 + arch/arm/mach-rockchip/rk3368/rk3368.c | 28 + board/geekbuying/geekbox/Kconfig | 15 + board/geekbuying/geekbox/Makefile |7 + board/geekbuying/geekbox/geekbox.c | 26 + configs/geekbox_defconfig | 20 + include/configs/geekbox.h | 19 + include/configs/rk3368_common.h| 47 ++ include/dt-bindings/clock/rk3368-cru.h | 384 16 files changed, 1985 insertions(+), 5 deletions(-) create mode 100644 arch/arm/dts/rk3368-geekbox.dts create mode 100644 arch/arm/dts/rk3368.dtsi create mode 100644 arch/arm/mach-rockchip/rk3368/Kconfig create mode 100644 arch/arm/mach-rockchip/rk3368/Makefile create mode 100644 arch/arm/mach-rockchip/rk3368/rk3368.c create mode 100644 board/geekbuying/geekbox/Kconfig create mode 100644 board/geekbuying/geekbox/Makefile create mode 100644 board/geekbuying/geekbox/geekbox.c create mode 100644 configs/geekbox_defconfig create mode 100644 include/configs/geekbox.h create mode 100644 include/configs/rk3368_common.h create mode 100644 include/dt-bindings/clock/rk3368-cru.h -- 2.6.6 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] ARM64: rockchip: Add initial support for RK3368 based GeekBox
The RK3368 is an octa-core Cortex-A53 SoC from Rockchip.
The GeekBox is a TV box from GeekBuying, based on an MXM3 module.
The module can be used with base boards such as the GeekBox Landingship.
This adds basic support to chain-load U-Boot from Rockchip's miniloader.
$ ./lollipop_u-boot/tools/loaderimage --pack u-boot.bin u-boot.img
# ./utils/upgrade_tool di uboot u-boot.img
Implemented is the serial console, but no boot media drivers yet.
Note that flashing the resulting U-Boot will not allow you to enter the
rockusb mode any more via "Update" button. Instead, you will need to
short two pins on the bottom of the module to enter MaskRom mode and
re-flash the loader:
# ./utils/upgrade_tool ul ./lollipop_u-boot/RK3368MiniLoaderAll_V2.40.bin
# ./utils/upgrade_tool di uboot u-boot.img
Signed-off-by: Andreas Färber
---
arch/arm/Kconfig | 4 ---
arch/arm/dts/rk3368.dtsi | 1 +
arch/arm/mach-rockchip/Kconfig | 14 ++
arch/arm/mach-rockchip/Makefile| 1 +
arch/arm/mach-rockchip/rk3368/Kconfig | 14 ++
arch/arm/mach-rockchip/rk3368/Makefile | 7 +
arch/arm/mach-rockchip/rk3368/rk3368.c | 28
board/geekbuying/geekbox/Kconfig | 15 +++
board/geekbuying/geekbox/Makefile | 7 +
board/geekbuying/geekbox/geekbox.c | 26 +++
configs/geekbox_defconfig | 20 +++
include/configs/geekbox.h | 19 ++
include/configs/rk3368_common.h| 47 ++
13 files changed, 199 insertions(+), 4 deletions(-)
create mode 100644 arch/arm/mach-rockchip/rk3368/Kconfig
create mode 100644 arch/arm/mach-rockchip/rk3368/Makefile
create mode 100644 arch/arm/mach-rockchip/rk3368/rk3368.c
create mode 100644 board/geekbuying/geekbox/Kconfig
create mode 100644 board/geekbuying/geekbox/Makefile
create mode 100644 board/geekbuying/geekbox/geekbox.c
create mode 100644 configs/geekbox_defconfig
create mode 100644 include/configs/geekbox.h
create mode 100644 include/configs/rk3368_common.h
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index f9fddad..4ff1a26 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -838,14 +838,10 @@ config STM32
config ARCH_ROCKCHIP
bool "Support Rockchip SoCs"
- select SUPPORT_SPL
- select SPL
select OF_CONTROL
select BLK
select DM
- select SPL_DM
select SYS_MALLOC_F
- select SPL_SYS_MALLOC_SIMPLE
select DM_GPIO
select DM_I2C
select DM_MMC
diff --git a/arch/arm/dts/rk3368.dtsi b/arch/arm/dts/rk3368.dtsi
index 8b4a7c9..3ab7edc 100644
--- a/arch/arm/dts/rk3368.dtsi
+++ b/arch/arm/dts/rk3368.dtsi
@@ -609,6 +609,7 @@
uart2: serial@ff69 {
compatible = "rockchip,rk3368-uart", "snps,dw-apb-uart";
reg = <0x0 0xff69 0x0 0x100>;
+ clock-frequency = <2400>;
clocks = <&cru SCLK_UART2>, <&cru PCLK_UART2>;
clock-names = "baudclk", "apb_pclk";
interrupts = ;
diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig
index 86b77f8..597f043 100644
--- a/arch/arm/mach-rockchip/Kconfig
+++ b/arch/arm/mach-rockchip/Kconfig
@@ -3,6 +3,10 @@ if ARCH_ROCKCHIP
config ROCKCHIP_RK3288
bool "Support Rockchip RK3288"
select CPU_V7
+ select SUPPORT_SPL
+ select SPL
+ select SPL_DM
+ select SPL_SYS_MALLOC_SIMPLE
help
The Rockchip RK3288 is a ARM-based SoC with a quad-core Cortex-A17
including NEON and GPU, 1MB L2 cache, Mali-T7 graphics, two
@@ -13,12 +17,21 @@ config ROCKCHIP_RK3288
config ROCKCHIP_RK3036
bool "Support Rockchip RK3036"
select CPU_V7
+ select SUPPORT_SPL
+ select SPL
+ select SPL_DM
+ select SPL_SYS_MALLOC_SIMPLE
help
The Rockchip RK3036 is a ARM-based SoC with a dual-core Cortex-A7
including NEON and GPU, Mali-400 graphics, several DDR3 options
and video codec support. Peripherals include Gigabit Ethernet,
USB2 host and OTG, SDIO, I2S, UART, SPI, I2C and PWMs.
+config ROCKCHIP_RK3368
+ bool "Support Rockchip RK3368"
+ select ARM64
+ select SYS_NS16550
+
config ROCKCHIP_SPL_BACK_TO_BROM
bool "SPL returns to bootrom"
default y if ROCKCHIP_RK3036
@@ -29,4 +42,5 @@ config ROCKCHIP_SPL_BACK_TO_BROM
source "arch/arm/mach-rockchip/rk3288/Kconfig"
source "arch/arm/mach-rockchip/rk3036/Kconfig"
+source "arch/arm/mach-rockchip/rk3368/Kconfig"
endif
diff --git a/arch/arm/mach-rockchip/Makefile b/arch/arm/mach-rockchip/Makefile
index 6763af4..48e78c1 100644
--- a/arch/arm/mach-rockchip/Makefile
+++
[U-Boot] [PATCH 1/2] dts: Import rk3368-geekbox.dts
Unmodified from Linux kernel v4.7-rc6.
Signed-off-by: Andreas Färber
---
arch/arm/dts/Makefile |3 +-
arch/arm/dts/rk3368-geekbox.dts| 319 ++
arch/arm/dts/rk3368.dtsi | 1081
include/dt-bindings/clock/rk3368-cru.h | 384
4 files changed, 1786 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/dts/rk3368-geekbox.dts
create mode 100644 arch/arm/dts/rk3368.dtsi
create mode 100644 include/dt-bindings/clock/rk3368-cru.h
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 73e334e..fd355e3 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -32,7 +32,8 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += \
rk3288-jerry.dtb \
rk3288-rock2-square.dtb \
rk3288-evb.dtb \
- rk3036-sdk.dtb
+ rk3036-sdk.dtb \
+ rk3368-geekbox.dtb
dtb-$(CONFIG_ARCH_MESON) += \
meson-gxbb-odroidc2.dtb
dtb-$(CONFIG_TEGRA) += tegra20-harmony.dtb \
diff --git a/arch/arm/dts/rk3368-geekbox.dts b/arch/arm/dts/rk3368-geekbox.dts
new file mode 100644
index 000..46cdddf
--- /dev/null
+++ b/arch/arm/dts/rk3368-geekbox.dts
@@ -0,0 +1,319 @@
+/*
+ * Copyright (c) 2016 Andreas Färber
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include "rk3368.dtsi"
+#include
+
+/ {
+ model = "GeekBox";
+ compatible = "geekbuying,geekbox", "rockchip,rk3368";
+
+ chosen {
+ stdout-path = "serial2:115200n8";
+ };
+
+ memory@0 {
+ device_type = "memory";
+ reg = <0x0 0x0 0x0 0x8000>;
+ };
+
+ ext_gmac: gmac-clk {
+ compatible = "fixed-clock";
+ clock-frequency = <12500>;
+ clock-output-names = "ext_gmac";
+ #clock-cells = <0>;
+ };
+
+ ir: ir-receiver {
+ compatible = "gpio-ir-receiver";
+ gpios = <&gpio3 30 GPIO_ACTIVE_LOW>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&ir_int>;
+ };
+
+ keys: gpio-keys {
+ compatible = "gpio-keys";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pwr_key>;
+
+ power {
+ gpios = <&gpio0 2 GPIO_ACTIVE_LOW>;
+ label = "GPIO Power";
+ linux,code = ;
+ wakeup-source;
+ };
+ };
+
+ leds: gpio-leds {
+ compatible = "gpio-leds";
+
+ blue {
+ gpios = <&gpio2 2 GPIO_ACTIVE_HIGH>;
+ label = "geekbox:blue:led";
+ default-state = "on";
+ };
+
+ red {
+ gpios = <&gpio2 3 GPIO_ACTIVE_HIGH>
Re: [U-Boot] [PATCH v3 2/5] ARM64: rockchip: add support for rk3399 SoC based evb-board
Am 15.07.2016 um 10:42 schrieb Kever Yang: > diff --git a/include/configs/rk3399_common.h b/include/configs/rk3399_common.h > new file mode 100644 > index 000..1c13e2e > --- /dev/null > +++ b/include/configs/rk3399_common.h [...] > +#ifndef CONFIG_SPL_BUILD > +#include > + > +#define ENV_MEM_LAYOUT_SETTINGS \ > + "scriptaddr=0x\0" \ > + "pxefile_addr_r=0x0010\0" \ > + "fdt_addr_r=0x01f0\0" \ > + "kernel_addr_r=0x0200\0" \ > + "ramdisk_addr_r=0x0400\0" > + > +/* First try to boot from SD (index 0), then eMMC (index 1 */ > +#define BOOT_TARGET_DEVICES(func) \ > + func(MMC, mmc, 0) \ > + func(MMC, mmc, 1) > + > +#include Lacking CONFIG_EXTRA_ENV_SETTINGS that incorporates BOOTENV, otherwise leads to error message about missing $distro_bootcmd. > +#endif > + > +#endif Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] ARM64: rockchip: Add initial support for RK3368 based GeekBox
Am 18.07.2016 um 03:06 schrieb Andreas Färber:
> The RK3368 is an octa-core Cortex-A53 SoC from Rockchip.
>
> The GeekBox is a TV box from GeekBuying, based on an MXM3 module.
> The module can be used with base boards such as the GeekBox Landingship.
>
> This adds basic support to chain-load U-Boot from Rockchip's miniloader.
>
> $ ./lollipop_u-boot/tools/loaderimage --pack u-boot.bin u-boot.img
> # ./utils/upgrade_tool di uboot u-boot.img
>
> Implemented is the serial console, but no boot media drivers yet.
>
> Note that flashing the resulting U-Boot will not allow you to enter the
> rockusb mode any more via "Update" button. Instead, you will need to
> short two pins on the bottom of the module to enter MaskRom mode and
> re-flash the loader:
>
> # ./utils/upgrade_tool ul ./lollipop_u-boot/RK3368MiniLoaderAll_V2.40.bin
> # ./utils/upgrade_tool di uboot u-boot.img
>
> Signed-off-by: Andreas Färber
> ---
> arch/arm/Kconfig | 4 ---
> arch/arm/dts/rk3368.dtsi | 1 +
> arch/arm/mach-rockchip/Kconfig | 14 ++
> arch/arm/mach-rockchip/Makefile| 1 +
> arch/arm/mach-rockchip/rk3368/Kconfig | 14 ++
> arch/arm/mach-rockchip/rk3368/Makefile | 7 +
> arch/arm/mach-rockchip/rk3368/rk3368.c | 28
> board/geekbuying/geekbox/Kconfig | 15 +++
> board/geekbuying/geekbox/Makefile | 7 +
> board/geekbuying/geekbox/geekbox.c | 26 +++
> configs/geekbox_defconfig | 20 +++
> include/configs/geekbox.h | 19 ++
> include/configs/rk3368_common.h| 47
> ++
> 13 files changed, 199 insertions(+), 4 deletions(-)
> create mode 100644 arch/arm/mach-rockchip/rk3368/Kconfig
> create mode 100644 arch/arm/mach-rockchip/rk3368/Makefile
> create mode 100644 arch/arm/mach-rockchip/rk3368/rk3368.c
> create mode 100644 board/geekbuying/geekbox/Kconfig
> create mode 100644 board/geekbuying/geekbox/Makefile
> create mode 100644 board/geekbuying/geekbox/geekbox.c
> create mode 100644 configs/geekbox_defconfig
> create mode 100644 include/configs/geekbox.h
> create mode 100644 include/configs/rk3368_common.h
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index f9fddad..4ff1a26 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -838,14 +838,10 @@ config STM32
>
> config ARCH_ROCKCHIP
> bool "Support Rockchip SoCs"
> - select SUPPORT_SPL
> - select SPL
> select OF_CONTROL
> select BLK
> select DM
> - select SPL_DM
> select SYS_MALLOC_F
> - select SPL_SYS_MALLOC_SIMPLE
> select DM_GPIO
> select DM_I2C
> select DM_MMC
> diff --git a/arch/arm/dts/rk3368.dtsi b/arch/arm/dts/rk3368.dtsi
> index 8b4a7c9..3ab7edc 100644
> --- a/arch/arm/dts/rk3368.dtsi
> +++ b/arch/arm/dts/rk3368.dtsi
> @@ -609,6 +609,7 @@
> uart2: serial@ff69 {
> compatible = "rockchip,rk3368-uart", "snps,dw-apb-uart";
> reg = <0x0 0xff69 0x0 0x100>;
> + clock-frequency = <2400>;
> clocks = <&cru SCLK_UART2>, <&cru PCLK_UART2>;
> clock-names = "baudclk", "apb_pclk";
> interrupts = ;
> diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig
> index 86b77f8..597f043 100644
> --- a/arch/arm/mach-rockchip/Kconfig
> +++ b/arch/arm/mach-rockchip/Kconfig
> @@ -3,6 +3,10 @@ if ARCH_ROCKCHIP
> config ROCKCHIP_RK3288
> bool "Support Rockchip RK3288"
> select CPU_V7
> + select SUPPORT_SPL
> + select SPL
> + select SPL_DM
> + select SPL_SYS_MALLOC_SIMPLE
> help
> The Rockchip RK3288 is a ARM-based SoC with a quad-core Cortex-A17
> including NEON and GPU, 1MB L2 cache, Mali-T7 graphics, two
> @@ -13,12 +17,21 @@ config ROCKCHIP_RK3288
> config ROCKCHIP_RK3036
> bool "Support Rockchip RK3036"
> select CPU_V7
> + select SUPPORT_SPL
> + select SPL
> + select SPL_DM
> + select SPL_SYS_MALLOC_SIMPLE
> help
> The Rockchip RK3036 is a ARM-based SoC with a dual-core Cortex-A7
> including NEON and GPU, Mali-400 graphics, several DDR3 options
> and video codec support. Peripherals include Gigabit Ethernet,
> USB2 host and OTG, SDIO, I2S, UART, SPI, I2C and PWMs.
>
> +config ROCKCHIP_RK3368
> + bool "Support Rockchip RK3368"
> + select ARM64
> + select SYS_NS16550
>
Re: [U-Boot] [PATCH v4 1/4] dts: add support for Rockchip rk3399 soc
Am 18.07.2016 um 10:46 schrieb Kever Yang: > These files are from kernel upstream with some modification > need by U-Boot: > - chosen with stdout-path to uart2. > > Signed-off-by: Kever Yang > Acked-by: Simon Glass > --- > > Changes in v4: None Commit message not extended as requested! Further I notice that arason is not in linux.git, so it would be good to further clarify which tree that came from or whether that is a U-Boot-local change as well. Andreas > Changes in v3: None > Changes in v2: None -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 2/4] ARM64: rockchip: add support for rk3399 SoC based evb
Am 18.07.2016 um 10:46 schrieb Kever Yang: > RK3399 is a SoC from Rockchip with dual-core Cortex-A72 > and quad-core Cortex-A53 CPU. It supports two USB3.0 > type-C ports and two USB2.0 EHCI ports. Other interfaces > are very much like RK3288, the DRAM are 32bit width address > and support address from 0 to 4GB-128MB range. > > Signed-off-by: Kever Yang > --- > > Changes in v4: > remove extra blank line in evb_rk3399.h, > remove unnecessary including file in rk3399_common.h, > fix base on commend from Andreas, > Rebase to U-Boot ToT. Most of my review comments are still unresolved... > > Changes in v3: > Rebase on patch from Andreas: > [PATCH] rockchip: Exclude rk_timer for ARM64 > [PATCH] rockchip: Clean up CPU selection > > Changes in v2: > fix description error on board Kconfig > > arch/arm/Kconfig | 2 - > arch/arm/mach-rockchip/Kconfig | 18 + > arch/arm/mach-rockchip/rk3399/Kconfig | 18 + > board/rockchip/evb_rk3399/Kconfig | 15 +++ > board/rockchip/evb_rk3399/MAINTAINERS | 0 > board/rockchip/evb_rk3399/Makefile | 7 > board/rockchip/evb_rk3399/evb-rk3399.c | 40 +++ > include/configs/evb_rk3399.h | 24 > include/configs/rk3399_common.h| 71 > ++ > 9 files changed, 193 insertions(+), 2 deletions(-) > create mode 100644 arch/arm/mach-rockchip/rk3399/Kconfig > create mode 100644 board/rockchip/evb_rk3399/Kconfig > create mode 100644 board/rockchip/evb_rk3399/MAINTAINERS > create mode 100644 board/rockchip/evb_rk3399/Makefile > create mode 100644 board/rockchip/evb_rk3399/evb-rk3399.c > create mode 100644 include/configs/evb_rk3399.h > create mode 100644 include/configs/rk3399_common.h > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > index f9fddad..fee6a1c 100644 > --- a/arch/arm/Kconfig > +++ b/arch/arm/Kconfig > @@ -838,8 +838,6 @@ config STM32 > > config ARCH_ROCKCHIP > bool "Support Rockchip SoCs" > - select SUPPORT_SPL > - select SPL > select OF_CONTROL > select BLK > select DM Here and below we seemed to get a merge conflict with Heiko's patch - he added ifs instead, but still they selects got added below. I don't care which way we do it, but it should be consistent please. > diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig > index 12415fc..4a4b6ee 100644 > --- a/arch/arm/mach-rockchip/Kconfig > +++ b/arch/arm/mach-rockchip/Kconfig > @@ -9,6 +9,9 @@ config ROCKCHIP_RK3288 > video interfaces supporting HDMI and eDP, several DDR3 options > and video codec support. Peripherals include Gigabit Ethernet, > USB2 host and OTG, SDIO, I2S, UART,s, SPI, I2C and PWMs. > + select CPU_V7 Still duplicate. > + select SUPPORT_SPL > + select SPL Still below help. > > config ROCKCHIP_RK3036 > bool "Support Rockchip RK3036" > @@ -18,7 +21,22 @@ config ROCKCHIP_RK3036 > including NEON and GPU, Mali-400 graphics, several DDR3 options > and video codec support. Peripherals include Gigabit Ethernet, > USB2 host and OTG, SDIO, I2S, UART, SPI, I2C and PWMs. > + select CPU_V7 > + select SUPPORT_SPL > + select SPL Ditto. > + > +config ROCKCHIP_RK3399 > + bool "Support Rockchip RK3399" > + help > + The Rockchip RK3399 is a ARM-based SoC with a dual-core Cortex-A72 > + and quad-core Cortex-A53. > + including NEON and GPU, 1MB L2 cache, Mali-T7 graphics, two > + video interfaces supporting HDMI and eDP, several DDR3 options > + and video codec support. Peripherals include Gigabit Ethernet, > + USB2 host and OTG, SDIO, I2S, UARTs, SPI, I2C and PWMs. > + select ARM64 Still below help. Note that in Simon's tree this slipped below the new BROM option, it should logically be above and after RK3288. > > source "arch/arm/mach-rockchip/rk3288/Kconfig" > source "arch/arm/mach-rockchip/rk3036/Kconfig" In Simon's tree this option accidentally got dropped in this patch! > +source "arch/arm/mach-rockchip/rk3399/Kconfig" > endif > diff --git a/arch/arm/mach-rockchip/rk3399/Kconfig > b/arch/arm/mach-rockchip/rk3399/Kconfig > new file mode 100644 > index 000..d15bb40 > --- /dev/null > +++ b/arch/arm/mach-rockchip/rk3399/Kconfig > @@ -0,0 +1,18 @@ > +if ROCKCHIP_RK3399 > + > +config TARGET_EVB_RK3399 > + bool "RK3399 evaluation board" > + help > + RK3399evb is a evaluation board for Rockchp rk3399, > + with full function and phisical connectors support like type-C ports, > + usb2.0 host ports, LVDS, JTAG, MAC, SDcard, HDMI, USB-2-serial... No choice - intentional or forgotten? > + > +config SYS_SOC > + default "rockchip" > + > +config SYS_MALLOC_F_LEN > + default 0x0800 > + > +source "board/rockchip/evb_rk3399/Kconfig" > + > +endif > diff --git a/board/rockchip/evb_rk3399/Kconfig > b/board/rockchip/evb_rk3399/Kconfig > new f
Re: [U-Boot] [PATCH v3 2/5] ARM64: rockchip: add support for rk3399 SoC based evb-board
Hi Kever, Am 18.07.2016 um 06:54 schrieb Kever Yang: > Hi Andreas, > > Thanks for you comments, I will apply them one by one except some > confuse below. > > On 07/18/2016 07:26 AM, Andreas Färber wrote: >> Hi, >> >> Isn't evb short for evaluation board? That makes board board then. ;) >> >> Am 15.07.2016 um 10:42 schrieb Kever Yang: >>> RK3399 is a SoC from Rockchip with dual-core Cortex-A72 >>> and qual-core Cortex-A53 CPU. It supports two USB3.0 >> quad-core >> >>> type-C ports and two USB2.0 EHCI ports. Other interfaces >>> are very like RK3288, the DRAM are 32bit width address >> "very much like" or "very similar to" >> >>> and support address from 0 to 4GB-128MB range. >>> >>> Signed-off-by: Kever Yang >>> --- >>> >>> Changes in v3: >>> Rebase on patch from Andreas: >>> [PATCH] rockchip: Exclude rk_timer for ARM64 >>> [PATCH] rockchip: Clean up CPU selection >>> >>> Changes in v2: >>> fix description error on board Kconfig >>> >>> arch/arm/Kconfig | 2 - >>> arch/arm/mach-rockchip/Kconfig | 22 - >>> arch/arm/mach-rockchip/rk3399/Kconfig | 14 ++ >>> arch/arm/mach-rockchip/rk3399/Makefile | 5 ++ >>> board/rockchip/evb_rk3399/Kconfig | 15 ++ >>> board/rockchip/evb_rk3399/MAINTAINERS | 0 >>> board/rockchip/evb_rk3399/Makefile | 7 +++ >>> board/rockchip/evb_rk3399/evb-rk3399.c | 41 + >>> include/configs/evb_rk3399.h | 24 ++ >>> include/configs/rk3399_common.h| 84 >>> ++ >>> 10 files changed, 211 insertions(+), 3 deletions(-) >>> create mode 100644 arch/arm/mach-rockchip/rk3399/Kconfig >>> create mode 100644 arch/arm/mach-rockchip/rk3399/Makefile >>> create mode 100644 board/rockchip/evb_rk3399/Kconfig >>> create mode 100644 board/rockchip/evb_rk3399/MAINTAINERS >>> create mode 100644 board/rockchip/evb_rk3399/Makefile >>> create mode 100644 board/rockchip/evb_rk3399/evb-rk3399.c >>> create mode 100644 include/configs/evb_rk3399.h >>> create mode 100644 include/configs/rk3399_common.h >>> >>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig >>> index a262145..6e4d78a 100644 >>> --- a/arch/arm/Kconfig >>> +++ b/arch/arm/Kconfig >>> @@ -846,8 +846,6 @@ config STM32 >>> config ARCH_ROCKCHIP >>> bool "Support Rockchip SoCs" >>> -select SUPPORT_SPL >>> -select SPL >>> select OF_CONTROL >>> select DM >>> diff --git a/arch/arm/mach-rockchip/Kconfig >>> b/arch/arm/mach-rockchip/Kconfig >>> index d3f5ffd..8499692 100644 >>> --- a/arch/arm/mach-rockchip/Kconfig >>> +++ b/arch/arm/mach-rockchip/Kconfig >>> @@ -9,6 +9,10 @@ config ROCKCHIP_RK3288 >>> video interfaces supporting HDMI and eDP, several DDR3 options >>> and video codec support. Peripherals include Gigabit Ethernet, >>> USB2 host and OTG, SDIO, I2S, UART,s, SPI, I2C and PWMs. >>> +select CPU_V7 >>> +select RK_TIMER >> You no longer define RK_TIMER - either please do (I liked it) or drop >> the selection, it leads to warnings on, e.g., firefly-rk3288_defconfig >> otherwise. >> >>> +select SUPPORT_SPL >>> +select SPL >>> config ROCKCHIP_RK3036 >>> bool "Support Rockchip RK3036" >>> @@ -18,6 +22,21 @@ config ROCKCHIP_RK3036 >>> including NEON and GPU, Mali-400 graphics, several DDR3 options >>> and video codec support. Peripherals include Gigabit Ethernet, >>> USB2 host and OTG, SDIO, I2S, UART, SPI, I2C and PWMs. >>> +select CPU_V7 >>> +select RK_TIMER >>> +select SUPPORT_SPL >>> +select SPL >>> + >>> +config ROCKCHIP_RK3399 >>> +bool "Support Rockchip RK3399" >>> +help >>> + The Rockchip RK3399 is a ARM-based SoC with a dual-core >>> Cortex-A72 >>> + and qual-core Cortex-A53. >> quad-core >> >>> + including NEON and GPU, 1MB L2 cache, Mali-T7 graphics, two >>> + video interfaces supporting HDMI and eDP, several DDR3 options >>> + and video codec support. Peripherals include Gigabit Ethernet, >>> + USB2 host and OTG, SDIO, I
Re: [U-Boot] what is the *recommended* split between defconfig file and header file?
Am 20.07.2016 um 10:56 schrieb Robert P. J. Day: > On Tue, 19 Jul 2016, Tom Rini wrote: > >> On Tue, Jul 19, 2016 at 04:15:47AM -0400, Robert P. J. Day wrote: >> >>> >>> kind of a style question but what is the preferred way to define a >>> board in the sense of what belongs in the defconfig file and what >>> belongs in the header file? >> >> The header files will eventually go away. Most of the contents are >> things that could be, but haven't yet been, converted. A few things >> like default environment are going to be harder to figure out. > > and what about the advantage of header files that allow the > inclusion of other header files to reduce duplication? will config > files be extended to allow the same thing? (they don't do that now, do > they?) Use Kconfig files for setting defaults or adding selects. Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] efi_loader: Always flush in cache line size granularity
Am 04.04.2016 um 09:32 schrieb Alexander Graf: > The cache line flush helpers only work properly when they get aligned > start and end addresses. Round our flush range to cache line size. It's > safe because we're guaranteed to flush within a single page which has the > same cache attributes. > > Reported-by: Marek Vasut > Signed-off-by: Alexander Graf > --- > lib/efi_loader/efi_runtime.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/lib/efi_loader/efi_runtime.c b/lib/efi_loader/efi_runtime.c > index 22bcd08..40acec0 100644 > --- a/lib/efi_loader/efi_runtime.c > +++ b/lib/efi_loader/efi_runtime.c > @@ -194,7 +194,8 @@ void efi_runtime_relocate(ulong offset, struct > efi_mem_desc *map) > #endif > > *p = newaddr; > - flush_dcache_range((ulong)p, (ulong)&p[1]); > + flush_dcache_range((ulong)p & ~(CONFIG_SYS_CACHELINE_SIZE - 1), > + ALIGN((ulong)&p[1], CONFIG_SYS_CACHELINE_SIZE)); dragonboard410c_defconfig fails to build with this due to undefined CONFIG_SYS_CACHELINE_SIZE. Do we need to #ifdef here or is the dragonboard410c at fault for not defining it? jetson-tk1_defconfig for instance builds fine with this patch. Regards, Andreas > } > > #ifndef IS_RELA -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] dragonboard410c: Add CONFIG_SYS_CACHELINE_SIZE
Am 11.04.2016 um 22:45 schrieb Mateusz Kulikowski: > Add missing define to board header file. > > Signed-off-by: Mateusz Kulikowski > --- > This patch fixes issue with efi_runtime patch: > http://lists.denx.de/pipermail/u-boot/2016-April/251121.html > > include/configs/dragonboard410c.h | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/include/configs/dragonboard410c.h > b/include/configs/dragonboard410c.h > index a63440f..26f95a7 100644 > --- a/include/configs/dragonboard410c.h > +++ b/include/configs/dragonboard410c.h > @@ -27,6 +27,8 @@ > #define CONFIG_SYS_LOAD_ADDR (CONFIG_SYS_SDRAM_BASE + 0x8) > #define CONFIG_SYS_BOOTM_LEN 0x100 /* 16MB max kernel size */ > > +#define CONFIG_SYS_CACHELINE_SIZE64 > + > /* UART */ > #define CONFIG_BAUDRATE 115200 I had tested a similar patch, so Reviewed-by: Andreas Färber Thanks, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC] efi_loader: Handle 32-bit memory overflows
jetson-tk1 has 2 GB of RAM at 0x8000, causing gd->ram_top to be zero.
Handle this by replacing it with 0x1 in that case.
Cc: Alexander Graf
Signed-off-by: Andreas Färber
---
lib/efi_loader/efi_memory.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/lib/efi_loader/efi_memory.c b/lib/efi_loader/efi_memory.c
index 138736f..7b87108 100644
--- a/lib/efi_loader/efi_memory.c
+++ b/lib/efi_loader/efi_memory.c
@@ -225,7 +225,7 @@ efi_status_t efi_allocate_pages(int type, int memory_type,
switch (type) {
case 0:
/* Any page */
- addr = efi_find_free_memory(len, gd->ram_top);
+ addr = efi_find_free_memory(len, gd->ram_top == 0 ?
0x1ull : gd->ram_top);
if (!addr) {
r = EFI_NOT_FOUND;
break;
@@ -343,7 +343,7 @@ int efi_memory_init(void)
/* Add U-Boot */
uboot_start = (gd->start_addr_sp - uboot_stack_size) & ~EFI_PAGE_MASK;
- uboot_pages = (gd->ram_top - uboot_start) >> EFI_PAGE_SHIFT;
+ uboot_pages = ((gd->ram_top == 0 ? 0x1ull : gd->ram_top) -
uboot_start) >> EFI_PAGE_SHIFT;
efi_add_memory_map(uboot_start, uboot_pages, EFI_LOADER_DATA, false);
/* Add Runtime Services */
--
2.6.6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] efi_loader: Add debug output for efi_add_memory_map()
Tracing the arguments has been helpful for pinpointing overflows.
Cc: Alexander Graf
Signed-off-by: Andreas Färber
---
lib/efi_loader/efi_memory.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/lib/efi_loader/efi_memory.c b/lib/efi_loader/efi_memory.c
index df99585..138736f 100644
--- a/lib/efi_loader/efi_memory.c
+++ b/lib/efi_loader/efi_memory.c
@@ -123,6 +123,11 @@ uint64_t efi_add_memory_map(uint64_t start, uint64_t
pages, int memory_type,
struct efi_mem_list *newlist;
bool do_carving;
+#ifdef DEBUG_EFI
+ printf("%s: 0x%" PRIx64 " 0x%" PRIx64 " %d %s\n", __func__,
+ start, pages, memory_type, overlap_only_ram ? "yes" : "no");
+#endif
+
if (!pages)
return start;
--
2.6.6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] efi_loader: Handle 32-bit memory overflows
Am 13.04.2016 um 07:50 schrieb Alexander Graf:
>> Am 13.04.2016 um 05:24 schrieb Andreas Färber :
>>
>> jetson-tk1 has 2 GB of RAM at 0x8000, causing gd->ram_top to be zero.
>> Handle this by replacing it with 0x1 in that case.
>
> Nice catch!
>
>>
>> Cc: Alexander Graf
>> Signed-off-by: Andreas Färber
>> ---
>> lib/efi_loader/efi_memory.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/lib/efi_loader/efi_memory.c b/lib/efi_loader/efi_memory.c
>> index 138736f..7b87108 100644
>> --- a/lib/efi_loader/efi_memory.c
>> +++ b/lib/efi_loader/efi_memory.c
>> @@ -225,7 +225,7 @@ efi_status_t efi_allocate_pages(int type, int
>> memory_type,
>>switch (type) {
>>case 0:
>>/* Any page */
>> -addr = efi_find_free_memory(len, gd->ram_top);
>> +addr = efi_find_free_memory(len, gd->ram_top == 0 ? 0x1ull
>> : gd->ram_top);
If we do use a constant, we should probably be using
UINT64_C(0x1) rather than ull for compatibility.
> Couldn't we just use gd->ram_top - 1? Then we underflow to 0x and
> everything should just work.
Hm, that does work in my testing. Is it guaranteed it will handle that
as unsigned long rather than uint64_t? And did you mean to always use it
that way or just in the zero case? I.e., might we be wasting one byte in
the non-zero case or is it guaranteed that the top of RAM is always
reserved?
I was wondering whether we might run into the same overflow problem on
aarch64, in which case my hunk would be wrong, but your -1 should work.
>>if (!addr) {
>>r = EFI_NOT_FOUND;
>>break;
>> @@ -343,7 +343,7 @@ int efi_memory_init(void)
>>
>>/* Add U-Boot */
>>uboot_start = (gd->start_addr_sp - uboot_stack_size) & ~EFI_PAGE_MASK;
>> -uboot_pages = (gd->ram_top - uboot_start) >> EFI_PAGE_SHIFT;
>> +uboot_pages = ((gd->ram_top == 0 ? 0x1ull : gd->ram_top) -
>> uboot_start) >> EFI_PAGE_SHIFT;
>
> Are you sure this hunk is necessary? We should already underflow to the
> correct value here.
Positive that _something_ here is necessary for sanity, it was using a
huge number of pages (uboot_start is uint64_t).
If we use an odd number like -1, then we probably should add
EFI_PAGE_MASK as done for the RAM for the non-zero case, shouldn't we?
That might overflow on aarch64 though...
>>efi_add_memory_map(uboot_start, uboot_pages, EFI_LOADER_DATA, false);
>>
>>/* Add Runtime Services */
>> --
>> 2.6.6
Thanks,
Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] efi_loader: Handle memory overflows
jetson-tk1 has 2 GB of RAM at 0x8000, causing gd->ram_top to be zero.
Handle this by either avoiding ram_top or by using the same type as
ram_top to reverse the overflow effect.
Cc: Alexander Graf
Signed-off-by: Andreas Färber
---
lib/efi_loader/efi_memory.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/lib/efi_loader/efi_memory.c b/lib/efi_loader/efi_memory.c
index 138736f..82003d7 100644
--- a/lib/efi_loader/efi_memory.c
+++ b/lib/efi_loader/efi_memory.c
@@ -225,7 +225,7 @@ efi_status_t efi_allocate_pages(int type, int memory_type,
switch (type) {
case 0:
/* Any page */
- addr = efi_find_free_memory(len, gd->ram_top);
+ addr = efi_find_free_memory(len, gd->start_addr_sp);
if (!addr) {
r = EFI_NOT_FOUND;
break;
@@ -325,9 +325,9 @@ efi_status_t efi_get_memory_map(unsigned long
*memory_map_size,
int efi_memory_init(void)
{
- uint64_t runtime_start, runtime_end, runtime_pages;
- uint64_t uboot_start, uboot_pages;
- uint64_t uboot_stack_size = 16 * 1024 * 1024;
+ unsigned long runtime_start, runtime_end, runtime_pages;
+ unsigned long uboot_start, uboot_pages;
+ unsigned long uboot_stack_size = 16 * 1024 * 1024;
int i;
/* Add RAM */
--
2.6.6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] dragonboard410c: Fix environment variables
Some variables for the distro boot commands were missing, using some custom name instead. Rename them. Cc: Mateusz Kulikowski Signed-off-by: Andreas Färber --- include/configs/dragonboard410c.h | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/include/configs/dragonboard410c.h b/include/configs/dragonboard410c.h index a63440f..6dd5fbf 100644 --- a/include/configs/dragonboard410c.h +++ b/include/configs/dragonboard410c.h @@ -126,10 +126,10 @@ REFLASH(dragonboard/u-boot.img, 8)\ "fdt_high=0x\0" \ "initrd_high=0x\0" \ "linux_image=Image\0" \ - "linux_addr=0x8100\0"\ - "fdt_image=apq8016-sbc.dtb\0" \ - "fdt_addr=0x8300\0"\ - "ramdisk_addr=0x8400\0"\ + "kernel_addr_r=0x8100\0"\ + "fdtfile=apq8016-sbc.dtb\0" \ + "fdt_addr_r=0x8300\0"\ + "ramdisk_addr_r=0x8400\0"\ BOOTENV #define CONFIG_ENV_IS_NOWHERE -- 2.6.6 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] dragonboard410c: Fix environment variables
Hi Daniel, Am 13.04.2016 um 14:16 schrieb Andreas Färber: > Some variables for the distro boot commands were missing, using some > custom name instead. Rename them. > > Cc: Mateusz Kulikowski > Signed-off-by: Andreas Färber > --- > include/configs/dragonboard410c.h | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/include/configs/dragonboard410c.h > b/include/configs/dragonboard410c.h > index a63440f..6dd5fbf 100644 > --- a/include/configs/dragonboard410c.h > +++ b/include/configs/dragonboard410c.h > @@ -126,10 +126,10 @@ REFLASH(dragonboard/u-boot.img, 8)\ > "fdt_high=0x\0" \ > "initrd_high=0x\0" \ > "linux_image=Image\0" \ > - "linux_addr=0x8100\0"\ > - "fdt_image=apq8016-sbc.dtb\0" \ > - "fdt_addr=0x8300\0"\ > - "ramdisk_addr=0x8400\0"\ > + "kernel_addr_r=0x8100\0"\ > + "fdtfile=apq8016-sbc.dtb\0" \ > + "fdt_addr_r=0x8300\0"\ > + "ramdisk_addr_r=0x8400\0"\ > BOOTENV > > #define CONFIG_ENV_IS_NOWHERE Forgot about investigating scriptaddr you mentioned. We can either add it in a v2 if there's something else, or you can follow up after this. EFI was still not working for me and I did not yet test boot.scr. Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] jetson-tk1: Set fdtfile environment variable
The 4.5.0 kernel cannot cope with U-Boot's internal device tree, and the distro boot commands are looking for $fdtfile, so provide it to avoid having users supply a dumb boot.scr doing a setenv fdtfile ...; boot, defeating the purpose of generic EFI boot. Cc: Stephen Warren Cc: Alexander Graf Signed-off-by: Andreas Färber --- include/configs/jetson-tk1.h | 4 1 file changed, 4 insertions(+) diff --git a/include/configs/jetson-tk1.h b/include/configs/jetson-tk1.h index 59dbb20..82a4be4 100644 --- a/include/configs/jetson-tk1.h +++ b/include/configs/jetson-tk1.h @@ -63,6 +63,10 @@ /* General networking support */ #define CONFIG_CMD_DHCP +#define BOARD_EXTRA_ENV_SETTINGS \ + "fdtfile=tegra124-jetson-tk1.dtb\0" \ + "" + #include "tegra-common-usb-gadget.h" #include "tegra-common-post.h" -- 2.6.6 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] efi_loader: Put fdt into convenient location
Am 11.04.2016 um 23:51 schrieb Alexander Graf: > The uEFI spec doesn't dictate where the device tree should live at, but > legacy 32bit ARM grub2 has some assumptions that it may stay at its place > when it's already loaded by the firmware. > > So let's put it somewhere where Linux that comes after would happily find > it - around the recommended 128MB line. > > Signed-off-by: Alexander Graf Tested-by: Andreas Färber It definitely avoids a warning message. However, it does not always allow Linux to actually boot, e.g. on jetson-tk1 (patch sent). Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] efi_loader: Expose ascending efi memory map
Am 11.04.2016 um 23:51 schrieb Alexander Graf: > The EFI memory map does not need to be in a strict order, but 32bit > grub2 does expect it to be ascending. If it's not, it may try to > allocate memory inside the U-Boot data memory region. > > We already sort the memory map in descending order, so let's just > reverse it when we pass it to a payload. > > Signed-off-by: Alexander Graf Tested-by: Andreas Färber This fixed clearfog for me. Thanks, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] efi_loader: Always flush in cache line size granularity
Am 11.04.2016 um 23:20 schrieb Alexander Graf: > The cache line flush helpers only work properly when they get aligned > start and end addresses. Round our flush range to cache line size. It's > safe because we're guaranteed to flush within a single page which has the > same cache attributes. > > Reported-by: Marek Vasut > Signed-off-by: Alexander Graf Reviewed-by: Andreas Färber Tested-by: Andreas Färber Thanks, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] jetson-tk1: Set fdtfile environment variable
Am 13.04.2016 um 14:48 schrieb Andreas Färber: > The 4.5.0 kernel cannot cope with U-Boot's internal device tree, and the > distro boot commands are looking for $fdtfile, so provide it to avoid > having users supply a dumb boot.scr doing a setenv fdtfile ...; boot, > defeating the purpose of generic EFI boot. > > Cc: Stephen Warren > Cc: Alexander Graf > Signed-off-by: Andreas Färber > --- > include/configs/jetson-tk1.h | 4 > 1 file changed, 4 insertions(+) > > diff --git a/include/configs/jetson-tk1.h b/include/configs/jetson-tk1.h > index 59dbb20..82a4be4 100644 > --- a/include/configs/jetson-tk1.h > +++ b/include/configs/jetson-tk1.h > @@ -63,6 +63,10 @@ > /* General networking support */ > #define CONFIG_CMD_DHCP > > +#define BOARD_EXTRA_ENV_SETTINGS \ > + "fdtfile=tegra124-jetson-tk1.dtb\0" \ > + "" Is there any more intelligent solution than doing this for each board? Andreas > + > #include "tegra-common-usb-gadget.h" > #include "tegra-common-post.h" > > -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] efi_loader: Put fdt into convenient location
Am 13.04.2016 um 14:51 schrieb Andreas Färber: > Am 11.04.2016 um 23:51 schrieb Alexander Graf: >> The uEFI spec doesn't dictate where the device tree should live at, but >> legacy 32bit ARM grub2 has some assumptions that it may stay at its place >> when it's already loaded by the firmware. >> >> So let's put it somewhere where Linux that comes after would happily find >> it - around the recommended 128MB line. >> >> Signed-off-by: Alexander Graf > > Tested-by: Andreas Färber > > It definitely avoids a warning message. However, it does not always > allow Linux to actually boot, e.g. on jetson-tk1 (patch sent). Err, wrong patch for comment but still tested. :) Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] efi_loader: Use system fdt as fallback
Am 11.04.2016 um 16:55 schrieb Alexander Graf: > When the user did not pass any device tree or the boot script > didn't find any, let's use the system device tree as last resort > to get something the payload (Linux) may understand. > > This means that on systems that use the same device tree for U-Boot > and Linux we can just share it and there's no need to manually provide > a device tree in the target image. > > While at it, also copy and pad the device tree by 64kb to give us > space for modifications. > > Signed-off-by: Alexander Graf Tested-by: Andreas Färber It definitely avoids a warning message. However, it does not always allow Linux to actually boot, e.g. on jetson-tk1 (patch sent). Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/8] efi_loader: Support loading from El Torito isos
Am 11.04.2016 um 16:16 schrieb Alexander Graf: > Alexander Graf (8): > iso: Make little endian and 64bit safe > iso: Start with partition 1 > iso: Allow 512 byte sector size > efi_loader: Split drive add into function > efi_loader: Add el torito support > efi_loader: Pass file path to payload > efi_loader: Increase path string to 32 characters > distro: Enable iso partition code Tested-by: Andreas Färber Doesn't break the regular EFI boot path for me. Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
