In part_amiga.c the name is unsigned but bcpl_strcpy() requires a signed
pointer. Add a cast to fix the warning.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Stephen Warren <swarren@nvidia.com>
Rename this function to blk_get_device_part_str(). This is a better name
because it makes it clear that the function returns a block device and
parses a string.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Stephen Warren <swarren@nvidia.com>
The current name is too generic. The function returns a block device based
on a provided string. Rename it to aid searching and make its purpose
clearer. Also add a few comments.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Stephen Warren <swarren@nvidia.com>
The current name is too generic. Add a 'blk_' prefix to aid searching and
make its purpose clearer.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Stephen Warren <swarren@nvidia.com>
The block interface is not well documented in the code. Pick two important
functions and add comments.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Stephen Warren <swarren@nvidia.com>
Since these are sequentially numbered it makes sense to use an enum. It
avoids having to maintain the maximum value, and provides a type we can use
if it is useful.
In fact the maximum value is not used. Rename it to COUNT, since MAX suggests
it is the maximum valid value, but it is not.
Signed-off-by: Simon Glass <sjg@chromium.org>
Tested-by: Stephen Warren <swarren@nvidia.com>
At present block devices are tied up with partitions. But not all block
devices have partitions within them. They are in fact separate concepts.
Create a separate blk.h header file for block devices.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Stephen Warren <swarren@nvidia.com>
We should not include <common.h> in header files. Each C file should include
it if needed.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Stephen Warren <swarren@nvidia.com>
Each region is displayed in almost the same way. Break out this common code
into its own function.
Signed-off-by: Simon Glass <sjg@chromium.org>
Tested-by: Stephen Warren <swarren@nvidia.com>
Use 'struct' instead of a typdef. Also since 'struct block_dev_desc' is long
and causes 80-column violations, rename it to struct blk_desc.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Stephen Warren <swarren@nvidia.com>
The serial output from the debug UART carries on going far to the
right in the console.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Stefan Roese <sr@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Simple MFD devices can bind children without special bus configuration.
Like Linux, let's handle "simple-mfd" in the same way as "simple-bus".
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Simon Glass <sjg@chromium.org>
A common pattern is to call uclass_first_device() and then check if it
actually returns a device. Add a new function which does this, returning
an error if there are no devices in that uclass.
Signed-off-by: Simon Glass <sjg@chromium.org>
I didn't have a common board to enable LVDS.
So add this dcocument to help others who want to enable LVDS in their board.
Signed-off-by: Jacob Chen <jacob-chen@iotwrt.com>
Acked-by: Simon Glass <sjg@chromium.org>
LVDS have a different display out mode, add code to get right flag.
The vop_ip decide display device and the remote_vop_id decide which
vop was being used. So we should use the remote_vop_id to set DCLK_VOP.
Signed-off-by: Jacob Chen <jacob-chen@iotwrt.com>
Acked-by: Simon Glass <sjg@chromium.org>
Some Rockchip SoCs support LVDS output. Add a display driver for this so
that these displays can be used on supported boards.
Signed-off-by: Jacob Chen <jacob-chen@iotwrt.com>
Acked-by: Simon Glass <sjg@chromium.org>
The current display class only allow to get timing from edid.
So add a operation to get timing directly from driver.
In driver, I will use fdtdec_decode_display_timing to get timing.
Signed-off-by: Jacob Chen <jacob-chen@iotwrt.com>
Acked-by: Simon Glass <sjg@chromium.org>
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>
Various boards have the wrong Kconfig ordering now. To avoid a misleading
diff in the next patch, reorder the configuration correctly.
Signed-off-by: Simon Glass <sjg@chromium.org>
The existing function to add a new property to a tree being built requires
that the entire contents of the new property be passed in. For some
applications it is more convenient to be able to add the property contents
later, perhaps by reading from a file. This avoids double-buffering of the
contents.
Add a new function to support this and adust the existing fdt_property() to
use it.
Signed-off-by: Simon Glass <sjg@chromium.org>
Sometimes incorrect arguments are supplied but the reason is not obvious to
the user. Add some helpful messages.
Signed-off-by: Simon Glass <sjg@chromium.org>
Adjust the code so that option alphabetical order matches the order in the
switch() statement. This makes it easier to find options.
Signed-off-by: Simon Glass <sjg@chromium.org>
The current way of parsing arguments is a bit clumsy. It seems better to
use getopt() which is commonly used for this purpose.
Convert the code to use getopt() and make a few minor adjustments as needed.
Signed-off-by: Simon Glass <sjg@chromium.org>
This is an enhancement that permits storing the environment file on an
EXT4 partition such as the root filesystem. It is based on the existing
FAT environment file code.
After this conversion the driver will able to support both dm and non-dm
and code is more extensible like we can remove the non-dm part simply
without touching anycode if all the boards which are using this driver
become dm driven.
Cc: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Acked-by: Christophe Ricard <christophe-h.ricard@st.com>
Tested-by: Christophe Ricard <christophe-h.ricard@st.com>
Signed-off-by: Jagan Teki <jteki@openedev.com>
[Set priv->wordlen, Add Kconfig entry and file credit for dm conversion]
Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com>
Attach static on local defined functions.
Cc: Tom Rini <trini@konsulko.com>
Cc: Simon Glass <sjg@chromium.org>
Signed-off-by: Jagan Teki <jteki@openedev.com>
Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com>
Header file have macro's and register definition and some unneeded
function proto types which becomes tunned further in future patches
and entire driver code resides in one file for more readability.
Cc: Tom Rini <trini@konsulko.com>
Cc: Simon Glass <sjg@chromium.org>
Signed-off-by: Jagan Teki <jteki@openedev.com>
[Fixes on code styles, Remove omap3_spi_txrx|write|read in header]
Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com>
GPIO4_21 is the LAN8720 power pin, not the LAN8720 reset pin.
Fix that, so that we can have Ethernet functional again.
Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
The stm_is_locked_sr() function is picked from Linux kernel. For reason
unknown, the 64bit data types used by the function and present in Linux
were replaced with 32bit unsigned ones, which causes trouble.
The testcase performed was done using ST M25P80 chip.
The command used was:
=> sf protect unlock 0 0x10000
The call chain starts in stm_unlock(), which calls stm_is_locked_sr()
with negative ofs argument. This works fine in Linux, where the "ofs"
is loff_t, which is signed long long, while this fails in U-Boot, where
"ofs" is u32 (unsigned int). Because of this signedness problem, the
expression past the return statement to be incorrectly evaluated to 1,
which in turn propagates back to stm_unlock() and results in -EINVAL.
The correction is very simple, just use the correctly sized data types
with correct signedness in the function to make it work as intended.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Simon Glass <sjg@chromium.org>
Reviewed-by: Jagan Teki <jteki@openedev.com>
TI QSPI driver directly typecasts fdt_addr_t to a pointer. This is
not strictly correct, as it gives a build warning when fdt_addr_t is u64.
So, use map_physmem for a proper typecasts.
This is inspired by commit 167efe01bc ("dm: ns16550: Use an address
instead of a pointer for the uart base")
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Jagan Teki <jteki@openedev.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Mugunthan V N <mugunthanvnm@ti.com>
Enable CONFIG_USB_ETHER_RTL8152 support for Odroid XU4 which
has support for RTL8153-CG gigabit Ethernet adapter,
connected over USB 3.0.
commit 9dc8ba19c5 added support
for Realtek 8152/8153 driver.
Signed-off-by: Anand Moon <linux.amoon@gmail.com>
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
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>
MIPS EL boards should define CONFIG_USE_PRIVATE_LIBGCC=y to work
with EB-only toolchains like the one from kernel.org. If one do
not globally set CONFIG_USE_PRIVATE_LIBGCC=y, the build fails with:
/opt/gcc-4.9.0-nolibc/mips-linux/bin/mips-linux-ld.bfd: /opt/gcc-4.9.0-nolibc/mips-linux/bin/../lib/gcc/mips-linux/4.9.0/libgcc.a(_lshrdi3.o): compiled for a big endian system and target is little endian
/opt/gcc-4.9.0-nolibc/mips-linux/bin/mips-linux-ld.bfd: /opt/gcc-4.9.0-nolibc/mips-linux/bin/../lib/gcc/mips-linux/4.9.0/libgcc.a(_lshrdi3.o): endianness incompatible with that of the selected emulation
/opt/gcc-4.9.0-nolibc/mips-linux/bin/mips-linux-ld.bfd: failed to merge target specific data of file /opt/gcc-4.9.0-nolibc/mips-linux/bin/../lib/gcc/mips-linux/4.9.0/libgcc.a(_lshrdi3.o)
/opt/gcc-4.9.0-nolibc/mips-linux/bin/mips-linux-ld.bfd: /opt/gcc-4.9.0-nolibc/mips-linux/bin/../lib/gcc/mips-linux/4.9.0/libgcc.a(_ashldi3.o): compiled for a big endian system and target is little endian
/opt/gcc-4.9.0-nolibc/mips-linux/bin/mips-linux-ld.bfd: /opt/gcc-4.9.0-nolibc/mips-linux/bin/../lib/gcc/mips-linux/4.9.0/libgcc.a(_ashldi3.o): endianness incompatible with that of the selected emulation
/opt/gcc-4.9.0-nolibc/mips-linux/bin/mips-linux-ld.bfd: failed to merge target specific data of file /opt/gcc-4.9.0-nolibc/mips-linux/bin/../lib/gcc/mips-linux/4.9.0/libgcc.a(_ashldi3.o)
/work/git-trees/u-boot-mips/Makefile:1171: recipe for target 'u-boot' failed
One example for a failing build is Travis CI.
Signed-off-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
Reviewed-by: Purna Chandra Mandal <purna.mandal@microchip.com>
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>
Following the previous patch, malloc() is never called before gd is set,
so we can remove the special-case check for this condition.
This reverts commit 854d2b9753 "dlmalloc: ensure gd is set for early
alloc".
Cc: Rabin Vincent <rabin@rab.in>
Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
When running sandbox, the following phases occur, each with different
malloc implementations or behaviors:
1) Dynamic linker execution, using the dynamic linker's own malloc()
implementation. This is fully functional.
2) After U-Boot's malloc symbol has been hooked into the GOT, but before
any U-Boot code has run. This phase is entirely non-functional, since
U-Boot's gd symbol is NULL and U-Boot's initf_malloc() and
mem_malloc_init() have not been called.
At least on Ubuntu Xenial, the dynamic linker does make both malloc() and
free() calls during this phase. Currently these free() calls crash since
they dereference gd, which is NULL.
U-Boot itself makes no use of malloc() during this phase.
3) U-Boot execution after gd is set and initf_malloc() has been called.
This is fully functional, albeit via a very simple malloc()
implementation.
4) U-Boot execution after mem_malloc_init() has been called. This is fully
functional with a complete malloc() implementation.
Furthermore, if code that called malloc() during phase 1 calls free() in
phase 3 or later, it is likely that heap corruption will occur, since
U-Boot's malloc implementation will assume the pointer is part of its own
heap, although it isn't. I have not actively observed this happening.
To prevent phase 2 from happening, this patch makes all of U-Boot's malloc
library public symbols have hidden visibility. This prevents them from
being hooked into the GOT, so only code in the U-Boot binary itself
actually calls them; any other code will call into the standard C library
malloc(). This also avoids the "furthermore" issue mentioned above.
I have seen references to this GCC pragma in blog posts from 2008, and
RHEL5's ancient gcc appears to accept it fine, so I believe it's quite
safe to use it without checking gcc version.
Cc: Rabin Vincent <rabin@rab.in>
Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
- 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>
Simon Glass
Masahiro Yamada
Jacob Chen
Stuart Longland
Jagan Teki
Tom Rini
Fabio Estevam
Marek Vasut
Lokesh Vutla
Anand Moon
Chris Zhong
FUKAUMI Naoki
Lin Huang
Daniel Schwierzeck
Matthias Schiffer
Stephen Warren