ARM: imx6: Adjust DDR DRAM settings on DHCOM i.MX6 PDK
The board uses T-topology for the four x16 DRAM chips, so remove
the write-leveling from the SPL as that is only usefly on fly-by
topology and can be harmful on T-topology. Also update the DRAM
timing with values from calibration on multiple boards.
Signed-off-by: Marek Vasut <marex@denx.de> Cc: Stefano Babic <sbabic@denx.de>
Gbp-Pq: Topic upstream
Gbp-Pq: Name 0001-ARM-imx6-Adjust-DDR-DRAM-settings-on-DHCOM-i.MX6-PDK.patch
Peter Lebbing [Thu, 28 Sep 2017 12:40:24 +0000 (14:40 +0200)]
Bug#877074: u-boot-exynos: Default environment for Odroid XU3 has wrong console var
Package: u-boot-exynos
Version: 2017.09+dfsg1-1
Severity: normal
Tags: patch
The odroid-xu3 platform passes a wrong "console" argument on the kernel commandline:
console=console=ttySAC2,115200n8
>From the source, it's clear where this comes from:
include/configs/odroid_xu3.h:
#define CONFIG_DEFAULT_CONSOLE "console=ttySAC2,115200n8\0"
#define CONFIG_EXTRA_ENV_SETTINGS \
[...]
"console=" CONFIG_DEFAULT_CONSOLE \
The patch below makes the situation equal to what Debian patches in odroid.h: drop it from CONFIG_DEFAULT_CONSOLE. Judging from a grep in include/configs, I think the same situation exists for s5pc210_universal.h, s5p_goni.h, trats2.h and trats.h, but I don't have these devices. There are many more header files that have a "console=" in their CONFIG_DEFAULT_CONSOLE, but I don't see that definition being subsequently used somewhere, so I don't know whether it's being used wrongly or not.
Ensure that CONFIG_SANDBOX is set when running "make env", avoiding a
failure to build caused by config_distro_bootcmd.h following the wrong
codepath...
Gbp-Pq: Name ensure-config-sandbox-for-make-env.patch
[MIPS] Fix little-endian build with non-ELDK toolchains
We've been in trouble for a long time when cross compiling with non-ELDK
toolchains. This is caused by -EB passed to CPPFLAGS incorrectly, by the
lack of an endian specifier to LDFLAGS, and by wrong OUTPUT_FORMATs.
We're going to implement two workarounds. One is the endianness specifier
bugfix not to pass -EB / -EL to CPPFLAGS unless ELDK toolchain is used.
Note that ELDK and non-ELDK toolchains know their default endianness, so
the endianness specifier may not be necessary in principle.
The other is removal of OUTPUT_FORMAT in *.lds files. If we have this,
it doesn't work unless an endianness specifier is added to LDFLAGS. As
we haven't added that to LDFLAGS so far, it must have not worked properly,
except ELDK; I don't know why and how ELDK works, though.
With these two changes, all objects will be generated and linked in the
toolchain's default endianness. Then MAKEALL mips_el will work even with
non-ELDK toolchain.
Note that Linux/MIPS kernel has CONFIG_CPU_BIG_ENDIAN and
CONFIG_CPU_LITTLE_ENDIAN alternatives to allow users to compile kernels
with a toolchain for the other endianness. But U-Boot does not have such
feature for now, and it's another story.
Signed-off-by: Shinya Kuribayashi <skuribay@ruby.dti.ne.jp>
Gbp-Pq: Name mipsel-native-endianness.diff
[ Vagrant Cascadian ]
* u-boot-tools: Fix broken FIT image generation by building tools-only
target with an empty defconfig.
* Run basic tests for mkimage/dumpimage.
Philipp Tomsich [Tue, 12 Sep 2017 15:30:56 +0000 (17:30 +0200)]
rockchip: clk: rk3399: add clk_enable function and support USB HOST0/1
The generic ehci-driver (ehci-generic.c) will try to enable the clocks
listed in the DTSI. If this fails (e.g. due to clk_enable not being
implemented in a driver and -ENOSYS being returned by the clk-uclass),
the driver will bail our and print an error message.
This implements a minimal clk_enable for the RK3399 and supports the
clocks mandatory for the EHCI controllers; as these are enabled by
default we simply return success.
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Gbp-Pq: Topic upstream/rk3399
Gbp-Pq: Name 0004-rockchip-clk-rk3399-add-clk_enable-function-and-supp.patch
Philipp Tomsich [Tue, 29 Aug 2017 16:24:05 +0000 (18:24 +0200)]
rockchip: rk3399: spl: remove hard-coded addresses for GRF and SGRF
On the RK3399, we will have either OF_PLATDATA or full OF_CONTROL
enabled: this allows the use of syscon to retrieve the addresses of
GRF and SGRF (except for the early debug UART setup, which runs so
early that the device-model is not initialised).
This removes the hard-coded addresses and goes through syscon to
retrieve the base-addresses of GRF and SGRF. After that, we use
the structure definitions to locate the respective registers.
In addition to this, the inclusion of header files is also cleaned up:
- all headers are included at the beginning (there was a spurious
inclusion of the grf header from within a function)
- all #include statements for unused headers are removed
- the remaining #include statements are sorted (while keeping common.h
included in front)
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Gbp-Pq: Topic upstream/rk3399
Gbp-Pq: Name 0003-rockchip-rk3399-spl-remove-hard-coded-addresses-for-.patch
Peter Lebbing [Thu, 28 Sep 2017 12:40:24 +0000 (14:40 +0200)]
Bug#877074: u-boot-exynos: Default environment for Odroid XU3 has wrong console var
Package: u-boot-exynos
Version: 2017.09+dfsg1-1
Severity: normal
Tags: patch
The odroid-xu3 platform passes a wrong "console" argument on the kernel commandline:
console=console=ttySAC2,115200n8
>From the source, it's clear where this comes from:
include/configs/odroid_xu3.h:
#define CONFIG_DEFAULT_CONSOLE "console=ttySAC2,115200n8\0"
#define CONFIG_EXTRA_ENV_SETTINGS \
[...]
"console=" CONFIG_DEFAULT_CONSOLE \
The patch below makes the situation equal to what Debian patches in odroid.h: drop it from CONFIG_DEFAULT_CONSOLE. Judging from a grep in include/configs, I think the same situation exists for s5pc210_universal.h, s5p_goni.h, trats2.h and trats.h, but I don't have these devices. There are many more header files that have a "console=" in their CONFIG_DEFAULT_CONSOLE, but I don't see that definition being subsequently used somewhere, so I don't know whether it's being used wrongly or not.
Ensure that CONFIG_SANDBOX is set when running "make env", avoiding a
failure to build caused by config_distro_bootcmd.h following the wrong
codepath...
Gbp-Pq: Name ensure-config-sandbox-for-make-env.patch
[MIPS] Fix little-endian build with non-ELDK toolchains
We've been in trouble for a long time when cross compiling with non-ELDK
toolchains. This is caused by -EB passed to CPPFLAGS incorrectly, by the
lack of an endian specifier to LDFLAGS, and by wrong OUTPUT_FORMATs.
We're going to implement two workarounds. One is the endianness specifier
bugfix not to pass -EB / -EL to CPPFLAGS unless ELDK toolchain is used.
Note that ELDK and non-ELDK toolchains know their default endianness, so
the endianness specifier may not be necessary in principle.
The other is removal of OUTPUT_FORMAT in *.lds files. If we have this,
it doesn't work unless an endianness specifier is added to LDFLAGS. As
we haven't added that to LDFLAGS so far, it must have not worked properly,
except ELDK; I don't know why and how ELDK works, though.
With these two changes, all objects will be generated and linked in the
toolchain's default endianness. Then MAKEALL mips_el will work even with
non-ELDK toolchain.
Note that Linux/MIPS kernel has CONFIG_CPU_BIG_ENDIAN and
CONFIG_CPU_LITTLE_ENDIAN alternatives to allow users to compile kernels
with a toolchain for the other endianness. But U-Boot does not have such
feature for now, and it's another story.
Signed-off-by: Shinya Kuribayashi <skuribay@ruby.dti.ne.jp>
Gbp-Pq: Name mipsel-native-endianness.diff
* Set the fdtfile variable from the value of CONFIG_DEFAULT_DEVICE_TREE
(Closes: #870897). Thanks to Diego Roversi for the bug report!
* Add patch to fix building jffs2 with gcc-7 (Closes: #877963). Thanks
to Adrian Bunk!
* Update Standards-Version of Debian Policy 4.1.1, no changes needed.
Peter Robinson [Sat, 1 Jul 2017 17:44:03 +0000 (18:44 +0100)]
mx6cuboxi: Add support for sata
The Cubox-i and Hummingboard series of devices have an option of
SATA on board, and depending on how the fuses are blown even the
option to boot SPL from SATA. So enable support for it so it can
be used to boot the OS from if people desire.
Cc: Fabio Estevam <fabio.estevam@nxp.com> Signed-off-by: Peter Robinson <pbrobinson@gmail.com> Acked-by: Fabio Estevam <fabio.estevam@nxp.com>
Gbp-Pq: Topic upstream/mx6cuboxi-sata
Gbp-Pq: Name 0001-mx6cuboxi-Add-support-for-sata.patch
Ensure that CONFIG_SANDBOX is set when running "make env", avoiding a
failure to build caused by config_distro_bootcmd.h following the wrong
codepath...
Gbp-Pq: Name ensure-config-sandbox-for-make-env.patch
[MIPS] Fix little-endian build with non-ELDK toolchains
We've been in trouble for a long time when cross compiling with non-ELDK
toolchains. This is caused by -EB passed to CPPFLAGS incorrectly, by the
lack of an endian specifier to LDFLAGS, and by wrong OUTPUT_FORMATs.
We're going to implement two workarounds. One is the endianness specifier
bugfix not to pass -EB / -EL to CPPFLAGS unless ELDK toolchain is used.
Note that ELDK and non-ELDK toolchains know their default endianness, so
the endianness specifier may not be necessary in principle.
The other is removal of OUTPUT_FORMAT in *.lds files. If we have this,
it doesn't work unless an endianness specifier is added to LDFLAGS. As
we haven't added that to LDFLAGS so far, it must have not worked properly,
except ELDK; I don't know why and how ELDK works, though.
With these two changes, all objects will be generated and linked in the
toolchain's default endianness. Then MAKEALL mips_el will work even with
non-ELDK toolchain.
Note that Linux/MIPS kernel has CONFIG_CPU_BIG_ENDIAN and
CONFIG_CPU_LITTLE_ENDIAN alternatives to allow users to compile kernels
with a toolchain for the other endianness. But U-Boot does not have such
feature for now, and it's another story.
Signed-off-by: Shinya Kuribayashi <skuribay@ruby.dti.ne.jp>
Gbp-Pq: Name mipsel-native-endianness.diff
Ensure that CONFIG_SANDBOX is set when running "make env", avoiding a
failure to build caused by config_distro_bootcmd.h following the wrong
codepath...
Gbp-Pq: Name ensure-config-sandbox-for-make-env.patch
[MIPS] Fix little-endian build with non-ELDK toolchains
We've been in trouble for a long time when cross compiling with non-ELDK
toolchains. This is caused by -EB passed to CPPFLAGS incorrectly, by the
lack of an endian specifier to LDFLAGS, and by wrong OUTPUT_FORMATs.
We're going to implement two workarounds. One is the endianness specifier
bugfix not to pass -EB / -EL to CPPFLAGS unless ELDK toolchain is used.
Note that ELDK and non-ELDK toolchains know their default endianness, so
the endianness specifier may not be necessary in principle.
The other is removal of OUTPUT_FORMAT in *.lds files. If we have this,
it doesn't work unless an endianness specifier is added to LDFLAGS. As
we haven't added that to LDFLAGS so far, it must have not worked properly,
except ELDK; I don't know why and how ELDK works, though.
With these two changes, all objects will be generated and linked in the
toolchain's default endianness. Then MAKEALL mips_el will work even with
non-ELDK toolchain.
Note that Linux/MIPS kernel has CONFIG_CPU_BIG_ENDIAN and
CONFIG_CPU_LITTLE_ENDIAN alternatives to allow users to compile kernels
with a toolchain for the other endianness. But U-Boot does not have such
feature for now, and it's another story.
Signed-off-by: Shinya Kuribayashi <skuribay@ruby.dti.ne.jp>
Gbp-Pq: Name mipsel-native-endianness.diff
projects / u-boot.git / log