This board has not been converted to CONFIG_DM_PCI by the deadline.
Remove it.
Cc: Ilya Yanok <yanok@emcraft.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
These boards have not been converted to CONFIG_DM_PCI, CONFIG_DM_USB or
in some cases CONFIG_DM itself by the deadline. Remove them.
Cc: Priyanka Jain <priyanka.jain@nxp.com>
Cc: Ruchika Gupta <ruchika.gupta@nxp.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
This board has not been converted to CONFIG_DM_MMC by the deadline.
Remove it.
Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
These board has not been converted to CONFIG_DM_PCI by the deadline.
Remove them. As this is the last of the mcf547x_8x family of boards,
remove that support as well.
Cc: TsiChung Liew <Tsi-Chung.Liew@nxp.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
These board has not been converted to CONFIG_DM_PCI by the deadline.
Remove them. As this is all of the CONFIG_M548x platforms as well,
remove that code.
Cc: TsiChung Liew <Tsi-Chung.Liew@nxp.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
With the ventana boards migrated to DM_PCI and DM_ETH, we can remove
this prototype.
Cc: Stefano Babic <sbabic@denx.de>
Signed-off-by: Tom Rini <trini@konsulko.com>
- Move to gcc-11.1.0 builds from kernel.org for supported platforms and
LLVM-11 for those tests.
- As Heinrich has noted, the RISC-V platform specification has a profile
OS-A for running rich operating systems like Linux and BSD. This profile
requires 64bit and UEFI conforming to the EBBR. Only the 'embedded'
profile may use 32bit. Given this, drop grub for 32bit RISC-V as it no
longer compiles with gcc-11.1 and upstream is unlikely to fix it:
https://www.mail-archive.com/grub-devel@gnu.org/msg30736.html
- Update to grub-2.06 release to address other issues of building with
gcc-11.1.
- Update to newer Xtensa (gcc-9.2.0) and ARC (gcc-10.2) toolchains
Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Bin Meng <bmeng.cn@gmail.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Rick Chen <rick@andestech.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
With x86 we can execute an option ROM either natively or using the
x86 emulator (if enabled with CONFIG_BIOSEMU). Both of these share
the _X86EMU_env variable, with the native code using it to hold
register state during interrupt processing.
At present, in 32-bit U-Boot, the variable is declared twice, once
in common code and once in code only compiled with CONFIG_BIOSEMU.
With GCC 11 this causes a 'multiple definitions' error on boards
with CONFIG_BIOSEMU.
Drop the emulator definition when CONFIG_BIOSEMU is used.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
When we do not have bootstage enabled, rather than include an empty
dummy function, we just don't reference it. This saves us space in some
tight builds. This also shows a few cases where show_boot_progress was
incorrectly guarded before.
Cc: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>
Follow what the Linux Kernel does here and disable the
'zero-length-bounds', 'array-bounds' and 'stringop-overflow' warnings
here.
This brings in commits 5c45de21a2223, 44720996e2d79 and 5a76021c2eff7
from the Linux Kernel.
Signed-off-by: Tom Rini <trini@konsulko.com>
With gcc-11 we get a multiple errors here as the declarations for
mscc_pinctrl_ops and mscc_gpio_ops are missing an extern.
CC: Gregory CLEMENT <gregory.clement@bootlin.com>
Cc: Lars Povlsen <lars.povlsen@microchip.com>
Cc: Horatiu Vultur <horatiu.vultur@microchip.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Horatiu Vultur <horatiu.vultur@microchip.com>
Reviewed-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
The board code here references the display_width / display_height
variables set in the video driver, declare these as externs as gcc-11
will notice and lead to a multiple definition error.
Signed-off-by: Tom Rini <trini@konsulko.com>
In some board cpld.h files the definition of the cpld_data struct
not-quite makes a typedef for cpld_data_t. This problem is caught with
gcc-11 as a multiple definition error. As there are no users of this
non-typedef, fix this by not declaring it one to begin with.
Cc: Priyanka Jain <priyanka.jain@nxp.com>
Cc: Shengzhou Liu <Shengzhou.Liu@nxp.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
With gcc-11 we see:
drivers/ddr/marvell/a38x/ddr3_debug.c:672:47: error: argument 2 of type 'u32[5]' {aka 'unsigned int[5]'} with mismatched bound [-Werror=array-parameter=]
672 | int ddr3_tip_read_adll_value(u32 dev_num, u32 pup_values[MAX_INTERFACE_NUM * MAX_BUS_NUM],
| ~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from drivers/ddr/marvell/a38x/ddr3_training_ip_engine.h:10,
from drivers/ddr/marvell/a38x/ddr3_init.h:17,
from drivers/ddr/marvell/a38x/ddr3_debug.c:6:
drivers/ddr/marvell/a38x/ddr3_training_ip_flow.h:116:47: note: previously declared as 'u32[]' {aka 'unsigned int[]'}
And similar warnings. Correct these by updating the prototype. Remove
the prototype for ddr3_tip_read_pup_value as it is unused.
Signed-off-by: Tom Rini <trini@konsulko.com>
-----BEGIN PGP SIGNATURE-----
iQFQBAABCgA6FiEEqxhEmNJ6d7ZdeFLIHrMeAg6sL8gFAmDkSkAcHGV1Z2VuLmhy
aXN0ZXZAbWljcm9jaGlwLmNvbQAKCRAesx4CDqwvyD24B/9t87hFqWovJvVAcoUT
JoTqFblplE4Sckssy0cQyR7sRpzuZEaakUeAxaLFecBN6Tn30YJEG3hNpEDCLEbA
hn/oiZ4hQ3JA9Yu2SHepQi0fLqdAjkQtMXy57o3Mk20GBLtPtpdItUHxg3iyeMSj
Ny1mm/KjL6ltmNeGfYfeqRf435Rm718DB94wCZTgS9woYe3Z5YRDNBPyL7u27hpY
2WiyvvU9EA12mjGYdEt5sCqnTQZFtHHlEWNHz4a3db6HkcPV7pfr+SpTNJjcFhIg
O7VN7yUTwnV0UGu5IXTWcZqFIqJkLPbPX5cvkSBnnaGge4e0K3Cw36Nv/EqCY8LX
gWfu
=Ru8k
-----END PGP SIGNATURE-----
Merge tag 'u-boot-atmel-fixes-2021.10-a' of https://source.denx.de/u-boot/custodians/u-boot-atmel
First set of u-boot-atmel fixes for 2021.10 cycle:
This small fixes set is dedicated to fixing the onewire subsystem for
the at91 boards which was broken since 2020.04.
Previous device tree for OpenPiton emits a warning during compilation.
This commit fixes the previous warning adds dts to the OpenPiton RISC-V
board and added the device tree to MAINTAINER file.
Signed-off-by: Tianrui Wei <tianrui-wei@outlook.com>
Reported-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
- mpc8379erdb DM_USB, DM_PCI and DM_ETH support.
- Drop PCI support from the integrator family of boards
- Add synquacer support
- Assorted lpc32xx updates and improvements
- snapdragon (and related) fixes, Broadcom iproc update
At the moment, the U-Boot serial_msm driver does not initialize the
UART_DM_DMEN register with the required value. Usually this does not
cause any problems, because there is Qualcomm's LK bootloader running
before U-Boot which initializes the register with the correct value.
It's important that this register is initialized correctly, because
the U-Boot driver does not make use of the BAM/DMA or single character
mode functionality of the UART controller. A different bootloader
before U-Boot might initialize the register differently.
For example, on DragonBoard 410c U-Boot can also be installed to the
"aboot" partition (replacing LK entirely). In this case U-Boot is
loaded directly by SBL, which seems to use the single-character mode
for some reason. In single character mode there is always just one
char in the FIFO, instead of the 4 characters expected by
msm_serial_fetch(). It also causes issues with "earlycon" later in
the Linux kernel, which tries to output 4 chars at once,
but only the first char will be written.
This causes early UART log in Linux to be corrupted like this:
[ 00ano:ameoi .Q1B[ 00ac _idaM00080oo'ahani-lcle._20). 15NdNii 5 SPMSJ20:U2
[ 00rkoolmsamel
[ 00Fw ]elamletopsioble
[ 00ore
instead of
[ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd030]
[ 0.000000] Machine model: Qualcomm Technologies, Inc. APQ 8016 SBC
[ 0.000000] earlycon: msm_serial_dm0 at MMIO 0x00000000078b0000 (options '')
[ 0.000000] printk: bootconsole [msm_serial_dm0] enabled
Make sure to initialize UART_DM_DMEN correctly to fix this issue
when loading U-Boot directly after SBL (instead of through LK).
There is no functional difference when loading U-Boot through LK
since LK also initializes UART_DM_DMEN to 0x0. [1]
[1]: https://git.linaro.org/landing-teams/working/qualcomm/lk.git/tree/platform/msm_shared/uart_dm.c?h=dragonboard410c-LA.BR.1.2.7-03810-8x16.0-linaro3#n203
Cc: Ramon Fried <rfried.dev@gmail.com>
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
It looks like SD card detection is broken at the moment for DB410c.
The eMMC is detected correctly, but the SD card is not.
This is probably similar to the issue fixed in commit 8505147403
("mmc: msm_sdhci: Use mmc_of_parse for setting host_caps") for eMMC,
except that the SD card does not have a property like "non-removable"
that skips the card detection.
The SDHCI on DB410c cannot detect itself if a SD card is inserted,
so add the necessary cd-gpios to make SD card detection work again.
While at it, fix the #gpio-cells for the soc_gpios to avoid DTC
warnings - the soc_gpios are actually already used with two cells
for the gpio-leds so this was just wrong all the time.
Cc: Ramon Fried <rfried.dev@gmail.com>
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
The GICC register used by u-boot is 0x0a20c000, which is actually a GICC
for WCNSS, the WLAN processor. U-boot runs on the Application Processor,
therefore it should use APCS GICC instead. Hence, correct it with APCS GICC
register address.
Signed-off-by: Sheep Sun <sunxiaoyang2003@gmail.com>
Enable a DMed i2c driver for the ea-lpc3250devkitv2 board.
Include some sample commands/output for testing.
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
Convert the CONFIG_SYS_I2C_LPC32XX configuration symbol from an include
directive to a Kconfig value.
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Add the of_match/compatible string to the lpc32xx i2c driver so it works
correctly with device-tree.
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
The lpc32xx driver was not obtaining the per-device base address correctly
from the device tree. Fix the FIXME in order to get the correct base address.
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
Add basic support for running U-Boot on the Embedded Artists LPC3250
Developer's Kit v2 board by launching U-Boot from the board's s1l loader
(which comes pre-installed on the board).
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
Import the dtsi, dts, and clock binding files for the lpc32xx ea3250 board
directly and unmodified from the latest Linux kernel.
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
There's nothing special or unique to the lpc32xx that requires its own config
parameter for specifying the console uart index. Therefore instead of using
the lpc32xx-specific CONFIG_SYS_LPC32XX_UART include parameter, use the
already-available CONFIG_CONS_INDEX from Kconfig.
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Enable EFI capsule update support. With the EFI capsule update,
you can update U-Boot, TF-A and OP-TEE. TF-A and OP-TEE are
usually combined as a FIP binary, but if the binary is bigger
than 480KB, you have to modify FIP header, split the OP-TEE
and stores the OP-TEE binary in the different place. This
configuration supports both cases.
Signed-off-by: Masami Hiramatsu <masami.hiramatsu@linaro.org>
Since the EDK2 GenerateCapsule script is out of date and it
doesn't generate the supported version capsule file, the document
should refer the mkeficapsule in tools.
Signed-off-by: Masami Hiramatsu <masami.hiramatsu@linaro.org>
Add the DeveloperBox 96boards EE support. This board is also
known as Socionext SynQuacer E-Series. It contians one "SC2A11"
SoC, which has 24-cores of arm Cortex-A53, and 4 DDR3 slots,
3 PCIe slots (1 4x port and 2 1x ports which are expanded via
PCIe bridge chip), 2 USB 3.0 ports and 2 USB 2.0 ports, 2 SATA
ports and 1 GbE, 64MB NOR flash and 8GB eMMC on standard
MicroATX Form Factor.
For more information, see this page;
https://www.96boards.org/product/developerbox/
Signed-off-by: Masami Hiramatsu <masami.hiramatsu@linaro.org>
Add device trees for 96boards EE DeveloperBox and basement SynQuacer
SoC dtsi. These files are imported from EDK2
commit 83d38b0b4c0f240d4488c600bbe87cea391f3922
as-is (except for the changes #include path and some macros).
And add U-Boot specific changes in synquacer-sc2a11-developerbox-u-boot.dtsi
Signed-off-by: Masami Hiramatsu <masami.hiramatsu@linaro.org>
This is a driver for the HSSPI SPI controller on SynQuacer SoC.
The HSSPI has command sequence mode (memory mapped) and
direct mode (FIFO access). The driver will operate it under
the direct mode. And before booting OS, it switch back to the
command sequence mode since that is compatible with default
EDK2 behavior.
Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
Signed-off-by: Masami Hiramatsu <masami.hiramatsu@linaro.org>
Add ECAM based SynQuacer PCIe RC driver. This driver configures the
PCIe RC and filter out a ghost pcie config.
Since the Linux kernel expects "socionext,synquacer-pcie-ecam" device
is configured by firmware (EDK2), it doesn't re-configure in the kernel.
So as same as EDK2, U-Boot needs to configure it before boot the kernel.
Signed-off-by: Masami Hiramatsu <masami.hiramatsu@linaro.org>
Since some SoCs and boards do not hae extra asm/arch/gpio.h,
introduce CONFIG_GPIO_EXTRA_HEADER instead of adding
!define(CONFIG_ARCH_XXXX) in asm/gpio.h.
Signed-off-by: Masami Hiramatsu <masami.hiramatsu@linaro.org>
Without this fix, scsi-scan will cause a synchronous abort
when accessing ops->scan.
Signed-off-by: Masami Hiramatsu <masami.hiramatsu@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Add support for 1.3GHz, 1.35GHz and 1.4GHz parts. This is based on
equivalent code in Broadcom's LDK 5.0.6.
Signed-off-by: Chris Packham <judge.packham@gmail.com>
We didn't convert the Integrator to use DM for PCI in
time, and we don't use it either so let's just drop
PCI support from the Integrator.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
In commit 1e4687aa47 ("binman: Use target-specific tools when
cross-compiling"), a utility function was implemented to get preferred
compilation tools using environment variables like CC and CROSS_COMPILE.
Although it intended to provide custom default tools (same as those in
the global Makefile) when no relevant variables were set (for example
using "gcc" for "cc"), it is only doing so when CROSS_COMPILE is set and
returning the literal name of the tool otherwise.
Remove the check for an empty CROSS_COMPILE, which makes the function
use it as an empty prefix to the custom defaults and return the intended
executables.
Fixes: 1e4687aa47 ("binman: Use target-specific tools when cross-compiling")
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
This patch adds a limited pulse-width modulator to sandbox's Chromium OS
Embedded Controller emulation. The emulated PWM device supports multiple
channels but can only set a duty cycle for each, as the actual EC
doesn't expose any functionality or information other than that. Though
the EC supports specifying the PWM channel by its type (e.g. display
backlight, keyboard backlight), this is not implemented in the emulation
as nothing in U-Boot uses this type specification.
This emulated PWM device is then used to test the Chromium OS PWM driver
in sandbox. Adding the required device node to the sandbox test
device-tree unfortunately makes it the first PWM device, so this also
touches some other tests to make sure they still use the sandbox PWM.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Each _device_ belonging to a given uclass of course has its own ->ops,
of a type determined by and known to the uclass.
However, no instance of a uclass_driver seems to populate ->ops, and
the only reference to it in code is this relocation.
Moreover, it's not really clear what could sensibly be assigned; it
would have to be some "struct uclass_ops *" providing a set of methods
for the core to call on that particular uclass, but should the need
for that ever arise, it would be better to have a member of that
particular type instead of void*.
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Reviewed-by: Simon Glass <sjg@chromium.org>
