| Age | Commit message (Collapse) | Author |
|---|
|
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 <[email protected]>
Reviewed-by: Quentin Schulz <[email protected]>
Reviewed-by: Mattijs Korpershoek <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Mattijs Korpershoek <[email protected]>
Reviewed-by: Quentin Schulz <[email protected]>
|
|
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 <[email protected]>
Acked-by: Ilias Apalodimas <[email protected]>
|
|
Replace Maximumm with Maximum in Kconfig symbol description, fix a typo.
No functional change.
Signed-off-by: Marek Vasut <[email protected]>
Reviewed-by: Michal Simek <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Marek Vasut <[email protected]>
|
|
Simon Glass <[email protected]> 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 <[email protected]>
|
|
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 <[email protected]>
|
|
type GUID"
Rasmus Villemoes <[email protected]> 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 <[email protected]>
|
|
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 <[email protected]>
|
|
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 <[email protected]>
|
|
Move this header to include/u-boot/ so that it can be used by external
tools.
Reviewed-by: Ilias Apalodimas <[email protected]>
Signed-off-by: Caleb Connolly <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
Introduce ubi_volume_offset_write() helper, which
allow to write to ubi volume with specified offset.
Signed-off-by: Alexey Romanov <[email protected]>
Reviewed-by: Heiko Schocher <[email protected]>
Acked-by: Heiko Schocher <[email protected]>
Signed-off-by: Michael Trimarchi <[email protected]>
|
|
Now user can pass an additional parameter 'offset'
to ubi_volume_read() function.
Signed-off-by: Alexey Romanov <[email protected]>
Reviewed-by: Heiko Schocher <[email protected]>
Acked-by: Heiko Schocher <[email protected]>
Signed-off-by: Michael Trimarchi <[email protected]>
|
|
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 <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Michal Simek <[email protected]> # 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 <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
|
|
This removes a number of duplicate newlines throughout the codebase.
|
|
Drop all duplicate newlines. No functional change.
Signed-off-by: Marek Vasut <[email protected]>
|
|
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 <[email protected]>
|
|
Add support for AMD Versal Gen 2. SoC is based on Cortex-a78ae 4 cluster/2
cpu core each. A lot of IPs are shared with previous families. There are
couple of new IP blocks where the most interesting from user point of view
is UFS.
Signed-off-by: Michal Simek <[email protected]>
Link: https://lore.kernel.org/r/bc2b70831ce1031bd0fac32357bff84936e1310f.1716994063.git.michal.simek@amd.com
|
|
As part of bringing the master branch back in to next, we need to allow
for all of these changes to exist here.
Reported-by: Jonas Karlman <[email protected]>
Signed-off-by: Tom Rini <[email protected]>
|
|
When bringing in the series 'arm: dts: am62-beagleplay: Fix Beagleplay
Ethernet"' I failed to notice that b4 noticed it was based on next and
so took that as the base commit and merged that part of next to master.
This reverts commit c8ffd1356d42223cbb8c86280a083cc3c93e6426, reversing
changes made to 2ee6f3a5f7550de3599faef9704e166e5dcace35.
Reported-by: Jonas Karlman <[email protected]>
Signed-off-by: Tom Rini <[email protected]>
|
|
Specifying a file in an EXT4 or FAT partition on a virtio device as
environment location failed because virtio hadn't been initialized by
the time the environment was loaded. This patch mirrors commit
54ee5ae84191 ("Add SCSI scan for ENV in EXT4 or FAT") in issue and
fix, just for a different kind of block device.
The additional include in include/virtio.h is needed so all functions
called there are defined, the alternative would have been to include
dm/device.h separately in the env/ sources.
Checkpatch suggests using "if (IS_ENABLED(CONFIG...))" instead of
"#if defined(CONFIG_...)", I'm sticking to the style of the existing
code here.
Signed-off-by: Fiona Klute <[email protected]>
CC: Joe Hershberger <[email protected]>
CC: Bin Meng <[email protected]>
CC: Rogier Stam <[email protected]>
|
|
Remove <common.h> from all "env/" files and when needed add
missing include files directly.
Signed-off-by: Tom Rini <[email protected]>
|
|
With the migration to Kconfig complete, we can now add some previously
missing dependencies to some commands.
Signed-off-by: Tom Rini <[email protected]>
|
|
This prints the MMC device being read similar to how we print the MMC
device we write to when e.g. calling saveenv.
One of the side effects is that the boot log now shows from which MMC
device the env was loaded:
Loading Environment from MMC... Reading from MMC(1)... OK
This is useful to identify which MMC device the environment was loaded
from for boards where there are more than one (e.g. eMMC and SD card)
without adding some debug messages manually.
Sadly, there's no way to know which of the default or redundant
environment is being read from env_mmc_load before env_import_redund is
called so it is printing a bit later (and possibly after error/warning
messages).
Cc: Quentin Schulz <[email protected]>
Signed-off-by: Quentin Schulz <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
Reviewed-by: Dragan Simic <[email protected]>
|
|
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-net platform as well.
Signed-off-by: Venkatesh Yadav Abbarapu <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Michal Simek <[email protected]>
|
|
In the non-redundant code for env_sf_save(), a failure to malloc() the
temporary buffer produces the following output:
Saving Environment to SPIFlash... OK
This is misleading as the flash has neither been erased nor written.
Fix it to return an error to the caller, so the output will be:
Saving Environment to SPIFlash... Failed (-12)
Note that there is another copy of env_sf_save() in the same file, for
handling redundant environment, and it already has the same logic.
Signed-off-by: Ralph Siemsen <[email protected]>
|
|
In order for our environment to be present on SPI flash we need to
depend not on the symbol for a SPI controller but rather that SPI flash
of some sort is present. Update the dependencies.
Signed-off-by: Tom Rini <[email protected]>
|
|
- A number of OS boot related cleanups, a number of TI platform
fixes/cleanups, SMBIOS fixes, tweak get_maintainers.pl to report me
for more places, fix the "clean the build" pytest and add a bootstage
pytest, fix PKCS11 URI being omitted in some valid cases, make an iommu
problem easier to debug on new platforms, nvme and pci improvements,
refactor image-host code a bit, fix a typo in env setting, add a missing
dependency for CMD_LICENSE, and correct how we call getchar() in some
places.
|
|
Since both functions share a similar goal and env_get_default_into can
do what env_get_default wants to do with specific arguments, let's make
env_get_default call env_get_default_into so as to avoid code
duplication.
Cc: Quentin Schulz <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
Reviewed-by: Kever Yang <[email protected]>
Signed-off-by: Quentin Schulz <[email protected]>
|
|
env_get_default suffers from a particular issue int that it can only
return a value truncated to gd->env_buf (32) characters. This may be
enough for most variables but it isn't for others, so let's allow users
to provide a preallocated buffer to copy the value into instead,
allowing for more control, though it'll still be truncated if the value
size is bigger than the preallocated buffer.
Cc: Quentin Schulz <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
Reviewed-by: Kever Yang <[email protected]>
Signed-off-by: Quentin Schulz <[email protected]>
|
|
Fix a typo: add a space after the single quote in 'illegal character'
error message in 'env set' command
Signed-off-by: Ivan Orlov <[email protected]>
|
|
In general terms, we -include include/linux/kconfig.h and so normal
U-Boot code does not need to also #include it. However, for code which
is shared with userspace we may need to add it so that either our full
config is available or so that macros such as CONFIG_IS_ENABLED() can be
evaluated. In this case make sure that we guard these includes with a
test for USE_HOSTCC so that it clear as to why we're doing this.
Reviewed-by: Simon Glass <[email protected]>
Signed-off-by: Tom Rini <[email protected]>
|
|
To quote the author:
It would be useful to be able to boot an OS when CONFIG_CMDLINE is
disabled. This could allow reduced code size.
Standard boot provides a way to handle programmatic boot, without
scripts, so such a feature is possible. The main impediment is the
inability to use the booting features of U-Boot without a command line.
So the solution is to avoid passing command arguments and the like to
code in boot/
A similar process has taken place with filesystems, for example, where
we have (somewhat) separate Kconfig options for the filesystem commands
and the filesystems themselves.
This series starts the process of refactoring the bootm logic so that
it can be called from standard boot without using the command line.
Mostly it removes the use of argc, argv and cmdtbl from the internal
logic.
Some limited tidy-up is included, but this is kept to smaller patches,
rather than trying to remove all #ifdefs etc. Some function comments
are added, however.
A simple programmatic boot is provided as a starting point.
This work will likely take many series, so this is just the start.
Size growth with this series for firefly-rk3288 (Thumb2) is:
arm: (for 1/1 boards) all +23.0 rodata -49.0 text +72.0
This should be removed by:
https://source.denx.de/u-boot/custodians/u-boot-dm/-/issues/11
but it is not included in this series as it is already large enough.
No functional change is intended in this series.
Changes in v3:
- Add a panic if programmatic boot fails
- Drop RFC tag
Changes in v2:
- Add new patch to adjust position of unmap_sysmem() in boot_get_kernel()
- Add new patch to obtain command arguments
- Fix 'boot_find_os' typo
- Pass in the command name
- Use the command table to provide the command name, instead of "bootm"
|
|
The declaration of U_BOOT_ENV_LOCATION() uses a different #ifdef
condition from the code it calls. Use the same condition to avoid a
build warning if CONFIG_CMD_SAVEENV is disabled.
Signed-off-by: Simon Glass <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
|
|
The part_length parameter is not used. Remove it.
Signed-off-by: Sean Anderson <[email protected]>
|
|
Inside of env/common.c we already have our helper env_set_xxx functions,
and even have a comment that explains why env_set() itself wasn't moved.
We now handle that move. This requires that we rename the previous
_do_env_set() to env_do_env_set() and note it as an internal env
function. Add comments about this function to explain why we do this
when we add the prototype. Add a new function, env_inc_id() to allow for
the counter to be updated by both commands and callers, and document
this as well by the prototype.
Signed-off-by: Tom Rini <[email protected]>
|
|
When reading Kconfig help messages to understand ENV_OFFSET and
ENV_OFFSET_REDUND, developers may not realise that they need to also
look at the chosen ENV_IS_IN_* options to see how the offsets will be
interpreted.
Signed-off-by: Paul Barker <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
PPA was a secure firmware developed in-house which is no longer
supported and replaced by TF-A quite some years ago. Drop support
for it.
Signed-off-by: Laurentiu Tudor <[email protected]>
Signed-off-by: Peng Fan <[email protected]>
|
|
This old patch was marked as deferred. Bring it back to life, to continue
towards the removal of common.h
Move this out of the common header and include it only where needed.
Signed-off-by: Simon Glass <[email protected]>
|
|
The last user of the NEEDS_MANUAL_RELOC has been removed in commit
26af162ac8f8 ("arch: m68k: Implement relocation")
Remove now unused NEEDS_MANUAL_RELOC code.
Signed-off-by: Marek Vasut <[email protected]>
|
|
The last user of the NEEDS_MANUAL_RELOC has been removed in commit
26af162ac8f8 ("arch: m68k: Implement relocation")
Remove now unused NEEDS_MANUAL_RELOC code.
Signed-off-by: Marek Vasut <[email protected]>
|
|
It is not a parse error to have a default value of "0" for a "hex" type
entry, instead of "0x0". However, "0" and "0x0" are not treated the
same even by the tools themselves. Correct this by changing the default
value from "0" to "0x0" for all hex type questions that had the
incorrect default. Fix one instance (in two configs) of a default of "0"
being used on a hex question to be "0x0". Remove the cases where a
defconfig had set a value of "0x0" to be used as the default had been
"0".
Signed-off-by: Tom Rini <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
When CONFIG_SYS_REDUNDAND_ENVIRONMENT is enabled, by default env is
getting saved to redundant environment irrespective of primary env is
present or not.
It means even if primary and redundant environment are not present, by
default, env is getting stored to redundant environment. Even if primary
env is present, it is choosing to store in redudndant env.
Ideally it should look for primary env and choose to store in primary env
if it is present. If both primary and redundant env are not present then
it should save in to primary env area.
Fix the issue by making env_valid = ENV_INVALID when both the
environments are not present.
Signed-off-by: Ashok Reddy Soma <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
The new opt-out setting, CONFIG_ENV_MMC_PARTITION, statically sets
the MMC environment partition name. Prior to this patch, the only way
to declare this partition name was by creating a
'u-boot,mmc-env-partition' parameter in the device-tree's /config node.
This setting provides additional flexibility, particularly in cases
where accessing the device-tree is not straightforward (e.g. QEMU).
If undeclared, the device-tree's setting will be used.
Signed-off-by: Emmanuel Di Fede <[email protected]>
Cc: Joe Hershberger <[email protected]>
Cc: Patrick Delaunay <[email protected]>
|
|
When using a list of writeable variables, the initial values come from
the built-in default environment since commit 5ab81058364b
("env: Complete generic support for writable list"). Remove leftover of
misuse of the env is nowhere driver as default environment.
Signed-off-by: Stefan Herbrechtsmeier <[email protected]>
|
