There are already two FIT options in Kconfig but the CONFIG options are
still in the header files. We need to do a proper move to fix this.
Move these options to Kconfig and tidy up board configuration:
CONFIG_FIT
CONFIG_OF_BOARD_SETUP
CONFIG_OF_SYSTEM_SETUP
CONFIG_FIT_SIGNATURE
CONFIG_FIT_BEST_MATCH
CONFIG_FIT_VERBOSE
CONFIG_OF_STDOUT_VIA_ALIAS
CONFIG_RSA
Unfortunately the first one is a little complicated. We need to make sure
this option is not enabled in SPL by this change. Also this option is
enabled automatically in the host builds by defining CONFIG_FIT in the
image.h file. To solve this, add a new IMAGE_USE_FIT #define which can
be used in files that are built on the host but must also build for U-Boot
and SPL.
Note: Masahiro's moveconfig.py script is amazing.
Signed-off-by: Simon Glass <sjg@chromium.org>
[trini: Add microblaze change, various configs/ re-applies]
Signed-off-by: Tom Rini <trini@konsulko.com>
Kconfig options must defined in the defconfig files. Since RSA_SOFTWARE_EXP
relies on CONFIG_DM, unless it is set in kconfig we cannot enable RSA.
Remove the hacks which enable CONFIG_DM in header files and update the
defconfig.
Signed-off-by: Simon Glass <sjg@chromium.org>
The DMC driver in v3.14 kernel[0] get the ddr setting from PMU_SYS_REG2,
and it expects uboot to store the value using a same protocol. But now
the ddr setting value is different with DMC, so if you enable the DMC,
system would crash in kernel. Correct the sdram setting here, according
to the requirements of kernel.
[0]
https://chromium.googlesource.com/chromiumos/third_party/kernel/+/
chromeos-3.14/drivers/clk/rockchip/clk-rk3288-dmc.c
Signed-off-by: Chris Zhong <zyw@rock-chips.com>
Acked-by: Simon Glass <sjg@chromium.org>
on v2016.03-rc3, size of SPL image compiled by gcc 5.3.0 is too large for
Firefly-RK3288. (it's fine for Rock2)
$ gcc --version
gcc (Ubuntu/Linaro 5.3.0-3ubuntu1~14.04) 5.3.0 20151204
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ ./tools/mkimage -n rk3288 -T rksd -d spl/u-boot-spl-dtb.bin u-boot-spl-dtb.img
Warning: SPL image is too large (size 0x80d0) and will not boot
to reduce size of SPL image, this patch makes configure_emmc() empty for
Firefly-RK3288 as same as Rock2.
Signed-off-by: FUKAUMI Naoki <naobsd@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
Tested-By: Vagrant Cascadian <vagrant@debian.org>
emac may use dpll as clock parent, and it request the clock frequency
multiples of 50, so change ddr frequency to 400M.
Signed-off-by: Lin Huang <hl@rock-chips.com>
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
Acked-by: Simon Glass <sjg@chromium.org>
The "R" constraint supplies the address of an variable in a register. Use
"r" instead and adjust asm to supply the content of addr in a register
instead.
Fixes: 2b8bcc5a ("MIPS: avoid .set ISA for cache operations")
Signed-off-by: Matthias Schiffer <mschiffer@universe-factory.net>
Cc: Paul Burton <paul.burton@imgtec.com>
Cc: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
- The macro __BIGGEST_ALIGNMENT__ is gcc-specific. If it is not defined
we'll just assume 16. This is correct for at least the common cases
and LLVM does not provide an equivalent macro.
- When linking U-Boot we're passing -T to the linker, and while gcc will
just pass this along with LLVM we need to be specific.
Cc: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Now that we fall back to the FS code path when we don't find u-boot
at the raw sector offset, there is no good reason to not default to
raw boot.
With this patch, I can successfully boot u-boot from a raw sector
offset on beagle-xm.
Signed-off-by: Alexander Graf <agraf@suse.de>
This function should just return for unknown SoCs rather than writing
unexpected values to registers.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
During very early boot-ROM execution the pinmux
configuration isi in Hi-Z state. If pull-up is enabled
on GPIO pad's there will be a short period of toggle
from high to low on the IO when GPIO is set low during
boot. To avoid this glitch, disable pull-up configuration
in GPIO pinmux.
Signed-off-by: Bhuvanchandra DV <bhuvanchandra.dv@toradex.com>
This introduces some minor cleanups, regarding aspects such as board name, code
and headers organization as well as deprecated and missing config options.
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Reviewed-by: Tom Rini <trini@konsulko.com>
The UniPhier SoC family has not supported ARMv8 yet, but these would
cause warnings if they were compiled with a 64bit compiler. Before
adding the ARMv8 support really, fix them now.
Because UniPhier SoCs do not support Large Physical Address Extension,
casting "phys_addr_t" into "unsigned long" would carry the address
as is.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Before adding ARMv8 support, this commit refactors the directory
structure. Move ARMv7 specific files to arch/arm/mach-uniphier/arm32
to avoid a mess by mixture of ARMv7 and ARMv8 code. Also move the
"select CPU_V7" to the lower-level menu because we will have to
select ARM64 instead of CPU_V7 for ARMv8 SoCs.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Due to the company's awful projecting, PH1-LD10 and PH1-sLD11 have
been renamed to PH1-LD20 and PH1-LD11, respectively.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
The chains of "depends on <SoC_name>" in the current Kconfig is
clumsy. The idea here is to allow users to choose a SoC group first
(SoC group consists of some SoCs that can coexist in one binary).
Then, allow to enable/disable each SoC support in the selected SoC
group. This makes the Kconfig menu clearer.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
These macros are no longer used. These base addresses are
SoC-dependent, so they should not be placed in the header.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Currently, DRAM size is converted twice:
size in byte -> size in Gbit -> enum
Optimize the code by converting the "size in byte" into enum directly.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Now this code can be re-written with a "for" statement instead of
calling the same function multiple times.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Now this code can be re-written with a "for" statement instead of
calling the same function multiple times.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Now this code can be re-written with a "for" statement instead of
calling the same function multiple times.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
The if-else statements for the frequency-dependent register settings
seem clumsy. Moving them to arrays would make it cleaner.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
The DDR PHY settings no longer depend on the DRAM size. Drop the
argument from the init function.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Now these three are almost the same. The only difference is the DTPR1
register dependency on the DRAM size, but it can be ignored. (It has
already been ignored in PH1-sLD8 and PH1-Pro4.)
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Add a field to distinguish DDR3+ from (standard) DDR3. It also
allows to delete CONFIG_DDR_STANDARD (this is not a software
configuration, but a board attribute).
Default DDR3 spec for each SoC:
PH1-LD4, PH1-sLD8: DDR3+
Others: DDR3
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
These settings control the clocks around the memory controller.
The debug ability is unneeded once it works properly.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
These settings were used only for the PH1-sLD3 and older SoCs. The
PH1-LD4 and newer one just ignore them because their DDR-PHY take
care of such timing parameters instead.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Currently, a dummy value is defined for the UMC_SPCCTLA register
when the DRAM size is zero. This seems weird because the controller
does not need setting in the first place if the size is zero.
Also, redefine enum dram_size to represent the DRAM size per 16-bit
unit. This makes things simpler because the channel 0 and 1 are
connected with 32-bit width DRAM, while the channel 2 is connected
with 16-bit width one.
I am renaming SIZE_* into DRAM_SZ_* (and also FREQ_* to DRAM_FREQ_*
for consistency) while I am here because SIZE_* might be easily
mixed-up with the macros in include/linux/sizes.h.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Now this code can be re-written with a "for" statement instead of
calling the same function multiple times.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
This commit reworks "struct uniphier_board_data" with an array of
DRAM channel data in it. It will allow further cleanups by means of
"for" statements that iterate over the DDR channels.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Of the several boot devices supported, it looks like the eMMC is the
most commonly used. Enable CONFIG_ENV_IS_IN_MMC by default.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
UniPhier SoC family supports both (e)MMC boot and SD card boot;
however, both of them are handled in the same uclass.
When booting from the eMMC, we want to know the device number
of the (e)MMC, not SD. This command is useful to find the first
MMC (non-SD) device.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Export device nodes needed for eMMC boot (eMMC node, pinctrl, and
clock) to the SPL DTB. CONFIG_SUPPORT_EMMC_BOOT is also necessary
to use "mmc partconf" command.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Enable the driver in all UniPhier defconfig files and add some
needed defines to the common files.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
I implemented a GPIO driver based on Driver Model for the UniPhier
SoC family, but I could not find any good reason why such SoC
specific GPIO headers are needed.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Simon Glass <sjg@chromium.org>
Simon Glass