8000 Update sunxi_mmc.c by izedgo · Pull Request #5 · u-boot/u-boot · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Update sunxi_mmc.c #5

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 1 commit into from
Closed

Update sunxi_mmc.c #5

wants to merge 1 commit into from

Conversation

izedgo
Copy link
@izedgo izedgo commented Oct 21, 2017

hex -> dec timeout

hex -> dec timeout
trini pushed a commit that referenced this pull request Aug 24, 2018
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>
@bufferoverflow
Copy link
Member

u-boot community does not handle PRs on GitHub, please read https://github.com/u-boot/u-boot/blob/master/README

trini pushed a commit that referenced this pull request Apr 14, 2019
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 le
10000
gend (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>
lokeshvutla pushed a commit to lokeshvutla/u-boot that referenced this pull request Aug 11, 2019
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 u-boot#1 and u-boot#5) are not included. The Main
R5FSS0 Core0 (rproc u-boot#2) is already started by R5 SPL, so is not included
in the list either.

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>
lokeshvutla pushed a commit to lokeshvutla/u-boot that referenced this pull request Aug 12, 2019
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 u-boot#1 and u-boot#5) are not included. The Main
R5FSS0 Core0 (rproc u-boot#2) is already started by R5 SPL, so is not included
in the list either.

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>
lokeshvutla pushed a commit to lokeshvutla/u-boot that referenced this pull request Aug 12, 2019
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 u-boot#1 and u-boot#5) are not included. The Main
R5FSS0 Core0 (rproc u-boot#2) is already started by R5 SPL, so is not included
in the list either.

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>
lokeshvutla pushed a commit to lokeshvutla/u-boot that referenced this pull request Aug 12, 2019
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 u-boot#1 and u-boot#5) are not included. The Main
R5FSS0 Core0 (rproc u-boot#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>
lokeshvutla pushed a commit to lokeshvutla/u-boot that referenced this pull request Aug 13, 2019
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 u-boot#1 and u-boot#5) are not included. The Main
R5FSS0 Core0 (rproc u-boot#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>
lokeshvutla pushed a commit to lokeshvutla/u-boot that referenced this pull request Aug 28, 2019
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 u-boot#1 and u-boot#5) are not included. The Main
R5FSS0 Core0 (rproc u-boot#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>
lokeshvutla pushed a commit to lokeshvutla/u-boot that referenced this pull request Sep 4, 2019
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 u-boot#1 and u-boot#5) are not included. The Main
R5FSS0 Core0 (rproc u-boot#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>
lokeshvutla pushed a commit to lokeshvutla/u-boot that referenced this pull request Oct 7, 2019
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 u-boot#1 and u-boot#5) are not included. The Main
R5FSS0 Core0 (rproc u-boot#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>
trini pushed a commit that referenced this pull request Oct 12, 2019
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>
baruchsiach-travis pushed a commit to baruchsiach-travis/u-boot that referenced this pull request Jan 19, 2020
Clearfog Base carrier uses serdes lane u-boot#5 as USB host. Use EEPROM stored
device identification to configure the serdes accordingly when
available.

Reviewed-by: Stefan Roese <sr@denx.de>
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
trini pushed a commit that referenced this pull request Jan 22, 2020
Clearfog Base carrier uses serdes lane #5 as USB host. Use EEPROM stored
device identification to configure the serdes accordingly when
available.

Reviewed-by: Stefan Roese <sr@denx.de>
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
roman3017 added a commit to roman3017/u-boot that referenced this pull request May 24, 2020
roman3017 added a commit to roman3017/u-boot that referenced this pull request Jul 11, 2020
lokeshvutla pushed a commit to lokeshvutla/u-boot that referenced this pull request Sep 7, 2020
The default rproc list currently used by A72 U-Boot to boot various
remote processors include the Main R5FSS0 (Split-mode) Core1, Main
R5FSS1 (LockStep mode) Core0 and the three DSPs. The Main R5FSS1 cluster
is configured for Split mode by default in the dts now, so add the
Main R5FSS1 Core1 (rproc u-boot#5) to the default rproc boot list. This
core is now booted after the Main R5FSS1 Core0 and before the DSPs.

The order of the rprocs to boot can always be changed at runtime if
desired by overwriting the 'rproc_fw_binaries' environment variable
at U-boot prompt. Note that the R5FSS Core1 cannot be booted before
its associated Core0.

Signed-off-by: Suman Anna <s-anna@ti.com>
lokeshvutla pushed a commit to lokeshvutla/u-boot that referenced this pull request Sep 15, 2020
The default rproc list currently used by A72 U-Boot to boot various
remote processors include the Main R5FSS0 (Split-mode) Core1, Main
R5FSS1 (LockStep mode) Core0 and the three DSPs. The Main R5FSS1 cluster
is configured for Split mode by default in the dts now, so add the
Main R5FSS1 Core1 (rproc u-boot#5) to the default rproc boot list. This
core is now booted after the Main R5FSS1 Core0 and before the DSPs.

The order of the rprocs to boot can always be changed at runtime if
desired by overwriting the 'rproc_fw_binaries' environment variable
at U-boot prompt. Note that the R5FSS Core1 cannot be booted before
its associated Core0.

Signed-off-by: Suman Anna <s-anna@ti.com>
fbertux referenced this pull request in OSSystems/u-boot Sep 29, 2020
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
    u-boot#7 0x4af77c in cmd_process common/command.c:538
    u-boot#8 0x46bafc in run_pipe_real common/cli_hush.c:1677
    u-boot#9 0x46bafc in run_list_real common/cli_hush.c:1875
    u-boot#10 0x46c780 in run_list common/cli_hush.c:2024
    u-boot#11 0x46c780 in parse_stream_outer common/cli_hush.c:3216
    u-boot#12 0x46d34b in parse_file_outer common/cli_hush.c:3299
    u-boot#13 0x4ad609 in cli_loop common/cli.c:217
    u-boot#14 0x4625ae in main_loop common/main.c:65
    u-boot#15 0x46f2d1 in run_main_loop common/board_r.c:648
    u-boot#16 0x640253 in initcall_run_list lib/initcall.c:30
    u-boot#17 0x46f9d0 in board_init_r common/board_r.c:879
    u-boot#18 0x40539b in main arch/sandbox/cpu/start.c:321
    u-boot#19 0x7fa94925f82f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
    u-boot#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>
lbmeng added a commit to lbmeng/u-boot that referenced this pull request Feb 7, 2021
Add a reST document to describe how to build and run U-Boot for
the QEMU ppce500 machine.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>

Series-to: Simon, Alexander Graf <agraf@csgraf.de>, Priyanka Jain <priyanka.jain@nxp.com>
Series-cc: Tom, U-Boot
Cover-letter:
ppc: qemu: Convert qemu-ppce500 to driver model
At present when building qemu-ppce500 the following warnings are seen:

===================== WARNING ======================
This board does not use CONFIG_DM. CONFIG_DM will be
compulsory starting with the v2020.01 release.
Failure to update may result in board removal.
  UPD     include/generated/timestamp_autogenerated.h
See doc/driver-model/migration.rst for more info.
====================================================
===================== WARNING ======================
This board does not use CONFIG_DM_PCI Please update
the board to use CONFIG_DM_PCI before the v2019.07 release.
Failure to update by the deadline may result in board removal.
See doc/driver-model/migration.rst for more info.
====================================================
===================== WARNING ======================
This board does not use CONFIG_DM_ETH (Driver Model
for Ethernet drivers). Please update the board to use
CONFIG_DM_ETH before the v2020.07 release. Failure to
update by the deadline may result in board removal.
See doc/driver-model/m
10000
igration.rst for more info.
====================================================

The conversion of qemu-ppce500 board to driver model is long overdue.

When testing the exisitng qemu-ppce500 support, PCI was found broken.
This is caused by 2 separate issues:

- One issue was caused by U-Boot:
  Commit e002474 ("pci: pci-uclass: Dynamically allocate the PCI regions")
  Patch u-boot#1 reverts this commit as it broken all boards that have not converted
  to driver model PCI.
- One issue was caused by QEMU:
  commit e6b4e5f4795b ("PPC: e500: Move CCSR and MMIO space to upper end of address space")
  commit cb3778a0455a ("PPC: e500 pci host: Add support for ATMUs")
  Patch u-boot#3-4 fixed this issue to keep in sync with latest QEMU upstream

Patch u-boot#5-8 are minor fixes and clean-ups.

Starting from patch#9, these are driver model conversion patches.

Patch u-boot#11-16 are mainly related to CONFIG_ADDR_MAP, a library to support targets
that have non-identity virtual-physical address mappings. A new command 'addrmap'
is introduced to aid debugging, and a fix to arch/powerpc/asm/include/io.h is
made to correct the usage of CONFIG_ADDR_MAP as it can only be used in the post-
relocation phase. Also the initialization of this library is moved a bit earlier
in the post-relocation phase otherwise device drivers won't work.

Patch u-boot#18-20 are 85xx PCI driver fixes. It adds the support to 64-bit bus and cpu
address as current upstream QEMU uses 64-bit cpu address.

Patch u-boot#23 is minor fix to the 'virtio' command dependency.

Patch u-boot#24 enables the VirtIO NET support as by default a VirtIO standard PCI
networking device is connected as an ethernet interface at PCI address 0.1.0.

Patch u-boot#25 moves the qemu-ppce500 boards codes to board/emulation as that is the
place for other QEMU targets like x86, arm, riscv.

Patch u-boot#26 adds a reST document to describe how to build and run U-Boot for the
QEMU ppce500 machine.

I hope we can make this series to U-Boot v2021.04 release.

This series is available at u-boot-x86/qemu-ppc for testing.

This cover letter is cc'ed to QEMU mailing list for a heads-up.
A future patch will be sent to QEMU mailing list to bring its in-tree
U-Boot source codes up-to-date.
END
lbmeng added a commit to lbmeng/u-boot that referenced this pull request Feb 7, 2021
Add a reST document to describe how to build and run U-Boot for
the QEMU ppce500 machine.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>

Series-to: Simon, Alexander Graf <agraf@csgraf.de>, Priyanka Jain <priyanka.jain@nxp.com>
Series-cc: Tom, U-Boot
Cover-letter:
ppc: qemu: Convert qemu-ppce500 to driver model
At present when building qemu-ppce500 the following warnings are seen:

===================== WARNING ======================
This board does not use CONFIG_DM. CONFIG_DM will be
compulsory starting with the v2020.01 release.
Failure to update may result in board removal.
  UPD     include/generated/timestamp_autogenerated.h
See doc/driver-model/migration.rst for more info.
====================================================
===================== WARNING ======================
This board does not use CONFIG_DM_PCI Please update
the board to use CONFIG_DM_PCI before the v2019.07 release.
Failure to update by the deadline may result in board removal.
See doc/driver-model/migration.rst for more info.
====================================================
===================== WARNING ======================
This board does not use CONFIG_DM_ETH (Driver Model
for Ethernet drivers). Please update the board to use
CONFIG_DM_ETH before the v2020.07 release. Failure to
update by the deadline may result in board removal.
See doc/driver-model/migration.rst for more info.
====================================================

The conversion of qemu-ppce500 board to driver model is long overdue.

When testing the exisitng qemu-ppce500 support, PCI was found broken.
This is caused by 2 separate issues:

- One issue was caused by U-Boot:
  Commit e002474 ("pci: pci-uclass: Dynamically allocate the PCI regions")
  Patch u-boot#1 reverts this commit as it broken all boards that have not converted
  to driver model PCI.
- One issue was caused by QEMU:
  commit e6b4e5f4795b ("PPC: e500: Move CCSR and MMIO space to upper end of address space")
  commit cb3778a0455a ("PPC: e500 pci host: Add support for ATMUs")
  Patch u-boot#3-4 fixed this issue to keep in sync with latest QEMU upstream

Patch u-boot#5-8 are minor fixes and clean-ups.

Starting from patch#9, these are driver model conversion patches.

Patch u-boot#11-16 are mainly related to CONFIG_ADDR_MAP, a library to support targets
that have non-identity virtual-physical address mappings. A new command 'addrmap'
is introduced to aid debugging, and a fix to arch/powerpc/asm/include/io.h is
made to correct the usage of CONFIG_ADDR_MAP as it can only be used in the post-
relocation phase. Also the initialization of this library is moved a bit earlier
in the post-relocation phase otherwise device drivers won't work.

Patch u-boot#18-20 are 85xx PCI driver fixes. It adds support to controller register
physical address beyond 32-bit, as well as support to 64-bit bus and cpu address
as current upstream QEMU uses 64-bit cpu address.

Patch u-boot#23 is minor fix to the 'virtio' command dependency.

Patch u-boot#24 enables the VirtIO NET support as by default a VirtIO standard PCI
networking device is connected as an ethernet interface at PCI address 0.1.0.

Patch u-boot#25 moves the qemu-ppce500 boards codes to board/emulation as that is the
place for other QEMU targets like x86, arm, riscv.

Patch u-boot#26 adds a reST document to describe how to build and run U-Boot for the
QEMU ppce500 machine.

I hope we can make this series to U-Boot v2021.04 release.

This series is available at u-boot-x86/qemu-ppc for testing.

This cover letter is cc'ed to QEMU mailing list for a heads-up.
A future patch will be sent to QEMU mailing list to bring its in-tree
U-Boot source codes up-to-date.
END
shenki pushed a commit to shenki/u-boot that referenced this pull request Feb 11, 2021
Fix ast2500 spl
During SPL boot, the SPI calibration had been finished, so skip the SPI calibration again during u-boot
lbmeng added a commit to lbmeng/u-boot that referenced this pull request Feb 18, 2021
Add a reST document to describe how to build and run U-Boot for
the QEMU ppce500 machine.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

Series-version: 2
Series-changes: 2
- add descriptions for VirtIO BLK, RTC and power off

Series-to: Simon, Alexander Graf <agraf@csgraf.de>, Priyanka Jain <priyanka.jain@nxp.com>
Series-cc: Tom, U-Boot
Cover-letter:
ppc: qemu: Convert qemu-ppce500 to driver model and enable additional driver support
At present when building qemu-ppce500 the following warnings are seen:

===================== WARNING ======================
This board does not use CONFIG_DM. CONFIG_DM will be
compulsory starting with the v2020.01 release.
Failure to update may result in board removal.
  UPD     include/generated/timestamp_autogenerated.h
See doc/driver-model/migration.rst for more info.
====================================================
===================== WARNING ======================
This board does not use CONFIG_DM_PCI Please update
the board to use CONFIG_DM_PCI before the v2019.07 release.
Failure to update by the deadline may result in board removal.
See doc/driver-model/migration.rst for more info.
====================================================
===================== WARNING ======================
This board does not use CONFIG_DM_ETH (Driver Model
for Ethernet drivers). Please update the board to use
CONFIG_DM_ETH before the v2020.07 release. Failure to
update by the deadline may result in board removal.
See doc/driver-model/migration.rst for more info.
====================================================

The conversion of qemu-ppce500 board to driver model is long overdue.

When testing the exisitng qemu-ppce500 support, PCI was found broken.
This is caused by 2 separate issues:

- One issue was caused by U-Boot:
  Commit e002474 ("pci: pci-uclass: Dynamically allocate the PCI regions")
  Patch u-boot#1 updated the non-DM fsl_pci_init driver to dynamically allocate the
  PCI regions, to keep in sync with the pci uclass driver
- One issue was caused by QEMU:
  commit e6b4e5f4795b ("PPC: e500: Move CCSR and MMIO space to upper end of address space")
  commit cb3778a0455a ("PPC: e500 pci host: Add support for ATMUs")
  Patch u-boot#3-4 fixed this issue to keep in sync with latest QEMU upstream

Patch u-boot#5-8, u-boot#34-36 are minor fixes and clean-ups.

Starting from patch#9, these are driver model conversion patches.

Patch u-boot#11-17 are mainly related to CONFIG_ADDR_MAP, a library to support targets
that have non-identity virtual-physical address mappings. A new command 'addrmap'
is introduced to aid debugging, and a fix to arch/powerpc/asm/include/io.h is
made to correct the usage of CONFIG_ADDR_MAP as it can only be used in the post-
relocation phase. Also the initialization of this library is moved a bit earlier
in the post-relocation phase otherwise device drivers won't work.

Patch u-boot#19-21 are 85xx PCI driver fixes. It adds support to controller register
physical address beyond 32-bit, as well as support to 64-bit bus and cpu address
as current upstream QEMU uses 64-bit cpu address.

Starting from patch#24, these are additional driver support patches.

Patch u-boot#24, u-boot#26 are minor fix to the 'virtio' command and BLK driver dependency.

Patch u-boot#25 enables the VirtIO NET support as by default a VirtIO standard PCI
networking device is connected as an ethernet interface at PCI address 0.1.0.

Patch u-boot#27 enables the VirtIO BLK driver support.

Patch u-boot#28-30 enables the GPIO support.

Patch u-boot#31-32 enables poweroff via GPIO.

Patch u-boot#33 enables RTC over the I2C bus.

Patch u-boot#37 moves the qemu-ppce500 boards codes to board/emulation as that is the
place for other QEMU targets like x86, arm, riscv.

Patch u-boot#38 adds a reST document to describe how to build and run U-Boot for the
QEMU ppce500 machine.

I hope we can make this series to U-Boot v2021.04 release.

This series is available at u-boot-x86/qemu-ppc for testing.

This cover letter is cc'ed to QEMU mailing list for a heads-up.
A future patch will be sent to QEMU mailing list to bring its in-tree
U-Boot source codes up-to-date.
END
lbmeng added a commit to lbmeng/u-boot that referenced this pull request Feb 25, 2021
Add a reST document to describe how to build and run U-Boot for
the QEMU ppce500 machine.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>

Series-version: 3
Series-changes: 3
- rebase on top of u-boot/master

Series-changes: 2
- add descriptions for VirtIO BLK, RTC and power off

Series-to: Simon, Alexander Graf <agraf@csgraf.de>, Priyanka Jain <priyanka.jain@nxp.com>
Series-cc: Tom, U-Boot
Cover-letter:
ppc: qemu: Convert qemu-ppce500 to driver model and enable additional driver support
At present when building qemu-ppce500 the following warnings are seen:

===================== WARNING ======================
This board does not use CONFIG_DM. CONFIG_DM will be
compulsory starting with the v2020.01 release.
Failure to update may result in board removal.
  UPD     include/generated/timestamp_autogenerated.h
See doc/driver-model/migration.rst for more info.
====================================================
===================== WARNING ======================
This board does not use CONFIG_DM_PCI Please update
the board to use CONFIG_DM_PCI before the v2019.07 release.
Failure to update by the deadline may result in board removal.
See doc/driver-model/migration.rst for more info.
====================================================
===================== WARNING ======================
This board does not use CONFIG_DM_ETH (Driver Model
for Ethernet drivers). Please update the board to use
CONFIG_DM_ETH before the v2020.07 release. Failure to
update by the deadline may result in board removal.
See doc/driver-model/migration.rst for more info.
====================================================

The conversion of qemu-ppce500 board to driver model is long overdue.

When testing the exisitng qemu-ppce500 support, PCI was found broken.
This is caused by 2 separate issues:

- One issue was caused by U-Boot:
  Commit e002474 ("pci: pci-uclass: Dynamically allocate the PCI regions")
  Patch u-boot#1 updated the non-DM fsl_pci_init driver to dynamically allocate the
  PCI regions, to keep in sync with the pci uclass driver
- One issue was caused by QEMU:
  commit e6b4e5f4795b ("PPC: e500: Move CCSR and MMIO space to upper end of address space")
  commit cb3778a0455a ("PPC: e500 pci host: Add support for ATMUs")
  Patch u-boot#3-4 fixed this issue to keep in sync with latest QEMU upstream

Patch u-boot#5-8, u-boot#34-36 are minor fixes and clean-ups.

Starting from patch#9, these are driver model conversion patches.

Patch u-boot#11-17 are mainly related to CONFIG_ADDR_MAP, a library to support targets
that have non-identity virtual-physical address mappings. A new command 'addrmap'
is introduced to aid debugging, and a fix to arch/powerpc/asm/include/io.h is
made to correct the usage of CONFIG_ADDR_MAP as it can only be used in the post-
relocation phase. Also the initialization of this library is moved a bit earlier
in the post-relocation phase otherwise device drivers won't work.

Patch u-boot#19-21 are 85xx PCI driver fixes. It adds support to controller register
physical address beyond 32-bit, as well as support to 64-bit bus and cpu address
as current upstream QEMU uses 64-bit cpu address.

Starting from patch#24, these are additional driver support patches.

Patch u-boot#24, u-boot#26 are minor fix to the 'virtio' command and BLK driver dependency.

Patch u-boot#25 enables the VirtIO NET support as by default a VirtIO standard PCI
networking device is connected as an ethernet interface at PCI address 0.1.0.

Patch u-boot#27 enables the VirtIO BLK driver support.

Patch u-boot#28-30 enables the GPIO support.

Patch u-boot#31-32 enables poweroff via GPIO.

Patch u-boot#33 enables RTC over the I2C bus.

Patch u-boot#37 moves the qemu-ppce500 boards codes to board/emulation as that is the
place for other QEMU targets like x86, arm, riscv.

Patch u-boot#38 adds a reST document to describe how to build and run U-Boot for the
QEMU ppce500 machine.

I hope we can make this series to U-Boot v2021.04 release.

This series is available at u-boot-x86/qemu-ppc for testing.

This cover letter is cc'ed to QEMU mailing list for a heads-up.
A future patch will be sent to QEMU mailing list to bring its in-tree
U-Boot source codes up-to-date.
END
svenschwermer added a commit to svenschwermer/u-boot that referenced this pull request Feb 9, 2022
Ccon centauri

Approved-by: Fredrik Flornes Ellertsen
samueldr pushed a commit to samueldr/u-boot that referenced this pull request Mar 27, 2023
Call trace:
 PC:   [< 00a7b36c >]  printch+0x3c/0x68      /home4/cjh/uboot-nextdev/drivers/serial/ns16550.c:280
 LR:   [< 00a247e4 >]  puts+0x1c/0x30      /home4/cjh/uboot-nextdev/common/console.c:592

Stack:
       [< 00a7b36c >]  printch+0x3c/0x68
       [< 00ab337c >]  printf+0x90/0xb4
       [< 00a036e4 >]  rk_board_fdt_fixup+0x30/0x1a8
       [< 00a01f10 >]  arch_fixup_fdt+0xc/0x94
       [< 00a2aa28 >]  image_setup_libfdt+0x14/0x114
       [< 00a26d1c >]  image_setup_linux+0x4c/0x6c
       ......

 PC Surrounding Instructions:
  a7b358:       528001a2        mov     w2, #0xd                        // u-boot#13
  a7b35c:       b9000022        str     w2, [x1]
  a7b360:       b4000192        cbz     x18, a7b390 <printch+0x60>
  a7b364:       f9400642        ldr     x2, [x18,u-boot#8]
  a7b368:       373000e2        tbnz    w2, u-boot#6, a7b384 <printch+0x54>
  a7b36c:       f940d242        ldr     x2, [x18,u-boot#416]
  a7b370:       b4000102        cbz     x2, a7b390 <printch+0x60>
  a7b374:       f940d241        ldr     x1, [x18,u-boot#416]
  a7b378:       b9401422        ldr     w2, [x1,u-boot#20]
  a7b37c:       362fffe2        tbz     w2, u-boot#5, a7b378 <printch+0x48>
  a7b380:       b9000020        str     w0, [x1]

Signed-off-by: Joseph Chen <chenjh@rock-chips.com>
Change-Id: I48391165094708dd86eeeabea09739a4c14fcf6f
cesar-pa pushed a commit to lunar-energy/u-boot that referenced this pull request Oct 4, 2023
The following changes have been made to be able to support
root filesystem rollback on boot failure:

- create new separate ti/lunar_hc board definition.
- revert all changes to existing ti/am335x evm board code.
- pass the boot device type (SD or eMMC) from the SPL to 'full' U-Boot.
- re-write bootscripts from scratch.
- enable 'bootlimit' to trigger alternate boot after 2 failed
  boot attempts.
- enable the 'bootretry' timeout (60s) to avoid sitting at the U-Boot
  prompt indefinitely.

Signed-off-by: Mark Corbin <mark.corbin@moixa.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants
0