u-boot.git/drivers/Makefile, branch v2019.01 Unnamed repository; edit this file 'description' to name the repository. Kconfig: rename CONFIG_SPL_USB_GADGET_SUPPORT as CONFIG_SPL_USB_GADGET 2019-01-10T17:52:55+00:00 Jean-Jacques Hiblot jjhiblot@ti.com 2019-01-10T14:44:13+00:00 f811e9763f4b6f6f5e3fe9c2fa30d2b6c62d289e The SPL option for USB gadget should be named after the option for u-boot (CONFIG_USB_GADGET) Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com> 
The SPL option for USB gadget should be named after the option for u-boot
(CONFIG_USB_GADGET)

Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
Merge tag 'u-boot-imx-20190101' of git://www.denx.de/git/u-boot-imx 2019-01-01T15:01:00+00:00 Tom Rini trini@konsulko.com 2019-01-01T14:56:41+00:00 522e035441ca04d99de2fc13b614ad896691e9c9 imx for 2019.01 - introduce support for i.MX8M - fix size limit for Vhybrid / pico boards - several board fixes - w1 driver for MX2x / MX5x 
imx for 2019.01

- introduce support for i.MX8M
- fix size limit for Vhybrid / pico boards
- several board fixes
- w1 driver for MX2x / MX5x
drivers: ddr: introduce DDR driver for i.MX8M 2019-01-01T13:12:18+00:00 Peng Fan peng.fan@nxp.com 2018-11-20T10:19:57+00:00 e3963c0943042afcb38d99041a8dc3d55f092f5f Introduce DDR driver for i.MX8M. The driver will be used by SPL to initialze DDR PHY and DDR Controller. Signed-off-by: Peng Fan <peng.fan@nxp.com> 
Introduce DDR driver for i.MX8M. The driver will be used by SPL to
initialze DDR PHY and DDR Controller.

Signed-off-by: Peng Fan <peng.fan@nxp.com>
spl: drivers: Link usb common library to SPL if USB gadget is enabled 2018-12-14T16:59:09+00:00 Jean-Jacques Hiblot jjhiblot@ti.com 2018-12-04T10:30:47+00:00 9a1dde58f5ed4a929971b37b7436040947ec732a Some drivers might need to access common USB functions such as usb_get_maximum_speed() or usb_get_dr_mode(). Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com> 
Some drivers might need to access common USB functions such as
usb_get_maximum_speed() or usb_get_dr_mode().

Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
spl: fix build failure with !CONFIG_SPL_PCI_SUPPORT 2018-12-12T17:14:23+00:00 Sekhar Nori nsekhar@ti.com 2018-12-06T10:10:08+00:00 d50d6817b583d20bf1c6e26c656d125bde5e4e4b Building U-Boot with CONFIG_PCI and CONFIG_DM_PCI enabled, but CONFIG_SPL_PCI_SUPPORT disabled, results in following linker error: lib/built-in.o: In function `fdtdec_get_pci_bar32': lib/fdtdec.c:305: undefined reference to `dm_pci_read_bar32' fdtdec.c:305:(.text.fdtdec_get_pci_bar32+0x24): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `dm_pci_read_bar32' This is because reference to dm_pci_read_bar32() remains in lib/fdtdec.c while SPL build does not descend into drivers/pci directory in drivers/Makefile if CONFIG_SPL_PCI_SUPPORT is not enabled. Fix this by applying appropriate #define guards in lib/fdtdec.c. It looks like ns16550.c has the same problem, so fixed that too. To simplify this, CONFIG_SPL_PCI_SUPPORT is renamed to CONFIG_SPL_PCI (enables use of CONFIG_IS_ENABLED() macro). Suggested-by: Vignesh R <vigneshr@ti.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com> 
Building U-Boot with CONFIG_PCI and CONFIG_DM_PCI enabled, but
CONFIG_SPL_PCI_SUPPORT disabled, results in following linker
error:

lib/built-in.o: In function `fdtdec_get_pci_bar32':
lib/fdtdec.c:305: undefined reference to `dm_pci_read_bar32'
fdtdec.c:305:(.text.fdtdec_get_pci_bar32+0x24): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `dm_pci_read_bar32'

This is because reference to dm_pci_read_bar32() remains in lib/fdtdec.c
while SPL build does not descend into drivers/pci directory in
drivers/Makefile if CONFIG_SPL_PCI_SUPPORT is not enabled.

Fix this by applying appropriate #define guards in lib/fdtdec.c.
It looks like ns16550.c has the same problem, so fixed that too.

To simplify this, CONFIG_SPL_PCI_SUPPORT is renamed to CONFIG_SPL_PCI
(enables use of CONFIG_IS_ENABLED() macro).

Suggested-by: Vignesh R <vigneshr@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
blk: Rework guard around part_init call 2018-12-12T17:14:22+00:00 Tom Rini trini@konsulko.com 2018-12-05T13:23:38+00:00 91ff6865629c81b8643b4ef6130e3e2130c60400 The function part_init() will only be built when we have both CONFIG_PARTITIONS and CONFIG_HAVE_BLOCK_DEVICE set. Protect the call to this function with both of these tests now. Cc: Simon Glass <sjg@chromium.org> Cc: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> Cc: Michal Simek <michal.simek@xilinx.com> Cc: York Sun <york.sun@nxp.com> Cc: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com> Cc: Mingkai Hu <mingkai.hu@nxp.com> Cc: Stefan Roese <sr@denx.de> Cc: Marek Behún <marek.behun@nic.cz> Cc: Vanessa Maegima <vanessa.maegima@nxp.com> Cc: Eugen Hristev <eugen.hristev@microchip.com> Cc: Adam Ford <aford173@gmail.com> Cc: Jagan Teki <jagan@amarulasolutions.com> Cc: Tom Warren <twarren@nvidia.com> Cc: Stephen Warren <swarren@nvidia.com> Cc: Vitaly Andrianov <vitalya@ti.com> Signed-off-by: Tom Rini <trini@konsulko.com> Reviewed-by: Simon Glass <sjg@chromium.org> 
The function part_init() will only be built when we have both
CONFIG_PARTITIONS and CONFIG_HAVE_BLOCK_DEVICE set.  Protect the call to
this function with both of these tests now.

Cc: Simon Glass <sjg@chromium.org>
Cc: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Cc: Michal Simek <michal.simek@xilinx.com>
Cc: York Sun <york.sun@nxp.com>
Cc: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>
Cc: Mingkai Hu <mingkai.hu@nxp.com>
Cc: Stefan Roese <sr@denx.de>
Cc: Marek Behún <marek.behun@nic.cz>
Cc: Vanessa Maegima <vanessa.maegima@nxp.com>
Cc: Eugen Hristev <eugen.hristev@microchip.com>
Cc: Adam Ford <aford173@gmail.com>
Cc: Jagan Teki <jagan@amarulasolutions.com>
Cc: Tom Warren <twarren@nvidia.com>
Cc: Stephen Warren <swarren@nvidia.com>
Cc: Vitaly Andrianov <vitalya@ti.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
dm: Add Hardware Spinlock class 2018-12-07T04:26:32+00:00 Benjamin Gaignard benjamin.gaignard@linaro.org 2018-11-27T12:49:50+00:00 7f84fc670b17fca3d8d1b7c9472a19bb8085c890 This is uclass for Hardware Spinlocks. It implements two mandatory operations: lock and unlock and one optional relax operation. Signed-off-by: Benjamin Gaignard <benjamin.gaignard@linaro.org> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Patrice Chotard <patrice.chotard@st.com> 
This is uclass for Hardware Spinlocks.
It implements two mandatory operations: lock and unlock
and one optional relax operation.

Signed-off-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Patrice Chotard <patrice.chotard@st.com>
spl: Support hash, input, pch, pci, rtc, tpm in SPL 2018-11-26T13:25:33+00:00 Simon Glass sjg@chromium.org 2018-11-16T01:43:55+00:00 2d424eb0cd6fc5c0060756e41feec3ec7e483678 At present these subsystems are only supported in U-Boot proper but it is sometimes necessary to support them in SPL, or even TPL. Update the Kconfig and Makefile to support this. Also adjust GPIO so that it can be used in TPL if required. Reviewed-by: Tom Rini <trini@konsulko.com> Signed-off-by: Simon Glass <sjg@chromium.org> 
At present these subsystems are only supported in U-Boot proper but it is
sometimes necessary to support them in SPL, or even TPL. Update the
Kconfig and Makefile to support this. Also adjust GPIO so that it can be
used in TPL if required.

Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
dm: Add a new uclass driver for VirtIO transport devices 2018-11-14T17:16:27+00:00 Bin Meng bmeng.cn@gmail.com 2018-10-15T09:21:00+00:00 8fb49b4c7a820461db7c11dce767f36fd6395cac This adds a new virtio uclass driver for “virtio” [1] family of devices that are are found in virtual environments like QEMU, yet by design they look like physical devices to the guest. The uclass driver provides child_pre_probe() and child_post_probe() methods to do some common operations for virtio device drivers like device and driver supported feature negotiation, etc. [1] http://docs.oasis-open.org/virtio/virtio/v1.0/virtio-v1.0.pdf Signed-off-by: Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi> Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org> 
This adds a new virtio uclass driver for “virtio” [1] family of
devices that are are found in virtual environments like QEMU,
yet by design they look like physical devices to the guest.

The uclass driver provides child_pre_probe() and child_post_probe()
methods to do some common operations for virtio device drivers like
device and driver supported feature negotiation, etc.

[1] http://docs.oasis-open.org/virtio/virtio/v1.0/virtio-v1.0.pdf

Signed-off-by: Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi>
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Add UCLASS_TEE for Trusted Execution Environment 2018-10-07T14:47:38+00:00 Jens Wiklander jens.wiklander@linaro.org 2018-09-25T14:40:09+00:00 9ff4a31175deb892cf5ea2976c213fb6c6dda080 Adds a uclass to interface with a TEE (Trusted Execution Environment). A TEE driver is a driver that interfaces with a trusted OS running in some secure environment, for example, TrustZone on ARM cpus, or a separate secure co-processor etc. The TEE subsystem can serve a TEE driver for a Global Platform compliant TEE, but it's not limited to only Global Platform TEEs. The over all design is based on the TEE subsystem in the Linux kernel, tailored for U-Boot. Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Igor Opaniuk <igor.opaniuk@linaro.org> Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org> 
Adds a uclass to interface with a TEE (Trusted Execution Environment).

A TEE driver is a driver that interfaces with a trusted OS running in
some secure environment, for example, TrustZone on ARM cpus, or a
separate secure co-processor etc.

The TEE subsystem can serve a TEE driver for a Global Platform compliant
TEE, but it's not limited to only Global Platform TEEs.

The over all design is based on the TEE subsystem in the Linux kernel,
tailored for U-Boot.

Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Igor Opaniuk <igor.opaniuk@linaro.org>
Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>