Bin Meng [Mon, 6 Jul 2015 08:31:35 +0000 (16:31 +0800)]
x86: crownbay: Enable graphics support
Enable graphics support on Intel Crown Bay board With the help of
vgabios for Intel TunnelCreek IGD. Tested with an external LVDS
panel connected to X4 connector and SDVO adapter connected to X9
connector on the board.
Signed-off-by: Jian Luo <jian.luo4@boschrexroth.de> Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
Bin Meng [Mon, 6 Jul 2015 08:31:33 +0000 (16:31 +0800)]
x86: Move VGA option rom macros to Kconfig
Move X86_OPTION_ROM_FILE & X86_OPTION_ROM_ADDR to arch/x86/Kconfig
and rename them to VGA_BIOS_FILE & VGA_BIOS_ADDR which depend on
HAVE_VGA_BIOS. The new names are consistent with other x86 binary
blob options like HAVE_FSP/FSP_FILE/FSP_ADDR.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
Bin Meng [Mon, 6 Jul 2015 08:31:31 +0000 (16:31 +0800)]
x86: queensbay: Change CPU_ADDR_BITS to 32
Per CPUID:80000008h result, the maximum physical address bits of
TunnelCreek processor is 32 instead of default 36. This will fix
the incorrect decoding of MTRR range mask.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
Bin Meng [Mon, 6 Jul 2015 08:31:30 +0000 (16:31 +0800)]
x86: Setup fixed range MTRRs for legacy regions
We should setup fixed range MTRRs for some legacy regions like VGA
RAM and PCI ROM areas as uncacheable. Note FSP may setup these to
other cache settings, but we can override this in x86_cpu_init_f().
Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
Jian Luo [Mon, 6 Jul 2015 08:31:29 +0000 (16:31 +0800)]
video: Add 32-bit color depth support for VBE
The TunnelCreek IGD VBE reports 32-bit color depth regardless 24-bit
color depth is configured. Since 24-bit mode already uses 4 bytes
internally, it should be OK to just add this option in switch case.
Signed-off-by: Jian Luo <jian.luo4@boschrexroth.de> Acked-by: Simon Glass <sjg@chromium.org> Tested-by: Bin Meng <bmeng.cn@gmail.com>
Bin Meng [Mon, 6 Jul 2015 08:31:26 +0000 (16:31 +0800)]
video: vesa_fb: Look up VGA device by class instead of id
Per PCI spec, VGA device reports its class as standard 030000h in
its configuration space, so we can use it to determine if we need
run option rom instead of testing the supported vendor/device ids.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
Simon Glass [Sun, 7 Jun 2015 14:50:40 +0000 (08:50 -0600)]
dm: pci: Use the correct hose when configuring devices
Only the PCI controller has access to the PCI region information. Make sure
to use the controller (rather than any attached bridges) when configuring
devices.
This corrects a failure to scan and configure devices when driver model is
enabled for PCI.
So far interrupt routing works pretty well for any on-chip devices
on Intel Crown Bay. When inserting any PCIe card to any PCIe slot,
Linux kernel is smart enough to do interrupt swizzling and figure
out device's irq using its parent bridge's interrupt routing info
all the way up to its root port. In U-Boot all PCIe root ports'
interrupts were routed to PIRQ E/F/G/H before, while actually all
PCIe downstream ports received INTx are routed to PIRQ A/B/C/D
directly and not configurable. Now we change this mapping so that
any external PCIe device can work correctly.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
Bin Meng [Tue, 23 Jun 2015 04:18:52 +0000 (12:18 +0800)]
x86: Generate a valid MultiProcessor (MP) table
Implement write_mp_table() to create a minimal working MP table.
This includes an MP floating table, a configuration table header
and all of the 5 base configuration table entries. The I/O interrupt
assignment table entry is created based on the same information used
in the creation of PIRQ routing table from device tree. A check
duplicated entry logic is applied to prevent writing multiple I/O
interrupt entries with the same information.
Use a Kconfig option GENERATE_MP_TABLE to tell U-Boot whether we
need actually write the MP table at the F seg, just like we did for
PIRQ routing and SFI tables. With MP table existence, linux kernel
will switch to I/O APIC and local APIC to process all the peripheral
interrupts instead of 8259 PICs. This takes full advantage of the
multicore hardware and the SMP kernel.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
Bin Meng [Tue, 23 Jun 2015 04:18:51 +0000 (12:18 +0800)]
x86: Add MultiProcessor (MP) table APIs
The MP table provides a way for the operating system to support
for symmetric multiprocessing as well as symmetric I/O interrupt
handling with the local APIC and I/O APIC. We provide a bunch of
APIs for U-Boot to write the floating table, configuration table
header as well as base and extended table entries.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
Bin Meng [Tue, 23 Jun 2015 04:18:50 +0000 (12:18 +0800)]
x86: Remove inline for lapic access routines
Remove inline for lapic access routines and expose lapic_read()
& lapic_write() as APIs to read/write lapic registers. Also move
stop_this_cpu() to mp_init.c as it has nothing to do with lapic.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
Bin Meng [Tue, 23 Jun 2015 04:18:49 +0000 (12:18 +0800)]
x86: Add I/O APIC register access routines
I/O APIC registers are addressed indirectly. Add io_apic_read() and
io_apic_write() routines to help register access. Two macros for I/O
APIC ID and version register offset are also added.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
Bin Meng [Tue, 23 Jun 2015 04:18:47 +0000 (12:18 +0800)]
x86: Reduce PIRQ routing table size
There is no need to populate multiple irq info entries with the same
bus number and device number, but with different interrupt pin. We
can use the same entry to store all the 4 interrupt pin (INT A/B/C/D)
routing information to reduce the whole PIRQ routing table size.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
Bin Meng [Tue, 23 Jun 2015 04:18:46 +0000 (12:18 +0800)]
x86: Ignore function number when writing PIRQ routing table
In fill_irq_info() pci device's function number is written into
the table, however this is not really necessary. The function
number can be anything as OS doesn't care about this field,
neither does the PIRQ routing specification. Change to always
writing 0 as the function number.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
Bin Meng [Tue, 23 Jun 2015 04:18:44 +0000 (12:18 +0800)]
x86: queensbay: Correct Topcliff device irqs
There are 4 usb ports on the Intel Crown Bay board, 2 of which are
connected to Topcliff usb host 0 and the other 2 connected to usb
host 1. USB devices inserted in the ports connected to usb host 1
cannot get detected due to wrong IRQ assigned to the controller.
Actually we need apply the PCI interrupt pin swizzling logic to all
devices on the Topcliff chipset when configuring the PIRQ routing.
This was observed on usb ports, but device 6 and 10 irqs are also
wrong. Correct them all together.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
Bin Meng [Wed, 17 Jun 2015 03:15:39 +0000 (11:15 +0800)]
x86: crownbay: Add MP initialization
Intel Crown Bay board has a TunnelCreek processor which supports
hyper-threading. Add /cpus node in the crownbay.dts and enable
the MP initialization.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org> Signed-off-by: Simon Glass <sjg@chromium.org>
(modified to remove error:
overriding the value of OF_CONTROL. Old value: "y", new value: "y")
Bin Meng [Wed, 17 Jun 2015 03:15:38 +0000 (11:15 +0800)]
x86: Clean up lapic codes
This commit cleans up the lapic codes:
- Delete arch/x86/include/asm/lapic_def.h, and move register and bit
defines into arch/x86/include/asm/lapic.h
- Use MSR defines from msr-index.h in enable_lapic() and disable_lapic()
- Remove unnecessary stuff like NEED_LAPIC, X86_GOOD_APIC and
CONFIG_AP_IN_SIPI_WAIT
- Move struct x86_cpu_priv defines to asm/arch-ivybridge/bd82x6x.h, as
it is not apic related and only used by ivybridge
- Fix coding convention issues
Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
Bin Meng [Wed, 17 Jun 2015 03:15:37 +0000 (11:15 +0800)]
x86: Move lapic_setup() call into init_bsp()
Currently lapic_setup() is called before calling mp_init(), which
then calls init_bsp() where it calls enable_lapic(), which was
already enabled in lapic_setup(). Hence move lapic_setup() call
into init_bsp() to avoid the duplication.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
Bin Meng [Wed, 17 Jun 2015 03:15:36 +0000 (11:15 +0800)]
x86: Move MP initialization codes into a common place
Most of the MP initialization codes in arch/x86/cpu/baytrail/cpu.c is
common to all x86 processors, except detect_num_cpus() which varies
from cpu to cpu. Move these to arch/x86/cpu/cpu.c and implement the
new 'get_count' method for baytrail and cpu_x86 drivers. Now we call
cpu_get_count() in mp_init() to get the number of CPUs.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
Bin Meng [Fri, 12 Jun 2015 06:52:23 +0000 (14:52 +0800)]
x86: kconfig: Fix minor nits in MAX_CPUS
Move MAX_CPUS definition after SMP so that it shows below SMP in the
menuconfig. Also replace the leading spaces in the MAX_CPUS section
with tabs to conform coding standard.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
Bin Meng [Fri, 12 Jun 2015 06:52:20 +0000 (14:52 +0800)]
x86: dm: Clean up cpu drivers
This commit does the following to clean up x86 cpu dm drivers:
- Move cpu_x86 driver codes from arch/x86/cpu/cpu.c to a dedicated
file arch/x86/cpu/cpu_x86.c
- Rename x86_cpu_get_desc() to cpu_x86_get_desc() to keep consistent
naming with other dm drivers
- Add a new cpu_x86_bind() in the cpu_x86 driver which does exactly
the same as the one in the intel baytrail cpu driver
- Update intel baytrail cpu driver to use cpu_x86_get_desc() and
cpu_x86_bind()
Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
Simon Glass [Sun, 7 Jun 2015 14:50:32 +0000 (08:50 -0600)]
spi: sf: Print the error code on failure
Rather than just 'ERROR', display the error code, which may be useful, at
least with driver model.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Marek Vasut <marex@denx.de> Reviewed-by: Jagan Teki <jteki@openedev.com>
Bin Meng [Sun, 7 Jun 2015 03:33:14 +0000 (11:33 +0800)]
x86: fsp: Move FspInitEntry call to board_init_f()
The call to FspInitEntry is done in arch/x86/lib/fsp/fsp_car.S so far.
It worked pretty well but looks not that good. Apart from doing too
much work than just enabling CAR, it cannot read the configuration
data from device tree at that time. Now we want to move it a little
bit later as part of init_sequence_f[] being called by board_init_f().
This way it looks and works better in the U-Boot initialization path.
Due to FSP's design, after calling FspInitEntry it will not return to
its caller, instead it jumps to a continuation function which is given
by bootloader with a new stack in system memory. The original stack in
the CAR is gone, but its content is perserved by FSP and described by
a bootloader temporary memory HOB. Technically we can recover anything
we had before in the previous stack, but that is way too complicated.
To make life much easier, in the FSP continuation routine we just
simply call fsp_init_done() and jump back to car_init_ret() to redo
the whole board_init_f() initialization, but this time with a non-zero
HOB list pointer saved in U-Boot's global data so that we can bypass
the FspInitEntry for the second time.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org> Tested-by: Andrew Bradford <andrew.bradford@kodakalaris.com> Tested-by: Simon Glass <sjg@chromium.org>
Bin Meng [Sun, 7 Jun 2015 03:33:13 +0000 (11:33 +0800)]
x86: fsp: Load GDT before calling FspInitEntry
Currently the FSP execution environment GDT is setup by U-Boot in
arch/x86/cpu/start16.S, which works pretty well. But if we try to
move the FspInitEntry call a little bit later to better fit into
U-Boot's initialization sequence, FSP will fail to bring up the AP
due to #GP fault as AP's GDT is duplicated from BSP whose GDT is
now moved into CAR, and unfortunately FSP calls AP initialization
after it disables the CAR. So basically the BSP's GDT still refers
to the one in the CAR, whose content is no longer available, so
when AP starts up and loads its segment register, it blows up.
To resolve this, we load GDT before calling into FspInitEntry.
The GDT is the same one used in arch/x86/cpu/start16.S, which is
in the ROM and exists forever.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Andrew Bradford <andrew.bradford@kodakalaris.com> Tested-by: Simon Glass <sjg@chromium.org> Acked-by: Simon Glass <sjg@chromium.org>
Bin Meng [Sun, 7 Jun 2015 03:33:12 +0000 (11:33 +0800)]
x86: Add Kconfig options to be used by arch/x86/cpu/config.mk
Add RESET_SEG_START, RESET_SEG_SIZE and RESET_VEC_LOC Kconfig options
and make arch/x86/cpu/config.mk use these options.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org> Tested-by: Andrew Bradford <andrew.bradford@kodakalaris.com> Tested-by: Simon Glass <sjg@chromium.org>
Andre Przywara [Thu, 2 Jul 2015 00:04:23 +0000 (01:04 +0100)]
scsi: fix compiler warning with DEBUG and 48bit LBAs
Commit 2b42c9317db ("ahci: support LBA48 data reads for 2+TB drives")
introduced conditional code which triggers a warning when compiled
with DEBUG enabled:
In file included from common/cmd_scsi.c:12:0:
common/cmd_scsi.c: In function 'scsi_read':
include/common.h:109:4: warning: 'smallblks' may be used uninitialized in this function [-Wmaybe-uninitialized]
...
Since this is for debug only, take the easy way and initialize the
variable explicitly on declaration to avoid the warning.
(Fix a nearby whitespace error on the way.)
Tested-by: Bin Meng <bmeng.cn@gmail.com> Signed-off-by: Andre Przywara <osp@andrep.de>
The type of the "size" of "struct mtd_info" is uint64_t, while
mtd_arg_off_size() and mtd_arg_off() treat chipsize as int type.
The chipsize is wrapped around if the argument is given with 2GB
or larger.
Stefan Roese [Mon, 29 Jun 2015 12:58:12 +0000 (14:58 +0200)]
block: ahci: Don't enable port interrupts
This patch changes the initialization of the AHCI controller to not
enable the default interrupts (DEF_PORT_IRQ). As interrupts are
not used in U-Boot in general, this should not break the common AHCI
driver operation.
This change is needed to support the Marvell Armada 38x AHCI
controller. With interrupts enabled, this results in timeouts in
ahci_device_data_io(). Not enabling these interrupts fixes this
problem and the common AHCI driver works fine.
Signed-off-by: Stefan Roese <sr@denx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Cc: Tom Rini <trini@konsulko.com> Cc: Hans de Goede <hdegoede@redhat.com> Cc: Luka Perkov <luka.perkov@sartura.hr>
Stefan Roese [Mon, 29 Jun 2015 12:58:10 +0000 (14:58 +0200)]
arm: mvebu: Add SDIO/SDHCI support for Armada A38x
Armada A38x implements an SDHCI compatible SDIO controller. This patch
enables the Marvell driver to support this SoC. And enables the
SDIO controller if selected by the board configuration.
Stefan Roese [Mon, 29 Jun 2015 12:58:09 +0000 (14:58 +0200)]
mmc: sdhci.c: Add config option to use a fixed buffer for transfers
While implementing SDIO/MMC SPL booting for the Marvell Armada 38x, the
following problem occured. The SPL runs in internal SRAM which is
the L2 cache locked to memory. When the MMC buffers now are located
on the stack (or bss), the SDIO controller (SDHCI) can't write into
this L2 cache memory.
This patch introduces a method to use a fixed buffer that will be
used for all transfers by defining CONFIG_FIXED_SDHCI_ALIGNED_BUFFER.
This way, the board can use this buffer address located in SDRAM
for all transfers. This solves this SPL problem on the A38x and
should only be used in the SPL U-Boot version.
Tested for SPL booting on Marvell Armada 38x DB-88F6820-GP board.
Signed-off-by: Stefan Roese <sr@denx.de> Cc: Pantelis Antoniou <panto@antoniou-consulting.com> Cc: Luka Perkov <luka.perkov@sartura.hr>
Stefan Roese [Mon, 29 Jun 2015 12:58:08 +0000 (14:58 +0200)]
mmc: sdhci: Use timer based timeout detection in sdhci_send_command()
The loop counter based timeout detection does not work on the Armada
38x based board (DB-88F6820-GP). At least with dcache enabled a
timeout is detected. Without dcache enabled, the timeout does not
occur. Increasing the loop counter solves this issue. But a better
solution is to use a timer based timeout detection instead. This
patch now implements this timer based detection.
Signed-off-by: Stefan Roese <sr@denx.de> Cc: Pantelis Antoniou <panto@antoniou-consulting.com> Cc: Luka Perkov <luka.perkov@sartura.hr>
ahci: Fix compiling warnings under 64bit platforms
When compling under 64bit platforms, there are lots of warnings,
like:
drivers/block/ahci.c:114:18: warning: cast to pointer from integer
of different size [-Wint-to-pointer-cast]
u8 *port_mmio = (u8 *)probe_ent->port[port].port_mmio;
^
drivers/block/ahci.c: In function ?.hci_host_init?.
drivers/block/ahci.c:218:49: warning: cast from pointer to integer
of different size [-Wpointer-to-int-cast]
probe_ent->port[i].port_mmio = ahci_port_base((u32) mmio, i);
Michael Scherban [Fri, 26 Jun 2015 14:17:31 +0000 (09:17 -0500)]
keystone2: config: update default mtd
Because it is possible for the MTD number to change, causing a
filesystem mount failure, we should use the volume name instead
of the MTD number and let Linux resolve the correct one.
Antonio Borneo [Wed, 1 Jul 2015 08:04:14 +0000 (16:04 +0800)]
stm32f4: fix gpio description in comment
On STM32F429 gpio PC6/PC7 can be allocated for USART6, as
reported in the comment.
But current code in
drivers/serial/serial_stm32.c
uses a different gpio mapping (PG14/PG9) for USART6.
Fix the comment to match current code in the driver.
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
To: u-boot@lists.denx.de
To: Kamil Lulko <rev13@wp.pl> Cc: Tom Rini <trini@konsulko.com>
Antonio Borneo [Wed, 1 Jul 2015 06:15:02 +0000 (14:15 +0800)]
stm32f4: fix MAINTAINERS file
When "scripts/get_maintainer.pl" parses "board/.../MAINTAINERS",
it uses the line containing board name as delimiter.
Without this line, the script happily mixes the lines from current
board MAINTAINERS file with lines from another file.
Fix it by adding a reasonable board name.
Tested by comparing output of:
cat board/st/stm32f429-discovery/MAINTAINERS
./scripts/get_maintainer.pl -f board/st/stm32f429-discovery
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
To: u-boot@lists.denx.de
To: Kamil Lulko <rev13@wp.pl> Cc: Tom Rini <trini@konsulko.com>
Egli, Samuel [Wed, 1 Jul 2015 15:57:39 +0000 (17:57 +0200)]
siemens,am33x: adjust mtd partition
Use one mtd partition for rootfs and configuration by
means of ubi volumes and get rid of configuration partition.
We can use partition layout for both 256MB and 512MB flash.
Signed-off-by: Samuel Egli <samuel.egli@siemens.com> Cc: Heiko Schocher <hs@denx.de> Cc: Roger Meier <r.meier@siemens.com> Reviewed-by: Tom Rini <trini@konsulko.com> Acked-by: Heiko Schocher <hs@denx.de>
Roger Quadros [Thu, 25 Jun 2015 07:25:50 +0000 (10:25 +0300)]
ARM: beagle_x15: prevent DCAN1 _wait_target_disable failure in kernel
If board is booted with transitions happening on DCAN1 pins then
the following warning is seen in the kernel at boot when the
hwmod layer initializes.
"omap_hwmod: dcan1: _wait_target_disable failed"
This is because DCAN1 module's SWAKEUP mechanism is broken
and it fails to correctly turn OFF if it sees a transition on the
DCAN1 pins. Suggested workaround is to keep DCAN1 pins in safe mode
while enabling/disabling DCAN1 module.
The hwmod layer enables and disables all modules at boot
and we have no opportunity to put the DCAN1 pins in safe mode
at that point.
DCAN1 is not used by u-boot so it doesn't matter to it if these
pins are in safe mode. The kernel driver correctly configures
the right mode when DCAN1 is active.
Signed-off-by: Roger Quadros <rogerq@ti.com>
[trini: s/PULLUP/PULL_UP/ based on DRA7xx EVM version of this patch] Signed-off-by: Tom Rini <trini@konsulko.com>
Roger Quadros [Wed, 24 Jun 2015 14:00:11 +0000 (17:00 +0300)]
ARM: DRA7-evm: prevent DCAN1 _wait_target_disable failure in kernel
If board is booted with transitions happening on DCAN1 pins then
the following warning is seen in the kernel at boot when the
hwmod layer initializes.
"omap_hwmod: dcan1: _wait_target_disable failed"
This is because DCAN1 module's SWAKEUP mechanism is broken
and it fails to correctly turn OFF if it sees a transition on the
DCAN1 pins. Suggested workaround is to keep DCAN1 pins in safe mode
while enabling/disabling DCAN1 module.
The hwmod layer enables and disables all modules at boot
and we have no opportunity to put the DCAN1 pins in safe mode
at that point.
DCAN1 is not used by u-boot so it doesn't matter to it if these
pins are in safe mode. The kernel driver correctly configures
the right mode when DCAN1 is active.
Makefile:Add GCC flag -fno-delete-null-pointer-checks
-fdelete-null-pointer-checks flag controls global dataflow analyses and
eliminate useless checks for null pointers; It assume that if a pointer is
checked after it has already been dereferenced, it cannot be null.
This flag is enabled by default.
gcc v4.9 has more optimizations added to this option. Hence it is very
aggressive with GCC v4.9 series. Add -fno-delete-null-pointer-checks to
disable the optimization
Joe Hershberger [Mon, 22 Jun 2015 22:57:36 +0000 (17:57 -0500)]
Allow CONFIG_REGEX to be disabled when CONFIG_NET
Instead of selecting REGEX when NET is enabled, make it the default, but
allow boards that are tiny to disable it and lose functionality on all
but the first Ethernet adapter.
cm-bf548, bf538f-ezkit, and bf533-stamp need this. None appear to have
more than one Ethernet interface.
Signed-off-by: Joe Hershberger <joe.hershberger@ni.com>
Bin Meng [Mon, 15 Jun 2015 10:40:19 +0000 (18:40 +0800)]
net: designware: Program MAC address to hardware after soft reset
commit f566c99 "net: Update hardware MAC address if it changes in env"
removes writing MAC address to designware controller after soft reset.
This makes designware ethernet port fail to work. Actually the MAC
address should always be programmed after soft reset.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
Mugunthan V N [Mon, 22 Jun 2015 09:13:10 +0000 (14:43 +0530)]
ARM: DRA72x: fix io delay calibration for ethernet
we currently use in-development IODelay values for DRA72x which are
proposed in the data sheet, however, DRA72x EVM uses DP83865 ethernet
Phy over RGMII. The PHY characteristics and routing choices made on
the EVM, make the current iodelay values fail ethernet communication.
Instead, we need to choose custom values for DRA72x-evm specifically
designed for the PHY and routing on the platform for ethernet to
function.
Simon Glass [Tue, 2 Jun 2015 17:08:21 +0000 (11:08 -0600)]
Revert "break build if it would produce broken binary"
The root cause of this problem should now be fixed.
This reverts commit a6a4c542d316b3401f0840ac5378743191bca851. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Pavel Machek <pavel@denx.de> Tested-by: Pavel Machek <pavel@denx.de>
Simon Glass [Tue, 2 Jun 2015 17:08:20 +0000 (11:08 -0600)]
arm: Add ENTRY/ENDPROC to private libgcc functions
When CONFIG_SYS_THUMB_BUILD is defined these functions may be called from
Thumb code. Add the required ENTRY and ENDPROC bracketing so that BLX is
used to call these ARM functions, instead of plain BL, which will fail.
Signed-off-by: Simon Glass <sjg@chromium.org> Reported-by: Pavel Machek <pavel@denx.de>
Axel Lin [Tue, 14 Apr 2015 06:55:24 +0000 (14:55 +0800)]
gpio: lpc32xx: Use priv_data instead of platdata
The LPC32XX GPIO driver platdata currently contains GPIO state information,
which should go into priv_data. Thus rename lpc32xx_gpio_platdata to
lpc32xx_gpio_priv and convert to use dev_get_priv() instead.
Signed-off-by: Axel Lin <axel.lin@ingics.com> Tested-by: Albert ARIBAUD <albert.aribaud@3adev.fr>
Chen-Yu Tsai [Tue, 23 Jun 2015 11:57:27 +0000 (19:57 +0800)]
sunxi: Add Sinlinx SinA33 defconfig
Sinlinx SinA33 is a core/daughter board SDK kit from Sinlinx. It has
the A33 SoC, USB host, USB OTG, audio input/output, LCD, camera, SDIO
and GPIO headers.
Signed-off-by: Chen-Yu Tsai <wens@csie.org> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>