8000 [bcm283x] Fix typo in mailbox constant by berkus · Pull Request #9 · u-boot/u-boot · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

[bcm283x] Fix typo in mailbox constant #9

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

Conversation

berkus
Copy link
Contributor
@berkus berkus commented Feb 3, 2018

No description provided.

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

@berkus
Copy link
Contributor Author
berkus commented Dec 13, 2018

I'm definitely not sending anything to mailing lists. You can live with invalid constants if you want.

@bufferoverflow
Copy link
Member

¯\_(ツ)_/¯

@trini
Copy link
Contributor
trini commented Dec 14, 2018

@berkus can I ask why? We indeed haven't been clear enough previously that github PRs aren't how we work (I wish we could remove the feature from the repository).

@berkus
Copy link
Contributor Author
berkus commented Dec 16, 2018

@trini Because mailing lists are very inconvenient compared to github PRs, require special formatting, special mailing program setup and other unhandy operations. Even a simple discussion of the PR turns into "sign up to a mailing list, dig through a number of intertwined, overquoted mail messages in a very clunky interface" etc. GH PRs are designed to be easy to interact with, part of the same convenient interface, good history and visibility (not only to people who are signed up to mailing list somewhere).

@trini
Copy link
Contributor
trini commented Dec 27, 2018

Thanks for explaining your feelings on this @berkus. I'm tagging @agraf as he's the Pi custodian and might be interested in picking up your work at least.

@berkus
Copy link
Contributor Author
berkus commented Dec 28, 2018

Thanks, I'm sure @agraf can change one little constant value without extra hassle. Can always refer to my branch for the details.

@agraf
Copy link
Contributor
agraf commented Jan 10, 2019

Sure :). @berkus, could you please give me some references where the correct constant is defined in the patch description and end the commit message with a Signed-off-by line?

That way I can take the patch as you sent it, put it on the ML and apply it from there if nobody complains within a few days. That should give us the best of both work flows (github vs ML).

@berkus
Copy link
Contributor Author
berkus commented Jan 13, 2019

@agraf Sure, will update right here.

@berkus
Copy link
Contributor Author
berkus commented Jan 13, 2019

@agraf it's here berkus@b26467c

@agraf
Copy link
Contributor
agraf commented Jan 13, 2019

Thanks, I sent it out as mail to the ML to give others a chance to review as well. Once that process is through, I'll pull it into the rpi queue which will then land in U-Boot proper.

Thanks a lot for the patch!

@berkus
Copy link
Contributor Author
berkus commented Jan 14, 2019

🙇 Thank you!

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 i
8000
n __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>
fbertux pushed a commit to OSSystems/u-boot that referenced this pull request 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>
charkear pushed a commit to HewlettPackard/gxp-uboot that referenced this pull request Jun 28, 2023
RadxaNaoki pushed a commit to RadxaNaoki/u-boot that referenced this pull request Jan 14, 2025
Raymond Mao <raymond.mao@linaro.org> says:

Motivations for changes:
Current SMBIOS library and command-line tool is not fully matching with
the requirements:
1. Missing support for other mandatory types (u-boot#7, u-boot#9, u-boot#16, u-boot#17, u-boot#19).
2. Only a few platforms support SMBIOS node from the device tree.
3. Values of some fields are hardcoded in the library other than fetching
   from the device hardware.
4. Embedded data with dynamic length is not supported (E.g. Contained
   Object Handles in Type u-boot#2 and Contained Elements in Type u-boot#3)

Changes:
1. Refactor the SMBIOS library and command-line tool to better align with
   the SMBIOS spec.
2. Create an arch-specific driver for all aarch64-based platforms to fetch
   SMBIOS private data fr
8000
om the device hardware (processor and cache).
3. Create a sysinfo driver to poppulate platform SMBIOS private data.
4. Add generic SMBIOS DTS file for arm64 platforms for those common strings
   and values which cannot be retrieved from the system registers.
   Vendors can create their own SMBIOS node using this as an example.
   For those boards without SMBIOS nodes, this DTS file can be included to
   have a generic SMBIOS information of the system.
5. Add support for Type u-boot#7 (Cache Information) and link its handles to
   Type u-boot#4.
6. To minimize size-growth for those platforms which have not sufficient
   ROM spaces or the platforms which don't need detailed SMBIOS
   information, new added fields are only being built when kconfig
   GENERATE_SMBIOS_TABLE_VERBOSE is selected.

Once this patch is acceptted, subsequent patch sets will add other missing
types (u-boot#9, u-boot#16, u-boot#17, u-boot#19).

Tests:
To test this with QEMU arm64, please follow the guide on dt_qemu.rst to
get a merged DT to run with.
```
qemu-system-aarch64 -machine virt -machine dumpdtb=qemu.dtb
cat  <(dtc -I dtb qemu.dtb) <(dtc -I dtb ./dts/dt.dtb | grep -v /dts-v1/) \
  | dtc - -o merged.dtb
qemu-system-aarch64 -machine virt -nographic -bios u-boot.bin \
  -dtb merged.dtb
```

Link: https://lore.kernel.org/r/20241206225438.13866-1-raymond.mao@linaro.org
trini added a commit that referenced this pull request Jan 14, 2025
Raymond Mao <raymond.mao@linaro.org> says:

Motivations for changes:
Current SMBIOS library and command-line tool is not fully matching with
the requirements:
1. Missing support for other mandatory types (#7, #9, #16, #17, #19).
2. Only a few platforms support SMBIOS node from the device tree.
3. Values of some fields are hardcoded in the library other than fetching
   from the device hardware.
4. Embedded data with dynamic length is not supported (E.g. Contained
   Object Handles in Type #2 and Contained Elements in Type #3)

Changes:
1. Refactor the SMBIOS library and command-line tool to better align with
   the SMBIOS spec.
2. Create an arch-specific driver for all aarch64-based platforms to fetch
   SMBIOS private data from the device hardware (processor and cache).
3. Create a sysinfo driver to poppulate platform SMBIOS private data.
4. Add generic SMBIOS DTS file for arm64 platforms for those common strings
   and values which cannot be retrieved from the system registers.
   Vendors can create their own SMBIOS node using this as an example.
   For those boards without SMBIOS nodes, this DTS file can be included to
   have a generic SMBIOS information of the system.
5. Add support for Type #7 (Cache Information) and link its handles to
   Type #4.
6. To minimize size-growth for those platforms which have not sufficient
   ROM spaces or the platforms which don't need detailed SMBIOS
   information, new added fields are only being built when kconfig
   GENERATE_SMBIOS_TABLE_VERBOSE is selected.

Once this patch is acceptted, subsequent patch sets will add other missing
types (#9, #16, #17, #19).

Tests:
To test this with QEMU arm64, please follow the guide on dt_qemu.rst to
get a merged DT to run with.
```
qemu-system-aarch64 -machine virt -machine dumpdtb=qemu.dtb
cat  <(dtc -I dtb qemu.dtb) <(dtc -I dtb ./dts/dt.dtb | grep -v /dts-v1/) \
  | dtc - -o merged.dtb
qemu-system-aarch64 -machine virt -nographic -bios u-boot.bin \
  -dtb merged.dtb
```

Link: https://lore.kernel.org/r/20241206225438.13866-1-raymond.mao@linaro.org
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.

4 participants
0