Fabio Estevam [Fri, 25 Mar 2016 14:37:04 +0000 (11:37 -0300)]
mx6sabresd: Remove unneeded enable_lvds() function
enable_lvds() function only set bits IOMUXC_GPR2_DATA_WIDTH_CH0_18BIT and
IOMUXC_GPR2_DATA_WIDTH_CH1_18BIT, but these bits were already set
previously inside setup_display().
Peng Fan [Thu, 3 Mar 2016 07:56:02 +0000 (15:56 +0800)]
imx: mx7d: move MX7D to Kconfig entry
If including MX7D in CONFIG_SYS_EXTRA_OPTIONS, CONFIG_ROM_UNIFIED_SECTIONS
will not effect.So move MX7D to Kconfig entry from CONFIG_SYS_EXTRA_OPTIONS to
"select MX7D" to boards using i.MX7 Dual.
Peng Fan [Thu, 3 Mar 2016 07:56:01 +0000 (15:56 +0800)]
imx: mx6sx: move MX6SX to Kconfig entry
If including MX6SX in CONFIG_SYS_EXTRA_OPTIONS, CONFIG_ROM_UNIFIED_SECTIONS
will not effect.So move MX6SX to Kconfig entry from CONFIG_SYS_EXTRA_OPTIONS to
"select MX6SX" to boards using i.MX6 SoloX.
Since the MX6UL/SL/SX only has one DDR channel, in CCM_CCDR register
the bit[17] for mmdc_ch0 is reserved and its proper state should be 1.
When clear this bit, the periph_clk_sel cannot be set and that
CDHIPR[periph_clk_sel_busy] handshake never clears.
Signed-off-by: Ye Li <ye.li@nxp.com> Signed-off-by: Peng Fan <van.freenix@gmail.com> Acked-by: Stefano Babic <sbabic@denx.de>
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>
projects / u-boot / log