Synchronize the README with the current state of U-Boot, unify
the build instructions to avoid duplication.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
The R8A7792 does not have the USB extal, so drop it.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
freescale.com domain is no longer reachable, so switch the
maintainers' emails to nxp.com domain instead.
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
The 'SDHCI_QUIRK_NO_HISPD_BIT' is used wrong here. The purpose of this
quirk is to tell the sdhci-driver that the IP-core doesn't have a "high-
speed-enable" bit in its registers.
With this commit we change this to the correct quirk:
SDHCI_QUIRK_BROKEN_HISPD_MODE
Signed-off-by: Hannes Schmelzer <hannes.schmelzer@br-automation.com>
Some IP-core implementations of the SDHCI have different troubles on the
silicon where they are placed.
On ZYNQ platform for example Xilinx doesn't accept the hold timing of an
eMMC chip which operates in High-Speed mode and must be forced to
operate in non high-speed mode. To get rid of this
"SDHCI_QUIRK_BROKEN_HISPD_MODE" is introduced.
For more details about this refer to the Xilinx answer-recor #59999https://www.xilinx.com/support/answers/59999.html
This commit:
- doesn't set HISPD bit on the host-conroller
- reflects this fact within the host-controller capabilities
Upon this the layer above (mmc-driver) can setup the card correctly.
Otherwise the MMC card will be switched into high-speed mode and causes
possible timing violation on the host-controller side.
Signed-off-by: Hannes Schmelzer <oe5hpm@oevsv.at>
Signed-off-by: Hannes Schmelzer <hannes.schmelzer@br-automation.com>
sd_read_ssr returns 0, means no error.
Fixes: 5b2e72f32721484("mmc: read ssr only if MMC write support is enabled")
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Cc: Jaehoon Chung <jh80.chung@samsung.com>
Cc: Jean-Jacques Hiblot <jjhiblot@ti.com>
Exynos5422 board has s2mps11 pmic.
If CONFIG_PMIC_S2MPS11 is enabled, it can initialize PMIC and Regulators
during booting time.
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
Tested-by: Anand Moon <linux.amoon@gmail.com>
The dts Makefile entries for the H3 are not ordered correctly.
Move the Nano Pi entries before the Orange Pi so they are.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
Reviewed-by: Jagan Teki <jagan@openedev.com>
This patch adds a device tree file for the H5 version of the Libre
Computer Board ALL-H3-CC. It is the same board first introduced in
commit afe2754412 ("sunxi: Add support for Libre Computer Board
ALL-H3-CC H3 ver."), with the H3 SoC replaced with the H5 SoC, and
has 4Gb DDR3 chips instead of 2Gb ones.
The device tree utilizes the common board design file for ALL-H3-CC,
providing just the model strings and SoC specifics.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
Reviewed-by: Jagan Teki <jagan@openedev.com>
This patch adds a device tree file for the H2+ version of the Libre
Computer Board ALL-H3-CC. It is the same board first introduced in
commit afe2754412 ("sunxi: Add support for Libre Computer Board
ALL-H3-CC H3 ver."), with the H3 SoC replaced with the H2+ SoC, and
has only two 2Gb DDR3 chips instead of four.
The device tree utilizes the common board design file for ALL-H3-CC,
providing just the model strings and SoC specifics.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
Reviewed-by: Jagan Teki <jagan@openedev.com>
The Libre Computer Project ALL-H3-CC has three models, all using the
same board design, but with different pin compatible SoCs and amount of
DRAM.
Currently only the H3 1GB DRAM variant is supported. To support the two
other variants, first split the original device tree into a common board
design part and an SoC specific part.
The SoC part only defines which SoC is used and model name, and includes
the SoC specific dtsi file and the common design dtsi file.
Also fix up the SPDX identifier line to use the correct comment style,
and place it on the first line.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
Reviewed-by: Jagan Teki <jagan@openedev.com>
The Libre Computer Board ALL-H3-CC does not have an I2C controllable
regulator. Having R_I2C and SPL_I2C enabled serves no purpose.
Disable them.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
Reviewed-by: Jagan Teki <jagan@openedev.com>
If generating a script image and no datafile has been passed in, mkimage
dies with SIGSEGV:
#0 __strchr_sse2 () at ../sysdeps/x86_64/multiarch/../strchr.S:32
#1 0x0000000000403818 in main
at tools/mkimage.c:503
Add explicit test for datafile to fix this.
Signed-off-by: Alex Kiernan <alex.kiernan@gmail.com>
The size of 'filebuf' was not increased as more and more bytes are read
from stdin, but 'filebuf' was always reallocated to the same fix size.
This works as long as only less bytes than the initial buffer size come
in, for more input this will segfault. (It actually does, I tested
that.) So for each loop cycle the buffer size has to be increased by the
number of bytes we want to read.
Signed-off-by: Alexander Dahl <ada@thorsis.com>
On success read() returns the number of bytes read or zero for EOF. On
error -1 is returned and errno is set, so the right way to test if read
had failed is to test the return value instead of errno.
Signed-off-by: Alexander Dahl <ada@thorsis.com>
Uart status register is named USART_ISR on STM32F7, STM32H7
and STM32MP1 SoCs family, but USART_SR only on STM32F4 SoCs.
Use USART_ISR_ prefix instead of USART_SR_ .
Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
Enable uart overrun feature which allows to benefits of uart
FIFO usage.
Previously overrun management was disabled, this has to effect
to bypassed the uart FIFO usage even if FIFO was enabled.
In particular configuration, for example when video console is
enabled, copy/pasting a long command line in console results in
corruption. This is due to the fact that a lot of time is consumed
in flushing the cache during frame buffer update, so uart chars are
not read fast enough.
By using uart FIFO and managing overrun, long command line can by
copy/paste in console without being corrupted.
Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
If SPL serial support is disabled nothing brings in sprintf, snprintf
or simple_strtoul:
env/built-in.o: In function `regex_callback':
env/attr.c:128: undefined reference to `sprintf'
disk/built-in.o: In function `blk_get_device_by_str':
disk/part.c:386: undefined reference to `simple_strtoul'
disk/part.c:395: undefined reference to `simple_strtoul'
disk/built-in.o: In function `blk_get_device_part_str':
disk/part.c:522: undefined reference to `simple_strtoul'
disk/built-in.o: In function `part_set_generic_name':
disk/part.c:704: undefined reference to `sprintf'
drivers/built-in.o: In function `init_peripheral_ep':
drivers/usb/musb-new/musb_gadget.c:1826: undefined reference to `sprintf'
drivers/built-in.o: In function `musb_core_init':
drivers/usb/musb-new/musb_core.c:1451: undefined reference to `snprintf'
Add those dependencies here.
Signed-off-by: Alex Kiernan <alex.kiernan@gmail.com>
When SPL serial is disabled, callers who need sprintf or strtoul fail
because their inclusion is guarded by CONFIG_SPL_SERIAL_SUPPORT/
CONFIG_TPL_SERIAL_SUPPORT.
Split printf, sprintf and strto into their own entries and then select
all of them if SERIAL_SUPPORT is enabled to match the current behaviour.
Include panic.o unconditionally as it can be called from anywhere which
uses BUG_ON().
Signed-off-by: Alex Kiernan <alex.kiernan@gmail.com>
If CONFIG_SPL_SERIAL_SUPPORT is not set, then the build will fail:
board/ti/am335x/built-in.o: In function `spl_start_uboot':
board/ti/am335x/board.c:247: undefined reference to `serial_tstc'
board/ti/am335x/board.c:247: undefined reference to `serial_getc'
Avoid the calls to the serial functions in that case.
Signed-off-by: Alex Kiernan <alex.kiernan@gmail.com>
CONFIG_SPL_SERIAL_SUPPORT had already been migrated to Kconfig, but
existed in some include files; fix those up here.
Signed-off-by: Alex Kiernan <alex.kiernan@gmail.com>
If CONFIG_SPL_SERIAL_SUPPORT is disabled then the build fails because
serial_init is undefined. Guard preloader_console_init() appropriately
to fix this.
Signed-off-by: Alex Kiernan <alex.kiernan@gmail.com>
SYS_ARCH_TIMER guards the usage of the ARM Generic Timer (aka arch
timer) in U-Boot.
At the moment it is mandatory for ARMv8 and used by a few ARMv7 boards.
Add a proper Kconfig symbol to express this dependency properly,
allowing certain board configuration to later disable arch timer in case
there are any problems with it.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
[tuomas: rebase + fix conflicts and resync with moveconfig & use select]
Signed-off-by: Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi>
After commit 46fc679ede ("arm: timer: get frequency for arch timer
armv7 in cp15 cntfrq") the ARM architected timer driver knows how to
determine the timer frequency at runtime by reading the CNTFRQ register,
so we don't need to hardcode the timer frequency anymore.
Signed-off-by: Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi>
'env exists' is used for scripting in include/config_distro_bootcmd.h
This command is available only when CONFIG_CMD_ENV_EXISTS is enabled.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Alexander Graf <agraf@suse.de>
The default of DISTRO_DEFAULTS is messy. Using the 'imply' keyword
is equivalent and cleaner.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
RSA_SOFTWARE_EXP and RSA_FREESCALE_EXP are wrapped inside:
if RSA
...
endif
So, remove the redundant "depends on RSA" from their depends expression.
In addition, move SPL_RSA into the same "if RSA ... endif" block, since
its only direct dependeny is CONFIG_RSA. This tidies up and simplifies
reading of lib/rsa/Kconfig.
No functional change intended.
Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
CONFIG_CMD_LOG without CONFIG_LOG leads to a build error:
‘gd_t {aka volatile struct global_data}’ has no member named
‘default_log_level’
So CMD_LOG should select LOG.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Compling with CONFIG_LOG and without CONFIG_DM results in
common/log.c:47: undefined reference to `uclass_get_name'
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
The __FILE__ macro is used everywhere in U-Boot to locate the file
printing the log message, such as WARN_ON(), etc. If U-Boot is
built out of tree, this can be a long absolute path.
This is because Kbuild runs in the objtree instead of the srctree,
then __FILE__ is expanded to a file path prefixed with $(srctree)/.
A brand-new option from GCC, -fmacro-prefix-map, solves this problem.
If your compiler supports it, __FILE__ is the relative path from the
srctree regardless of O= option. This provides more readable log,
more reproducible builds, and smaller image size.
[ Linux commit: a73619a845d5625079cc1b3b820f44c899618388 ]
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
These symbols are declared in Kconfig, so it's wrong to set them in
header files.
Note that this is not size-neutral - some 'default y' options will now
get turned on by Kconfig, such as CONFIG_CMD_DM=y and CONFIG_DM_STDIO=y.
Signed-off-by: Tuomas Tynkkynen <tuomas@tuxera.com>
As of clang-5.0, things have changed a bit. First, we cannot
automatically guess -target values as if we do not pass one with CC then
cc-option will fail. Second, to disable movt/movw relocations the
argument has become -mno-movt.
Related to the target part, we cannot use arm-none-eabi as that ends up
being too generic of an ARM target for things like say rpi_3_32b to
work.
Signed-off-by: Tom Rini <trini@konsulko.com>
Re-sync the logic about which clang warnings to disable from v4.17-rc1.
Note that we don't disable all of the same ones as for now we haven't
run into any cases of warnings from clang in code from upstream Linux.
Signed-off-by: Tom Rini <trini@konsulko.com>
We have a large number of places where while we historically referenced
gd in the code we no longer do, as well as cases where the code added
that line "just in case" during development and never dropped it.
Signed-off-by: Tom Rini <trini@konsulko.com>
