Bin Meng [Wed, 22 Jul 2015 08:21:10 +0000 (01:21 -0700)]
x86: mpspec: Move writing ISA interrupt entry after PCI
On some platforms the I/O APIC interrupt pin#0-15 may be connected
to platform pci devices' interrupt pin. In such cases the legacy ISA
IRQ is not available so we should not write ISA interrupt entry if
it is already occupied.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
Bin Meng [Wed, 22 Jul 2015 08:21:09 +0000 (01:21 -0700)]
x86: mpspec: Allow platform to determine how PIRQ is connected to I/O APIC
Currently during writing MP table I/O interrupt assignment entry, we
assume the PIRQ is directly mapped to I/O APIC INTPIN#16-23, which
however is not always the case on some platforms.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
Bin Meng [Sat, 18 Jul 2015 16:20:06 +0000 (00:20 +0800)]
dm: pci: Support bridge device configuration correctly
Commit aec241d "dm: pci: Use the correct hose when configuring devices"
was an attempt to fix pci bridge device configuration, but unfortunately
that does not work 100%. In pciauto_config_devices(), the fix tried to
call pciauto_config_device() with a ctlr_hose which is supposed to be
the root controller hose, however when walking through a pci topology
with 2 or more pci bridges this logic simply fails.
The call chain is: pciauto_config_devices()->pciauto_config_device()
->dm_pci_hose_probe_bus(). Here the call to dm_pci_hose_probe_bus()
does not make any sense as the given hose is not the bridge device's
hose, instead it is either the root controller's hose (case#1: if it
is the 2nd pci bridge), or the bridge's parent bridge's hose (case#2:
if it is the 3rd pci bridge). In both cases the logic is wrong.
For example, for failing case#1 if the bridge device to config has the
same devfn as one of the devices under the root controller, the call
to pci_bus_find_devfn() will return the udevice of that pci device
under the root controller as the bus, but this is wrong as the udevice
is not a bus which does not contain all the necessary bits associated
with the udevice which causes further failures.
To correctly support pci bridge device configuration, we should still
call pciauto_config_device() with the pci bridge's hose directly.
In order to access valid pci region information, we need to refer to
the root controller simply by a call to pci_bus_to_hose(0) and get the
region information there in the pciauto_prescan_setup_bridge(),
pciauto_postscan_setup_bridge() and pciauto_config_device().
Bin Meng [Sat, 18 Jul 2015 16:20:05 +0000 (00:20 +0800)]
dm: pci: Pass only device/function to pci_bus_find_devfn()
In dm_pci_hose_probe_bus(), pci_bus_find_devfn() is called with a bdf
which includes a bus number, but it really should not as this routine
only expects a device/function encoding.
Bin Meng [Sat, 18 Jul 2015 16:20:04 +0000 (00:20 +0800)]
dm: pci: Use complete bdf in all pci config read/write routines
Currently pci_bus_read_config() and pci_bus_write_config() are
called with bus number masked off in the parameter bdf, and bus
number is supposed to be added back in the bridge driver's pci
config read/write ops if the device is behind a pci bridge.
However this logic only works for a pci topology where there is
only one bridge off the root controller. If there is addtional
bridge in the system, the logic will create a non-existent bdf
where its bus number gets accumulated across bridges.
To correct this, we change all pci config read/write routines
to use complete bdf all the way up to the root controller.
Bin Meng [Sat, 18 Jul 2015 16:20:03 +0000 (00:20 +0800)]
dm: pci: Correct primary/secondary/subordinate bus number assignment
In driver model, each pci bridge device has its own hose structure.
hose->first_busno points to the bridge device's device number, so
we should not substract hose->first_busno before programming the
bridge device's primary/secondary/subordinate bus number registers.
Bin Meng [Fri, 10 Jul 2015 02:51:23 +0000 (10:51 +0800)]
x86: Simplify architecture defined exception handling in irq_llsr()
Instead of using switch..case for architecture defined exceptions,
simply unify the handling by printing a message of exception name,
followed by registers dump then halt the CPU.
With this unification, it also fixes the wrong exception numbers
for #MF/#AC/#MC/#XM which should be 16/17/18/19 not 15/16/17/18.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
Bin Meng [Fri, 10 Jul 2015 02:38:32 +0000 (10:38 +0800)]
x86: Display correct CS/EIP/EFLAGS when there is an error code
Some exceptions cause an error code to be saved on the current stack
after the EIP value. We should extract CS/EIP/EFLAGS from different
position on the stack based on the exception number.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
Michal Simek [Wed, 22 Jul 2015 09:03:36 +0000 (11:03 +0200)]
ARM: zynq: DT: Cleanup address-cells and size-cells
Remove unneeded address-cells form intc node because it is already setup
in parent node.
Add missing address-cells and size-cells to eth node to be shared for
every platform DTSes.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Michal Simek [Wed, 22 Jul 2015 08:51:16 +0000 (10:51 +0200)]
ARM: zynq: DT: Use the zynq binding with macb
Use the new zynq binding for macb ethernet, since it will disable half
duplex gigabit like the Zynq TRM says to do. Also allow the compatible
cadence gem binding that won't disable half duplex but works otherwise.
Michal Simek [Wed, 22 Jul 2015 08:42:51 +0000 (10:42 +0200)]
ARM: zynq: DT: Remove 222 MHz OPP
Due to dependencies between timer and CPU frequency, only changes by
powers of two are allowed. The clocksource driver prevents other
changes, but with cpufreq and its governors it can result in being
spammed with error messages constantly. Hence, remove the 222 MHz OPP.
Signed-off-by: Soren Brinkmann <soren.brinkmann@xilinx.com> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Michal Simek [Wed, 22 Jul 2015 08:40:51 +0000 (10:40 +0200)]
ARM: zynq: DT: Migrate UART to Cadence binding
The Zynq UART is Cadence IP and the driver has been renamed accordingly.
Migrate the DT to use the new binding for the UART driver.
Signed-off-by: Soren Brinkmann <soren.brinkmann@xilinx.com> Acked-by: Peter Crosthwaite <peter.crosthwaite@xilinx.com> Acked-by: Rob Herring <robh@kernel.org> Tested-by: Michal Simek <michal.simek@xilinx.com> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Michal Simek [Wed, 22 Jul 2015 08:38:45 +0000 (10:38 +0200)]
ARM: zynq: DT: Add a fixed regulator for CPU voltage
To silence the warning
cpufreq_cpu0: failed to get cpu0 regulator: -19
from the cpufreq driver regarding a missing regulator,
add a fixed regulator to the DT.
Zynq does not support voltage scaling and the CPU rail should always be
supplied with 1 V, hence it is added in the SOC-level dtsi.
Signed-off-by: Soren Brinkmann <soren.brinkmann@xilinx.com> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Define a new config "zynqmp_ep" for ZynqMP instead
of xilinx_zynqmp. This defconfig supports all emulation
platforms of ZynqMP. Also renamed TARGET_XILINX_ZYNQMP
to ARCH_ZYNQMP.
Signed-off-by: Siva Durga Prasad Paladugu <sivadur@xilinx.com> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
zynq: gem: Increase the Rx buffer descriptors to 32
Increase the Rx Buffer descriptors to 32. This will avoid
Rx buffer descriptors overflow if more packets were received
at one shot before we process the received ones.
This fixes the issue of intermittent timeouts during tftp
on a 1Gb connection with tftp server running on windows.
Signed-off-by: Siva Durga Prasad Paladugu <sivadur@xilinx.com> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
The encoding of the sub instruction used to handle CONFIG_SYS_MALLOC_F_LEN
can only accept certain values, and the set of acceptable values differs
between the AArch32 and AArch64 instructions sets. The default value of
CONFIG_SYS_MALLOC_F_LEN works with either ISA. Tegra uses a non-default
value that can only be encoded in the AArch32 ISA. Fix the AArch64 crt0
assembly so it can handle completely arbitrary values.
Signed-off-by: Thierry Reding <treding@nvidia.com>
[twarren: trimmed Thierry's patch to remove changes already present] Signed-off-by: Tom Warren <twarren@nvidia.com>
[swarren, cleaned up patch, wrote description, re-wrote subject] Signed-off-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
[swarren, stripped out changes not strictly related to warnings] Signed-off-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Tom Warren <twarren@nvidia.com> Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Tom Rini <trini@konsulko.com> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Warren <twarren@nvidia.com>
Stephen Warren [Tue, 21 Jul 2015 23:49:41 +0000 (17:49 -0600)]
pxe: add AArch64 image support
The sysboot and pxe commands currently support either U-Boot formats or
raw zImages. Add support for the AArch64 Linux port's native image format
too.
As with zImage support, there is no auto-detection of the native image
format. Rather, if the image is auto-detected as a U-Boot format, U-Boot
will try to interpret it as such. Otherwise, U-Boot will fall back to a
raw/native image format, if one is enabled.
My belief is that CONFIG_CMD_BOOTZ won't ever be enabled for any AArch64
port, hence there's never a need to differentiate between CONFIG_CMD_
_BOOTI and _BOOTZ at run-time; compile-time will do. Even if this isn't
true, we want to prefer _BOOTI over _BOOTZ when defined, since _BOOTI is
definitely the native format for AArch64.
Change-Id: I83c5cc7566032afd72516de46f4e5eb7a780284a Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
Reproducible U-Boot build support, using SOURCE_DATE_EPOCH
In order to achieve reproducible builds in U-Boot, timestamps that are defined
at build-time have to be somewhat eliminated. The SOURCE_DATE_EPOCH environment
variable allows setting a fixed value for those timestamps.
Simply by setting SOURCE_DATE_EPOCH to a fixed value, a number of targets can be
built reproducibly. This is the case for e.g. sunxi devices.
However, some other devices might need some more tweaks, especially regarding
the image generation tools.
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
configs: k2*_evm: rename skernel binary names to generated file names
using http://git.ti.com/keystone-linux/boot-monitor/trees/master as
reference (tag K2_BM_15.07) the generated files do not have evm
extensions by default. So dont use -evm extension.
configs: ti_armv7_keystone2: switch to using kernel zImage
Switch to using zImage instead of uImage. and while at it, start using
bootz as default. While at it, get rid of BOOTIMAGE define and start
using Linux upstream dtb file names.
configs: ti_armv7_keystone2: start using armv7_common
Try to maintain as much commonality by conditionally including stuff
in armv7_common as necessary and removing the common defines from
keystone2 header.
Note: as part of this change, all keystone2 platforms will now start
using the generic u-boot prompt instead of the custom prompt.
Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
configs: ti: armv7_common: enable Thumb mode for all
Commit bd2c4522c26d5 ("ti: armv7: enable EXT support in SPL (using
ti_armv7_common.h)") enabled thumb mode only for SPL builds, however,
All TI armv7 platforms do support thumb, and there is no reason why the
space savings cannot be exploited for u-boot as well.
Reported-by: Murali Karicheri <m-karicheri2@ti.com> Suggested-by: Tom Rini <trini@konsulko.com> Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
configs: split ti_armv7_common into a omap generic header
TI armv7 based SoCs are based on two architectures - one based on OMAP
generation architecture and others based on Keystone architecture.
Many of the options are architecture specific, however a lot are common
with v7 architecture. So, step 1 will be to move out OMAP specific stuff
from ti_armv7_common into a ti_armv7_omap.h header which is then used
by all the relevant architecture headers.
Reviewed-by: Tom Rini <trini@konsulko.com> Signed-off-by: Nishanth Menon <nm@ti.com>
Antonio Borneo [Sun, 19 Jul 2015 14:19:48 +0000 (22:19 +0800)]
stm32f429: use 180 MHz system clock
Mainline Linux kernel commit 338a6aaabc02fa63b70441dd0e1b70aea64673c6 (ARM: dts: Introduce
STM32F429 MCU) in arch/arm/boot/dts/stm32f429.dtsi
requires U-Boot to set system clock to 180 MHz.
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
To: Albert Aribaud <albert.u.boot@aribaud.net>
To: Tom Rini <trini@konsulko.com>
To: Kamil Lulko <rev13@wp.pl> Cc: u-boot@lists.denx.de
Antonio Borneo [Sun, 19 Jul 2015 14:19:47 +0000 (22:19 +0800)]
stm32f4: add cpu clock option for 180 MHz
While most stm32f4 run at 168 MHz, stm32f429 can work till 180 MHz.
Add option to select 180 MHz through macro CONFIG_SYS_CLK_FREQ.
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
To: Albert Aribaud <albert.u.boot@aribaud.net>
To: Tom Rini <trini@konsulko.com>
To: Kamil Lulko <rev13@wp.pl> Cc: u-boot@lists.denx.de
Antonio Borneo [Sun, 19 Jul 2015 14:19:46 +0000 (22:19 +0800)]
stm32f429: pass the device unique ID in DTB
Read device unique ID and set environment variable "serial#".
Value would then be passed to kernel through DTB.
To read ID from DTB, kernel is required to have commit: 3f599875e5202986b350618a617527ab441bf206 (ARM: 8355/1: arch: Show
the serial number from devicetree in cpuinfo)
This commit is already mainline since v4.1-rc1.
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
To: Albert Aribaud <albert.u.boot@aribaud.net>
To: Tom Rini <trini@konsulko.com>
To: Kamil Lulko <rev13@wp.pl> Cc: u-boot@lists.denx.de
Because the top-level Makefile forces all the source files
to include include/linux/kconfig.h (see the UBOOTINCLUDE define),
these includes are redundant.
By the way, there are exceptions for the statement above; host
programs. In fact, host tools in U-Boot depend on a particular
board configuration, although I think they should not. So, some
files still include <linux/config.h> to work around build errors
on host tools.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Ian Campbell <ijc@hellion.org.uk> Acked-by: Simon Glass <sjg@chromium.org>
All am33xx device tree are using device-tree, so get_board_rev is never actually
called. Thus, we can get rid of it to make the code easier to maintain.
Signed-off-by: Paul Kocialkowski <contact@paulk.fr> Reviewed-by: Tom Rini <trini@konsulko.com>
omap-common: SYS_BOOT-based fallback boot device selection for peripheral boot
OMAP devices might boot from peripheral devices, such as UART or USB.
When that happens, the U-Boot SPL tries to boot the next stage (complete U-Boot)
from that peripheral device, but in most cases, this is not a valid boot device.
This introduces a fallback option that reads the SYS_BOOT pins, that are used by
the bootrom to determine which device to boot from. It is intended for the
SYS_BOOT value to be interpreted in the memory-preferred scheme, so that the
U-Boot SPL can load the next stage from a valid location.
Practically, this options allows loading the U-Boot SPL through USB and have it
load the next stage according to the memory device selected by SYS_BOOT instead
of stalling.
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
siemens-am33x-common: Hardcoded value instead of non-included define
The config file for the siemens-am33x-common was using OMAP_I2C_STANDARD, which
is defined in a header that is not included in the config header. In most cases,
it was being included by the code using CONFIG_SYS_OMAP24_I2C_SPEED, but it
might not always be the case.
In particular, when introducing I2C SPL support in omap-common's boot-common.c,
the header is missing and including it breaks other devices.
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
omap-common: Common boot code OMAP3 support and cleanup
This introduces OMAP3 support for the common omap boot code, as well as a
major cleanup of the common omap boot code.
First, the omap_boot_parameters structure becomes platform-specific, since its
definition differs a bit across omap platforms. The offsets are removed as well
since it is U-Boot's coding style to use structures for mapping such kind of
data (in the sense that it is similar to registers). It is correct to assume
that romcode structure encoding is the same as U-Boot, given the description
of these structures in the TRMs.
The original address provided by the bootrom is passed to the U-Boot binary
instead of a duplicate of the structure stored in global data. This allows to
have only the relevant (boot device and mode) information stored in global data.
It is also expected that the address where the bootrom stores that information
is not overridden by the U-Boot SPL or U-Boot.
The save_omap_boot_params is expected to handle all special cases where the data
provided by the bootrom cannot be used as-is, so that spl_boot_device and
spl_boot_mode only return the data from global data.
All of this is only relevant when the U-Boot SPL is used. In cases it is not,
save_boot_params should fallback to its weak (or board-specific) definition.
save_omap_boot_params should not be called in that context either.
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
kbuild: create symbolic link only for ARM, AVR32, SPARC, PowerPC, x86
The symbolic link to SoC/CPU specific header directory is created
during the build, while it is only necessary for ARM, AVR32, SPARC,
x86, and some CPUs of PowerPC. For the other architectures, it just
results in a broken symbolic link.
Introduce CONFIG_CREATE_ARCH_SYMLINK to not create unneeded symbolic
links.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Simon Glass <sjg@chromium.org>
generic_board: Call "checkboard" even though the root node has a "model" property
In case of enable CONFIG_OF_CONTROL and has a "model" property in the root node,
the board special "checkboard" will not be called.
Usually we show some useful version information in the function.
This patch enable call "checkboard" in any case.
It is not conflicting with showing "model" at the same time.
For example on LS2085AQDS:
Showing "model" only:
Model: Freescale Layerscape 2085a QDS Board
keystone2: net: add mcast function to keyston2 Ethernet driver
The MCAST_TFTP support requires that network drivers has mcast functon
implemented. This commit adds dummy keystone2_eth_bcast_addr() to meet
the requirement. As far as the driver doesn't use ALE and doesn't filter
any incoming packets, the function is empty.
Signed-off-by: Vitaly Andrianov <vitalya@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
When core A turning of core B, via tetris DPSC it places the core
B DPSC into transitional state. The core B has to execute wfi instruction
to move its DPSC to the OFF state. This patch add such instruction.
Signed-off-by: Vitaly Andrianov <vitalya@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
Stefan Roese [Mon, 6 Jul 2015 11:35:55 +0000 (13:35 +0200)]
misc: led: pca9551_led: Fix problem with multiple blink frequencies
Only 2 frequencies are supported. The current driver implementation does
not always use the 2 last configured blink frequencies. This patch
fixes this problem. So that the last two entered frequencies are
active.
Signed-off-by: Stefan Roese <sr@denx.de> Cc: Fabio Estevam <fabio.estevam@freescale.com> Cc: Tom Rini <trini@konsulko.com>
kbuild: use relative path more to include Makefile
Prior to this commit, it was impossible to use relative path to
include Makefiles from the top level Makefile because the option
"--include-dir=$(srctree)" becomes effective when Make enters into
sub Makefiles.
To use relative path in any places, this commit moves the option
above the "sub-make" target.
This was imported from Linux (commit a436bb7b8063) and adjusted for
U-Boot.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Michal Marek <mmarek@suse.cz>
projects / karo-tx-uboot.git / log