Nishanth Menon [Thu, 13 Aug 2015 14:50:59 +0000 (09:50 -0500)]
ARM: DRA74-evm: Add iodelay values for SR2.0
Silicon revision 2.0 has new signal routing hence has an updated set of
iodelay parameters to be used. Update the configuration for the same.
Padmux remains the same.
Based on data from VayuES2_EVM_Base_Config-20150807.
NOTE: With respect to the RGMII values, the Manual IODelay values
are used for the fine adjusments needed to meet the tight RGMII
specification.
Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
Nishanth Menon [Thu, 13 Aug 2015 14:50:58 +0000 (09:50 -0500)]
ARM: DRA7: Add detection of ES2.0
Add support for detection of ES2.0 version of DRA7 family of
processors. ES2.0 is an incremental revision with various fixes
including the following:
- reset logic fixes
- few assymetric aging logic fixes
- MMC clock rate fixes
- Ethernet speed fixes
- edma fixes for mcasp
[ravibabu@ti.com: posted internal for an older bootloader] Signed-off-by: Ravi Babu <ravibabu@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Acked-by: Lokesh Vutla <lokeshvutla@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
Chris Packham [Thu, 13 Aug 2015 06:08:27 +0000 (18:08 +1200)]
Makefile: Use correct timezone for U_BOOT_TZ
When building with SOURCE_DATE_EPOCH the timezone is in UTC. When
building normally the timezone is taken from the build machine's locale
setting.
Signed-off-by: Chris Packham <judge.packham@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Paul Kocialkowski <contact@paulk.fr> Tested-by: Andreas Bießmann <andreas.devel@googlemail.com>
Suriyan Ramasami [Tue, 18 Aug 2015 16:25:33 +0000 (09:25 -0700)]
lib/display_options: Fix print_freq
Build without CONFIG_SPL_SERIAL_SUPPORT does not print the cpu freq.
I have seen this in the odroid U3 board, where on boot one sees this:
CPU: Exynos4412 @ GHz
instead of:
CPU: Exynos4412 @ 1 GHz
I am assuming that this change was done to get rid of compiler
warnings related to unused variables when building with
CONFIG_SPL_SERIAL_SUPPORT not being defined in an SPL build.
Signed-off-by: Suriyan Ramasami <suriyan.r@gmail.com> Acked-by: Simon Glass <sjg@chromium.org> Acked-by: Heiko Schocher <hs@denx.de> Reviewed-by: Joe Hershberger <joe.hershberger@ni.com>
Thierry Reding [Thu, 20 Aug 2015 09:45:43 +0000 (11:45 +0200)]
image: Fix loop condition to avoid warning
GCC 5.1 starts warning for comparisons such as !a > 0, assuming that the
negation was meant to apply to the whole expression rather than just the
left operand.
Indeed the comparison in the FIT loadable code is confusingly written,
though it does end up doing the right thing. Rewrite the condition to be
more explicit, that is, iterate over strings until they're exhausted.
Signed-off-by: Thierry Reding <treding@nvidia.com> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Bin Meng [Mon, 24 Aug 2015 08:14:03 +0000 (01:14 -0700)]
x86: crownbay: Support Topcliff integrated pci uart devices with driver model
In order to make a pci uart device node to be properly bound to its
driver, we need make sure its parent node has a compatible string
which matches a driver that scans all of its child device nodes in
the device tree.
Change all pci bridge nodes under root pci node to use "pci-bridge"
compatible driver, as well as corresponding <reg> properties to
indicate its devfn. At last, adding "u-boot,dm-pre-reloc" to each
of these nodes for driver model to initialize them before relocation.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
Bin Meng [Mon, 24 Aug 2015 08:14:02 +0000 (01:14 -0700)]
dm: core: Fix code reentrancy issue in device_probe_child()
The device might have already been probed during the call to
device_probe() on its parent device (e.g. PCI bridge devices).
In its parent device's probe routine, it might probe all of
its child devices via device_probe() thus the codes reenter
device_probe_child(). To support code reentrancy, test these
allocated memory against NULL to avoid memory leak, and return
to the caller if dev->flags has DM_FLAG_ACTIVATED set after
device_probe() returns, so that we don't mess up the device.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
So far we only enabled one legacy serial port on the SMSC LPC47m
superio chipset on Intel Crown Bay board. As the board also has
dual PS/2 ports routed out, enable the keyboard controller which
is i8042 compatible so that we can use PS/2 keyboard and mouse.
In order to make PS/2 keyboard work with the VGA console, remove
CONFIG_VGA_AS_SINGLE_DEVICE. To boot Linux kernel with PIC mode
using PIRQ routing table, adjust the mask in the device tree to
reserve irq12 which is used by PS/2 mouse.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Bin Meng [Mon, 24 Aug 2015 08:00:07 +0000 (01:00 -0700)]
video: cfb_console: Allow VGA device to work without i8042 keyboard
So far if CONFIG_VGA_AS_SINGLE_DEVICE is not defined, the VGA device
will try to initialize a keyboard device (for x86, it is i8042). But
if i8042 controller initialization fails (eg: there is no keyboard
connected to the PS/2 port), drv_video_init() just simply returns.
This kills the opportunity of using a usb keyboard later with the vga
console, as the vga initialization part is actually ok, only keyboard
part fails. Change the code logic to allow this.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org> Acked-by: Anatolij Gustschin <agust@denx.de>
Bin Meng [Mon, 24 Aug 2015 08:00:06 +0000 (01:00 -0700)]
x86: i8042: Correctly initialize the controller
The existing i8042 keyboard controller driver has some issues.
First of all, it does not issue a self-test command (0xaa) to the
controller at the very beginning. Without this, the controller
does not respond to any command at all. Secondly, it initializes
the configuration byte register to turn on the keyboard's interrupt,
as U-Boot does not normally allow interrupts to be processed.
Finally, at the end of the initialization routine, it wrongly
sets the controller to disable all interfaces including both
keyboard and mouse.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
Bin Meng [Mon, 24 Aug 2015 08:00:05 +0000 (01:00 -0700)]
x86: i8042: Clean up the driver per coding convention
- Rename CamelCase variables to conform U-Boot coding convention
- Rename wait_until_kbd_output_full() to kbd_output_full()
- Change to use macros for i8042 command and control register bits
Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
Simon Glass [Sat, 22 Aug 2015 21:58:59 +0000 (15:58 -0600)]
x86: gpio: Tidy up gpio_ich6_get_base() and callers
This function can return an error. Correct the detection of this error so
that it works even with large 32-bit addresses.
The return value is set up for returning an I/O address but the function is
also used to return a memory-mapped address. Adjust the return code to make
this work.
Saket Sinha [Sat, 22 Aug 2015 06:50:56 +0000 (12:20 +0530)]
x86: Add ACPI table support to QEMU
This patch mainly adds ACPI support to QEMU.
Verified by booting Linux kernel on QEMU Q35.
Signed-off-by: Saket Sinha <saket.sinha89@gmail.com>
Minor whitespace fixes and dropped mention of i440FX in commit message: Signed-off-by: Simon Glass <sjg@chromium.org>
Saket Sinha [Sat, 22 Aug 2015 06:50:55 +0000 (12:20 +0530)]
x86: Generate a valid ACPI table
Implement write_acpi_table() to create a minimal working ACPI table.
This includes writing FACS, XSDT, RSDP, FADT, MCFG, MADT, DSDT & SSDT
ACPI table entries.
Use a Kconfig option GENERATE_ACPI_TABLE to tell U-Boot whether we need
actually write the APCI table just like we did for PIRQ routing, MP table
and SFI tables. With ACPI table existence, linux kernel gets control of
power management, thermal management, configuration management and
monitoring in hardware.
Signed-off-by: Saket Sinha <saket.sinha89@gmail.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tidied up whitespace and aligned some tabs: Signed-off-by: Simon Glass <sjg@chromium.org>
Bin Meng [Fri, 21 Aug 2015 07:18:51 +0000 (00:18 -0700)]
x86: superio: Add keyboard controller support to smsc_lpc47m driver
Add an api to enable and configure the integrated keyboard controller
on SMSC LPC47m superio chipset. It also adds several macros to help
future extension.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
Bin Meng [Thu, 20 Aug 2015 13:40:23 +0000 (06:40 -0700)]
x86: fsp: Call fsp_init_phase_pci() in pci_uclass_post_probe()
Per Intel FSP specification, we should call FSP notify API to
inform FSP that PCI enumeration has been done so that FSP will
do any necessary initialization as required by the chipset's
BIOS Writer's Guide (BWG).
Unfortunately we have to put this call here as with driver model,
the enumeration is all done on a lazy basis as needed, so until
something is touched on PCI it won't happen.
Note we only call this after U-Boot is relocated and root bus has
finished probing.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
Bin Meng [Thu, 20 Aug 2015 13:40:22 +0000 (06:40 -0700)]
x86: baytrail: Remove the fsp_init_phase_pci() call
It turns out that calling fsp_init_phase_pci() in arch_misc_init()
is subject to break pci device drivers as with driver model, when
the bus enumeration happens is not deterministic.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
Bin Meng [Thu, 20 Aug 2015 13:40:21 +0000 (06:40 -0700)]
x86: queensbay: Move unprotect_spi_flash() to arch_misc_init()
With dm pci conversion, pci config read/write in unprotect_spi_flash()
silently fails as at that time dm pci is not ready and bus enumeration
is not done yet. Actually we don't need to do this in that early phase,
hence we delay this call to arch_misc_init().
Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
Bin Meng [Thu, 20 Aug 2015 13:40:20 +0000 (06:40 -0700)]
x86: fsp: Add comments about U-Boot entering start.S twice
Add some comments in start.S for the fact that with FSP U-Boot
actually enters the code twice. Also change to use fsp_init()
and fsp_continue for accuracy.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
Bin Meng [Thu, 20 Aug 2015 13:40:19 +0000 (06:40 -0700)]
x86: fsp: Enlarge the size of malloc() pool before relocation
After fsp_init() returns, the stack has already been switched to a
place within system memory as defined by CONFIG_FSP_TEMP_RAM_ADDR.
Enlarge the size of malloc() pool before relocation since we have
plenty of memory now.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
Bin Meng [Thu, 20 Aug 2015 13:40:17 +0000 (06:40 -0700)]
dm: pci: Support selected device/driver binding before relocation
On some platforms pci devices behind bridge need to be probed (eg:
a pci uart on recent x86 chipset) before relocation. But we won't
bind all devices found during the enumeration. Only devices whose
driver with DM_FLAG_PRE_RELOC set will be bound. Any other generic
devices except bridges won't be bound.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
Simon Glass [Sat, 15 Aug 2015 20:37:54 +0000 (14:37 -0600)]
x86: ifdtool: Drop microcode from the device tree when collating
When ifdtool collates the microcode into one place it effectively creates
a copy of the 'data' properties in the device tree microcode nodes. This
is wasteful since we now have two copies of the microcode in the ROM.
To avoid this, remove the microcode data from the device tree and shrink it
down. This means that there is only one copy and the overall ROM space used
by the microcode does not increase.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Sat, 15 Aug 2015 20:37:53 +0000 (14:37 -0600)]
x86: ifdtool: Support collating microcode into one place
The Intel Firmware Support Package (FSP) requires that microcode be provided
very early before the device tree can be scanned. We already support adding
a pointer to the microcode data in a place where early init code can access.
However this just points into the device tree and can only point to a single
lot of microcode. For boards which may have different CPU types we must
support multiple microcodes and pass all of them to the FSP in one place.
Enhance ifdtool to scan all the microcode, place it together in the ROM and
update the microcode pointer to point there. This allows us to pass multiple
microcode blocks to the FSP using its existing API.
Enable the flag in the Makefile so that this feature is used by default for
all boards.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Sat, 15 Aug 2015 20:37:51 +0000 (14:37 -0600)]
x86: ifdtool: Check that U-Boot does not overlap other regions
Since U-Boot and its device tree can grow we should check that it does not
overlap the regions above it. Track the ROM offset that U-Boot reaches and
check that other regions (written after U-Boot) do not interfere.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com>
Bin Meng [Sat, 15 Aug 2015 20:37:50 +0000 (14:37 -0600)]
x86: baytrail: Support multiple microcode copies
Intel FSP has the capability to walk through the microcode blocks
which are passed as the TempRamInit() parameter from U-Boot and
finds the most appropriate microcode which is suitable for the cpu
on which it is running. Now we've seen several steppings for Intel
BayTrail series processors, adding those microcodes to the Intel
BayleyBay and MinnowMax board device tree files.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Signed-off-by: Simon Glass <sjg@chromium.org>
Bin Meng [Thu, 13 Aug 2015 07:29:17 +0000 (00:29 -0700)]
x86: Set up video framebuffer for coreboot before loading kernel
Currenlty we only set up video framebuffer when VIDEO_VESA driver is
used. With coreboot, VIDEO_COREBOOT driver is used instead. Since we
already saved VESA mode in the VIDEO_COREBOOT driver, now we can also
set up video framebuffer for coreboot before loading Linux kernel.
Bin Meng [Thu, 13 Aug 2015 07:29:16 +0000 (00:29 -0700)]
video: coreboot: Save VESA mode for future use
When booting as a coreboot payload, the framebuffer details are
passed from coreboot via configuration tables. We save these
information into vesa_mode_info structure for future use.
Bin Meng [Thu, 13 Aug 2015 07:29:08 +0000 (00:29 -0700)]
x86: coreboot: Increase memrange entry number to 32
Increase lib_sysinfo memrange entry number to 32 to sync with coreboot.
This allows a complete E820 table to be reported to the kernel, as on
some platforms (eg: Bayley Bay) having only 16 entires does not cover
all the memory ranges.
Bin Meng [Thu, 13 Aug 2015 07:29:07 +0000 (00:29 -0700)]
x86: doc: Update coreboot payload entry point address
With recent EFI support, the entry point address of coreboot payload
was changed. Now we update the address to use _x86boot_start, which
is the same one for EFI.
Bin Meng [Wed, 26 Aug 2015 13:17:27 +0000 (06:17 -0700)]
net: e1000: Fix build warnings for 32-bit
commit 6497e37 "net: e1000: Support 64-bit physical address" causes
compiler warnings on 32-bit U-Boot build below.
drivers/net/e1000.c: In function 'e1000_configure_tx':
drivers/net/e1000.c:4982:2: warning: right shift count >= width of type [enabled by default]
drivers/net/e1000.c: In function 'e1000_configure_rx':
drivers/net/e1000.c:5126:2: warning: right shift count >= width of type [enabled by default]
This commit fixes the build warnings.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
Peng Fan [Tue, 21 Jul 2015 08:15:21 +0000 (16:15 +0800)]
mtd: nand: mxs invalidate dcache before DMA read
Follow linux dma flow:
Before DMA read, be sure to invalidate the cache over the address
range of DMA buffer to prevent cache coherency problems.
After DMA read, invalidate dcache again.
Signed-off-by: Peng Fan <Peng.Fan@freescale.com> Acked-by: Marek Vasut <marex@denx.de> Acked-by: Tim Harvey <tharvey@gateworks.com>
Peng Fan [Tue, 21 Jul 2015 08:15:19 +0000 (16:15 +0800)]
mtd: nand: mxs support oobsize bigger than 512
If ecc chunk data size is 512 and oobsize is bigger than 512, there is
a chance that block_mark_bit_offset conflicts with bch ecc area.
The following graph is modified from kernel gpmi-nand.c driver with
each data block 512 bytes. We can see that Block Mark conflicts with
ecc area from bch view. We can enlarge the ecc chunk size to avoid
this problem to those oobsize which is larger than 512.
| P |
|<----------------------------------------------------------------->|
| |
| (Block Mark) |
| P' | | | |
|<--------------------------------------------------->| D | | O'|
| |<--------->| |<->|
V V V V V
+---+--------------+-+--------------+-+--------------+-+----------+-+---+
| M | data |E| data |E| data |E| data |E| |
+---+--------------+-+--------------+-+--------------+-+----------+-+---+
^ ^
| O |
|<---------------->|
P : the page size for BCH module.
E : The ECC strength.
G : the length of Galois Field.
N : The chunk count of per page.
M : the metasize of per page.
C : the ecc chunk size, aka the "data" above.
P': the nand chip's page size.
O : the nand chip's oob size.
O': the free oob.
Signed-off-by: Peng Fan <Peng.Fan@freescale.com> Reviewed-by: Marek Vasut <marex@denx.de> Tested-By: Tim Harvey <tharvey@gateworks.com>
Tested on the Marvell Armada XP DB-MV784MP-GP eval board.
Signed-off-by: Stefan Roese <sr@denx.de> Cc: Antoine Tenart <antoine.tenart@free-electrons.com> Cc: Ezeguil Garcia <ezequiel.garcia@free-electrons.com> Cc: Luka Perkov <luka.perkov@sartura.hr> Cc: Scott Wood <scottwood@freescale.com>
Scott Wood [Sat, 27 Jun 2015 00:03:26 +0000 (19:03 -0500)]
nand: Sync with Linux v4.1
Update the NAND code to match Linux v4.1. The previous sync was
from Linux v3.15 in commit 4e67c57125290b25.
CONFIG_SYS_NAND_RESET_CNT is removed, as the upstream Linux code now
has its own timeout. Plus, CONFIG_SYS_NAND_RESET_CNT was undocumented
and not selected by any board.
Signed-off-by: Scott Wood <scottwood@freescale.com>
Ezequiel Garcia [Wed, 21 May 2014 22:06:12 +0000 (19:06 -0300)]
mtd: Introduce mtd_block_isreserved()
In addition to mtd_block_isbad(), which checks if a block is bad or
reserved, it's needed to check if a block is reserved only (but not
bad). This commit adds an MTD interface for it, in a similar fashion to
mtd_block_isbad().
While here, fix mtd_block_isbad() so the out-of-bounds checking is done
before the callback check.
Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Tested-by: Pekon Gupta <pekon@ti.com> Signed-off-by: Brian Norris <computersforpeace@gmail.com>
[scottwood: Cherry-picked from Linux 8471bb73ba10ed67] Signed-off-by: Scott Wood <scottwood@freescale.com>
Andrew Ruder [Wed, 12 Aug 2015 18:18:31 +0000 (13:18 -0500)]
arm: pxa: use common timer functions
This patch moves pxa to the common timer functions added in commit
8dfafdd - Introduce common timer functions <Rob Herring>
The (removed) pxa timer code (specifically __udelay()) could deadlock at
the 32-bit boundary of get_ticks(). get_ticks() returned a 32-bit value
cast up to a 64-bit value. If get_ticks() + tmo in __udelay() crossed
the 32-bit boundary, the while condition became unconditionally true and
locked the processor. Rather than patch the specific pxa issues, simply
move everything over to the common code.
Signed-off-by: Andrew Ruder <andrew.ruder@elecsyscorp.com> Cc: Marek Vasut <marex@denx.de> Cc: Tom Rini <trini@konsuiko.com>
Andrew Ruder [Wed, 12 Aug 2015 17:55:47 +0000 (12:55 -0500)]
pxa: Fix boot hang by avoiding vector relocation
Since commit 3ff46cc42b9d73d0 ("arm: relocate the exception vectors")
pxa does not boot anymore.
Add a specific relocate_vectors macro that skips the vector relocation,
as the pxa SoC does not provide RAM at the high vectors address
(0xFFFF0000), and (0x00000000) maps to ROM.
This allows pxa to boot again.
Cc: Marek Vasut <marex@denx.de> Signed-off-by: Andrew Ruder <andrew.ruder@elecsyscorp.com>
Marek Vasut [Wed, 19 Aug 2015 05:46:49 +0000 (07:46 +0200)]
arm: socfpga: Fix ArriaV SoCDK PLL config
Pull out the ArriaV SoCDK clock config from ancient Altera U-Boot
"rel_socfpga_v2013.01.01_15.05.01_pr" and implant those values into
mainline to get a booting ArriaV SoCDK.
Marek Vasut [Mon, 10 Aug 2015 15:20:23 +0000 (17:20 +0200)]
arm: socfpga: dts: Add bank-name property to each GPIO bank
Add "bank-name" property to each GPIO bank to give it unique name.
The approach here is exactly the same as with the "regulator-name"
property for regulators.
Marek Vasut [Mon, 10 Aug 2015 20:17:46 +0000 (22:17 +0200)]
arm: socfpga: Make the pinmux table const u8
Now that we're actually converting the QTS-generated header files,
we can even adjust their data types. A good candidate for this is
the pinmux table, where each entry can have value in the range of
0..3, but each element is declared as unsigned long. By changing
the type to u8, we can save over 600 Bytes from the SPL, so do it.
This patch also constifies the array.
Marek Vasut [Mon, 10 Aug 2015 18:48:07 +0000 (20:48 +0200)]
arm: socfpga: Add qts-filter.sh script
Add script which loads the QTS-generated sources and headers and converts
them into sensible format which can be used with much more easy in mainline
U-Boot. The script also filters out macros which makes no sense anymore, so
they don't pollute namespace and waste space.
Marek Vasut [Mon, 10 Aug 2015 19:24:53 +0000 (21:24 +0200)]
arm: socfpga: Split Altera socfpga into AV and CV SoCDK
The board/altera/socfpga directory is not a generic SoCFPGA machine
anymore, but instead it represents the Altera SoCDK board. To make
matters more complicated, it represents both CycloneV and ArriaV
variant.
On the other hand, nowadays, the content of this board directory is
mostly comprised of QTS-generated header files, while all the generic
code is in arch/arm/mach-socfpga already.
Thus, this patch splits the board/altera/socfpga into a separate
board directory for ArriaV SoCDK and CycloneV SoCDK, so that each
can be populated with the correct QTS-generated header files for
that particular board.
Marek Vasut [Sun, 2 Aug 2015 19:57:57 +0000 (21:57 +0200)]
arm: socfpga: Unbind CPU type from board type
The CONFIG_TARGET_SOCFPGA_CYCLONE5 and CONFIG_TARGET_SOCFPGA_ARRIA5
selected both a board and a CPU. This is not correct as these macros
are supposed to select only board.
All would be good, if QTS-generated header files didn't check for
these macros exactly to determine if the platform is Cyclone V or
Arria V. Thus, for the sake of compatibility with not well fleshed
out header file generator, this patch makes these two macros into
a stub config option and introduces new CONFIG_TARGET_SOCFPGA_CYCLONE5_SOCDK
and CONFIG_TARGET_SOCFPGA_ARRIA5_SOCDK targets, which select the
previous stub config option.
The result is that compatibility with QTS is preserved and the new
CONFIG_TARGET_* select actual target boards.
Marek Vasut [Sun, 2 Aug 2015 19:12:09 +0000 (21:12 +0200)]
arm: socfpga: Move wrappers into platform directory
Move the wrappers for QTS-generated files into platform directory
out of the board directory. The trick here is to add -I to CFLAGS
such that it points to the board directory in source tree and thus
the qts/ directory there is still reachable.
Marek Vasut [Mon, 3 Aug 2015 13:32:37 +0000 (15:32 +0200)]
arm: socfpga: Do not enable gmac1 in Cyclone V dtsi
The GMAC which is enabled is purely board property, so do not enable
arbitrary GMAC in DT include files. Same goes for PHY mode, which is
again a board property. The CycloneV SoCDK does this correctly, but
SoCrates doesn't. This bug never manifested itself though, since all
the boards ever used the GMAC1 . This bug manifests itself only on
boards that utilise GMAC0.
Marek Vasut [Sun, 2 Aug 2015 20:55:24 +0000 (22:55 +0200)]
arm: socfpga: Make the DT mmc node consistent
The socfpga_cyclone5.dtsi has an mmc0 node, socrates has mmc node.
This makes aliases not very usable, so make everything into mmc0.
Moreover, zap the useless mmc alias while at this.
projects / u-boot / log