LS NADK memory manager by default works on HugeTLB. Hence bootargs
must include parameters default_hugepagesz (default hugepagesize,
hugepagesz (hugepage size) and hugepages (number of hugepages to be
reserved in kernel for the given size).
Signed-off-by: Kuldip Giroh <kuldip.giroh@freescale.com>
Reviewed-by: York Sun <yorksun@freescale.com>
Controller number is passed for function calls to support individual
DDR clock, depending on SoC implementation. It is backward compatible
with exising platforms. Multiple clocks have been verifyed on LS2085A
emulator.
Signed-off-by: York Sun <yorksun@freescale.com>
This patch ensures that the TZPC (BP147) and TZASC-400 programming
happens for LS2085A SoC only when the desired config flags are
enabled and ensures that the TZPC programming is done to allow Non-secure
(NS) + secure (S) transactions only for DCGF registers.
The TZASC component is not present on LS2085A-Rev1, so the TZASC-400
config flag is turned OFF for now.
Signed-off-by: Bhupesh Sharma <bhupesh.sharma@freescale.com>
Reviewed-by: York Sun <yorksun@freescale.com>
Clksel value is exynos specific value.
It removed "clksel_val" into dwmci_host and created the
"dwmci_exynos_priv_data" structure for exynos specific data.
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
The SD/MMC version scheme was buggy when dealing with standard
major.minor.change cases. Fix it by using something similar to
the linux's kernel versioning method.
Signed-off-by: Pantelis Antoniou <pantelis.antoniou@konsulko.com>
Tested-by: Jaehoon Chung <jh80.chung@samsung.com>
Reported-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Stephen Warren <swarren@nvidia.com>
The WaRP Board is a Wearable Reference Plaform. The board features:
- Freescale i.MX6 SoloLite processor with 512MB of RAM
- Freescale FXOS8700CQ 6-axis Xtrinsic sensor
- Freescale Kinetis KL16 MCU
- Freescale Xtrinsic MMA955xL intelligent motion sensing platform
The board implements a hybrid architecture to address the evolving
needs of the wearables market. The platform consists of a main board
and an example daughtercard with the ability to add additional
daughtercards for different usage models.
For more information about the project, visit:
http://www.warpboard.org/
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
Reviewed-by: Marek Vasut <marex@denx.de>
Acked-by: Stefano Babic <sbabic@denx.de>
This adds support to switch to 1.8V in case CMD11 succeeds.
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
Reviewed-by: Marek Vasut <marex@denx.de>
Right now U-Boot supports the CONFIG_OLD_SUNXI_KERNEL_COMPAT option,
which makes it go out of its way in limiting the selection of PLL clock
frequencies and PMIC voltages in order not to upset outdated buggy
sunxi-3.4 kernel releases. And if the CONFIG_OLD_SUNXI_KERNEL_COMPAT
option is not set, then booting such old kernels exhibits various
failures at runtime. This is very user unfriendly, and there were
already several incidents when people wasted their time being hit
by these runtime failures and trying to debug them.
The right solution is not to add hacks and workarounds to the mainline
U-Boot, but to fix these bugs in the sunxi-3.4 kernel. And in fact,
the updated sunxi-3.4 kernels already exist. Still we need to follow
the 'Principle of Least Surprise' and U-Boot needs to ensure that
the old buggy kernels are not getting happily booted when the
CONFIG_OLD_SUNXI_KERNEL_COMPAT option is not set. And this patch
addresses this particular issue.
This patch makes U-Boot store the 'compatibility revision' number in
the top 4 bits of the machine id and pass it to the kernel. The old
buggy kernels will fail to load with a very much googlable error
message on the serial console (the "r1 = 0x100010bb" part of it):
"Error: unrecognized/unsupported machine ID (r1 = 0x100010bb)"
This error message can be documented in the linux-sunxi wiki with
proper explanations about how to resolve this situation and where
to get the necessary bugfixes for the sunxi-3.4 kernel.
The fixed sunxi-3.4 kernels implement a revision compatibility check
and clear the top 4 bits of the machine id if everything is alright.
By accepting the machine id with the bits 31:28 set to 1, the sunxi-3.4
kernel effectively certifies that it has the PLL5 clock speed and
AXP209 DCDC3 voltage fixes applied.
It is still possible to set the CONFIG_OLD_SUNXI_KERNEL_COMPAT option
in U-Boot if the user desires to use an outdated unpatched sunxi-3.4
kernel.
Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
Acked-by: Ian Campbell <ijc@hellion.org.uk>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
While discussing with some people how to get the Linux kernel to do the
right thing wrt sending output to both the serial console and the
hdmi out / lcd screen when booting on ARM devices, Grant Likely pointed out
that there already is a solution for this.
All we need to do is set the /chosen/stdout-path fdt property, and if no
console= arguments were specified on the kernel commandline the kernel
will honor this and add this device as a console (next to the primary
video output on hdmi).
And u-boot already has support for setting this, all we need to do is
define OF_STDOUT_PATH and then everything will just work ootb, without
people needing to meddle with adding console= arguments in extlinux.conf .
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Ian Campbell <ijc@hellion.org.uk>
Reviewed-by: Tom Rini <trini@ti.com>
USB doesn't seem to work yet; the controller detects the on-board Hub/
Ethernet device but can't read the descriptors from it. I haven't
investigated yet.
Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
This commits adds support for configuring a a bitbang i2c controller, which
is used on some boards to configure the LCD panel (via i2c).
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Ian Campbell <ijc@hellion.org.uk>
Since device_unbind() is also defined in device-remove.c,
which is compiled in only in case CONFIG_DM_DEVICE_REMOVE
is defined, protect the device_unbind() prototype with the
same CONFIG_DM_DEVICE_REMOVE check.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Simon Glass <sjg@chromium.org>
Cc: Stefan Roese <sr@denx.de>
Cc: Tom Rini <trini@ti.com>
Acked-by: Simon Glass <sjg@chromium.org>
This came up in a discussion on the mailing list here:
https://patchwork.ozlabs.org/patch/384613/
My concerns at the time were:
- it doesn't need to be written in assembler
- it doesn't need to be ARM-specific
This patch provides a possible alternative. It works by allowing any serial
driver to export one init function and provide a putc() function. These
can be used to output debug data before the real serial driver is available.
This implementation does not depend on driver model, and it is possible for
it to operate without a stack on some architectures (e.g. PowerPC, ARM). It
provides the same features as the ARM-specific debug.S but with more UART
and architecture support.
Signed-off-by: Simon Glass <sjg@chromium.org>
Make this option available in Kconfig and clean up the board that uses it.
Note there is also an entry in exynos5-common.h but this affects multiple
boards and should be dropped as part of the Samsung I2C migration to
driver model.
Signed-off-by: Simon Glass <sjg@chromium.org>
Since both I2C and SPI are converted to Kconfig, we can convert cros_ec
to Kconfig for these buses.
LPC will need to wait until driver mode PCI is available.
Signed-off-by: Simon Glass <sjg@chromium.org>
Commit 90bac29a76 claims to fix this bug
that was introduced in commit a92fd6577e
but doesn't actually make the change that the commit message describes.
Actually fix the bug this time.
Signed-off-by: Joe Hershberger <joe.hershberger@ni.com>
Acked-by: Simon Glass <sjg@chromium.org>
Introduce arch_reserve_stacks() to tailor gd->start_addr_sp and gd->irq_sp to
the architecture needs.
Signed-off-by: Andreas Bießmann <andreas.devel@googlemail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
This allows to define the ethaddr env variable according to the the IVM
content by reading the IVM in misc_init_r.
Later, when HUSH is available the content read earlier is analyzed to
populate some non env variables.
Signed-off-by: Valentin Longchamp <valentin.longchamp@keymile.com>
Make sunxi's FEL code fit with the normal U-Boot boot sequence instead of
creating its own. There are some #ifdefs required in start.S. Future work
will hopefully remove these.
This series is available at u-boot-dm, branch sunxi-working.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Do not use CONFIG_SYS_MEM_TOP_HIDE for the framebuffer, instead override
board_get_usable_ram_top to make sure that u-boot is not relocated into the
area where we want to use the framebuffer, and patch the devicetree from
sunxi_simplefb_setup() to tell the kernel to not touch the framebuffer.
This makes u-boot properly see the framebuffer as dram, and initalize the
level 2 cache for it, fixing the very slow cfb scrolling problem.
As an added bonus this stops us from reserving the framebuffer when simplefb
is not used because an older kernel is booted, or hdp is used and no hdmi
cable was plugged in, freeing up the memory for kernel use in these cases.
Reported-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Ian Campbell <ijc@hellion.org.uk>
The recent changes to config_distro_bootcmd.h require CONFIG_CMD_PART to be
defined, as the default bootcmd now uses the "part" command.
This fixes sunxi boards not booting with v2015.04-rc1.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Stephen Warren <swarren@nvidia.com>
SILK is an entry level development board based on R-Car E2 SoC (R8A7794)
This commit supports the following peripherals:
- SCIF, I2C, Ethernet, QSPI, MMC, USB Host
Signed-off-by: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
Reviewed-by: Tom Rini <trini@ti.com>
Signed-off-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
Abstracting dev_get_addr can improve drivers that want to
get device's address.
Signed-off-by: Peng Fan <Peng.Fan@freescale.com>
Acked-by: Igor Grinberg <grinberg@compulab.co.il>
Acked-by: Simon Glass <sjg@chromium.org>
This adds driver model support with this driver. This was tested by Koelsch
board and Gose board.
Signed-off-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
Acked-by: Simon Glass <sjg@chromium.org>
Remove driver model CONFIGs from the board config headers and use Kconfig
instead.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Ian Campbell <ijc@hellion.org.uk>
Make the driver model I2C API available always, even if driver model
is not enabled. This allows for a 'soft' switch-over, where drivers can
use the new structures in code which is compiled but not yet used. This
makes migration easier in some cases.
Fix up the existing drivers which define their own 'struct i2c_msg'.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Heiko Schocher <hs@denx.de>
As with i2c_read() and i2c_write(), add a dm_ prefix to the driver model
versions of these functions to avoid conflicts.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Heiko Schocher <hs@denx.de>
Drop the old checksum functions in favour of the new ones.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>
Many CONFIG options have an unnecessary value of 1. CONFIG_440 is set in
the various board config files. Also simplify the CONFIG_440 check in
config.mk
Signed-off-by: Simon Glass <sjg@chromium.org>
Use the bootz command to load zImages in case of any new boot scripts. Only
the legacy one will still use bootm. Apart form the fact, that this will
simplify the image generation process, it saves one copy of the kernel
image: Common practice is to generate an uImage with a loading address of
0x8000. This uImage contains a compressed zImage, which will unpack the
kernel image to the beginning of the RAM. But because there is already the
compressed image the uncompressor first relocates the compressed image to a
higher location. The load address is encoded into the uImage which is
generated by the distributions and thus cannot be easily changed. By using
the bootz command we can load the compressed image to a higher memory
address and the decompressor doesn't have to reloacte the image.
Signed-off-by: Michael Walle <michael@walle.cc>
The dtb was loaded at a memory address after the initial ramdisk. Thus a
large ramdisk would overwrite the dtb. Move it to "ramdisk_start - 64k".
64k should be enough for the device tree blob. Also the kernel
documentation arm/Booting suggests to put the dtb before the initial
ramdisk.
Signed-off-by: Michael Walle <michael@walle.cc>
The load addresses for the bootcmd_legacy script were taken from the
original bootloader from Buffalo. But newer kernels are too big and the
uncompressing will overwrite parts of the initial ramdisk. Therefore,
we switch to the load addresses which are also used by the other boot
script.
Signed-off-by: Michael Walle <michael@walle.cc>
The recent changes to config_distro_bootcmd.h require CONFIG_CMD_PART to be
defined, as the default bootcmd not uses the "part" command.
This fixes sunxi boards not booting with v2015.04-rc1.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Add linux/compiler-gcc5/h from the kernel sources at:
commit 5631b8fba640a4ab2f8a954f63a603fa34eda96b
Author: Steven Noonan <steven@uplinklabs.net>
Date: Sat Oct 25 15:09:42 2014 -0700
compiler/gcc4+: Remove inaccurate comment about 'asm goto' miscompiles
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
lcd_logo() currently performs tasks well beyond just displaying the logo.
It has code which displays splash image, it has logic which determines
when the different display features are displayed, and it is coupled with
the lcd console because it holds the responsibility of returning the
lcd console base address.
Make lcd_logo() just about the logo by:
* Moving splash image display code into a dedicated function
* Moving the logic regarding when various features are displayed to
lcd_clear() (which is arguably not the correct name for housing such
code either, but it is currently the most fitting location code wise)
* Move the responsibility of setting the console base address to
lcd_clear() too.
Signed-off-by: Nikita Kiryanov <nikita@compulab.co.il>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Bo Shen <voice.shen@atmel.com>
Tested-by: Josh Wu <josh.wu@atmel.com>
Cc: Bo Shen <voice.shen@atmel.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Anatolij Gustschin <agust@denx.de>
We now have api functions that can support compiling simplefb code as its own
module. Since this code is not part of the display functionality, extract it
to its own file.
Raspberry Pi is updated to accommodate the changes.
Signed-off-by: Nikita Kiryanov <nikita@compulab.co.il>
Acked-by: Stephen Warren <swarren@wwwdotorg.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Bo Shen <voice.shen@atmel.com>
Tested-by: Josh Wu <josh.wu@atmel.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Anatolij Gustschin <agust@denx.de>
Cc: Stephen Warren <swarren@wwwdotorg.org>
This cleanup mostly focuses on removing unnecessary whitespace and comments
which are superfluous and/or do not conform to the coding style.
Signed-off-by: Nikita Kiryanov <nikita@compulab.co.il>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Bo Shen <voice.shen@atmel.com>
Tested-by: Josh Wu <josh.wu@atmel.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Anatolij Gustschin <agust@denx.de>
configuration_get_cmap() is multiple platform-specific functions stuffed into
one function. Split it into multiple versions, and move each version to the
appropriate driver to reduce the #ifdef complexity.
Signed-off-by: Nikita Kiryanov <nikita@compulab.co.il>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Bo Shen <voice.shen@atmel.com>
Tested-by: Josh Wu <josh.wu@atmel.com>
Cc: Bo Shen <voice.shen@atmel.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Anatolij Gustschin <agust@denx.de>
common/lcd code is full of platform-specific code and definitions, which
ideally should reside with the respective driver code. Take a step towards that
goal by moving platform-specific structs from lcd.h to their own header files.
The structs for the generic case (the #else for all the platform-specific
cases) is retained in lcd.h as the default case.
Signed-off-by: Nikita Kiryanov <nikita@compulab.co.il>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Bo Shen <voice.shen@atmel.com>
Tested-by: Josh Wu <josh.wu@atmel.com>
Cc: Bo Shen <voice.shen@atmel.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Anatolij Gustschin <agust@denx.de>
"#define PFUZE100_SW1ABC_SETP(x) ((x - 3000) / 250)"
This macro is for configuring SW1A/B/C Output Voltage easily.
Signed-off-by: Peng Fan <Peng.Fan@freescale.com>
This patch has some parts connected together:
- Use _gd in bss section which is automatically cleared
Location at SPL_MALLOC_END wasn't cleared at all
- Use MALLOC_F_LEN(early alloc) instead of FULL MALLOC
(mem_malloc_init is not called at all)
- Simplify malloc and stack init.
At the end of SPL addr is malloc area and below is stack
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Compile code with -fPIC to get GOT. Do not build SPL
with fPIC because it increasing SPL size for nothing.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Following SPARK ARC now has SYS_MONITOR_BASE setup via Kconfig.
This makes "include/configs/*.h" cleaner and more flexible.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Common arch_early_init_r() is used in "arc/lib/cpu.c" for all ARC boards
so there's no sense in separate per-board definitions.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Currently there's nothing related to really low-level init on ARC so
CONFIG_SKIP_LOWLEVEL_INIT definition makes no sense.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
There're no other options for ARC except "generic board" so ther's no
point to define CONFIG_SYS_GENERIC_BOARD per board.
We now have it set fo all ARC boards.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
This change allows to keep board description clean and minimalistic.
This is especially helpful if one board may house different CPUs with
different features.
It is applicable to both FPGA-based boards or those that have CPUs
mounted on interchnagable daughter-boards.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
This change allows to keep board description clean and minimalistic.
This is especially helpful if one board may house different CPUs with
different features.
It is applicable to both FPGA-based boards or those that have CPUs
mounted on interchnagable daughter-boards.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Now we may select a particular version of ARC700:
* ARC750D or
* ARC770D
It allows more flexible (or more fine tuned) configuration of U-Boot.
Before that change we relied on minimal configuration but now we may
use specific features of each CPU.
Moreover allows us to escape manual selection of options that
exist in both CPUs but may have say different version like MMUv2 in
ARC750D vs MMUv3 in ARC770D.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
With switch to Kconfig we only need very board-specific descriptions in
include/configs.
CPU selection is performed with either defconfig or manually via
menuconfig.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
This patch will save U-Boot environment as a file: uboot.env, in FAT partition
instead of saving it in raw sector of MMC card.
This make us easier to manage the environment file.
Signed-off-by: Josh Wu <josh.wu@atmel.com>
Acked-by: Bo Shen <voice.shen@atmel.com>
This patch will save U-Boot environment as a file: uboot.env, in FAT partition
instead of in raw sector of MMC card.
This make us easier to manage the environment file.
Signed-off-by: Josh Wu <josh.wu@atmel.com>
Acked-by: Bo Shen <voice.shen@atmel.com>
This patch will save U-Boot environment as a file: uboot.env, in FAT partition
instead of saving it in raw sector of MMC card.
This make us easier to manage the environment file.
Signed-off-by: Josh Wu <josh.wu@atmel.com>
Acked-by: Bo Shen <voice.shen@atmel.com>
Current the MMC support will enable MCI port A, Which is only exist
for 2mmc board.
So by default we need to disable MMC (port A) support. And only enable
it for 2mmc board. Otherwise, dataflash won't work in at91sam9260ek board
as MMC has confliction with Dataflash in the CLK pin.
Signed-off-by: Josh Wu <josh.wu@atmel.com>
There are two typos in the comment block in bootstage.h, fix them.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
Intel Galileo board has a microSD slot which is routed from Quark SoC
SDIO controller. Enable SD/MMC support so that we can use an SD card.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
Add standard dt-bindings macros to be used by Intel Quark MRC node.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
Add COMPAT_INTEL_QRK_MRC and "intel,quark-mrc" so that fdtdec can
decode Intel Quark MRC node.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
New board/intel/galileo board directory with minimum codes, plus
board dts, defconfig and configuration files.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
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>
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>
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 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>
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>
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>
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>
There is an existing function prototype in the header file but it is not
implemented. Implement something similar.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
It turns out that the device_mode_data is rsb specific, rather then slave
specific, so integrate the rsb_set_device_mode() call into rsb_init().
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Ian Campbell <ijc@hellion.org.uk>
We do not need i2c support in the SPL when there is no PMIC (some sun4i
boards), or when the PMIC is not using i2c such as on sun6i and sun8i.
This reduces the SPL size from (e.g.) 21812 to 19260 bytes.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Ian Campbell <ijc@hellion.org.uk>
This patch adds support for handling 828024 and 826974 erratas
for Cortex-A57 cores present on LS2085A SoC.
Signed-off-by: Bhupesh Sharma <bhupesh.sharma@freescale.com>
The Juno Development Platform is a physical Versatile Express
device with some differences from the emulated semihosting
models. The main difference is that the system is split in
a SoC and an FPGA where the SoC hosts the serial ports at
totally different adresses.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The Versatile Express ARMv8 semihosted FVP platform is still
using the legacy CONFIG_SYS_EXTRA_OPTIONS method to configure
some compile-time flags. Get rid of this and create a Kconfig
entry for the FVP model, and a selectable bool for the
semihosting library.
The FVP subboard is now modeled as a target choice so we can
eventually choose between different ARMv8 versatile express
boards (FVP, base model, Juno...) this way. All dependent
symbols are updated to reflect this.
The 64bit Versatile Express board symbols are renamed
VEXPRESS64 so we have some chance to see what is actually
going on. Tested on the FVP fast model.
Acked-by: Steve Rae <srae@broadcom.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
only tested tested under QEMU with vexpress_ca9x4 ("-M vexpress-a9") and
vexpress_ca15_tc2 ("-M vexpress-a15"). Makes the ugly warning go away.
Signed-off-by: Chris Kuethe <chris.kuethe+github@gmail.com>
Modify $bootcmd_dhcp to read the downloaded script filename from an
environment variable rather than hard-coding it. This allows the user
(or another script) to select a different script name if they want,
without editing the whole value of $bootcmd_dhcp.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
These functions are useful in case the board calls them. Also fix a missing
parameter caused by applying the wrong patch (actually I failed to send v2
and applied v1 by mistake).
Signed-off-by: Simon Glass <sjg@chromium.org>
This patch enables CONFIG_DM_I2C and also CONFIG_DM_I2C_COMPAT.
The last one should be removed when all the i2c peripheral
drivers will use dm i2c framework.
Signed-off-by: Przemyslaw Marczak <p.marczak@samsung.com>
Acked-by: Simon Glass <sjg@chromium.org>
Cc: Akshay Saraswat <akshay.s@samsung.com>
Cc: Minkyu Kang <mk7.kang@samsung.com>
Cc: Simon Glass <sjg@chromium.org>
This patch enables CONFIG_DM_I2C and also CONFIG_DM_I2C_COMPAT.
The last one should be removed when the dm pmic framework will
be finished.
Signed-off-by: Przemyslaw Marczak <p.marczak@samsung.com>
Acked-by: Simon Glass <sjg@chromium.org>
Cc: Minkyu Kang <mk7.kang@samsung.com>
This commit enable support for the above driver,
which was disabled in common config.
Signed-off-by: Przemyslaw Marczak <p.marczak@samsung.com>
Acked-by: Simon Glass <sjg@chromium.org>
Cc: Simon Glass <sjg@chromium.org>
Cc: Minkyu Kang <mk7.kang@samsung.com>
This PMIC is not common for all Exynos5250
based boards, so should be romoved from
common config.
Signed-off-by: Przemyslaw Marczak <p.marczak@samsung.com>
Acked-by: Simon Glass <sjg@chromium.org>
Cc: Simon Glass <sjg@chromium.org>
Cc: Minkyu Kang <mk7.kang@samsung.com>
There is no MAX77686 pmic on this board,
so the driver support should be removed.
Signed-off-by: Przemyslaw Marczak <p.marczak@samsung.com>
Cc: Minkyu Kang <mk7.kang@samsung.com>
Currently the hash functions used in RSA are called directly from the sha1
and sha256 libraries. Change the RSA checksum library to use the progressive
hash API's registered with struct hash_algo. This will allow the checksum
library to use the hardware accelerated progressive hash API's once available.
Signed-off-by: Ruchika Gupta <ruchika.gupta@freescale.com>
CC: Simon Glass <sjg@chromium.org>
Acked-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>
(Fixed build error in am335x_boneblack_vboot due to duplicate CONFIG_DM)
Change-Id: Ic44279432f88d4e8594c6e94feb1cfcae2443a54
The hash_algo structure has some implementations in which progressive hash
API's are not defined. These are basically the hardware based implementations
of SHA. An API is added to find the algo which has progressive hash API's
defined. This can then be integrated with RSA checksum library which uses
Progressive Hash API's.
Signed-off-by: Ruchika Gupta <ruchika.gupta@freescale.com>
CC: Simon Glass <sjg@chromium.org>
Acked-by: Simon Glass <sjg@chromium.org>
Modify rsa_verify to use the rsa driver of DM library .The tools
will continue to use the same RSA sw library.
CONFIG_RSA is now dependent on CONFIG_DM. All configurations which
enable FIT based signatures have been modified to enable CONFIG_DM
by default.
Signed-off-by: Ruchika Gupta <ruchika.gupta@freescale.com>
CC: Simon Glass <sjg@chromium.org>
Acked-by: Simon Glass <sjg@chromium.org>
For the platforms which use,CONFIG_FIT_SIGNATURE, the required configs are
moved to the platform's defconfig file. Selecting CONFIG_FIT_SIGNATURE using
defconfig automatically resolves the dependencies for signature verification.
The RSA library gets automatically selected and user does not have to define
CONFIG_RSA manually.
Signed-off-by: Ruchika Gupta <ruchika.gupta@freescale.com>
CC: Simon Glass <sjg@chromium.org>
Acked-by: Simon Glass <sjg@chromium.org>
Add a new rsa uclass for performing modular exponentiation and implement
the software driver basing on this uclass.
Signed-off-by: Ruchika Gupta <ruchika.gupta@freescale.com>
CC: Simon Glass <sjg@chromium.org>
Acked-by: Simon Glass <sjg@chromium.org>
Public exponentiation which is required in rsa verify functionality is
tightly integrated with verification code in rsa_verify.c. The patch
splits the file into twp separating the modular exponentiation.
1. rsa-verify.c
- The file parses device tree keys node to fill a keyprop structure.
The keyprop structure can then be converted to implementation specific
format.
(struct rsa_pub_key for sw implementation)
- The parsed device tree node is then passed to a generic rsa_mod_exp
function.
2. rsa-mod-exp.c
Move the software specific functions related to modular exponentiation
from rsa-verify.c to this file.
Signed-off-by: Ruchika Gupta <ruchika.gupta@freescale.com>
CC: Simon Glass <sjg@chromium.org>
Acked-by: Simon Glass <sjg@chromium.org>
this is an atempt to make the export of functions typesafe.
I replaced the jumptable void ** by a struct (jt_funcs) with function pointers.
The EXPORT_FUNC macro now has 3 fixed parameters and one
variadic parameter
The first is the name of the exported function,
the rest of the parameters are used to format a functionpointer
in the jumptable,
the EXPORT_FUNC macros are expanded three times,
1. to declare the members of the struct
2. to initialize the structmember pointers
3. to call the functions in stubs.c
Signed-off-by: Martin Dorwig <dorwig@tetronik.com>
Acked-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>
(resending to the list since my tweaks are not quite trivial)
This has moved to driver model so we don't need the fdtdec support.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Minkyu Kang <mk7.kang@samsung.com>
At present we go through various contortions to store the I2C's chip
address in its private data. This only exists when the chip is active so
must be set up when it is probed. Until the device is probed we don't
actually record what address it will appear on.
However, now that we can support per-child platform data, we can use that
instead. This allows us to set up the address when the child is bound,
and avoid the messy contortions.
Unfortunately this is a fairly large change and it seems to be difficult to
break it down further.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
At present we go through various contortions to store the SPI slave's chip
select in its private data. This only exists when the slave is active so
must be set up when it is probed. Until the device is probed we don't
actually know what chip select it will appear on.
However, now that we can support per-child platform data, we can use that
instead. This allows us to set up the chip select when the child is bound,
and avoid the messy contortions.
Unfortunately this is a fairly large change and it seems to be difficult to
break it down further.
Signed-off-by: Simon Glass <sjg@chromium.org>
Some buses need to set up their devices before they can be used. This setup
may well be common to all buses in a particular uclass. Support a common
pre-probe method for the uclass, called before any bus devices are probed.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
For buses, after a child is bound, allow the uclass to perform some
processing. This can be used to figure out the address of the child (e.g.
the chip select for SPI slaves) so that it is ready to be probed.
This avoids bus drivers having to repeat the same process, which really
should be done by the uclass, since it is common.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
In many cases the per-child private data for a device's children is defined
by the uclass rather than the individual driver. For example, a SPI bus
needs to store information about each of its children, but all SPI drivers
store the same information. It makes sense to allow the uclass to define
this data.
If the driver provides a size value for its per-child private data, then use
it. Failng that, fall back to that provided by the uclass.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
At present we try to use the 'reg' property and device tree aliases to give
devices a sequence number. The 'reg' property is often actually a memory
address, so the sequence numbers thus-obtained are not useful. It would be
better if the devices were just sequentially numbered in that case. In fact
neither I2C nor SPI use this feature, so drop it.
Some devices need us to look up an alias to number them within the uclass.
Add a flag to control this, so it is not done unless it is needed.
Adjust the tests to test this new behaviour.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
This is useful to check which uclass a device is in.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Allow parent drivers to be called when a new child is bound to them. This
allows a bus to set up information it needs for that child.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
In many cases the child platform data for a device's children is defined by
the uclass rather than the individual devices. For example, a SPI bus needs
to know the chip select and speed for each of its children. It makes sense
to allow this information to be defined the SPI uclass rather than each
individual driver.
If the device provides a size value for its child platdata, then use it.
Failng that, fall back to that provided by the uclass.
Reviewed-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
For buses it is common for parents to need to know the address of the child
on the bus, the bus speed to use for that child, and other information. This
can be provided in platform data attached to each child.
Add driver model support for this, including auto-allocation which can be
requested using a new property to specify the size of the data.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Rather than assuming that the chip offset length is 1, allow it to be
provided. This allows chips that don't use the default offset length to
be used (at present they are only supported by the command line 'i2c'
command which sets the offset length explicitly).
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Heiko Schocher <hs@denx.de>
For boards which use multiple I2C devices, or for SOCs which support
multiple boards, we might want to convert these to driver model at different
times. At present this is difficult because we need to either use
CONFIG_DM_I2C for a board or not.
Add a compatibility layer which implements the old API, thus allowing a
board to move to driver model for I2C without requiring that everything it
uses is moved in the same commit.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add a dm_ prefix to driver model I2C functions so that we can keep the old
ones around.
This is a little unfortunate, but on reflection it is too difficult to
change the API. We can undo this rename when most boards and drivers are
converted to use driver model for I2C.
Signed-off-by: Simon Glass <sjg@chromium.org>
Now that we support device tree GPIO bindings directly in the driver model
GPIO uclass we can remove these functions.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add a new 'demo light' command which uses GPIOs to control imaginary lights.
Each light is assigned a bit number in the overall value. This provides an
example driver for using the new GPIO API.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add a deprecation notice to each function so that it is more obvious that we
are moving GPIOs to driver model.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present U-Boot sort-of supports the standard way of reading GPIOs from
device tree nodes, but the support is incomplete, a bit clunky and only
works for GPIO bindings where #gpio-cells is 2.
Add new functions to request GPIOs, taking full account of the device
tree binding. These permit requesting a GPIO with a simple call like:
gpio_request_by_name(dev, "cd-gpios", 0, &desc, GPIOD_IS_IN);
This will request the GPIO, looking at the device's node which might be
this, for example:
cd-gpios = <&gpio TEGRA_GPIO(B, 3) GPIO_ACTIVE_LOW>;
The GPIO will be set to input mode in this case and polarity will be
honoured by the GPIO calls.
It is also possible to request and free a list of GPIOs.
Signed-off-by: Simon Glass <sjg@chromium.org>
Only the GPIO driver knows about the full GPIO device tree binding used by
a device. Add a method to allow the driver to provide this information to the
uclass, including the GPIO offset within the device and flags such as the
polarity.
Signed-off-by: Simon Glass <sjg@chromium.org>
So far driver model's GPIO uclass just implements the existing GPIO API.
This has some limitations:
- it requires manual device tree munging to support GPIOs in device tree
(fdtdec_get_gpio() and friends)
- it does not understand polarity
- it is somewhat slower since we must scan for the GPIO device each time
- Global GPIO numbering can change if other GPIO drivers are probed
- it requires extra steps to set the GPIO direction and value
The new functions have a dm_ prefix where necessary to avoid name conflicts
but we can remove that when it is no-longer needed. The new struct gpio_desc
holds all required information about the GPIO. For now this is intended to
be stored by the client requesting the GPIO, but in future it might be
brought into the uclass in some way.
With these changes the old GPIO API still works, and uses the driver model
API underneath.
Signed-off-by: Simon Glass <sjg@chromium.org>
For GPIOs and other functions we want to look up a phandle and then decode
a list of arguments for that phandle. Each phandle can have a different
number of arguments, specified by a property in the target node. This is
the "#gpio-cells" property for GPIOs.
Add a function to provide this feature, taken modified from Linux 3.18.
Signed-off-by: Simon Glass <sjg@chromium.org>
The common/board_r.c has show_model_r() to display the model name
if the DTB has a "model" property. It sounds useful to have a similar
function in common/board_f.c too because most of the boards show
their board name before relocation.
Instead of implementing the same function in both common/board_f.c
and common/board_r.c, let's split it up into common/show_board_info.c.
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Acked-by: Simon Glass <sjg@chromium.org>
The dumpimage is able to extract components contained in a FIT image:
$ ./dumpimage -T flat_dt -i CONTAINER.ITB -p INDEX FILE
The CONTAINER.ITB is a regular FIT container file. The INDEX is the poisition
of the sub-image to be retrieved, and FILE is the file (path+name) to save the
extracted sub-image.
For example, given the following kernel.its to build a kernel.itb:
/dts-v1/;
/ {
...
images {
kernel@1 {
description = "Kernel 2.6.32-34";
data = /incbin/("/boot/vmlinuz-2.6.32-34-generic");
type = "kernel";
arch = "ppc";
os = "linux";
compression = "gzip";
load = <00000000>;
entry = <00000000>;
hash@1 {
algo = "md5";
};
};
...
};
...
};
The dumpimage can extract the 'kernel@1' node through the following command:
$ ./dumpimage -T flat_dt -i kernel.itb -p 0 kernel
Extracted:
Image 0 (kernel@1)
Description: Kernel 2.6.32-34
Created: Wed Oct 22 15:50:26 2014
Type: Kernel Image
Compression: gzip compressed
Data Size: 4040128 Bytes = 3945.44 kB = 3.85 MB
Architecture: PowerPC
OS: Linux
Load Address: 0x00000000
Entry Point: 0x00000000
Hash algo: md5
Hash value: 22352ad39bdc03e2e50f9cc28c1c3652
Which results in the file 'kernel' being exactly the same as '/boot/vmlinuz-2.6.32-34-generic'.
Signed-off-by: Guilherme Maciel Ferreira <guilherme.maciel.ferreira@gmail.com>
Move the bootcmd commands into a seperate distro_bootcmd environment
variable. Allowing a user to easily launch the distro boot sequence if
the default bootcmd did not default to distro boot commands.
Also set CONFIG_BOOTCOMMAND to "run distro_bootcmd" if it hasn't been
configured yet rather then putting it directly in the environment. This
allows boards to make the distro boot commands available without
necessarily default to them or to use them as a fallback after running
some board specific commands instead.
Signed-off-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
Reviewed-by: Stephen Warren <swarren@nvidia.com>
Not all devices use the convention that the boot scripts are on the
first partition. For example on chromebooks it seems common for the
first two partitions to be ChromeOS kernel partitions.
So instead of just the first partition scan all partitions on a device
with a filesystem u-boot can recognize.
Signed-off-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
New command to determine the filesystem type of a given partition.
Optionally stores the filesystem type in a environment variable.
Signed-off-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
Reviewed-by: Stephen Warren <swarren@nvidia.com>
- use linux display timing settings
- change backlight duty cycle 500ns
- some defaultenvironment changes
- change fit_addr_r to 0x14000000 as needed if
MAX_LOCKDEP_SUBCLASSES in linux gets increased.
- Environment now at 0xd0000 in nand flash
Signed-off-by: Heiko Schocher <hs@denx.de>
Use the STATUS_LED APIs for indicating a boot progress instead of
show_boot_progress.
This patch also fixes a problem introduced with commit b3f4ca1135 (dm: omap3:
Move to driver model for GPIO and serial). After that commit the board doesn't
boot. Looks like the problem is the gpio_request call inside the function
show_boot_progress.
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Generic board with #define CONFIG_SYS_GENERIC_BOARD is working fine.
There is no visible difference between legacy and generic board code.
Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
Acked-by: Pavel Machek <pavel@ucw.cz>
Move board/compulab/common/splash.c code to
common/splash_source.c to make it available for everybody. This move
renames cl_splash_screen_prepare() to splash_source_load(), and
the compilation of this code is conditional on CONFIG_SPLASH_SOURCE.
splash_source features:
* Provide a standardized way for declaring board specific splash screen
locations
* Provide existing routines for auto loading the splash image from the
locations as declared by the board
* Introduce the "splashsource" environment variable, which makes it
possible to select the splash image source.
cm-t35 and cm-fx6 are updated to use the modified version.
Signed-off-by: Nikita Kiryanov <nikita@compulab.co.il>
Cc: Stefano Babic <sbabic@denx.de>
Cc: Tom Rini <trini@ti.com>
Cc: Igor Grinberg <grinberg@compulab.co.il>
Cc: Anatolij Gustschin <agust@denx.de>
Reviewed-by: Tom Rini <trini@ti.com>
Acked-by: Igor Grinberg <grinberg@compulab.co.il>
Add support for splash screen.
The splash screen is loaded from the SPI flash and is displayed on the
HDMI display.
Signed-off-by: Nikita Kiryanov <nikita@compulab.co.il>
[grinberg@compulab.co.il: minor code and commit message updates]
Signed-off-by: Igor Grinberg <grinberg@compulab.co.il>
Cc: Stefano Babic <sbabic@denx.de>
Cc: Igor Grinberg <grinberg@compulab.co.il>
