8000 V3s i2c by ujuo · Pull Request #6 · u-boot/u-boot · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

V3s i2c #6

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 16 commits into from
Closed

V3s i2c #6

wants to merge 16 commits into from

Conversation

ujuo
Copy link
@ujuo ujuo commented Dec 15, 2017

sunxi: add i2c driver for V3s

Icenowy and others added 16 commits December 29, 2016 02:47
Allwinner SoCs after H3 (e.g. A64, H5, R40, V3s) uses a H3-like
DesignWare DRAM controller, which do not have official free DRAM
initialization code, but can use modified dram_sun8i_h3.c.

Add a invisible option for easier DRAM initialization code reuse.

Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
According to Jens disabling the on-die-termination should set bit 5,
not bit 1 in the respective register. Fix this.

Reported-by: Jens Kuske <jenskuske@gmail.com>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
H3-like DRAM controller needs some special code to operate a DDR2 DRAM
chip. Add the logic to probe such a chip.

As there's no commercial boards available now with H3 and DDR2 DRAM, the
patch is developed and tested on a V3s chip, which has in-package DDR2
DRAM.

Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
Currently a working SPL for V3s can be built now.

The U-Boot main binary still cannot work.

Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
As we have now V3s support in board code, the V3s DTSI file should also
be added.

Add also some CCU include headers to satisfy the DTSI file.

Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
Lichee Pi Zero is a development board with a V3s SoC.

Add support for it.

Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
V3s devices won't have enough memory to load U-Boot binary at
0x4a000000, and they do not have enough memory to reserve 64MiB for
malloc() (it has only 64MiB at all!)

Change the DRAM mapping for it.

Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
USB OTG on V3s SoC seems to need the USB OTG clock gate to be passed and
the reset to be deasserted before boot, otherwise it won't work in
Linux.

Add this quirk.

Also add a generic quirk framework in sunxi's clock initialization code.

Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
This is needed for HDMI support, which will be added later.

Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
[Icenowy: renamed back lcd0_ch0_clk_cfg, add PLL3 for DE2 on V3s,
and add CONFIG_SUNXI_DE2]
Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
V3s SoC features a DE2 composer.

Add support for it.

Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
DE2 do not have dedicated BE or FE.

Remove the "_be" suffix in the pipeline string of DE2.

Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
The cache of Cortex-A7 is only enabled if the SMP bit is set, but the
SMP bit of V3s is wrongly left unset, because I thought that it's not
SMP-capable.

Fix this.

Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
@ujuo ujuo closed this Dec 15, 2017
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>
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 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>
trini pushed a commit that referenced this pull request Jun 28, 2019
The MPU region dedicated for SDRAM for STM32F4 SoCs family
was set to 16MB, but STM32F429 Evaluation board have 32MB of SDRAM.

When kernel starts, only first 16MB of SDRAM are config
8000
ured with XN
(eXecute Never) bit disabled, whereas kernel is using 32MB.
To avoid such situation in the future, extend this MPU region to 512MB
as for STM32F7/H7.

It fixes the following user land exception on STM32F429 Evaluation
board :

[    1.713002] VFS: Mounted root (ext4 filesystem) readonly on device 179:2.
[    1.722605] devtmpfs: mounted
[    1.733057] Freeing unused kernel memory: 72K
[    1.737622] This architecture does not have kernel memory protection.
[    1.744070] Run /sbin/init as init process
[    1.906850]
[    1.906850] Unhandled exception: IPSR = 00000004 LR = fffffffd
[    1.914282] CPU: 0 PID: 1 Comm: init Not tainted 5.1.0-00002-gcf9ca5719954 #6
[    1.921433] Hardware name: STM32 (Device Tree Support)
[    1.926601] PC is at 0x1a00b64
[    1.929642] LR is at   (null)
[    1.932669] pc : [<01a00b64>]    lr : [<00000000>]    psr: 01000000
[    1.938993] sp : 01a5cfb0  ip : 00000000  fp : 00000000
[    1.944269] r10: 01a43b00  r9 : 00000000  r8 : 00000000
[    1.949564] r7 : 00000000  r6 : 00000000  r5 : 00000000  r4 : 00000000
[    1.956168] r3 : 00000000  r2 : 00000000  r1 : 00000000  r0 : 00000000
[    1.962701] xPSR: 01000000
[    1.965506] CPU: 0 PID: 1 Comm: init Not tainted 5.1.0-00002-gcf9ca5719954 #6
[    1.972658] Hardware name: STM32 (Device Tree Support)
[    1.978132] [<0000c009>] (unwind_backtrace) from [<0000b24f>] (show_stack+0xb/0xc)
[    1.986024] [<0000b24f>] (show_stack) from [<0000b947>] (__invalid_entry+0x4b/0x4c)

Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
roman3017 added a commit to roman3017/u-boot that referenced this pull request May 24, 2020
Add support for fat and auto detection
roman3017 added a commit to roman3017/u-boot that referenced this pull request Jul 11, 2020
Add support for fat and auto detection
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>
svenschwermer added a commit to svenschwermer/u-boot that referenced this pull request Mar 10, 2022
Sven/ma510 poweron

Approved-by: Alexey Orishko
ljkenny pushed a commit to ljkenny/u-boot that referenced this pull request Aug 11, 2022
Drop unused drivers (EFI_LOADER, ETH, QFW, SIMPLE_BUS), helper code
(CAAM_64BIT, GZIP, LIB_DATE, ZLIB), and ARCH_FIXUP_FDT_MEMORY:

       FILE SIZE        VM SIZE
    --------------  --------------
     -1.2%     -88  -1.2%     -88    .data
     -0.3%    -176  [ = ]       0    [Unmapped]
     [ = ]       0  -9.6%    -192    .bss
     -9.3%    -192  [ = ]       0    [LOAD u-boot#6 [RW]]
    -18.1%    -720 -18.4%    -720    .u_boot_list
     -4.7% -1.16Ki  -4.7% -1.16Ki    .rodata
    -12.4% -1.92Ki -12.4% -1.92Ki    .rela.dyn
    -98.4% -3.83Ki  [DEL] -3.83Ki    .efi_runtime
    -18.2% -4.74Ki  [ = ]       0    .strtab
    -17.4% -12.1Ki  [ = ]       0    .symtab
    -19.0% -15.3Ki  [ = ]       0    .debug_frame
    -19.6% -22.5Ki  [ = ]       0    .debug_ranges
    -20.5% -23.2Ki  [ = ]       0    .debug_abbrev
    -22.4% -29.2Ki  [ = ]       0    .debug_str
    -15.7% -30.2Ki -15.7% -30.2Ki    .text_rest
    -19.8% -60.6Ki  [ = ]       0    .debug_line
    -18.7%  -166Ki  [ = ]       0    .debug_loc
    -21.8%  -200Ki  [ = ]       0    .debug_info
    -19.3%  -572Ki -15.2% -38.1Ki    TOTAL

Explicitly set HAVE_BLOCK_DEVICE now that EFI_LOADER isn't in use, as
that option is necessary for block device I/O.

Remove SYS_LOAD_ADDR as it's duplicated from vm-aarch64.fragment.

Bug: 204525012
Change-Id: I57b5a9590a9e7241cc3f81a319c55af6a9c45aaf
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 8250_omap driver now uses ttyS* instead of ttyO*. Fixing this
in the console boot command prevents the kernel from having to do
a fixup and issue a warning at boot.

Signed-off-by: Mark Corbin <mcorbin@lunarenergy.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.

4 participants
0