Currently the setbrg logic of serial-mtk is messy, and should be rewritten.
Also an option is added to make it possible to use highspeed-3 mode for all
bauds.
The new logic is:
1. If baud clock > 12MHz
a) If baud <= 115200, highspeed-0 mode will be used (ns16550 compatible)
b) If baud <= 576000, highspeed-2 mode will be used
c) any bauds > 576000, highspeed-3 mode will be used
2. If baud clock <= 12MHz
Forced highspeed-3 mode
a) If baud <= 115200, calculates the divisor using DIV_ROUND_CLOSEST
b) any bauds > 115200, the same as 1. c)
Signed-off-by: Weijie Gao <weijie.gao@mediatek.com>
The EPHY LEDs of mt7629 can be used as JTAG. This patch adds the jtag pin
group to the pinctrl driver.
Signed-off-by: Weijie Gao <weijie.gao@mediatek.com>
The mtk pinctrl driver is a combination driver with support for both
pinctrl and gpio. When this driver is used in SPL, gpio support may not be
enabled, and this will result in a compilation error.
To fix this, macros are added to make sure gpio related code will only be
compiled when gpio support is enabled.
Signed-off-by: Weijie Gao <weijie.gao@mediatek.com>
This is a bug fix for mtk pinctrl common part. Appearently pins should be
used instead of grps in mtk_get_pin_name().
Signed-off-by: Sam Shih <sam.shih@mediatek.com>
Renesas RZ/G2E (a.k.a. r8a774c0) is pin compatible with R-Car
E3 (a.k.a. r8a77990), however it doesn't have several automotive
specific peripherals.
This patch hooks R8A774C0 SoC with the pfc driver.
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com>
Sync the R8A77990 SoC PFC tables with Linux 5.11 , commit f40ddce88593.
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com>
- stm32mp1_trusted_defconfig rely on SCMI support
- Remove the nand MTD configuration for NOR boot in stm32mp1 board
- STM32programmer update
- Bsec: manage clock when present in device tree
- stm32mp15: move bootdelay configuration in defconfig
- Update for stm32 dsi and dw_mipi_dsi
- STM32 MCU's cleanup
- Fix compilation issue depending on SYS_DCACHE_OFF and SYS_ICACHE_OFF flags
- Update stm32mp1 doc
-----BEGIN PGP SIGNATURE-----
iQJQBAABCgA6FiEEXyrViUccKBz9c35Jysd4L3sz/6YFAmBLfA8cHHBhdHJpY2Uu
Y2hvdGFyZEBmb3NzLnN0LmNvbQAKCRDKx3gvezP/pkNnD/4hQrwBdaJMz9YXL4Tp
0W7kpCcTkG+gINY06BONNnKzBHq62SkWMo/lw9iF0nlcNKSOHzrz6ttm+e54ngs0
qe/dn0yjgImDfr5p5JRMTG1m7/XwQpucZ8wowSZAwt5f/DDh9eta9AyST0ev+iXI
Eqgbk5HsF2OCOK6h74FJidZUdLMLw+uQkIwPhglx3ZaxxFfXHAdWtXtJ9Fky2adU
BC0PltvJ6KYl1LTUGCQvrCST1sNe1PXPHrcsUpsQnqUSZ65tGKgeH2On9Exsw6cE
eA5v0aiQSMmAH2pYXrJwxhSW9b03yt3NdBQd09Du2YUuFe7yZeoWIFy8mM9jRaov
QDe88aJ9ZjxB+TvYQPToEL0EIyBGkN3HnX05BtKzKLf+E2+wP6gEf/6Sob7fBf6n
3n2Eud0COfe06hNiocYOHm8n/8bZxdmuEgMA8LU0PZETbH33NlvJtrjyBxY4OHOV
G+RG6J8idpVWWQ69g2TqfsVhXSjF893nvLOu0+KjuNrZWG4BVxGjylVUSvayk7bG
TI++ZKlbdvJGweZ3uUPcNLH4VaX47P/nZS/6vX1uL7NtRNvv3jLHN5z4t6zKI9rh
3iTJxxVv3zilWcY1WsoSdUvK56RTubnNwUlpjriabdRwMDjMN0isL9N06PvOELoi
jU1IkKBLtMvPbb2XfLRIjvQjTQ==
=nIJc
-----END PGP SIGNATURE-----
Merge tag 'u-boot-stm32-20210312' of https://source.denx.de/u-boot/custodians/u-boot-stm
- Add WATCHDOG_RESET() in MTD framework and STM32 QSPI driver
- stm32mp1_trusted_defconfig rely on SCMI support
- Remove the nand MTD configuration for NOR boot in stm32mp1 board
- STM32programmer update
- Bsec: manage clock when present in device tree
- stm32mp15: move bootdelay configuration in defconfig
- Update for stm32 dsi and dw_mipi_dsi
- STM32 MCU's cleanup
- Fix compilation issue depending on SYS_DCACHE_OFF and SYS_ICACHE_OFF flags
- Update stm32mp1 doc
Adds support for a working SCP03 emulation. Input parameters are
validated however the commands (enable, provision) executed by the TEE
are assumed to always succeed.
Signed-off-by: Jorge Ramirez-Ortiz <jorge@foundries.io>
Reviewed-by: Simon Glass <sjg@chromium.org>
Fix the warning:
drivers/tpm/tpm2_tis_sandbox.c: In function ‘sandbox_tpm2_xfer’:
drivers/tpm/tpm2_tis_sandbox.c:288:48: warning: format ‘%ld’ expects
argument of type ‘long int’, but argument 2 has type ‘size_t’
{aka ‘unsigned int’} [-Wformat=]
printf("TPM2: Unmatching length, received: %ld, expected: %d\n",
~~^
%d
send_size, length);
~~~~~~~~~
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
With of-platdata we always have a dtv struct that holds the platform data
provided by the driver_info record. However, this struct can be empty if
there are no actual devicetree properties provided.
The upshot of empty platform data is that it will end up as a zero-size
member in the BSS section, which is fine. But if the driver specifies
plat_auto then it expects the correct amount of space to be allocated.
At present this does not happen, since device_bind() assumes that the
platform-data size will always be >0. As a result we end up not
allocating the space and just use the BSS region, overwriting whatever
other contents are present.
Fix this by removing the condition that platform data be non-empty, always
allocating space if requested.
This fixes a strange bug that has been lurking since of-platdata was
implemented. It has likely never been noticed since devices normally have
at least some devicetree properties, BSS is seldom used on SPL, the dtv
structs are normally at the end of bss and the overwriting only happens
if a driver changes its platform data.
It was discovered using sandbox_spl, which exercises more features than
a normal board might, and the critical global_data variable 'gd' happened
to be at the end of BSS.
Fixes: 9fa2819009 ("dm: core: Expand platdata for of-platdata devices")
Signed-off-by: Simon Glass <sjg@chromium.org>
Config option ARMADA_39X is never set so remove all dead code hidden under
ifdef CONFIG_ARMADA_39X blocks.
Also remove useless checks for CONFIG_ARMADA_38X define as this macro is
always defined for a38x code path.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
Marvell Armada 3720 Functional Errata, Guidelines, and Restrictions
document describes in erratum 4.1 PCIe value of vendor ID (Ref #: 243):
The readback value of VEND_ID (RD0070000h [15:0]) is 1B4Bh, while it
should read 11ABh.
The firmware can write the correct value, 11ABh, through VEND_ID
(RD0076044h [15:0]).
Implement this workaround in U-Boot PCIe controller driver aardvark for
both PCI vendor id and PCI subsystem vendor id.
This change affects PCI vendor id of PCIe root bridge emulated by Linux
kernel. With this change Linux kernel reports correct vendor id 11AB.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
The arrays `pbs_dq_mapping`, `div_ratio1to1` and `div_ratio2to1` have
different bounds declared in header files where these variables are also
defined from the ones declared in source files.
This causes the compiler to complain (when building with LTO):
ddr3_sdram.c:24:12: warning: type of ‘pbs_dq_mapping’ does not match
original declaration
[-Wlto-type-mismatch]
ddr3_patterns_64bit.h:911:5: note: array types have different bounds
ddr3_patterns_64bit.h:911:5: note: ‘pbs_dq_mapping’ was previously
declared here
ddr3_dfs.c:45:11: warning: type of ‘div_ratio1to1’ does not match
original declaration [-Wlto-type-mismatch]
ddr3_axp_vars.h:167:4: note: array types have different bounds
ddr3_axp_vars.h:167:4: note: ‘div_ratio1to1’ was previously declared
here
ddr3_dfs.c:46:11: warning: type of ‘div_ratio2to1’ does not match
original declaration [-Wlto-type-mismatch]
ddr3_axp_vars.h:196:4: note: array types have different bounds
ddr3_axp_vars.h:196:4: note: ‘div_ratio2to1’ was previously declared
here
CI managed to trigger this as an error when compiling with LTO for AXP.
Fix this by using values from the header files, which seem to be the
correct ones.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
In arch/arm/mach-mvebu/dram.c we always include axp's xor.h for common
XOR definitions, regardless whether we compile for axp or a38x.
But the declaration of this function has a different signature in axp's
xor.h from the one used in a38x' implementation - one parameter is u64
instead of u32. This can result in wrong argument's being passed to that
function on a38x with no one the wiser.
I discovered this when building U-Boot for Turris Omnia with LTO. The
compiler complains about the different signatures being thrown into the
same linking process:
axp/xor.h:67:5: warning: type of ‘mv_xor_mem_init’ does not match
original declaration [-Wlto-type-mismatch]
67 | int mv_xor_mem_init(u32 chan, u32 start_ptr, u32 block_size,
| ^
a38x/xor.c:165:5: note: type mismatch in parameter 3
165 | int mv_xor_mem_init(u32 chan, u32 start_ptr, unsigned long long
| ^
a38x/xor.c:165:5: note: type ‘long long unsigned int’ should match
type ‘u32’
Fix this by changing the type of the block_size argument in the axp's
implementation and header file to the one used in a38x (and upstream
mv-ddr-marvell).
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>
This syncs drivers/ddr/marvell/a38x/ with the master branch of repository
https://github.com/MarvellEmbeddedProcessors/mv-ddr-marvell.git up to the
commit 7c351731d196 ("Merge pull request #29 from pali/sync-a38x-uboot").
This patch was created by following steps:
1. Replace all a38x files in U-Boot tree by files from upstream github
Marvell mv-ddr-marvell repository.
2. Run following command to omit portions not relevant for a38x and ddr3:
files=drivers/ddr/marvell/a38x/*
sed 's/#if defined(CONFIG_ARMADA_38X) || defined(CONFIG_ARMADA_39X)/#ifdef TRUE/' -i $files
unifdef -m -UMV_DDR -UMV_DDR_ATF -UCONFIG_DDR4 -UCONFIG_APN806 \
-UCONFIG_MC_STATIC -UCONFIG_MC_STATIC_PRINT -UCONFIG_PHY_STATIC \
-UCONFIG_PHY_STATIC_PRINT -UCONFIG_CUSTOMER_BOARD_SUPPORT \
-UCONFIG_A3700 -UA3900 -UA80X0 -UA70X0 -DTRUE $files
3. Manually omit SPDX-License-Identifier changes from this patch as
upstream license in upstream github repository contains long license
texts and U-Boot is using just SPDX-License-Identifier.
After applying this patch, a38x ddr3 code in upstream Marvell github
repository and in U-Boot would be fully identical. So in future applying
above steps could be used to sync code again.
The only change in this patch is removal of dead code and some fixes with
include files.
Signed-off-by: Pali Rohár <pali@kernel.org>
Tested-by: Chris Packham <judge.packham@gmail.com>
Reviewed-by: Stefan Roese <sr@denx.de>
commit 258be123226f8f5cd516b7813fe201fb7d7416e9 upstream.
At this moment, only page 0 of SPD is being read but to support
smbios, we need to read page 1 also which has more info. In order
to do that, we need to allocate more space.
Signed-off-by: Sujeet Baranwal <sujeet.baranwal@cavium.com>
Tested-by: sa_ip-sw-jenkins <sa_ip-sw-jenkins@marvell.com>
Reviewed-by: Sujeet Kumar Baranwal <Sujeet.Baranwal@cavium.com>
Reviewed-by: Nadav Haklai <nadavh@marvell.com>
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Tested-by: Chris Packham <judge.packham@gmail.com>
The DSI phy can be turned on from the DSI digital interface in
the dphy_enable() function or from a dedicated DSI phy "wrapper"
in phy_ops->init() function. If the STM32MP1 case, the wrapper
is used then the dphy_enable() "warning" traces are not relevant.
This patch moves these "warning" traces to "debug" traces so
they are still available for DSI phy based on the digital
interface in debug logging mode, but not there in normal mode
for both cases.
Note: The related Linux kernel driver uses a "debug"
message too.
Signed-off-by: Yannick Fertre <yannick.fertre@foss.st.com>
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Acked-by: Yannick Fertre <yannick.fertre@foss.st.com>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Remove the child device of the STM32 DSI bridge when the driver probe
failed to stop futher probe request on panels used with STMicroelectronics
board (orisetech_otm8009a.c or raydium-rm68200.c driver).
This patch avoid the trace "cannot get reset GPIO" when
STM32MP157 device tree is used on stm32MP151 SOC without DSI support.
In this hw_version value is 0, as DSI bridge is absent and the panel
ofdata_to_platdata is called for each try of panel probe,
the gpio reset pin is requested but after dsi father probe failed).
For the next request, the PANEL ofdata_to_platdata failed as the gpio
is already used.
Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reorder include files in expected order.
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Define LOG_CATEGORY to allow filtering with log command.
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Include the file needed for log function prototype, this patch solves the
compilation issue for undefined reference to `dev_err'.
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
This change makes stm32mp1 clock driver to get the root clocks
reference from the device node in the FDT rather than fetching
straight these clocks by their name. Driver now stores the
clock reference and use it to know if a root clock is present,
get its rate or gets its related udevice reference.
Signed-off-by: Etienne Carriere <etienne.carriere@st.com>
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
In case of big area read/write on spi nand, watchdog timeout may occurs.
To fix that, add WATCHDOG_RESET() in spinand_mtd_read() and
spinand_mtd_write() to ensure that watchdog is reset.
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
In case of big area erased on nand, watchdog timeout may occurs.
To fix that, add WATCHDOG_RESET() in nanddev_mtd_erase() to ensure that
watchdog is reset.
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
In case of reading large area and memory-map mode is misconfigured
(memory-map size declared lower than the real size of the memory chip)
watchdog can be triggered.
Add WATCHDOG_RESET() in _stm32_qspi_read_fifo to fix it.
Issue reproduced with stm32mp157c-ev1 board and memory map size set to
1, with following command:
sf read 0xC0000000 0 0x4000000
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
In case of big area write/erase on spi nor, watchdog timeout may occurs.
Issue reproduced on stm32mp157c-ev1 with following commands:
sf write 0xC0000000 0 0x3000000
or
sf erase 0 0x1000000
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
When flush cache of the current GPD and resume QMU, the controller
will try to access the next GPD after processing the current one,
if not flush the next GPD, the controller may get wrong GPD status.
Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
This option is better placed in the x86 code since it is not generic
enough to be in the core code. Move it.
Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
[bmeng: fixed a typo in arch/x86/Kconfig]
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Fix the treshold typo in code by threshold.
Fixes: c0165c85c3 ("button: add a simple Analog to Digital Converter device based button driver")
Suggested-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Acked-by: Marek Szyprowski <m.szyprowski@samsung.com>
sysreset uclass driver provides an implementation of 'reset'
command using the sysreset_ APIs unconditionally. It also
supports the 'poweroff' command using the sysreset_ APIs,
but under a Kconfig option CONFIG_SYSRESET_CMD_POWEROFF.
Let's do the same for the 'reset' command, by introducing a
new Kconfig option CONFIG_SYSRESET_CMD_RESET, and set it to
on by default, to allow a board that don't have a sysreset
reset driver yet, but have a sysreset poweroff driver to
compile without any issue.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>
dev_read_addr_size_index() returns fdt_addr_t which might be a
64-bit physical address. This might be true for some 85xx SoCs
whose CCSBAR is mapped beyond 4 GiB.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>
The VirtIO BLK driver depends on the blk uclass driver.
Add the dependency in the Kconfig.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>
At present the driver only supports 32-bit bus and cpu address.
The controller's outbound registers/fields for extended address
are not programmed. Let's program them to support 64-bit bus and
cpu address.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Heiko Schocher <hs@denx.de>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>
devfdt_get_addr_index() returns fdt_addr_t which might be a 64-bit
physical address. Use map_physmem() to return the virtual address
that can be used by a 32-bit machine.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Heiko Schocher <hs@denx.de>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>
For the QEMU ppce500 machine, LAW registers are not implemented
hence CONFIG_FSL_LAW is not turned on and all LAW APIs are not
available. We should wrap all LAW registers programming in the
mpc85xx PCI driver with CONFIG_FSL_LAW.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Heiko Schocher <hs@denx.de>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>
Commit e002474158 ("pci: pci-uclass: Dynamically allocate the PCI regions")
changes 'struct pci_controller'.regions from pre-allocated array of
regions to dynamically allocated, which unfortunately broken lots of
boards that still use the non-DM PCI driver.
This patch changes the non-DM fsl_pci_init driver to dynamically
allocate the regions, just like what's done in the pci uclass driver.
Fixes: e002474158 ("pci: pci-uclass: Dynamically allocate the PCI regions")
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>
-----BEGIN PGP SIGNATURE-----
iGwEABECACwWIQSC4hxrSoIUVfFO0kRM6ATMmsalXAUCYEE0zg4cYWd1c3RAZGVu
eC5kZQAKCRBM6ATMmsalXMQWAJ4pwG2oykEwa+BEC5JUrJ9B/QWa+wCeP1HwJS5N
siPaX+vgDLOqTg1Y/T4=
=0Dow
-----END PGP SIGNATURE-----
Merge tag 'next-2021-03-04' of https://gitlab.denx.de/u-boot/custodians/u-boot-video into next
- convert sunxi_display to DM_VIDEO
A working device tree node of ns16550 should never be populated
with value zero for the <clock-frequency> property. Unfortunately
this is the case for the QEMU ppce500 target.
Let's try to assign plat->clock to CONFIG_SYS_NS16550_CLK as the
last resort to handle such case.
This commit should be reverted when:
- The following QEMU patch [1] is merged, and
- U-Boot CI has upgraded its QEMU version that contains the fix
[1] http://patchwork.ozlabs.org/project/qemu-devel/patch/1612362288-22216-2-git-send-email-bmeng.cn@gmail.com/
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Currently ns16550_serial_assign_base() treats the argument 'base'
with type `ulong`. This is incorrect because the base address was
obtained from device tree with type `fdt_addr_t` that can represent
a physical address larger than 32-bit in a 32-bit system.
Fixes: 9e6ce62190 ("serial: ns16550: Fix ordering of getting base address")
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Each invocation of the 'host bind' command with a file name argument opens
a file descriptor. The next invocation of the 'host bind' command destroys
the block device but the file descriptor remains open. The same holds true
for the 'unbind blk' command.
Close the file descriptor when unbinding the host block device.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
At present device_bind() does some unnecessary work if a device fails to
bind in SPL. Add the missing conditions.
Also fix a style nit in the same function while we are here.
Signed-off-by: Simon Glass <sjg@chromium.org>
With of-platdata we always have a dtv struct that holds the platform data
provided by the driver_info record. However, this struct can be empty if
there are no actual devicetree properties provided.
The upshot of empty platform data is that it will end up as a zero-size
member in the BSS section, which is fine. But if the driver specifies
plat_auto then it expects the correct amount of space to be allocated.
At present this does not happen, since device_bind() assumes that the
platform-data size will always be >0. As a result we end up not
allocating the space and just use the BSS region, overwriting whatever
other contents are present.
Fix this by removing the condition that platform data be non-empty, always
allocating space if requested.
This fixes a strange bug that has been lurking since of-platdata was
implemented. It has likely never been noticed since devices normally have
at least some devicetree properties, BSS is seldom used on SPL, the dtv
structs are normally at the end of bss and the overwriting only happens
if a driver changes its platform data.
It was discovered using sandbox_spl, which exercises more features than
a normal board might, and the critical global_data variable 'gd' happened
to be at the end of BSS.
Fixes: 9fa2819009 ("dm: core: Expand platdata for of-platdata devices")
Signed-off-by: Simon Glass <sjg@chromium.org>
Using the internal vs. external pull resistors it is possible to get
27 different combinations from 3 strapping pins. Add an implementation
of this.
This involves updating the sandbox GPIO driver to model external and
(weaker) internal pull resistors. The get_value() method now takes account
of what is driving a pin:
sandbox: GPIOD_EXT_DRIVEN - in which case GPIO_EXT_HIGH provides the
value
outside source - in which case GPIO_EXT_PULL_UP/DOWN indicates the
external state and we work the final state using those flags and
the internal GPIOD_PULL_UP/DOWN flags
Of course the outside source does not really exist in sandbox. We are just
modelling it for test purpose.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add a new flag to keep track of whether sandbox is driving the pin, or
whether it is expecting an input signal. If it is driving, then the value
of the pin is the value being driven (0 or 1). If not driving, then we
consider the value 0, since we don't currently handle things like pull-ups
yet.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
