PLL1 on sun6i / sun8i also has a p factor which divides the clock by
2^p (to the power p). On sun6i the p factor is ignored, but on sun8i it is
used and we were setting it to 1, resulting in the CPU running at 504 MHz
instead of 1008 MHz, this commit fixes this.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Ian Campbell <ijc@hellion.org.uk>
After reboot, reset or even short power off, DRAM typically retains
the old stale data for some period of time (for this type of memory,
the bits of data are stored in slowly discharging capacitors).
The current sun6i/sun8i DRAM size detection logic, which is
inherited from the Allwinner code, relies on using a large magic
signature with the hope that it is unique enough and unlikely to
ever accidentally match this leftover garbage data in RAM. But
this approach is inherently unsafe, as can be demonstrated using
the following test program:
/***** A testcase for reproducing the problem ******/
void main(int argc, char *argv[])
{
size_t size, i;
uint32_t *buf;
/* Allocate the buffer */
if (argc < 2 || !(size = (size_t)atoi(argv[1]) * 1048576) ||
!(buf = malloc(size))) {
printf("Need buffer size in MiB as a cmdline argument\n");
exit(1);
}
/* Fill it with the Allwinner DRAM "magic" values */
for (i = 0; i < size / 4; i++)
buf[i] = 0xaa55aa55 + ((uintptr_t)&buf[i] / 4) % 64;
/* Try to reboot */
system("reboot");
/* And wait */
for (;;) {}
}
/***************************************************/
If this test program is run on the device (giving it a large
chunk of memory), then the DRAM size detection logic in u-boot
gets confused after reboot and fails to initialize DRAM properly.
A better approach is not to rely on luck and abstain from making
any assumptions about the properties of the leftover garbage
data in RAM. Instead just use a more reliable code for testing
whether two different addresses refer to the same memory location.
Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Based on the register / dram_para headers from the Allwinner u-boot / linux
sources + the init sequences from boot0.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Ian Campbell <ijc@hellion.org.uk>
The sun8i boot0 code fills the DRAM with a "random" pattern before comparing
it at different offsets to do columns, etc. detection. The sun6i boot0 code
does not do it, instead relying on the memory contents being random enough
to begin with for the memcmp to properly detect the wrap-around address, iow
it is working purely by chance. Since our sun6i dram code was modelled after
the boot0 code it contained the same issue.
This commit fixes this by filling the memory with a unique, distinct pattern.
The new mctl_mem_fill function this introduces is added as an inline helper
in dram.h, so that it can be shared with the sun8i dram code.
While at it move mctl_mem_matches to dram.h for re-use in sun8i too.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Ian Campbell <ijc@hellion.org.uk>
The await_completion helper is already copy pasted between the sun4i and sun6i
dram code, and we need it for sun8i too, so lets make it an inline helper in
dram.h, rather then adding yet another copy.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Ian Campbell <ijc@hellion.org.uk>
Our old hardcoded k and m values are based on PLL5 being configured in steps
of 48 MHz, which is correct for sun6i where the DRAM PLL runs at twice the
DRAM CLK, which is usually configured in 24 MHz step. But on the A23 (sun8i)
the PLL5 runs at half the DRAM CLK, so we require 12 MHz steps.
This commit adjusts clock_set_pll5 to automatically select the best k and m
depending on the requested clk rate.
Suggested-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Ian Campbell <ijc@hellion.org.uk>
The sun8i dram code sometimes wants to enable sigma delta mode,
add a parameter to allow this.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Ian Campbell <ijc@hellion.org.uk>
The axp223 appears to be the same as the axp221, except that it uses the
rsb to communicate rather then the p2wi. At least all the registers we use
are 100% the same.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Ian Campbell <ijc@hellion.org.uk>
sun8i (A23) introduces a new bus for communicating with the pmic, the rsb,
the rsb is also used to communicate with the pmic on the A80, and is
documented in the A80 user manual.
This commit adds support for this based on the rsb driver from the allwinner
u-boot sources.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Ian Campbell <ijc@hellion.org.uk>
The p2wi interface is only available on sun6i, adjust the gpio pinmux and
base address defines for it to reflect this.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Ian Campbell <ijc@hellion.org.uk>
0x400 is true 1K.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Ian Campbell <ijc@hellion.org.uk>
On sun6i the SID is stored in the pmic, rather then in the SoC itself,
add a helper function to abstract this away.
This makes our MAC address generation code also work on sun6i.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Ian Campbell <ijc@hellion.org.uk>
The sunxi mmc controller has both an internal clock divider, as well as
the divider in the mod0-clk for the mmc controller.
The internal divider cannot be used, as it conflicts with the setting of
clock sampling phases which is done in the mod0-clk, so it must be set to
0 (divide by 1).
For some reason while the kernel has had this correct from day one, the
u-boot sunxi mmc code has been using a fixed mod0-clk and setting its
internal divider depending on the desired speed. This is something which
we've inherited from the original Allwinner u-boot sources, but while this
has been fixed in Allwinner's own u-boot code at least for the A23 and later
upstream u-boot was still doing this wrong.
This commit fixes this, thereby also fixing mmc support not working reliable
on the A23 (which seems more sensitive to this) and possible also fixes some
other sunxi mmc issues.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Ian Campbell <ijc@hellion.org.uk>
The A31s only has one dram channel, so do not bother with trying to initialize
a second channel.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Ian Campbell <ijc@hellion.org.uk>
Add a sunxi_get_ss_bonding_id() function, and use it to differentiate between
the A31s and the A31.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Ian Campbell <ijc@hellion.org.uk>
It turns out that there is a too large spread between boards to handle this
with a default value, turn this into Kconfig options, and set the values
the factory images are using for the Colombus and Mele_M9 boards.
Note this changes the ZQ default when not overriden through defconfig from
120 to 123, as that is what most boards seem to actually use.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Ian Campbell <ijc@hellion.org.uk>
Resynchronize memcpy/memset with kernel 3.17 and build them in
Thumb2 mode (unified syntax). Those assembler files can be built
and linked in ARM mode too, however when calling them from Thumb2
built code, the stack got corrupted and the copy did not succeed
(the exact details have not been traced back). However, the Linux
kernel builds those files in Thumb2 mode. Hence U-Boot should
build them in Thumb2 mode too when CONFIG_SYS_THUMB_BUILD is set.
To build the files without warning, some assembler instructions
had to be replaced with their UAL compliant variant (thanks
Jeroen for this input).
To build the file in Thumb2 mode the implicit-it=always option need
to be set to generate Thumb2 compliant IT instructions where needed.
We add this option to the general AFLAGS when building for Thumb2.
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Stefan Agner <stefan@agner.ch>
Since commit 3ff46cc42b ("arm: relocate the exception vectors") mx25pdk
hangs like this:
CPU: Freescale i.MX25 rev1.2 at 399 MHz
Reset cause: WDOG
Board: MX25PDK
I2C: ready
DRAM: 64 MiB
(hangs)
Add a specific relocate_vectors macro that skips the vector relocation, as the
i.MX25 SoC does not provide RAM at the high vectors address (0xFFFF0000), and
(0x00000000) maps to ROM.
This allows mx25 to boot again.
Acked-By: Bill Pringlemeir <bpringlemeir@nbsps.com>
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Currently there is an unneeded empty line after printing the reset cause:
U-Boot 2015.01-rc4-00080-g0551a93 (Jan 06 2015 - 13:04:19)
CPU: Freescale i.MX25 rev1.2 at 399 MHz
Reset cause: POR
Board: MX25PDK
I2C: ready
DRAM: 64 MiB
MMC: FSL_SDHC: 0
Remove the extra "\n" when printing the reset cause.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
The low-level debugging functions are useful to debug the early boot
stage where the full UART driver is not available.
UniPhier SoCs need to initialize the UART port 0 to use this feature.
The initialization routine is called at the very entry of the
lowlevel_init().
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
For NAND boot on PH1-LD4, PH1-sLD8, and some other SoCs,
the output of the system bus is disabled by default.
It must be enabled by software to have access to the system bus.
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
The max size of available memories on slot0 and slot1 is 32MB because
- EA[25] signal is not output on the save-pin mode which is
used PH1-LD4 or later SoCs.
- EA[25] signal is not connected by the limitation (or bug?) of
the PLD logic of DCC support card.
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
This optional DT property is called 'num-cs', so repair the misnomers.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Chin Liang See <clsee@opensource.altera.com>
Cc: Dinh Nguyen <dinguyen@opensource.altera.com>
Cc: Pavel Machek <pavel@denx.de>
Cc: Stefan Roese <sr@denx.de>
Cc: Vince Bridgers <vbridger@opensource.altera.com>
Acked-by: Pavel Machek <pavel@denx.de>
Reviewed-by: Jagannadha Sutradharudu Teki <jagannadh.teki@gmail.com>
Linux now also contains SPI driver, yet the name is 'snps,dw-apb-ssi'.
Fix the naming before we have to support both names.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Chin Liang See <clsee@opensource.altera.com>
Cc: Dinh Nguyen <dinguyen@opensource.altera.com>
Cc: Pavel Machek <pavel@denx.de>
Cc: Stefan Roese <sr@denx.de>
Cc: Vince Bridgers <vbridger@opensource.altera.com>
Reviewed-by: Stefan Roese <sr@denx.de>
Acked-by: Pavel Machek <pavel@denx.de>
Reviewed-by: Jagannadha Sutradharudu Teki <jagannadh.teki@gmail.com>
The ChromeOS EC keyboard is used by various different chromebooks. Peach
pi being the third board in the u-boot tree to use it (snow and peach
pit the other two). Rather then embedding the same big DT node in the
peach-pi DT again, copy the dtsi snippit & bindings documentation from
linux and include it in all 3 boards.
This slightly changes the dt bindings in u-boot:
* google,key-rows becomes keypad,num-rows
* google,key-colums becomes keypad,num-colums
* google,repeat-delay-ms and google,repeat-rate-ms are no longer used
and replaced by hardcoded values (similar to tegra kbc)
Signed-off-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
Acked-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
pci ports are used as root complex in Linux. So set this as default
in u-boot for keystone devices
Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
On OMAP platforms (like OMAP5) Linux kernel fails to detect a SATA
device if it is used by U-Boot.
It happens because U-Boot does not reset SATA controller before boot.
Reset the controller on OS boot so that Linux will have a clean state
to work with.
Signed-off-by: Dmitry Lifshitz <lifshitz@compulab.co.il>
Reviewed-by: Tom Rini <trini@ti.com>
Part of DMM logic is reuse from commit
47a4bea6af ("ARM: omap4: Update sdram
setting for panda rev A6") Which broke SDP4430 with ES2.3 (uses old
DDR).
So, to maintain support for newer DDR used in Panda ES rev B3, we
should, in addition to the commit
675cc77a3a ("ARM:OMAP4+: panda-es: Support
Rev B3 Elpida DDR2 RAM"), DDR timings, also do DMM configuration
specific to Panda.
Signed-off-by: Nishanth Menon <nm@ti.com>
The gd will be cleared at first so we don't need to set arch.tbl to 0.
In addition, the checks later against lastinc also work fine with an
initial value of 0 here. This also brings us in line with sunxi code
for example.
Signed-off-by: Tom Rini <trini@ti.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
In both SPL and non-SPL cases we will make a call to timer_init() early
on and do not need to call it again within s_init().
Signed-off-by: Tom Rini <trini@ti.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The save_boot_params function here is the same as the default weak one
from arch/arm/cpu/armv7/start.S, drop.
Cc: Dinh Nguyen <dinguyen@opensource.altera.com>
Cc: Vince Bridgers <vbridger@opensource.altera.com>
Cc: Chin Liang See <clsee@altera.com>
Cc: Marek Vasut <marex@denx.de>
Signed-off-by: Tom Rini <trini@ti.com>
Reviewed-by: Marek Vasut <marex@denx.de>
Commit 8bc347e2ec "ARM: bootm: Allow booting in secure mode on hyp capable
systems" added the capability to select nonsec vs sec mode boot via an
environment var.
There is a subtle gotcha with this functionality, which is that the PSCI nodes
are still created in the fdt (via armv7_update_dt->fdt_psci) even when booting
in secure mode. Which means that if the kernel is PSCI aware then it will fail
to boot because it will try and do PSCI from secure world, which won't work.
This likely didn't get noticed before because the original purpose was to
support booting the legacy linux-sunxi kernels which don't understand PSCI.
To fix expose boot_nonsec (renaming with armv7_ prefix) outside of bootm.c and
use from the virt-dt code.
As well as avoiding the creation of the PSCI nodes we should also avoid
reserving the secure RAM, so do so.
Signed-off-by: Ian Campbell <ijc@hellion.org.uk>
Cc: Hans de Goede <hdegoede@redhat.com>
Cc: Albert ARIBAUD <albert.u.boot@aribaud.net>
Cc: Tom Rini <trini@ti.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
The malloc() calls are unnecessary, just allocate the stuff on stack.
While at it, reorder the code a little, so that only one variable is
used for the text, use snprintf() instead of sprintf() and use %01d
as a formatting string to avoid any possible overflows.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Igor Grinberg <grinberg@compulab.co.il>
Cc: Nikita Kiryanov <nikita@compulab.co.il>
Cc: Sean Cross <xobs@kosagi.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Stefano Babic <sbabic@denx.de>
Cc: Tim Harvey <tharvey@gateworks.com>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
This commit adds a dump command of DDR PHY parameters of UniPhier
SoC family. It might not be used very often for the regular operation
but it would be useful when something goes wrong with DDR memories.
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
This training code provides run-time adjustment of DDR PHY parameters
for stable DDR operation.
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
