Alexey Brodkin [Wed, 21 Feb 2018 10:06:26 +0000 (13:06 +0300)]
Makefile: Don't mess with .text section location for selected arches
Most of architectures have .text section situated in the very beginning
of U-Boot binary and thus it is very logical that CONFIG_SYS_TEXT_BASE
is used on final linkage step to specify where U-Boot gets linked to.
For that we pass the following construction to the LD:
---------------------------->8-----------------------
xxx-ld ... -Ttext $(CONFIG_SYS_TEXT_BASE) ...
---------------------------->8-----------------------
But there could be exceptions. For example:
1. In case of ARCv2 we want to put vectors table in its own section
.ivt in front of .text section which means we need either add an
offset to CONFIG_SYS_TEXT_BASE to compensate for .ivt or don't
pass "-Ttext" to the LD at all and specify link base in linker
script directly.
2. Some architectures even though have .text section in the very
beginning of the U-Boot image still use different symbols to
specify link-base:
* NIOS2: CONFIG_SYS_MONITOR_BASE (which I really like because
that exactly what makes sense - where out image starts but not
beginning of its .text section which just happened to match the
whole image beginning)
* EXTENSA: CONFIG_SYS_TEXT_ADDR
* X86: Which doesn't use CONFIG_SYS_MONITOR_BASE in case of EFI
otherwise sets explicit link base in u-boot.lds
I think that's good to allow for flexibility and don't require each and
every architecture or even platform to specify CONFIG_SYS_TEXT_BASE as well
as use it to set .text section location.
So let's only pass "-Ttext xxx" for those architectures who don't set
link-base explicitly in their linker scripts.
This patch iaddresses comments for previously sent
https://patchwork.ozlabs.org/patch/867540/.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com> Cc: Masahiro Yamada <yamada.masahiro@socionext.com> Cc: Marek Vasut <marek.vasut@gmail.com> Cc: Max Filippov <jcmvbkbc@gmail.com> Cc: Simon Glass <sjg@chromium.org> Cc: Tom Rini <trini@konsulko.com>
Karl Beldan [Tue, 20 Feb 2018 23:30:08 +0000 (23:30 +0000)]
arm64: show_regs: Dump the LRs HW values
These were dropped in [1], after relocation, for their values offset by
reloc_off.
Unconditionally show the HW values and add a '(reloc)' hint for the
offset values showed after relocation.
Also, the LRs' dumps are now formatted the same way the other regs' are.
[1] Commit 082693f4 ("arm64 :show_regs: show the address before relocation")
Signed-off-by: Karl Beldan <karl.beldan+oss@gmail.com>
Michal Simek [Tue, 20 Feb 2018 09:19:00 +0000 (10:19 +0100)]
net: Remove Xilinx ll_temac driver
ll_temac driver was used by Xilinx Microblaze big endian and
Xilinx ppc405/ppc440 SoCs.
ppc support was removed by: "powerpc: remove 4xx support"
(sha1: 98f705c9cefdfdba62c069821bbba10273a0a8ed)
and Microblaze BE is not tested for a long time that's why this driver
can be removed because none is going to updated it to DM anyway.
Signed-off-by: Michal Simek <michal.simek@xilinx.com> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
Andrew F. Davis [Wed, 14 Feb 2018 17:53:37 +0000 (11:53 -0600)]
ARM: Kconfig: Move TI_SECURE_DEVICE to a common area
TI_SECURE_DEVICE is used by both OMAP2+ and Keystone2 family devices,
and so when ARCH_OMAP2PLUS was used to gate off the OMAP2+ Kconfig
Keystone2 family devices lost this config option.
Move this option out of mach-omap2 Kconfig to a spot accessible by both
families. We picked arch/arm/Kconfig over the TI specific board/ti/
location as this option is not specific to our boards but rather our
architecture.
Plus at some point this option can be changed to just
SECURE_DEVICE, as having secure parts is not exclusive to TI and
so other vendors can interpret this option as needed by their device
configurations.
Fixes: a93fbf4a7892 ("ARM: omap2+: rename config to ARCH_OMAP2PLUS and consolidate Kconfig") Signed-off-by: Andrew F. Davis <afd@ti.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
Tom Rini [Sat, 10 Feb 2018 21:54:38 +0000 (16:54 -0500)]
configs: Re-sync with CONFIG_DISTRO_DEFAULTS
A number of platforms include config_distro_defaults.h but do not enable
CONFIG_DISTRO_DEFAULTS. As they plainly intended to, set that flag and
re-sync config files.
Lukasz Majewski [Wed, 14 Feb 2018 10:39:48 +0000 (11:39 +0100)]
script: Make the get_default_envs.sh script working with newest u-boot
This commit fixes several issues:
- After moving env related code to ./env directory the env_common.o file
is no longer present in the system (has been replaced with built-in.o).
- Use ${OBJCOPY} if available, fallback to system default's objcopy if not
present.
- Extend the script to accept different build directory than current one.
It is extremely handy with OE usage, where source code is separated from
build.
Signed-off-by: Lukasz Majewski <lukma@denx.de> Tested-by: Alex Kiernan <alex.kiernan@gmail.com>
Faiz Abbas [Mon, 12 Feb 2018 13:54:31 +0000 (19:24 +0530)]
env: mmc/fat/ext4: make sure that the MMC sub-system is initialized before using it
When booting from a non-MMC device, the MMC sub-system may not be
initialized when the environment is first accessed.
We need to make sure that the MMC sub-system is ready in even a non-MMC
boot case.
Therefore, initialize mmc before loading environment from it.
Alex Kiernan [Fri, 9 Feb 2018 15:24:38 +0000 (15:24 +0000)]
mmc: Fix uninitialised priv member
When using omap_hsmmc without the device model then the allocation
of mmc->priv ends up uninitialised.
Signed-off-by: Alex Kiernan <alex.kiernan@gmail.com> Tested-by: Robert Nelson <robertcnelson@gmail.com> Reviewed-by: Sam Protsenko <semen.protsenko@linaro.org>
The correspondence between mmc versions as used in u-boot and the version
numbers reported in register EXT_CSD_REV is wrong for versions above and
including MMC_VERSION_4_41. All those versions were shifted by one:
real 4.5 hardware appeared to be MMC_VERSION_5_0.
Fix this by adding the missing version in the correspondence table.
Reported-by: eil Eilmsteiner Heribert <eil@keba.com> Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Sam Protsenko <semen.protsenko@linaro.org>
After settings the speed of the sd with the switch command, a check is
done to make sure that the new speed has been set. The current check has a
masking error: speed are encoded on 4 bits only.
Fix it by masking the upper bits.
This fixes a problem seen with QEmu emulating a vexpress-a15.
Reported-by: Jonathan Gray <jsg@jsg.id.au> Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com> Tested-by: Jonathan Gray <jsg@jsg.id.au>
ARM: DRA7x/AM57x: Add MMC/SD fixups for rev1.0 and rev 1.1
Since DRA7xx/AM57xx SR1.1 and SR1.0 has errata to limit the frequency of
MMC1 to 96MHz and frequency of MMC2 to 48MHz for AM572x SR1.1, limit the
frequency and disable higher speed modes for those revision.
Also use the recommended IO delays (those tagged with "rev11")
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
dts: am57xx-beagle-x15: disable UHS and HS200 support
The UHS modes are not supported in beagle-x15 because it's not possible to
switch the IO lines supply voltage to 1.8v.
Also HS200 cannot be supported on mmc2, because the IO lines of mmc2 are
connected to 3.3v.
ARM: dts: DRA7: use new dra7-specific compatible string
Use the new compatible string "ti,dra7-hsmmc" that was specifically
added for dra7 and dra72. This is required since for dra7 and dra72
processors iodelay values has to be set unlike other processors.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
Now that omap_hsmmc has support for hs200 mode, change the clock
frequency to 192MHz. Also change the REFERENCE CLOCK frequency to
192MHz based on which the internal mmc clock divider is calculated.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
mmc: omap_hsmmc: add signal voltage selection support
I/O data lines of UHS SD card operates at 1.8V when in UHS speed
mode (same is true for eMMC in DDR and HS200 modes). Add support
to switch signal voltage to 1.8V in order to support
UHS cards and eMMC HS200 and DDR modes.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
mmc: omap_hsmmc: Add support to get pinctrl values and max frequency for different hw revisions
AM572x SR1.1 requires different IODelay values to be used than that used
in AM572x SR2.0. These values are populated in device tree. Add
capability in omap_hsmmc driver to extract IOdelay values for different
silicon revision. The maximum frequency is also reduced when using a ES1.1.
To keep the ability to boot both revsions with the same dtb, those values
can be provided by the platform code.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
mmc: omap_hsmmc: Add support to set IODELAY values
The data manual of J6/J6 Eco recommends to set different IODELAY values
depending on the mode in which the MMC/SD is enumerated in order to
ensure IO timings are met.
Add support to parse mux values and iodelay values from device tree
and set these depending on the enumerated MMC mode.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
ARM: OMAP5/DRA7: Enable iodelay recalibration to be done from uboot
Add a new API to perform iodelay recalibration without isolate
io to be used in uboot.
The data manual of J6/J6 Eco recommends to set different IODELAY values
depending on the mode in which the MMC/SD is enumerated in order to
ensure IO timings are met. The MMC driver can use the new API to
set the IO delay values depending on the MMC mode.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
mmc: omap_hsmmc: Reduce the max timeout for reset controller fsm
>From OMAP3 SoCs (OMAP3, OMAP4, OMAP5, AM572x, AM571x), the DAT/CMD lines
reset procedure section in TRM suggests to first poll the SRD/SRC bit
until it is set to 0x1. But looks like that bit is never set to 1 and there
is an observable delay of 1sec everytime the driver tries to reset DAT/CMD.
(The same is observed in linux kernel).
Reduce the time the driver waits for the controller to set the SRC/SRD bits
to 1 so that there is no observable delay.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
According to errata i802, DCRC error interrupts
(MMCHS_STAT[21] DCRC=0x1) can occur during the tuning procedure.
The DCRC interrupt, occurs when the last tuning block fails
(the last ratio tested). The delay from CRC check until the
interrupt is asserted is bigger than the delay until assertion
of the tuning end flag. Assertion of tuning end flag is what
masks the interrupts. Because of this race, an erroneous DCRC
interrupt occurs.
The suggested workaround is to disable DCRC interrupts during
the tuning procedure which is implemented here.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
HS200/SDR104 requires tuning command to be sent to the card. Use
the mmc_send_tuning library function to send the tuning
command and configure the internal DLL.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
mmc: omap_hsmmc: add support to set default io voltage
"ti,dual-volt" is used in linux kernel to set the voltage capabilities.
For host controller dt nodes that doesn't have "ti,dual-volt",
it's assumed 1.8v is the io voltage. This is not always true (like in
the case of beagle-x15 where the io lines are connected to 3.3v).
Hence if "no-1-8-v" property is set, io voltage will be set to 3v.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
Add a separate function for starting the clock, stopping the clock and
setting the clock. Starting the clock and stopping the clock can
be used irrespective of setting the clock (For example during iodelay
recalibration).
Also set the clock only if there is a change in frequency.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
Fixes a bug found on thuban boards, which were for 2 years in
a long-term test with varying temperatures. They showed
problems in u-boot when attaching the ubi partition:
Reason is, that accidentially the U-Boot implementation
from __schedule_ubi_work() did not check the flag
ubi->thread_enabled and started with wearleveling work,
but ubi did not have setup all structures at this point
and crashes.
Solve this problem by splitting work scheduling and processing.
Signed-off-by: Richard Weinberger <richard@nod.at> Signed-off-by: Heiko Schocher <hs@denx.de>
If actual_speed is passed as NULL in this function:
static void __twsi_i2c_init(struct mvtwsi_registers *twsi, int speed,
int slaveadd, uint *actual_speed)
than __twsi_i2c_set_bus_speed never get called. This causes i2c clock
to run on default speed - 2MHz (measured with oscilloscope). This is issue
on some boards, sunxi for example, since on I2C0 bus PMU is connected.
The bootlogs with and without the patch are as follows:
Wihtout the patch:
U-Boot SPL 2018.03-rc2 (Feb 13 2018 - 09:23:17 +0200)
DRAM: 1024 MiB
Failed to set core voltage! Can't set CPU frequency
Trying to boot from FEL
With the patch:
U-Boot SPL 2018.03-rc2-00001-g838ff85 (Feb 13 2018 - 09:24:34 +0200)
DRAM: 1024 MiB
CPU: 912000000Hz, AXI/AHB/APB: 3/2/2
Trying to boot from FEL
Simon Glass [Sat, 3 Feb 2018 17:36:59 +0000 (10:36 -0700)]
sandbox: Rename 'num-gpios' property to avoid dtc warning
At present dtc produces these warnings when compiling sandbox:
arch/sandbox/dts/test.dtb: Warning (gpios_property):
Could not get phandle node for /base-gpios:num-gpios(cell 0)
arch/sandbox/dts/test.dtb: Warning (gpios_property):
Missing property '#gpio-cells' in node /reset-ctl or bad phandle
(referred from /extra-gpios:num-gpios[0])
Both are due to it assuming that the 'num-gpios' property holds a phandle
pointing to a GPIO node.
To avoid these warnings, rename the sandbox property so that it does not
include the string 'gpios'.
Simon Glass [Sat, 3 Feb 2018 17:36:58 +0000 (10:36 -0700)]
sandbox: Correct dtc warning in /chosen node
At present dtc produces these warnings when compiling sandbox:
arch/sandbox/dts/test.dtb: Warning (reg_format): "reg" property in /chosen/chosen-test has invalid length (8 bytes) (#address-cells == 2, #size-cells == 1)
arch/sandbox/dts/test.dtb: Warning (avoid_default_addr_size): Relying on default #address-cells value for /chosen/chosen-test
arch/sandbox/dts/test.dtb: Warning (avoid_default_addr_size): Relying on default #size-cells value for /chosen/chosen-test
Alexey Brodkin [Wed, 24 Jan 2018 17:47:09 +0000 (20:47 +0300)]
fdt: Implement weak arch_fixup_fdt()
Only ARM and in some configs MIPS really implement arch_fixup_fdt().
Others just use the same boilerplate which is not good by itself,
but what's worse if we try to build with disabled CONFIG_CMD_BOOTM
and enabled CONFIG_OF_LIBFDT we'll hit an unknown symbol which was
apparently implemented in arch/xxx/lib/bootm.c.
Now with weak arch_fixup_fdt() right in image-fdt.c where it is
used we get both items highlighted above fixed.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com> Cc: Daniel Schwierzeck <daniel.schwierzeck@gmail.com> Cc: Simon Glass <sjg@chromium.org> Cc: York Sun <york.sun@nxp.com> Cc: Stefan Roese <sr@denx.de> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
Marek Vasut [Fri, 16 Feb 2018 23:57:49 +0000 (00:57 +0100)]
net: sh_eth: Fix DT base address fetching
Drop the whole map/unmap_physmem stuff and just use the address
already obtained from DT in ofdata_to_platdata(), instead of
repeating that, wrongly, in probe.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com> Cc: Nobuhiro Iwamatsu <iwamatsu@nigauri.org> Cc: Joe Hershberger <joe.hershberger@ni.com>
Marek Vasut [Sat, 17 Feb 2018 01:16:48 +0000 (02:16 +0100)]
ARM: rmobile: Fix broken reset code on Porter
The 'reset' command did not work on Porter because the reset code
was accessing the wrong PMIC address over broken I2C bus driver.
Replace the code with DM-aware code and fix up the PMIC address.
This makes the 'reset' command work again.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com> Cc: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
Marek Vasut [Sat, 17 Feb 2018 01:15:08 +0000 (02:15 +0100)]
ARM: rmobile: Replace SH I2C with IIC on Porter
Get rid of the SH I2C driver on Porter and enable the IIC driver
instead . The old SH I2C is completely broken on Porter anyway
and the DM/DT capable IIC driver allows access to the PMIC too.
Use the DM/DT capable driver instead.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com> Cc: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
Marek Vasut [Fri, 16 Feb 2018 23:35:23 +0000 (00:35 +0100)]
ARM: rmobile: Reset ethernet PHY
Toggle the PHY reset GPIO to bring the ethernet PHY out of reset properly.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com> Cc: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
---
NOTE: This should be moved to the SH ethernet driver, but it's quite
late in the cycle, so this is something to be done in 2018.05.
With multiple environments, the 'get_char' callback for env
drivers does not really make sense any more because it is
only supported by two drivers (eeprom and nvram).
To restore single character loading for these drivers,
override 'env_get_char_spec'.
Signed-off-by: Simon Goldschmidt <sgoldschmidt@de.pepperl-fuchs.com> Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
York Sun [Wed, 7 Feb 2018 22:17:11 +0000 (14:17 -0800)]
env: Fix env_load_location
Commit 7d714a24d725 ("env: Support multiple environments") added
static variable env_load_location. When saving environmental
variables, this variable is presumed to have the value set before.
In case the value was set before relocation and U-Boot runs from a
NOR flash, this variable wasn't writable. This causes failure when
saving the environment. To save this location, global data must be
used instead.
Signed-off-by: York Sun <york.sun@nxp.com> CC: Maxime Ripard <maxime.ripard@free-electrons.com>
Marek Vasut [Fri, 16 Feb 2018 00:33:27 +0000 (01:33 +0100)]
ARM: rmobile: Convert Porter to SPL
Due to size limitations of the MERAM, switch U-Boot to SPL.
The SPL is loaded by the SPI_LOADER into MERAM and then loads
U-Boot proper into DRAM. This way U-Boot can freely grow in
size in DRAM, as there is plenty of it.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com> Cc: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
---
NOTE: To update U-Boot, first install u-boot.img to 0x140000 in SPI NOR,
then use the Minimon to flash u-boot-spl.srec using ls,2,e6304000.
To generate u-boot-spl.srec, use objcopy:
arm-linux-gnueabi-objcopy -O srec spl/u-boot-spl u-boot-spl.srec
Marek Vasut [Fri, 16 Feb 2018 00:33:27 +0000 (01:33 +0100)]
ARM: dts: rmobile: Make PFC and RST available before reloc
Those two nodes are needed to configure pinmux before relocation
and to configure clock before relocation, since CPG/MSSR needs
access to RST node. This is not noticable on Gen3, but on Gen2
this causes problems in SPL if they are not available early.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com> Cc: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
Marek Vasut [Tue, 13 Feb 2018 16:21:15 +0000 (17:21 +0100)]
net: ravb: Initialize PHY in probe() once
Reset and initialize the PHY once in the probe() function rather than
doing it over and over again is start() function. This requires us to
keep the clock enabled while the driver is in use. This significantly
reduces the time between transfers as the PHY doesn't have to restart
autonegotiation between transfers, which takes forever.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com> Cc: Geert Uytterhoeven <geert+renesas@glider.be> Cc: Joe Hershberger <joe.hershberger@ni.com>
Alexander Graf [Thu, 15 Feb 2018 14:50:54 +0000 (15:50 +0100)]
RPi: Add myself as board maintainer
Commit 958d55f26ce ("MAINTAINERS: Take over BCM2835 maintainership") put
me in as maintainer for the RPi soc, but forgot to update the board
MAINTAINERS file.
arm: socfpga: use imply instead of select where applicable
Kconfig should only 'select' features that are required for an arch.
Standard features that can be disabled without breaking board support
should use 'imply' instead, to allow users to disable it.
These options are changed for mach-socfpga:
- DM_SPI & DM_SPI_FLASH: only required with QSPI support enabled
- SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION: the boot rom supports a
partitionless mode also, where SPL is located at address 0
- HW_WATCHDOG: while all mainline board defconfigs use it, U-Boot
should still work without it.
Signed-off-by: Simon Goldschmidt <sgoldschmidt@de.pepperl-fuchs.com>
Lukasz Majewski [Tue, 13 Feb 2018 05:34:13 +0000 (06:34 +0100)]
Convert socfpga: select CONFIG_HW_WATCHDOG support for ARCH_SOCFPGA
All Socfpga boards from ./include/configs/socfpga_* define
CONFIG_HW_WATCHDOG.
To ease CONFIG_HW_WATCHDOG conversion to Kconfig select it in
config ARCH_SOCFPGA (arch/arm/Kconfig) section.
Signed-off-by: Lukasz Majewski <lukma@denx.de> Signed-off-by: Simon Goldschmidt <sgoldschmidt@de.pepperl-fuchs.com>
This patch adds "spi-flash" to the compatible list of the qspi flash
chip for all socfpga boards. This is required to make qspi work on
these boards on top of the recent fixes. Without the "spi-flash"
compatible string for the flash chip, the speed cannot be read and a
speed of 0Hz is used (which results in a divide-by-zero on these
boards).
Signed-off-by: Simon Goldschmidt <sgoldschmidt@de.pepperl-fuchs.com>
Alexey Brodkin [Thu, 15 Feb 2018 12:34:58 +0000 (15:34 +0300)]
arc: Fix final linkage with Elf32 tools
ARC Elf32 tools by default enable usage of so-called "small data"
section or in ARC PRM parlance "GP-relative addressing".
The idea is to put up to 2kB of frequently used data into a separate
location and use indirect addressing via dedicated core register (GP).
Where GP is used as a base for offset calculation.
And so if "-msdata" toggle is passed to the compiler either explicitly
or implicitly (that's Elf32 tools case) it will try to put some data
in that "small data" area and then to calculate real offset from GP
to be encoded in instructions we need to know the base value which
liker gets from __SDATA_BEGIN__ symbol in hte linker script.
In U-Boot we don't use that feature and linker script doesn't define
__SDATA_BEGIN__ which gives us the following linkage error if we use
Elf32 tools:
------------------------->8-------------------
LD u-boot
.../bin/arc-elf32-ld.bfd: Error: Linker symbol __SDATA_BEGIN__ not found
.../bin/arc-elf32-ld.bfd: final link failed: Bad value
------------------------->8-------------------
Note if uClibc or glibc tools are used that problem doesn't happen
because usage of "small data section" is disabled by default as not very
useful for bigger executables. Moreover GP is just another name of r26
so we're loosing 1 core register which is not used by the compiler as a
generic register with "-msdata".
Faiz Abbas [Thu, 15 Feb 2018 11:42:11 +0000 (17:12 +0530)]
usb: host: xhci-omap: Remove redundant board_usb_init and board_usb_cleanup functions
board_usb_init()/_cleanup() should be in board files and don't have
a place in the xhci-omap driver. Weak versions for
board_usb_init()/_cleanup() already exist in common/usb.c
(for host mode) and drivers/usb/gadget/g_dnl.c (for gadget mode).
Therefore, remove init and cleanup functions from xhci-omap and
implement them in the board files.
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com> Reviewed-by: Marek Vasut <marex@denx.de> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Alexey Brodkin [Wed, 31 Jan 2018 14:56:59 +0000 (17:56 +0300)]
usb: dwc2: Rename CONFIG_DWC2_UTMI_PHY_WIDTH to CONFIG_DWC2_UTMI_WIDTH
For some reason from day one we used to have both CONFIG_DWC2_UTMI_WIDTH
mentioned in dwc2.h and in scripts/config_whitelist.txt but never really used
and CONFIG_DWC2_UTMI_PHY_WIDTH used in real code in dwc2.c (but never
defined).
Moreover even though CONFIG_DWC2_UTMI_WIDTH might be either 8 or 16
depending on hardware (and the same is said in a comment for it in
dwc2.h) but then 8 is hardcoded in the header leaving no ability to
override this value in board's configuration.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com> Cc: Marek Vasut <marex@denx.de>
spl: unbreak CONFIG_SPL_MULTI_DTB_FIT after fixing CONFIG_OF_EMBED
With commit 9bd76b807636 ("spl: make CONFIG_OF_EMBED pass dts through
fdtgrep"), CONFIG_SPL_MULTI_DTB_FIT has been broken because
cmd_fdtgrep was now unknown in scripts/Makefile.spl after moving
it to dts/Makefile. This bug has been introduced with v2018.01.
This patch moves cmd_fdtgrep from dts/Makefile to scripts/Makefile.lib
and includes scripts/Makefile.lib in scripts/Makefile.spl.
Fixes: 9bd76b807636 ("spl: make CONFIG_OF_EMBED pass dts through fdtgrep") Reported-by: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Simon Goldschmidt <sgoldschmidt@de.pepperl-fuchs.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
Andre Heider [Fri, 9 Feb 2018 07:10:22 +0000 (08:10 +0100)]
arm/PSCI: support PSCI versions greater than 1.0
ATF recently began announcing PSCI v1.1. Since that version is unknown
to u-boot, the PSCI device nodes were not updated.
Switch from the case statement to a greater/less-than comparison so that
v1.1, as well as future versions, get at least the compatible nodes of
known versions.
PSCI v1.1 doesn't seem to have introduced a new corresponding compatible.
projects / u-boot / log