Add Pine64 patches from apritzel/u-boot #2

Vogtinator · 2016-10-05T16:33:28Z

I'm currently working on getting the pine64 upstream images up-to-date and the newest ATF requires a much newer u-boot. The Pine64 is supported by v2016.09.01 in u-boot, but these patches are nice to have. With this in place, u-boot-pine64(plus) can be a _link to u-boot in OBS instead of a hacked together package.
I'm not sure whether tumbleweed-staging is the right place, maybe a new branch is a good idea until those patches have been merged.

The SPL and U-Boot proper may use different initial stack locations, which are configured via CONFIG_SPL_STACK and CONFIG_SYS_INIT_SP_ADDR defines. The lowlevel_init.S code needs to handle this in the same way as crt0.S Without this fix, setting the U-Boot stack location to some place, which is not safely accessible by the SPL (such as the DRAM), causes a very early SPL deadlock. Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>

Compiling the SPL in aarch64 for the Allwinner A64 yields a bigger code size, which lets the lowlevel stack run into the end of the code. Now with CONFIG_SPL_STACK properly honoured, let's move the initial stack into the SRAM A2 on the A64. The other SoCs stay at the end of SRAM A1, but the A80 can use the full 40K of it. Signed-off-by: Andre Przywara <andre.przywara@arm.com>

These days many Allwinner SoCs use clock_sun6i.c, although out of them only the (original sun6i) A31 has a second MBUS clock register. Also setting up the PRCM PLL_CTLR1 register to provide the proper voltage seems to be an A31-only feature as well. So restrict the initialization to this SoC only to avoid writing bogus values to (undefined) registers in other chips. Signed-off-by: Andre Przywara <andre.przywara@arm.com>

agraf · 2017-02-07T12:22:05Z

This should be deprecated by now, since we have updated U-boot, right?

Vogtinator · 2017-02-07T13:58:03Z

Yup, upstream u-boot includes these (or equivalent) now

Strings read from devices may sometimes fail to be NULL-terminated. The functions in lib/string.c are subject to failure in this case. Protect against observed failures in set_gpt_info() by switching to length-checking variants with a length limit of the maximum possible partition table length. At the same time, add a few checks for NULL string pointers. Here is an example as observed in sandbox under GDB: => gpt verify host 0 $partitions Program received signal SIGSEGV, Segmentation fault. 0x0000000000477747 in strlen (s=0x0) at lib/string.c:267 267 for (sc = s; *sc != '\0'; ++sc) (gdb) bt #0 0x0000000000477747 in strlen (s=0x0) at lib/string.c:267 #1 0x00000000004140b2 in set_gpt_info (str_part=<optimized out>, str_disk_guid=str_disk_guid@entry=0x7fffffffdbe8, partitions=partitions@entry=0x7fffffffdbd8, parts_count=parts_count@entry=0x7fffffffdbcf "", dev_desc=<optimized out>) at cmd/gpt.c:415 #2 0x00000000004145b9 in gpt_verify (str_part=<optimized out>, blk_dev_desc=0x7fffef09a9d0) at cmd/gpt.c:580 #3 do_gpt (cmdtp=<optimized out>, flag=<optimized out>, argc=<optimized out>, argv=0x7fffef09a8f0) at cmd/gpt.c:783 #4 0x00000000004295b0 in cmd_call (argv=0x7fffef09a8f0, argc=0x5, flag=<optimized out>, cmdtp=0x714e20 <_u_boot_list_2_cmd_2_gpt>) at common/command.c:500 #5 cmd_process (flag=<optimized out>, argc=0x5, argv=0x7fffef09a8f0, repeatable=repeatable@entry=0x726c04 <flag_repeat>, ticks=ticks@entry=0x0) at common/command.c:539 Suggested-by: Lothar Waßmann <LW@karo-electronics.de> Signed-off-by: Alison Chaiken <alison@peloton-tech.com>

Adding CONFIG_WARP7_ROOT_PART allows a defconfig to specify which partition is use as the root partition on WaRP7, this is a desirable change in order to support a different partitioning schemes. The default is the current partition #2. Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Tested-by: Breno Lima <breno.lima@nxp.com> Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>

Commit 5d8fae7 ("dfu: avoid memory leak") brings a regression which described below. This patch is effectively reverting that commit, adding corresponding comment to avoid such regressions in future. In case of error in dfu_config_entities(), it frees "dfu" array, which leads to "data abort" in dfu_free_entities(), which tries to free the same array (and even tries to access it from linked list first). The issue occurs e.g. when partition table on device does not match $dfu_alt_info layout: => dfu 0 mmc 1 Couldn't find part #2 on mmc device #1 DFU entities configuration failed! data abort To fix this issue, do not free "dfu" array in dfu_config_entities(). It will be freed later in dfu_free_entities(). Tested on BeagleBone Black (where this regression was originally found). Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>

Compiling U-Boot with ubsan/asan libraries and running it in sandbox may lead to below backtrace: => avb init 0 => avb verify ## Android Verified Boot 2.0 version 1.1.0 read_is_device_unlocked not supported yet common/avb_verify.c:407:31: runtime error: division by zero AddressSanitizer:DEADLYSIGNAL Reviewed-by: Igor Opaniuk <igor.opaniuk@linaro.org> ================================================================= ==9388==ERROR: AddressSanitizer: FPE on unknown address 0x0000004b467f \ (pc 0x0000004b467f bp 0x000000000000 sp 0x7ffd899fe150 T0) #0 0x4b467e in mmc_byte_io common/avb_verify.c:407 #1 0x4b4c47 in mmc_byte_io common/avb_verify.c:532 #2 0x4b4c47 in read_from_partition common/avb_verify.c:533 #3 0x69dc0d in load_and_verify_vbmeta lib/libavb/avb_slot_verify.c:560 #4 0x6a1ee6 in avb_slot_verify lib/libavb/avb_slot_verify.c:1139 #5 0x45dabd in do_avb_verify_part cmd/avb.c:245 #6 0x4af77c in cmd_call common/command.c:499 #7 0x4af77c in cmd_process common/command.c:538 #8 0x46bafc in run_pipe_real common/cli_hush.c:1677 #9 0x46bafc in run_list_real common/cli_hush.c:1875 #10 0x46c780 in run_list common/cli_hush.c:2024 #11 0x46c780 in parse_stream_outer common/cli_hush.c:3216 #12 0x46d34b in parse_file_outer common/cli_hush.c:3299 #13 0x4ad609 in cli_loop common/cli.c:217 #14 0x4625ae in main_loop common/main.c:65 #15 0x46f2d1 in run_main_loop common/board_r.c:648 #16 0x640253 in initcall_run_list lib/initcall.c:30 #17 0x46f9d0 in board_init_r common/board_r.c:879 #18 0x40539b in main arch/sandbox/cpu/start.c:321 #19 0x7fa94925f82f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f) #20 0x408908 in _start (/srv/R/u-boot-master/u-boot+0x408908) AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: FPE common/avb_verify.c:407 in mmc_byte_io ==9388==ABORTING Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com>

This is required to enable the USB port #2 in SPL when DM_USB is used. Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>

The console is actually serial #2. When we would like to enable other ports, this would be not okay to mess up with the ordering. Thus, fix the number of default console interface to be 2. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>

v2019.04-rc3 sandbox U-Boot fails to boot when compiled with -fsanitize=address and linked against -lasan, reporting [1]. Git bisecting shows that the issue is contributed by v2019.01 commit 1678754 ("core: ofnode: Fix ofnode_get_addr_index function"). The root cause seems to be the mismatch between sizeof(u64) and sizeof(fdt_size_t) on sandbox. Luckily, thanks to the fact that the size argument of both of_get_address() and fdtdec_get_addr_size_fixed() is optional, we can pass NULL in its place, avoiding the problem. [1] Backtrace reported by ASAN (gcc 8.1.0): $> ./u-boot -d arch/sandbox/dts/sandbox.dtb [..] Reviewed-by: Simon Glass <sjg@chromium.org> ================================================================= ==10998==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffcc2331140 at pc 0x0000004eeeb0 bp 0x7ffcc2330f80 sp 0x7ffcc2330f70 WRITE of size 8 at 0x7ffcc2331140 thread T0 #0 0x4eeeaf in of_get_address drivers/core/of_addr.c:154 #1 0x4f7441 in ofnode_get_addr_index drivers/core/ofnode.c:263 #2 0x5b2a78 in sb_eth_ofdata_to_platdata drivers/net/sandbox.c:422 #3 0x4dccd8 in device_probe drivers/core/device.c:407 #4 0x753170 in eth_initialize net/eth-uclass.c:428 #5 0x47d9bf in initr_net common/board_r.c:557 #6 0x6bcfa7 in initcall_run_list lib/initcall.c:30 #7 0x47e1fe in board_init_r common/board_r.c:859 #8 0x4060e5 in main arch/sandbox/cpu/start.c:356 #9 0x7fb8d135482f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f) #10 0x40a3a8 in _start (/path/to/u-boot/u-boot+0x40a3a8) Address 0x7ffcc2331140 is located in stack of thread T0 at offset 32 in frame #0 0x4f72b8 in ofnode_get_addr_index drivers/core/ofnode.c:255 This frame has 3 object(s): [32, 36) 'size' <== Memory access at offset 32 partially overflows this variable [96, 100) 'flags' [160, 168) 'node' HINT: this may be a false positive if your program uses some custom stack unwind mechanism or swapcontext (longjmp and C++ exceptions *are* supported) SUMMARY: AddressSanitizer: stack-buffer-overflow drivers/core/of_addr.c:154 in of_get_address Shadow bytes around the buggy address: 0x10001845e1d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x10001845e1e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x10001845e1f0: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1 0x10001845e200: 04 f2 f2 f2 f2 f2 f2 f2 04 f2 f2 f2 f2 f2 f2 f2 0x10001845e210: 04 f2 f2 f2 f3 f3 f3 f3 00 00 00 00 00 00 00 00 =>0x10001845e220: 00 00 00 00 f1 f1 f1 f1[04]f2 f2 f2 f2 f2 f2 f2 0x10001845e230: 04 f2 f2 f2 f2 f2 f2 f2 00 f2 f2 f2 f3 f3 f3 f3 0x10001845e240: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x10001845e250: 00 00 00 00 f1 f1 f1 f1 00 00 f2 f2 f3 f3 f3 f3 0x10001845e260: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 0x10001845e270: f1 f1 00 f2 f2 f2 f3 f3 f3 f3 00 00 00 00 00 00 Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb ==10998==ABORTING 'To' list: git log --since=1year drivers/core/ofnode.c | grep "\-by: .*@" | \ sed 's/.*-by: //' | sort | uniq -c | sort -rn 10 Simon Glass <sjg@chromium.org> 3 Mario Six <mario.six@gdsys.cc> 2 Martin Fuzzey <mfuzzey@parkeon.com> 2 Marek Vasut <marek.vasut+renesas@gmail.com> 1 Tom Rini <trini@konsulko.com> 1 Masahiro Yamada <yamada.masahiro@socionext.com> 1 Keerthy <j-keerthy@ti.com> 1 Jens Wiklander <jens.wiklander@linaro.org> 1 Bin Meng <bmeng.cn@gmail.com> Fixes: 1678754 ("core: ofnode: Fix ofnode_get_addr_index function") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com>

Add support to boot some remoteprocs at U-boot prompt on the J721E EVM boards by using the 'boot_rprocs' and other env variables defined in the common environment file k3_rproc.h, and updating the 'DEFAULT_RPROCS' macro. The list of R5F cores to be started before loading and booting the Linux kernel are as follows, and in this order: Main R5FSS0 (Split) Core1 : 3 /lib/firmware/j7-main-r5f0_1-fw Main R5FSS1 (LockStep) : 4 /lib/firmware/j7-main-r5f1_0-fw The MCU R5FSS0 and Main R5FSS1 are currently in LockStep mode, so the equivalent Core1 rprocs (rproc #1 and #5) are not included. The Main R5FSS0 Core0 (rproc #2) is already started by R5 SPL, so is not included in the list either. The DSP cores are started in the following order before loading and booting the Linux kernel: C66_0: 6 /lib/firmware/j7-c66_0-fw C66_1: 7 /lib/firmware/j7-c66_1-fw C71_0: 8 /lib/firmware/j7-c71_0-fw The order of the rprocs to boot can be changed at runtime if desired by overwriting the 'rproc_fw_binaries' environment variable at U-boot prompt. Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com> Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>

After updating libavb to most recent version from AOSP/master, two new warnings appear: Warning #1: lib/libavb/avb_cmdline.c: In function 'avb_append_options': lib/libavb/avb_cmdline.c:365:15: warning: 'dm_verity_mode' may be used uninitialized in this function [-Wmaybe-uninitialized] new_ret = avb_replace( ^~~~~~~~~~~~ slot_data->cmdline, "$(ANDROID_VERITY_MODE)", dm_verity_mode); ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ lib/libavb/avb_cmdline.c:374:8: warning: 'verity_mode' may be used uninitialized in this function [-Wmaybe-uninitialized] if (!cmdline_append_option( ^~~~~~~~~~~~~~~~~~~~~~ slot_data, "androidboot.veritymode", verity_mode)) { ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Warning #2: lib/libavb/avb_slot_verify.c: In function 'avb_slot_verify': lib/libavb/avb_slot_verify.c:1349:23: warning: 'ret' may be used uninitialized in this function [-Wmaybe-uninitialized] AvbSlotVerifyResult ret; ^~~ Fix those by providing default return values to affected functions. Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>