Change address_cells and size_cells of root node and 'soc' node
from 2 to 1.
We backport ls1021a device tree source files from kernel to u-boot.
Kernel files set address_cells and size_cells to 2 in order to access
more than 4GB space.
But we don't have this requirement now and u-boot fdtdec_get_xxx interfaces
can't support property whose size is 'u64' completely.
So make this change.
Signed-off-by: Haikun Wang <Haikun.Wang@freescale.com>
Acked-by: Simon Glass <sjg@chromium.org>
Bring in required device tree files for ls1021a from Linux.
These are initially unchanged and have a number of pieces not needed by U-Boot.
Signed-off-by: Haikun Wang <Haikun.Wang@freescale.com>
Acked-by: Simon Glass <sjg@chromium.org>
Backport of kernel commits:
7c14f6c719de092d69c81877786e83ce7ae1a860
35faad2a1563b3d4dc983a82ac41033fe053870c
Signed-off-by: Haikun Wang <Haikun.Wang@freescale.com>
Acked-by: Simon Glass <sjg@chromium.org>
The U-Boot device trees are slightly different in a few places. Adjust them
to remove most of the differences. Note that U-Boot does not support the
concept of interrupts as distinct from GPIOs, so this difference remains.
For sandbox, use the same keyboard file as for ARM boards and drop the
host emulation bus which seems redundant.
Signed-off-by: Simon Glass <sjg@chromium.org>
The PCH (Platform Controller Hub) is on the PCI bus, so show it as such.
The LPC (Low Pin Count) and SPI bus are inside the PCH, so put these in the
right place also.
Rename the compatible strings to be more descriptive since this board is the
only user. Once we are using driver model fully on x86, these will be
dropped.
Signed-off-by: Simon Glass <sjg@chromium.org>
On x86 systems this device is commonly used to provide legacy port access.
It is sort-of a replacement for the old ISA bus.
Add a uclass for this, and allow it to have child devices.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add a simple uclass for this chip which is often found in x86 systems
where the CPU is a separate device.
The device can have children, so make it scan the device tree for these.
Signed-off-by: Simon Glass <sjg@chromium.org>
Convert this driver over to use driver model. Since all x86 platforms use
it, move x86 to use driver model for SPI and SPI flash. Adjust all dependent
code and remove the old x86 spi_init() function.
Note that this does not make full use of the new PCI uclass as yet. We still
scan the bus looking for the device. It should move to finding its details
in the device tree.
Signed-off-by: Simon Glass <sjg@chromium.org>
The 'lo' interface on Linux doesn't support thinks like ARP or
link-layer access like we use to talk to a normal network interface.
A higher-level network API must be used to access localhost.
As written, this interface is limited to not supporting ICMP since the
API doesn't allow the socket to be opened for all IP traffic and be able
to receive at the same time. UDP is far more useful to test with, so it
was selected over ICMP. Ping won't work, but things like TFTP should
work.
Signed-off-by: Joe Hershberger <joe.hershberger@ni.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Implement a bridge between U-Boot's network stack and Linux's raw packet
API allowing the sandbox to send and receive packets using the host
machine's network interface.
This raw Ethernet API requires elevated privileges. You can either run
as root, or you can add the capability needed like so:
sudo /sbin/setcap "CAP_NET_RAW+ep" /path/to/u-boot
Signed-off-by: Joe Hershberger <joe.hershberger@ni.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
This is needed to test the netretry functionality (make the command fail
on a sandbox eth device).
Signed-off-by: Joe Hershberger <joe.hershberger@ni.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The sandbox driver will now generate response traffic to exercise the
ping command even when no network exists. This allows the basic data
pathways of the DM to be tested.
Signed-off-by: Joe Hershberger <joe.hershberger@ni.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Add basic network support to sandbox which includes a network driver.
Signed-off-by: Joe Hershberger <joe.hershberger@ni.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
This value is not used by the network stack and is available in the
global data, so stop passing it around. For the one legacy function
that still expects it (init op on old Ethernet drivers) pass in the
global pointer version directly to avoid changing that interface.
Signed-off-by: Joe Hershberger <joe.hershberger@ni.com>
Reported-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>
(Trival fix to remove an unneeded variable declaration in 4xx_enet.c)
The current implementation exposes the eth_device struct to code that
needs to access the MAC address. Add a wrapper function for this to
abstract away the pointer for this operation.
Signed-off-by: Joe Hershberger <joe.hershberger@ni.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
In the case where the arch defines a custom map_sysmem(), make sure that
including just mapmem.h is sufficient to have these functions as they
are when the arch does not override it.
Also split the non-arch specific functions out of common.h
Signed-off-by: Joe Hershberger <joe.hershberger@ni.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Move chromebook_link over to driver model for PCI.
This involves:
- adding a uclass for platform controller hub
- removing most of the existing PCI driver
- adjusting how CPU init works to use driver model instead
- rename the lpc compatible string (it will be removed later)
This does not really take advantage of driver model fully, but it does work.
Furture work will improve the code structure to remove many of the explicit
calls to init the board.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add the required header information, device tree nodes and I/O accessor
functions to support PCI on sandbox. All devices are emulated by drivers
which can be added as required for testing or development.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present we do more in this function than we should. Split out the
post-driver-model part into a separate function.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
These functions currently use a generic name, but they are for x86 only.
This may introduce confusion and prevents U-Boot from using these names
more widely.
In fact it should be possible to remove these at some point and use
generic functions, but for now, rename them.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
We should have a size value for these. Add one in each case. This will
be needed for PCI.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Support running U-Boot as a coreboot payload. Tested peripherals include:
- Video (HDMI and DisplayPort)
- SATA disk
- Gigabit Ethernet
- SPI flash
USB3 does not work. This may be a problem with the USB3 PCI driver or
something in the USB3 stack and has not been investigated So far this is
disabled. The SD card slot also does not work.
For video, coreboot will need to run the OPROM to set this up.
With this board, bare support (running without coreboot) is not available
as yet.
Signed-off-by: Simon Glass <sjg@chromium.org>
Some systems have more than 4GB of RAM. U-Boot can only place things below
4GB so any memory above that should not be used. Ignore any such memory so
that the memory size will not exceed the maximum.
This prevents gd->ram_size exceeding 4GB which causes problems for PCI
devices which use DMA.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Lukasz Majewski <l.majewski@samsung.com>
Commit d3cfcb3 (ARM: DRA7: Enable clocks for USB OTGSS and USB PHY)
changed the member names of prcm_regs from cm_l3init_usb_otg_ss_clkctrl
to cm_l3init_usb_otg_ss1_clkctrl and from cm_coreaon_usb_phy_core_clkctrl
to cm_coreaon_usb_phy1_core_clkctrl in order to differentiate between
the two dwc3 controllers present in dra7xx/am43xx and enabled these
clocks in enable_basic_clocks() in hw_data.c. However these clocks
continued to be enabled in board files/driver files for dwc3 host
mode functionality causing compilation break with few configs.
Fixed it here by making all the clocks enabled in enable_basic_clocks()
and removing it from board files/driver files here.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Sunxi platforms come with at least 3 TWI (I2C) controllers and some platforms
even have up to 5. This adds support for every controller on each supported
platform, which is especially useful when using expansion ports on single-board-
computers.
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Orion5x, Kirkwood and Armada XP platforms come with a single TWSI (I2C) MVTWSI
controller. However, other platforms using MVTWSI may come with more: this is
the case on Allwinner (sunxi) platforms, where up to 4 controllers can be found
on the same chip.
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Acked-by: Heiko Schocher <hs@denx.de>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
When u-boot boots the board may be powering vbus, we turn off vbus in
sunxi_usbc_request_resources, if we are too quick with reading vusb-detect
after this we may see a residual charge and assume we've an external vusb
connected even though we do not. So when we see an external vusb wait a bit
and try again.
Without this when dealing with a pmic controller vbus and doing "reset" on
the u-boot console the musb host will only init once every other boot, because
the other boot it thinks an external vbus is present, this commit fixes this.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Ian Campbell <ijc@hellion.org.uk>
On boards which use the pmic to enable/disable vbus on the otg port, the
vbus value is not reset to 0 on reset, as reset only resets the SoC and not
the pmic, so explicitly set vbus to 0 on init (request_resources) by moving
the gpio_direction_output call into request_resources.
For consistency also move the gpio_direction_input call for vbus-detect into
request_resources.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Ian Campbell <ijc@hellion.org.uk>
Sunxi platforms have different possible mmc pin mux setups (except for mmc0),
which are different across platforms.
This lets users configure which is used through the CONFIG_MMC*_PINS Kconfig
options. This is especially relevant when a second (in addition to mmc0) port
is used and CONFIG_MMC_SUNXI_SLOT_EXTRA is enabled.
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Each hardware feature exposed through the GPIO pin mux is usually using the same
function index (for a given port), so there is no need to define one value per
pin: one value per hardware feature per port is sufficient, avoids duplication
and makes everything easier to understand.
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
VBUS detection could be needed not only by the musb code (to prevent host mode),
but also by e.g. gadget drivers to start only when a cable is connected.
In addition, this allows more flexibility in vbus detection, as it could easily
be extended to other USBC indexes. Eventually, this would help making musb
support independent from a hardcoded USB controller index (0).
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
VBUS detection and enable is now be used with virtual AXP GPIOs, so all the USB
code has to use GPIO in every case and let sunxi_gpio do the heavy lifting.
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
This converts the VBUS detection and enable logic to GPIO instead of separate
axp functions and checks that have to be used aside usual GPIO functions.
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Implemented board_usb_init(), board_usb_cleanup() and
usb_gadget_handle_interrupts() in am43xx board file that
can be invoked by various gadget drivers.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Reviewed-by: Lukasz Majewski <l.majewski@samsung.com>
Implemented board_usb_init(), board_usb_cleanup() and
usb_gadget_handle_interrupts() in dra7xx board file that
can be invoked by various gadget drivers.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Reviewed-by: Lukasz Majewski <l.majewski@samsung.com>
Added resource_size_t type in order to get rid of the following
compilation error whiel building dwc3 gadget.
include/linux/ioport.h:19:2: error: unknown type name ‘resource_size_t’
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Reviewed-by: Lukasz Majewski <l.majewski@samsung.com>
Added dma_free_coherent corresponding to the dma_alloc_coherent in
dma-mapping.h in order to free memory allocated using dma_alloc_coherent.
This API is used in dwc3 driver.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Reviewed-by: Lukasz Majewski <l.majewski@samsung.com>
Fixed the following warning here.
"warning: ‘dma_alloc_coherent’ defined but not used" while compiling
udc-core
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Reviewed-by: Lukasz Majewski <l.majewski@samsung.com>
Enabled clocks for dwc3 controller and USB PHY present in AM43xx.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Reviewed-by: Lukasz Majewski <l.majewski@samsung.com>
Enabled clocks for dwc3 controller and USB PHY present in DRA7.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Reviewed-by: Lukasz Majewski <l.majewski@samsung.com>
When we communicate with the VideoCore to perform property mailbox
transactions, that is a DMA operation as far as the property buffer
is concerned. Use phys_to_bus() on that buffer.
Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
The BCM283[56] contain both a L1 and L2 cache between the GPU (a/k/a
VideoCore CPU?) and DRAM. DMA-capable peripherals can also optionally
access DRAM via this same L2 cache (although they always bypass the L1
cache). Peripherals select whether to use or bypass the cache via the
top two bits of the bus address.
An IOMMU exists between the ARM CPU and the rest of the system. This
controls whether the ARM CPU's accesses use or bypass the L1 and/or L2
cache. This IOMMU is configured/controlled exclusively by the VideoCore
CPU.
In order for DRAM accesses made by the ARM core to be coherent with
accesses made by other DMA peripherals, we must program a bus address
into those peripherals that causes the peripheral's accesses to use the
same set of caches that the ARM core's accesses will use.
On the RPi1, the VideoCore firmware sets up the IOMMU to enable use of
the L2 cache. This corresponds to addresses based at 0x40000000.
On the RPi2, the VideoCore firmware sets up the IOMMU to disable use of
the L2 cache. This corresponds to addresses based at 0xc0000000.
This patch implements U-Boot's phys_to_bus/bus_to_phys APIs according
to those rules.
For full details of this setup, please see Dom Cobley's description at:
http://lists.denx.de/pipermail/u-boot/2015-March/208201.htmlhttp://permalink.gmane.org/gmane.comp.boot-loaders.u-boot/215038https://www.mail-archive.com/u-boot@lists.denx.de/msg166568.html
Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>