| Age | Commit message (Collapse) | Author |
|---|
|
Try to maintain as much commonality by conditionally including stuff
in armv7_common as necessary and removing the common defines from
keystone2 header.
Note: as part of this change, all keystone2 platforms will now start
using the generic u-boot prompt instead of the custom prompt.
Signed-off-by: Nishanth Menon <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
|
|
rename the keystone2 common header into an keystone2 architecture
specific header which can then reuse the common ti_armv7 config headers.
Acked-by: Vitaly Andrianov <[email protected]>
Acked-By: Murali Karicheri <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
Signed-off-by: Nishanth Menon <[email protected]>
|
|
CONFIG_LINUX_BOOT_PARAM_ADDR is not a valid configuration option. Do
just like what the rest of the world does.
Acked-by: Vitaly Andrianov <[email protected]>
Acked-By: Murali Karicheri <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
Signed-off-by: Nishanth Menon <[email protected]>
|
|
Commit bd2c4522c26d5 ("ti: armv7: enable EXT support in SPL (using
ti_armv7_common.h)") enabled thumb mode only for SPL builds, however,
All TI armv7 platforms do support thumb, and there is no reason why the
space savings cannot be exploited for u-boot as well.
Reported-by: Murali Karicheri <[email protected]>
Suggested-by: Tom Rini <[email protected]>
Signed-off-by: Nishanth Menon <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
|
|
TI armv7 based SoCs are based on two architectures - one based on OMAP
generation architecture and others based on Keystone architecture.
Many of the options are architecture specific, however a lot are common
with v7 architecture. So, step 1 will be to move out OMAP specific stuff
from ti_armv7_common into a ti_armv7_omap.h header which is then used
by all the relevant architecture headers.
Reviewed-by: Tom Rini <[email protected]>
Signed-off-by: Nishanth Menon <[email protected]>
|
|
CONFIG_MUSB_HDC should be CONFIG_MUSB_HCD to have any effect.
Signed-off-by: Paul Kocialkowski <[email protected]>
|
|
Gumstix is migrating from ext3 to ext4 file system.
Signed-off-by: Adam YH Lee <[email protected]>
Acked-by: Ash Charles <[email protected]>
|
|
Mainline Linux kernel commit
338a6aaabc02fa63b70441dd0e1b70aea64673c6 (ARM: dts: Introduce
STM32F429 MCU) in arch/arm/boot/dts/stm32f429.dtsi
requires U-Boot to set system clock to 180 MHz.
Signed-off-by: Antonio Borneo <[email protected]>
To: Albert Aribaud <[email protected]>
To: Tom Rini <[email protected]>
To: Kamil Lulko <[email protected]>
Cc: [email protected]
|
|
Read device unique ID and set environment variable "serial#".
Value would then be passed to kernel through DTB.
To read ID from DTB, kernel is required to have commit:
3f599875e5202986b350618a617527ab441bf206 (ARM: 8355/1: arch: Show
the serial number from devicetree in cpuinfo)
This commit is already mainline since v4.1-rc1.
Signed-off-by: Antonio Borneo <[email protected]>
To: Albert Aribaud <[email protected]>
To: Tom Rini <[email protected]>
To: Kamil Lulko <[email protected]>
Cc: [email protected]
|
|
The config file for the siemens-am33x-common was using OMAP_I2C_STANDARD, which
is defined in a header that is not included in the config header. In most cases,
it was being included by the code using CONFIG_SYS_OMAP24_I2C_SPEED, but it
might not always be the case.
In particular, when introducing I2C SPL support in omap-common's boot-common.c,
the header is missing and including it breaks other devices.
Signed-off-by: Paul Kocialkowski <[email protected]>
|
|
This introduces OMAP3 support for the common omap boot code, as well as a
major cleanup of the common omap boot code.
First, the omap_boot_parameters structure becomes platform-specific, since its
definition differs a bit across omap platforms. The offsets are removed as well
since it is U-Boot's coding style to use structures for mapping such kind of
data (in the sense that it is similar to registers). It is correct to assume
that romcode structure encoding is the same as U-Boot, given the description
of these structures in the TRMs.
The original address provided by the bootrom is passed to the U-Boot binary
instead of a duplicate of the structure stored in global data. This allows to
have only the relevant (boot device and mode) information stored in global data.
It is also expected that the address where the bootrom stores that information
is not overridden by the U-Boot SPL or U-Boot.
The save_omap_boot_params is expected to handle all special cases where the data
provided by the bootrom cannot be used as-is, so that spl_boot_device and
spl_boot_mode only return the data from global data.
All of this is only relevant when the U-Boot SPL is used. In cases it is not,
save_boot_params should fallback to its weak (or board-specific) definition.
save_omap_boot_params should not be called in that context either.
Signed-off-by: Paul Kocialkowski <[email protected]>
|
|
There are only two SoC-specific headers for this architecture:
- arch/nds32/include/asm/arch-ag101/ag101.h
- arch/nds32/include/asm/arch-ag102/ag102.h
Those two have different file names, so there is no advantage to
include them via symbolic linked directory.
Signed-off-by: Masahiro Yamada <[email protected]>
|
|
Mainline kernel will be using this device name as well.
Signed-off-by: Kamil Lulko <[email protected]>
|
|
Palmas power support is required for OMAP5 devices such as the OMAP5 uEVM, that
need to e.g. enable MMC power at SPL stage.
This is especially important when booting from a peripheral (such as USB, UART),
where the bootrom will not enable power for the MMC device that will hold the
main U-Boot.
Signed-off-by: Paul Kocialkowski <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
|
|
Use more standard boot scripts and also add the capability of
booting via NFS.
Signed-off-by: Otavio Salvador <[email protected]>
|
|
Add SATA support.
Signed-off-by: Otavio Salvador <[email protected]>
|
|
Add LVDS and HDMI support.
Signed-off-by: Otavio Salvador <[email protected]>
|
|
Add USB support.
Signed-off-by: Otavio Salvador <[email protected]>
|
|
cgtqmx6eval has a PFUZE100 FSL PMIC connected to I2C2.
Add support for it.
Signed-off-by: Otavio Salvador <[email protected]>
|
|
Add thermal support so that we can see the following message on boot:
CPU: Industrial temperature grade (-40C to 105C) at 33C
Signed-off-by: Otavio Salvador <[email protected]>
|
|
Entering the maximum number of characters defined by CONFIG_SYS_CBSIZE into
the console and hitting enter afterwards, causes a hang in the system because
CONFIG_SYS_PBSIZE is not capable of storing the extra characters of the error
message:
"Unknown command '' - try 'help'".
Use the default CONFIG_SYS_PBSIZE definition from config_fallbacks.h to solve
this problem.
Signed-off-by: Otavio Salvador <[email protected]>
|
|
Remove the custom prompt and use the default instead.
Signed-off-by: Otavio Salvador <[email protected]>
|
|
Warp has a MAX77696 PMIC connected via I2C1 bus.
Add support for it.
Signed-off-by: Fabio Estevam <[email protected]>
|
|
Add support for MAX77696 PMIC.
Signed-off-by: Fabio Estevam <[email protected]>
|
|
It seems that many comments were copied from the I2C uclass, so adjust
the comments for the thermal class.
Reported-by: Simon Glass <[email protected]>
Signed-off-by: Fabio Estevam <[email protected]>
Acked-by: Otavio Salvador <[email protected]>
Acked-by: Simon Glass <[email protected]>
|
|
This patch adds support for the "OHB System AG" baseboard
with is equipped with the TQMa6S SoM.
Signed-off-by: Stefan Roese <[email protected]>
Cc: Markus Niebel <[email protected]>
Cc: Stefano Babic <[email protected]>
|
|
|
|
Start using the new Kconfig options which are available for these now,
and simply always enable them by selecting them as sunxi builds always
include USB support.
Signed-off-by: Hans de Goede <[email protected]>
Acked-by: Ian Campbell <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
|
|
This makes more complex U-Boot scripts possible.
Signed-off-by: Stefan Roese <[email protected]>
Cc: Luka Perkov <[email protected]>
|
|
This patch adds the configuration options to boot via SDIO/MMC on the
Marvell DB-88F6820-GP Armada A38x board. The default boot device
is still SPI NOR flash.
To enable MMC booting on this board 2 things need to be changes:
a) Change kwbimage.cfg
BOOT_FROM sdio
b) In the config header select
#define CONFIG_SPL_BOOT_DEVICE SPL_BOOT_SDIO_MMC_CARD
The generated image needs to be copied to the first bootable MMC
partition:
dd if=u-boot-spl.kwb of=/dev/sdX1
Signed-off-by: Stefan Roese <[email protected]>
Cc: Luka Perkov <[email protected]>
Cc: Dirk Eibach <[email protected]>
|
|
|
|
The init code for UMC (Unified Memory Controller) and PLL has not
been mainlined yet, but U-boot proper should work.
Signed-off-by: Masahiro Yamada <[email protected]>
|
|
Both "earlyprintk" and "loglevel=8" should be useful for the
development.
Signed-off-by: Masahiro Yamada <[email protected]>
|
|
The command "run tftpboot" downloads some files onto the RAM
via TFTP and boots the kernel.
Signed-off-by: Masahiro Yamada <[email protected]>
|
|
Currently, the environment variables "norboot" and "nandboot" only
work with CONFIG_FIT, but we do not want to depend on CONFIG_FIT to
boot the kernel.
This commit adds environments useful for booting Linux with separate
uImage + ramdisk + DTB.
Signed-off-by: Masahiro Yamada <[email protected]>
|
|
|
|
This patch adds SPL support for the Marvell DB-88F6820-GP board.
With this change, the bin_hdr from the original Marvell U-boot
is not needed any more on this board. The sources from bin_hdr
(SERDES/PHY and DDR setup) are now integrated in mainline
U-Boot. And this patch enables them for this board.
Signed-off-by: Stefan Roese <[email protected]>
|
|
With the upcoming addition of the Armada 38x DDR support, which is not
compatible to the Armada XP DDR init code, we need to introduce a new
directory infrastructure. To support multiple Marvell DDR controller.
This will be the new structure:
drivers/ddr/marvell/axp
Supporting Armada XP (AXP) devices (and perhaps Armada 370)
drivers/ddr/marvell/a38x
Supporting Armada 38x devices (and perhaps Armada 39x)
Signed-off-by: Stefan Roese <[email protected]>
|
|
This patch initializes the SATA address windows on Armada XP and
allows it to work with the existing mvsata_ide driver.
It also adds the necessary configuration for the db-mv784mp-gp board.
Signed-off-by: Anton Schubert <[email protected]>
Tested-by: Stefan Roese <[email protected]>
Cc: Luka Perkov <[email protected]>
|
|
Currently, kzalloc() returns zero-filled memory, while kmalloc()
simply ignores the second argument and never fills the memory
area with zeros.
I want kmalloc(size, __GFP_ZERO) to behave as kzalloc() does,
which will make it easier to add more memory allocator variants.
With the introduction of __GFP_ZERO flag, going forward, kzmalloc()
variants can fall back to kmalloc() enabling the __GFP_ZERO flag.
Signed-off-by: Masahiro Yamada <[email protected]>
Reviewed-by: Heiko Schocher <[email protected]>
Acked-by: Simon Glass <[email protected]>
Reviewed-by: Lukasz Majewski <[email protected]>
|
|
The vzalloc(size) is equivalent to kzalloc(size, 0). Move it to
include/linux/compat.h as an inline function in order to avoid the
function call overhead.
Signed-off-by: Masahiro Yamada <[email protected]>
Reviewed-by: Heiko Schocher <[email protected]>
Acked-by: Simon Glass <[email protected]>
|
|
The macro cpu_relax() is defined by several headers in different
ways.
arch/{arm,avr32,mips}/include/asm/processor.h defines it as follows:
#define cpu_relax() barrier()
On the other hand, include/linux/compat.h defines it as follows:
#define cpu_relax() do {} while (0)
If both headers are included from the same source file, the warning
warning: "cpu_relax" redefined [enabled by default]
is displayed.
It effectively makes it impossible to include <linux/compat.h>
from some sources. Drop the latter.
Signed-off-by: Masahiro Yamada <[email protected]>
Reviewed-by: Heiko Schocher <[email protected]>
Acked-by: Simon Glass <[email protected]>
Reviewed-by: Lukasz Majewski <[email protected]>
|
|
FASTBOOT is defined both by CONFIG_USB_FUNCTION_FASTBOOT AND CONFIG_CMD_FASTBOOT, so it doesn't
make much sense to have a CONFIG_USB_FASTBOOT prefix for fastboot-specific options, especially
given that other config options for fastboot use the CONFIG_FASTBOOT prefix.
This replaces the CONFIG_USB_FASTBOOT prefix with CONFIG_FASTBOOT, for consistency.
Signed-off-by: Paul Kocialkowski <[email protected]>
|
|
Signed-off-by: Jiandong Zheng <[email protected]>
Signed-off-by: Steve Rae <[email protected]>
|
|
Signed-off-by: Steve Rae <[email protected]>
Tested-by: Lukasz Majewski <[email protected]>
Test HW: Exynos 4210 (trats), Exynos 5422 (Odroid XU3)
|
|
Each USB download function command calls board_usb_init before registering the
USB gadget and board_usb_cleanup after de-registering it. On devices currently
using fasboot, musb-new is usually initialized earlier, but some other boards
might need the board_usb_init call to properly initialize musb-new.
This requires adding an argument (the USB controller index) to the fastboot
command, as it is currently done with other USB download gadget functions.
Signed-off-by: Paul Kocialkowski <[email protected]>
Tested-by: Lukasz Majewski <[email protected]>
Test HW: Odroid_XU3 (Exynos5422), trats (Exynos4210)
|
|
USB download gadget functions such as thor and dfu have a separate config option
for the USB gadget part of the code, independent from the command part.
This switches the fastboot USB gadget to the same scheme, for better
consistency.
Signed-off-by: Paul Kocialkowski <[email protected]>
Tested-by: Lukasz Majewski <[email protected]>
Test HW: Odroid_XU3 (Exynos5422), trats (Exynos4210)
|
|
This introduces a coherent scheme for naming USB download gadget and functions
config options. The download USB gadget config option is moved to
CONFIG_USB_GADGET_DOWNLOAD for better consistency with other gadgets and each
function's config option is moved to a CONFIG_USB_FUNCTION_ prefix.
Signed-off-by: Paul Kocialkowski <[email protected]>
Tested-by: Lukasz Majewski <[email protected]>
Test HW: Odroid_XU3 (Exynos5422), trats (Exynos4210)
|
|
Map USB XHCI controller base addresses for LS2085A SOC
Signed-off-by: Nikhil Badola <[email protected]>
|
