Peter Chubb [Wed, 14 Sep 2016 03:49:22 +0000 (03:49 +0000)]
net: Fix cache misalignment message after network load operations
After any operation that downloads a file (e.g., pxe get, or dhcp), the
buffer containing the downloaded data is flushed. This is unnecessary
and annoying. Unnecessary, because
the network driver should already have fliushed the cache for the DMAed area,
and annoying because it generates a cache misalignment message.
Signed-off-by: Peter Chubb <peter.chubb@data61.csiro.au> Acked-by: Heiko Schocher <hs@denx.de> Acked-by: Joe Hershberger <joe.hershberger@ni.com> Reviewed-by: Tom Rini <trini@konsulko.com>
Peter Chubb [Wed, 14 Sep 2016 01:29:03 +0000 (01:29 +0000)]
rtl8169: fix cache misalignment message on transmit.
The call to flush cache on the transmit buffer was misplaced (for very
short packets) and asked to flush less than a cacheline.
Move the flush cache call to after a short packet has been padded
to minimum length (so the padding is flushed too), and round the size
up to a cacheline.
Signed-off-by: Peter Chubb <peter.chubb@data61.csiro.au> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
Chris Packham [Fri, 26 Aug 2016 05:30:26 +0000 (17:30 +1200)]
net: mv88e61xx: Add support for fixed links
On some boards these switches are wired directly into a SERDES
interface on another Ethernet MAC. Add the ability to specify
these kinds of boards using CONFIG_MV88E61XX_FIXED_PORTS which defines
a bit mask of these fixed ports.
Signed-off-by: Chris Packham <judge.packham@gmail.com> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
Chris Packham [Fri, 26 Aug 2016 05:30:25 +0000 (17:30 +1200)]
net: Add support for mv88e609x switches
The Marvell Link Street mv88e60xx is a series of FastEthernet switch
chips, some of which also support Gigabit ports. It is similar to the
mv88e61xx series which support Gigabit on all ports.
The main difference is the number of ports. Which affects the
PORT_COUNT define and the size of the mask passed to
mv88e61xx_port_set_vlan().
Other than that it's just a matter of adding the appropriate chip
IDs.
Signed-off-by: Chris Packham <judge.packham@gmail.com> Cc: Joshua Scott <joshua.scott@alliedtelesis.co.nz> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
Roger Quadros [Wed, 24 Aug 2016 12:35:51 +0000 (15:35 +0300)]
board: am335x: Always set eth/eth1addr environment variable
Ethernet ports might be used in the kernel even if CPSW driver
is disabled at u-boot. So always set ethaddr and eth1addr
environment variable from efuse.
Retain usbnet_devaddr as it is required for SPL USB eth boot.
Signed-off-by: Roger Quadros <rogerq@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Tom Rini <trini@konsulko.com> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
Both ethernet ports can be used as CPSW ethernet (RMII mode)
or PRU ethernet (MII mode) by setting the jumper near the port.
Read the jumper value and set the pinmux, external mux and
PHY clock accordingly.
As jumper line is overridden by PHY RX_DV pin immediately
after bootstrap (power-up/reset), we have to use GPIO edge
detection to capture the jumper line status.
As u-boot doesn't provide any infrastructure for GPIO edge
detection, we directly access the GPIO registers.
Signed-off-by: Roger Quadros <rogerq@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Tom Rini <trini@konsulko.com> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
Mugunthan V N [Thu, 13 Oct 2016 14:03:38 +0000 (19:33 +0530)]
driver: net: cpsw: add support for RGMII id mode support and RMII clock source selection
cpsw driver supports only selection of phy mode in control module
but control module has more setting like RGMII ID mode selection,
RMII clock source selection. So ported to cpsw-phy-sel driver
from kernel to u-boot.
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
Mugunthan V N [Thu, 13 Oct 2016 14:03:37 +0000 (19:33 +0530)]
include: configs: am335x: add Atheros phy support
In AM335x GP EVM, Atheros 8031 phy is used, enable the driver as
AM335x SoC RGMII delay mode has to be enabled in phy as mentioned
in the silicon errata Advisory 1.0.10
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
Mugunthan V N [Thu, 13 Oct 2016 14:03:36 +0000 (19:33 +0530)]
drivers: net: phy: atheros: add separate config for AR8031
In the current driver implementation, config() callback is common
for AR8035 and AR8031 phy. In config() callback, driver tries to
configure MMD Access Control Register and MMD Access Address Data
Register unconditionally for both phy versions which leads to
auto negotiation failure in AM335x EVMsk second port which uses
AR8031 Giga bit RGMII phy. Fixing this by adding separate config
for AR8031 phy.
Reviewed-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
Andrea Merello [Thu, 26 May 2016 16:24:28 +0000 (18:24 +0200)]
phy: atheros: add support for RGMII_ID, RGMII_TXID and RGMII_RXID
This adds support for internal delay on RX and TX on RGMII interface for the
AR8035 phy.
This is basically the same Linux driver do. Tested on a Zynq Zturn board (for
which u-boot support in is my tree; first patch waiting ML approval)
Signed-off-by: Andrea Merello <andrea.merello@gmail.com> Reviewed-by: Marek Vasut <marex@denx.de> Acked-by: Marek Vasut <marex@denx.de> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
Bin Meng [Sun, 9 Oct 2016 11:14:17 +0000 (04:14 -0700)]
dm: video: Don't do anything in alloc_fb() when plat->size is zero
With DM VESA driver on x86 boards, plat->base/size/align are all
zeroes and starting address passed to alloc_fb() happens to be 1MB
aligned, so this routine does not trigger any issue. On QEMU with
U-Boot as coreboot payload, the starting address is within 1MB
range (eg: 0x7fb0000), thus causes failure in video_post_bind().
Actually if plat->size is zero, it makes no sense to do anything
in this routine. Add such check there.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Bin Meng [Sun, 9 Oct 2016 11:14:13 +0000 (04:14 -0700)]
x86: Convert to use DM VESA video driver
At present only chromebook boards are converted to DM video. Other
x86 boards are still using the legacy cfb_console driver. This
switches to use DM version drivers.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Bin Meng [Sun, 9 Oct 2016 11:14:10 +0000 (04:14 -0700)]
x86: doc: Document coreboot framebuffer driver issue on QEMU
For some unknown reason, coreboot framebuffer driver never works on
QEMU since day 1. It seems the driver only works on real hardware.
Document this issue.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Simon Glass [Mon, 26 Sep 2016 03:33:31 +0000 (21:33 -0600)]
x86: Don't export interrupt handlers with x86_64
We don't have a way of adjusting these at present so it is best to refuse to
export these functions. This can be implemented later if the API is required.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Thu, 6 Oct 2016 02:42:18 +0000 (20:42 -0600)]
x86: Adjust config to support DM_VIDEO
Update the common configuration so that it works correctly when
CONFIG_DM_VIDEO is enabled. This involves dropping the legacy CONFIG_VIDEO
option and changing the stdio device from "vga" to "vidconsole".
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Thu, 6 Oct 2016 02:42:15 +0000 (20:42 -0600)]
dm: x86: video: Add a driver-model driver for ivybridge graphics
At present we use the legacy vesa driver for graphics. Add a driver which
supports driver model. This can be probed only when needed, removing the
need to start up the display if it is not used.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Thu, 6 Oct 2016 02:42:17 +0000 (20:42 -0600)]
dm: video: Add driver-model support to vesa graphics
Provide a function to run the Vesa BIOS for a given PCI device and obtain
the resulting configuration (e.g. display size) for use by the video
uclass. This makes it easier to write a video driver that uses vesa and
supports driver model.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Thu, 6 Oct 2016 02:42:16 +0000 (20:42 -0600)]
dm: stdio: Allow lazy probing of video devices
At present all video devices are probed on start-up. It would be better to
probe a device only when it is needed. This can happen if it is referenced
in the stdout environment variable, for example.
Add support for this by searching for a suitable device when needed, probing
it, and finding the stdio device it creates.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Thu, 6 Oct 2016 02:42:11 +0000 (20:42 -0600)]
Fix return value in trailing_strtoln()
This function should return -1 if there is no trailing integer in the
string. Instead it returns 0. Fix it by checking for this condition at the
start.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Thu, 6 Oct 2016 02:42:09 +0000 (20:42 -0600)]
Revert "x86: broadwell: gpio: Remove the codes to set up pin control"
This makes the assumption that setting up pinctrl in cpu_init_r() is safe.
On samus we need GPIOs before relocation in order to support power control.
This commit fixes the following message on boot:
initcall sequence ffe5c6f4 failed at call ffe01d3d (err=-1)
### ERROR ### Please RESET the board ###
In any case it seems better to leave init to driver model, so that it can
pick up the GPIO driver when it needs it. Since pinctrl is a dependency of
the GPIO driver, we may as well put the dependency there and avoid these
problems.
Stefan Roese [Fri, 30 Sep 2016 07:15:59 +0000 (09:15 +0200)]
x86: Fix Linux v4.7+ zimage booting (update bootparam.h)
Booting Linux kernel v4.7+ does not work since Linux kernel commit 974f221c
"x86/boot: Move compressed kernel to the end of the decompression buffer".
This patch adds the latest version of the setup_header struct, adding
"init_size" which is needed since this commit referenced above. With this
patch, booting Linux v4.8-rc8 does work again on x86 boards.
Signed-off-by: Stefan Roese <sr@denx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com>
Stefan Roese [Mon, 26 Sep 2016 08:18:07 +0000 (10:18 +0200)]
x86: baytrail: Add 2nd eMMC controller to the PCI probe list
With this addition, the eMMC device available on the congatec and DFI
BayTrail SoM is detected correctly.
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>
Stephen Warren [Mon, 10 Oct 2016 15:50:55 +0000 (09:50 -0600)]
ARM: tegra: reduce DRAM size mapped into MMU on ARM64
ARM CPUs can architecturally (speculatively) prefetch completely arbitrary
normal memory locations, as defined by the current translation tables. The
current MMU configuration for 64-bit Tegras maps an extremely large range
of addresses as DRAM, well beyond the actual physical maximum DRAM window,
even though U-Boot only needs access to the first 2GB of DRAM; the Tegra
port of U-Boot deliberately limits itself to 2GB of RAM since some HW
modules on at least some 64-bit Tegra SoCs can only access a 32-bit
physical address space. This change reduces the amount of RAM mapped via
the MMU to disallow the CPU from ever speculatively accessing RAM that
U-Boot will definitely not access. This avoids the possibility of the HW
raising SError due to accesses to always-invalid physical addresses.
Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
Without this patch the following error will be shown:
stdio_add_devices: Video device failed (ret=-22)
As commit ec5507707a1d1e84056a6c864338f95f6118d3ca (video: tegra: Move
to using simple-panel and pwm-backlight) states the Colibri T20 needs
updating too which this patch finally attempts doing.
Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com> Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
regulator: fixed: honour optionality of enable gpio
According to the binding documentation the fixed regulator enable GPIO
is optional. However so far registration thereof failed if no enable
GPIO was specified. Fix this by making it entirely optional whether an
enable GPIO is used.
Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com> Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
sunxi: OLinuXino Lime A20 boards: Use 384 MHz DRAM clock
We have a number of OlinuXino Lime2 boards (both NAND and eMMC versions)
which were experiencing sporadic hangs. After testing with some heavy
benchmarking and help from the Armbian forum, it was pinned down as the
DRAM settings for the board. The default is 480MHz, but this is unstable,
and even the build instructions from the vendor Olimex themselves say to
set the DRAM clock to 384. See line 96 at:
https://github.com/OLIMEX/OLINUXINO/blob/master/SOFTWARE/A20/A20-build-3.4.103-release-2/BUILD_DESCRIPTION_A20_Olimex_kernel_3.4.103%2B_Jessie_rel_2.txt
Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
sunxi: Fix H3 DRAM impedance calibration on rev. A chips
H3 seems to have a silicon bug breaking the impedance calibration.
This is currently worked around in software by multiple steps
combining the results to replace the wrong values.
Revision A chips need a different workaround, which is present in
the vendor bootloader too, but got overlooked in lack of
information and affected boards till now.
This commit adds a simplified version without correction factor,
which would be 1.00 for all known boards anyway.
Signed-off-by: Jens Kuske <jenskuske@gmail.com> Reviewed-by: Jagan Teki <jteki@openedev.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Masahiro Yamada [Sat, 8 Oct 2016 04:25:30 +0000 (13:25 +0900)]
reset: declare fdtdec_phandle_args as struct to fix warning
The of_xlate() callback needs to know fdtdec_phandle_args is struct.
Otherwise, the following warning is displayed.
include/reset-uclass.h:40:11: warning: 'struct fdtdec_phandle_args'
declared inside parameter list
struct fdtdec_phandle_args *args);
^
include/reset-uclass.h:40:11: warning: its scope is only this
definition or declaration, which is probably not what you want
Masahiro Yamada [Sat, 8 Oct 2016 04:25:29 +0000 (13:25 +0900)]
ARM: uniphier: insert udelay() just before support_card_reset_deassert()
As for LD11/LD20, we can no longer rely on the udelay() in the PLL
init functions. udelay(200) is needed here to keep the ethernet
device in the reset state for enough time. Anyway, 200 usec is
quite short for humans, so nobody cares it.
Masahiro Yamada [Sat, 8 Oct 2016 04:25:27 +0000 (13:25 +0900)]
ARM: uniphier: enable CONFIG_SYS_NO_FLASH if no CONFIG_MICRO_SUPPORT_CARD
NOR flash devices are seldom used on UniPhier platforms these days.
The only use case I see is the Micro Support Card is connected.
Otherwise, define CONFIG_SYS_NO_FLASH to disable NOR FLASH.
Masahiro Yamada [Sat, 8 Oct 2016 04:25:24 +0000 (13:25 +0900)]
ARM: uniphier: update DRAM init code for LD20 SoC (2nd)
- Do not reference CONFIG_DDR_FREQ; now the DDR frequency
is passed from the uniphier_board_data structure
- Constify parameter arrays
- Tidy up cluttered macros
- Lots of code cleanups
- Lots of coding style fixes
ARM: uniphier: do not setup pins for System Bus on NAND boot mode
For LD11 and LD20 SoCs, the System Bus and NAND are multiplexed
in the same I/O pins. When booting from a NAND device, pin-mux
for the System Bus must not be set-up because they are exclusive
with each other.
Lokesh Vutla [Tue, 4 Oct 2016 04:04:50 +0000 (09:34 +0530)]
ARM: AM437X: Add Silicon ID support
Add silicon ID code for AM437x silicon. This can be used to print
the cpu info using CONFIG_DISPLAY_CPUINFO.
Also printing "CPU :" along with cpu name in order to be consistent
with other OMAP platforms.
Reviewed-by: Tom Rini <trini@konsulko.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
B, Ravi [Wed, 28 Sep 2016 09:16:18 +0000 (14:46 +0530)]
spl: saveenv: adding saveenv support in SPL
By default saveenv option is not supported for SPL. This patch
enable the support for save environment variable for SPL build.
Enable save environment support in SPL after setenv. By default
the saveenv option is not provided in SPL, but some boards need
this support in 'Falcon' boot, where SPL need to boot from
different images based on environment variable set by OS. For
example OS may set "reboot_image" environment variable to
"recovery" inorder to boot recovery image by SPL. The SPL read
"reboot_image" and act accordingly and change the reboot_image
to default mode using setenv and save the environemnt.
Signed-off-by: Ravi Babu <ravibabu@ti.com> Reviewed-by: Simon Glass <sig@chromium.org>
change in v1:
- dropped SUPPORT, use CONFIG_SPL_SAVEENV
- updates the comments in mmc_private.h
Moritz Fischer [Tue, 27 Sep 2016 22:42:07 +0000 (15:42 -0700)]
cros_ec: Honor the google,remote-bus dt property
Boards where ECs that use a I2C port != 0 specify this in the
devicetree file via the google,remote-bus property.
Previously this was ignored and hardcoded to port 0.
Signed-off-by: Moritz Fischer <moritz.fischer@ettus.com> Cc: Simon Glass <sjg@chromium.org> Cc: Heiko Schocher <hs@denx.de> Cc: u-boot@lists.denx.de Acked-by: Simon Glass <sjg@chromium.org>
Mugunthan V N [Tue, 27 Sep 2016 07:31:41 +0000 (13:01 +0530)]
ARM: dts: dra72: add rev C evm support
Add DTS support for dra72 evm Rev C which has the following
changes
* Two ethernet ports now instead of the single one in rev B.
* DP83867 ethernet phy instead of DP838865.
Cc: Vignesh R <vigneshr@ti.com> Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
Alexander Graf [Tue, 27 Sep 2016 07:30:32 +0000 (09:30 +0200)]
arm: Add return value argument to longjmp
The normal longjmp command allows for a caller to pass the return value
of the setjmp() invocation. This patch adds that semantic to the arm
implementation of it and adjusts the efi_loader call respectively.
Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Simon Glass <sjg@chromium.org>
B, Ravi [Mon, 26 Sep 2016 12:54:08 +0000 (18:24 +0530)]
env: tool: add command line option to input lockfile path
The default lockname is set to /var/lock. This limits the
usage of this application where OS uses different lockfile
location parameter.
For example, In case of android, the default lock
path location is /data.
Hence by providing the command line option to input lockfile
path will be useful to reuse the tool across multiple
operating system.
The build failure of k2*evm boards was fixed in a different way by
the previous commit. It is nasty to patch generic drivers around
with #ifdef CONFIG_CLK just for the KeyStone's matter.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
projects / u-boot.git / log