RK3128 is a SoC from Rockchip with quad-core Cortex-A7 CPU
and mali400 GPU. Support Nand flash, eMMC, SD card, USB 2.0 host
and device, HDMI/LVDS/MIPI display.
Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
Acked-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Add dts binding header for rk3128, files origin from kernel.
Series-Changes: 2
- fix i2c address
- add saradc and usb phy node
- emmc using fifo mode for there is no dma support in rk3128 emmc
- add some clock id in cru.h
Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
Acked-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
After commit d962e5dadc2c("rockchip: mkimage: use spl_boot0 for all Rockchip SoCs"),
the mkimage will not pad the Tag memroy, so we shoud
pass a Taged ddr.bin/spl.bin to it.
Signed-off-by: Andy Yan <andy.yan@rock-chips.com>
Acked-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
With some of the recent cleanups (e.g. moving the DRAM controller
drivers for Rockchip devices to drivers/ram/rockchip), the files
and paths listed in MAINTAINERS no longer covered what really is
looked after as part of the Rockchip port.
This commit updates the files/paths listed in MAINTAINERS for the
Rockchip port. I am certain, though, that this will have missed some
additional paths that should have been included...
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Acked-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Rework the ULCB CPLD driver and make it into a sysreset driver,
since that is what the ULCB CPLD driver is mostly for.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
The order of members in struct hws_topology_map is cas_wl, cas_l. The
comments in the original db-88f6820-gp.c had this wrong and have been
copied to other Armada-385 based boards. Practically this hasn't made a
difference since all these boards set both cas_wl and cas_l to 0
(autodetect) but if there were ever a board that did need to set these
explicitly they would run into unexpected issued.
Update the comments to reflect the correct order of structure members.
Reported-by: Tobi Wulff <tobi.wulff@alliedtelesis.co.nz>
Signed-off-by: Chris Packham <judge.packham@gmail.com>
Reviewed-by: Stefan Roese <sr@denx.de>
Signed-off-by: Stefan Roese <sr@denx.de>
CONFIG_ENV_IS_IN_NAND has been removed in commit 2be296538e (Convert
CONFIG_ENV_IS_IN_MMC/NAND/UBI and NOWHERE to Kconfig).
CONFIG_ENV_IS_IN_SPI_FLASH has been removed in commit 91c868fe7c
(Convert CONFIG_ENV_IS_IN_SPI_FLASH to Kconfig). The environment #ifdef
is now empty. Remove it.
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Stefan Roese <sr@denx.de>
Check if we are booting from NAND and let the bootrom
continue to load the rest of the bootloader
Signed-off-by: Sean Nyekjaer <sean.nyekjaer@prevas.dk>
Signed-off-by: Stefan Roese <sr@denx.de>
It's the first 8 bits of the bootrom error register that
contain the boot error/fallback error code. Let's check that
and continue to boot from UART.
Signed-off-by: Sean Nyekjaer <sean.nyekjaer@prevas.dk>
Signed-off-by: Stefan Roese <sr@denx.de>
bbt_mirror_descr and bbt_main_descr is defined but not used
when compiling without CONFIG_SYS_NAND_USE_FLASH_BBT set.
Signed-off-by: Sean Nyekjaer <sean.nyekjaer@prevas.dk>
Signed-off-by: Stefan Roese <sr@denx.de>
This patch removes the inclusion of the libgcc math functions and
replaces them by functions coded in C, taken from the coreboot
project. This makes U-Boot building more independent from the toolchain
installed / available on the build system.
The code taken from coreboot is authored from Vadim Bendebury
<vbendeb@chromium.org> on 2014-11-28 and committed with commit
ID e63990ef [libpayload: provide basic 64bit division implementation]
(coreboot git repository located here [1]).
I modified the code so that its checkpatch clean without any
functional changes.
[1] git://github.com/coreboot/coreboot.git
Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Simon Glass <sjg@chromium.org>
Cc: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
Currently X86 does not properly support distro defaults.
This patch is only a partial fix.
It provides the name of the bootloader EFI application
for the X86 architecture.
The architecture dependent file names are defined in the UEFI
specification.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
This reverts commit 13c531e52a.
The error message with FIT style image mentioned in the above commit
only happens when booting using FIT image containing bzImage kernel
and without setup node (setup.bin). The current documentation for
x86 FIT support in doc/uImage.FIT/x86-fit-boot.txt mentions that
kernel's setup.bin file is required for building x86 FIT images.
The above commit breaks FIT images generated as described in the
documentation. Revert it to allow booting with images built in the
documented way.
Signed-off-by: Anatolij Gustschin <agust@denx.de>
Reviewed-by: Stefan Roese <sr@denx.de>
Acked-by: Bin Meng <bmeng.cn@gmail.com>
x86_vendor_name is defined as
static const char *const x86_vendor_name[]
So its elements should not be compared to 0.
Remove superfluous paranthesis.
Problem identified with Coccinelle.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Adjust VGA rom address to 0xfffb0000 so that u-boot.rom image
can be built again.
Signed-off-by: Anatolij Gustschin <agust@denx.de>
Reviewed-by: Stefan Roese <sr@denx.de>
Acked-by: Bin Meng <bmeng.cn@gmail.com>
ROM has been made read-only in qemu recently (namely commit 208fa0e4:
"pc: make 'pc.rom' readonly when machine has PCI enabled"). So this
patch restores compatibility between U-Boot and qemu.
Signed-off-by: Anton Gerasimov <anton@advancedtelematic.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
[bmeng: mention qemu commit title in the commit message]
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Before this patch one could receive following errors when executing "fatls"
command on machine with cache enabled (ex i.MX6Q) :
=> fatls mmc 0:1
CACHE: Misaligned operation at range [4f59dfc8, 4f59e7c8]
CACHE: Misaligned operation at range [4f59dfc8, 4f59e7c8]
ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x4f59dfc8
ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x4f59e7c8
CACHE: Misaligned operation at range [4f59dfc8, 4f59e7c8]
CACHE: Misaligned operation at range [4f59dfc8, 4f59e7c8]
ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x4f59dfc8
ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x4f59e7c8
To alleviate this problem - the calloc()s have been replaced with
malloc_cache_aligned() and memset().
After those changes the buffers are properly aligned (with both start
address and size) to SoC cache line.
Fixes: 09fa964bba ("fs/fat: Fix 'CACHE: Misaligned operation at range' warnings")
Suggested-by: Lukasz Majewski <lukma@denx.de>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
This board is based on the Atmel sama5d3 eval boards.
Supporting the following features:
- Boot from NAND Flash
- Ethernet
- FIT
- SPL
Signed-off-by: Ben Whitten <ben.whitten@lairdtech.com>
Signed-off-by: Dan Kephart <dan.kephart@lairdtech.com>
This board is based on the Atmel 9x5 eval board.
Supporting the following features:
- Boot from NAND Flash
- Ethernet
- FIT
- SPL
Signed-off-by: Ben Whitten <ben.whitten@lairdtech.com>
Signed-off-by: Dan Kephart <dan.kephart@lairdtech.com>
GCC 7.1 seems to be smart enough to track val through the various
static inline functions, but not smart enough to see that val will
always be initialised when no error is returned. This triggers
the following warning:
env/mmc.c: In function 'mmc_get_env_addr':
env/mmc.c:121:12: warning: 'val' may be used uninitialized in this function [-Wmaybe-uninitialized]
To make it easier for compiler to understand what is going on, let's
initialise val.
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Building spl with CONFIG_OF_EMBED enabled results in an error message
on my board: "SPL image too big". This is because the fdtgrep build
step is only executed for CONFIG_OF_SEPARATE.
Fix this by moving the fdtgrep build step ('cmd_fdtgreo') from
scripts/Makefile.spl to dts/Makefile so that the reduced dtb is
available for all kinds of spl builds.
The resulting variable name for the embedded device tree blob changes,
too, which is why common.h and fdtdec.c have tiny changes.
Signed-off-by: Simon Goldschmidt <sgoldschmidt@de.pepperl-fuchs.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
In U-Boot, this device tree is compatible with both the Torpedo and
SOM-LV kits. Let's rename it in the device tree since the U-Boot code and
show a more generic OMAP3 name. The code auto detects between the two and
loads the proper DTB file for Linux. This would eliminate the SOM-LV showing
the name Torpedo during boot and hopefully eliminate some confusion.
Signed-off-by: Adam Ford <aford173@gmail.com>
It is unwise to first dereference a variable
and then to check if it was NULL.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Marek Behun <marek.behun@nic.cz>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
When copying the command line buffer the target array should
at least have the same size.
Cf. definition of console_buffer in common/cli_readline.c.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
use ALLOC_CACHE_ALIGN_BUFFER_PAD for mbr header allocation
in stack to fix alloc issue in is_gpt_valid()
this patch fix also issue for GPT partition handling
with blocksize != 512 in set_protective_mbr()
Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
Add the SAMA5D2 PTC EK board and remove the SAMA5D2 PTC ENGI board
which was a prototype.
Signed-off-by: Ludovic Desroches <ludovic.desroches@microchip.com>
Signed-off-by: Wenyou Yang <wenyou.yang@microchip.com>
Add a header for SAMA5D2 SMC since it's not compatible with
SAMA5D3 one.
Signed-off-by: Ludovic Desroches <ludovic.desroches@microchip.com>
[wenyou: fix the wrong base address of the SMC register]
Signed-off-by: Wenyou Yang <wenyou.yang@microchip.com>
The capabilities have default values which doesn't reflect the reality
when it concerns the base clock and the mul value. Use a fixe rate
for the gck. 240 MHz is an arbitrary choice, it is a multiple of the
maximum SD clock frequency handle by the controller and it allows to
get a 400 kHz clock for the card initialisation.
Signed-off-by: Ludovic Desroches <ludovic.desroches@microchip.com>
Signed-off-by: Wenyou Yang <wenyou.yang@microchip.com>
Differentiate the generic clock source selection value from the parent
clock index to fix the incorrect assignment of the generic clock
source selection.
Signed-off-by: Wenyou Yang <wenyou.yang@microchip.com>
To get the same behavior as the Linux driver, instead of selecting
the closest inferior rate, select the closest inferior or superior
rate
Signed-off-by: Ludovic Desroches <ludovic.desroches@microchip.com>
Signed-off-by: Wenyou Yang <wenyou.yang@microchip.com>
What the AT91_UTMI depends on SPL_DM isn't right. AT91_UTMI is not
only used in SPL, also in other place, even if SPL_DM isn't enabled.
Signed-off-by: Wenyou Yang <wenyou.yang@microchip.com>
MPU's region setup can be factorized between STM32F4/F7/H7 SoCs family
and used a common MPU's region config.
Only one exception for STM32H7 which doesn't have device area
located at 0xA000 0000.
For STM32F4, configure_clocks() need to be moved from arch_cpu_init()
to board_early_init_f().
Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
Reviewed-by: Vikas Manocha <vikas.manocha@st.com>
In order to factorize code between STM32F4 and STM32F7
migrate all structs related to RCC clocks in include/stm32_rcc.h
Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
Reviewed-by: Vikas Manocha <vikas.manocha@st.com>
MMC block needs 48Mhz source clock, for that we choose
to select the SAI PLL.
Update also stm32_clock_get_rate() to retrieve the MMC
clock source needed in MMC driver.
STM32F4 uses a different RCC variant than STM32F7. For STM32F4
sdmmc clocks bit are located into dckcfgr register whereas there
are located into dckcfgr2 registers on STM32F7.
In both registers, bits CK48MSEL and SDMMC1SEL are located at
the same position.
Signed-off-by: Christophe Priouzeau <christophe.priouzeau@st.com>
Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
Reviewed-by: Vikas Manocha <vikas.manocha@st.com>
Like STM32H7, now STM32F4/F7 clock drivers are binded by
MFD stm32_rcc driver.
This also allows to add reset support to STM32F4/F7 SoCs family.
As Reset driver is not part of SPL supported drivers, don't bind it
in case of SPL to avoid that stm32_rcc_bind() returns an error.
Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
Reviewed-by: Vikas Manocha <vikas.manocha@st.com>
This allows to add rcc MFD support to stm32f746-disco board
This rcc MFD driver manages clock and reset for STM32 SoCs family
Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
Reviewed-by: Vikas Manocha <vikas.manocha@st.com>
STM32F4 doesn't get rcc.h file, to avoid compilation
issue, migrate RCC related defines from rcc.h to driver
file and remove rcc.h file.
Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
Reviewed-by: Vikas Manocha <vikas.manocha@st.com>
Now that clk_stm32f7.c manages clocks for both STM32F4 and F7 SoCs
rename it to a more generic clk_stm32f.c
Fix also some checkpatch errors/warnings.
Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
Reviewed-by: Vikas Manocha <vikas.manocha@st.com>
STM32F4 and STM32F7 RCC clock IP are very similar.
Same driver can be used to managed RCC clock for
these 2 SoCs.
Differences between STM32F4 and F7 will be managed using
different compatible string :
_ overdrive clock is only supported by STM32F7
_ different sys_pll_psc parameters can be used between STM32F4
and STM32F7.
Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
Reviewed-by: Vikas Manocha <vikas.manocha@st.com>
Align the RCC compatible string with the one used by kernel.
It will allow to use the same clock driver for STM32F4
and STM32F7 and to manage the differences between the 2 SoCs
Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
Reviewed-by: Vikas Manocha <vikas.manocha@st.com>
Add a dedicated stm32f7 compatible string to use clk_stm32f7
driver with both STM32F4 and STM32F7 SoCs.
It will be needed to manage differences between these 2 SoCs.
Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
Reviewed-by: Vikas Manocha <vikas.manocha@st.com>
PWR IP is used to enable over-drive feature in
order to reach a higher frequency.
Get its base address from DT instead of hard-coded value
Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
Reviewed-by: Vikas Manocha <vikas.manocha@st.com>
This node is needed to enable performance mode
when system frequency is set up to 200Mhz.
Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
Reviewed-by: Vikas Manocha <vikas.manocha@st.com>
Up to now we were able to read/write environment data from/to UBI
volumes only indirectly by gluebi driver. This driver creates NAND MTD
on top of UBI volumes, which is quite a workaroung for this use case.
Add support for direct read/write UBI volumes in order to not use
obsolete gluebi driver.
Forward-ported from this patch:
http://patchwork.ozlabs.org/patch/619305/
Original patch:
Signed-off-by: Marcin Niestroj <m.niestroj@grinn-global.com>
Forward port:
Signed-off-by: S. Lockwood-Childs <sjl@vctlabs.com>
