dfu: add optional timeout #7
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
As far as I understood you took the original patch and slightly adopted it. There are at least the following issues with that:
So, please update and resend. |
When the `dfu` command is called from the U-Boot environment, it now accepts an optional fourth parameter that specifies a timeout (in seconds). If a DFU connection is not made within that time the dfu command exits (as it would if ctrl+c was pressed). If the timeout is left empty the dfu command behaves as it does now. This is useful for allowing U-Boot to check to see if anything wants to upload new firmware before continuing to boot. This option is not compatible with the dfu "list" command. If "list" is specified that command takes priority. This patch is based on commit 5e966ccc3c65c18c9783741fa04e0c45e021780c from intel/edison-u-boot@5e966cc It updates that patch to the newer changes of u-boot which split the DFU functionality into multiple functions. Signed-off-by: Sebastien Colleur <sebastienx.colleur@intel.com> Signed-off-by: Brad Campbell <bradjc5@gmail.com>
|
I updated things with I think what you asked. Let me know if there is anything else. |
andy-shev
pushed a commit
that referenced
this pull request
Jul 31, 2017
It was observed that on Intel MinnowMax board, when xHCI is enabled in the BayTrail SoC, with a USB 3.0 device connected to the bottom USB 3.0 port (mapped to xHCI root port #7), its PORTSC register is always 0x201203 (CCS = 1, CSC = 0). The root cause of such behavior is unknown yet. Connect status change bit is set on the same port with a USB 2.0 device (mapped to xHCI port #1, which is a different port on the root hub). With current logic in usb_scan_port(), the enumeration process will abort if it does not detect a connect status change on a hub port. However since a device connection status is correctly reported, the enumeration process can still continue. With this change, USB device connected to the bottom blue port on MinnowMax board can be enumerated under either SS or HS mode. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Stefan Roese <sr@denx.de> Tested-by: Stefan Roese <sr@denx.de> Tested-by: Dinh Nguyen <dinguyen@kernel.org>
staroselskii
pushed a commit
to staroselskii/u-boot
that referenced
this pull request
Sep 1, 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
andy-shev#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
andy-shev#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
andy-shev#12 0x46d34b in parse_file_outer common/cli_hush.c:3299
andy-shev#13 0x4ad609 in cli_loop common/cli.c:217
andy-shev#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>
andy-shev
pushed a commit
that referenced
this pull request
Apr 30, 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 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>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When the
dfucommand is called from the U-Boot environment, it now accepts an optional fourth parameter that specifies a timeout (in seconds). If a DFU connection is not made within that time the dfucommand exits (as it would if ctrl+c was pressed). If the timeout is left empty the dfu command behaves as it does now.
This is useful for allowing U-Boot to check to see if anything wants to upload new firmware before continuing to boot.
This options is not compatible with the dfu "list" command. If "list" is specified that command takes priority.