| Commit message (Collapse) | Author | Age | Lines |
|
|
|
|
|
|
| |
Tested on a Vayu EVM Rev.E2 with DRA752 ES1.1
Signed-off-by: Lubomir Popov <l-popov@ti.com>
Reviewed-by: Tom Rini <trini@ti.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Boards using the TWL4030 regulator may not all use the LDOs the same way
(e.g. MMC2 power can be controlled by another LDO than VMMC2).
This delegates TWL4030 MMC power initializations to board-specific functions,
that may still call twl4030_power_mmc_init for the default behavior.
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Reviewed-by: Tom Rini <trini@ti.com>
[trini: Fix omap3_evm warning, add twl4030.h]
Signed-off-by: Tom Rini <trini@ti.com>
|
|
|
|
|
|
|
|
|
| |
Not every device has multiple MMC slots available, so it makes sense to enable
only the required LDOs for the available slots. Generic code in omap_hsmmc will
enable both VMMC1 and VMMC2, in doubt.
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Reviewed-by: Tom Rini <trini@ti.com>
|
|
|
|
|
|
|
|
|
| |
Some devices may use non-standard combinations of regulators to power MMC:
this allows these devices to provide a board-specific MMC power init function
to set everything up in their own way.
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Reviewed-by: Tom Rini <trini@ti.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
BeagleBoard-X15 is the next generation Open Source
Hardware BeagleBoard based on TI's AM5728 SoC
featuring dual core 1.5GHZ A15 processor. The
platform features 2GB DDR3L (w/dual 32bit busses),
eSATA, 3 USB3.0 ports, integrated HDMI (1920x108@60),
separate LCD port, video In port, 4GB eMMC, uSD,
Analog audio in/out, dual 1G Ethernet.
For more information, refer to:
http://www.elinux.org/Beagleboard:BeagleBoard-X15
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Tom Rini <trini@ti.com>
|
|
|
|
|
|
|
|
| |
just add a few ifdefs around because this
device is very similar to dra7xxx.
Signed-off-by: Felipe Balbi <balbi@ti.com>
Reviewed-by: Tom Rini <trini@ti.com>
|
|
|
|
|
|
|
|
|
| |
expose those two definitions so they can be
used by another board which we're adding in upcoming
patches.
Signed-off-by: Felipe Balbi <balbi@ti.com>
Reviewed-by: Tom Rini <trini@ti.com>
|
|
|
|
|
|
|
|
| |
this will allow for boards to overwrite those
in case memory setup is different.
Signed-off-by: Felipe Balbi <balbi@ti.com>
Reviewed-by: Tom Rini <trini@ti.com>
|
|
|
|
|
|
|
|
| |
this way we can let boards overwrite based
on what they need.
Signed-off-by: Felipe Balbi <balbi@ti.com>
Reviewed-by: Tom Rini <trini@ti.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Since the emmc isn't always programed trying to load the fs from the
emmc causes boot failures/kernel panic.
* The current bootcmd is set to:
bootcmd=run findfdt; run mmcboot;setenv mmcdev 1; setenv bootpart 1:2; \
setenv mmcroot /dev/mmcblk0p2 rw; run mmcboot;
My guess is the env variables should be set so that sd card boot
(dt,kernel,fs) is the default and then fallback to emmc if it fails (no
sd card detected)
The current bootcmd attempts to set mmcroot to the sd card rootfs but
that code doesn't run due to mmcboot being ran early on.
Signed-off-by: Franklin Cooper Jr. <fcooper@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Reviewed-by: Tom Rini <trini@ti.com>
|
|
|
|
|
|
|
|
|
| |
If we want to have two sections, one on each EMIF, without
interleaving, current code wouldn't enable emif2. Fix that
problem.
Signed-off-by: Felipe Balbi <balbi@ti.com>
Reviewed-by: Tom Rini <trini@ti.com>
|
|
|
|
|
|
|
|
|
|
| |
there's no such function usb3_phy_power(),
it's likely that author meant to call,
usb_phy_power() instead, but that's already
called properly from xhci-omap.c.
Signed-off-by: Felipe Balbi <balbi@ti.com>
Reviewed-by: Tom Rini <trini@ti.com>
|
|
|
|
|
|
|
|
|
| |
some boards might want to use USB1 for host,
without fiddling those registers it'll be
impossible.
Signed-off-by: Felipe Balbi <balbi@ti.com>
Reviewed-by: Tom Rini <trini@ti.com>
|
|
|
|
|
|
|
|
|
| |
Those regulators don't have any coupling with
what they supply, so remove the suffixes in order
to not confuse anybody.
Signed-off-by: Felipe Balbi <balbi@ti.com>
Reviewed-by: Tom Rini <trini@ti.com>
|
|
|
|
|
|
|
|
|
|
| |
Out of all OMAP5-like boards, only one of them
needs CONFIG_MISC_INIT_R, so it's best to enable
that for that particular board only, instead of
enabling for all boards unconditionally.
Signed-off-by: Felipe Balbi <balbi@ti.com>
Reviewed-by: Tom Rini <trini@ti.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It has been found that this change breaks the case of an appended device
tree file, so for the problem in question some other solution must be
found.
This reverts commit c6150aaf2f2745141a7c2ceded58d7efbfeace7d.
Reported-by: Bill Pringlemeir <bpringlemeir@nbsps.com>
Reported-by: Pantelis Antoniou <panto@antoniou-consulting.com>
Confirmed-by: Bill Pringlemeir <bpringlemeir@nbsps.com>
Signed-off-by: Tom Rini <trini@ti.com>
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
After commit 933cdbb479: "fdt: Try to use fdt_address_cells()/fdt_size_cells()"
I noticed that allwinner boards would no longer boot.
Switching to fdt_address_cells / fdt_size_cells changes the result from
bytes to 32 bit words, so when we increment pointers into the blob, we must
do so by 32 bit words now.
This commit makes allwinner boards boot again.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Tested-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Acked-by: Simon Glass <sjg@chromium.org>
Tested-by: Stefan Roese <sr@denx.de>
Tested-by: Vince Hsu <vinceh@nvidia.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The fdt_path_offset() checks an alias too.
fdtdec_get_alias_node(blob, "foo") is equivalent to
fdt_path_offset(blob, "foo").
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Acked-by: Simon Glass <sjg@chromium.org>
|
|\ \ |
|
| | |
| | |
| | |
| | |
| | | |
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
|
| | |
| | |
| | |
| | |
| | |
| | | |
Enable the Chrome OS EC so that it can be used from U-Boot.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
| | |
| | |
| | |
| | |
| | |
| | | |
Enable this so that it can be used instead of native execution if desired.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This is a rare event and should not happen. When it does it is confusing to
work out why. At least we should print a message.
Adjust the emulator to always print decode errors to the console.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
At present there are DEBUG options spread around the place. If you enable
one and not another you can end up with an emulator that does not work,
since each file can have a different view of what the registers look like.
To fix this, create a global CONFIG_X86EMU_DEBUG option that keeps
everything consistent.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Sometime we want to provide an interrupt handler for the ROM, Add a
function to allow this.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
As well as locating the ROM on the PCI bus, allow the ROM to be supplied to
the emulator. Split the init up a little so that callers can supply their
own interrupt routines. Also allow a vesa mode to be provided, to be
selected once the BIOS run is complete.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
There is an implicit assumption that x86 machines want to use raw I/O in the
BIOS emulator, but this should be selectable. Add an CONFIG_X86EMU_RAW_IO
option to control it instead.
Also fix a few bugs which cause warnings on x86 and adjust the Makefile to
remove the assumption that only PowerPC uses the emulator.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Now that we have the required drivers, enable video support with a suitable
option ROM.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
| | |
| | |
| | |
| | |
| | |
| | | |
This provides panel timing information needed by the video driver.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Intel's Graphics Media Accelerator (GMA) is a generic name for a wide range
of video devices. Add code to set up the hardware on ivybridge. Part of the
init happens in native code, part of it happens in a 16-bit option ROM for
those nostalgic for the 1970s.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Some x86 machines require a binary blob containing 16-bit initialisation
code for their video hardware. Allow this to be built into the x86 ROM so
that it is accessible during boot.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Add a very simple driver which uses vesa to discover the video mode and
then provides a frame buffer for use by U-Boot.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Anatolij Gustschin <agust@denx.de>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Some platforms don't have native code for dealing with their video
hardware. In some cases they use a binary blob to set it up and perform
required actions like setting the video mode. This approach is a hangover
from the old PC days where a ROM was provided and executed during startup.
Even now, these ROMs are supplied as a way to set up video. It avoids the
code for every video chip needing to be provided in the boot loader. But
it makes the video much less flexible - e.g. it is not possible to do
anything else while the video init is happening (including waiting hundreds
of milliseconds for display panels to start up).
In any case, to deal with this sad state of affairs, provide an API for
execution of x86 video ROMs, either natively or through emulation.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
On x86 machines we can use an emulator to run option ROMS as with other
architectures. But with some additional effort (mostly due to the 16-bit
nature of option ROMs) we can run them natively. Add support for this.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
For option ROMs we can use these extensions to request a particular video
mode. Add a header file which defines the binary interface.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
| | |
| | |
| | |
| | |
| | |
| | | |
Add Kconfig options to allow selection of a vesa mode on x86 machines.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Option ROMs require a few additional descriptors. Add these, and remove the
enum since we now have to access several descriptors from assembler.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
We should have a public header so that users can avoid defining functions
themselves.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This is needed to permit calling C from assembler without too much pain.
Add a definition for x86.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
| | |
| | |
| | |
| | |
| | |
| | | |
Enable SPI so that the SPI flash can be used.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
| | |
| | |
| | |
| | |
| | |
| | | |
Add init for the northbridge, another part of the platform controller hub.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
| | |
| | |
| | |
| | |
| | |
| | | |
These are not available in U-Boot as yet, so drop them.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
| | |
| | |
| | |
| | |
| | |
| | | |
Add the setup code for the CPU so that it can be used at full speed.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Add code to set up the Local Advanced Peripheral Interrupt Controller.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This is no-longer used, so drop it.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Actually initr_enable_interrupts() was never called in an x86 build
due to it was wrapped by CONFIG_x86 (typo of X86).
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Rename interrupt_init() in arch/x86/lib/pcat_interrupts.c to
i8259_init() and create a new interrupt_init() in
arch/x86/cpu/interrupt.c to call i8259_init() followed by a
call to cpu_init_interrupts().
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Since cpu_init_interrupts() was moved out of cpu_init_r(), it is
useless to keep cpu_init_r() for x86, thus remove it.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Currently cpu_init_interrupts() is called from cpu_init_r() to
setup the interrupt and exception of the cpu core, but at that
time the i8259 has not been initialized to mask all the irqs
and remap the master i8259 interrupt vector base, so the whole
system is at risk of being interrupted, and if interrupted,
wrong interrupt/exception message is shown.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
|