Re: [U-Boot] [PATCH 2/2] at91: cleanup taurus port
Hello Eugen,
Am 12.04.2019 um 15:52 schrieb Heiko Schocher:
Hello Eugen,
Am 12.04.2019 um 15:07 schrieb eugen.hris...@microchip.com:
On 12.04.2019 15:53, Heiko Schocher wrote:
External E-Mail
Hello eugen,
Am 12.04.2019 um 13:24 schrieb eugen.hris...@microchip.com:
On 11.04.2019 08:53, Heiko Schocher wrote:
- at91sam9g20-taurus.dts: use labels
- cleanup taurus port to compile clean with
current mainline again. SPL has no serial
output anymore, so it fits into SRAM.
Signed-off-by: Heiko Schocher
[snip]
Hello Heiko,
This patch has several issues:
taurus_defconfig
+spl/dts/dt-platdata.c:11:46: error: missing braces around initializer
[-Werror=missing-braces]
+ static const struct dtd_simple_bus dtv_ahb = {
+ ^
+spl/dts/dt-platdata.c:20:46: error: missing braces around initializer
[-Werror=missing-braces]
+ static const struct dtd_simple_bus dtv_apb = {
+cc1: all warnings being treated as errors
+make[2]: *** [spl/dts/dt-platdata.o] Error 1
+make[1]: *** [spl/u-boot-spl] Error 2
+make: *** [sub-make] Error 2
Ah, I had not warnings as errors active ... sorry for this!
Hmmm:
in generated ./include/generated/dt-structs-gen.h
struct dtd_simple_bus {
bool ranges;
};
True but at line #44 you have
#define dtd_simple_bus dtd_atmel_at91rm9200_pinctrl
Which redefines things...
indeed. As this is an autmatic generated file, I must look deeper
into it!
Hmm... following wip patch solves the warning:
$ git diff
diff --git a/arch/arm/dts/at91sam9260.dtsi b/arch/arm/dts/at91sam9260.dtsi
index 800d96eb2f..551364513f 100644
--- a/arch/arm/dts/at91sam9260.dtsi
+++ b/arch/arm/dts/at91sam9260.dtsi
@@ -440,7 +440,7 @@
pinctrl: pinctrl@f400 {
#address-cells = <1>;
#size-cells = <1>;
- compatible = "atmel,at91rm9200-pinctrl",
"simple-bus";
+ compatible = "atmel,at91rm9200-pinctrl";
ranges = <0xf400 0xf400 0x600>;
reg = <0xf400 0x200 /* pioA */
0xf600 0x200 /* pioB */
$
This prevents that the line with:
#define dtd_simple_bus dtd_atmel_at91rm9200_pinctrl
gets created, but I wonder why other boards do not have this warning.
bye,
Heiko
bye,
Heiko
and in spl/dts/dt-platdata.c:
#include
static const struct dtd_simple_bus dtv_ahb = {
.ranges = true,
};
Do not see what is really wrong ... may friday afternoon ...
and axm_defconfig :
+drivers/built-in.o: In function `get_current':
+drivers/serial/serial.c:318: undefined reference to
`default_serial_console'
+make[2]: *** [spl/u-boot-spl] Error 1
+make[1]: *** [spl/u-boot-spl] Error 2
+make: *** [sub-make] Error 2
Ups, sorry, just forgot to add this, update this in v2.
Thanks for the review!
bye,
Heiko
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: h...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PULL] u-boot-stm32 for v2019.07-rc1
On Fri, Apr 12, 2019 at 03:44:05PM +, Patrick DELAUNAY wrote: > Hi Tom, > > please pull u-boot-smt32-20190412 including > the following STM32 related patches for v2019.07-rc1 > > - add trusted boot with TF-A for stm32mp1 > - stm32mp1 dts files sync'ed with Linux version > - add STM32MP1 Discovery boards (DK1 and DK2) > - add STMFX gpio expander driver > - misc improvement for stm3mp1 supports > - rename stpmu1 to stpmic1 (official name) > - stm32_qspi: move to exec_op (spi nor driver for stm32 mpu and mcu) > - add STM32 FMC2 NAND flash controller driver > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-marvell/master (v2)
On Fri, Apr 12, 2019 at 01:27:36PM +0200, Stefan Roese wrote: > Hi Tom, > > please pull the following Marvell related patches. I've > removed the board support, causing the out-of-tree building > error for now. I'll push this one after its resolved. Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-sunxi/master
On Fri, Apr 12, 2019 at 06:34:52PM +0530, Jagan Teki wrote: > Hi Tom, > > Please pull this PR. > > thanks, > Jagan. > > The following changes since commit 3c99166441bf3ea325af2da83cfe65430b49c066: > > Prepare v2019.04 (2019-04-08 21:40:40 -0400) > > are available in the Git repository at: > > git://git.denx.de/u-boot-sunxi.git master > > for you to fetch changes up to 067e0b9684d4f195d92e0b1de260d69dc1e0f2c5: > > sunxi: Allow booting from 128KB SD/eMMC offset (2019-04-10 15:34:32 +0530) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Please pull from u-boot-i2c
On Thu, Apr 11, 2019 at 08:33:18PM +0200, Heiko Schocher wrote: > Hello Tom, > > removed patch "i2c: mvtwsi: fix hang on SPL bind" as discussed on ML, > > so here the new pull request: > > The following changes since commit 3c99166441bf3ea325af2da83cfe65430b49c066: > > Prepare v2019.04 (2019-04-08 21:40:40 -0400) > > are available in the Git repository at: > > git://git.denx.de/u-boot-i2c.git master > > for you to fetch changes up to 84c80c63d53bc8a7779b1e7e7084ee3b2d20e768: > > misc: i2c_eeprom: add eeprom write support (2019-04-11 15:21:33 +0200) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] Build error: caused by CONFIG_SPL_LOG_CONSOLE
If I activate "Enable logging support in SPL" (ie. CONFIG_SPL_LOG_CONSOLE), ie. the following window in make menuconfig: Logging ---> [*] Enable logging support [*] Enable logging support in SPL [*] Enable logging support in TPL (5) Maximum log level to record (3) Maximum log level to record in SPL (NEW) (3) Maximum log level to record in TPL (6) Default logging level to display [*] Allow log output to the console [*] Allow log output to the console in SPL (NEW) [*] Allow log output to the console in SPL [ ] Provide a test for logging [*] Log all functions which return an error then the build fails as follows (paths sanitized): arm-linux-gnueabihf-ld.bfd: common/built-in.o: in function `log_get_cat_name': /.../u-boot/common/log.c:48: undefined reference to `uclass_get_name' arm-linux-gnueabihf-ld.bfd: common/built-in.o: in function `_log': /.../u-boot/common/log.c:212: undefined reference to `vsnprintf' scripts/Makefile.spl:384: recipe for target 'spl/u-boot-spl' failed make[1]: *** [spl/u-boot-spl] Error 1 Makefile:1664: recipe for target 'spl/u-boot-spl' failed make: *** [spl/u-boot-spl] Error 2 Deactivating "Enable logging support in SPL" builds ok. Version: U-Boot 2019.04-00077-g48ff1bc4f0 (using stock git source tree w/o any own modifications) Platform: CONFIG_ARM=y CONFIG_SYS_ARCH="arm" CONFIG_SYS_CPU="armv7" CONFIG_SYS_SOC="sunxi" CONFIG_SYS_BOARD="sunxi" CONFIG_SYS_CONFIG_NAME="sun7i" CONFIG_DEFAULT_DEVICE_TREE="sun7i-a20-lamobo-r1" ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 05/13] fdtdec: Implement fdtdec_add_reserved_memory()
From: Thierry Reding
This function can be used to add subnodes in the /reserved-memory node.
Reviewed-by: Simon Glass
Signed-off-by: Thierry Reding
---
Changes in v3:
- use fdt_generate_phandle() instead of fdtdec_generate_phandle()
- add device tree bindings for /reserved-memory
- add examples to code comments
Changes in v2:
- split fdt_{addr,size}_unpack() helpers into separate patch
- use name@x,y notation only if the upper cell is > 0
- use debug() instead of printf() to save code size
- properly compute number of cells in reg property
- fix carveout size computations, was off by one
- use #size-cells where appropriate
.../reserved-memory/reserved-memory.txt | 136 ++
include/fdtdec.h | 48 +++
lib/fdtdec.c | 131 +
3 files changed, 315 insertions(+)
create mode 100644
Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
Applied to u-boot-dm, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] clk: socfpga: replace dm_fdt_pre_reloc by dm_ofnode_pre_reloc
On Thu, 21 Mar 2019 at 01:21, Patrick Delaunay wrote: > > Prepare to remove dm_fdt_pre_reloc function. > > Signed-off-by: Patrick Delaunay > --- > > drivers/clk/altera/clk-arria10.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) Reviewed-by: Simon Glass Applied to u-boot-dm, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 10/13] fdtdec: test: Add carveout tests
On Fri, Mar 22, 2019 at 03:53:07PM +0800, Simon Glass wrote: > Hi Thierry, > > On Fri, 22 Mar 2019 at 02:10, Thierry Reding wrote: > > > > From: Thierry Reding > > > > Implement carveout tests for 32-bit and 64-bit builds. > > > > Signed-off-by: Thierry Reding > > --- > > Changes in v2: > > - new patch > > > > lib/fdtdec_test.c | 152 ++ > > 1 file changed, 152 insertions(+) > > Reviewed-by: Simon Glass > > Just an idea - as an alternative you could use the built-in device > tree as your base rather than creating a new one. But perhaps that > would only be safe on sandbox? Yeah, running that test on a live system would mess up the reserved memory regions. If U-Boot does something based on the reserved-memory node, or passes it on to the kernel, that's going to cause issues. The test also uses rather arbitrary values for the carveout, which may not point at system memory at all. Thierry Applied to u-boot-dm, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 09/13] fdtdec: test: Use compound statement macros
On Fri, 22 Mar 2019 at 02:10, Thierry Reding wrote: > > From: Thierry Reding > > This eliminates the need for intermediate helper functions and allow the > macros to return a value so that it can be used subsequently. > > Signed-off-by: Thierry Reding > --- > Changes in v2: > - new patch > > lib/fdtdec_test.c | 64 --- > 1 file changed, 22 insertions(+), 42 deletions(-) Reviewed-by: Simon Glass Applied to u-boot-dm, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] Please pull u-boot-dm
Hi Tom,
Build result at https://travis-ci.org/sglass68/u-boot/builds/519059521
The following changes since commit 02f173ca156cee8526dff87603d5e446b443cde3:
Merge branch 'master' of git://git.denx.de/u-boot-usb (2019-04-11
14:29:37 -0400)
are available in the Git repository at:
git://git.denx.de/u-boot-dm.git tags/pull-12apr19
for you to fetch changes up to 73c02e5e4fc1ef53d06289232edd6cc52e3d73f6:
fdt: Fix mkimage list to try every header type (2019-04-11 20:10:50 -0600)
fdtdec tests and improvements for carve-outs
pinctrl race-condition fix
various other fixes in sandbox, sound, mkimage, etc.
Christian Gmeiner (1):
dm: sound: make all functions static inline
Christoph Muellner (1):
dm: pinctrl: Remove obsolete function pinctrl_decode_pin_config_dm().
Eugeniu Rosca (1):
core: ofnode: Fix ASAN-reported stack-buffer-overflow in
of_get_address
Jordan Hand (1):
fdt: Fix mkimage list to try every header type
Michal Simek (1):
dm: Also remove interrupts property from SPL DT
Patrice Chotard (1):
dm: pinctrl: Avoid race condition on probe for UCLASS_PINCTRL
Patrick Delaunay (7):
dm: remove pre reloc properties in SPL and TPL device tree
dm: pinctrl: Skip gpio-controller node in pinconfig_post_bind()
syscon: update syscon_regmap_lookup_by_phandle
sysreset: use syscon_regmap_lookup_by_phandle
clk: at91: replace dm_fdt_pre_reloc by dm_ofnode_pre_reloc
clk: socfpga: replace dm_fdt_pre_reloc by dm_ofnode_pre_reloc
dm: remove unused function dm_fdt_pre_reloc
Simon Glass (1):
cros: Expand the Chromium OS documentation
Thierry Reding (15):
fdt: Remove duplicate code
vsprintf: Support phys_addr_t specifier unconditionally
sandbox: Use correct phys_{addr, size}_t for PHYS_64BIT=y
sandbox: Properly print physical addresses
libfdt: Add phandle generation helper
fdtdec: Add cpu_to_fdt_{addr, size}() macros
fdtdec: Add fdt_{addr, size}_unpack() helpers
fdtdec: Implement fdtdec_set_phandle()
fdtdec: Implement fdtdec_add_reserved_memory()
fdtdec: Implement carveout support functions
fdtdec: Add Kconfig symbol for tests
fdtdec: test: Fix build warning
fdtdec: test: Use compound statement macros
fdtdec: test: Add carveout tests
sandbox: Enable fdtdec tests
.../devicetree/bindings/reserved-memory/reserved-memory.txt| 136
++
arch/sandbox/dts/test.dts | 3 +-
arch/sandbox/include/asm/sdl.h | 4 +-
arch/sandbox/include/asm/types.h | 12 +-
arch/sandbox/lib/pci_io.c | 2 +-
common/fdt_support.c | 6 -
configs/sandbox64_defconfig| 1 +
configs/sandbox_defconfig | 1 +
doc/README.chromium| 296
--
doc/README.chromium-chainload | 239
drivers/clk/altera/clk-arria10.c | 3 +-
drivers/clk/at91/pmc.c | 2 +-
drivers/core/ofnode.c | 21
+--
drivers/core/syscon-uclass.c | 83
++---
drivers/core/util.c| 40
+---
drivers/pinctrl/pinctrl-uclass.c | 36
+---
drivers/sysreset/sysreset_syscon.c | 15 +-
dts/Kconfig| 8 +-
include/dm/pinctrl.h | 12 --
include/dm/util.h | 26
---
include/fdtdec.h | 169
+
lib/Kconfig| 4 +
lib/fdtdec.c | 225
+++
lib/fdtdec_test.c | 216
+-
lib/libfdt/fdt_ro.c| 31
lib/vsprintf.c | 2 +-
scripts/Makefile.lib | 1 +
scripts/dtc/libfdt/fdt_ro.c| 31
scripts/dtc/libfdt/libfdt.h| 19 ++
scripts/dtc/libfdt/libfdt_env.h| 1 +
test/dm/syscon.c
Re: [U-Boot] [PATCH v3 08/13] fdtdec: test: Fix build warning
On Fri, 22 Mar 2019 at 02:10, Thierry Reding wrote: > > From: Thierry Reding > > Hide the declaration of the "fd" variable When not building a DEBUG > configuration, to avoid the variable being unused. > > Signed-off-by: Thierry Reding > --- > Changes in v2: > - new patch > > lib/fdtdec_test.c | 2 ++ > 1 file changed, 2 insertions(+) Reviewed-by: Simon Glass Applied to u-boot-dm, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 07/13] fdtdec: Add Kconfig symbol for tests
On Fri, 22 Mar 2019 at 02:10, Thierry Reding wrote: > > From: Thierry Reding > > Runtime tests are provided as a test_fdtdec command implementation. Add > a Kconfig symbol that allows this command to be built so that the tests > can be used. > > Signed-off-by: Thierry Reding > --- > Changes in v2: > - new patch > > lib/Kconfig | 4 > 1 file changed, 4 insertions(+) Reviewed-by: Simon Glass Applied to u-boot-dm, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 04/13] fdtdec: Implement fdtdec_set_phandle()
Hi Thierry, On Fri, 22 Mar 2019 at 16:34, Thierry Reding wrote: > > On Fri, Mar 22, 2019 at 03:53:01PM +0800, Simon Glass wrote: > > Hi Thierry, > > > > On Fri, 22 Mar 2019 at 02:10, Thierry Reding > > wrote: > > > > > > From: Thierry Reding > > > > > > This function can be used to set a phandle for a given node. > > > > > > Signed-off-by: Thierry Reding > > > --- > > > Changes in v2: > > > - don't emit deprecated linux,phandle property > > > > > > include/fdtdec.h | 11 +++ > > > lib/fdtdec.c | 7 +++ > > > 2 files changed, 18 insertions(+) > > > Applied to u-boot-dm, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 06/13] fdtdec: Implement carveout support functions
From: Thierry Reding The fdtdec_get_carveout() and fdtdec_set_carveout() function can be used to read a carveout from a given node or add a carveout to a given node using the standard device tree bindings (involving reserved-memory nodes and the memory-region property). Reviewed-by: Simon Glass Signed-off-by: Thierry Reding --- Changes in v3: - add examples to code comments Changes in v2: - use debug() instead of printf() to save code size - fix carveout size computations, was off by one - use fdtdec_get_addr_size_auto_noparent() include/fdtdec.h | 81 lib/fdtdec.c | 87 2 files changed, 168 insertions(+) Applied to u-boot-dm, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] dm: remove unused function dm_fdt_pre_reloc
On Thu, 21 Mar 2019 at 01:21, Patrick Delaunay wrote: > > The function dm_ofnode_pre_reloc should be used instead > of the function dm_fdt_pre_reloc and avoid duplicated code. > > Signed-off-by: Patrick Delaunay > --- > > drivers/core/util.c | 24 > include/dm/util.h | 26 -- > 2 files changed, 50 deletions(-) Reviewed-by: Simon Glass Thanks. Applied to u-boot-dm, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 01/13] libfdt: Add phandle generation helper
Hi Thierry, On Mon, 25 Mar 2019 at 01:27, Thierry Reding wrote: > > On Fri, Mar 22, 2019 at 03:52:59PM +0800, Simon Glass wrote: > > On Fri, 22 Mar 2019 at 02:10, Thierry Reding > > wrote: > > > > > > From: Thierry Reding > > > > > > The new fdt_generate_phandle() function can be used to generate a new, > > > unused phandle given a specific device tree blob. The implementation is > > > somewhat naive in that it simply walks the entire device tree to find > > > the highest phandle value and then returns a phandle value one higher > > > than that. A more clever implementation might try to find holes in the > > > current set of phandle values and fill them. But this implementation is > > > relatively simple and works reliably. > > > > > > Also add a test that validates that phandles generated by this new API > > > are indeed unique. > > > > > > Signed-off-by: Thierry Reding > > > --- > > > Changes in v3: > > > - update to latest upstream commit > > > > > > lib/libfdt/fdt_ro.c | 31 +++ > > > scripts/dtc/libfdt/fdt_ro.c | 31 +++ > > > scripts/dtc/libfdt/libfdt.h | 19 +++ > > > scripts/dtc/libfdt/libfdt_env.h | 1 + > > > 4 files changed, 82 insertions(+) > > > > Reviewed-by: Simon Glass > > Looks like this was reverted again upstream (for, in my opinion, dubious > reasons). Shall I just move it to fdtdec again and we can convert to > whatever we end up with upstream, if anything, later on? Yes that is OK with me. Regards, Simon Applied to u-boot-dm, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] fdt: Fix mkimage list to try every header type
Image type is not supplied to `mkimage -l`. For this reason, we cannot use imagetool_verify_print_header_by_type. Instead, this patch uses imagetool_verify_print_header to look through all header types to find one where image validation succeeds. This patch fixes failures in test/image/test-imagetools.sh Signed-off-by: Jordan Hand Tested-by: Alex Kiernan Tested-by: Vagrant Cascadian --- Changes in v2: - Fix patch formatting to move commit message above the cut tools/mkimage.c | 23 +++ 1 file changed, 15 insertions(+), 8 deletions(-) Applied to u-boot-dm, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 11/13] sandbox: Enable fdtdec tests
On Fri, 22 Mar 2019 at 02:10, Thierry Reding wrote: > > From: Thierry Reding > > Enable fdtdec tests on sandbox configurations so that they can be run to > validate the fdtdec implementation. > > Signed-off-by: Thierry Reding > --- > Changes in v2: > - new patch > > configs/sandbox64_defconfig | 1 + > configs/sandbox_defconfig | 1 + > 2 files changed, 2 insertions(+) Reviewed-by: Simon Glass Applied to u-boot-dm, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] dm: sound: make all functions static inline
Fixes following compile problem:
➜ u-boot-mainline git:(master) ✗ make sandbox_defconfig all NO_SDL=1
scripts/kconfig/conf --syncconfig Kconfig
CHK include/config.h
CFG u-boot.cfg
GEN include/autoconf.mk
GEN include/autoconf.mk.dep
CHK include/config/uboot.release
CHK include/generated/version_autogenerated.h
CHK include/generated/timestamp_autogenerated.h
UPD include/generated/timestamp_autogenerated.h
CHK include/generated/generic-asm-offsets.h
HOSTCC tools/mkenvimage.o
HOSTLD tools/mkenvimage
HOSTCC tools/fit_image.o
HOSTCC tools/image-host.o
HOSTCC tools/dumpimage.o
HOSTLD tools/dumpimage
HOSTCC tools/mkimage.o
HOSTLD tools/mkimage
HOSTLD tools/fit_info
HOSTLD tools/fit_check_sign
CC cmd/version.o
GZIPcmd/config_data.gz
CHK cmd/config_data_gz.h
CHK cmd/config_data_size.h
CHK cmd/license_data_gz.h
CHK cmd/license_data_size.h
LD cmd/built-in.o
CC common/main.o
LD common/built-in.o
CC drivers/fastboot/fb_getvar.o
LD drivers/fastboot/built-in.o
LD drivers/video/built-in.o
ld.bfd: drivers/video/sandbox_sdl.o: in function `sandbox_sdl_sound_play':
/home/christian/projects/u-boot-mainline/./arch/sandbox/include/asm/sdl.h:110:
multiple definition of `sandbox_sdl_sound_play';
drivers/video/video-uclass.o:/home/christian/projects/u-boot-mainline/./arch/sandbox/include/asm/sdl.h:110:
first defined here
ld.bfd: drivers/video/sandbox_sdl.o: in function `sandbox_sdl_sound_init':
/home/christian/projects/u-boot-mainline/./arch/sandbox/include/asm/sdl.h:120:
multiple definition of `sandbox_sdl_sound_init';
drivers/video/video-uclass.o:/home/christian/projects/u-boot-mainline/./arch/sandbox/include/asm/sdl.h:120:
first defined here
make[3]: *** [scripts/Makefile.build:355: drivers/video/built-in.o] Fehler 1
make[2]: *** [scripts/Makefile.build:432: drivers/video] Fehler 2
make[1]: *** [Makefile:1531: drivers] Fehler 2
make: *** [Makefile:485: __build_one_by_one] Fehler 2
Fixes: f2b25c9bf82 ("dm: sound: Complete migration to driver model")
Signed-off-by: Christian Gmeiner
---
arch/sandbox/include/asm/sdl.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Applied to u-boot-dm, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] sandbox: Use correct phys_{addr, size}_t for PHYS_64BIT=y
On Tue, 12 Mar 2019 at 04:38, Thierry Reding wrote: > > From: Thierry Reding > > If 64-bit physical addresses support is enabled, make sure the sandox > defines the correct types for phys_addr_t and phys_size_t. > > Signed-off-by: Thierry Reding > --- > arch/sandbox/include/asm/types.h | 12 ++-- > 1 file changed, 6 insertions(+), 6 deletions(-) > Applied to u-boot-dm, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 02/13] fdtdec: Add cpu_to_fdt_{addr, size}() macros
On Thu, 21 Mar 2019 at 12:10, Thierry Reding wrote: > > From: Thierry Reding > > These macros are useful for converting the endianness of variables of > type fdt_addr_t and fdt_size_t. > > Reviewed-by: Simon Glass > Signed-off-by: Thierry Reding > --- > Changes in v2: > - add Reviewed-by from Simon > > include/fdtdec.h | 4 > 1 file changed, 4 insertions(+) Applied to u-boot-dm, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 03/13] fdtdec: Add fdt_{addr, size}_unpack() helpers
Hi Thierry,
On Fri, 22 Mar 2019 at 02:31, Thierry Reding wrote:
>
> On Fri, Mar 22, 2019 at 03:53:00PM +0800, Simon Glass wrote:
> > Hi Thierry,
> >
> > On Fri, 22 Mar 2019 at 02:10, Thierry Reding
> > wrote:
> > >
> > > From: Thierry Reding
> > >
> > > These helpers can be used to unpack variables of type fdt_addr_t and
> > > fdt_size_t into a pair of 32-bit variables. This is useful in cases
> > > where such variables need to be written to properties (such as "reg")
> > > of a device tree node where they need to be split into cells.
> > >
> > > Signed-off-by: Thierry Reding
> > > ---
> > > Changes in v2:
> > > - new patch
> > >
> > > include/fdtdec.h | 25 +
> > > 1 file changed, 25 insertions(+)
> > >
> > > diff --git a/include/fdtdec.h b/include/fdtdec.h
> > > index a965c33157c9..a0ba57c6318b 100644
> > > --- a/include/fdtdec.h
> > > +++ b/include/fdtdec.h
> > > @@ -23,6 +23,31 @@
> > > */
> > > typedef phys_addr_t fdt_addr_t;
> > > typedef phys_size_t fdt_size_t;
> > > +
> > > +static inline fdt32_t fdt_addr_unpack(fdt_addr_t addr, fdt32_t *upper)
> > > +{
> > > + if (upper)
> > > +#ifdef CONFIG_PHYS_64BIT
> >
> > Could we use 'if IS_ENABLED()' instead?
>
> Are you suggesting to use IS_ENABLED() in a preprocessor #if or a
> compiler if (IS_ENABLED(...)) { ... } construct? For the former, yes we
> could certainly do that.
>
> The latter would probably work as well if we did something like this:
>
> > > + *upper = addr >> 32;
>
> *upper = upper_32_bits(addr);
>
> where upper_32_bits() is a macro such as the one defined in Linux'
> include/linux/kernel.h. That prevents the right-shift of 32 bits for
> 32-bit quantities to not produce a warning.
>
> That said, I see that we already have that macro in U-Boot's kernel.h
> header file, so I could switch to using that. With that I think we could
> even leave out the conditional. The compiler would hopefully optimize it
> (the upper_32_bits() invocation) out by itself.
>
> I'll do some testing and respin if that works out.
Applied to u-boot-dm, thanks!
Please do a fixup patch if this works out. I hope I didn't miss an email/patch.
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] warp7: Fix dfu_alt_info setting after DM conversion
Hi Pierre-Jean, On Fri, Apr 12, 2019 at 5:37 PM Pierre-Jean Texier wrote: > > After DM conversion, U-Boot is larger than 512 KiB, so we need to increase > the "size" of the dfu_alt_info setting. > > Signed-off-by: Pierre-Jean Texier Thanks for the fix. Reviewed-by: Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [linux-sunxi] [PATCH] ARM: HYP/non-sec: Don't enable ARMV7_LPAE for old sunxi kernels
Mark Kettenis wrote on 04/12/2019 03:03 PM: From: Jagan Teki Date: Fri, 12 Apr 2019 12:02:06 +0530 On Fri, Mar 22, 2019 at 2:31 AM Jonathan Liu wrote: Hi Jagan, On Fri., 22 Mar. 2019 at 4:05 am, Jagan Teki wrote: On Tue, Mar 19, 2019 at 11:09 AM Jonathan Liu wrote: Old sunxi kernels fail to boot with ARMV7_LPAE enabled. Any idea why? I don't have relevant stuff with to test this. I don't know why. It failed to boot linux-sunxi 3.4.104 kernel on A20 OLinuXino-MICRO after updating from 2018.07 to 2018.09-rc1 and would hang at "Starting kernel...". I bisected the issue to: https://git.denx.de/?p=u-boot.git;a=commit;h=d32e86bde8a31a49cf4a9b233ad91ecdfc96ba2a No problems booting mainline kernel. Can you update full details of bug on the commit message. Technically I think the right thing to do would be disabling ARMV7_VIRT as my understanding is that booting into HYP mode doesn't work without LPAE support. Some days ago I tried to disable HYP mode for SVC mode. But with SVC the PSCI is not loading (u-boot bug?), and without PSCI only the 1st core of the CPU gets used. I had documented the case here: https://lists.denx.de/pipermail/u-boot/2019-April/364192.html ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-marvell/master (v2)
On Sat, Apr 13, 2019 at 08:37:46AM +1200, Chris Packham wrote: > On Fri, 12 Apr 2019, 11:27 PM Stefan Roese, wrote: > > > Hi Tom, > > > > please pull the following Marvell related patches. I've > > removed the board support, causing the out-of-tree building > > error for now. I'll push this one after its resolved. > > > I'll take a look at the db-88f6281 out of tree build failures. I think I've > got a handle on the issue now. I probably won't have a fix before you go > offline but it should be waiting for you when you get back. Have a good > break. > > "Check for configs without MAINTAINERS entry". I've not seen > > this error before. Frankly, I'm in a bit of a hurry, as I am > > leaving for a 10 days vacation tomorrow and this will be my > > last try to get these Marvell patches upstream before it. > > > If this is due to one of my recent additions I'll send a fix direct to Tom. It was a trivial enough problem on board/Marvell/db-xc3-24g4xg/MAINTAINERS that I fixed it up in the merge. -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] very short list of "badref selects" in u-boot source
rather than go to the trouble of whipping up a wiki page, i can present this in a short post to the list. here's the list of what my script identified as "badref selects" -- those identifiers for which there is a Kconfig line of the form: select X where there is no corresponding: config X the entire list: > BOOTM_LINUX > CONFIG_EHCI_HCD_INIT_AFTER_RESET > CONFIG_MPC8xx_WATCHDOG > CPU_ARM926EJS1 > CRC32 > GPIO > MSCC_BITBANG_SPI_GPIO > SPL_DISABLE_OF_CONTROL > VEXPRESS_CLK first, the two with the "CONFIG_" prefix are obvious typos which should have those prefixes removed. as for the rest, as one example, consider "CRC32": $ git grep "select CRC32" cmd/Kconfig:select CRC32 cmd/Kconfig:select CRC32 drivers/mtd/ubi/Kconfig:select CRC32 fs/btrfs/Kconfig: select CRC32C $ there is no matching "config CRC32" anywhere, although there is: include/image.h:# define CONFIG_CRC32 /* FIT images need CRC32 support */ in any event, others are welcome to decide what to do about that short list of suspicious "select" directives. i am not trying to be annoying, i am merely succeeding. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] warp7: Fix dfu_alt_info setting after DM conversion
Acked-by: Joris Offouga Le 12/04/2019 à 22:36, Pierre-Jean Texier a écrit : After DM conversion, U-Boot is larger than 512 KiB, so we need to increase the "size" of the dfu_alt_info setting. Signed-off-by: Pierre-Jean Texier --- include/configs/warp7.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/configs/warp7.h b/include/configs/warp7.h index 043f286..4947597 100644 --- a/include/configs/warp7.h +++ b/include/configs/warp7.h @@ -39,7 +39,7 @@ #define CONFIG_SERIAL_TAG #define CONFIG_DFU_ENV_SETTINGS \ - "dfu_alt_info=boot raw 0x2 0x400 mmcpart 1\0" \ + "dfu_alt_info=boot raw 0x2 0x1000 mmcpart 1\0" \ #define CONFIG_EXTRA_ENV_SETTINGS \ CONFIG_DFU_ENV_SETTINGS \ ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-marvell/master (v2)
On Fri, 12 Apr 2019, 11:27 PM Stefan Roese, wrote:
> Hi Tom,
>
> please pull the following Marvell related patches. I've
> removed the board support, causing the out-of-tree building
> error for now. I'll push this one after its resolved.
I'll take a look at the db-88f6281 out of tree build failures. I think I've
got a handle on the issue now. I probably won't have a fix before you go
offline but it should be waiting for you when you get back. Have a good
break.
"Check for configs without MAINTAINERS entry". I've not seen
> this error before. Frankly, I'm in a bit of a hurry, as I am
> leaving for a 10 days vacation tomorrow and this will be my
> last try to get these Marvell patches upstream before it.
If this is due to one of my recent additions I'll send a fix direct to Tom.
> [1] https://travis-ci.org/stroese/u-boot/builds/519095642
>
> Thanks,
> Stefan
>
> The following changes since commit
> 02f173ca156cee8526dff87603d5e446b443cde3:
>
>Merge branch 'master' of git://git.denx.de/u-boot-usb (2019-04-11
> 14:29:37 -0400)
>
> are available in the Git repository at:
>
>git://www.denx.de/git/u-boot-marvell.git
>
> for you to fetch changes up to 937cb9d0a671b1df01955edd515ebf4a65e45f85:
>
>ARM: mvebu: sync db-88f6820-amc.dts with Linux v5.0 (2019-04-12
> 07:20:20 +0200)
>
>
> Baruch Siach (6):
>ARM: mvebu: define board_ahci_enable() for A38x
>ata: ahci_mvebu: add support for Armada 38x
>git-mailrc: update the kirkwood entry
>arm: mvebu: clearfog: document eMMC installation
>mvebu: drop dangling SPI flash comments and #ifdefs
>arm: mvebu: turris_omnia: select Kconfig SPI_FLASH_SPANSION
>
> Chris Packham (20):
>arm: sync armada-xp dts files from Linux 5.0
>watchdog: orion_wdt: support SPL usage
>watchdog: orion_wdt: take timeout value in ms
>arm: mvebu: x530: Enable watchdog in SPL and U-Boot
>tools: kwbimage: don't adjust for image_header for Armada MSYS
>ARM: kirkwood: rename KW_CPU_WIN_BASE to MVEBU_CPU_WIN_BASE
>ARM: kirkwood: remove KW_DEFADR_PCI_IO_REMAP
>ARM: kirkwood: switch to using mvebu mbus
>ARM: kirkwood: remove kw_config_adr_windows
>ARM: kirkwood: enable CONFIG_DM_USB for {dream, guru, sheeva}plug
>ARM: kirkwood: enable CONFIG_DM_USB for dns325
>ARM: kirkwood: enable CONFIG_DM_USB for ds109
>ARM: kirkwood: enable CONFIG_DM_USB for goflexhome
>ARM: kirkwood: enable CONFIG_DM_USB for lschlv2 and lsxhl
>ARM: kirkwood: enable CONFIG_DM_USB for nas220
>arm: mvebu: Add Marvell's integrated CPUs
>arm: mvebu: NAND clock support for MSYS devices
>arm: mvebu: Add DB-XC3-24G4XG board
>ARM: mvebu: rename armada-385-amc.dts to
> armada-385-db-88f6820-amc.dts
>ARM: mvebu: sync db-88f6820-amc.dts with Linux v5.0
>
> Leigh Brown (1):
>ARM: kirkwood: remove obsolete call to icache_enable
>
> Michael Walle (5):
>sata: sata_mv: use correct format specifier in debug()
>sata: sata_mv: support kirkwood architecture
>sata: sata_mv: add orion-sata compatible string
>arm: kirkwood: lsxl: enable DM for SATA
>cmd: add wdt command
>
> Stefan Roese (8):
>sata: sata_mv: Add DM support to enable CONFIG_BLK usage
>arm: mvebu: theadorable_debug_defconfig: Enable CONFIG_BLK
>arm: mvebu: db-mv784mp-gp_defconfig: Enable CONFIG_BLK
>arm: mvebu: theadorable: Add test for ctrl-c in PCIe PEX switch test
>Makefile: Correct logic for DM_SCSI + unconverted drivers check
>arm: mvebu: ds412: Enable CONFIG_BLK
>arm: mvebu: AXP: Enhance PCIe port capability configuration
>arm: mvebu: Fix Kconfig dependency warnings
>
> Makefile | 19 +-
> arch/arm/dts/Makefile | 5 +-
> arch/arm/dts/armada-370-xp.dtsi| 133
> arch/arm/dts/armada-385-amc.dts| 166 --
> arch/arm/dts/armada-385-atl-x530-u-boot.dtsi | 4 +
> arch/arm/dts/armada-385-db-88f6820-amc.dts | 146 +
> arch/arm/dts/armada-xp-98dx3236.dtsi | 343
>
> arch/arm/dts/armada-xp-98dx3336.dtsi | 39 +++
> arch/arm/dts/armada-xp-98dx4251.dtsi | 54
> arch/arm/dts/armada-xp-db-xc3-24g4xg-u-boot.dtsi | 24 ++
> arch/arm/dts/armada-xp-db-xc3-24g4xg.dts | 110 +++
> arch/arm/dts/armada-xp-gp.dts | 167 +-
> arch/arm/dts/armada-xp-maxbcm.dts | 24 +-
> arch/arm/dts/armada-xp-mv78230.dtsi| 55 +---
> arch/arm/dts/armada-xp-mv78260.dtsi| 58 +---
> arch/arm/dts/armada-xp-mv78460.dtsi| 58 +---
> arch/arm/dts/armada-xp-synology-ds414.dts | 199
[U-Boot] [PATCH] warp7: Fix dfu_alt_info setting after DM conversion
After DM conversion, U-Boot is larger than 512 KiB, so we need to increase the "size" of the dfu_alt_info setting. Signed-off-by: Pierre-Jean Texier --- include/configs/warp7.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/configs/warp7.h b/include/configs/warp7.h index 043f286..4947597 100644 --- a/include/configs/warp7.h +++ b/include/configs/warp7.h @@ -39,7 +39,7 @@ #define CONFIG_SERIAL_TAG #define CONFIG_DFU_ENV_SETTINGS \ - "dfu_alt_info=boot raw 0x2 0x400 mmcpart 1\0" \ + "dfu_alt_info=boot raw 0x2 0x1000 mmcpart 1\0" \ #define CONFIG_EXTRA_ENV_SETTINGS \ CONFIG_DFU_ENV_SETTINGS \ -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PULL] u-boot-mips
Hi Tom, please pull MIPS updates for 2019.07 https://travis-ci.org/danielschwierzeck/u-boot/builds/519324026 The following changes since commit 02f173ca156cee8526dff87603d5e446b443cde3: Merge branch 'master' of git://git.denx.de/u-boot-usb (2019-04-11 14:29:37 -0400) are available in the Git repository at: git://git.denx.de/u-boot-mips.git tags/mips-pull-2019-04-12 for you to fetch changes up to c3b6c8e2d8fb5b8d0d67858dc4a2133b7065df5b: mips: mt76xx: linkit-smart-7688: Enable USB and FS support (2019-04-12 17:32:53 +0200) - mt76xx: add USB support, small fixes - ath79: small fixes, add support for QCA9563 SoC and AP152 reference board - mscc: small fixes, add network support for JR2 and ServalT SoCs - bmips: small fixes, enable more drivers for ARM specific BCM6858 and BCM63158 SoCs - MIPS: fix redundant relocation of initrd images Horatiu Vultur (10): bootm: mips: Remove boot_reloc_ramdisk net: mscc: ocelot: Fix reset of the phys net: Add MSCC Jaguar2 network driver. board: mscc: jr2: Update MSCC Jaguar2 boards net: mscc: jaguar2: Add ethenet nodes for Jaguar2. configs: mscc_jr2: Add network support configs: vcoreiii: Change CONFIG_ENV_SIZE net: Add MSCC ServalT network driver. net: mscc: servalt: Add ethernet nodes for ServalT configs: mscc_servalt: Add network support Philippe Reynes (14): gpio: bcm6345: switch to raw I/O functions dt: bcm6838: add gpio controller dt: bcm968380gerg: enable gpio controller bcm968380gerg: enable gpio support gpio: bcm6345: allow this driver on ARCH_BCM6858 gpio: do not include on ARCH_BCM6858 dt: bcm6858: add gpio controller dt: bcm968580xref: enable gpio controller bcm968580xref: enable gpio support gpio: bcm6345: allow this driver on ARCH_BCM63158 gpio: do not include on ARCH_BCM63158 dt: bcm63158: add gpio controller dt: bcm963158: enable gpio controller bcm963158: enable gpio support Rosy Song (6): drivers: fix typo for pinctrl qca953x drivers: add ethernet support for qca953x in ag7xxx driver mips: add ethernet support for qca953x referenced boards mips: fix erros on registers macros of pll-ddr-config1-nfrac for QCA956X mips: add initial support for qca956x referenced board ag7xxx: add initial support for s17 Stefan Roese (4): mips: mt76xx: linkit: Add mtd command support mips: mt76xx: gardena-smart-gateway: Correct spelling of GARDENA phy: Add USB PHY driver for the MT76x8 (7628/7688) SoC mips: mt76xx: linkit-smart-7688: Enable USB and FS support Álvaro Fernández Rojas (1): dma: bcm6348: check if driver is enabled before send/recv arch/arm/dts/bcm63158.dtsi | 80 ++ arch/arm/dts/bcm6858.dtsi | 80 ++ arch/arm/dts/bcm963158.dts | 32 + arch/arm/dts/bcm968580xref.dts | 32 + arch/arm/include/asm/gpio.h|3 +- arch/mips/dts/Makefile |1 + arch/mips/dts/ap143.dts|5 + arch/mips/dts/ap152.dts| 48 + arch/mips/dts/brcm,bcm6838.dtsi| 27 + arch/mips/dts/brcm,bcm968380gerg.dts | 12 + arch/mips/dts/gardena-smart-gateway-mt7688.dts |2 +- arch/mips/dts/jr2_pcb110.dts | 76 ++ arch/mips/dts/jr2_pcb111.dts | 400 arch/mips/dts/mscc,jr2.dtsi| 116 +++ arch/mips/dts/mscc,servalt.dtsi| 40 + arch/mips/dts/qca953x.dtsi | 31 + arch/mips/dts/qca956x.dtsi | 87 ++ arch/mips/dts/serval2_pcb112.dts | 44 + arch/mips/dts/servalt_pcb116.dts | 25 + arch/mips/lib/bootm.c | 19 - arch/mips/mach-ath79/Kconfig | 14 + arch/mips/mach-ath79/Makefile |1 + arch/mips/mach-ath79/include/mach/ar71xx_regs.h| 77 +- arch/mips/mach-ath79/include/mach/ath79.h |3 + arch/mips/mach-ath79/qca956x/Makefile |5 + arch/mips/mach-ath79/qca956x/clk.c | 419 arch/mips/mach-ath79/qca956x/cpu.c |9 + arch/mips/mach-ath79/qca956x/ddr.c | 308 ++ arch/mips/mach-ath79/qca956x/qca956x-ddr-tap.S | 193 arch/mips/mach-ath79/reset.c | 271 + .../include/mach/servalt/servalt_devcpu_gcb.h |2 + arch/mips/mach-mt7620/Kconfig |4 +- board/mscc/jr2/jr2.c | 23 + board/qca/ap152/Kconfig| 15 +
[U-Boot] Missing: CONFIG_EXTRA_ENV_SETTINGS
The "make menuconfig" help page for "Environment --> Create default environment from file" mentions CONFIG_EXTRA_ENV_SETTINGS, but searching for this says "No matches found", and also in the saved .config it's missing. Version info (boot msgs): U-Boot SPL 2019.04-00077-g48ff1bc4f0-dirty (Apr 11 2019 - 13:43:54 +0200) DRAM: 1024 MiB CPU: 91200Hz, AXI/AHB/APB: 3/2/2 Trying to boot from MMC1 U-Boot 2019.04-00077-g48ff1bc4f0-dirty (Apr 11 2019 - 13:43:54 +0200) Allwinner Technology CPU: Allwinner A20 (SUN7I) Model: Lamobo R1 I2C: ready DRAM: 1 GiB MMC: mmc@1c0f000: 0 Loading Environment from FAT... *** Warning - bad CRC, using default environment ... ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC v2 08/11] cmd: bootefi: carve out bootmgr code from do_bootefi()
On 4/12/19 4:19 PM, AKASHI Takahiro wrote:
On Fri, Apr 12, 2019 at 10:58:25AM +0200, Heinrich Schuchardt wrote:
On 4/12/19 9:06 AM, AKASHI Takahiro wrote:
On Fri, Apr 12, 2019 at 07:55:16AM +0200, Heinrich Schuchardt wrote:
On 3/27/19 5:40 AM, AKASHI Takahiro wrote:
This is a preparatory patch for reworking do_bootefi() in later patch.
do_bootmgr_exec() is renamed to do_efibootmgr() as we put all the necessary
code into this function.
Signed-off-by: AKASHI Takahiro
---
cmd/bootefi.c | 42 ++
1 file changed, 34 insertions(+), 8 deletions(-)
diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index e9d4881997a1..94b5bdeed3f1 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -309,22 +309,47 @@ err_add_protocol:
return ret;
}
-static int do_bootefi_bootmgr_exec(void)
+/**
+ * do_efibootmgr() - execute EFI Boot Manager
+ *
+ * @fdt_opt: string of fdt start address
+ * Return: status code
+ *
+ * Execute EFI Boot Manager
+ */
+static int do_efibootmgr(const char *fdt_opt)
{
struct efi_device_path *device_path, *file_path;
void *addr;
- efi_status_t r;
+ efi_status_t ret;
+
+ /* Allow unaligned memory access */
+ allow_unaligned();
+
+ switch_to_non_secure_mode();
+
Shouldn't we move these two call to efi_init_obj_list()?
Given the fact that efi_init_obj_list() is called without invoking
any UEFI binary at some places, I'm not sure that it is the right
place where switch_to_non_secure_mode() be called.
If this is UEFI(and arm)-specific, it should be placed just
before setjmp() in efi_start_image().
But I'm not sure whether we should call switch_to_non_secure_mode()
even for a driver, which is logically part of U-Boot UEFI.
switch_to_not_secure_mode() is a weak function which is implemented only
for armv7 and armv8.
efi_init_obj_list() would be a safe place to call it.
Best regards
Heinrich
-Takahiro Akashi
I think this could even be done in initr_reloc_global_data().
@Alex
What are your thoughts.
Best regards
Heinrich
-Takahiro Akashi
Best regards
Heinrich
+ /* Initialize EFI drivers */
+ ret = efi_init_obj_list();
+ if (ret != EFI_SUCCESS) {
+ printf("Error: Cannot initialize UEFI sub-system, r = %lu\n",
+ ret & ~EFI_ERROR_MASK);
+ return CMD_RET_FAILURE;
+ }
+
+ ret = efi_install_fdt(fdt_opt);
+ if (ret != EFI_SUCCESS)
+ return CMD_RET_FAILURE;
addr = efi_bootmgr_load(_path, _path);
if (!addr)
return 1;
printf("## Starting EFI application at %p ...\n", addr);
- r = do_bootefi_exec(addr, device_path, file_path);
+ ret = do_bootefi_exec(addr, device_path, file_path);
printf("## Application terminated, r = %lu\n",
- r & ~EFI_ERROR_MASK);
+ ret & ~EFI_ERROR_MASK);
- if (r != EFI_SUCCESS)
+ if (ret != EFI_SUCCESS)
return 1;
return 0;
@@ -463,6 +488,9 @@ static int do_bootefi(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
if (argc < 2)
return CMD_RET_USAGE;
+
+ if (!strcmp(argv[1], "bootmgr"))
+ return do_efibootmgr(argc > 2 ? argv[2] : NULL);
#ifdef CONFIG_CMD_BOOTEFI_SELFTEST
else if (!strcmp(argv[1], "selftest"))
return do_efi_selftest(argc > 2 ? argv[2] : NULL);
@@ -497,9 +525,7 @@ static int do_bootefi(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
memcpy(map_sysmem(addr, size), __efi_helloworld_begin, size);
} else
#endif
- if (!strcmp(argv[1], "bootmgr")) {
- return do_bootefi_bootmgr_exec();
- } else {
+ {
saddr = argv[1];
addr = simple_strtoul(saddr, NULL, 16);
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] efi_selftest: expect boot services data for fdt
Hi Heinrich,
> In a previous patch the memory type used for the FDT has been changed to
> boot services data. We have to adjust the test.
>
> Correct an incorrect comment. The tested services are boot services.
>
> Signed-off-by: Heinrich Schuchardt
> ---
> lib/efi_selftest/efi_selftest_memory.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/lib/efi_selftest/efi_selftest_memory.c
> b/lib/efi_selftest/efi_selftest_memory.c
> index d41227b605..5eeb42a9be 100644
> --- a/lib/efi_selftest/efi_selftest_memory.c
> +++ b/lib/efi_selftest/efi_selftest_memory.c
> @@ -4,7 +4,7 @@
> *
> * Copyright (c) 2018 Heinrich Schuchardt
> *
> - * This unit test checks the following runtime services:
> + * This unit test checks the following boottime services:
> * AllocatePages, FreePages, GetMemoryMap
> *
> * The memory type used for the device tree is checked.
> @@ -176,9 +176,9 @@ static int execute(void)
> /* Check memory reservation for the device tree */
> if (fdt_addr &&
> find_in_memory_map(map_size, memory_map, desc_size, fdt_addr,
> -EFI_RUNTIME_SERVICES_DATA) != EFI_ST_SUCCESS) {
> +EFI_BOOT_SERVICES_DATA) != EFI_ST_SUCCESS) {
> efi_st_error
> - ("Device tree not marked as runtime services data\n");
> + ("Device tree not marked as boot services data\n");
> return EFI_ST_FAILURE;
> }
> return EFI_ST_SUCCESS;
> --
> 2.20.1
>
I probably should have updated that myself. Thanks for catching this
Reviewed-by: Ilias Apalodimas
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/1] efi_selftest: expect boot services data for fdt
In a previous patch the memory type used for the FDT has been changed to
boot services data. We have to adjust the test.
Correct an incorrect comment. The tested services are boot services.
Signed-off-by: Heinrich Schuchardt
---
lib/efi_selftest/efi_selftest_memory.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/lib/efi_selftest/efi_selftest_memory.c
b/lib/efi_selftest/efi_selftest_memory.c
index d41227b605..5eeb42a9be 100644
--- a/lib/efi_selftest/efi_selftest_memory.c
+++ b/lib/efi_selftest/efi_selftest_memory.c
@@ -4,7 +4,7 @@
*
* Copyright (c) 2018 Heinrich Schuchardt
*
- * This unit test checks the following runtime services:
+ * This unit test checks the following boottime services:
* AllocatePages, FreePages, GetMemoryMap
*
* The memory type used for the device tree is checked.
@@ -176,9 +176,9 @@ static int execute(void)
/* Check memory reservation for the device tree */
if (fdt_addr &&
find_in_memory_map(map_size, memory_map, desc_size, fdt_addr,
- EFI_RUNTIME_SERVICES_DATA) != EFI_ST_SUCCESS) {
+ EFI_BOOT_SERVICES_DATA) != EFI_ST_SUCCESS) {
efi_st_error
- ("Device tree not marked as runtime services data\n");
+ ("Device tree not marked as boot services data\n");
return EFI_ST_FAILURE;
}
return EFI_ST_SUCCESS;
--
2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] doing anything about "bad" Kbuild configuration options?
On Sat, 13 Apr 2019, Chris Packham wrote:
>
> On Sat, 13 Apr 2019, 4:56 AM Robert P. J. Day, wrote:
> one of the worst culprits appears to be CONFIG_SPL_BUILD, which
> appears all over the tree, but one can see a recent commit that takes
> that into account:
>
>
> That's not quite right. CONFIG_SPL_BUILD is defined for the Makefile
> just not in Kconfig (I'm on a tablet right now so I can't point you
> to the source).
>
> commit 0ef692084363f2de8547db93397c6a69123d26ca
> Author: Baruch Siach
> Date: Thu Feb 7 13:21:16 2019 +0200
>
> Kconfig: fix BUILD_TARGET for ARCH_MVEBU
>
> Commit dc146ca11187 ("Kconfig: Migrate CONFIG_BUILD_TARGET") made
> the
> mvebu default build target depend on CONFIG_SPL_BUILD.
> Unfortunately,
> there is no such Kconfig symbol. Use the CONFIG_SPL symbol instead
> to
> fix that.
>
> Cc: Jagan Teki
> Signed-off-by: Baruch Siach
> Reviewed-by: Stefan Roese
> Reviewed-by: Jagan Teki
> Signed-off-by: Stefan Roese
>
>
> This commit addresses the fact that CONFIG_SPL_BUILD is not
> available to use in Kconfig. It is available to Makefiles, I can't
> remember if it gets defined for source files.
i realize there are such things; however, the standard is that any
options/variables prefixed with "CONFIG_" are typically defined as
part of the Kbuild infrastructure (with the exception of prefixes of
"CONFIG_SYS_").
i think what you're referring to is in scripts/Makefile.spl:
scripts/Makefile.spl:KBUILD_CPPFLAGS += -DCONFIG_SPL_BUILD
i'm not going to make recommendations one way or the other; merely
pointing out that i have scripts that display such things, and people
are free to do what they wish with the results.
rday
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] [U-boot]: Change FDT memory type from runtime data to boot services data
On Fri, 12 Apr 2019 at 12:55, Heinrich Schuchardt wrote: > > On 4/12/19 9:30 PM, Heinrich Schuchardt wrote: > > On 4/12/19 8:26 PM, Ilias Apalodimas wrote: > >> Following Ard's suggestion: > >> Runtime data sections are intended for data that is used by the runtime > >> services implementation. > >> Let's change the type to EFI_BOOT_SERVICES_DATA > >> > >> This also fixes booting of armv7 using efi and fdtcontroladdr > >> > >> Suggested-by: Ard Biesheuvel > >> Signed-off-by: Ilias Apalodimas > >> Acked-by: Ard Biesheuvel > > > > EfiBootServicesData is used by EDK II for installing the FDT. > > GRUB uses EfiLoaderCode when installing its modified version of the FDT. > > > > Reviewed-by: Heinrich Schuchardt > > Applied u-bootefi branch efi-2019-07 Thanks Heinrich. I still have a question, though. The following code new_fdt_addr = (ulong)memalign(EFI_PAGE_SIZE, fdt_size); ret = efi_allocate_pages(EFI_ALLOCATE_MAX_ADDRESS, EFI_BOOT_SERVICES_DATA, fdt_pages, _fdt_addr); looks (from the patch context) like it sets new_fdt_addr to the FDT size rounded up to 4 KB, and then uses that *size* as the max address in the allocation. That seems a bit strange. But the important point is that the EFI stub does not care at all where the FDT is. The stub allocates a new fdt based on the firmware provided one, and copies in all the data, and adds some data of its own. This means that the EFI code in u-boot really doesn't have to abide by the same rules as the other code allocating FDTs. (It also means there is no point in using ACPI reclaim memory for the FDT, as I suggested earlier, so BS data is definitely the best choice here) -- Ard. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] [U-boot]: Change FDT memory type from runtime data to boot services data
On 4/12/19 9:30 PM, Heinrich Schuchardt wrote: On 4/12/19 8:26 PM, Ilias Apalodimas wrote: Following Ard's suggestion: Runtime data sections are intended for data that is used by the runtime services implementation. Let's change the type to EFI_BOOT_SERVICES_DATA This also fixes booting of armv7 using efi and fdtcontroladdr Suggested-by: Ard Biesheuvel Signed-off-by: Ilias Apalodimas Acked-by: Ard Biesheuvel EfiBootServicesData is used by EDK II for installing the FDT. GRUB uses EfiLoaderCode when installing its modified version of the FDT. Reviewed-by: Heinrich Schuchardt Applied u-bootefi branch efi-2019-07 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] doing anything about "bad" Kbuild configuration options?
On Sat, 13 Apr 2019, 4:56 AM Robert P. J. Day,
wrote:
> one of the worst culprits appears to be CONFIG_SPL_BUILD, which
> appears all over the tree, but one can see a recent commit that takes
> that into account:
>
That's not quite right. CONFIG_SPL_BUILD is defined for the Makefile just
not in Kconfig (I'm on a tablet right now so I can't point you to the
source).
commit 0ef692084363f2de8547db93397c6a69123d26ca
> Author: Baruch Siach
> Date: Thu Feb 7 13:21:16 2019 +0200
>
> Kconfig: fix BUILD_TARGET for ARCH_MVEBU
>
> Commit dc146ca11187 ("Kconfig: Migrate CONFIG_BUILD_TARGET") made the
> mvebu default build target depend on CONFIG_SPL_BUILD. Unfortunately,
> there is no such Kconfig symbol. Use the CONFIG_SPL symbol instead to
> fix that.
>
> Cc: Jagan Teki
> Signed-off-by: Baruch Siach
> Reviewed-by: Stefan Roese
> Reviewed-by: Jagan Teki
> Signed-off-by: Stefan Roese
>
This commit addresses the fact that CONFIG_SPL_BUILD is not available to
use in Kconfig. It is available to Makefiles, I can't remember if it gets
defined for source files.
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] watchdog: fix typo "CONFIG_MPC8XX_WATCHDOG" -> "MPC8XX_WATCHDOG"
Kbuild "select" directive should not use "CONFIG_" prefix. Signed-off-by: Robert P. J. Day --- diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig index 34e78beb2a..a89cc6edec 100644 --- a/drivers/watchdog/Kconfig +++ b/drivers/watchdog/Kconfig @@ -149,7 +149,7 @@ config WDT_MT7621 config WDT_MPC8xx bool "MPC8xx watchdog timer support" depends on WDT && MPC8xx - select CONFIG_MPC8xx_WATCHDOG + select MPC8xx_WATCHDOG help Select this to enable mpc8xx watchdog timer -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] [U-boot]: Change FDT memory type from runtime data to boot services data
On 4/12/19 8:26 PM, Ilias Apalodimas wrote:
Following Ard's suggestion:
Runtime data sections are intended for data that is used by the runtime
services implementation.
Let's change the type to EFI_BOOT_SERVICES_DATA
This also fixes booting of armv7 using efi and fdtcontroladdr
Suggested-by: Ard Biesheuvel
Signed-off-by: Ilias Apalodimas
Acked-by: Ard Biesheuvel
EfiBootServicesData is used by EDK II for installing the FDT.
GRUB uses EfiLoaderCode when installing its modified version of the FDT.
Reviewed-by: Heinrich Schuchardt
---
cmd/bootefi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index 3619a20e6433..15ee4af45667 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -111,13 +111,13 @@ static efi_status_t copy_fdt(void **fdtp)
new_fdt_addr = (uintptr_t)map_sysmem(fdt_ram_start + 0x7f0 +
fdt_size, 0);
ret = efi_allocate_pages(EFI_ALLOCATE_MAX_ADDRESS,
-EFI_RUNTIME_SERVICES_DATA, fdt_pages,
+EFI_BOOT_SERVICES_DATA, fdt_pages,
_fdt_addr);
if (ret != EFI_SUCCESS) {
/* If we can't put it there, put it somewhere */
new_fdt_addr = (ulong)memalign(EFI_PAGE_SIZE, fdt_size);
ret = efi_allocate_pages(EFI_ALLOCATE_MAX_ADDRESS,
-EFI_RUNTIME_SERVICES_DATA, fdt_pages,
+EFI_BOOT_SERVICES_DATA, fdt_pages,
_fdt_addr);
if (ret != EFI_SUCCESS) {
printf("ERROR: Failed to reserve space for FDT\n");
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] [U-boot]: Change FDT memory typpe from runtime data to acpi reclaim
On Thu, Apr 11, 2019 at 10:08:10PM +0200, Heinrich Schuchardt wrote: > > > How about systab.tables assigned in efi_initialize_system_table()? Which > > > of the addresses in systab.tables should be updated upon relocation. > > > > > > The EFI Spec is really hazy: "A pointer to the table associated with > > > VendorGuid. Whether this pointer is a physical address or a > > > virtual address during runtime is determined by the VendorGuid." > > > > > > > Indeed. So it is up to the publisher to update the reference, but I am > > not aware of any firmware implementations that do this in practice. It > > is typically assumed that a firmware component that is still active at > > runtime holds its own reference to data exposed via a configuration > > table, and updates the reference during SetVirtualAddressMap. > > > > There is also a known bug in EDK2 where the ESRT table is passed in > > boot services memory, but the capsule update code actually tries to > > access it at runtime, so this isn't as clean as we'd like it to be. > > > > > The FDT_TABLE_GUID or DEVICE_TREE_GUID as Linux calls it is not defined > > > in the UEFI spec. So we can marvel about expected behavior. Is there any > > > other document specifying it? > > > > > > > No, its de facto specification is in the EDK2 source tree. Well, in reality, it appeared simultanously-ish in Linux and GRUB, and I think is entry into the EDK2 codebase came later :) > As all ARM systems use it I guess this GUID should move into the UEFI > spec. Maybe Linaro could raise this issue. While the UEFI specification does list the ACPI, ACPI_20, SMBIOS, and some other common GUIDs, this is not where they are defined. If it needs to go into some specification, that would probably be the devicetree.org one. / Leif ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] i2c: mxc: Hide kconfig based control in DM_I2C mode
These options only apply when not using DM_I2C. When using device trees, the dt will enable and control the speeds of the I2C controller(s) and these configuration options have no effect. So disable them in DM_I2C mode. Otherwise they show up as decoys, and make it look like one is enabling I2C controllers and setting the speed when really it's doing nothing. Cc: Sriram Dash Cc: Priyanka Jain Cc: Heiko Schocher Signed-off-by: Trent Piepho --- drivers/i2c/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/i2c/Kconfig b/drivers/i2c/Kconfig index 1ef22e6bcd..df7fc7db0a 100644 --- a/drivers/i2c/Kconfig +++ b/drivers/i2c/Kconfig @@ -161,7 +161,7 @@ config SYS_I2C_MXC channels and operating on standard mode upto 100 kbits/s and fast mode upto 400 kbits/s. -if SYS_I2C_MXC +if SYS_I2C_MXC && !DM_I2C config SYS_I2C_MXC_I2C1 bool "NXP MXC I2C1" help -- 2.14.5 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] include: compiler: fix tools-only compiles on Cygwin and with the Android NDK on Linux
Hi again, I am submitting this patch with some easy fixes for the ongoing broken compiling U-Boot tools-only on Cygwin and cross-compiling with the Android NDK on Linux. The added __kernel_* definitions in posix_types.h come from mainline so should be safe for inclusion: https://github.com/torvalds/linux/blob/master/include/uapi/asm-generic/posix_types.h I also feel it worth mentioning that my previous bug report for dumpimage failing on untrimmed dumps has not received any response yet, so I'll link it again for your attention as the issue remains in 2019.04: https://lists.denx.de/pipermail/u-boot/2019-January/355670.html Errors on Cygwin resolved by this patch: HOSTCC tools/aisimage.o In file included from tools/aisimage.c:9:0: include/image.h:321:2: error: unknown type name ‘__be32’ __be32 ih_magic; /* Image Header Magic Number */ ^~ (and 6 similar __be32 errors) make[1]: *** [scripts/Makefile.host:114: tools/aisimage.o] Error 1 make: *** [Makefile:1722: tools-only] Error 2 HOSTCC tools/imx8image.o In file included from include/linux/kernel.h:5:0, from include/imx8image.h:14, from tools/imx8image.c:8: include/linux/types.h:155:2: error: unknown type name ‘__kernel_daddr_t’ __kernel_daddr_t f_tfree; ^~~~ include/linux/types.h:156:2: error: unknown type name ‘__kernel_ino_t’ __kernel_ino_t f_tinode; ^~ make[1]: *** [scripts/Makefile.host:114: tools/imx8image.o] Error 1 make: *** [Makefile:1722: tools-only] Error 2 HOSTCC tools/mtk_image.o In file included from tools/mtk_image.c:12:0: tools/mtk_image.h:18:3: error: unknown type name ‘__le32’ __le32 version; ^~ (and 30 similar __le32 errors) tools/mtk_image.h:35:3: error: unknown type name ‘__le16’ __le16 ioif; ^~ (and 10 similar __le16 errors) make[1]: *** [scripts/Makefile.host:114: tools/mtk_image.o] Error 1 make: *** [Makefile:1722: tools-only] Error 2 HOSTCC tools/zynqmpbif.o tools/zynqmpbif.c: In function ‘bif_add_bit’: tools/zynqmpbif.c:520:15: warning: implicit declaration of function ‘__swab32’; did you mean ‘__bswap32’? [-Wimplicit-function-declaration] *bitbin32 = __swab32(*bitbin32); ^~~~ __bswap32 tools/zynqmpbif.o:zynqmpbif.c:(.text+0xdb7): undefined reference to `__swab32' collect2: error: ld returned 1 exit status make[1]: *** [scripts/Makefile.host:106: tools/dumpimage] Error 1 make: *** [Makefile:1722: tools-only] Error 2 Errors with the Android NDK on Linux resolved by this patch: HOSTCC tools/aisimage.o In file included from tools/aisimage.c:7:0: tools/imagetool.h:215:2: error: unknown type name 'ulong' ulong file_data, ^ In file included from tools/aisimage.c:9:0: include/image.h:335:2: error: unknown type name 'ulong' ulong start, end; /* start/end of blob */ ^ (and 42 similar ulong errors) make[1]: *** [tools/aisimage.o] Error 1 make: *** [tools-only] Error 2 HOSTCC tools/zynqmpbif.o tools/zynqmpbif.c: In function 'bif_add_bit': tools/zynqmpbif.c:520:3: warning: implicit declaration of function '__fswab32' [-Wimplicit-function-declaration] *bitbin32 = __swab32(*bitbin32); ^ tools/zynqmpbif.o:zynqmpbif.c:function bif_add_bit: error: undefined reference to '__fswab32' collect2: error: ld returned 1 exit status make[1]: *** [tools/mkimage] Error 1 make: *** [tools-only] Error 2 Thanks for your time and consideration! Chris 0001-include-compiler-fix-tools-only-compiles-on-Cygwin-a.patch Description: 0001-include-compiler-fix-tools-only-compiles-on-Cygwin-a.patch ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] ARM tools-only CROSS_COMPILE issues within Cygwin
Just posting an update on the current Cygwin issues with U-Boot and the Android NDK. I do have NDK cross-compiles of tools-only working well from a Linux environment now but on Cygwin there continues to be some major compatibility issue with U-Boot's KBuild system and the Android NDK. Using the same command-line as my Linux NDK cross-compile on Cygwin results in the following odd build error: HOSTCC scripts/basic/fixdep CHK include/config/uboot.release CHK include/generated/version_autogenerated.h CHK include/generated/timestamp_autogenerated.h UPD include/generated/timestamp_autogenerated.h HOSTCC tools/gen_eth_addr : No such file or directoryg file: make[1]: *** [scripts/Makefile.host:97: tools/gen_eth_addr] Error 2 make[1]: *** Deleting file 'tools/gen_eth_addr' make: *** [Makefile:1722: tools-only] Error 2 Then seeing if adding --sysroot helps gives the following also-bizarre error: HOSTCC scripts/basic/fixdep CHK include/config/uboot.release CHK include/generated/version_autogenerated.h CHK include/generated/timestamp_autogenerated.h UPD include/generated/timestamp_autogenerated.h HOSTCC tools/gen_eth_addr In file included from ././include/compiler.h:19:0, from :0: g:\cygwin\home\chris\x-tools\arm-linux-androideabi-r15c-api21-unified\lib\gcc\arm-linux-androideabi\4.9.x\include\stdint.h:9:26: fatal error: stdint.h: No such file or directory # include_next ^ compilation terminated. make[1]: *** [scripts/Makefile.host:97: tools/gen_eth_addr] Error 1 make: *** [Makefile:1722: tools-only] Error 2 I'll be uploading a patch to fix issues with tools-only native Cygwin compiles and Android NDK cross-compiles on Linux shortly, but Android NDK cross-compiles on Cygwin could definitely still use some attention beyond my ability. Thanks for you for your time! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] [U-boot]: Change FDT memory type from runtime data to boot services data
Following Ard's suggestion:
Runtime data sections are intended for data that is used by the runtime
services implementation.
Let's change the type to EFI_BOOT_SERVICES_DATA
This also fixes booting of armv7 using efi and fdtcontroladdr
Suggested-by: Ard Biesheuvel
Signed-off-by: Ilias Apalodimas
Acked-by: Ard Biesheuvel
---
cmd/bootefi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index 3619a20e6433..15ee4af45667 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -111,13 +111,13 @@ static efi_status_t copy_fdt(void **fdtp)
new_fdt_addr = (uintptr_t)map_sysmem(fdt_ram_start + 0x7f0 +
fdt_size, 0);
ret = efi_allocate_pages(EFI_ALLOCATE_MAX_ADDRESS,
-EFI_RUNTIME_SERVICES_DATA, fdt_pages,
+EFI_BOOT_SERVICES_DATA, fdt_pages,
_fdt_addr);
if (ret != EFI_SUCCESS) {
/* If we can't put it there, put it somewhere */
new_fdt_addr = (ulong)memalign(EFI_PAGE_SIZE, fdt_size);
ret = efi_allocate_pages(EFI_ALLOCATE_MAX_ADDRESS,
-EFI_RUNTIME_SERVICES_DATA, fdt_pages,
+EFI_BOOT_SERVICES_DATA, fdt_pages,
_fdt_addr);
if (ret != EFI_SUCCESS) {
printf("ERROR: Failed to reserve space for FDT\n");
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] [U-boot]: Change FDT memory typpe from runtime data to acpi reclaim
On 4/12/19 7:36 PM, Ilias Apalodimas wrote: Hi Heinrich, Hello Ilias, hello Ard, please, have a look at this patch: efi_loader: update virtual address in efi_mem_carve_out https://lists.denx.de/pipermail/u-boot/2019-April/364937.html Possibly the bug reported here could have contributed the Linux crash you experienced. Thanks for the heads up. Unfortunately i've already tried that. I was talking to Patrick before he posted the patch upstream. This seems unrelated anyway (all my tests were with the patch applied regardless) https://lore.kernel.org/linux-arm-kernel/20190411151320.GA23031@apalos/ This has an explanation on the problem. The tl;dr version (quoting Russell) "It is also designed to allow hardware-section sized mappings (making it possible to map sections on 1MB granularity) but as a single Linux page table always occupies 2MB, it is not permitted for the unused half of an aligned 2MB slot to be used for a page table mapping - hence this BUG_ON(). The ARM early mapping routines are intentionally designed such that areas of memory that they are asked to map are non-overlapping - it is the caller's responsibility to ensure this." In order to make sure this won't trigger we got to make sure that the fdt is placed on the first 1mb boundary of the memory (of any 2mb aligned area) thus forcing the kernel to init the pte's correctly, instead of trying to do section mappings for the memory in that area. The problem happens when you have a small no-map section within a 2MB region, and it does cross the even-odd 1MB boundary. So fdt at 0x7f0 (or any other are after that like 0xc7f01000) will crash the kernel with a BUG_ON(). Placing it in 0x7e01000-7eFF000 would be fine (on armv7's with LPAE off in the kernel) I think Linux cannot make any assumptions about UEFI memory layout if it is not explicitly specified in the UEFI spec. Everything is simply a Linux bug. Concerning FDT I suggest to stick to what EDK II does: use EfiBootServicesData. Best regards Heinrich Thanks /Ilias ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] [U-boot]: Change FDT memory typpe from runtime data to acpi reclaim
On Fri, 12 Apr 2019 at 10:44, Heinrich Schuchardt wrote: > > On 4/12/19 7:24 PM, Ard Biesheuvel wrote: > > On Fri, 12 Apr 2019 at 10:16, Heinrich Schuchardt > > wrote: > >> > >> On 4/11/19 10:50 PM, Ard Biesheuvel wrote: > >>> On Thu, 11 Apr 2019 at 12:59, Heinrich Schuchardt > >>> wrote: > > On 4/11/19 9:41 PM, Ilias Apalodimas wrote: > > Hi Heinrich, > >> On 4/11/19 8:39 PM, Ilias Apalodimas wrote: > >>> Following Ard's suggestion: > >>> Runtime data sections are intended for data that is used by the > >>> runtime > >>> services implementations. > >>> Let's change they type to EFI_ACPI_RECLAIM_MEMORY > >>> > >>> Suggested-by: Ard Biesheuvel > >>> Signed-off-by: Ilias Apalodimas > >>> --- > >>> cmd/bootefi.c | 4 ++-- > >>> 1 file changed, 2 insertions(+), 2 deletions(-) > >>> > >>> diff --git a/cmd/bootefi.c b/cmd/bootefi.c > >>> index 3619a20e6433..b54181909aff 100644 > >>> --- a/cmd/bootefi.c > >>> +++ b/cmd/bootefi.c > >>> @@ -111,13 +111,13 @@ static efi_status_t copy_fdt(void **fdtp) > >>> new_fdt_addr = (uintptr_t)map_sysmem(fdt_ram_start + 0x7f0 + > >>>fdt_size, 0); > >>> ret = efi_allocate_pages(EFI_ALLOCATE_MAX_ADDRESS, > >>> -EFI_RUNTIME_SERVICES_DATA, fdt_pages, > >>> +EFI_ACPI_RECLAIM_MEMORY, fdt_pages, > >> > >> GRUB uses EfiLoaderCode when installing its modified version of the > >> FDT. > >> > >> The "Embedded Base Boot Requirements (EBBR) Specification, Release > >> v1.0" > >> does not require ACPI support. Can we expect EfiACPIReclaimMemory to be > >> supported if we do not have any ACPI table? > >> > >> How about functions efi_smbios_register() and efi_acpi_register()? > >> > >> How about systab.tables assigned in efi_initialize_system_table()? > >> Which > >> of the addresses in systab.tables should be updated upon relocation. > >> > >> The EFI Spec is really hazy: "A pointer to the table associated with > >> VendorGuid. Whether this pointer is a physical address or a > >> virtual address during runtime is determined by the VendorGuid." > >> > >> The FDT_TABLE_GUID or DEVICE_TREE_GUID as Linux calls it is not defined > >> in the UEFI spec. So we can marvel about expected behavior. Is there > >> any > >> other document specifying it? > > > > What about using EFI_BOOT_SERVICES_DATA instead of > > EFI_ACPI_RECLAIM_MEMORY? > > This still fixes the issue and doesn't cause any of the potential > > problems you > > mentioned > > Why services data and not loader data? > > >>> > >>> Services data is used by the boot services and loader data by the > >>> loader. GRUB is a loader so it uses loader data, u-boot is both boot > >>> services and a loader so it could arguably use both, but boot services > >>> data is more idiomatic. > >>> > >>> >From the pov of the OS, it makes no difference at all. > >>> > As said above we should consider all three supported tables ACPI, > SMBIOS, and FDT when thinking about a fix. The UEFI spec describes that > the addresses inside ACPI and SMBIOS tables are not fixed up when > entering runtime. > > This indicates that at least these tables have to be accessible at > runtime. > >>> > >>> Accessible at runtime but *not* by the runtime services themselves. > >>> > Why do you think that the FDT table should be treated> differently to > the ACPI table? > > >>> > >>> Same thing. Accessible at runtime but not by the firmware services > >>> themselves. > >>> > >>> Only data structures that the runtime services need to access in order > >>> to implement the functionality they expose to the OS should be in > >>> runtime services data memory. This applies to DT, ACPI and SMBIOS > >>> tables alike, but as I mentioned, for historical reasons, SMBIOS > >>> tables are usually exposed via runtime services data. Interestingly, > >>> the UEFI spec mentions that smbios tables should be located in runtime > >>> services data but no virtual mapping should be requested for them, and > >>> this is actually impossible in EDK2, so the current practice of using > >>> rtservicesdata for SMBIOS with the EFI_MEMORY_RUNTIME attribute set > >>> also violates the UEFI spec. > >>> > >> > >> Hello Ilias, hello Ard, > >> > >> please, have a look at this patch: > >> > >> efi_loader: update virtual address in efi_mem_carve_out > >> https://lists.denx.de/pipermail/u-boot/2019-April/364937.html > >> > >> Possibly the bug reported here could have contributed the Linux crash > >> you experienced. > >> > > > > Hello Heinrich, > > > > That patch looks completely unrelated, to be honest. > > > > I wondered if virtual address != physical address could be the cause why > the Linux memory
Re: [U-Boot] [PATCH] [U-boot]: Change FDT memory typpe from runtime data to acpi reclaim
Hi Heinrich, > > Hello Ilias, hello Ard, > > please, have a look at this patch: > > efi_loader: update virtual address in efi_mem_carve_out > https://lists.denx.de/pipermail/u-boot/2019-April/364937.html > > Possibly the bug reported here could have contributed the Linux crash > you experienced. > Thanks for the heads up. Unfortunately i've already tried that. I was talking to Patrick before he posted the patch upstream. This seems unrelated anyway (all my tests were with the patch applied regardless) https://lore.kernel.org/linux-arm-kernel/20190411151320.GA23031@apalos/ This has an explanation on the problem. The tl;dr version (quoting Russell) "It is also designed to allow hardware-section sized mappings (making it possible to map sections on 1MB granularity) but as a single Linux page table always occupies 2MB, it is not permitted for the unused half of an aligned 2MB slot to be used for a page table mapping - hence this BUG_ON(). The ARM early mapping routines are intentionally designed such that areas of memory that they are asked to map are non-overlapping - it is the caller's responsibility to ensure this." In order to make sure this won't trigger we got to make sure that the fdt is placed on the first 1mb boundary of the memory (of any 2mb aligned area) thus forcing the kernel to init the pte's correctly, instead of trying to do section mappings for the memory in that area. The problem happens when you have a small no-map section within a 2MB region, and it does cross the even-odd 1MB boundary. So fdt at 0x7f0 (or any other are after that like 0xc7f01000) will crash the kernel with a BUG_ON(). Placing it in 0x7e01000-7eFF000 would be fine (on armv7's with LPAE off in the kernel) Thanks /Ilias ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] [U-boot]: Change FDT memory typpe from runtime data to acpi reclaim
On 4/12/19 7:24 PM, Ard Biesheuvel wrote: On Fri, 12 Apr 2019 at 10:16, Heinrich Schuchardt wrote: On 4/11/19 10:50 PM, Ard Biesheuvel wrote: On Thu, 11 Apr 2019 at 12:59, Heinrich Schuchardt wrote: On 4/11/19 9:41 PM, Ilias Apalodimas wrote: Hi Heinrich, On 4/11/19 8:39 PM, Ilias Apalodimas wrote: Following Ard's suggestion: Runtime data sections are intended for data that is used by the runtime services implementations. Let's change they type to EFI_ACPI_RECLAIM_MEMORY Suggested-by: Ard Biesheuvel Signed-off-by: Ilias Apalodimas --- cmd/bootefi.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/cmd/bootefi.c b/cmd/bootefi.c index 3619a20e6433..b54181909aff 100644 --- a/cmd/bootefi.c +++ b/cmd/bootefi.c @@ -111,13 +111,13 @@ static efi_status_t copy_fdt(void **fdtp) new_fdt_addr = (uintptr_t)map_sysmem(fdt_ram_start + 0x7f0 + fdt_size, 0); ret = efi_allocate_pages(EFI_ALLOCATE_MAX_ADDRESS, -EFI_RUNTIME_SERVICES_DATA, fdt_pages, +EFI_ACPI_RECLAIM_MEMORY, fdt_pages, GRUB uses EfiLoaderCode when installing its modified version of the FDT. The "Embedded Base Boot Requirements (EBBR) Specification, Release v1.0" does not require ACPI support. Can we expect EfiACPIReclaimMemory to be supported if we do not have any ACPI table? How about functions efi_smbios_register() and efi_acpi_register()? How about systab.tables assigned in efi_initialize_system_table()? Which of the addresses in systab.tables should be updated upon relocation. The EFI Spec is really hazy: "A pointer to the table associated with VendorGuid. Whether this pointer is a physical address or a virtual address during runtime is determined by the VendorGuid." The FDT_TABLE_GUID or DEVICE_TREE_GUID as Linux calls it is not defined in the UEFI spec. So we can marvel about expected behavior. Is there any other document specifying it? What about using EFI_BOOT_SERVICES_DATA instead of EFI_ACPI_RECLAIM_MEMORY? This still fixes the issue and doesn't cause any of the potential problems you mentioned Why services data and not loader data? Services data is used by the boot services and loader data by the loader. GRUB is a loader so it uses loader data, u-boot is both boot services and a loader so it could arguably use both, but boot services data is more idiomatic. >From the pov of the OS, it makes no difference at all. As said above we should consider all three supported tables ACPI, SMBIOS, and FDT when thinking about a fix. The UEFI spec describes that the addresses inside ACPI and SMBIOS tables are not fixed up when entering runtime. This indicates that at least these tables have to be accessible at runtime. Accessible at runtime but *not* by the runtime services themselves. Why do you think that the FDT table should be treated> differently to the ACPI table? Same thing. Accessible at runtime but not by the firmware services themselves. Only data structures that the runtime services need to access in order to implement the functionality they expose to the OS should be in runtime services data memory. This applies to DT, ACPI and SMBIOS tables alike, but as I mentioned, for historical reasons, SMBIOS tables are usually exposed via runtime services data. Interestingly, the UEFI spec mentions that smbios tables should be located in runtime services data but no virtual mapping should be requested for them, and this is actually impossible in EDK2, so the current practice of using rtservicesdata for SMBIOS with the EFI_MEMORY_RUNTIME attribute set also violates the UEFI spec. Hello Ilias, hello Ard, please, have a look at this patch: efi_loader: update virtual address in efi_mem_carve_out https://lists.denx.de/pipermail/u-boot/2019-April/364937.html Possibly the bug reported here could have contributed the Linux crash you experienced. Hello Heinrich, That patch looks completely unrelated, to be honest. I wondered if virtual address != physical address could be the cause why the Linux memory management is incorrectly initialized. --- GRUB uses EfiLoaderCode when installing its modified version of the FDT. In EDK II EmbeddedPkg/Library/DxeDtPlatformDtbLoaderLibDefault/DxeDtPlatformDtbLoaderLibDefault.c function DtPlatformLoadDtb() calls function AllocateCopyPool(). In MdePkg/Library/UefiMemoryAllocationLib/MemoryAllocationLib.c function AllocateCopyPool() uses EfiBootServicesData for the device tree So I think using EfiBootServicesData in U-Boot should be safe. Please, update the patch accordingly. Best regards Heinrich ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] [U-boot]: Change FDT memory typpe from runtime data to acpi reclaim
On Fri, 12 Apr 2019 at 10:16, Heinrich Schuchardt wrote: > > On 4/11/19 10:50 PM, Ard Biesheuvel wrote: > > On Thu, 11 Apr 2019 at 12:59, Heinrich Schuchardt > > wrote: > >> > >> On 4/11/19 9:41 PM, Ilias Apalodimas wrote: > >>> Hi Heinrich, > On 4/11/19 8:39 PM, Ilias Apalodimas wrote: > > Following Ard's suggestion: > > Runtime data sections are intended for data that is used by the runtime > > services implementations. > > Let's change they type to EFI_ACPI_RECLAIM_MEMORY > > > > Suggested-by: Ard Biesheuvel > > Signed-off-by: Ilias Apalodimas > > --- > >cmd/bootefi.c | 4 ++-- > >1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/cmd/bootefi.c b/cmd/bootefi.c > > index 3619a20e6433..b54181909aff 100644 > > --- a/cmd/bootefi.c > > +++ b/cmd/bootefi.c > > @@ -111,13 +111,13 @@ static efi_status_t copy_fdt(void **fdtp) > > new_fdt_addr = (uintptr_t)map_sysmem(fdt_ram_start + 0x7f0 + > > fdt_size, 0); > > ret = efi_allocate_pages(EFI_ALLOCATE_MAX_ADDRESS, > > -EFI_RUNTIME_SERVICES_DATA, fdt_pages, > > +EFI_ACPI_RECLAIM_MEMORY, fdt_pages, > > GRUB uses EfiLoaderCode when installing its modified version of the FDT. > > The "Embedded Base Boot Requirements (EBBR) Specification, Release v1.0" > does not require ACPI support. Can we expect EfiACPIReclaimMemory to be > supported if we do not have any ACPI table? > > How about functions efi_smbios_register() and efi_acpi_register()? > > How about systab.tables assigned in efi_initialize_system_table()? Which > of the addresses in systab.tables should be updated upon relocation. > > The EFI Spec is really hazy: "A pointer to the table associated with > VendorGuid. Whether this pointer is a physical address or a > virtual address during runtime is determined by the VendorGuid." > > The FDT_TABLE_GUID or DEVICE_TREE_GUID as Linux calls it is not defined > in the UEFI spec. So we can marvel about expected behavior. Is there any > other document specifying it? > >>> > >>> What about using EFI_BOOT_SERVICES_DATA instead of > >>> EFI_ACPI_RECLAIM_MEMORY? > >>> This still fixes the issue and doesn't cause any of the potential > >>> problems you > >>> mentioned > >> > >> Why services data and not loader data? > >> > > > > Services data is used by the boot services and loader data by the > > loader. GRUB is a loader so it uses loader data, u-boot is both boot > > services and a loader so it could arguably use both, but boot services > > data is more idiomatic. > > > >>From the pov of the OS, it makes no difference at all. > > > >> As said above we should consider all three supported tables ACPI, > >> SMBIOS, and FDT when thinking about a fix. The UEFI spec describes that > >> the addresses inside ACPI and SMBIOS tables are not fixed up when > >> entering runtime. > >> > >> This indicates that at least these tables have to be accessible at > >> runtime. > > > > Accessible at runtime but *not* by the runtime services themselves. > > > >> Why do you think that the FDT table should be treated> differently to the > >> ACPI table? > >> > > > > Same thing. Accessible at runtime but not by the firmware services > > themselves. > > > > Only data structures that the runtime services need to access in order > > to implement the functionality they expose to the OS should be in > > runtime services data memory. This applies to DT, ACPI and SMBIOS > > tables alike, but as I mentioned, for historical reasons, SMBIOS > > tables are usually exposed via runtime services data. Interestingly, > > the UEFI spec mentions that smbios tables should be located in runtime > > services data but no virtual mapping should be requested for them, and > > this is actually impossible in EDK2, so the current practice of using > > rtservicesdata for SMBIOS with the EFI_MEMORY_RUNTIME attribute set > > also violates the UEFI spec. > > > > Hello Ilias, hello Ard, > > please, have a look at this patch: > > efi_loader: update virtual address in efi_mem_carve_out > https://lists.denx.de/pipermail/u-boot/2019-April/364937.html > > Possibly the bug reported here could have contributed the Linux crash > you experienced. > Hello Heinrich, That patch looks completely unrelated, to be honest. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] [U-boot]: Change FDT memory typpe from runtime data to acpi reclaim
On 4/11/19 10:50 PM, Ard Biesheuvel wrote: On Thu, 11 Apr 2019 at 12:59, Heinrich Schuchardt wrote: On 4/11/19 9:41 PM, Ilias Apalodimas wrote: Hi Heinrich, On 4/11/19 8:39 PM, Ilias Apalodimas wrote: Following Ard's suggestion: Runtime data sections are intended for data that is used by the runtime services implementations. Let's change they type to EFI_ACPI_RECLAIM_MEMORY Suggested-by: Ard Biesheuvel Signed-off-by: Ilias Apalodimas --- cmd/bootefi.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/cmd/bootefi.c b/cmd/bootefi.c index 3619a20e6433..b54181909aff 100644 --- a/cmd/bootefi.c +++ b/cmd/bootefi.c @@ -111,13 +111,13 @@ static efi_status_t copy_fdt(void **fdtp) new_fdt_addr = (uintptr_t)map_sysmem(fdt_ram_start + 0x7f0 + fdt_size, 0); ret = efi_allocate_pages(EFI_ALLOCATE_MAX_ADDRESS, -EFI_RUNTIME_SERVICES_DATA, fdt_pages, +EFI_ACPI_RECLAIM_MEMORY, fdt_pages, GRUB uses EfiLoaderCode when installing its modified version of the FDT. The "Embedded Base Boot Requirements (EBBR) Specification, Release v1.0" does not require ACPI support. Can we expect EfiACPIReclaimMemory to be supported if we do not have any ACPI table? How about functions efi_smbios_register() and efi_acpi_register()? How about systab.tables assigned in efi_initialize_system_table()? Which of the addresses in systab.tables should be updated upon relocation. The EFI Spec is really hazy: "A pointer to the table associated with VendorGuid. Whether this pointer is a physical address or a virtual address during runtime is determined by the VendorGuid." The FDT_TABLE_GUID or DEVICE_TREE_GUID as Linux calls it is not defined in the UEFI spec. So we can marvel about expected behavior. Is there any other document specifying it? What about using EFI_BOOT_SERVICES_DATA instead of EFI_ACPI_RECLAIM_MEMORY? This still fixes the issue and doesn't cause any of the potential problems you mentioned Why services data and not loader data? Services data is used by the boot services and loader data by the loader. GRUB is a loader so it uses loader data, u-boot is both boot services and a loader so it could arguably use both, but boot services data is more idiomatic. From the pov of the OS, it makes no difference at all. As said above we should consider all three supported tables ACPI, SMBIOS, and FDT when thinking about a fix. The UEFI spec describes that the addresses inside ACPI and SMBIOS tables are not fixed up when entering runtime. This indicates that at least these tables have to be accessible at runtime. Accessible at runtime but *not* by the runtime services themselves. Why do you think that the FDT table should be treated> differently to the ACPI table? Same thing. Accessible at runtime but not by the firmware services themselves. Only data structures that the runtime services need to access in order to implement the functionality they expose to the OS should be in runtime services data memory. This applies to DT, ACPI and SMBIOS tables alike, but as I mentioned, for historical reasons, SMBIOS tables are usually exposed via runtime services data. Interestingly, the UEFI spec mentions that smbios tables should be located in runtime services data but no virtual mapping should be requested for them, and this is actually impossible in EDK2, so the current practice of using rtservicesdata for SMBIOS with the EFI_MEMORY_RUNTIME attribute set also violates the UEFI spec. Hello Ilias, hello Ard, please, have a look at this patch: efi_loader: update virtual address in efi_mem_carve_out https://lists.denx.de/pipermail/u-boot/2019-April/364937.html Possibly the bug reported here could have contributed the Linux crash you experienced. Best regards Heinrich ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot,v2,0/7] AM65x HS device support
On 4/12/19 12:27 PM, Tom Rini wrote: > On Thu, Feb 21, 2019 at 04:35:05PM -0600, Andrew F. Davis wrote: > >> Hello all, >> >> This series brings up HS device support on the AM65x platform. Support >> for HS on K3 family devices is a bit different than previous devices >> but for the most part all that has been abstracted into the SECDEV >> package, allowing for a rather straight forward implementation here. >> >> Thanks, >> Andrew >> >> Changes from v1: >> - Commented on use of .data section >> - Use ti_sci_msg_hdr header directly when possible >> - Rebase and add Reviewed-bys >> - Will add makefile cleanup later as it also affects >>files unrelated to this series >> >> Andrew F. Davis (7): >> arm: K3: Avoid use of MCU_PSRAM0 before SYSFW is loaded >> firmware: ti_sci: Add support for firewall management >> firmware: ti_sci: Modify auth_boot TI-SCI API to match new version >> arm: mach-k3: Add secure device support >> arm: mach-k3: Add secure device build support >> configs: Add a config for AM65x High Security EVM >> doc: Update info on using K3 secure devices > > Can you please rebase this on master and repost? Thanks! > Done and sent. Thanks, Andrew ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 6/7] configs: Add configs for AM65x High Security EVM
Add new defconfig files for the AM65x High Security EVM.
This defconfigs are the same as for the non-secure part, except for:
CONFIG_TI_SECURE_DEVICE option set to 'y'
CONFIG_FIT_IMAGE_POST_PROCESS option set to 'y'
CONFIG_SPL_FIT_IMAGE_POST_PROCESS option set to 'y'
Signed-off-by: Andrew F. Davis
Reviewed-by: Tom Rini
Reviewed-by: Andreas Dannenberg
---
MAINTAINERS| 2 +
configs/am65x_hs_evm_a53_defconfig | 77 +
configs/am65x_hs_evm_r5_defconfig | 90 ++
3 files changed, 169 insertions(+)
create mode 100644 configs/am65x_hs_evm_a53_defconfig
create mode 100644 configs/am65x_hs_evm_r5_defconfig
diff --git a/MAINTAINERS b/MAINTAINERS
index 69a6789c04..aae2838f5c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -734,6 +734,8 @@ F: configs/k2hk_hs_evm_defconfig
F: configs/k2e_hs_evm_defconfig
F: configs/k2g_hs_evm_defconfig
F: configs/k2l_hs_evm_defconfig
+F: configs/am65x_hs_evm_r5_defconfig
+F: configs/am65x_hs_evm_a53_defconfig
TQ GROUP
#M:Martin Krause
diff --git a/configs/am65x_hs_evm_a53_defconfig
b/configs/am65x_hs_evm_a53_defconfig
new file mode 100644
index 00..dcafa458e0
--- /dev/null
+++ b/configs/am65x_hs_evm_a53_defconfig
@@ -0,0 +1,77 @@
+CONFIG_ARM=y
+CONFIG_ARCH_K3=y
+CONFIG_TI_SECURE_DEVICE=y
+CONFIG_SPL_LIBCOMMON_SUPPORT=y
+CONFIG_SPL_LIBGENERIC_SUPPORT=y
+CONFIG_SYS_MALLOC_F_LEN=0x2000
+CONFIG_SOC_K3_AM6=y
+CONFIG_TARGET_AM654_A53_EVM=y
+CONFIG_SPL_MMC_SUPPORT=y
+CONFIG_SPL_SERIAL_SUPPORT=y
+CONFIG_SPL_DRIVERS_MISC_SUPPORT=y
+CONFIG_SPL_STACK_R_ADDR=0x8200
+CONFIG_SPL_FS_FAT=y
+CONFIG_SPL_LIBDISK_SUPPORT=y
+CONFIG_DISTRO_DEFAULTS=y
+CONFIG_NR_DRAM_BANKS=2
+# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
+CONFIG_FIT_IMAGE_POST_PROCESS=y
+CONFIG_SPL_LOAD_FIT=y
+CONFIG_SPL_FIT_IMAGE_POST_PROCESS=y
+CONFIG_OF_BOARD_SETUP=y
+CONFIG_BOOTCOMMAND="run findfdt; run envboot; run init_${boot}; run
get_kern_${boot}; run get_fdt_${boot}; run run_kern"
+# CONFIG_DISPLAY_CPUINFO is not set
+CONFIG_SPL_SYS_MALLOC_SIMPLE=y
+CONFIG_SPL_STACK_R=y
+CONFIG_SPL_SEPARATE_BSS=y
+CONFIG_SPL_I2C_SUPPORT=y
+CONFIG_SPL_DM_MAILBOX=y
+CONFIG_SPL_DM_RESET=y
+CONFIG_SPL_POWER_DOMAIN=y
+CONFIG_SPL_REMOTEPROC=y
+CONFIG_SPL_YMODEM_SUPPORT=y
+CONFIG_CMD_ASKENV=y
+# CONFIG_CMD_FLASH is not set
+CONFIG_CMD_MMC=y
+CONFIG_CMD_REMOTEPROC=y
+# CONFIG_CMD_SETEXPR is not set
+CONFIG_CMD_TIME=y
+# CONFIG_ISO_PARTITION is not set
+# CONFIG_EFI_PARTITION is not set
+CONFIG_OF_CONTROL=y
+CONFIG_SPL_OF_CONTROL=y
+CONFIG_DEFAULT_DEVICE_TREE="k3-am654-base-board"
+CONFIG_SPL_MULTI_DTB_FIT=y
+CONFIG_SPL_MULTI_DTB_FIT_NO_COMPRESSION=y
+CONFIG_ENV_IS_IN_FAT=y
+CONFIG_ENV_FAT_INTERFACE="mmc"
+CONFIG_ENV_FAT_DEVICE_AND_PART="1:1"
+CONFIG_DM=y
+CONFIG_SPL_DM=y
+CONFIG_SPL_DM_SEQ_ALIAS=y
+CONFIG_CLK=y
+CONFIG_SPL_CLK=y
+CONFIG_CLK_TI_SCI=y
+CONFIG_DMA_CHANNELS=y
+CONFIG_TI_K3_NAVSS_UDMA=y
+CONFIG_TI_SCI_PROTOCOL=y
+CONFIG_DM_MAILBOX=y
+CONFIG_K3_SEC_PROXY=y
+CONFIG_DM_MMC=y
+CONFIG_MMC_SDHCI=y
+CONFIG_MMC_SDHCI_K3_ARASAN=y
+CONFIG_PINCTRL=y
+# CONFIG_PINCTRL_GENERIC is not set
+CONFIG_SPL_PINCTRL=y
+# CONFIG_SPL_PINCTRL_GENERIC is not set
+CONFIG_PINCTRL_SINGLE=y
+CONFIG_POWER_DOMAIN=y
+CONFIG_TI_SCI_POWER_DOMAIN=y
+CONFIG_K3_SYSTEM_CONTROLLER=y
+CONFIG_REMOTEPROC_K3=y
+CONFIG_DM_RESET=y
+CONFIG_RESET_TI_SCI=y
+CONFIG_DM_SERIAL=y
+CONFIG_SOC_TI=y
+CONFIG_SYSRESET=y
+CONFIG_SYSRESET_TI_SCI=y
diff --git a/configs/am65x_hs_evm_r5_defconfig
b/configs/am65x_hs_evm_r5_defconfig
new file mode 100644
index 00..1b9c138c03
--- /dev/null
+++ b/configs/am65x_hs_evm_r5_defconfig
@@ -0,0 +1,90 @@
+CONFIG_ARM=y
+CONFIG_ARCH_K3=y
+CONFIG_TI_SECURE_DEVICE=y
+CONFIG_SPL_GPIO_SUPPORT=y
+CONFIG_SPL_LIBCOMMON_SUPPORT=y
+CONFIG_SPL_LIBGENERIC_SUPPORT=y
+CONFIG_SYS_MALLOC_F_LEN=0x2000
+CONFIG_SOC_K3_AM6=y
+CONFIG_TARGET_AM654_R5_EVM=y
+CONFIG_SPL_MMC_SUPPORT=y
+CONFIG_SPL_SERIAL_SUPPORT=y
+CONFIG_SPL_DRIVERS_MISC_SUPPORT=y
+CONFIG_SPL_STACK_R_ADDR=0x8200
+CONFIG_SPL_FS_FAT=y
+CONFIG_SPL_LIBDISK_SUPPORT=y
+CONFIG_NR_DRAM_BANKS=2
+# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
+CONFIG_SPL_LOAD_FIT=y
+CONFIG_SPL_FIT_IMAGE_POST_PROCESS=y
+CONFIG_USE_BOOTCOMMAND=y
+# CONFIG_DISPLAY_CPUINFO is not set
+CONFIG_SPL_SYS_MALLOC_SIMPLE=y
+CONFIG_SPL_STACK_R=y
+CONFIG_SPL_SEPARATE_BSS=y
+CONFIG_SPL_I2C_SUPPORT=y
+CONFIG_SPL_DM_MAILBOX=y
+CONFIG_SPL_DM_RESET=y
+CONFIG_SPL_POWER_SUPPORT=y
+CONFIG_SPL_POWER_DOMAIN=y
+CONFIG_SPL_RAM_SUPPORT=y
+CONFIG_SPL_RAM_DEVICE=y
+CONFIG_SPL_REMOTEPROC=y
+CONFIG_SPL_YMODEM_SUPPORT=y
+CONFIG_HUSH_PARSER=y
+CONFIG_CMD_BOOTZ=y
+CONFIG_CMD_ASKENV=y
+# CONFIG_CMD_FLASH is not set
+CONFIG_CMD_GPT=y
+CONFIG_CMD_MMC=y
+CONFIG_CMD_REMOTEPROC=y
+# CONFIG_CMD_SETEXPR is not set
+CONFIG_CMD_TIME=y
+CONFIG_CMD_FAT=y
+CONFIG_OF_CONTROL=y
+CONFIG_SPL_OF_CONTROL=y
+CONFIG_DEFAULT_DEVICE_TREE="k3-am654-r5-base-board"
+CONFIG_SPL_MULTI_DTB_FIT=y
+CONFIG_SPL_MULTI_DTB_FIT_NO_COMPRESSION=y
+CONFIG_ENV_IS_IN_FAT=y
[U-Boot] [PATCH v3 7/7] doc: Update info on using K3 secure devices
Signed-off-by: Andrew F. Davis Reviewed-by: Tom Rini Reviewed-by: Andreas Dannenberg --- doc/README.ti-secure | 20 +++- 1 file changed, 15 insertions(+), 5 deletions(-) diff --git a/doc/README.ti-secure b/doc/README.ti-secure index 76950253ac..27c0eaa77f 100644 --- a/doc/README.ti-secure +++ b/doc/README.ti-secure @@ -138,7 +138,7 @@ Booting of U-Boot SPL Invoking the script for Keystone2 Secure Devices - = + create-boot-image.sh \ @@ -157,6 +157,18 @@ Booting of U-Boot SPL boot from all media. Secure boot from SPI NOR flash is not currently supported. + Invoking the script for K3 Secure Devices + = + + The signing steps required to produce a bootable SPL image on secure + K3 TI devices are the same as those performed on non-secure devices. + The only difference is the key is not checked on non-secure devices so + a dummy key is used when building U-Boot for those devices. For secure + K3 TI devices simply use the real hardware key for your device. This + real key can be set with the Kconfig option "K3_KEY". The environment + variable TI_SECURE_DEV_PKG is also searched for real keys when the + build targets secure devices. + Booting of Primary U-Boot (u-boot.img) == @@ -181,10 +193,8 @@ Booting of Primary U-Boot (u-boot.img) is enabled through the CONFIG_SPL_FIT_IMAGE_POST_PROCESS option which must be enabled for the secure boot scheme to work. In order to allow verifying proper operation of the secure boot chain in case of successful - authentication messages like "Authentication passed: CERT_U-BOOT-NOD" are - output by the SPL to the console for each blob that got extracted from the - FIT image. Note that the last part of this log message is the (truncated) - name of the signing certificate embedded into the blob that got processed. + authentication messages like "Authentication passed" are output by the + SPL to the console for each blob that got extracted from the FIT image. The exact details of the how the images are secured is handled by the SECDEV package. Within the SECDEV package exists a script to process -- 2.21.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 0/7] AM65x HS device support
Hello all, This series brings up HS device support on the AM65x platform. Support for HS on K3 family devices is a bit different than previous devices but for the most part all that has been abstracted into the SECDEV package, allowing for a rather straight forward implementation here. Thanks, Andrew Changes from v2: - Rebased on latest master Changes from v1: - Commented on use of .data section - Use ti_sci_msg_hdr header directly when possible - Rebase and add Reviewed-bys - Will add makefile cleanup later as it also affects files unrelated to this series Andrew F. Davis (7): arm: K3: Avoid use of MCU_PSRAM0 before SYSFW is loaded firmware: ti_sci: Add support for firewall management firmware: ti_sci: Modify auth_boot TI-SCI API to match new version arm: mach-k3: Add secure device support arm: mach-k3: Add secure device build support configs: Add configs for AM65x High Security EVM doc: Update info on using K3 secure devices MAINTAINERS | 4 + arch/arm/Kconfig | 2 +- arch/arm/mach-k3/Makefile| 1 + arch/arm/mach-k3/am6_init.c | 13 +- arch/arm/mach-k3/config.mk | 25 +++ arch/arm/mach-k3/config_secure.mk| 44 arch/arm/mach-k3/include/mach/am6_hardware.h | 3 - arch/arm/mach-k3/security.c | 63 ++ configs/am65x_hs_evm_a53_defconfig | 77 +++ configs/am65x_hs_evm_r5_defconfig| 90 + doc/README.ti-secure | 20 +- drivers/firmware/ti_sci.c| 202 ++- drivers/firmware/ti_sci.h| 130 +++- include/linux/soc/ti/ti_sci_protocol.h | 68 ++- tools/k3_fit_atf.sh | 8 +- 15 files changed, 721 insertions(+), 29 deletions(-) create mode 100644 arch/arm/mach-k3/config_secure.mk create mode 100644 arch/arm/mach-k3/security.c create mode 100644 configs/am65x_hs_evm_a53_defconfig create mode 100644 configs/am65x_hs_evm_r5_defconfig -- 2.21.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 2/7] firmware: ti_sci: Add support for firewall management
TI-SCI message protocol provides support for controlling the firewall
configurations available in SoC.
Introduce support for the set of TI-SCI message protocol APIs that
provide us with this capability of controlling firewalls.
Signed-off-by: Andrew F. Davis
Reviewed-by: Tom Rini
Reviewed-by: Andreas Dannenberg
---
drivers/firmware/ti_sci.c | 177 +
drivers/firmware/ti_sci.h | 121 +
include/linux/soc/ti/ti_sci_protocol.h | 64 +
3 files changed, 362 insertions(+)
diff --git a/drivers/firmware/ti_sci.c b/drivers/firmware/ti_sci.c
index d47d22fff3..44bbeb66c2 100644
--- a/drivers/firmware/ti_sci.c
+++ b/drivers/firmware/ti_sci.c
@@ -2428,6 +2428,178 @@ fail:
return ret;
}
+/**
+ * ti_sci_cmd_set_fwl_region() - Request for configuring a firewall region
+ * @handle:pointer to TI SCI handle
+ * @region:region configuration parameters
+ *
+ * Return: 0 if all went well, else returns appropriate error value.
+ */
+static int ti_sci_cmd_set_fwl_region(const struct ti_sci_handle *handle,
+const struct ti_sci_msg_fwl_region *region)
+{
+ struct ti_sci_msg_fwl_set_firewall_region_req req;
+ struct ti_sci_msg_hdr *resp;
+ struct ti_sci_info *info;
+ struct ti_sci_xfer *xfer;
+ int ret = 0;
+
+ if (IS_ERR(handle))
+ return PTR_ERR(handle);
+ if (!handle)
+ return -EINVAL;
+
+ info = handle_to_ti_sci_info(handle);
+
+ xfer = ti_sci_setup_one_xfer(info, TISCI_MSG_FWL_SET,
+TI_SCI_FLAG_REQ_ACK_ON_PROCESSED,
+(u32 *), sizeof(req), sizeof(*resp));
+ if (IS_ERR(xfer)) {
+ ret = PTR_ERR(xfer);
+ dev_err(info->dev, "Message alloc failed(%d)\n", ret);
+ return ret;
+ }
+
+ req.fwl_id = region->fwl_id;
+ req.region = region->region;
+ req.n_permission_regs = region->n_permission_regs;
+ req.control = region->control;
+ req.permissions[0] = region->permissions[0];
+ req.permissions[1] = region->permissions[1];
+ req.permissions[2] = region->permissions[2];
+ req.start_address = region->start_address;
+ req.end_address = region->end_address;
+
+ ret = ti_sci_do_xfer(info, xfer);
+ if (ret) {
+ dev_err(info->dev, "Mbox send fail %d\n", ret);
+ return ret;
+ }
+
+ resp = (struct ti_sci_msg_hdr *)xfer->tx_message.buf;
+
+ if (!ti_sci_is_response_ack(resp))
+ return -ENODEV;
+
+ return 0;
+}
+
+/**
+ * ti_sci_cmd_get_fwl_region() - Request for getting a firewall region
+ * @handle:pointer to TI SCI handle
+ * @region:region configuration parameters
+ *
+ * Return: 0 if all went well, else returns appropriate error value.
+ */
+static int ti_sci_cmd_get_fwl_region(const struct ti_sci_handle *handle,
+struct ti_sci_msg_fwl_region *region)
+{
+ struct ti_sci_msg_fwl_get_firewall_region_req req;
+ struct ti_sci_msg_fwl_get_firewall_region_resp *resp;
+ struct ti_sci_info *info;
+ struct ti_sci_xfer *xfer;
+ int ret = 0;
+
+ if (IS_ERR(handle))
+ return PTR_ERR(handle);
+ if (!handle)
+ return -EINVAL;
+
+ info = handle_to_ti_sci_info(handle);
+
+ xfer = ti_sci_setup_one_xfer(info, TISCI_MSG_FWL_GET,
+TI_SCI_FLAG_REQ_ACK_ON_PROCESSED,
+(u32 *), sizeof(req), sizeof(*resp));
+ if (IS_ERR(xfer)) {
+ ret = PTR_ERR(xfer);
+ dev_err(info->dev, "Message alloc failed(%d)\n", ret);
+ return ret;
+ }
+
+ req.fwl_id = region->fwl_id;
+ req.region = region->region;
+ req.n_permission_regs = region->n_permission_regs;
+
+ ret = ti_sci_do_xfer(info, xfer);
+ if (ret) {
+ dev_err(info->dev, "Mbox send fail %d\n", ret);
+ return ret;
+ }
+
+ resp = (struct ti_sci_msg_fwl_get_firewall_region_resp
*)xfer->tx_message.buf;
+
+ if (!ti_sci_is_response_ack(resp))
+ return -ENODEV;
+
+ region->fwl_id = resp->fwl_id;
+ region->region = resp->region;
+ region->n_permission_regs = resp->n_permission_regs;
+ region->control = resp->control;
+ region->permissions[0] = resp->permissions[0];
+ region->permissions[1] = resp->permissions[1];
+ region->permissions[2] = resp->permissions[2];
+ region->start_address = resp->start_address;
+ region->end_address = resp->end_address;
+
+ return 0;
+}
+
+/**
+ * ti_sci_cmd_change_fwl_owner() - Request for changing a firewall owner
+ * @handle:pointer to TI SCI handle
+ * @region:region configuration parameters
+ *
+ * Return: 0 if all went well, else
[U-Boot] [PATCH v3 1/7] arm: K3: Avoid use of MCU_PSRAM0 before SYSFW is loaded
On HS devices the 512b region of reset isolated memory called
MCU_PSRAM0 is firewalled by default. Until SYSFW is loaded we
cannot use this memory. It is only used to store a single value
left at the end of SRAM by ROM that will be needed later. Save
that value to a global variable stored in the .data section.
This section is used as .bss will be cleared between saving
this value and using it.
Signed-off-by: Andrew F. Davis
Reviewed-by: Andreas Dannenberg
Reviewed-by: Lokesh Vutla
---
arch/arm/mach-k3/am6_init.c | 13 -
arch/arm/mach-k3/include/mach/am6_hardware.h | 3 ---
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-k3/am6_init.c b/arch/arm/mach-k3/am6_init.c
index 77cd15f388..60a580305d 100644
--- a/arch/arm/mach-k3/am6_init.c
+++ b/arch/arm/mach-k3/am6_init.c
@@ -49,11 +49,16 @@ static void ctrl_mmr_unlock(void)
mmr_unlock(CTRL_MMR0_BASE, 7);
}
+/*
+ * This uninitialized global variable would normal end up in the .bss section,
+ * but the .bss is cleared between writing and reading this variable, so move
+ * it to the .data section.
+ */
+u32 bootindex __attribute__((section(".data")));
+
static void store_boot_index_from_rom(void)
{
- u32 *boot_index = (u32 *)K3_BOOT_PARAM_TABLE_INDEX_VAL;
-
- *boot_index = *(u32 *)(CONFIG_SYS_K3_BOOT_PARAM_TABLE_INDEX);
+ bootindex = *(u32 *)(CONFIG_SYS_K3_BOOT_PARAM_TABLE_INDEX);
}
void board_init_f(ulong dummy)
@@ -92,7 +97,6 @@ u32 spl_boot_mode(const u32 boot_device)
{
#if defined(CONFIG_SUPPORT_EMMC_BOOT)
u32 devstat = readl(CTRLMMR_MAIN_DEVSTAT);
- u32 bootindex = readl(K3_BOOT_PARAM_TABLE_INDEX_VAL);
u32 bootmode = (devstat & CTRLMMR_MAIN_DEVSTAT_BOOTMODE_MASK) >>
CTRLMMR_MAIN_DEVSTAT_BOOTMODE_SHIFT;
@@ -168,7 +172,6 @@ static u32 __get_primary_bootmedia(u32 devstat)
u32 spl_boot_device(void)
{
u32 devstat = readl(CTRLMMR_MAIN_DEVSTAT);
- u32 bootindex = readl(K3_BOOT_PARAM_TABLE_INDEX_VAL);
if (bootindex == K3_PRIMARY_BOOTMODE)
return __get_primary_bootmedia(devstat);
diff --git a/arch/arm/mach-k3/include/mach/am6_hardware.h
b/arch/arm/mach-k3/include/mach/am6_hardware.h
index b5244609af..3343233aa3 100644
--- a/arch/arm/mach-k3/include/mach/am6_hardware.h
+++ b/arch/arm/mach-k3/include/mach/am6_hardware.h
@@ -44,7 +44,4 @@
#define CTRLMMR_LOCK_KICK1 0x0100c
#define CTRLMMR_LOCK_KICK1_UNLOCK_VAL 0xd172bc5a
-/* MCU SCRATCHPAD usage */
-#define K3_BOOT_PARAM_TABLE_INDEX_VAL CONFIG_SYS_K3_MCU_SCRATCHPAD_BASE
-
#endif /* __ASM_ARCH_AM6_HARDWARE_H */
--
2.21.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 3/7] firmware: ti_sci: Modify auth_boot TI-SCI API to match new version
SYSFW version 2019.01 introduces a slightly modified version of this API,
add support for it here.
Signed-off-by: Andrew F. Davis
Reviewed-by: Tom Rini
Reviewed-by: Andreas Dannenberg
---
drivers/firmware/ti_sci.c | 25 -
drivers/firmware/ti_sci.h | 9 +++--
include/linux/soc/ti/ti_sci_protocol.h | 4 ++--
3 files changed, 25 insertions(+), 13 deletions(-)
diff --git a/drivers/firmware/ti_sci.c b/drivers/firmware/ti_sci.c
index 44bbeb66c2..1196ce0712 100644
--- a/drivers/firmware/ti_sci.c
+++ b/drivers/firmware/ti_sci.c
@@ -1915,16 +1915,19 @@ static int ti_sci_cmd_set_proc_boot_ctrl(const struct
ti_sci_handle *handle,
* ti_sci_cmd_proc_auth_boot_image() - Command to authenticate and load the
* image and then set the processor configuration flags.
* @handle:Pointer to TI SCI handle
- * @proc_id: Processor ID this request is for
- * @cert_addr: Memory address at which payload image certificate is located.
+ * @image_addr:Memory address at which payload image and certificate is
+ * located in memory, this is updated if the image data is
+ * moved during authentication.
+ * @image_size: This is updated with the final size of the image after
+ * authentication.
*
* Return: 0 if all went well, else returns appropriate error value.
*/
static int ti_sci_cmd_proc_auth_boot_image(const struct ti_sci_handle *handle,
- u8 proc_id, u64 cert_addr)
+ u64 *image_addr, u32 *image_size)
{
struct ti_sci_msg_req_proc_auth_boot_image req;
- struct ti_sci_msg_hdr *resp;
+ struct ti_sci_msg_resp_proc_auth_boot_image *resp;
struct ti_sci_info *info;
struct ti_sci_xfer *xfer;
int ret = 0;
@@ -1944,9 +1947,8 @@ static int ti_sci_cmd_proc_auth_boot_image(const struct
ti_sci_handle *handle,
dev_err(info->dev, "Message alloc failed(%d)\n", ret);
return ret;
}
- req.processor_id = proc_id;
- req.cert_addr_low = cert_addr & TISCI_ADDR_LOW_MASK;
- req.cert_addr_high = (cert_addr & TISCI_ADDR_HIGH_MASK) >>
+ req.cert_addr_low = *image_addr & TISCI_ADDR_LOW_MASK;
+ req.cert_addr_high = (*image_addr & TISCI_ADDR_HIGH_MASK) >>
TISCI_ADDR_HIGH_SHIFT;
ret = ti_sci_do_xfer(info, xfer);
@@ -1955,10 +1957,15 @@ static int ti_sci_cmd_proc_auth_boot_image(const struct
ti_sci_handle *handle,
return ret;
}
- resp = (struct ti_sci_msg_hdr *)xfer->tx_message.buf;
+ resp = (struct ti_sci_msg_resp_proc_auth_boot_image
*)xfer->tx_message.buf;
if (!ti_sci_is_response_ack(resp))
- ret = -ENODEV;
+ return -ENODEV;
+
+ *image_addr = (resp->image_addr_low & TISCI_ADDR_LOW_MASK) |
+ (((u64)resp->image_addr_high <<
+ TISCI_ADDR_HIGH_SHIFT) & TISCI_ADDR_HIGH_MASK);
+ *image_size = resp->image_size;
return ret;
}
diff --git a/drivers/firmware/ti_sci.h b/drivers/firmware/ti_sci.h
index 1b601ff01b..a484b1fa40 100644
--- a/drivers/firmware/ti_sci.h
+++ b/drivers/firmware/ti_sci.h
@@ -708,7 +708,6 @@ struct ti_sci_msg_req_set_proc_boot_ctrl {
/**
* struct ti_sci_msg_req_proc_auth_start_image - Authenticate and start image
* @hdr: Generic Header
- * @processor_id: ID of processor
* @cert_addr_low: Lower 32bit (Little Endian) of certificate
* @cert_addr_high:Higher 32bit (Little Endian) of certificate
*
@@ -717,11 +716,17 @@ struct ti_sci_msg_req_set_proc_boot_ctrl {
*/
struct ti_sci_msg_req_proc_auth_boot_image {
struct ti_sci_msg_hdr hdr;
- u8 processor_id;
u32 cert_addr_low;
u32 cert_addr_high;
} __packed;
+struct ti_sci_msg_resp_proc_auth_boot_image {
+ struct ti_sci_msg_hdr hdr;
+ u32 image_addr_low;
+ u32 image_addr_high;
+ u32 image_size;
+} __packed;
+
/**
* struct ti_sci_msg_req_get_proc_boot_status - Get processor boot status
* @hdr: Generic Header
diff --git a/include/linux/soc/ti/ti_sci_protocol.h
b/include/linux/soc/ti/ti_sci_protocol.h
index 895cb1b911..c57802f293 100644
--- a/include/linux/soc/ti/ti_sci_protocol.h
+++ b/include/linux/soc/ti/ti_sci_protocol.h
@@ -279,8 +279,8 @@ struct ti_sci_proc_ops {
u64 bv, u32 cfg_set, u32 cfg_clr);
int (*set_proc_boot_ctrl)(const struct ti_sci_handle *handle, u8 pid,
u32 ctrl_set, u32 ctrl_clr);
- int (*proc_auth_boot_image)(const struct ti_sci_handle *handle, u8 pid,
- u64 caddr);
+ int (*proc_auth_boot_image)(const struct ti_sci_handle *handle,
+ u64 *image_addr, u32 *image_size);
int (*get_proc_boot_status)(const
[U-Boot] [PATCH v3 5/7] arm: mach-k3: Add secure device build support
K3 HS devices require signed binaries for boot, use the SECDEV tools
to sign the boot artifacts during build.
Signed-off-by: Andrew F. Davis
Reviewed-by: Tom Rini
Reviewed-by: Andreas Dannenberg
---
MAINTAINERS | 1 +
arch/arm/mach-k3/config.mk| 25 ++
arch/arm/mach-k3/config_secure.mk | 44 +++
tools/k3_fit_atf.sh | 8 --
4 files changed, 76 insertions(+), 2 deletions(-)
create mode 100644 arch/arm/mach-k3/config_secure.mk
diff --git a/MAINTAINERS b/MAINTAINERS
index de1ea20930..69a6789c04 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -722,6 +722,7 @@ F: arch/arm/mach-omap2/omap5/sec_entry_cpu1.S
F: arch/arm/mach-omap2/sec-common.c
F: arch/arm/mach-omap2/config_secure.mk
F: arch/arm/mach-k3/security.c
+F: arch/arm/mach-k3/config_secure.mk
F: configs/am335x_hs_evm_defconfig
F: configs/am335x_hs_evm_uart_defconfig
F: configs/am43xx_hs_evm_defconfig
diff --git a/arch/arm/mach-k3/config.mk b/arch/arm/mach-k3/config.mk
index be00d79fb0..2d8f61f9db 100644
--- a/arch/arm/mach-k3/config.mk
+++ b/arch/arm/mach-k3/config.mk
@@ -36,6 +36,14 @@ cmd_gencert = cat $(srctree)/tools/k3_x509template.txt | sed
$(SED_OPTS) > u-boo
# If external key is not provided, generate key using openssl.
ifeq ($(CONFIG_SYS_K3_KEY), "")
KEY=u-boot-spl-eckey.pem
+# On HS use real key or warn if not available
+ifeq ($(CONFIG_TI_SECURE_DEVICE),y)
+ifneq ($(wildcard $(TI_SECURE_DEV_PKG)/keys/custMpk.pem),)
+KEY=$(TI_SECURE_DEV_PKG)/keys/custMpk.pem
+else
+$(warning "WARNING: signing key not found. Random key will NOT work on HS
hardware!")
+endif
+endif
else
KEY=$(patsubst "%",$(srctree)/%,$(CONFIG_SYS_K3_KEY))
endif
@@ -65,6 +73,15 @@ ALL-y+= tiboot3.bin
endif
ifdef CONFIG_ARM64
+ifeq ($(CONFIG_TI_SECURE_DEVICE),y)
+SPL_ITS := u-boot-spl-k3_HS.its
+$(SPL_ITS): FORCE
+ IS_HS=1 \
+ $(srctree)/tools/k3_fit_atf.sh \
+ $(patsubst %,$(obj)/dts/%.dtb,$(subst ",,$(CONFIG_SPL_OF_LIST))) > $@
+
+ALL-y += tispl.bin_HS
+else
SPL_ITS := u-boot-spl-k3.its
$(SPL_ITS): FORCE
$(srctree)/tools/k3_fit_atf.sh \
@@ -72,7 +89,15 @@ $(SPL_ITS): FORCE
ALL-y += tispl.bin
endif
+endif
+
+else
+ifeq ($(CONFIG_TI_SECURE_DEVICE),y)
+ALL-y += u-boot.img_HS
else
ALL-y += u-boot.img
endif
+endif
+
+include $(srctree)/arch/arm/mach-k3/config_secure.mk
diff --git a/arch/arm/mach-k3/config_secure.mk
b/arch/arm/mach-k3/config_secure.mk
new file mode 100644
index 00..6d63c57665
--- /dev/null
+++ b/arch/arm/mach-k3/config_secure.mk
@@ -0,0 +1,44 @@
+# SPDX-License-Identifier: GPL-2.0
+#
+# Copyright (C) 2018 Texas Instruments, Incorporated - http://www.ti.com/
+# Andrew F. Davis
+
+quiet_cmd_k3secureimg = SECURE $@
+ifneq ($(TI_SECURE_DEV_PKG),)
+ifneq ($(wildcard $(TI_SECURE_DEV_PKG)/scripts/secure-binary-image.sh),)
+cmd_k3secureimg = $(TI_SECURE_DEV_PKG)/scripts/secure-binary-image.sh \
+ $< $@ \
+ $(if $(KBUILD_VERBOSE:1=), >/dev/null)
+else
+cmd_k3secureimg = echo "WARNING:" \
+ "$(TI_SECURE_DEV_PKG)/scripts/secure-binary-image.sh not found." \
+ "$@ was NOT secured!"; cp $< $@
+endif
+else
+cmd_k3secureimg = echo "WARNING: TI_SECURE_DEV_PKG environment" \
+ "variable must be defined for TI secure devices." \
+ "$@ was NOT secured!"; cp $< $@
+endif
+
+%.dtb_HS: %.dtb FORCE
+ $(call if_changed,k3secureimg)
+
+$(obj)/u-boot-spl-nodtb.bin_HS: $(obj)/u-boot-spl-nodtb.bin FORCE
+ $(call if_changed,k3secureimg)
+
+tispl.bin_HS: $(obj)/u-boot-spl-nodtb.bin_HS $(patsubst
%,$(obj)/dts/%.dtb_HS,$(subst ",,$(CONFIG_SPL_OF_LIST))) $(SPL_ITS) FORCE
+ $(call if_changed,mkfitimage)
+
+MKIMAGEFLAGS_u-boot.img_HS = -f auto -A $(ARCH) -T firmware -C none -O u-boot \
+ -a $(CONFIG_SYS_TEXT_BASE) -e $(CONFIG_SYS_UBOOT_START) \
+ -n "U-Boot $(UBOOTRELEASE) for $(BOARD) board" -E \
+ $(patsubst %,-b arch/$(ARCH)/dts/%.dtb_HS,$(subst ",,$(CONFIG_OF_LIST)))
+
+OF_LIST_TARGETS = $(patsubst %,arch/$(ARCH)/dts/%.dtb,$(subst
",,$(CONFIG_OF_LIST)))
+$(OF_LIST_TARGETS): dtbs
+
+u-boot-nodtb.bin_HS: u-boot-nodtb.bin FORCE
+ $(call if_changed,k3secureimg)
+
+u-boot.img_HS: u-boot-nodtb.bin_HS u-boot.img $(patsubst
%.dtb,%.dtb_HS,$(OF_LIST_TARGETS)) FORCE
+ $(call if_changed,mkimage)
diff --git a/tools/k3_fit_atf.sh b/tools/k3_fit_atf.sh
index 430b5ca616..4e9f69c087 100755
--- a/tools/k3_fit_atf.sh
+++ b/tools/k3_fit_atf.sh
@@ -21,6 +21,10 @@ if [ ! -f $TEE ]; then
TEE=/dev/null
fi
+if [ ! -z "$IS_HS" ]; then
+ HS_APPEND=_HS
+fi
+
cat << __HEADER_EOF
/dts-v1/;
@@ -51,7 +55,7 @@ cat << __HEADER_EOF
};
spl {
description = "SPL (64-bit)";
- data = /incbin/("spl/u-boot-spl-nodtb.bin");
+ data = /incbin/("spl/u-boot-spl-nodtb.bin$HS_APPEND");
type = "standalone";
Re: [U-Boot] [U-Boot, 4/5] board: ti: am65x: Enable fixing up msmc sram node
On Fri, Mar 08, 2019 at 11:47:35AM +0530, Lokesh Vutla wrote: > Create a ft_board_setup() api that gets called as part of > DT fixup before jumping to kernel. In this ft_board_setup() > call fdt_fixup_msmc_ram that update msmc sram node. > > Signed-off-by: Lokesh Vutla Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 4/7] arm: mach-k3: Add secure device support
K3 devices have High Security (HS) variants along with the non-HS already
supported. Like the previous generation devices (OMAP/Keystone2) K3
supports boot chain-of-trust by authenticating and optionally decrypting
images as they are unpacked from FIT images. Add support for this here.
Signed-off-by: Andrew F. Davis
Reviewed-by: Tom Rini
Reviewed-by: Andreas Dannenberg
---
MAINTAINERS | 1 +
arch/arm/Kconfig| 2 +-
arch/arm/mach-k3/Makefile | 1 +
arch/arm/mach-k3/security.c | 63 +
4 files changed, 66 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/mach-k3/security.c
diff --git a/MAINTAINERS b/MAINTAINERS
index f9ee4281d9..de1ea20930 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -721,6 +721,7 @@ S: Supported
F: arch/arm/mach-omap2/omap5/sec_entry_cpu1.S
F: arch/arm/mach-omap2/sec-common.c
F: arch/arm/mach-omap2/config_secure.mk
+F: arch/arm/mach-k3/security.c
F: configs/am335x_hs_evm_defconfig
F: configs/am335x_hs_evm_uart_defconfig
F: configs/am43xx_hs_evm_defconfig
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 398dbef1cb..f89e590464 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1456,7 +1456,7 @@ endchoice
config TI_SECURE_DEVICE
bool "HS Device Type Support"
- depends on ARCH_KEYSTONE || ARCH_OMAP2PLUS
+ depends on ARCH_KEYSTONE || ARCH_OMAP2PLUS || ARCH_K3
help
If a high secure (HS) device type is being used, this config
must be set. This option impacts various aspects of the
diff --git a/arch/arm/mach-k3/Makefile b/arch/arm/mach-k3/Makefile
index bd4ab361b2..0c3a4f7db1 100644
--- a/arch/arm/mach-k3/Makefile
+++ b/arch/arm/mach-k3/Makefile
@@ -6,4 +6,5 @@
obj-$(CONFIG_SOC_K3_AM6) += am6_init.o
obj-$(CONFIG_ARM64) += arm64-mmu.o
obj-$(CONFIG_CPU_V7R) += r5_mpu.o lowlevel_init.o
+obj-$(CONFIG_TI_SECURE_DEVICE) += security.o
obj-y += common.o
diff --git a/arch/arm/mach-k3/security.c b/arch/arm/mach-k3/security.c
new file mode 100644
index 00..52f49bf01f
--- /dev/null
+++ b/arch/arm/mach-k3/security.c
@@ -0,0 +1,63 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * K3: Security functions
+ *
+ * Copyright (C) 2018 Texas Instruments Incorporated - http://www.ti.com/
+ * Andrew F. Davis
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+void board_fit_image_post_process(void **p_image, size_t *p_size)
+{
+ struct udevice *dev;
+ struct ti_sci_handle *ti_sci;
+ struct ti_sci_proc_ops *proc_ops;
+ u64 image_addr;
+ u32 image_size;
+ int ret;
+
+ /* Get handle to Device Management and Security Controller (SYSFW) */
+ ret = uclass_get_device_by_name(UCLASS_FIRMWARE, "dmsc", );
+ if (ret) {
+ printf("Failed to get handle to SYSFW (%d)\n", ret);
+ hang();
+ }
+ ti_sci = (struct ti_sci_handle *)(ti_sci_get_handle_from_sysfw(dev));
+ proc_ops = _sci->ops.proc_ops;
+
+ image_addr = (uintptr_t)*p_image;
+
+ debug("Authenticating image at address 0x%016llx\n", image_addr);
+
+ /* Authenticate image */
+ ret = proc_ops->proc_auth_boot_image(ti_sci, _addr, _size);
+ if (ret) {
+ printf("Authentication failed!\n");
+ hang();
+ }
+
+ /*
+* The image_size returned may be 0 when the authentication process has
+* moved the image. When this happens no further processing on the
+* image is needed or often even possible as it may have also been
+* placed behind a firewall when moved.
+*/
+ *p_size = image_size;
+
+ /*
+* Output notification of successful authentication to re-assure the
+* user that the secure code is being processed as expected. However
+* suppress any such log output in case of building for SPL and booting
+* via YMODEM. This is done to avoid disturbing the YMODEM serial
+* protocol transactions.
+*/
+ if (!(IS_ENABLED(CONFIG_SPL_BUILD) &&
+ IS_ENABLED(CONFIG_SPL_YMODEM_SUPPORT) &&
+ spl_boot_device() == BOOT_DEVICE_UART))
+ printf("Authentication passed\n");
+}
--
2.21.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] doing anything about "bad" Kbuild configuration options?
at risk of boring, i'll mention a couple more scripts i have for locating oddities or inconsistencies in the Kbuild structure, which people are welcome to play with. the first is called "find_badref_selects.sh", which specifically locates "select" directives in Kconfig files that are selecting non-existing Kbuild options, which makes them pointless. example (focusing attention on arch/arm directory): $ find_badref_selects.sh arch/arm > CPU_ARM926EJS1 arch/arm/mach-imx/mx2/Kconfig:20: select CPU_ARM926EJS1 > SPL_DISABLE_OF_CONTROL arch/arm/mach-exynos/Kconfig:119: select SPL_DISABLE_OF_CONTROL arch/arm/mach-exynos/Kconfig:153: select SPL_DISABLE_OF_CONTROL $ and a second script called "find_badref_make_configs.sh" specifically finds Kconfig references in Makefiles that point to non-existent Kconfig options. for example: $ find_badref_make_configs.sh drivers/gpio > ADI_GPIO2 ./drivers/gpio/Makefile:obj-$(CONFIG_ADI_GPIO2) += adi_gpio2.o > DB8500_GPIO ./drivers/gpio/Makefile:obj-$(CONFIG_DB8500_GPIO) += db8500_gpio.o > DM644X_GPIO ./drivers/gpio/Makefile:obj-$(CONFIG_DM644X_GPIO) += da8xx_gpio.o $ if anyone's interested, i can post those scripts on a couple more wiki pages this weekend, with an example or two. and on that note, i will shut up about this now. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, 05/11] net: ti: cpsw: Block off ofdata_to_platdata with OF_CONTROL
On Mon, Mar 18, 2019 at 01:54:35PM +0530, Faiz Abbas wrote: > The ofdata_to_platdata function should not be called if OF_CONTROL is > not enabled because fdtdec_* calls will fail. Block the function with > OF_CONTROL > > Signed-off-by: Faiz Abbas Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, 11/11] board: ti: am335x: Remove non DM_ETH code
On Mon, Mar 18, 2019 at 01:54:41PM +0530, Faiz Abbas wrote: > With DM_ETH enabled in am335x devices, remove all the unused > non-DM code. > > Signed-off-by: Faiz Abbas Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, 06/11] net: ti: cpsw: Enable DM_FLAG_PRE_RELOC
On Mon, Mar 18, 2019 at 01:54:36PM +0530, Faiz Abbas wrote: > Add DM_FLAG_PRE_RELOC to make the driver probe in SPL. > > Signed-off-by: Faiz Abbas Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, 3/5] arm: k3: Add support for updating msmc dt node
On Fri, Mar 08, 2019 at 11:47:34AM +0530, Lokesh Vutla wrote: > Certain parts of msmc sram can be used by DMSC or can be > marked as L3 cache. Since the available size can vary, changing > DT every time the size varies might be painful. So, query this > information using TISCI cmd and fixup the DT for kernel. > Fixing up DT does the following: > - Create a sram node if not available > - update the reg property with available size > - update ranges property > - loop through available sub nodes and delete it if: > - mentioned size is out if available range > - subnode represents l3 cache or dmsc usage. > > Signed-off-by: Lokesh Vutla Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, 08/11] configs: am335x_evm: Reduce size of SPL
On Mon, Mar 18, 2019 at 01:54:38PM +0530, Faiz Abbas wrote: > Make some room in SPL by getting rid of unnecessary configs. > > Signed-off-by: Faiz Abbas Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v3, 6/7] k2g: config enable ti phy dp83867 for k2g
On Thu, Feb 21, 2019 at 12:02:06PM -0500, Murali Karicheri wrote: > Enable ti phy dp83867 for k2g > > Signed-off-by: Murali Karicheri > Reviewed-by: Tom Rini > Acked-by: Joe Hershberger Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2, 4/4] configs: ti_omap5_common: Add NAND environment settings
On Wed, Feb 27, 2019 at 01:29:38PM +0530, Faiz Abbas wrote: > Now that NAND is supported on DRA71x include various NAND environment > settings > > Signed-off-by: Faiz Abbas > Reviewed-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] armv7R: K3: am654: Trigger panic on DDR init failures
On Mon, Mar 11, 2019 at 03:15:43PM -0500, Andreas Dannenberg wrote: > When initializing DDR from R5 SPL trigger U-Boot's panic facility > rather than simply returning from the board init function as there > is little point continuing code execution. Further, as panic implies > a board reset, so using it might potentially allow to recover from > this error in certain cases such as when the init failure was caused > by a temporary glitch of some sorts. > > Signed-off-by: Andreas Dannenberg > Reviewed-by: Lokesh Vutla Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2, 3/3] mmc: omap_hsmmc: Set 3.3V for IO voltage
On Fri, Apr 05, 2019 at 02:18:46PM +0530, Faiz Abbas wrote: > Pbias voltage should match the IO voltage set for the SD card. With the > latest pbias change to 3.3V, update the capabilities and IO voltages > settings to 3.3V. > > Signed-off-by: Faiz Abbas Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, V3, 1/2] davinci: da850evm/omapl138-lcdk: Move BSS to SDRAM because SRAM is full
On Mon, Feb 25, 2019 at 09:53:46PM -0600, Adam Ford wrote: > In order to fully support SPL_OF_CONTROL, we need BSS to be a bit > larger. This patch relocates BSS to SDRAM instead of SRAM which > is similar to how ARMv7 boards (like OMAP2+) do it. > > This means two new variables are required: > CONFIG_SPL_BSS_START_ADDR set to DAVINCI_DDR_EMIF_DATA_BASE > CONFIG_SPL_BSS_MAX_SIZE is set to 0x108 which is 1 byte > before the location where U-Boot will load. > > Signed-off-by: Adam Ford Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, 2/5] arm: k3: Add a wrapper to get tisci handle
On Fri, Mar 08, 2019 at 11:47:33AM +0530, Lokesh Vutla wrote: > Create a wrapper to get the ti sci handle. > > Signed-off-by: Lokesh Vutla Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v3, 5/7] ARM: dts: k2g-evm: remove unused phy-mode property from phy node
On Thu, Feb 21, 2019 at 12:02:05PM -0500, Murali Karicheri wrote: > This patch removes the unused phy-mode property from the phy dt node. On > K2G, currently link-interface determines if phy is used or not and is > already set to use rgmii. So this is not needed. Besides phy-mode should > be added to slave interface configuration of the cpsw driver, not in the > phy node. > > Signed-off-by: Murali Karicheri > Acked-by: Joe Hershberger Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot,01/11] net: Add priv_pdata to eth_pdata
On Mon, Mar 18, 2019 at 01:54:31PM +0530, Faiz Abbas wrote: > Add a priv member for eth_pdata for platform specific platform data. > > Signed-off-by: Faiz Abbas Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, 04/11] net: ti: cpsw-common: Isolate getting syscon address from assigning macid
On Mon, Mar 18, 2019 at 01:54:34PM +0530, Faiz Abbas wrote: > ti_cm_get_macid() is used to get a syscon node from the dt, read the > efuse address and then assign the macid read from the address. Divide > these two steps into separate functions one of which can be called from > ofdata_to_platdata() while the other can be called from _probe(). This > ensures that platdata can be assigned statically in a board file when > OF_CONTROL is not enabled. Also add a macid_sel_compat in private data > to get information about the macid byte placement. > > Signed-off-by: Faiz Abbas Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v3, 1/7] ARM: k2g-ice: Add pinmux support for rgmii interface
On Thu, Feb 21, 2019 at 12:02:01PM -0500, Murali Karicheri wrote: > This add pinmux configuration for rgmii interface so that network > driver can be supported on K2G ICE boards. The pinmux configurations > for this are generated using the pinmux tool at > https://dev.ti.com/pinmux/app.html#/default > > As this required some BUFFER_CLASS definitions, same is re-used > from the linux defnitions in include/dt-bindings/pinctrl/keystone.h > > Signed-off-by: Murali Karicheri > Reviewed-by: Lokesh Vutla > Acked-by: Joe Hershberger Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, 09/11] configs: am335x_evm: Add Support for SPL_ETH
On Mon, Mar 18, 2019 at 01:54:39PM +0530, Faiz Abbas wrote: > Add Support for booting from Ethernet. > > Signed-off-by: Faiz Abbas Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, 5/5] configs: am65x_evm_a53: Enable CONFIG_OF_BOARD_SETUP
On Fri, Mar 08, 2019 at 11:47:36AM +0530, Lokesh Vutla wrote: > Enable CONFIG_OF_BOARD_SETUP so that msmc sram dt nodes > are updated correctly. > > Signed-off-by: Lokesh Vutla Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2, 1/3] ARM: dts: dra7: Change pbias voltage to 3.3V
On Fri, Apr 05, 2019 at 02:18:44PM +0530, Faiz Abbas wrote: > As per recent TRM[1], PBIAS cell on dra7 devices supports > 3.3v and not 3.0v as documented earlier. > > Update PBIAS regulator max voltage and the voltage written > in the driver to reflect this. > > [1] http://www.ti.com/lit/pdf/sprui30 > > Signed-off-by: Faiz Abbas Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] ARM: am3517_evm: Add spl_start_uboot for Falcon Mode
On Sun, Mar 31, 2019 at 09:18:29AM -0500, Adam Ford wrote:
> When booting the am3517-evm, the following message appears:
> SPL: Please implement spl_start_uboot() for your board
> SPL: Direct Linux boot not active!
>
> This patch implements spl_start_uboot to clear this message
> and allow device to know if it should boot U-Boot or kernel.
>
> Fixes: 1c6b6f383a41 ("ARM: am3517_evm: Enable Falcon Mode")
>
> Signed-off-by: Adam Ford
>
> diff --git a/board/logicpd/am3517evm/am3517evm.c
> b/board/logicpd/am3517evm/am3517evm.c
> index 6f728398c3..10031a4801 100644
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot,10/11] configs: am335x_evm: Update VCI String
On Mon, Mar 18, 2019 at 01:54:40PM +0530, Faiz Abbas wrote: > Update VCI string to keep it compatible with legacy test setups. > > Signed-off-by: Faiz Abbas > Reviewed-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, 02/11] net: ti: cpsw: Move cpsw_phy_sel() to _probe()
On Mon, Mar 18, 2019 at 01:54:32PM +0530, Faiz Abbas wrote: > cpsw_phy_sel() is a configuration step that should not be in > ofdata_to_platdata(). Add phy_sel_compat to the cpsw_platform_data > structure so that it is accessible in _probe. Then move the call of > cpsw_phy_sel() to _probe. > > Signed-off-by: Faiz Abbas Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, 07/11] board: ti: am335x: Add platdata for cpsw in SPL
On Mon, Mar 18, 2019 at 01:54:37PM +0530, Faiz Abbas wrote: > The SPL image overflows when cpsw dt nodes are added and SPL_OF_CONTROL > is enabled. Use static platdata instead to save space. > > Signed-off-by: Faiz Abbas Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2, 2/4] arm: dra7: Allow NAND to be enabled on DRA71x EVM.
On Wed, Feb 27, 2019 at 01:29:36PM +0530, Faiz Abbas wrote: > From: Franklin S Cooper Jr > > If SW 8 pins 0 and 1 indicate that NAND should be enabled then > the pins pinmux must be reconfigured for NAND mode. > > Therefore, enable NAND by reconfiguring the pinmux. > > Signed-off-by: Franklin S Cooper Jr > Signed-off-by: Faiz Abbas Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v3, 3/7] net: netcp: add support for phy with rgmii ids
On Thu, Feb 21, 2019 at 12:02:03PM -0500, Murali Karicheri wrote: > Enhance the netcp driver to support phys that can be configured > for internal delay (rgmii-id, rgmii-rxid, rgmii-txid) > > Signed-off-by: Murali Karicheri > Acked-by: Joe Hershberger Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] am57xx_evm_defconfig: Enable configs to support QSPI boot
On Fri, Feb 22, 2019 at 11:01:52AM +0530, Vignesh R wrote: > AM57xx IDK EVMs can boot out of QSPI. Enable configs to support QSPI > boot. Also enable configs for updating QSPI boot images over DFU. > > Tested on AM572x IDK EVM. > > Signed-off-by: Vignesh R > Reviewed-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v3, 4/7] ARM: k2g: add a workaround to reset the phy
On Thu, Feb 21, 2019 at 12:02:04PM -0500, Murali Karicheri wrote: > This patch adds a workaround to reset the phy one time during boot > using GPIO0 pin 10 to make sure, the Phy latches the configuration > from the input pins correctly. > > Signed-off-by: Murali Karicheri > Acked-by: Joe Hershberger Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2, 3/4] configs: dra71x-evm: Add Support for NAND
On Wed, Feb 27, 2019 at 01:29:37PM +0530, Faiz Abbas wrote: > Add NAND support to dra71x-evm defconfig > > Signed-off-by: Faiz Abbas Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v3, 05/13] regmap: Add support for polling on a register
On Tue, Feb 12, 2019 at 02:28:11PM +0530, Faiz Abbas wrote: > Add an API to continuously read a register until a condition is > satisfied or a timeout occurs. > > Signed-off-by: Faiz Abbas > Reviewed-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v3, 2/3] env: Don't check CONFIG_ENV_OFFSET_REDUND for SPL build
On Mon, Feb 25, 2019 at 03:32:59PM +, Martyn Welch wrote: > When booting using an SPL on am335x, if we want to support booting with > the boot ROM loader via USB (which uses RNDIS, making bootp and tftp > calls) we need to enable gadget eth in the SPL to load the main U-Boot > image. To enable CONFIG_SPL_ETH_SUPPORT, we must enable > CONFIG_SPL_ENV_SUPPORT as the environment is used by the eth support, but > we don't actually need to have environment variables saved in the SPL > environment. We do however have environment variables saved in the main > U-Boot image and enable CONFIG_ENV_OFFSET_REDUND (we are storing in raw > NAND). In such instances, even with the build config enabling both > CONFIG_CMD_SAVEENV and CONFIG_CMD_NAND, these options aren't set when > building the SPL, but CONFIG_ENV_OFFSET_REDUND still is. > > Don't check this configuration option for SPL builds to enable the above > configuration. > > Signed-off-by: Martyn Welch > Reviewed-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, 1/5] firmware: Add support for querying msmc memory
On Fri, Mar 08, 2019 at 11:47:32AM +0530, Lokesh Vutla wrote: > DMSC can use certain amount of msmc memory available in the > system. Also certain part of msmc memory can be marked as L3 > cache using board config. But users might not know what size > is being used and the remaining available msmc memory. In order > to fix this TISCI protocol provides a messages that can query > the available msmc memory in the system. Add support for this > message. > > Signed-off-by: Lokesh Vutla Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, 03/11] net: ti: cpsw: Convert cpsw_platform_data to a pointer in cpsw_priv
On Mon, Mar 18, 2019 at 01:54:33PM +0530, Faiz Abbas wrote: > Convert cpsw_platform_data to a pointer in cpsw_priv. Allocate it > dynamically and assign it as a part of eth_pdata. This helps in > isolating platform data handling and implementing platdata for SPL > in a board file. > > Signed-off-by: Faiz Abbas Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v3, 12/13] mmc: sdhci: Add support for HOST_CONTROL2 and setting UHS timings
On Tue, Feb 12, 2019 at 02:28:18PM +0530, Faiz Abbas wrote: > From: Faiz Abbas > > The HOST_CONTROL2 register is a part of SDHC v3.00 and not just specific > to arasan/zynq controllers. Add the same to sdhci.h. > > Also create a common API to set UHS timings in HOST_CONTROL2. > > Signed-off-by: Faiz Abbas > Reviewed-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2, 1/4] board: ti: dra71: Add pinmux settings for NAND on DRA71x EVM
On Wed, Feb 27, 2019 at 01:29:35PM +0530, Faiz Abbas wrote: > From: Franklin S Cooper Jr > > By default VOUT3 occupies the pins required for NAND. Therefore, create > a seperate entry that can be use to reconfigure these pins to work for > NAND. > > On the EVM SWITCH 8 pins 0 and 1 will be used to determine if NAND is > enabled or not. For NAND to be selected pin 0 should be on and pin 1 > should be off. Any other combination will assume NAND shouldn't be > enabled. > > Signed-off-by: Franklin S Cooper Jr > Signed-off-by: Faiz Abbas Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v3, 11/13] configs: am65x_evm: Enable CONFIG_REGMAP
On Tue, Feb 12, 2019 at 02:28:17PM +0530, Faiz Abbas wrote: > Add Support for CONFIG_REGMAP. > > Signed-off-by: Faiz Abbas > Reviewed-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, PATCHv2, 1/2] ti: keystone2: Move CONFIG_ISW_ENTRY_ADDR to a common place
On Tue, Mar 19, 2019 at 07:14:37AM -0400, Tom Rini wrote: > The ISW_ENTRY_ADDR Kconfig option under mach-omap2 isn't a SoC specific > notion but rather "where is our previous stage loaded in memory?" > option. Make use of this on ARCH_KEYSTONE rather than SPL_TEXT_BASE for > our HS builds that are not using SPL anyhow. > > Cc: Vitaly Andrianov > Cc: Andrew F. Davis > Cc: Lokesh Vutla > Signed-off-by: Tom Rini > Reviewed-by: Lokesh Vutla signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, V3, 2/2] ARM: davinci: da850evm: Enable SPL_OF_CONTROL without PLATDATA
On Mon, Feb 25, 2019 at 09:53:47PM -0600, Adam Ford wrote: > With the memory mapping giving us some more avialable RAM, this > updates the da850-evm-u-boot.dtsi to include the serial port, SPI > and Flash nodes along with some dependent nodes in the SPL dtb. > This also removes the platform data initialization code for the > serial port and SPI Flash. > > Signed-off-by: Adam Ford Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v3, 10/13] mmc: am654_sdhci: Add Support for PHY
On Tue, Feb 12, 2019 at 02:28:16PM +0530, Faiz Abbas wrote: > Add support in the driver for handling phy specific registers. > > Signed-off-by: Faiz Abbas > Reviewed-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
