In DRA7xx Soc's voltage scaling is done using GPI2C.
So i2c_init should happen before scaling. I2C driver
uses __udelay which needs timer to be initialized.
So moving timer_init just before voltage scaling.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
TPS659038 is the power IC used in DRA7XX boards.
Adding support for this and also adding pmic data
for DRA7XX boards.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
The registers that are used for device identification
are changed from OMAP5 to DRA7xx.
Using the correct registers for DRA7xx.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Voltage scaling can be done in two ways:
-> Using SR I2C
-> Using GP I2C
In order to support both, have a function pointer in pmic_data
so that we can call as per our requirement.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
SGX clocks should be enabled only for OMAP5 ES1.0.
So this can be removed.
Signed-off-by: Sricharan R <r.sricharan@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
After having the u-boot clean up series, there are
many definitions that are unused in header files.
Removing all those unused ones.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
The newly introduced function setup_warmreset_time(), called
from within prcm_init(), tries to write to the prm_rsttime
OMAP5 register. The struct member holding this register's
address is however initialized for OMAP5 ES2.0 only. On ES1.0
devices this uninitialized value causes a second (warm) reset
at startup.
Add .prm_rsttime address init to the ES1.0 struct.
Signed-off-by: Lubomir Popov <lpopov@mm-sol.com>
Acked-by: Tom Rini <trini@ti.com>
Patch adds a call of abb_setup() function, and proper registers
definitions needed for ABB setup sequence. ABB is initialized
for MPU voltage domain.
Signed-off-by: Andrii Tseglytskyi <andrii.tseglytskyi@ti.com>
Adaptive Body Biasing (ABB) modulates transistor bias voltages
dynamically in order to optimize switching speed versus leakage.
Adaptive Body-Bias ldos are present for some voltage domains
starting with OMAP3630. There are three modes of operation:
* Bypass - the default, it just follows the vdd voltage
* Foward Body-Bias - applies voltage bias to increase transistor
performance at the cost of power. Used to operate safely at high
OPPs.
* Reverse Body-Bias - applies voltage bias to decrease leakage and
save power. Used to save power at lower OPPs.
Signed-off-by: Andrii Tseglytskyi <andrii.tseglytskyi@ti.com>
Acked-by: Nishanth Menon <nm@ti.com>
This fixes several warnings like
In file included from ./u-boot/include/linux/mtd/mtd.h:13:0,
from env_onenand.c:37:
./u-boot/build/vct_platinumavc_onenand_small/include2/asm/errno.h:52:0: warning: "ENOMSG" redefined [enabled by default]
Signed-off-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
The purpose of the __raw* IO accessors is to provide
IO access in native-endian order. However in the current
MIPS implementation, the 16 and 32 bit variants of the
__raw accessors are swapping the values on big-endian
systems if the CONFIG_SWAP_IO_SPACE option is enabled.
The patch changes the IO accessor macros to fix this
broken behaviour.
Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Cc: Daniel Schwierzeck <daniel.schwierzeck@googlemail.com>
The pci_indirect.c file is always compiled when
CONFIG_PCI is defined although the indirect PCI
bridge support is not needed by every board.
Introduce a new CONFIG_PCI_INDIRECT_BRIDGE
config option and only compile indirect PCI
bridge support if this options is enabled.
Also add the new option into the configuration
files of the boards which needs that.
Compile tested for powerpc, x86, arm and nds32.
MAKEALL results:
powerpc:
--------------------- SUMMARY ----------------------------
Boards compiled: 641
Boards with warnings but no errors: 2 ( ELPPC MPC8323ERDB )
----------------------------------------------------------
Note: the warnings for ELPPC and MPC8323ERDB are present even
without the actual patch.
x86:
--------------------- SUMMARY ----------------------------
Boards compiled: 1
----------------------------------------------------------
arm:
--------------------- SUMMARY ----------------------------
Boards compiled: 311
----------------------------------------------------------
nds32:
--------------------- SUMMARY ----------------------------
Boards compiled: 3
----------------------------------------------------------
Cc: Tom Rini <trini@ti.com>
Cc: Daniel Schwierzeck <daniel.schwierzeck@googlemail.com>
Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Some ARM compilers may emit code that makes unaligned accesses when
faced with constructs such as:
char mac[16] = "ethaddr";
Replace this with a strcpy() call instead to avoid this. strcpy() is
used here, rather than replacing all usage of the mac variable with the
string itself, since the loop itself sprintf()s to the variable each
iteration, so strcpy() is doing basically the same thing.
Reported-by: Florian Meier
Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
This commit refactors common/board_f.c and common/board_r.c
in order to delete the dest_addr and dest_addr_sp from
gd_t struct.
As mentioned as follows in include/asm-generic/global_data.h,
/* TODO: is this the same as relocaddr, or something else? */
unsigned long dest_addr; /* Post-relocation address of U-Boot */
dest_addr is the same as relocaddr.
Likewise, dest_addr_sp is the same as start_addr_sp.
It seemed dest_addr/dest_addr_sp was used only as a scratch variable
to calculate relocaddr/start_addr_sp, respectively.
With a little refactoring, we can delete dest_addr and dest_addr_sp.
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Cc: Simon Glass <sjg@chromium.org>
Jump into full u-boot mode if a 'c' character is received on the uart.
We need to adjust the spl bss/malloc area to not overlap with the
loadaddr of the kernel (sdram + 32k), so move it past u-boot instead.
For raw mmc, we store the kernel parameter area in the free space after
the MBR (if used). For nand, we use the last sector of the partition
reserved for u-boot.
This also enables the spl command in the full u-boot so the kernel
parameter area snapshot can be created.
Signed-off-by: Peter Korsgaard <peter.korsgaard@barco.com>
If Falcon mode support is enabled (and the system isn't directed into
booting u-boot), it will instead try to load kernel from sector
CONFIG_SYS_MMCSD_RAW_MODE_KERNEL_SECTOR and
CONFIG_SYS_MMCSD_RAW_MODE_ARGS_SECTORS of kernel argument parameters
starting from sector CONFIG_SYS_MMCSD_RAW_MODE_ARGS_SECTOR.
Signed-off-by: Peter Korsgaard <peter.korsgaard@barco.com>
If Falcon mode support is enabled (and the system isn't directed into
booting u-boot), it will instead try to load kernel from
CONFIG_SPL_FAT_LOAD_KERNEL_NAME file and kernel argument parameters from
CONFIG_SPL_FAT_LOAD_ARGS_NAME, both from the same partition as u-boot.
Signed-off-by: Peter Korsgaard <peter.korsgaard@barco.com>
The non-SPL build of U-Boot on Tegra only runs on a single CPU, and
hence there is no need to enable the SCU when running U-Boot. If an
SMP OS is booted, and it needs the SCU enabled, it will enable the SCU
itself. U-Boot doing so is redundant.
The one exception is Tegra20, where an enabled SCU is required for some
aspects of PCIe to work correctly.
Some Tegra SoCs contain CPUs without a software-controlled SCU. In this
case, attempting to turn it on actively causes problems. This is the case
for Tegra114. For example, when running Linux, the first (or at least
some very early) user-space process will trigger the following kernel
message:
Unhandled fault: imprecise external abort (0x406) at 0x00000000
This is typically accompanied by that process receving a fatal signal,
and exiting. Since this process is usually pid 1, this causes total
system boot failure.
Signed-off-by: Tom Warren <twarren@nvidia.com>
[swarren, fleshed out description, ported to upstream chipid APIs]
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
No need to use the 'status' variable, so just remove it.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Reviewed-by: Otavio Salvador <otavio@ossystems.com.br>
[trini: Applied v1 of the series rather than v2, this commit is the
delta from v1 to v2]
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Tom Rini <trini@ti.com>
When running the "save" command several times on a mx6qsabresd we see:
U-Boot > save
Saving Environment to MMC...
Writing to MMC(1)... done
U-Boot > save
Saving Environment to MMC...
MMC partition switch failed
U-Boot > save
Saving Environment to MMC...
Writing to MMC(1)... done
U-Boot > save
Saving Environment to MMC...
MMC partition switch failed
U-Boot > save
Saving Environment to MMC...
Writing to MMC(1)... done
U-Boot > save
Saving Environment to MMC...
MMC partition switch failed
This issue is caused by the incorrect usage of CONFIG_SYS_MMC_ENV_PART.
CONFIG_SYS_MMC_ENV_PART should be used to specify the mmc partition that stores
the environment variables.
On some imx boards it is been incorrectly used to pass the partition of kernel
and dtb files for the 'mmcpart' script variable.
Remove the CONFIG_SYS_MMC_ENV_PART usage and configure the 'mmcpart' variable
directly.
Reported-by: Jason Liu <r64343@freescale.com>
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Acked-by: Jason Liu <r64343@freescale.com>
The location of valid scratch space is dependent on SoC, so move that
there. On OMAP4+ we continue to use SRAM_SCRATCH_SPACE_ADDR. On
am33xx/ti814x we want to use what the ROM defines as "public stack"
which is the area after our defined download image space. Correct the
comment about and location of CONFIG_SPL_TEXT_BASE.
Signed-off-by: Tom Rini <trini@ti.com>
Add a DT simple-framebuffer node to DT when booting the Linux kernel.
This will allow the kernel to inherit the framebuffer configuration from
U-Boot, and display a graphical boot console, and even run a full SW-
rendered X server.
Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
Acked-by: Simon Glass <sjg@chromium.org>
simple-framebuffer is a new device tree binding that describes a pre-
configured frame-buffer memory region and its format. The Linux kernel
contains a driver that supports this binding. Implement functions to
create a DT node (or fill in an existing node) with parameters that
describe the framebuffer format that U-Boot is using.
This will be immediately used by the Raspberry Pi board in U-Boot, and
likely will be used by the Samsung ARM ChromeBook support soon too. It
could well be used by many other boards (e.g. Tegra boards with built-in
LCD panels, which aren't yet supported by the Linux kernel).
Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
Acked-by: Simon Glass <sjg@chromium.org>
We need to call the save_omap_boot_params function on am33xx/ti81xx and
other newer TI SoCs, so move the function to boot-common. Only OMAP4+
has the omap_hw_init_context function so add ifdefs to not call it on
am33xx/ti81xx. Call save_omap_boot_params from s_init on am33xx/ti81xx
boards.
Reviewed-by: R Sricharan <r.sricharan@ti.com>
Signed-off-by: Tom Rini <trini@ti.com>
Prior to Sricharan's cleanup of the boot parameter saving code, we
did not make use of NON_SECURE_SRAM_START on am33xx, so it wasn't a
problem that the address was pointing to the middle of our running SPL.
Correct to point to the base location of the download image area.
Increase CONFIG_SPL_TEXT_BASE to account for this scratch area being
used. As part of correcting these tests, make use of the fact that
we've always been placing our stack outside of the download image area
(which is fine, once the downloaded image is run, ROM is gone) so
correct the max size test to be the ROM defined top of the download area
to where we link/load at.
Signed-off-by: Tom Rini <trini@ti.com>
---
Changes in v2:
- Fix typo noted by Peter Korsgaard
This can be useful to force bootcmd to execute as soon as U-Boot has
started.
My use-case is: An SoC-specific tool pushes U-Boot into RAM, along with
an image to be written to device boot flash, with the DT config property
"bootcmd" set to contain a command to write that image to flash. In this
scenario, we don't want to allow any stale bootdelay value taken from
the current flash content to affect how long it takes before the
flashing process starts.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Simon Glass <sjg@chromium.org>
Acked-by: Gerald Van Baren <vanbaren@cideas.com>
We know the exact property names that the code wants to process. Look
these up directly with fdt_get_property(), rather than iterating over
all properties within the node, and checking each property's name, in
a convoluted fashion, against the expected name.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Initialized character arrays on the stack can cause gcc to emit code that
performs unaligned accessess. Make the data static to avoid this.
Note that the unaligned accesses are made when copying data to prefix[] on
the stack from .rodata. By making the data static, the copy is completely
avoided. All explicitly written code treats the data as u8[], so will never
cause any unaligned accesses.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Simon Glass <sjg@chromium.org>
The generic-board board_init_f function called board_postclk_init twice.
The first one came from arch/arm/lib/board.c, while the second one
from arch/powerpc/lib/board.c.
This commit deletes the first occurrence.
In addition, the second get_clocks call is moved after
board_postclk_init in order to keep the function call order
both for ARM and PowerPC.
ARM board calles get_clocks function after board_postclk_init.
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Make sure to never access beyond bounds of either EFI partition name
or DOS partition name. This situation is happening:
part.h: disk_partition_t->name is 32-byte long
part_efi.h: gpt_entry->partition_name is 36-bytes long
The loop in part_efi.c copies over 36 bytes and thus accesses beyond
the disk_partition_t->name .
Fix this by picking the shortest of source and destination arrays and
make sure the destination array is cleared so the trailing bytes are
zeroed-out and don't cause issues with string manipulation.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Tom Rini <trini@ti.com>
Cc: Simon Glass <sjg@chromium.org>
The image code is fairly complex with various different options. It would
be useful to have comprehensive tests for this.
As a start, create a script which tries out loading a kernel/ramdisk/fdt
from a FIT and checks that the images appear in the right place in memory.
This uses sandbox which now supports bootm and related features.
Signed-off-by: Simon Glass <sjg@chromium.org>
Now that the code for loading these three images from a FIT is common, we
don't need individual boostage IDs for each of them.
Note: there are some minor changes in the bootstage numbering, particuarly
for kernel loading. I don't believe this matters.
Signed-off-by: Simon Glass <sjg@chromium.org>
Use map_sysmem() to convert from address to pointer, so that sandbox can
print FIT information without crashing.
Signed-off-by: Simon Glass <sjg@chromium.org>
Use the new common code to load a flat device tree. Also fix up a few casts
so that this code works with sandbox. Other than that the functionality
should not change.
Signed-off-by: Simon Glass <sjg@chromium.org>
