Tom Warren [Mon, 22 Jun 2015 20:03:44 +0000 (13:03 -0700)]
Tegra: clocks: Add 38.4MHz OSC support for T210 use
Added 38.4MHz/48MHz entries to pll_x_table for CPU PLL. Needs
to be measured - should be close to 700MHz (1.4G/2).
Note that some freqs aren't in the PLLU table in T210 TRM
(13, 26MHz), so I used the 12MHz table entry for them. They
shouldn't be selected since they're not viable T210 OSC freqs.
Since there are now 2 new OSC defines, all tables (pll_x_table,
PLLU) had to increase by two entries, but since 38.4/48MHz are
not viable osc freqs on T20/30/114, etc, they're just set to 0.
Tom Warren [Tue, 28 Jul 2015 22:16:38 +0000 (15:16 -0700)]
T210: P2571: Restore USB gadget mode (ums)
The tegra-common-usb-gadget.h include was causing
some build problems in ci_udc.c with a 64-bit gcc
in an earlier version of the T210 patches, but it
is working fine now, so restore it.
Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
Marek Vasut [Wed, 5 Aug 2015 01:19:22 +0000 (03:19 +0200)]
usb: Fix device detection code
The code in question polls an USB port status via USB_REQ_GET_STATUS
to determine whether there is a device on the port or not. The way to
figure that out is to check two bits. Those are wPortChange[0] and
wPortStatus[0].
The wPortChange[0] indicates whether some kind of a connection status
change happened on a port (a device was plugged or unplugged). The
wPortStatus[0] bit indicates the status of the connection (plugged or
unplugged).
The current code tests whether wPortChange[0] == wPortStatus[0] and
if that's the case, considers the loop polling for the presence of a
USB device on port finished.
This works for most USB sticks, since they come up really quickly and
trigger the USB port change detection before the first iteration of the
detection loop happens. Thus, both wPortChange[0] and wPortStatus[0]
are set to 1 and thus equal. The loop is existed in it's first iteration
and the stick is detected correctly.
The problem is with some obscure USB sticks, which take some time before
they pop up on the bus after the port was enabled. In this case, both
the wPortChange[0] and wPortStatus[0] are 0. They are equal again, so
the loop again exits in the first iteration, but this is incorrect, as
such USB stick didn't have the opportunity to get detected on the bus.
Rework the code such, that it checks for wPortChange[0] first to test
if any connection change happened at all. If no change occured, keep
polling. If a change did occur, test the wPortStatus[0] to see there is
some device present on the port and only if this is the case, break out
of the polling loop.
This patch also trims down the duration of the polling loop from 10s
per port to 1s per port. This is still annoyingly long, but there is
no better option in case of U-Boot unfortunatelly. This change will
most likely increase the duration of 'usb start' on some platforms,
but this is needed to fix a bug.
Signed-off-by: Marek Vasut <marex@denx.de> Cc: Simon Glass <sjg@chromium.org> Cc: Hans de Goede <hdegoede@redhat.com>
Marcel Ziswiler [Wed, 5 Aug 2015 15:16:59 +0000 (17:16 +0200)]
net: asix: fix operation without eeprom
This patch fixes operation of our on-board AX88772B chip without EEPROM
but with a ethaddr coming from the regular U-Boot environment. This is
a forward port of some remaining parts initially implemented by
Antmicro.
Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com> Acked-by: Marek Vasut <marex@denx.de>
sunxi: usb: USB_MUSB_SUNXI move to musb-new Kconfig
Now that the musb-new driver has a Kconfig, we can move Kconfig options to
enable controllers to it, so that it's easier in e.g. menuconfig.
In addition, this allows declaring support for USB_MUSB_HOST/GADGET in
defconfigs instead of the USB_MUSB_SUNXI controller, that will get selected
automatically when needed.
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
usb: musb-new: Kconfig support for USB_MUSB_HOST and USB_MUSB_GADGET
Having MUSB_HOST and MUSB_GADGET in Kconfig allows more flexibility with regard
to what Kconfig options to enable, such as USB_STORAGE or USB_KEYBOARD.
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
usb: musb-new: CONFIG_MUSB prefix replacement with CONFIG_USB_MUSB
USB-related options are usually prefixed with CONFIG_USB and platform-specific
adaptation for the MUSB controller already have a CONFIG_USB_MUSB prefix, so
this switches all MUSB-related options to a CONFIG_USB_MUSB prefix, for
consistency.
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
usb: Generic USB Kconfig option, that fits both host and gadget and comments
There is no particular reason why the USB Kconfig option should be specific to
host mode. In prevision of adding MUSB host and gadget to Kconfig, this moves
the title and help message of the USB Kconfig option to a more generic format.
Adding comments to the usb Kconfig allows for a better separation and more
readability in generated configs and in menuconfig.
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Simon Glass [Tue, 4 Aug 2015 18:34:04 +0000 (12:34 -0600)]
x86: Gracefully disable the vesa driver when running from EFI
We cannot use this driver when running from EFI as we have no direct hardware
access. In fact coreboot uses a different driver which uses tables provided
by coreboot. So far it does not seem possible to use a normal video driver
when booting from EFI.
Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Anatolij Gustschin <agust@denx.de> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Tue, 4 Aug 2015 18:34:02 +0000 (12:34 -0600)]
x86: baytrail: Support operation as an EFI payload
Disable a few things which interfere with the EFI init. This allows the
Minnowboard MAX to boot into EFI, load a U-Boot payload then boot to the
U-Boot prompt.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Tue, 4 Aug 2015 18:34:01 +0000 (12:34 -0600)]
x86: Add helper code for running from EFI
When U-Boot is running from EFI some of the x86 init is replaced with
EFI-specific init. For example, since DRAM has already been set up, we only
need to find it, not init it. Add these functions so that boards can easily
allow booting from EFI if required.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Tue, 4 Aug 2015 18:34:00 +0000 (12:34 -0600)]
x86: Handle running as EFI payload
When U-Boot runs as an EFI payload it needs to avoid setting up the CPU
again. Also U-Boot currently does not handle interrupts for many devices, so
run with interrupts disabled.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Tue, 4 Aug 2015 18:33:57 +0000 (12:33 -0600)]
x86: Add support for passing tables into U-Boot
The EFI stub provides information to U-Boot in a table. This includes the
memory map which is needed to decide where to relocate U-Boot. Collect this
information in the early init code and store it in global_data.
Fix up the BIST code at the same time since we don't have it when booting
from EFI and can assume it is 0.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Tue, 4 Aug 2015 18:33:56 +0000 (12:33 -0600)]
efi: Add 64-bit payload support
Most EFI implementations use 64-bit. Add a way to build U-Boot as a 64-bit
EFI payload. The payload unpacks a (32-bit) U-Boot and starts it. This can
be enabled for x86 boards at present.
Signed-off-by: Simon Glass <sjg@chromium.org>
Improvements to how the payload is built: Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Tue, 4 Aug 2015 18:33:55 +0000 (12:33 -0600)]
x86: Add a way to call 32-bit code from 64-bit mode
The procedure to drop from 64-bit mode to 32-bit is a bit messy. Add a
function to take care of it. It requires identity-mapped pages and that
the calling code is running below 4GB.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Tue, 4 Aug 2015 18:33:52 +0000 (12:33 -0600)]
efi: Add support for loading U-Boot through an EFI stub
It is useful to be able to load U-Boot onto a board even if is it already
running EFI. This can allow access to the U-Boot command interface, flexible
booting options and easier development.
The easiest way to do this is to build U-Boot as a binary blob and have an
EFI stub copy it into RAM. Add support for this feature, targeting 32-bit
initially.
Also add a way to detect when U-Boot has been loaded via a stub. This goes
in common.h since it needs to be widely available so that we avoid redoing
initialisation that should be skipped.
Signed-off-by: Simon Glass <sjg@chromium.org>
Improvements to how the payload is built: Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Tue, 4 Aug 2015 18:33:51 +0000 (12:33 -0600)]
x86: Add relocation and link script for a 64-bit EFI application
Add a linker script and relocation code for building 64-bit EFI
applications. This can be used for the EFI stub.
Signed-off-by: Simon Glass <sjg@chromium.org>
Improvements to how the payload is built: Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Tue, 4 Aug 2015 18:33:49 +0000 (12:33 -0600)]
x86: Allow relocation code to build without text base
This code currently requires CONFIG_SYS_TEXT_BASE but this should be
unnecessary. As a first step, remove the build-time limitation and report an
error instead.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Ben Stoltz [Tue, 4 Aug 2015 18:33:47 +0000 (12:33 -0600)]
x86: Add EFI board code
Add support for the efi-x86 board, which supports running U-Boot as an
EFI 32-bit application.
Signed-off-by: Ben Stoltz <stoltz@google.com> Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com>
Ben Stoltz [Tue, 4 Aug 2015 18:33:46 +0000 (12:33 -0600)]
x86: Add support for U-Boot as an EFI application
Add the required x86 glue code. This includes the initial start-up,
relocation and jumping to efi_main(). We also need to avoid fiddling with
interrupts.
Signed-off-by: Ben Stoltz <stoltz@google.com> Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Tue, 4 Aug 2015 18:33:43 +0000 (12:33 -0600)]
efi: Support building a u-boot-app.efi executable
Add support for building U-Boot as an EFI application with a .efi suffix.
This can be loaded by EFI provided that EFI has the same bit width (32-
or 64-bit) as U-Boot. This unfortunate limitation is imposed by EFI.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Ben Stoltz [Tue, 4 Aug 2015 18:33:42 +0000 (12:33 -0600)]
x86: Set up toolchain flags for running as EFI application
Adjust the toolchain flags to build U-Boot as a relocatable shared library,
as required by EFI.
Signed-off-by: Ben Stoltz <stoltz@google.com> Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com>
Ben Stoltz [Tue, 4 Aug 2015 18:33:41 +0000 (12:33 -0600)]
efi: Drop CONFIG_SYS_TEXT_BASE for EFI
When U-Boot runs as an EFI application is does not have a definition of
CONFIG_SYS_TEXT_BASE. U-Boot is a relocatable application and the relocation
is done by EFI. U-Boot can be loaded at any address.
Ensure that this CONFIG option is not set in this case.
Signed-off-by: Ben Stoltz <stoltz@google.com> Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Tue, 4 Aug 2015 18:33:40 +0000 (12:33 -0600)]
efi: Add a serial driver
Add a serial driver which makes use of EFI's console in/out service.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested on Intel Crown Bay and QEMU Tested-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Tue, 4 Aug 2015 18:33:39 +0000 (12:33 -0600)]
Add a way to skip relocation
When running U-Boot as an EFI application we cannot relocate since we do not
have relocation information. U-Boot has already been relocated to a suitable
address.
Add a global_data flag to control skipping relocation.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Mon, 27 Jul 2015 21:47:31 +0000 (15:47 -0600)]
x86: Update README to explain booting Ubuntu on Minnowmax
The steps required to boot a Linux distribution from U-Boot on x86 are not
very complicated, but it is a good idea to have these written down in an
accessible place.
Document how to examine the boot media from U-Boot, how to load a kernel,
load a ramdisk, set the kernel boot arguments and start the kernel. With
these instructions Ubuntu boots mostly normally on Minnowmax.
Note that the TSC timer does not operate correctly and gives warnings in
the boot log. I expect that ACPI support will solve this.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Mon, 27 Jul 2015 21:47:18 +0000 (15:47 -0600)]
pci: Indicate prefetchable memory allocate when debugging
At present the PCI output displays 'Mem' when it allocates memory for a PCI
device, whether it is prefetchable or not. There is a distinction since the
memory comes from separate pools. Use 'Prf' instead of 'Mem' when allocating
prefetchable memory.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Fri, 31 Jul 2015 15:31:38 +0000 (09:31 -0600)]
efi: Display the correct initcall pre-relocation values
With EFI the start address of U-Boot is specified differently. We could
consider just setting GD_FLG_RELOC and then setting up reloc_off. But that
flag has other implementations and we are not able to use U-Boot relocation
which this flag implies.
Instead, just add a special case for EFI.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Ben Stoltz [Fri, 31 Jul 2015 15:31:37 +0000 (09:31 -0600)]
efi: Avoid using non-existent text base
When U-Boot runs as an EFI application is does not have a definition of
CONFIG_SYS_TEXT_BASE. U-Boot is a relocatable application and the relocation
is done by EFI. U-Boot can be loaded at any address.
This is similar to how sandbox works. Adjust the early board init to deal
with this.
Signed-off-by: Ben Stoltz <stoltz@google.com> Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Fri, 31 Jul 2015 15:31:35 +0000 (09:31 -0600)]
x86: Allow use of global_data with EFI
On x86 the global_data pointer is provided through a somewhat-bizarre and
x86-specific mechanism: the F segment register is set to a pointer to the
start of global_data, so that accesses can use this build-in register.
When running as an EFI application we don't want to mess with the Global
Descriptor Table (GDT) and there is little advantage (in terms of code size)
to doing so.
Allow global_data to be a simple variable in this case.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Fri, 31 Jul 2015 15:31:28 +0000 (09:31 -0600)]
x86: Tidy up global_data flags
These flags now overlap some global ones. Adjust the x86-specific flags to
avoid this. Since this requires a change to the start.S code, add a way for
tools to find the 32-bit cold reset entry point. Previously this was at a
fixed offset.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Fri, 31 Jul 2015 15:31:27 +0000 (09:31 -0600)]
Reserve the top 16 flag bits for architecture-specific use
Add a convention that the generic global_data only occupy the bottom 16 bits
of the flags word, so that there is less chance of a conflict. At present the
x86 flags conflict.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Fri, 31 Jul 2015 15:31:23 +0000 (09:31 -0600)]
Allow objcopy to work without filling gaps with 0xff
This is currently done for all targets, since 0xff is the default erased
value for most flash devices. In some cases this is not what we want (e.g.
for EFI images) so provide a command to do a vanilla objcopy.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Fri, 31 Jul 2015 15:31:20 +0000 (09:31 -0600)]
dm: serial: Correct logic in serial_find_console_or_panic()
In a final attempt to find a console UART this function uses the first
first available serial device. However the check for a valid device is
inverted.
This code is only executed when there is in fact no serial UART, but at
present it can fail to reach the panic_str() call in this case, and start
trying to use a non-existent UART.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Fri, 31 Jul 2015 15:31:18 +0000 (09:31 -0600)]
Support removing default assembler flags
The CFLAGS_REMOVE_<file> feature allows default C compiler flags to be
removed for particular files. Add the same feature for assembler, using
AFLAGS_REMOVE_<file>.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Tom Rini <trini@konsulko.com>
Peng Fan [Tue, 28 Jul 2015 14:45:37 +0000 (22:45 +0800)]
common: command add '\n' for debug msg
Add '\n' for debug msg.
Signed-off-by: Peng Fan <Peng.Fan@freescale.com> Cc: Tom Rini <trini@konsulko.com> Cc: Masahiro Yamada <yamada.m@jp.panasonic.com> Cc: Simon Glass <sjg@chromium.org> Acked-by: Simon Glass <sjg@chromium.org>
Bin Meng [Thu, 30 Jul 2015 10:49:14 +0000 (03:49 -0700)]
x86: minnowmax: Remove smsc47x superio codes
On Intel BayTrail SoC, there is a legacy UART (I/O 0x3f8) integrated
into the SoC which is enabled by the FSP. Remove the smsc47x superio
initialization codes.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
Miao Yan [Mon, 27 Jul 2015 11:16:07 +0000 (19:16 +0800)]
x86: Add a 'pause' instruction in __udelay() for QEMU target
When running SMP configuration on QEMU (tcg mode, no kvm), there is
a busy loop in start_aps(), calling udelay(), that waits for APs to
show up online. However, there is a chance that VCPU1 will be timeout
waiting, IOW the secondary VCPUs haven't started their execution yet.
This patch adds a 'pause' instruction in __udelay() only for QEMU
target, to give other VCPUs a chance to run. When QEMU sees the
'pause' instruction, it will yeild the execution to other CPUs.
Signed-off-by: Miao Yan <yanmiaobest@gmail.com> Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org> Tested-by: Simon Glass <sjg@chromium.org>
Bin Meng [Mon, 27 Jul 2015 07:33:39 +0000 (00:33 -0700)]
dm: pci: Allow scan bridge child devices before relocation
On some platforms pci devices behind bridge need to be probed (eg:
a pci uart on recent x86 chipset) before relocation. Remove such
limitation so that dm pci can be used before relocation.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
configs: ti_armv7_keystone2: replace addr_uboot with loadaddr
This patch replaces not existing addr_uboot environment variable by
loadaddr at get_uboot_net and burn_uboot_xxx commands. Otherwise these
commands are broken.
York Sun [Thu, 23 Jul 2015 21:04:48 +0000 (14:04 -0700)]
drivers/ddr/fsl: Adjust bstopre value
By default the bstopre value has been set to 0x100, used to be 1/4
value of refint. Modern DDR has increased the refresh time. Adjust
to 1/4 of refresh interval dynamically. Individual board can still
override this value in board ddr file, or to use auto-precharge.
drivers/crypto/fsl: fix snooping for write transactions
HW coherency won't work properly for CAAM write transactions
if AWCACHE is left to default (POR) value - 4'b0001.
It has to be programmed to 4'b0010.
For platforms that have HW coherency support:
-PPC-based: the update has no effect; CAAM coherency already works
due to the IOMMU (PAMU) driver setting the correct memory coherency
attributes
-ARM-based: the update fixes cache coherency issues,
since IOMMU (SMMU) driver is not programmed to behave similar to PAMU
Fixes: b9eebfade974c ("fsl_sec: Add hardware accelerated SHA256 and SHA1") Signed-off-by: Horia Geantă <horia.geanta@freescale.com> Reviewed-by: Aneesh Bansal <aneesh.bansal@freescale.com> Reviewed-by: Mingkai Hu <Mingkai.Hu@freescale.com> Acked-by: Ruchika Gupta<ruchika.gupta@freescale.com> Reviewed-by: York Sun <yorksun@freescale.com>