The R8A7794_ETHERNET_B config option is unused and based on the
description, this is a setting which should be fully done on a
DT level instead. Remove this config option.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
We'd better use correct way to check if module has enabled.
for we have 3 timer MACRO:
- CONFIG_TIMER
- CONFIG_SPL_TIMER
- CONFIG_TPL_TIMER
Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
I took over maintainership from Alex Graf with commit
3157bbfa18 ("rpi: Make Matthias maintainer")
But I forgot to update the board maintainer file.
This patch adds myself to the game.
Signed-off-by: Matthias Brugger <mbrugger@suse.com>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Alexander Graf <agraf@csgraf.de>
The FIT image is loaded to 0x8700_0000 followed by extracting from that
several large images also into the 0x8x00_0000 range. Large images
can end up overwriting the FIT image as it is being extracted from.
Move the FIT load address clear out to 0x9000_0000, this will require
a board to have at least 256MB of DRAM, if less then more careful
planning will be required for that platform.
Signed-off-by: Andrew F. Davis <afd@ti.com>
After the commit b9a2a0e2e9 ("mmc: Add support for downgrading
HS200/HS400 to HS mode"), it add a parameter in mmc_set_card_speed()
which indicates that the HS200/HS400 to HS downgrade is happening.
During the HS400 initialization, first select to HS200, and config
the related clock rate, then downgrade to HS mode. So here also need
to config the downgrade value to be true for two reasons. First,
make sure in the function mmc_set_card_speed(), after switch to HS
mode, first config the clock rate, then read the EXT_CSD, avoid
receiving data of EXT_CSD in HS mode at 200MHz. Second, after issue
the MMC_CMD_SWITCH command, it need to wait a bit then switch bus
properties.
Test on i.MX8QM MEK board, some Micron eMMC will stuck in transfer
mode in this case, and USDHC will never get data transfer complete
status, cause the uboot hang.
Signed-off-by: Haibo Chen <haibo.chen@nxp.com>
Acked-by: Marek Vasut <marek.vasut@gmail.com>
This patch series contains a bug fix for a double free in a UEFI unit
test. The other patches are documentation only (except for the definition
of two additional constants).
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEbcT5xx8ppvoGt20zxIHbvCwFGsQFAlydMVEACgkQxIHbvCwF
GsQ0KA/+JU1s0Mhu9fWb+LR/sDz7hoLgbPgYQA71+ngwy0ihzIKfrOx7BBfBzzC6
yaFJznaWGZBskvlEpD7n+6g+RPomcsvla3KUEwIGjstBYkDJ1AHyjNtt3fbEEyqo
Ub90hOvvB46BKZ4uqkM+qA4GpctONgAeEUVtmYvx1FXAlzXKhltZdt67V3ZzV0ir
JdQ3UtuNibSTmvTxLRRkCUk6xCBF912NXkwPY5J6tnnRNJmmqE9urdmsmmycNByK
zTmCG3z80xBE5GoEB9mm/89XKreqCIZ3w8ANk/u6WIGLaa4tjR47k5MxXju2PyVQ
sLg2j5uyfr9CKeq0HdtD1PLXc4dzp9JX4xuJKNZ+J+kzqid8Foh4Av/D44z3/xAW
dJ7BqPo+JjJEitbjtqVcAQCFS2a+Sk94TrPmKhiNbMbGo/D1tqC1yMdwAFQebH4l
46UJCq4lOw1QwjaESpozWKNAZe41QvZn2vLvOxIEiZeIbGHwYVFYoqXaJIf5YEx9
D9YLBxx27SRAQFB9bqnmHh6a44c+E8MKmbTbQsLY9tX8tCNUEXpSpod88Yaaobny
pRtBXskdmMyvViivrcawdWmHk95OIQscV61DGJAGD26dYkPli6YKx0At3kBhu0iT
TZ0SKmWAloXopI8mqL7xlMCBsgl33oNfPOjzGsxoA5ka2m6HapU=
=UiND
-----END PGP SIGNATURE-----
Merge tag 'efi-2019-04-rc5-2' of git://git.denx.de/u-boot-efi
Pull request for UEFI system for v2019.04-rc5-2
This patch series contains a bug fix for a double free in a UEFI unit
test. The other patches are documentation only (except for the definition
of two additional constants).
There are no higher 16 writing corresponding bits for pmu_gpio0's
iomux/drive/pull at rk3288, need to read the value from register
firstly. Add the flag to distinguish it from normal registers.
Signed-off-by: David Wu <david.wu@rock-chips.com>
Due to a final resolution not coming up in time for 2019.04 and
following the consensus on the discussion, we'll keep this around
for 2019.04 after all.
This reverts commit 0d968ceb1f.
This is last minute change which fixes problems in runtime on
AXS10x board caused by some changes in NAND framework and
tiny documentation improvement.
Anyways NAND flash storage was never really used on the board for various
reasons and now we decided to drop it for good.
Note this change only touches 1 ARC board so that should be safe for others.
As usual - build tested in TravisCI, see
https://travis-ci.org/abrodkin/u-boot/builds/512041342
Currently, HDMI driver doesn't consider minimum and maximum allowed rate
of pll3 (video PLL). It works most of the time, but not always.
Consider monitor with resolution 1920x1200, which has pixel clock rate
of 154 MHz. Current code would determine that pll3 rate has to be set to
154 MHz. However, minimum supported rate is 192 MHz. In this case video
output just won't work.
The reason why the driver is written in the way it is, is that at the
time HDMI PHY and clock configuration wasn't fully understood. But now
we have needed knowledge, so the issue can be fixed.
With this fix, clock configuration routine uses full range (1-16) for
clock divider instead of limited one (1, 2, 4, 11). It also considers
minimum and maximum allowed rate for pll3.
Fixes: 56009451d8 ("sunxi: video: Add A64/H3/H5 HDMI driver")
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
On AXS10x boards we have non-standard NAND controller
which was never really used a lot as there're other much more
convenient [as they are standard & removable] persistent media
like SD-card and USB mass storage.
Moreover after recent changes we face with some NAND controller
runtime issues. So instead of keeping support of yet another
non-standard peripheral we're dropping its support for good.
Signed-off-by: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
The following TODOs are closed:
- GetNextVariableName is not implemented
- event groups
- manage events in a linked list
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
We currently only support EFI_FILE_PROTOCOL_REVISION while
UEFI specs 2.4 - 2.7 prescribe EFI_FILE_PROTOCOL_REVISION2.
Add a todo.
Add missing constants for the EFI file protocol revision.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
This converts the following to Kconfig:
CONFIG_ENV_SPI_BUS
CONFIG_ENV_SPI_CS
CONFIG_ENV_SPI_MAX_HZ
CONFIG_ENV_SPI_MODE
Most of time these value are not needed, CONFIG_SF_DEFAULT
with same value is used, so I introduced CONFIG_USE_ENV_SPI_*
to force the associated value for the environment.
Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
This converts the following to Kconfig:
CONFIG_SF_DEFAULT_BUS
CONFIG_SF_DEFAULT_CS
CONFIG_SF_DEFAULT_MODE
CONFIG_SF_DEFAULT_SPEED
I use moveconfig script and then manual check on generated u-boot.cfg
to solve the remaining issue.
Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
Define the function board_spi_cs_gpio only when needed,
only called in drivers/spi/mxc_spi.c.
That avoid compilation issue for tqma6s_wru4_mmc_defconfig
when CONFIG_SF_DEFAULT_BUS and CONFIG_SF_DEFAULT_CS are not
defined (CMD_SF not defined) after migration in KConfig.
Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
Replace CONFIG_ENV_SPI_BASE by the better CONFIG_SYS_SPI_BASE
(it is not the location for environment but the location for U-Boot)
and, as it is the only platform with use this define, remove
it from whitelist.
Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
Move some configurations in defconfig file
- CONFIG_CMD_I2C
- CONFIG_CMD_SPI
This allow correct dependency handling in Kconfig.
Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
Move some configurations in defconfig file
- CONFIG_DM_SPI (removed by syncing defconfigs )
- CONFIG_CMD_SF
- CONFIG_CMD_SPI
- CONFIG_CMD_SF_TEST
This allow correct dependency handling in Kconfig.
Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
- 3 bugfixes:
- mmc: Align MMC_TRACE with tiny printf
- scripts/Makefile.extrawarn: Silence more DTC warnings
- rsa: check that pointer checksum isn't NULL before using it
On 16bit variants of the TMIO SD IP, the SECCNT register can only be
programmed to 16bit values, while on the 32bit and 64bit variants it
can be programmed to 32bit values. The SECCNT register indicates the
maximum number of blocks in a continuous transfer. Hence, limit the
maximum continuous transfer block count to 65535 blocks on 16bit
variants of the TMIO IP and to BIT(32)-1 blocks on 32bit and 64bit
variants.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Set MMCIF clock rate to 97.5 MHz, which is the default according
to Gen2 datasheet.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
Cc: Jaehoon Chung <jh80.chung@samsung.com>
Add code for configuring the MMC0CKCR/MMC1CKCR on Gen2 platforms.
This allows the MMCIF driver to set higher clock rate if desired.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
The $div and $mul values were swapped in the debug output,
fix this.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
The gen2_clk_get_sdh_div() function is supposed to look up the
$val value read out of the SDCKCR register in the supplied table
and return the matching divider value. The current implementation
was matching the value from SDCKCR on the divider value in the
table, which is wrong. Fix this and rework the function a bit
to make it more readable.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
An ADATA 16GB Industrial MLC card has so much capacitance on the Vcc
pin that the usual toggling of regulator to power the card off and on
is insufficient. When the card is calibrated into UHS SDR104 mode, it
will remain in that mode across the power cycle and subsequent attempt
to communicate with the card will fail.
The test with this card is to insert it into an SDHI slot and perform
"mmc dev 0 ; mmc dev 0", where the second "mmc dev 0" will fail.
Fix this problem by increasing the off-on delay from 0 to 20 mS.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
The tiny printf implementation only supports %x format specifier,
it does not support %X . Since it makes little difference whether
the debug output prints hex numbers in capitals or not, change it
to %x and make the MMC_TRACE output work with tiny printf too.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Jaehoon Chung <jh80.chung@samsung.com>
Cc: Simon Glass <sjg@chromium.org>
While our "extrawarns" logic has gotten out of sync with upstream
Kbuild, for now lets start by bringing in the latest set of DTC_FLAGS
from the Linux Kernel 5.0 to match their behavior in silencing warnings
from dtc.
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
The pointer checksum were used before checking that it
isn't NULL. We move the code that use it after the check.
Reported-by: Coverity (CID: 185835)
Signed-off-by: Philippe Reynes <philippe.reynes@softathome.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
- Don't attempt to write to ext4 volumes with the metadata_csum feature
we don't support
- Correct how we build dtb files.
- Fix regression on SPL_FIT with FIT_IMAGE_TINY
- Minor TI platform fixes
U-Boot doesn't support metadata_csum feature. Writing to filesystem with
metadata_csum feature makes the filesystem corrupted and unbootable by
Linux:
[ 2.527495] EXT4-fs (mmcblk0p2): ext4_check_descriptors: Checksum for group 0 failed (52188!=0)
[ 2.537421] EXT4-fs (mmcblk0p2): ext4_check_descriptors: Checksum for group 1 failed (5262!=0)
...
[ 2.653308] EXT4-fs (mmcblk0p2): ext4_check_descriptors: Checksum for group 14 failed (42611!=0)
[ 2.662179] EXT4-fs (mmcblk0p2): ext4_check_descriptors: Checksum for group 15 failed (21527!=0)
[ 2.687920] JBD2: journal checksum error
[ 2.691982] EXT4-fs (mmcblk0p2): error loading journal
[ 2.698292] VFS: Cannot open root device "mmcblk0p2" or unknown-block(179,2): error -74
Don't write to filesystem with meatadata_csum feature to not corrupt the
filesystem.
Signed-off-by: Sébastien Szymanski <sebastien.szymanski@armadeus.com>
When these were moved from mach-omap2 to board files they got placed
inside TI_SECURE_DEVICE ifdef block, they are not secure only, move
them up and out.
Fixes: 413b90777f ("ti: fastboot: Move weak overrides to board files")
Signed-off-by: Andrew F. Davis <afd@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
This patch adds a comment to the header with the PCI_foo macros related
to DEVFN to explain the difference in U-Boot vs Linux.
Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Simon Glass <sjg@chromium.org>
Cc: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
This reverts commit 27cb7300ff.
I am not sure if I correctly understood the log of commit 27cb7300ff
("Ensure device tree DTS is compiled"), but the code-diff looks like
it was trying to solve the missed re-compilation when .dts was modified.
Recently, commit 2737dfe096 ("kbuild: make arch-dtbs target PHONY")
fixed the issue in a more correct and more complete way.
Anyway, since the former commit, we see a clumsy log like this:
make[2]: 'arch/sandbox/dts/sandbox.dtb' is up to date
Another problem is, it created multiple paths to descend into
arch/*/dts/, causing a race in parallel building.
So, let's revert it.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Since commit 27cb7300ff ("Ensure device tree DTS is compiled"),
build succeeds irrespective of the correctness of Makefile.
In fact, you can compile any defconfig without adding any entry in
arch/*/dts/Makefile.
I am going to revert that commit, so device tree must be explicitly
listed in Makefile.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
Since commit 27cb7300ff ("Ensure device tree DTS is compiled"),
build succeeds irrespective of the correctness of Makefile.
I am going to revert that commit, so wrong code must be fixed.
CONFIG_MCR3000 is not defined anywhere. CONFIG_TARGET_MCR3000 is the
correct one.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
