Skip to content

U
U-Boot.Mirror

OS / U-Boot.Mirror

通知 1
Star 0
Fork 0
U
U-Boot.Mirror

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 19 7月, 2018 6 次提交
    • L
      arm/arm64: zynq/zynqmp: pass the PS init file as a kconfig variable · 6da4f67a
      由 Luca Ceresoli 提交于 
      U-Boot needs to link ps7_init_gpl.c on Zynq or psu_init_gpl.c on
ZynqMP (PS init for short). The current logic to locate this file for
both platforms is:

 1. if a board-specific file exists in
    board/xilinx/zynq[mp]/$(CONFIG_DEFAULT_DEVICE_TREE)/ps?_init_gpl.c
    then use it
 2. otherwise use board/xilinx/zynq/ps?_init_gpl.c

In the latter case the file does not exist in the U-Boot sources and
must be copied in the source tree from the outside before starting the
build. This is typical when it is generated from Xilinx tools while
developing a custom hardware. However making sure that a
board-specific file is _not_ found (and used) requires some trickery
such as removing or overwriting all PS init files (e.g.: the current
meta-xilinx yocto layer).

This generates a few problems:

 * if the source tree is shared among different out-of-tree builds,
   they will pollute (and potentially corrupt) each other
 * the source tree cannot be read-only
 * any buildsystem must add a command to copy the PS init file binary
 * overwriting or deleting files in the source tree is ugly as hell

Simplify usage by allowing to pass the path to the desired PS init
file in kconfig variable XILINX_PS_INIT_FILE. It can be an absolute
path or relative to $(srctree). If the variable is set, the
user-specified file will always be used without being copied
around. If the the variable is left empty, for backward compatibility
fall back to the old behaviour.

Since the issue is the same for Zynq and ZynqMP, add one kconfig
variable in a common place and use it for both.

Also use the new kconfig help text to document all the ways to give
U-Boot the PS init file.

Build-tested with all combinations of:
 - platform: zynq or zynqmp
 - PS init file: from XILINX_PS_INIT_FILE (absolute, relative path,
   non-existing), in-tree board-specific, in board/xilinx/zynq[mp]/
 - building in-tree, in subdir, in other directory
Signed-off-by: NLuca Ceresoli <luca@lucaceresoli.net>
Cc: Albert Aribaud <albert.u.boot@aribaud.net>
Cc: Michal Simek <michal.simek@xilinx.com>
Cc: Nathan Rossi <nathan@nathanrossi.com>
Signed-off-by: NMichal Simek <michal.simek@xilinx.com>
      6da4f67a
    • M
      hush: Remove default CONFIG_SYS_PROMPT_HUSH_PS2 setting from board files · 5da7b8cb
      由 Michal Simek 提交于 
      There is no reason to define default option for this macro which is
already done in common/cli_hush.c.

  86 #ifndef CONFIG_SYS_PROMPT_HUSH_PS2
  87 #define CONFIG_SYS_PROMPT_HUSH_PS2      "> "
  88 #endif
Signed-off-by: NMichal Simek <michal.simek@xilinx.com>
Reviewed-by: NYork Sun <york.sun@nxp.com>
      5da7b8cb
    • M
      common: command: Handle USAGE failure separately · 27eb7bce
      由 Michal Simek 提交于 
      command_ret_t enum contains 3 return values but only two are handled
now. Extend cmd_process_error() and handle CMD_RET_USAGE separately.

These commands are affected by this change.
cmd/demo.c
cmd/efi.c
cmd/gpio.c
cmd/qfw.c
cmd/x86/fsp.c
test/dm/cmd_dm.c

And scripts shouldn't be affected because return value is not 0. But
every command implementation can choose what it is correct to pass.
I would expect that RET_USAGE is called when parameters are not
correctly passed (have incorrect value, missing parameters)
and RET_FAILURE when correct parameters are passed but command fails.
Signed-off-by: NMichal Simek <michal.simek@xilinx.com>
Reviewed-by: NSimon Glass <sjg@chromum.org>
      27eb7bce
    • M
      common: command: Use command_ret_t enum values instead of values · 37233240
      由 Michal Simek 提交于 
      Use enum command_ret_t types in cmd_process_error().
Signed-off-by: NMichal Simek <michal.simek@xilinx.com>
Reviewed-by: NSimon Glass <sjg@chromum.org>
      37233240
    • M
      arm64: zynqmp: Enable usb mass storage command and functionality · 24e2b201
      由 Michal Simek 提交于 
      Enable ums command for zcu100 to enable mass storage gadget.
Tested with ums 0 mmc 0 (for SD) and ums 0 usb 0 (for USB flashdisk).
Signed-off-by: NMichal Simek <michal.simek@xilinx.com>
      24e2b201
    • M
      gpio: zynq: Use live-tree function · d509f8dc
      由 Michal Simek 提交于 
      Use live-tree function.
Signed-off-by: NMichal Simek <michal.simek@xilinx.com>
      d509f8dc
  3. 18 7月, 2018 1 次提交
  5. 17 7月, 2018 1 次提交
    • C
      sunxi: Enable eMMC on Libre Computer Board ALL-H3-CC boards · 32f67bb7
      由 Chen-Yu Tsai 提交于 
      The Libretech ALL-H3-CC has a high density connector for attaching
an eMMC module. The module form factor and connection is specific
to Libretech, and has provisions for split vmmc/vqmmc (core and I/O)
voltage supplies, but this board does not wire the vqmmc side. The
H2+/H3/H5 SoCs do not support alternate I/O voltages for eMMC either.
Only 3.3V is supported. A specific module that ties vqmmc to vmmc,
with both at 3.3V, must be used.

Given that a) eMMC is not designed to be hotplugged, b) power is
always provided on the pins, and c) MMC controllers can deal with
missing cards, we can enable this by default. If a module is attached
it will be picked up by the system.

The device tree change was also submitted to the Linux Kernel and
has already been queued up for 4.19.
Signed-off-by: NChen-Yu Tsai <wens@csie.org>
Acked-by: NMaxime Ripard <maxime.ripard@bootlin.com>
Reviewed-by: NJagan Teki <jagan@openedev.com>
      32f67bb7
  7. 16 7月, 2018 25 次提交
  9. 14 7月, 2018 2 次提交
  11. 12 7月, 2018 5 次提交