Add minimum codes to support Intel Quark SoC. DRAM initialization
is not ready yet so a hardcoded gd->ram_size is assigned.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
Quark SoC contains an embedded 512KiB SRAM (eSRAM) that is
initialized by hardware. eSRAM is the ideal place to be used
for Cache-As-RAM (CAR) before system memory is available.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
Move PCI_REG_ADDR and PCI_REG_DATA from arch/x86/lib/pci_type1.c to
arch/x86/include/asm/pci.h, also define PCI_CFG_EN so that these
macros can be used for pci configuration space access.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
In the Quark SoC, some chipset commands are accomplished by utilizing
the internal message network within the host bridge (D0:F0). Accesses
to this network are accomplished by populating the message control
register (MCR), Message Control Register eXtension (MCRX) and the
message data register (MDR).
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
device.h for integrated pci devices' bdf on Quark SoC and quark.h for
various memory-mapped and i/o-mapped base addresses within SoC.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
This is a relatively low-cost x86 board in a small form factor. The main
peripherals are uSD, USB, HDMI, Ethernet and SATA. It uses an Atom 3800
series CPU. So far only the dual core 2GB variant is supported.
This uses the existing FSP support. Binary blobs are required to make this
board work. The microcode update is included as a patch (all 3000 lines of
it).
Change-Id: I0088c47fe87cf08ae635b343d32c332269062156
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Some information has been gleaned on tools and procedures for porting
U-Boot to different x86 platforms. Add a few notes to start things off.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Allow measuring of boot time using bootstage.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
On some hardware this time can be significant. Add bootstage support for
measuring this. The result can be obtained using 'bootstage report' or
passed on to the Linux via the device tree.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
The base address is found in a different way and the protection bit is also
in a different place. Otherwise it is very similar.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Since the FSP is a black box it helps to have some sort of debugging
available to check its inputs. If the debug UART is in use, set it up
after CAR is available.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
While queensbay is the first chip with these settings, others will want to
use them too. Make them common.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Since these board functions seem to be the same for all boards which use
FSP, move them into a common file. We can adjust this later if future FSPs
need more flexibility.
This creates a generic PCI MMC device.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
This patch fixes the following compilation warning for maxbcm:
Building maxbcm board...
text data bss dec hex filename
160075 6596 38240 204911 3206f ./u-boot
board/maxbcm/maxbcm.c: In function 'reset_phy':
board/maxbcm/maxbcm.c:68:6: warning: unused variable 'reg' [-Wunused-variable]
u16 reg;
^
board/maxbcm/maxbcm.c:66:6: warning: unused variable 'devadr' [-Wunused-variable]
u16 devadr = CONFIG_PHY_BASE_ADDR;
^
Additionally support Spansion SPI NOR flash is added. With larger SPI device
support via the CONFIG_SPI_FLASH_BAR define.
Signed-off-by: Stefan Roese <sr@denx.de>
Reviewed-by: Luka Perkov <luka.perkov@sartura.hr>
This patch adds the DDR3 setup and training code taken from the Marvell
U-Boot repository. This code used to be included as a binary (bin_hdr)
into the AXP boot image. Not linked with the main U-Boot. With this code
addition and the following serdes/PHY setup code, the Armada-XP support
in mainline U-Boot is finally self-contained. So the complete image
for booting can be built from mainline U-Boot. Without any additional
external inclusion. Hopefully other MVEBU SoC's will follow here.
Support for some SoC's has been removed in this version. This is:
MV_MSYS:
The code referred to by the MV_MSYS define is currently unused. And its
not really planned to support this in mainline. So lets remove it to
make the code clearer and increase the readability.
MV88F68XX (A38x):
The code referred to by the MV88F68XX define (A38x) is currently unused.
And its partial and not sufficient for this device in this stage.
So lets remove it to make the code clearer and increase the readability.
MV88F66XX (ALP):
The code referred to by the MV88F66XX define is currently unused. And its
not really planned to support this in mainline. So lets remove it to
make the code clearer and increase the readability.
MV88F78X60_Z1:
The code referred to by the MV88F78X60_Z1 define is currently unused. As the
Z1 revision of the AXP is not supported in mainline anymore.
So lets remove it to make the code clearer and increase the readability.
Remove support for Z1 & A0 AXP revisions (steppings). The current stepping
is B0 and this is the only one that is actively supported in this code
version.
Tested on AXP using a SPD DIMM setup on the Marvell DB-MV784MP-GP board and
on a custom fixed DDR configuration board (maxbcm).
Note:
This code has undergone many hours of coding-style cleanup and refactoring.
It still is not checkpatch clean though, I'm afraid. As the factoring of the
code has so many levels of indentation that many lines are longer than 80
chars. This might be some task to tackly later on.
Signed-off-by: Stefan Roese <sr@denx.de>
Reviewed-by: Luka Perkov <luka.perkov@sartura.hr>
This code is ported from the Marvell bin_hdr code into mainline
SPL U-Boot. It needs to be executed very early so that the devices
connected to the serdes PHY are configured correctly.
Signed-off-by: Stefan Roese <sr@denx.de>
Reviewed-by: Luka Perkov <luka.perkov@sartura.hr>
This patch adds SPL support to the Marvell Armada-XP. With this addition
the bin_hdr integration is not needed any more. The SPL will first
initialize the serdes/PHY and the call the DDR setup and training code
now integrated into mainline U-Boot.
Signed-off-by: Stefan Roese <sr@denx.de>
Reviewed-by: Luka Perkov <luka.perkov@sartura.hr>
This is used on the AXP boards, to pad u-boot.img to the desired offset in
SPI flash (only this boot target supported right now). This offset is
used by the SPL then to load u-boot.img into SDRAM and execute it there.
Signed-off-by: Stefan Roese <sr@denx.de>
Reviewed-by: Luka Perkov <luka.perkov@sartura.hr>
This build target now includes the SPL binary as the bin_hdr into the
kwb image. Its used on the AXP port with the mainlined DDR training code.
Signed-off-by: Stefan Roese <sr@denx.de>
Reviewed-by: Luka Perkov <luka.perkov@sartura.hr>
This patch adds SPL support to the db-mv784mp-gp eval board.
Signed-off-by: Stefan Roese <sr@denx.de>
Reviewed-by: Luka Perkov <luka.perkov@sartura.hr>
This patch adds SPL support to the maxbcm MV78460 based board. Including
the fixed DDR configuratrion needed for the DDR training code. And the
the serdes PHY init code.
Signed-off-by: Stefan Roese <sr@denx.de>
Reviewed-by: Luka Perkov <luka.perkov@sartura.hr>
With this patchset the Marvell bin_hdr (DDR training) code is intergrated
into mainline U-Boot. We can remove the placeholder file again, which was
only introduced to make U-Boot compile and link again.
Signed-off-by: Stefan Roese <sr@denx.de>
Reviewed-by: Luka Perkov <luka.perkov@sartura.hr>
Checking if the pointer is NULL would be easier to know the tail
of the boot_device_table[] array.
For clarification, add the /* sentinel */ comment.
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
The return value of get_boot_mode_sel() is used as the index of
the boot_device_table[] array. Its type should be "int" rather
than "u32".
Use only the iterator "i" for the loop in do_pinmon().
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
To use I2C controllers on PH1-sLD8, the bit 10 (SCL0/SDA0)
and bit 11 (SCL1/SDA1) of IECTRL register must be set.
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
It is true that unused functions are removed from the ELF image
by the compiler's garbage collection but relying on it too much
does not look nice.
Currently, the build is taking more than it should.
Refactor the makefiles to compile only files that are really needed.
CONFIG_SOC_INIT and CONFIG_DRAM_INIT are no longer needed by the
optimization.
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Since commit 0365ffcc0b (generic-board: show model name in
board_init_f() too), checkboard() is invoked only when
show_board_info() fails to get the model name from Device Tree.
It never happens because UniPhier SoCs now only work with
CONFIG_OF_CONTROL and all the root nodes of UniPhier device trees
have the "model" property.
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Since commit 0365ffcc0b (generic-board: show model name in
board_init_f() too), the support card information has not been
displayed because check_support_card() is invoked only when
show_board_info() fails to get the model name from Device Tree.
This commit adds misc_init_f() function to call check_support_card()
from there.
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Now init functions called from board_postclk_init() and dram_init()
are only necessary for SPL.
Move them to spl_board_init() for clean-up.
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Currently, I/O pin settings are not necessary for SPL.
The board_early_init_f() seems a suitable place to call pin_init().
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
The EEPROM chips on UniPhier reference daughter boards expect 2-byte
offset address.
Since 7132b9fd68 (dm: i2c: dts: Support an offset-len device tree
property), I2C sub-nodes can have "u-boot,i2c-offset-len" property.
It is convenient to set the default I2C offset address length in
Device Tree, so that we do not have to set it on the command line.
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
This EEPROM chip is installed on the expansion board commonly used
on UniPhier platform. To avoid duplicated description, move the
EEPROM node to a separate file and include it from other device tree
sources.
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
To boot UniPhier boards with the NAND boot mode, two images
(u-boot-spl.bin and u-boot-dtb.img) must be written at the correct
offset addresses.
TFTP downloading is useful to update such images in the NAND device.
We generally do:
=> nand erase 0 0x100000
=> tftpboot u-boot-spl.bin
=> nand write $loadaddr 0 0x10000
=> tftpboot u-boot-dtb.img
=> nand write $loadaddr 0x10000 0xf0000
It is a tedious and error-prone operation.
This commit provides the shorthand:
=> run nandupdate
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
This dummy header was introduced by commit 630bf80ebb (ARM:
UniPhier: add dummy gpio.h to enable CONFIG_OF_CONTROL).
Thanks to commit a08d643dbd (dm: Drop gpio.h header from
fdtdec.c), such an ugly workaround is no longer needed.
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
For now this code seems to be the same for all FSP platforms. Make it
common until we see what differences are required.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
To avoid casts, find_fsp_header() should return a pointer. Add asmlinkage
to two API functions which use that convention. UPD_TERMINATOR is common
so move it into a common file.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
Since we must run a PCI BIOS ROM, and this can take a calamitous amount of
time, measure it using bootstage.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
If the BIOS emulator is not available, allow use of native execution if
available, and vice versa. This can be controlled by the caller.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
