Simon Glass [Fri, 5 Feb 2021 04:22:01 +0000 (21:22 -0700)]
gpio: sandbox: Fully separate pin value from output value
At present we have the concept of a pin's external value. This is what
is used when getting the value of a pin. But we still set the
GPIOD_IS_OUT_ACTIVE flag when changing the value. This is not actually
correct, since if the pin changes from output to input, the external
value need not change. Adjust the logic for this difference.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Simon Glass [Fri, 5 Feb 2021 04:22:00 +0000 (21:22 -0700)]
gpio: sandbox: Use a separate flag for the value
At present with the sandbox GPIO driver it is not possible to change the
value of GPIOD_IS_OUT_ACTIVE unless the GPIO is an output. This makes it
hard to test changing the flags since we need to be aware of the internal
workings of the driver.
The feature is designed to aid testing.
Split this feature out into a separate sandbox-specific flag, so that the
flags can change unimpeded. This will make it easier to allow updating the
flags in a future patch.
Simon Glass [Fri, 5 Feb 2021 04:21:59 +0000 (21:21 -0700)]
gpio: sandbox: Rename GPIO dir_flags to flags
Adjust the terminology in this driver to reflect that fact that all flags
are handled, not just direction flags.
Create a new access function to get the full GPIO state, not just the
direction flags. Drop the static invalid_dir_flags since we can rely on a
segfault if something is wrong.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Simon Glass [Fri, 5 Feb 2021 04:21:56 +0000 (21:21 -0700)]
dm: gpio: Rename get_dir_flags() method to get_flags()
It is more useful to be able to read all the flags, not just the direction
ones. In fact this is what the STM32 driver does. Update the method name
to reflect this.
Tweak the docs a little and use 'flagsp' as the return argument, as is
common in driver model, to indicate it returns a value.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com> Reviewed-by: Pratyush Yadav <p.yadav@ti.com>
Simon Glass [Sat, 6 Feb 2021 21:23:42 +0000 (14:23 -0700)]
tpm: Allow disabling platform hierarchy with TPM2
With TPM2 we don't actually lock the TPM once verified boot is finished.
Instead we disable the platform hierarchy which serves the same purpose.
Add an implementation of this so we can safely boot into the kernel.
Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Simon Glass [Sat, 6 Feb 2021 21:23:37 +0000 (14:23 -0700)]
tpm: Add a basic API implementation for TPMv2
Add support for TPMv2 versions of API functions. So far this is not
complete as the standard is quite large, but it implements everything
currently available for TPMv2 in U-Boot.
Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Simon Glass [Sat, 6 Feb 2021 21:23:36 +0000 (14:23 -0700)]
tpm: Switch TPMv1 over to use the new API
Take over the plain 'tpm_...' functions for use by the new TPM API. Rename
all the TPMv1 functions so they are called from the API.
Update the TPMv1 functions so that they are called from the API. Change
existing users to use the tpm1_ prefix so they don't need to go through
the API, which might introduce uncertainty.
Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Simon Glass [Sat, 6 Feb 2021 21:23:35 +0000 (14:23 -0700)]
tpm: Add an API that can support v1.2 and v2
There are two different TPM standards. U-Boot supports both but each has
its own set of functions. We really need a single TPM API that can call
one or the other. This is not always possible as there are some
differences between the two standards, but it is mostly possible.
Add an API to handle this. So far it is not plumbed into the build and
only supports TPMv1.
Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Simon Glass [Sat, 6 Feb 2021 16:57:33 +0000 (09:57 -0700)]
sandbox: Avoid using malloc() for system state
This state is not accessible to the running U-Boot but at present it is
allocated in the emulated SDRAM. This doesn't seem very useful. Adjust
it to allocate from the OS instead.
The RAM buffer is currently not freed, but should be, so add that into
state_uninit(). Update the comment for os_free() to indicate that NULL is
a valid parameter value.
Note that the strdup() in spl_board_load_image() is changed as well, since
strdup() allocates memory in the RAM buffer.
Simon Glass [Sat, 6 Feb 2021 16:57:32 +0000 (09:57 -0700)]
sandbox: Add os_realloc()
We provide os_malloc() and os_free() but not os_realloc(). Add this,
following the usual semantics. Also update os_malloc() to behave correctly
when passed a zero size.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Simon Glass [Sat, 6 Feb 2021 16:57:31 +0000 (09:57 -0700)]
s5p4418_nanopi2: Drop dead code
This code is still using the old command typedef. It was not noticed since
this file is not currently built. It is using a non-existent option in the
Makefile.
Drop this file since it is not needed for correct operation.
Simon Glass [Sat, 6 Feb 2021 16:57:30 +0000 (09:57 -0700)]
doc: Add a note about producing 'md.b' output using hexdump
Comparing a hex dump on the U-Boot command line with the contents of a
file on the host system is fairly easy and convenient to do manually if
it is small. But the format used hexdump by default differs from that
shown by U-Boot. Add a note about how to make them the same.
(For large dumps, writing the data to the network with tftpput, or to a
USB stick with ext4save is easiest.)
Simon Glass [Sat, 6 Feb 2021 16:57:27 +0000 (09:57 -0700)]
spl: Drop duplicate 'Jumping to U-Boot' message
This is printed twice but we only need one message, since there is very
little processing in between them. Drop the second one, since all branches
of the switch() already have output. Update the U-Boot message to include
the phase being jumped to.
arm: cp15: update DACR value to activate access control
Update the initial value of Domain Access Control Register (DACR)
and set by default the access permission to client (DACR_Dn_CLIENT = 1U)
for each of the 16 domains and no more to all-supervisor
(DACR_Dn_MANAGER = 3U).
This patch allows to activate the domain checking in MMU against the
permission bits in the translation tables and avoids prefetching issue
on ARMv7 [1].
Today it was already done for OMAP2 architecture
./arch/arm/mach-omap2/omap-cache.c::arm_init_domains
introduced by commit de63ac278cba ("ARM: mmu: Set domain permissions
to client access") which fixes lot of speculative prefetch aborts seen
on OMAP5 secure devices.
arm: remove TTB_SECT_XN_MASK in DCACHE_WRITETHROUGH
The normal memory (other that DCACHE_OFF) should be executable by default,
only the device memory (DCACHE_OFF) used for peripheral access should have
the bit execute never (TTB_SECT_XN_MASK).
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
stm32mp: update the mmu configuration for SPL and prereloc
Overidde the weak function dram_bank_mmu_setup() to set the DDR
(preloc case) or the SYSRAM (in SPL case) executable before to enable
the MMU and configure DACR.
This weak function is called in dcache_enable/mmu_setup.
This patchs avoids a permission access issue when the DDR is marked
executable (by calling mmu_set_region_dcache_behaviour with
DCACHE_DEFAULT_OPTION) after MMU setup and domain access permission
activation with DACR in dcache_enable.
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Mark the top of ram, used for relocated U-Boot as a normal memory
(cacheable and executable) to avoid permission access issue when
U-Boot jumps to this relocated code.
When MMU is activated in pre-reloc stage; only the beginning of
DDR is marked executable.
This patch avoids access issue when DACR is correctly managed.
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Harald Seiler [Tue, 15 Dec 2020 15:47:52 +0000 (16:47 +0100)]
reset: Remove addr parameter from reset_cpu()
Historically, the reset_cpu() function had an `addr` parameter which was
meant to pass in an address of the reset vector location, where the CPU
should reset to. This feature is no longer used anywhere in U-Boot as
all reset_cpu() implementations now ignore the passed value. Generic
code has been added which always calls reset_cpu() with `0` which means
this feature can no longer be used easily anyway.
Over time, many implementations seem to have "misunderstood" the
existence of this parameter as a way to customize/parameterize the reset
(e.g. COLD vs WARM resets). As this is not properly supported, the
code will almost always not do what it is intended to (because all
call-sites just call reset_cpu() with 0).
To avoid confusion and to clean up the codebase from unused left-overs
of the past, remove the `addr` parameter entirely. Code which intends
to support different kinds of resets should be rewritten as a sysreset
driver instead.
This transformation was done with the following coccinelle patch:
The parameter passed to reset_cpu() no longer holds a meaning as all
call-sites now pass the value 0. Thus, branching on it is essentially
dead code and will just confuse future readers.
Revert soft-reset support and just always perform a hard-reset for now.
This is a preparation for removal of the reset_cpu() parameter across
the entire tree in a later patch.
Fixes: 576007aec9a4 ("lpc32xx: cpu: add support for soft reset") Cc: Sylvain Lemieux <slemieux@tycoint.com> Signed-off-by: Harald Seiler <hws@denx.de>
Harald Seiler [Tue, 15 Dec 2020 15:47:50 +0000 (16:47 +0100)]
board: ns3: Remove superfluous reset logic
The current implementation of reset_cpu() in the ns3 board code does not
archieve what it is supposed to (according to the comments), due to
a number of reasons:
1. The argument to reset_cpu() is _not_ actually passed from the
`reset` command, but is set to 0 in all call-sites (in this
specific case, see arch/arm/lib/reset.c). Thus, performing
different kinds of resets based on its value will not work as
expected.
2. Contrary to its documentation, the passed argument is not
interpreted, but a static `L3_RESET` define is used. The other
comment properly notes that this will always perform a L3 reset,
though.
3. The "parsing" of the static `L3_RESET` value is not even using the
upper and lower nibble as stated in the comment, but uses the last
two decimal digits of the value.
This is currently one of the only implementations left in U-Boot, which
make "use" of the value passed to reset_cpu(). As this is done under
false assumption (the value does not have any meaning anymore), it makes
sense to bring it into line with the rest and start ignoring the
parameter.
This is a preparation for removal of the reset_cpu() parameter across
the entire tree in a later patch.
Fixes: b5a152e7ca0b ("board: ns3: default reset type to L3") Cc: Bharat Gooty <bharat.gooty@broadcom.com> Cc: Rayagonda Kokatanur <rayagonda.kokatanur@broadcom.com> Signed-off-by: Harald Seiler <hws@denx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
Harald Seiler [Tue, 15 Dec 2020 15:47:49 +0000 (16:47 +0100)]
nds32: Remove dead reset_cpu() implementation
nds32 is one of the only architectures which still have a reset_cpu()
implementation that makes use of the `addr` parameter. The rest of
U-Boot now ignores it and passes 0 everywhere. It turns out that even
here, reset_cpu() is no longer referenced anywhere; reset is either not
implemented (e.g. ae3xx) or realized using a WDT (e.g. ag101).
Remove this left-over implementation in preparation for the removal of
the `addr` parameter in the entire tree.
Cc: Rick Chen <rick@andestech.com> Signed-off-by: Harald Seiler <hws@denx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Rick Chen <rick@andestech.com>
In drivers we use a family of printing functions including pr_err() and
pr_cont(). CONFIG_LOGLEVEL is used to control which of these lead to output
via printf().
Our logging functions allow finer grained control of output. So replace
printf() by the matching logging functions. The usage of CONFIG_LOGLEVEL
remains unchanged.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Tom Rini [Fri, 26 Feb 2021 17:41:06 +0000 (12:41 -0500)]
Merge tag 'u-boot-stm32-20210226' of https://gitlab.denx.de/u-boot/custodians/u-boot-stm
- Add USB host boot support in stm32mp1 config
- Enable uefi related commands for STMicroelectronics STM32MP15 boards
- Remove duplicate uart nodes in stm32mp15 device tree
efi_loader: limit output length for VenHw, VenMedia
VenHw and VenMedia device path nodes may carry vendor defined data of
arbitrary length. When converting a device path node to text ensure that we
do not overrun our internal buffer.
In our implementation of
EFI_DEVICE_PATH_TO_TEXT_PROTOCOL.ConvertDevicePathToText() we could first
determine the output length and then allocate buffers but that would nearly
double the code size. Therefore keep the preallocated buffers and truncate
excessive device paths instead.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Ilias Apalodimas [Fri, 26 Feb 2021 12:52:51 +0000 (14:52 +0200)]
configs: stm32mp1: enable uefi related commands
The board can boot with UEFI. With the latest changes in U-Boot's
EFI subsystem we also have support for EFI runtime variables, without
SetVariable support. We can also store the EFI variables in a file on the
ESP partition and preserve them across reboots.
The env and efidebug commands are missing in order to configure
EFI variables and the efibootmgr though. Since U-Boot's default config
enables other EFI related commands (e.g bootefi), let's add the env related
and efidebug commands and allow users to do that
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Patrick Delaunay [Wed, 24 Feb 2021 10:00:56 +0000 (11:00 +0100)]
arm: dts: stm32mp15: remove duplicate uart nodes
Remove duplicated uart nodes introduced with commit 62f95af92a3f
("ARM: dts: stm32mp1: DT alignment with Linux kernel v5.9-rc4"),
because the uart nodes wasn't correctly ordered in alphabetic order.
Only cosmetic: the generated device tree don't change.
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com> Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Stefan Brüns [Sat, 20 Feb 2021 16:26:06 +0000 (17:26 +0100)]
usb: kbd: Also accept keyboards with Interrupt OUT endpoint
The OUT endpoint can just be ignored as it is not used, just as the
corresponding Set_Report request for IN-only interfaces. E.g. the
Linux gadget hid keyboard also provides an interrupt endpoint.
Also cleanup confusing debug messages like "found set protocol", which
is printed when a keyboard device is found, while the Set_Protocol request
is issued quite some time later.
Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de>
Sean Anderson [Fri, 5 Feb 2021 14:39:02 +0000 (09:39 -0500)]
doc: Document partition specifications
This documents the way U-Boot understands partitions specifications.
This also updates the fastboot documentation for the changes in the
previous commit.
Signed-off-by: Sean Anderson <sean.anderson@seco.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Sean Anderson [Fri, 5 Feb 2021 14:39:01 +0000 (09:39 -0500)]
doc: Rename k210 partitions anchor
This anchor is only for the k210 partition layout, so rename it
appropriately. This keeps it from conflicting with the (to be added)
anchor for U-Boot partitions in general.
Signed-off-by: Sean Anderson <sean.anderson@seco.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Sean Anderson [Fri, 5 Feb 2021 14:39:00 +0000 (09:39 -0500)]
fastboot: Allow u-boot-style partitions
This adds support for partitions of the form "dev.hwpart:part" and
"dev#partname". This allows one to flash to eMMC boot partitions without
having to use CONFIG_FASTBOOT_MMC_BOOT1_SUPPORT. It also allows one to
flash to an entire device without needing CONFIG_FASTBOOT_MMC_USER_NAME.
Lastly, one can also flash MMC devices other than
CONFIG_FASTBOOT_FLASH_MMC_DEV.
Because devices can be specified explicitly, CONFIG_FASTBOOT_FLASH_MMC_DEV
is used only when necessary for existing functionality. For those cases,
fastboot_mmc_get_dev has been added as a helper function. This allows
There should be no conflicts with the existing system, but just in case, I
have ordered detection of these names after all existing names.
The fastboot_mmc_part test has been updated for these new names.
Signed-off-by: Sean Anderson <sean.anderson@seco.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Sean Anderson [Fri, 5 Feb 2021 14:38:58 +0000 (09:38 -0500)]
fastboot: Remove mmcpart argument from raw_part_get_info_by_name
The only thing mmcpart was used for was to pass to blk_dselect_hwpart.
This calls blk_dselect_hwpart directly from raw_part_get_info_by_name. The
error handling is dropped, but it is reintroduced in the next commit
(albeit less specificly).
Signed-off-by: Sean Anderson <sean.anderson@seco.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Sean Anderson [Fri, 5 Feb 2021 14:38:55 +0000 (09:38 -0500)]
part: Give several functions more useful return values
Several functions in disk/part.c just return -1 on error. This makes them
return different errnos for different failures. This helps callers
differentiate between failures, even if they cannot read stdout.
Signed-off-by: Sean Anderson <sean.anderson@seco.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Sean Anderson [Fri, 5 Feb 2021 14:38:54 +0000 (09:38 -0500)]
test: dm: Add test for fastboot mmc partition naming
This test verifies the mapping between fastboot partitions and partitions
as understood by U-Boot. It also tests the creation of GPT partitions,
though that is not the primary goal.
Signed-off-by: Sean Anderson <sean.anderson@seco.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Sean Anderson [Fri, 5 Feb 2021 14:38:53 +0000 (09:38 -0500)]
mmc: sandbox: Add support for writing
This adds support writing to the sandbox mmc backed by an in-memory
buffer. The unit test has been updated to test reading, writing, and
erasing. I'm not sure what MMCs erase to; I picked 0, but if it's 0xFF
then that can be easily changed.
Signed-off-by: Sean Anderson <sean.anderson@seco.com> Reviewed-by: Simon Glass <sjg@chromium.org>
- turris_mox: Enhancements, mostlly defconfig changes (Pali)
- pci-aardvark: Set Max Payload Size and Max Read Request Size
to 512 bytes (Pali)
- pci_mvebu: Minor cleanup and refactoring (Marek)
- Upgrade A38x DDR3 training to version 14.0.0 (Marek)
Reto Schneider [Thu, 11 Feb 2021 12:05:48 +0000 (13:05 +0100)]
mtd: nand: spi: Support GigaDevice GD5F1GQ5UExxG
The relevant changes to the already existing GD5F1GQ4UExxG support has
been determined by consulting the GigaDevice product change notice
AN-0392-10, version 1.0 from November 30, 2020.
As the overlaps are huge, variable names have been generalized
accordingly.
Apart form the lowered ECC strength (4 instead of 8 bits per 512 bytes),
the new device ID, and the extra quad IO dummy byte, no changes had to
be taken into account.
New hardware features are not supported, namely:
- Power on reset
- Unique ID
- Double transfer rate (DTR)
- Parameter page
- Random data quad IO
The inverted semantic of the "driver strength" register bits, defaulting
to 100% instead of 50% for the Q5 devices, got ignored as the driver has
never touched them anyway.
The no longer supported "read from cache during block erase"
functionality is not reflected as the current SPI NAND core does not
support it anyway.
Implementation has been tested on MediaTek MT7688 based GARDENA smart
Gateways using both, GigaDevice GD5F1GQ5UEYIG and GD5F1GQ4UBYIG.
Signed-off-by: Reto Schneider <reto.schneider@husqvarnagroup.com> Reviewed-by: Stefan Roese <sr@denx.de> Acked-by: Jagan Teki <jagan@amarulasolutions.com>
Hauke Mehrtens [Thu, 11 Feb 2021 12:05:47 +0000 (13:05 +0100)]
mtd: nand: spi: Only one dummy byte in QUADIO
The datasheet only lists one dummy byte in the 0xEB operation for the
following chips:
* GD5F1GQ4xExxG
* GD5F1GQ4xFxxG
* GD5F1GQ4UAYIG
* GD5F4GQ4UAYIG
Reto Schneider:
- Linux patch ported to U-Boot
- Checked for compatibility with GD5F1GQ4xBxxG
- Fixed operation code in original commit message (0xEH -> 0xEB)
Signed-off-by: Reto Schneider <reto.schneider@husqvarnagroup.com> Reviewed-by: Stefan Roese <sr@denx.de> Acked-by: Jagan Teki <jagan@amarulasolutions.com>
Sean Anderson [Fri, 5 Feb 2021 04:11:08 +0000 (23:11 -0500)]
mtd: spi-nor-core: Fix typo in documentation
This line should come before the docs for the next function.
Fixes: 7aeedac0153 ("mtd: spi: Port SPI NOR framework from Linux") Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Pratyush Yadav <p.yadav@ti.com> Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
Sean Anderson [Fri, 5 Feb 2021 04:11:07 +0000 (23:11 -0500)]
cmd: sf: Print error on test failure
The sf test command is used to test spi flashes (and spi masters). Printing
the exact error code is very helpful to those debugging the spi stack.
Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Pratyush Yadav <p.yadav@ti.com> Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
Sean Anderson [Fri, 5 Feb 2021 04:11:06 +0000 (23:11 -0500)]
cmd: sf: Display errno on erase failure
If there is an error while erasing SPI flash, no errno is displayed. This
makes it difficult to determine the cause of the error. This change mirrors
the logic for write errors above.
Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Pratyush Yadav <p.yadav@ti.com> Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
Adam Ford [Mon, 18 Jan 2021 21:32:49 +0000 (15:32 -0600)]
spi: nxp_fspi: Fix error reporting
On the i.MX8M Mini, ret = clk_set_rate() sets ret to the value of the
rate the clock was able to set. When checking for errors, it only
checks that it is not NULL. Since positive numbers are not errors,
only check for negative numbers when handling errors.
Fixes: 383fded70c4f ("spi: nxp_fspi: new driver for the FlexSPI controller") Signed-off-by: Adam Ford <aford173@gmail.com> Reviewed-by: Pratyush Yadav <p.yadav@ti.com> Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
Marek Behún [Fri, 19 Feb 2021 16:11:26 +0000 (17:11 +0100)]
ddr: marvell: a38x: fix comment in conditional macro
The code was processed with unifdef utility to omit portions not
relevant to A38x and DDR3. This removes usage of many macros, including
A70X0, A80X0 and A3900. It seems that the unifdef utility did not remove
the macros from #else comment.
Signed-off-by: Marek Behún <marek.behun@nic.cz> Tested-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
Marek Behún [Fri, 19 Feb 2021 16:11:25 +0000 (17:11 +0100)]
ddr: marvell: a38x: bump version to 14.0.0
Bump version of a38x DDR3 trianing to version 14.0.0 to reflect the
version in the mv-ddr-devel branch of upstream repository
https://github.com/MarvellEmbeddedProcessors/mv-ddr-marvell.git.
There is a new version numbering system, where after 18.12.0 came
1.0.0, 2.0.0, and so on until 14.0.0. So 14.0.0 is newer than 18.12.0.
Signed-off-by: Marek Behún <marek.behun@nic.cz> Tested-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
@pali suggested this change
In commit 6285efb ("mv_ddr: add support for twin-die combined memory
device") was added support for twin-die combined memory device and
default value for explicitly uninitialized structure members is zero, s
also twin_die_combined is initialized to zero. Which means COMBINED
value.
As prior this commit there was no support for twin-die combined memory
device, default value for twin_die_combined should be NOT_COMBINED. This
change change order of enum mv_ddr_twin_die to ensure that NOT_COMBINED
has value zero.
Signed-off-by: heaterC <airyguy@gmx.de> Signed-off-by: Marek Behún <marek.behun@nic.cz> Tested-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
The funtion returnd cs size in byte instead of MB, that cause
calculation error since the caller was expected to get u32 and when he
got above 4G it refers it as 0.
The fix was to get the cs memory size from function as in MB and then
multiply it by 1MB.
Signed-off-by: Moti Buskila <motib@marvell.com> Reviewed-by: Kostya Porotchkin <kostap@marvell.com> Signed-off-by: Marek Behún <marek.behun@nic.cz> Tested-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
the twin-die combined memory device should be treatened as X8
device and not as X16 one
Signed-off-by: Moti Buskila <motib@marvell.com> Reviewed-by: Kostya Porotchkin <kostap@marvell.com>
[ - the default value for twin_die_combined is set to NOT_COMBINED for
all boards, as this was default behaviour prior this change ] Signed-off-by: Marek Behún <marek.behun@nic.cz> Tested-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
The ODT enable heuristic based on active chip-selects is not always
correct. Some board might use two chip-selects, but have only one ODT
line connected. Allow board specific mv_ddr_topology_map to directly set
the ODT configuration register value.
- function mv_ddr_spd_die_capacity_user_get() has a bug,
since it insert a user memory enum to it,
instead of SPD memory enum (which are different)
- fix: remove mv_ddr_spd_die_capacity_user_get() function.
- memory size with 64 and 32 bit already calculated correctly
at mv_ddr_mem_sz_per_cs_get() function
Signed-off-by: Moti Buskila <motib@marvell.com> Reviewed-by: Stefan Chulski <Stefan.Chulski@cavium.com> Reviewed-by: Alex Leibovich <alexl@marvell.com> Reviewed-by: Kostya Porotchkin <Kostya.Porotchkin@cavium.com> Signed-off-by: Marek Behún <marek.behun@nic.cz> Tested-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
- fix JIRA A7K8K-5056
- remove TEST_PATTERN write at the load patern stage earlier to WL SUP stage
- the WL SUP stage already writes this pattern to the memory, if the pattern exist at the memory
then the algorithm will fail, since it think that there are no phase to correct
Signed-off-by: Moti Buskila <motib@marvell.com> Reviewed-by: Kostya Porotchkin <kostap@marvell.com> Signed-off-by: Marek Behún <marek.behun@nic.cz> Tested-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
projects / u-boot.git / log