| Age | Commit message (Collapse) | Author |
|---|
|
Since commit 5fb88fa725 "env: Rename SYS_REDUNDAND_ENVIRONMENT to ENV_REDUNDANT"
the option SYS_REDUNDAND_ENVIRONMENT is no longer available and should be
renamed to ENV_REDUNDANT.
Fixes: 95f03ee65c0e ("env: mmc: fix offsets relative to the end of the partition")
Signed-off-by: Heiko Thiery <heiko.thiery@gmail.com>
Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
|
|
bug fix MTD_OOB_AUTO to MTD_OPS_AUTO_OOB since MTD_OOB_AUTO does not exist
Fixes: dfe64e2c8973 ("mtd: resync with Linux-3.7.1")
Signed-off-by: david regan <dregan@broadcom.com>
Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com>
|
|
As part of renaming environment related Kconfig options,
ENV_MMC_SW_PARTITION was inadvertently changed from a string to a bool.
Correct this.
Fixes: ffc4914703a2 ("env: Rename ENV_MMC_PARTITION to ENV_MMC_SW_PARTITION")
Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
In order to set the BOOTFILE symbol we first need to have USE_BOOTFILE
be set, or some of the logic might not work as expected later on when
building. Second, defaults like this belong with the symbol itself.
Fixes: da595d236b97 ("include: configs: soc64: Use CONFIG_SPL_ATF to differentiate bootfile")
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
When sect_size is greater than the CONFIG_ENV_SIZE, this wild
pointer will cause CPU halt or system crash.
Fixes: 03fb08d4aef8 ("env: Introduce support for MTD")
Signed-off-by: Shiji Yang <yangshiji66@outlook.com>
|
|
The mtd device is got in setup_mtd_device(), we must put the mtd
device before exiting the function to update the mtd use count.
This patch fixes the following env error:
> Removing MTD device #2 (u-boot-env) with use count 1
> Error when deleting partition "u-boot-env" (-16)
Fixes: 03fb08d4aef8 ("env: Introduce support for MTD")
Signed-off-by: Shiji Yang <yangshiji66@outlook.com>
|
|
We have a few options that we cannot enable in a "allyesconfig" type
build because we cannot use zero as a default value.
- The logic around HAS_BOARD_SIZE_LIMIT assumes that if we have set this
then we compare with it. Similarly, we need to set SPL_NO_BSS_LIMIT as
the default there.
- Both SYS_CUSTOM_LDSCRIPT and ENV_USE_DEFAULT_ENV_TEXT_FILE then prompt
for a file name to use.
- The SYS_I2C_SOFT driver is a legacy driver which requires a lot of
configuration within the board config. file instead, so disable it.
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
It was discovered that env_do_env_set() currently suffer from a long
time of a possible out-of-bound access for the argv array handling.
The BUG is present in the function env_do_env_set() line:
name = argv[1];
where the function at this point assume the argv at index 1 is always
present and can't be NULL. Aside from the fact that it's always
better to validate argv entry with the argc variable, situation where
the argv[1] is NULL is actually possible and not an error condition.
A example of where an out-of-bound access is triggered is with the
command "askenv - Press ENTER to ...".
This is a common pattern for bootmenu entry to ask the user input after
a bootmenu command succeeded.
In the context of such command, the while loop before "name = argv[1];"
parse the "-" char as an option arg and increment the argv pointer by
one (to make the rest of the logic code ignore the option argv) and
decrement argc value.
The while loop logic is correct but at the "name = argv[1];" line, the
argv have only one element left (the "-" char) and accessing argv[1]
(aka the secong element from argv pointer) cause an out-of-bound access
(making the bootloader eventually crash with strchr searching in invalid
data)
To better handle this and prevent the out-of-bound access, actually
check the argv entry left (with the use of the argc variable) and exit
early before doing any kind of array access.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
|
|
According to the help text, you can set negative offsets to indicated
that the offset is relative to the end of the parition. But kconfig
doesn't let you specify negative hex values. I think this fell through
the cracks when converting the symbol from a '#define' to a kconfig
option.
Introduce a new boolean kconfig option to switch on the "relative to the
end" behavior.
Signed-off-by: Michael Walle <mwalle@kernel.org>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
|
|
Marek Vasut <marek.vasut+renesas@mailbox.org> says:
Rename the environment related variables and add ENV_ prefix, so that
all configuration options which are related to environment would have
an CONFIG_ENV_ prefix. No functional change.
Link: https://lore.kernel.org/r/20250609192701.20260-1-marek.vasut+renesas@mailbox.org
|
|
There are no users of DELAY_ENVIRONMENT and the same effect can
be achieved either using DT /config/load-environment property,
or by using ENV_IS_NOWHERE . Remove this configuration option
and matching functionality.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
|
|
Rename the variable and add ENV_ prefix, so that all configuration
options which are related to environment would have an CONFIG_ENV_
prefix. No functional change.
Also rename USE_DEFAULT_ENV_FILE to USE_ENV_DEFAULT_ENV_TEXT_FILE .
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
|
|
Rename the variable and add ENV_ prefix, so that all configuration
options which are related to environment would have an CONFIG_ENV_
prefix. No functional change.
Use ENV_MMC_SW_PARTITION to clarify this is the SD/MMC software
partition table entry selector. Update the help text accordingly.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
|
|
Rename the variable and add ENV_ prefix, so that all configuration
options which are related to environment would have an CONFIG_ENV_
prefix. No functional change.
Use ENV_MMC_EMMC_HW_PARTITION to clarify this is the eMMC hardware
partition selector, not a software partition table entry selector.
Retain the ENV_MMC_ prefix to make it easier to search for all the
SD/MMC related ENV options. Update the help text accordingly.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
|
|
Rename the variable and add ENV_ prefix, so that all configuration
options which are related to environment would have an CONFIG_ENV_
prefix. No functional change.
Use ENV_MMC_DEVICE_INDEX to clarify this is the SD/MMC device
index, a number, as enumerated by U-Boot. Update the help text
accordingly.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
|
|
Rename the variable and add ENV_ prefix, so that all configuration
options which are related to environment would have an CONFIG_ENV_
prefix. No functional change.
Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
|
|
Rename the variable and add ENV_ prefix, so that all configuration
options which are related to environment would have an CONFIG_ENV_
prefix. No functional change.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
|
|
Rename the variable and add ENV_ prefix, so that all configuration
options which are related to environment would have an CONFIG_ENV_
prefix. No functional change.
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
|
|
Prepare v2025.07-rc4
|
|
When lwIP (CONFIG_NET_LWIP) is used instead of legacy stack (CONFIG_NET),
environment flags support associated with network was not built: restore
support of "i" and "m" environment flags.
Signed-off-by: Benjamin ROBIN <dev@benjarobin.fr>
Acked-by: Jerome Forissier <jerome.forissier@linaro.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
|
|
Varadarajan Narayanan <quic_varada@quicinc.com> says:
The qcs9100 based Ride platforms have UFS as their primary storage.
Hence add support to U-Boot env framework to be able to save and
retrieve the environment from UFS. The environment will be
saved/retrieved from the partition specified in the config option
CONFIG_SCSI_ENV_PART.
Also add an API to convert partition UUID string to block device
descriptor for UFS. This API will be used to get the block device
descriptor for the partition specified in CONFIG_SCSI_ENV_PART.
Link: https://lore.kernel.org/r/20250513091710.3719292-1-quic_varada@quicinc.com
|
|
Allow SCSI to be able to store environment variables.
Signed-off-by: Varadarajan Narayanan <quic_varada@quicinc.com>
Acked-by: Casey Connolly <casey.connolly@linaro.org>
|
|
1. As this is for MTD-based devices, the Kconfig dependency should be MTD
instead of only spi-nor flashes
2. Initialize saved_buf to avoid crash on free()
3. Remaining size should be set correctly to write_size
Fixes: 03fb08d4aef (env: Introduce support for MTD)
Signed-off-by: Weijie Gao <weijie.gao@mediatek.com>
Reviewed-by: Christian Marangi <ansuelsmth@gmail.com>
|
|
Introduce support for env in generic MTD. Currently we only support SPI
flash based on the lagacy sf cmd that assume SPI flash are always NOR.
This is not the case as to SPI controller also NAND can be attached.
To support also these flash scenario, add support for storing and
reading ENV from generic MTD device by adding an env driver that
base entirely on the MTD api.
Introduce a new kconfig CONFIG_ENV_IS_IN_MTD and
CONFIG_ENV_MTD_DEV to define the name of the MTD device as exposed
by mtd list.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
|
|
This series from Raymond Mao <raymond.mao@linaro.org> fixes some cases
of passing the device tree to U-Boot via standard passage and then
ensures that we set the environment variable of the device tree
correctly in this case.
Link: https://lore.kernel.org/r/20250331224011.2734284-1-raymond.mao@linaro.org
|
|
Point fdt_addr to the fdt embedded in the bloblist since fdt_addr
is a default address for bootefi, bootm and booti to look for the
device tree when launching the kernel.
Signed-off-by: Raymond Mao <raymond.mao@linaro.org>
|
|
Enable saving variables to MMC(FAT) and SPI based on primary
bootmode. If bootmode is JTAG, dont save env anywhere(NOWHERE).
Enable ENV_FAT_DEVICE_AND_PART="0:auto" for Versal Gen 2 platform.
Signed-off-by: Venkatesh Yadav Abbarapu <venkatesh.abbarapu@amd.com>
Link: https://lore.kernel.org/r/20250411154612.107136-1-venkatesh.abbarapu@amd.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
|
|
The symbol "ENV_IS_EMBEDDED" is an environment internal define and not a
real CONFIG symbol. The IS_ENABLED() macro is still valid to use here,
so update the check.
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
Rename the variants of env_mmc_load() for redundant and non-redundant
environment to env_mmc_load_redundant() and env_mmc_load_singular()
respectively and convert the env_mmc_load() implementation to use of
if (IS_ENABLED(...)). As a result, drop __maybe_unused from
mmc_env_is_redundant_in_both_boot_hwparts().
Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
|
|
Introduce a new function mmc_env_is_redundant_in_both_boot_hwparts()
which replaces IS_ENABLED(ENV_MMC_HWPART_REDUND) and internally does
almost the same check as the macro which assigned ENV_MMC_HWPART_REDUND
did, and call it in place of IS_ENABLED(ENV_MMC_HWPART_REDUND).
The difference compared to IS_ENABLED(ENV_MMC_HWPART_REDUND) is
in the last conditional, which does not do plain macro compare
(CONFIG_ENV_OFFSET == CONFIG_ENV_OFFSET_REDUND), but instead does
mmc_offset(mmc, 0) == mmc_offset(mmc, 1). If OF_CONTROL is not
in use, this gets optimized back to original macro compare, but
if OF_CONTROL is in use, this also takes into account the DT
properties u-boot,mmc-env-offset and u-boot,mmc-env-offset-redundant.
Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
|
|
The env_fat_get_dev_part() function mostly returns a fixed string, set
via some Kconfig variable. However when the first character is a colon,
that means that the boot device number is determined at runtime, and
patched in. This requires altering the string.
So far this was done via some ugly and actually illegal direct write to
the .rodata string storage. We got away with this because U-Boot maps
everything as read/write/execute so far.
A proposed patch set actually enforces read-only (and no-execute)
permissions in the page tables, so this routine now causes an exception:
=======================
Loading Environment from FAT... "Synchronous Abort" handler, esr 0x9600004f, far 0xfffb7d4c
elr: 000000004a054228 lr : 000000004a05421c (reloc)
elr: 00000000fff7c228 lr : 00000000fff7c21c
.....
=======================
Rewrite the routine to do away with the dodgy string manipulation,
instead allocate the string in the r/w .data section, where we can
safely manipulate it.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
|
|
Replace Maximumm with Maximum in Kconfig symbol description, fix a typo.
No functional change.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Michal Simek <michal.simek@amd.com>
|
|
Switch the callback static list from the board configuration variable
CFG_ENV_CALLBACK_LIST_STATIC to Kconfig CONFIG_ENV_CALLBACK_LIST_STATIC.
Signed-off-by: Christoph Niedermaier <cniedermaier@dh-electronics.com>
Reviewed-by: Marek Vasut <marex@denx.de>
|
|
Simon Glass <sjg@chromium.org> says:
When the SPL build-phase was first created it was designed to solve a
particular problem (the need to init SDRAM so that U-Boot proper could
be loaded). It has since expanded to become an important part of U-Boot,
with three phases now present: TPL, VPL and SPL
Due to this history, the term 'SPL' is used to mean both a particular
phase (the one before U-Boot proper) and all the non-proper phases.
This has become confusing.
For a similar reason CONFIG_SPL_BUILD is set to 'y' for all 'SPL'
phases, not just SPL. So code which can only be compiled for actual SPL,
for example, must use something like this:
#if defined(CONFIG_SPL_BUILD) && !defined(CONFIG_TPL_BUILD)
In Makefiles we have similar issues. SPL_ has been used as a variable
which expands to either SPL_ or nothing, to chose between options like
CONFIG_BLK and CONFIG_SPL_BLK. When TPL appeared, a new SPL_TPL variable
was created which expanded to 'SPL_', 'TPL_' or nothing. Later it was
updated to support 'VPL_' as well.
This series starts a change in terminology and usage to resolve the
above issues:
- The word 'xPL' is used instead of 'SPL' to mean a non-proper build
- A new CONFIG_XPL_BUILD define indicates that the current build is an
'xPL' build
- The existing CONFIG_SPL_BUILD is changed to mean SPL; it is not now
defined for TPL and VPL phases
- The existing SPL_ Makefile variable is renamed to SPL_
- The existing SPL_TPL Makefile variable is renamed to PHASE_
It should be noted that xpl_phase() can generally be used instead of
the above CONFIGs without a code-space or run-time penalty.
This series does not attempt to convert all of U-Boot to use this new
terminology but it makes a start. In particular, renaming spl.h and
common/spl seems like a bridge too far at this point.
The series is fully bisectable. It has also been checked to ensure there
are no code-size changes on any commit.
|
|
Use PHASE_ as the symbol to select a particular XPL build. This means
that SPL_TPL_ is no-longer set.
Update the comment in bootstage to refer to this symbol, instead of
SPL_
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
Complete this rename for all directories outside arch/ board/ drivers/
and include/
Use the new symbol to refer to any 'SPL' build, including TPL and VPL
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
type GUID"
Rasmus Villemoes <rasmus.villemoes@prevas.dk> says:
I always define a disk layout with two separate partitions for the two
copies of the U-Boot environment and, being the one who introduced the
type GUID for such partitions, of course also set those partitions'
type GUID appropriately.
This has worked just fine, but, it turns out, only because I've never
had CONFIG_PARTITION_TYPE_GUID enabled on any of my boards; I've
always just set the offsets of the two partitions via the config
variables CONFIG_ENV_OFFSET(,_REDUND).
I didn't even know that env/mmc.c had learnt to look for the env
partition based on the type GUID, or that that would overrule the
ENV_OFFSET config variables, until I experienced weird random
corruption while doing bringup for an stm32 board, where
PARTITION_TYPE_GUID is automatically set because it is select'ed by
CMD_STM32PROG.
These patches try to fix the code to fit my scheme, while not changing
anything for existing setups that use the two-copies-one-partition
scheme, other than complaining loudly if the system is misconfigured
and avoiding such random corruption of neighbouring partitions.
|
|
partitions
Having two separate partitions for use in a redundant environment
setup works just fine, if one only relies on setting CONFIG_ENV_OFFSET
and CONFIG_ENV_OFFSET_REDUND. However, if CONFIG_PARTITION_TYPE_GUID
is enabled, the current logic in mmc_env_partition_by_guid() means
that only the first partition will ever be considered, and prior to
the previous commit, lead to silent data corruption.
Extend the logic so that, when we are looking for the location for the
second copy of the environment, we keep track of whether we have
already found one matching partition. If a second match is found,
return that, but also modify *copy so that the logic in the caller
will use the last ENV_SIZE bytes of that second partition - in my
case, and I suppose that would be typical, both partitions have been
created with a size of exactly the desired ENV_SIZE.
When only a single matching partition exists, the behaviour is
unchanged: We return that single partition, and *copy is left as-is,
so the logic in the caller will either use the last (copy==0) or
second-to-last (copy==1) ENV_SIZE bytes.
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
|
|
I have an GPT layout containing two partitions with the type GUID for
U-Boot environment:
partition U-Boot-env-1 {
offset = 0x1fc000
size = 0x2000
partition-type-uuid = "3de21764-95bd-54bd-a5c3-4abe786f38a8"
}
partition U-Boot-env-2 {
offset = 0x1fe000
size = 0x2000
partition-type-uuid = "3de21764-95bd-54bd-a5c3-4abe786f38a8"
}
and have set CONFIG_ENV_OFFSET=0x1fc000,
CONFIG_ENV_OFFSET_REDUND=0x1fe000 and CCONFIG_ENV_SIZE=0x2000.
This usually works just fine, but on an stm32mp, I was seeing weird
behaviour. It turns out that can be tracked down to that board setting
CONFIG_PARTITION_TYPE_GUID, so the logic in mmc.c ends up only finding
the first of the two partitions, but then in the copy=1 case ends up
computing 0x1fa000 as the *val returned (that is, the end of the
partition minus two times the environment size). That is of course
outside the found partition and leads to random corruption of the
partition preceding U-Boot-env-1.
Add a sanity check that the partition found is at least as large as
needed for the "one or two copies from the end of the partition" logic
to at least produce something within that partition. That will also
catch a bug where the partition is too small for even one copy of the
environment.
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
|
|
In preparation for fixing the handling of a the case of redundant
environment defined in two separate partitions with the U-Boot env
GUID, refactor the
for ()
if (str)
...
#ifdef CONFIG_FOO
if (!str)
..
#endif
to
if (str)
for ()
else if (CONFIG_FOO && !str)
for ()
and put those for loops in separate functions.
No functional change intended, but I did change the direct access of
info.type_guid into using the disk_partition_type_guid() helper, so
that I could avoid the #ifdef and use IS_ENABLED() in the if() statement.
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
|
|
Move this header to include/u-boot/ so that it can be used by external
tools.
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
|
|
Prepare v2024.10-rc3
|
|
current env_set_default_vars() doesn't delete
var that are not in the imported env. hashtable
removes vars that are not in the imported
env but present in the current env only if H_NOCLEAR
flag is not set.
This change is to avoid passing H_NOCLEAR flag if
specific vars are passed to env_set_default_vars()
Without this change:
Marvell>> env default boot_mode
Marvell>>
With the change:
Marvell>> env default boot_mode
WARNING: 'boot_mode' not in imported env, deleting it!
Signed-off-by: Ravi Minnikanti <rminnikanti@marvell.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
Introduce ubi_volume_offset_write() helper, which
allow to write to ubi volume with specified offset.
Signed-off-by: Alexey Romanov <avromanov@salutedevices.com>
Reviewed-by: Heiko Schocher <hs@denx.de>
Acked-by: Heiko Schocher <hs@denx.de>
Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com>
|
|
Now user can pass an additional parameter 'offset'
to ubi_volume_read() function.
Signed-off-by: Alexey Romanov <avromanov@salutedevices.com>
Reviewed-by: Heiko Schocher <hs@denx.de>
Acked-by: Heiko Schocher <hs@denx.de>
Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com>
|
|
This enables boards to choose where to/from the environment
should be saved/loaded. They can then for example support using
the same device (dynamically) from which the bootloader was
launched to load and save env data and do not have to
define CONFIG_ENV_SPI_BUS statically.
In my use case, the environment needs to be on the same device I
booted from. It can be the QSPI or OSPI device.
I therefore would override spi_get_env_dev in the board code,
read the bootmode registers to determine where we booted from
and return the corresponding device index.
Signed-off-by: Venkatesh Yadav Abbarapu <venkatesh.abbarapu@amd.com>
Link: https://lore.kernel.org/r/20240614124811.22945-2-venkatesh.abbarapu@amd.com
Signed-off-by: Michal Simek <michal.simek@amd.com> # Move spi_get_env_dev to sf.c
|
|
When CONFIG_SYS_MMC_ENV_PART=2, the environment is loaded from
the USER partition (hwpart=0) instead of from the
BOOT1 partition (hwpart=2).
IS_ENABLED() cannot be used for non-boolean KConfig options.
Its documentation states:
> * IS_ENABLED(CONFIG_FOO) evaluates to 1 if CONFIG_FOO is set to 'y',
> * 0 otherwise.
So in our case, IS_ENABLED(CONFIG_SYS_MMC_ENV_PART) evaluates to 0.
Because of this, the hwpart variable is never assigned and mmc_offset()
ends up switching back to the USER hwpart (0) instead of BOOT1 (2).
Fix it by using #define instead.
Tested with:
# have CONFIG_SYS_MMC_ENV_PART=2 in defconfig
# 1. Erase mmc0boot1
=> mmc dev 0 2
=> mmc erase 0 400
=> mmc read ${loadaddr} 0 400
=> md ${loadaddr} 4
82000000: 00000000 00000000 00000000 00000000 ................
# 2. Restore default environment and save to MMC
=> env default -a -f
=> saveenv
# 3. Read back mmc0boot1 and confirm the env is present
=> mmc read ${loadaddr} 0 400
=> md ${loadaddr} 4
82000000: 13e0632e 72646461 7469665f 3978303d .c..addr_fit=0x9
Fixes: 5b4acb0ff79d ("env: mmc: Apply GPT only on eMMC user HW partition")
Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
|
|
This removes a number of duplicate newlines throughout the codebase.
|
|
Drop all duplicate newlines. No functional change.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
|
|
When enabling CONFIG_ENV_IS_IN_EXT4 the environment might be stored on
an mmc device similar to the CONFIG_ENV_IS_IN_FAT case.
Fixes: 7d080773347c ("Convert CONFIG_SYS_MMC_ENV_DEV et al to Kconfig")
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
|
