Python3 taken from the PATH causes build issues when pylibfdt bindings are
generated with Yocto SDK.
Python3 provided as a part of SDK is not compatible with host Python3,
therefore binding build breaks with following errors:
scripts/dtc/pylibfdt/libfdt_wrap.c:154:11: fatal error: Python.h: No such file or directory
154 | # include <Python.h>
| ^~~~~~~~~~
Do not enforce the python3 from the PATH and make it conditionally-assigned
so it can be overridden from outside of build system. Keep the default
assignment to point to version that is taken from the PATH.
Similar fix has been introduced in b48bfc74ee ("tools: allow to override
python"), where conditional assignment is used for python executable to
address similar build errors.
Signed-off-by: Andrey Zhizhikin <andrey.zhizhikin@leica-geosystems.com> Cc: Simon Glass <sjg@chromium.org> Fixes: e91610da7c ("kconfig: re-sync with Linux 4.17-rc4") Reviewed-by: Simon Glass <sjg@chromium.org>
- Add base support for Marvell OcteonTX2 CN9130 DB (mostly done
by Kostya)
- Sync Armada 8k MMU setup with Marvell version (misc Marvell
authors)
- spi: kirkwood: Some fixes especially for baudrate generation
(misc Marvell authors)
- mvebu: x530: Reduce SPL image size (Stefan)
- Rename "rx_training" to "mvebu_comphy_rx_training" (Stefan)
Andre Przywara [Wed, 5 May 2021 12:51:03 +0000 (13:51 +0100)]
usb: musb-new: Extend and move Allwinner quirk into Kconfig
All newer Allwinner SoCs (since about 2013) miss the CONFIGDATA register
in their MUSB implementation, so they need a quirk to hardcode this.
Currently this quirk depends on listing the SoCs affected in musb_reg.h,
which means that this list needs to grow with every new chip.
Move the quirk feature into Kconfig, next to PIO_ONLY, and change the
default to y (for Allwinner builds), while listing the early
implementations as exceptions.
This fixes USB peripheral operation on some newer SoCs, which were not
explicitly listed before.
Tested on H6, H616, R40 (which were broken before), and also on the H5
and A20, for regressions.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
This patch adds the base support for the Marvell Octeon TX2 CN913x DB.
Only one defconfig is added with this patch. Other board variants are
available (NAND, MMC booting) and images for these boards can be
generated by following the documentation added in the included README.
Signed-off-by: Konstantin Porotchkin <kostap@marvell.com> Signed-off-by: Stefan Roese <sr@denx.de>
arm: octeontx2: Add dtsi/dts files for Octeon TX2 CN913x DB
This patch adds the dtsi/dts files needed to support the Marvell
Octeon TX2 CN913x DB. This is only the base port with not all
interfaces supported fully.
Signed-off-by: Konstantin Porotchkin <kostap@marvell.com> Signed-off-by: Stefan Roese <sr@denx.de>
Stefan Roese [Wed, 5 May 2021 07:15:10 +0000 (09:15 +0200)]
cmd: mvebu: Rename rx_training to mvebu_comphy_rx_training
Rename the misleading cmd "rx_training" to "mvebu_comphy_rx_training" to
avoid confusion and mixup with DDR3/4 training. This makes it clear,
that this command is platform specific and handles the COMPHY RX
training.
Also depend this cmd on ARMADA_8K and not TARGET_MVEBU_ARMADA_8K to make
is available for OcteonTX2 CN913x.
Signed-off-by: Stefan Roese <sr@denx.de> Cc: Pali Rohár <pali@kernel.org> Cc: Marek Behun <marek.behun@nic.cz> Cc: Kostya Porotchkin <kostap@marvell.com> Cc: Nadav Haklai <nadavh@marvell.com> Acked-by: Marek Behún <marek.behun@nic.cz> Acked-by: Pali Rohár <pali@kernel.org>
Marcin Wojtas [Fri, 30 Apr 2021 13:33:15 +0000 (15:33 +0200)]
pcie: designware: mvebu: do not configure ATU for IO when not used
The pcie_dw_mvebu configure ATU regions for memory, configuration
and IO space types. However the latter is not obligatory
and when not specified in the device tree, causes wrong
ATU configuration. Fix that by adding a dependency on the
detected PCIE regions count.
arm64: mvebu: do not map firmware RT service region
There is region left by ATF, which needs to remain in memory to provide RT
services. To prevent overwriting it by u-boot, do not provide any mapping
for this memory region, so any attempt to access it will trigger
synchronous exception.
Update sr 2021-04-12:
Don't update armada3700/cpu.c mmu table, as this has specific changes
included in mainline.
Signed-off-by: Grzegorz Jaszczyk <jaz@semihalf.com> Signed-off-by: Stefan Roese <sr@denx.de>
After commit 1fe929ed497bcc8975be8d37383ebafd22b99dd2
("spi: kirkwood: prevent configuring speed exceeding max controller freq")
the spi frequency could be set to 0 on platform where spi-max-frequency
is not defined (e.g. on armada-388-gp). Prevent limiting speed in
mentioned cases.
Signed-off-by: Grzegorz Jaszczyk <jaz@semihalf.com> Tested-by: Kostya Porotchkin <kostap@marvell.com> Reviewed-by: Marcin Wojtas <marcin@marvell.com> Reviewed-by: Kostya Porotchkin <kostap@marvell.com> Signed-off-by: Stefan Roese <sr@denx.de>
Ken Ma [Fri, 30 Apr 2021 13:26:29 +0000 (15:26 +0200)]
spi: kirkwood: support extended baud rates
The Armada SoC family implementation of this SPI hardware module has
extended the configuration register to allow for a wider range of SPI
clock rates. Specifically the Serial Baud Rate Pre-selection bits in the
SPI Interface Configuration Register now also use bits 6 and 7 as well.
Modify the baud rate calculation to handle these differences for the
Armada case. Potentially a baud rate can be setup using a number of
different pre-scalar and scalar combinations. This code tries all
possible pre-scalar divisors (8 in total) to try and find the most
accurate set.
Signed-off-by: Ken Ma <make@marvell.com> Signed-off-by: Stefan Roese <sr@denx.de>
Neil Armstrong [Wed, 5 May 2021 07:52:08 +0000 (09:52 +0200)]
net: dwmac_meson8b: do not set TX delay in TXID & RXID
When the PHY interface is set as TXID & RXID, the delays should be taken from DT,
but first they should not be hardcoded since the PHY driver will set them.
Fixes: 798424e857 ("net: designware: add Amlogic Meson8b & later glue driver") Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
Vincent Chen [Mon, 3 May 2021 07:26:49 +0000 (15:26 +0800)]
pwm: sifive: make set_config() and set_enable() work properly
The pwm_sifive_set_config() and pwm_sifive_set_enable() cannot work
properly due to the wrong implementations. It will cause the u-boot
PWM command to not work as expected. The bugs will be resolved in this
patch.
Signed-off-by: Vincent Chen <vincent.chen@sifive.com> Reviewed-by: Rick Chen <rick@andestech.com>
Sean Anderson [Fri, 9 Apr 2021 02:13:08 +0000 (22:13 -0400)]
clk: Add support for the k210 clock driver pre-relocation
Variables which had previously been stored in .bss are moved to .data. In
addition, probed needs to be reset when the clock driver is re-bound
post-relocation.
Sean Anderson [Fri, 9 Apr 2021 02:13:05 +0000 (22:13 -0400)]
clk: k210: Fix PLL enable always getting taken
This conditional always evaluated as false, regardless of the value of reg.
Fix it so that it properly tests the bits in the PLL register. Also test
PLL_EN, now that we set it.
Reported-by: Damien Le Moal <Damien.LeMoal@wdc.com> Signed-off-by: Sean Anderson <seanga2@gmail.com>
Sean Anderson [Fri, 9 Apr 2021 02:13:03 +0000 (22:13 -0400)]
clk: Warn on failure to assign rate
If the user/dev explicitly requests a clock be assigned a certain rate,
then we should warn them if we can't do it. This makes it clear if the
clock is running at the default rate.
Kory Maincent [Tue, 4 May 2021 17:31:27 +0000 (19:31 +0200)]
arm: sunxi: add support for DIP detection to CHIP board
Add the extension_board_scan specific function to scan the information
of the EEPROM on one-wire and fill the extension struct.
Add the Kconfig symbol to enable the needs to detect DIPs.
Signed-off-by: Kory Maincent <kory.maincent@bootlin.com> Reviewed-by: Maxime Ripard <maxime@cerno.tech> Acked-by: Andre Przywara <andre.przywara@arm.com>
Kory Maincent [Tue, 4 May 2021 17:31:26 +0000 (19:31 +0200)]
w1: replace dt detection by automatic detection
This patch changes the functioning of the detection of w1 devices.
The old way was a comparison between detected w1 and the ones described in
the device tree. Now it will just look for the driver matching the family
id of the w1 detected.
The patch is inspired from Maxime Ripard code.
Signed-off-by: Kory Maincent <kory.maincent@bootlin.com> Reviewed-by: Maxime Ripard <maxime@cerno.tech>
Kory Maincent [Tue, 4 May 2021 17:31:24 +0000 (19:31 +0200)]
ti/common: add support for extension_scan_board function
The BeagleBone platforms all use a common mechanism to discover and
identify extension boards (called "capes"): each extension board has an
I2C-connected EEPROM describing itself.
This patch implements a generic extension_scan_board() feature that can
be used by all BeagleBone platforms to read those I2C EEPROMs and fill
in the list of "extension" structures.
Following commits will enable this common logic on two BeagleBone
platforms.
Kory Maincent [Tue, 4 May 2021 17:31:23 +0000 (19:31 +0200)]
pytest: add sandbox test for "extension" command
This commit extends the sandbox to implement a dummy
extension_board_scan() function and enables the extension command in
the sandbox configuration. It then adds a test that checks the proper
functionality of the extension command by applying two Device Tree
overlays to the sandbox Device Tree.
Signed-off-by: Kory Maincent <kory.maincent@bootlin.com>
[trini: Limit to running on sandbox] Signed-off-by: Tom Rini <trini@konsulko.com>
Kory Maincent [Tue, 4 May 2021 17:31:22 +0000 (19:31 +0200)]
cmd: add support for a new "extension" command
This patch adds a new "extension" command, which aims at detecting
extension boards connected to the hardware platform, and apply the
Device Tree overlays that describe the hardware present on those
extension boards.
In order to enable this mechanism, board-specific code must implement
the extension_board_scan() function that fills in a linked list of
"struct extension", each describing one extension board. In addition,
the board-specific code must select the SUPPORT_EXTENSION_SCAN Kconfig
boolean.
Based on this:
- "extension scan" makes the generic code call the board-specific
extension_board_scan() function to retrieve the list of detected
extension boards.
- "extension list" allows to list the detected extension boards.
- "extension apply <number>|all" allows to apply the Device Tree
overlay(s) corresponding to one, or all, extension boards
The latter requires two environment variables to exist and set one variable
to run:
- extension_overlay_addr: the RAM address where to load the Device
Tree overlays
- extension_overlay_cmd: the U-Boot command to load one overlay.
Indeed, the location and mechanism to load DT overlays is very setup
specific.
- extension_overlay_name: set by the command: the name of the DT which
will be load during the execution.
When calling the command described in the extension_overlay_cmd
variable, the variable extension_overlay_name will be defined. So a
typical extension_overlay_cmd will look like this:
Here is an example on how to use it:
=> run loadfdt
=> fdt addr $fdtaddr
=> setenv extension_overlay_addr 0x1000
=> setenv extension_overlay_cmd 'load mmc 0:1 ${extension_overlay_addr} /boot/${extension_overlay_name}'
=> extension scan
Found 1 extension board(s).
=> extension apply 0
519 bytes read in 3 ms (168.9 KiB/s)
Signed-off-by: Kory Maincent <kory.maincent@bootlin.com> Reviewed-by: Maxime Ripard <maxime@cerno.tech>
Marek Vasut [Sat, 3 Apr 2021 14:58:49 +0000 (16:58 +0200)]
ARM: renesas: Scrub duplicate memory nodes from DT on Gen3
Scrub duplicate /memory@* node entries here. Some R-Car DTs might
contain multiple /memory@* nodes, however fdt_fixup_memory_banks()
either generates single /memory node or updates the first /memory
node. Any remaining memory nodes are thus potential duplicates.
However, it is not possible to delete all the memory nodes right
away, since some of those might not be DRAM memory nodes, but some
sort of other memory. Thus, delete only the memory nodes which are
in the R-Car3 DBSC ranges.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Marek Vasut [Wed, 12 May 2021 19:34:11 +0000 (21:34 +0200)]
ARM: rmobile: Add missing rcar-common/common.c to Beacon RZG2M kit
The rcar-common/common.c contains various common board functions shared
by all R-Car and RZG boards. This board is not compiling the file in, so
add it. This way, part of the board code can be de-duplicated too.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com> Cc: Adam Ford <aford173@gmail.com>
net: ti: am65-cpsw-nuss: Prepare to support non primary ext port
CPSW NUSS IP on K3 SoCs can have more than one external port (upto 8)
Therefore increase AM65_CPSW_CPSWNU_MAX_PORTS to 9 (8 ext + 1 Root port)
as preparation to allow any one of the 8 ports to be used as ethernet
interface in U-Boot.
soc: ti: k3-navss-ringacc: Remove unused ring modes
With AM64x supporting only K3_NAV_RINGACC_RING_MODE_RING or the exposed
ring mode, all other K3 SoCs have also been moved to this common
baseline. Therefore drop other modes such as
K3_NAV_RINGACC_RING_MODE_MESSAGE (and proxy) to save on SPL footprint.
There is a saving of ~800 bytes with this change for am65x_evm_r5_defconfig.
soc: ti: k3-navss-ringacc: Add AM64 ringacc support
AM64 dual mode rings are modeled as pair of Rings objects which has common
configuration and memory buffer, but separate real-time control register
sets for each direction mem2dev (forward) and dev2mem (reverse).
AM64 rings must be requested only using k3_ringacc_request_rings_pair(),
and forward ring must always be initialized/configured. After this any
other Ringacc APIs can be used without any callers changes.
Lokesh Vutla [Thu, 6 May 2021 11:14:59 +0000 (16:44 +0530)]
arm: dts: am642-sk: Add initial sk dts
AM642 StarterKit (SK) board is a low cost, small form factor board
designed for TI’s AM642 SoC. It supports the following interfaces:
* 2 GB LPDDR4 RAM
* x2 Gigabit Ethernet interfaces capable of working in switch and MAC mode
* x1 USB 3.0 Type-A port
* x1 UHS-1 capable µSD card slot
* 2.4/5 GHz WLAN + Bluetooth 4.2 through WL1837
* 512 Mbit OSPI flash
* x2 UART through UART-USB bridge
* XDS110 for onboard JTAG debug using USB
* Temperature sensors, user push buttons and LEDs
* 40-pin Raspberry Pi compatible GPIO header
* 24-pin header for peripherals in MCU island (I2C, UART, SPI, IO)
* 54-pin header for Programmable Realtime Unit (PRU) IO pins
* Interface for remote automation. Includes:
* power measurement and reset control
* boot mode change
Lokesh Vutla [Thu, 6 May 2021 11:14:55 +0000 (16:44 +0530)]
include: configs: Update env for selecting right dtb
Now that single defconfig can be used for booting AM64 EVM and SK,
default device tree will not work for selecting dtb for kernel.
Update the env to select right dtb based on eeprom.
Lokesh Vutla [Thu, 6 May 2021 11:14:49 +0000 (16:44 +0530)]
board: ti: am64x: Add support for reading eeprom data
I2C EEPROM data contains the board name and its revision.
Add support for:
- Reading EEPROM data and store a copy at end of SRAM
- Updating env variable with relevant board info
- Printing board info during boot.
Dave Gerlach [Tue, 4 May 2021 23:00:53 +0000 (18:00 -0500)]
arm: mach-k3: am642: Add support for triggering ddr init from SPL
In SPL, DDR should be made available by the end of board_init_f()
so that apis in board_init_r() can use ddr. Adding support for
triggering DDR initialization from board_init_f().
Dave Gerlach [Tue, 11 May 2021 15:22:12 +0000 (10:22 -0500)]
ram: k3-ddrss: Introduce support for AM642 SoCs
Introduce support for the AM64 DDRSS controller which uses the 16bit
variation of the controller. This controller shares much functionality
with the existing J721e support, so this patch introduces only the new
code needed for am64 specific support from "_16bit_" files with headers
under "16bit/" include path/.
Also add a CONFIG_K3_AM64_DDRSS option to the choice required for use
with CONFIG_K3_DDRSS to allow selecting AM64 support.
Dave Gerlach [Tue, 11 May 2021 15:22:11 +0000 (10:22 -0500)]
ram: k3-ddrss: Introduce common driver with J7 SoC support
Introduce a new version of the ddr driver which has the ability to
support different variations of the controller. Also introduce support
for the 32bit variation of the controller which is what was already
supported by the previous version used for J721e and J7200.
Create a new CONFIG_K3_DDRSS option to select the common parts of the
k3-ddrss driver. Also introduce a choice that depends on the top level
option to select CONFIG_K3_J721E_DDRSS for j721e support, and update
corresponding Kconfig as required.
Fix the indentation for certain macros to be consistent with the other
macros in the file, as the existing indentation does not make sense in
many places.
Fix the indentation for certain macros to be consistent with the other
macros in the file, as the existing indentation does not make sense in
many places.
Fix the indentation for certain macros to be consistent with the other
macros in the file, as the existing indentation does not make sense in
many places.
Fix the indentation for certain macros to be consistent with the other
macros in the file, as the existing indentation does not make sense in
many places.
projects / u-boot.git / log