Simon Glass [Sun, 13 Mar 2016 14:22:33 +0000 (08:22 -0600)]
dm: usb: Unbind old block devices when shutting down USB
When 'usb start' is used, block devices are created for any USB flash sticks
and disks, etc. When 'usb stop' is used, these block devices are currently
not removed.
We don't want old block devices hanging around since they can still be
visible to U-Boot. Therefore, when USB is shut down, remove and unbind all
the block devices created by the USB subsystem.
Possibly we should unbind all devices which don't cause problems by being
unbound. Most likely we can remove everything except USB controllers, hubs
and emulators. We can consider that later.
Signed-off-by: Simon Glass <sjg@chromium.org> Tested-by: Stephen Warren <swarren@nvidia.com>
Simon Glass [Sun, 13 Mar 2016 01:50:32 +0000 (18:50 -0700)]
buildman: Add a way to specific a full toolchain prefix
At present buildman allows you to specify the directory containing the
toolchain, but not the actual toolchain prefix. If there are multiple
toolchains in a single directory, this can be inconvenient.
Add a new 'toolchain-prefix' setting to the settings file, which allows
the full prefix (or path to the C compiler) to be specified.
Update the documentation to match.
Suggested-by: Stephen Warren <swarren@wwwdotorg.org> Reviewed-by: Joe Hershberger <joe.hershberger@ni.com> Signed-off-by: Simon Glass <sjg@chromium.org> Tested-by: Stephen Warren <swarren@nvidia.com>
Simon Glass [Sun, 13 Mar 2016 01:50:31 +0000 (18:50 -0700)]
buildman: Allow branch names which conflict with directories
At present if you try to use buildman with the branch 'test' it will
complain that it is unsure whether you mean the branch or the directory.
This is a feature of the 'git log' command that buildman uses. Fix it
by resolving the ambiguity.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Joe Hershberger <joe.hershberger@ni.com>
Michal Simek [Tue, 16 Feb 2016 15:17:49 +0000 (16:17 +0100)]
dm: ns16550: Add support for reg-offset property
reg-offset is the part of standard 8250 binding in the kernel.
It is shifting start of address space by reg-offset.
On Xilinx platform this offset is typically 0x1000.
Signed-off-by: Michal Simek <michal.simek@xilinx.com> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
Moved the new field to the end of the struct to avoid problems: Signed-off-by: Simon Glass <sjg@chromium.org>
The reverted commit was applied for a temporary to unbreak
few Exynos boards on the release.
After the discussion about the change, this commit should be avoided.
Fixed device-tree for Exynos, allows reverting it without any issues.
Signed-off-by: Przemyslaw Marczak <p.marczak@samsung.com> Cc: Stefan Roese <sr@denx.de> Cc: Tom Rini <trini@konsulko.com> Cc: Simon Glass <sjg@chromium.org> Cc: Stephen Warren <swarren@nvidia.com> Cc: Stephen Warren <swarren@wwwdotorg.org> Tested-by: Simon Glass <sjg@chromium.org> Acked-by: Simon Glass <sjg@chromium.org>
dts:exynos:update pinctrl size-cells and fix child regs
This change is required to avoid warnings about invalid
size-cells defined in device-tree pinctrl nodes for Exynos.
Tested on:
- Odroid U3
- Odroid XU3
Signed-off-by: Przemyslaw Marczak <p.marczak@samsung.com> Cc: Stefan Roese <sr@denx.de> Cc: Tom Rini <trini@konsulko.com> Cc: Simon Glass <sjg@chromium.org> Cc: Stephen Warren <swarren@nvidia.com> Cc: Stephen Warren <swarren@wwwdotorg.org> Tested-by: Simon Glass <sjg@chromium.org> Acked-by: Simon Glass <sjg@chromium.org> Acked-by: Minkyu Kang <mk7.kang@samsung.com>
Tom Rini [Thu, 17 Mar 2016 14:14:25 +0000 (10:14 -0400)]
cmd_dhry.c: Use lldiv for vax_mips calculation as well
Since dhry_per_sec is a u64 we must also use lldiv here when working
with it. Otherwise:
../lib/dhry/cmd_dhry.c:(.text.do_dhry+0xd8): undefined reference to `__udivdi3'
Stefan Roese [Wed, 16 Mar 2016 07:48:21 +0000 (08:48 +0100)]
x86: Add congatec conga-QA3/E3845-4G (Bay Trail) support
This patch adds support for the congatec conga-QA3/E3845-4G eMMC8 SoM,
installed on the congatec Qseven 2.0 evaluation carrier board
(conga-QEVAL).
Its port is very similar to the MinnowboardMAX port and also uses
the Intel FSP as described in doc/README.x86.
Currently supported are the following interfaces / devices:
- UART (via Winbond legacy SuperIO chip on carrier board)
- Ethernet (PCIe Intel I210 / E1000)
- SPI including SPI NOR as boot-device
- USB 2.0
- SATA via U-Boot SCSI IF
- eMMC
- Video (HDMI output @ 800x600)
- PCIe
Not supported yet is:
- I2C
- USB 3.0
Signed-off-by: Stefan Roese <sr@denx.de> Cc: Simon Glass <sjg@chromium.org> Cc: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Wed, 16 Mar 2016 13:44:43 +0000 (07:44 -0600)]
x86: Add support for the samus chromebook
This adds basic support for chromebook_samus. This is the 2015 Pixel and
is based on an Intel broadwell platform.
Supported so far are:
- Serial
- SPI flash
- SDRAM init (with MRC cache)
- SATA
- Video (on the internal LCD panel)
- Keyboard
Various less-visible drivers are provided to make the above work (e.g. PCH,
power control and LPC).
The platform requires various binary blobs which are documented in the
README. The major missing feature is USB3 since the existing U-Boot support
does not work correctly with Intel XHCI controllers.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Wed, 16 Mar 2016 13:44:40 +0000 (07:44 -0600)]
x86: Support a chained-boot development flow
Sometimes it is useful to jump into U-Boot directly from coreboot or UEFI
without any 16-bit init. This can help during development by allowing U-Boot
to avoid doing all the init required by the platform.
U-Boot expects its GDT to be set up correctly by its 16-bit code. If
coreboot doesn't do this (because it hasn't run the payload setup code yet)
then this won't happen.
In this case we cannot rely on the GDT settings. U-Boot will hang or crash
if these are wrong. Provide a development-only option to set up the GDT
correctly. This is just a hack so you can jump to U-Boot from any stage of
coreboot, not just at the end.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Wed, 16 Mar 2016 13:44:37 +0000 (07:44 -0600)]
x86: Add common SDRAM-init code
The code to call the memory reference code is common to several Intel CPUs.
Add common code for performing this init. Intel calls this 'Pre-EFI-Init'
(PEI), where EFI stands for Extensible Firmware Interface.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Sat, 12 Mar 2016 05:07:30 +0000 (22:07 -0700)]
x86: broadwell: Add video support
Add a video driver for Intel's broadwell integrated graphics controller.
This uses a binary blob for most init, with the driver just performing a few
basic tasks.
This driver supports VESA as the mode-setting mechanism. Since most boards
don't support driver model yet with VESA, a special case is added to the
Kconfig for broadwell. Eventually all boards will use driver model and this
can be removed.
Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Sat, 12 Mar 2016 05:07:26 +0000 (22:07 -0700)]
x86: broadwell: Add support for SDRAM setup
Broadwell uses a binary blob called the memory reference code (MRC) to start
up its SDRAM. This is similar to ivybridge so we can mostly use common code
for running this blob.
Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Sat, 12 Mar 2016 05:07:25 +0000 (22:07 -0700)]
x86: broadwell: Add power-control support
Broadwell requires quite a bit of power-management setup. Add code to set
this up correctly.
Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Bin Meng <bmeng.cn@gmail.com>
[squashed in http://patchwork.ozlabs.org/patch/598373/] Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Sat, 12 Mar 2016 05:07:16 +0000 (22:07 -0700)]
x86: Add support for running Intel reference code
Intel has invented yet another binary blob which firmware is required to
run. This is run after SDRAM is ready. It is linked to load at a particular
address, typically 0, but is a relocatable ELF so can be moved if required.
Add support for this in the build system. The file should be placed in the
board directory, and called refcode.elf.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Sat, 12 Mar 2016 05:07:13 +0000 (22:07 -0700)]
x86: Add an ICH6 pin configuration driver
Add a driver which sets up the pin configuration on x86 devices with an ICH6
(or later) Platform Controller Hub.
The driver is not in the pinctrl uclass due to some oddities of the way x86
devices work:
- The GPIO controller is not present in I/O space until it is set up
- This is done by writing a register in the PCH
- The PCH has a driver which itself uses PCI, another driver
- The pinctrl uclass requires that a pinctrl device be available before any
other device can be probed
It would be possible to work around the limitations by:
- Hard-coding the GPIO address rather than reading it from the PCH
- Using special x86 PCI access to set the GPIO address in the PCH
However it is not clear that this is better, since the pin configuration
driver does not actually provide normal pin configuration services - it
simply sets up all the pins statically when probed. While this remains the
case, it seems better to use a syscon uclass instead. This can be probed
whenever it is needed, without any limitations.
Also add an 'invert' property to support inverting the input.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Sat, 12 Mar 2016 05:07:12 +0000 (22:07 -0700)]
x86: link: Add pin configuration to the device tree
At present pin configuration on link does not use the standard mechanism,
but some rather ugly custom code. As a first step to resolving this, add the
pin configuration to the device tree.
Four of the GPIOs must be available before relocation (for SDRAM pin
strapping).
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Sat, 12 Mar 2016 05:07:00 +0000 (22:07 -0700)]
x86: Move Intel Management Engine code to a common place
Some of the Intel ME code is common to several Intel CPUs. Move it into a
common location. Add a header file for report_platform.c also.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
[squashed in http://patchwork.ozlabs.org/patch/598372/] Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Sat, 12 Mar 2016 05:06:55 +0000 (22:06 -0700)]
x86: Create a common header for Intel register access
There are several blocks of registers that are accessed from all over the
code on Intel CPUs. These don't currently have their own driver and it is
not clear whether having a driver makes sense.
An example is the Memory Controller Hub (MCH). We map it to a known location
on some Intel chips (mostly those without FSP - Firmware Support Package).
Add a new header file for these registers, and move MCH into it.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Sat, 12 Mar 2016 05:06:51 +0000 (22:06 -0700)]
x86: Allow use of serial soon after relocation
At present on x86 machines with use cache-as-RAM, the memory goes away just
before board_init_r() is called. This means that serial drivers are
no-longer unavailable, until initr_dm() it called, etc.
Any attempt to use printf() within this period will cause a hang.
To fix this, mark the serial devices as 'unavailable' when it is no-longer
available. Bring it back when serial_initialize() is called. This means that
the debug UART will be used instead for this period.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Sat, 12 Mar 2016 05:06:49 +0000 (22:06 -0700)]
syscon: Avoid returning a device on failure
If the device cannot be probed, syscon_get_by_driver_data() will still
return a useful value in its devp parameter. Ensure that it returns NULL
instead.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Sat, 12 Mar 2016 05:06:46 +0000 (22:06 -0700)]
dm: timer: Correct timer init ordering after relocation
Commit 1057e6c broke use of the timer with driver model. If the timer is used
before relocation, then it becomes broken after relocation. This prevents
some x86 boards from booting. Fix it.
Fixes: 1057e6c (timer: Set up the real timer after driver model is available) Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Mon, 7 Mar 2016 02:28:25 +0000 (19:28 -0700)]
x86: Add comments to the SIPI vector
The Intel SIPI (start-up inter-processor interrupt) vector is the entry
point for each secondary CPU (also called an AP - applications processor).
The assembler and C code are linked, so add comments to indicate this.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Mon, 7 Mar 2016 02:28:22 +0000 (19:28 -0700)]
x86: Tidy up mp_init to reduce duplication
The timeout step is always 50us. By updating apic_wait_timeout() to print
the debug messages we can simplify the code. Also tidy up a few messages and
comments while we are here.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Mon, 7 Mar 2016 02:28:13 +0000 (19:28 -0700)]
x86: gpio: Correct GPIO setup ordering
The Intel GPIO driver can set up the GPIO pin mapping when the first GPIO
is probed. However, it assumes that the first GPIO to be probed is in the
first GPIO bank. If this is not the case then the init will write to the
wrong registers.
Fix this. Also add a note that this code is deprecated. We should move to
using device tree instead.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Mon, 7 Mar 2016 02:28:11 +0000 (19:28 -0700)]
x86: dts: link: Move SPD info into the memory controller
The SDRAM SPD (Serial Presence Detect) information should be contained
with the SDRAM controller. This makes it easier for the controller to access
it and removes the need for a separate compatible string.
As a first step, move the information.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Mon, 7 Mar 2016 02:28:04 +0000 (19:28 -0700)]
x86: Add some more common MSR indexes
Many of the model-specific indexes are common to several Intel CPUs. Add
some more common ones, and remove them from the ivybridge-specific header
file.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Mon, 7 Mar 2016 02:27:52 +0000 (19:27 -0700)]
pci: Add functions to update PCI configuration registers
It is common to read a config register value, clear and set some bits, then
write back the updated value. Add functions to do this in one step, for
convenience.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Mon, 7 Mar 2016 02:27:50 +0000 (19:27 -0700)]
gpio: Add a function to obtain a GPIO vector value
We can use GPIOs as binary digits for reading 'strapping' values. Each GPIO
is assigned a single bit and can be set high or low on the circuit board. We
already have a legacy function for reading these values. Add one that
supports driver model.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Mon, 7 Mar 2016 02:27:49 +0000 (19:27 -0700)]
cpu: Add support for microcode version and CPU ID
Some CPUs use microcode and each core can have a different version of
microcode loaded. Also some CPUs support the concept of an integer ID used
for identification purposes. Add support for these in the CPU uclass.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Mon, 7 Mar 2016 02:27:48 +0000 (19:27 -0700)]
video: Allow simple-panel to be used without regulators
At present simple-panel requires regulator support and will not build
without it. But some panels do not have a power supply, or at least not one
that can be controlled. Update the implementation to cope with this.
Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Anatolij Gustschin <agust@denx.de>
Bin Meng [Mon, 29 Feb 2016 07:54:50 +0000 (23:54 -0800)]
x86: Support booting SeaBIOS
SeaBIOS is an open source implementation of a 16-bit x86 BIOS.
It can run in an emulator or natively on x86 hardware with the
use of coreboot. With SeaBIOS's help, we can boot some OSes
that require 16-bit BIOS services like Windows/DOS.
As U-Boot, we have to manually create a table where SeaBIOS gets
system information (eg: E820) from. The table unfortunately has
to follow the coreboot table format as SeaBIOS currently supports
booting as a coreboot payload.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Bin Meng [Sun, 28 Feb 2016 06:58:02 +0000 (22:58 -0800)]
x86: Support writing configuration tables in high area
For those secondary bootloaders like SeaBIOS who want to live in
the F segment, which conflicts the configuration table address,
now we allow write_tables() to write the configuration tables in
high area (malloc'ed memory).
Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Tom Rini [Tue, 15 Mar 2016 21:56:29 +0000 (17:56 -0400)]
spl: arm: Make sure to include all of the u_boot_list entries
Starting with 96e5b03 we use a linker list for partition table
information. However since we use this in SPL we need to make sure that
the SPL linker scripts include these as well. While doing this, it's
best to simply include all linker lists to future proof ourselves.
Cc: Andreas Bießmann <andreas.devel@googlemail.com> Acked-by: Michal Simek <michal.simek@xilinx.com> Reviewed-by: Simon Glass <sjg@chromium.org> Reported-by: Nishanth Menon <nm@ti.com> Tested-by: Nishanth Menon <nm@ti.com> Signed-off-by: Tom Rini <trini@konsulko.com>
Tom Rini [Wed, 16 Mar 2016 19:25:46 +0000 (15:25 -0400)]
mvebu: ds414: Move cmd_syno into ds414 directory
When we switch to including all linker lists in SPL it is important to
not include commands as that may lead to link errors due to other things
we have already discarded. In this case as we don't have other common
code nor other Synology borads, move the cmd_syno.c file (which claims
to be ds414 specific anyways!) into the ds414 directory and only build
it for non-SPL builds.
Tom Rini [Wed, 16 Mar 2016 14:38:21 +0000 (10:38 -0400)]
arm: omap-common: Guard some parts of the code with CONFIG_OMAP44XX/OMAP54XX
On OMAP4 platforms that also need to calculate their DDR settings we are
now getting very close to the linker limit size. Since OMAP44XX is only
seen with LPDDR2, remove some run time tests for LPDDR2 or DDR3 as we
will know that we don't have it for OMAP44XX.
Cc: Nishanth Menon <nm@ti.com> Signed-off-by: Tom Rini <trini@konsulko.com>
Tom Rini [Wed, 16 Mar 2016 13:56:55 +0000 (09:56 -0400)]
lpc32xx: work_92105: Rework Makefile
When we switch to including all linker lists in SPL it is important
to not include commands as that may lead to link errors due to other
things we have already discarded. In this case change things so that we
only build the right objects for SPL or non-SPL
Cc: Albert ARIBAUD (3ADEV) <albert.aribaud@3adev.fr> Signed-off-by: Tom Rini <trini@konsulko.com>
Tom Rini [Wed, 16 Mar 2016 13:45:03 +0000 (09:45 -0400)]
cmd: scsi: Group the command portion together, guard with !CONFIG_SPL_BUILD
When we switch to including all linker lists in SPL it is important
to not include commands as that may lead to link errors due to other
things we have already discarded. In this case, the SCSI code needs a lot
of attention so for now just guard the command portions.
Tom Rini [Wed, 16 Mar 2016 13:24:00 +0000 (09:24 -0400)]
ARM: keystone2: Only link cmd_ddr3.o on non-SPL builds
When we switch to including all linker lists in SPL it is important
to not include commands as that may lead to link errors due to other
things we have already discarded. In this case simply move cmd_ddr3.o
over to the list with the rest.
Tom Rini [Wed, 16 Mar 2016 13:10:08 +0000 (09:10 -0400)]
ARM: keystone2: Split monitor code / command code
When we switch to including all linker lists in SPL it is important
to not include commands as that may lead to link errors due to other
things we have already discarded. In this case, we split the code for
supporting the monitor out from the code for loading it.