Tom Rini [Thu, 3 Aug 2017 13:33:07 +0000 (09:33 -0400)]
PowerPC: mpc85xx: Update ft_verify_fdt
With the changes to fdt_get_base_address() we need to modify the logic
in ft_verify_fdt() for how we check the validity of the CCSR address.
Tested-on: qemu-ppce500 -M mpc8544ds Fixes: 336a44877af8 ("fdt: Correct fdt_get_base_address()") Cc: York Sun <york.sun@nxp.com> Cc: Wolfgang Denk <wd@denx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Rini <trini@konsulko.com>
The logic of what fdt_get_base_address() will search for and return has
changed. Rework get_phys_ccsrbar_addr_early() to perform the logic that
fdt_get_base_address used to perform.
Fixes: 336a44877af8 ("fdt: Correct fdt_get_base_address()") Reviewed-by: Simon Glass <sjg@chromium.org> Cc: Alexander Graf <agraf@suse.de> Signed-off-by: Tom Rini <trini@konsulko.com>
Marek Vasut [Fri, 21 Jul 2017 21:20:34 +0000 (23:20 +0200)]
net: ravb: Detect PHY correctly
The order of parameters passed to the phy_connect() was wrong.
Moreover, only PHY address 0 was used. Replace this with code
capable of detecting the PHY address.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com> Cc: Joe Hershberger <joe.hershberger@ni.com> Cc: Nobuhiro Iwamatsu <iwamatsu@nigauri.org> Acked-by: Joe Hershberger <joe.hershberger@ni.com> Signed-off-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
Marek Vasut [Fri, 21 Jul 2017 21:19:18 +0000 (23:19 +0200)]
serial: sh: Use the clock framework to obtain clock config
Since we now have clock driver on the RCar Gen3 , obtain the clock
configuration using the clock framework functions. In case this
fails, fall back to the original code for pulling the clock config
directly out of OF.
Marek Vasut [Fri, 21 Jul 2017 21:18:03 +0000 (23:18 +0200)]
clk: rmobile: Add RCar Gen3 clock driver
Add clock driver for the RCar Gen3 R8A7795 and R8A7796 SoCs .
This driver allows reading out the clock configuration set by
previous boot stages and enabling and disabling clock using
the MSTP registers. Setting clock is not supported thus far.
Marek Vasut [Fri, 21 Jul 2017 21:16:59 +0000 (23:16 +0200)]
ARM: dts: rmobile: Import DTS from Linux 4.12
Import the RCar Gen3 DTS and headers from upstream Linux kernel v4.12-rc6,
commit 6f7da290413ba713f0cdd9ff1a2a9bb129ef4f6c . This includes both M3
and H3 ULCB and Salvator-X boards.
VINITHA PILLAI [Mon, 12 Jun 2017 04:13:45 +0000 (09:43 +0530)]
arm64: ls2088ardb: Add distro secure boot support
Enable validation of boot.scr script prior to its execution dependent
on "secureboot" flag in environment. Also enable "secureboot=y"
flag in environment for ARM based platforms instead of bootcmd.
Signed-off-by: Vinitha Pillai <vinitha.pillai@nxp.com> Signed-off-by: Sumit Garg <sumit.garg@nxp.com> Reviewed-by: York Sun <york.sun@nxp.com>
Include common config_distro_defaults.h and config_distro_bootcmd.h
for u-boot enviroments to support automatical distro boot which
scan boot.scr from external storage devices(e.g. SD/USB/SATA/SCSI disk)
and execute autoboot script. Tested on ls2088ardb with automatically
boot Ubuntu from SD card or USB disk, if it fails to detect external
storage disk, fall back to nor/qspi boot.
Signed-off-by: Zhang Ying-22455 <ying.zhang22455@nxp.com> Reviewed-by: York Sun <york.sun@nxp.com>
Sumit Garg [Tue, 6 Jun 2017 15:21:31 +0000 (20:51 +0530)]
arm: ls1021atwr: Add distro secure boot support
Enable validation of boot.scr script prior to its execution dependent
on "secureboot" flag in environment. Disable fall back option to
qspi boot in case of secure boot. Also enable "secureboot=y" flag
in environment for ARM based platforms instead of bootcmd.
Signed-off-by: Sumit Garg <sumit.garg@nxp.com> Tested-by: Vinitha Pillai <vinitha.pillai@nxp.com> Reviewed-by: York Sun <york.sun@nxp.com>
Sumit Garg [Tue, 6 Jun 2017 15:20:29 +0000 (20:50 +0530)]
arm64: ls1046ardb: Add distro secure boot support
Enable validation of boot.scr script prior to its execution dependent
on "secureboot" flag in environment. Disable fall back option to
qspi boot in case of secure boot. Also enable "secureboot=y" flag
in environment for ARM based platforms instead of bootcmd.
Signed-off-by: Sumit Garg <sumit.garg@nxp.com> Tested-by: Vinitha Pillai <vinitha.pillai@nxp.com> Reviewed-by: York Sun <york.sun@nxp.com>
Sumit Garg [Mon, 5 Jun 2017 18:21:51 +0000 (23:51 +0530)]
arm64: ls1043ardb: Add distro secure boot support
Enable validation of boot.scr script prior to its execution dependent
on "secureboot" flag in environment. Disable fall back option to
nor/qspi boot in case of secure boot. Also enable "secureboot=y"
flag in environment for ARM based platforms instead of bootcmd.
Signed-off-by: Sumit Garg <sumit.garg@nxp.com> Tested-by: Vinitha Pillai <vinitha.pillai@nxp.com> Reviewed-by: York Sun <york.sun@nxp.com>
Shengzhou Liu [Thu, 8 Jun 2017 07:59:48 +0000 (15:59 +0800)]
arm64: ls1043ardb: Add distro boot support
Include common config_distro_defaults.h and config_distro_bootcmd.h
for u-boot enviroments to support automatical distro boot which
scan boot.scr from external storage devices(e.g. SD/USB/SATA/SCSI disk)
and execute autoboot script. Tested on ls1043ardb with automatically
boot Ubuntu from SD card or USB disk, if it fails to detect external
storage disk, fall back to nor/qspi boot.
Signed-off-by: Shengzhou Liu <Shengzhou.Liu@nxp.com> Reviewed-by: York Sun <york.sun@nxp.com>
Alison Wang [Fri, 26 May 2017 07:46:15 +0000 (15:46 +0800)]
arm: ls1021atwr: Add distro boot support
This patch includes common config_distro_defaults.h and
config_distro_bootcmd.h for u-boot enviroments to support distro boot
which automatically scan boot.scr from storage devices(e.g.
SD/USB/SATA/SCSI disk) and execute autoboot script on LS1021ATWR board.
Signed-off-by: Shengzhou Liu <Shengzhou.Liu@nxp.com> Signed-off-by: Alison Wang <alison.wang@nxp.com> Reviewed-by: York Sun <york.sun@nxp.com>
Simon Glass [Mon, 31 Jul 2017 02:24:01 +0000 (19:24 -0700)]
x86: Convert MMC to driver model
Convert the pci_mmc driver over to driver model and migrate all x86 boards
that use it.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com>
[bmeng: remove DM_MMC from edison_defconfig] Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Bin Meng [Sun, 30 Jul 2017 13:23:26 +0000 (06:23 -0700)]
x86: kconfig: Let board select SPI flash
Only a specific type of SPI flash exists on a board, having board
Kconfig to select the SPI flash seems to make more sense. Other
flash types are not necessary except coreboot, which implies all
available flash drivers there.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Bin Meng [Sun, 30 Jul 2017 13:23:16 +0000 (06:23 -0700)]
x86: kconfig: Imply DM uclass drivers
Now that all x86 boards have been converted to use DM, we can imply
these uclass drivers (DM_ETH, DM_RTC, DM_USB, DM_VIDEO) from the
top level.
Previously DM_GPIO, DM_KEYBOARD, DM_SERIAL, DM_SPI, DM_SPI_FLASH
are selected. Change to use 'imply' to allow them to be removed.
Note with this change, chromebook_link64 build fails:
common/built-in.o:(.data.env_htab+0xc): undefined reference to 'env_flags_validate'
lib/built-in.o: In function `hsearch_r':
lib/hashtable.c:380: undefined reference to 'env_callback_init'
lib/hashtable.c:382: undefined reference to 'env_flags_init'
make[1]: *** [spl/u-boot-spl] Error 1
CONFIG_SPL_ENV_SUPPORT is required for chromebook_link64 to build
again. This is just a workaround as it is not needed at all. See
commit bda40d5 "x86: qemu: Add a config for 64-bit U-Boot" for
the same issue seen on QEMU 64-bit target.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Bin Meng [Sun, 30 Jul 2017 13:23:10 +0000 (06:23 -0700)]
x86: kconfig: Imply HAVE_INTEL_ME in the platform Kconfig
Intel Management Engine is required by the platform, however it's
not a must have when building a U-Boot image. For example, during
development normally programming ME firmware is a one-time effort.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Bin Meng [Wed, 26 Jul 2017 03:12:03 +0000 (20:12 -0700)]
x86: tsc: Update comments and expand definitions in freq_desc_tables[]
Some processor abbreviations in the comments of freq_desc_tables[]
are obscure. This updates part of these to mention processors
that are known to us. Also expand frequency definitions.
This keeps in sync with Linux kernel commit: 9e0cae9: x86/tsc_msr: Update comments, expand definitions
Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Bin Meng [Thu, 27 Jul 2017 13:12:35 +0000 (06:12 -0700)]
x86: Enforce toolchain to generate 64-bit codes for 64-bit U-Boot
64-bit U-Boot image is a combination of 32-bit U-Boot (SPL) plus
64-bit U-Boot (proper). For the U-Boot proper, it has be compiled
to 64-bit object codes. Attempting to use a toolchain to compile
64-bit U-Boot for qemu-x86_64, like kernel.org 4.9 i386-linux-gcc,
fails with the following errors:
arch/x86/cpu/intel_common/microcode.c:79:2: error: PIC register
clobbered by 'ebx' in 'asm'
The issue is because toolchain is preconfigured to generate code
for the 32-bit architecture (i386), and currently '-m64' is missing
in the makefile fragment. Using kernel.org 4.9 x86_64-linux-gcc
works out of the box, since it is preconfigured to generate 64-bit
codes.
When compiling U-Boot SPL, '-m32' is passed to the toolchain, no
mater 32-bit (i386-linux-) or 64-bit (x86_64-linux) the toolchain
is preconfigured to generate.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Bin Meng [Thu, 27 Jul 2017 13:12:34 +0000 (06:12 -0700)]
x86: Use default stack boundary alignment
At present U-Boot x86 build is using -mpreferred-stack-boundary=2
which is 4 bytes stack boundary alignment. With 64-bit U-Boot, the
minimal required stack boundary alignment is 16 bytes.
If -mpreferred-stack-boundary is not specified, the default is 4
(16 bytes). Switch to use the default one.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
regulator: palmas: Add support for LDO1 regulator to provide 1.8V
Modify palmas_mmc1_poweron_ldo() API to set the voltage based on the
voltage parameter passed as argument instead of always setting it to
3.0V. This allows MMC1 to set the LDO1 regulator voltage to 3.3V or 1.8V.
1.8V is required to add support for UHS mode.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
Simon Glass [Tue, 4 Jul 2017 19:31:32 +0000 (13:31 -0600)]
dm: sunxi: Move Linksprite_pcDuino3 to use DM for MMC, SATA
Move this board over to driver model for MMC and SATA. This means that it
uses CONFIG_BLK as well. In SPL these options remain turned off since it
increases the code size. One option would be to use CONFIG_SPL_OF_PLATDATA
to avoid device-tree overhead.
Simon Glass [Tue, 4 Jul 2017 19:31:30 +0000 (13:31 -0600)]
dm: sunxi: sata: Don't build sata support into SPL
This is not used in SPL so we do not need to compile it. Make this change
before adding driver-model support to the driver, to avoid build errors.
With driver model we define a U_BOOT_DRIVER() which would otherwise be
present in SPL and not be garbage-collected when building.
Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Simon Glass [Tue, 4 Jul 2017 19:31:26 +0000 (13:31 -0600)]
dm: mmc: sunxi: Drop mmc_clk_io_on()
This function has #ifdefs in it which we want to avoid for driver model.
Instead we should use different compatible strings and the .data field.
It also uses the MMC device number which is not available in driver
model except through aliases.
Move the function's into its caller so that the driver-model version can
do things its own way.
Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Simon Glass [Tue, 4 Jul 2017 19:31:25 +0000 (13:31 -0600)]
dm: mmc: sunxi: Pass private data around explicitly
At present the driver-private data is obtained in various functions by
various means. With driver model this is provided automatically. Without
driver model it comes from a C array declared at the top of the file.
Adjust internal functions so that they are passed the private data as
a parameter, allowing the caller to obtain it using either means.
Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Simon Glass [Tue, 4 Jul 2017 19:31:22 +0000 (13:31 -0600)]
dm: ahci: Correct uclass private data
This is expected to be attached to the uclass and the code operates that
way, but the uclass has not been updated. Fix it to avoid using memory at
address 0.
Signed-off-by: Simon Glass <sjg@chromium.org> Fixes: 47fc61a (dm: ahci: Drop use of probe_ent)
Simon Glass [Tue, 4 Jul 2017 19:31:21 +0000 (13:31 -0600)]
dm: scsi: Drop duplicate SCSI and DM_SCSI options
When the SATA code was moved into drivers/ata these Kconfig options were
added to that directory. They already exist in drivers/scsi. Remove them
from drivers/ata to fix the duplication.
Signed-off-by: Simon Glass <sjg@chromium.org> Fixes: 7f2b5f4 (sata: Move drivers into new drivers/ata directory)
Simon Glass [Tue, 4 Jul 2017 19:31:19 +0000 (13:31 -0600)]
dm: mmc: Allow disabling driver model in SPL
At present if U-Boot proper uses driver model for MMC, then SPL has to
also. While this is desirable, it places a significant barrier to moving
to driver model in some cases. For example, with a space-constrained SPL
it may be necessary to enable CONFIG_SPL_OF_PLATDATA which involves
adjusting some drivers.
Add new SPL versions of the options for DM_MMC, DM_MMC_OPS and BLK. By
default these follow their non-SPL versions, but this can be changed by
boards which need it.
Simon Glass [Tue, 4 Jul 2017 19:31:18 +0000 (13:31 -0600)]
ahci: Support non-PCI controllers
At present the AHCI SCSI driver only supports PCI with driver model.
Rename the existing function to indicate this and add support for adding
a non-PCI controller .
Simon Glass [Thu, 27 Jul 2017 15:31:04 +0000 (09:31 -0600)]
dm: console: Check for serial devices properly
With driver model the serial device is often not called "serial". Mark
driver-model stdio devices so that they can be detected and we can look up
the uclass. This is a more reliable way of finding out whether the console
is connected to a serial device or not.
Tom Rini [Wed, 26 Jul 2017 17:11:36 +0000 (13:11 -0400)]
am335x_hs_evm: Disable CONFIG_SPL_ENV_SUPPORT
The main uses of CONFIG_SPL_ENV_SUPPORT are for network support and for
disabling "Falcon Mode" support at run-time. As this build enables
neither, remove this feature.
Cc: Andrew F. Davis <afd@ti.com> Signed-off-by: Tom Rini <trini@konsulko.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Tom Rini [Thu, 27 Jul 2017 01:48:00 +0000 (21:48 -0400)]
env: Migrate CONFIG_ENV_IS_IN_FAT options to Kconfig
We rename the various FAT_ENV_xxx options to CONFIG_ENV_FAT_xxx so that
they can be modified via Kconfig. Migrate all existing users to the new
values.
Alexander Graf [Mon, 31 Jul 2017 07:15:57 +0000 (09:15 +0200)]
efi_loader: Fix warning in efi_gop
Commit ca9193d2b16 ("efi_loader: gop: fixes for CONFIG_DM_VIDEO without
CONFIG_LCD") dropped the explicit (void*) cast for fb_base in efi gop support
for CONFIG_LCD without DM. This patch adds it back, eliminating the now occuring
warning again
Fixes: ca9193d2b16 ("efi_loader: gop: fixes for CONFIG_DM_VIDEO without CONFIG_LCD") Reported-by: Tom Rini <trini@konsulko.com> Signed-off-by: Alexander Graf <agraf@suse.de>
projects / u-boot / log