Caching pointers to device tree nodes or names is not safe. The barebox
internal device tree may be changed by loading a new device tree or through
fixup handlers. As a result, the string may be deleted.
Use local copies of the full path instead.
Signed-off-by: Michael Olbrich <m.olbrich@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Fix small typo frendly -> friendly
Signed-off-by: Sam Van Den Berge <sam.van.den.berge@telenet.be>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Of_unflatten_dtb returns a ERR_PTR value so checking it against NULL is
incorrect. Fix it in all of the places where this was happening.
Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Fixes: cb47dde boot: Call blspec_scan_directory() only on strings containing an absolute path
This commit introduced a check if the path contains a '/' at the
beginning. For booting a bootloader spec entry from NFS we have to
test the path for starting with "nfs://" aswell.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
CMD_TEST is required for scripts in defaultenv-2, e.g. automount.
Signed-off-by: Alexander Kurz <akurz@blala.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
it already gets free in bootentries_free
no need to do this in ->release method
Signed-off-by: Aleksey Kuleshov <rndfax@yandex.ru>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
The error message warning the user that the image is too big for
the device has its parameters in the wrong order. Swap the two
parameters so that the output makes sense.
Signed-off-by: Renaud Barbier <renaud.barbier@ge.com>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Normally one should not be interested that the blspec code scans
a directory. In case blspec is not actively used it might even be
confusing, so lower priority of the message in blspec_scan_directory()
to pr_debug.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
It's nicer to read when target names have quotes around them, it
makes it clear that this is a string passed in somewhere.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Normally code in commands/ shall only do the option parsing whereas the
functionality shall be in common/ to make the code usable from C aswell.
Do this in the boot code aswell, move it to common/boot.c and add the
function prototypes to include/boot.h
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Since blspec_boot is now only used locally we can make it static. Move
it up to avoid a static declaration.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
This completes the separation of the blspec code from the boot
code. With this the boot code only handles generic boot entries
of type struct bootentry which are embedded into the type
(blspec/bootscript) specific structs.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
We currently have to special case blspec entries vs. boot scripts
in the common boot code since we want to print different informations
about them. This adds a 'title' and 'description' which can be filled
in with different information by bootscripts and blspec entries and
so we get rid of the special handling.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
The code in common/boot.c collects the different boot entries in
lists of type struct blspec, eventhough many of them may not be
bootloader spec entries but for example boot scripts. This is the first
step of separating the data structures from boot entries and bootloader
spec: As struct blspec is merely a container for collecting boot entries
We simply rename struct blspec to struct bootentries. No functional change.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
The majority of the stuff currently in include/boot.h is about bootm
code implemented common/bootm.c. To be more consistent move it to a
new file include/bootm.h.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
The circular backend depends on MTD symbols and is only useful
if MTD is present. Exclude it from the build if MTD is not enabled.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
With this patch 'nv -r' can also take "*" and "?" wildcards for nv
variables. This makes it easier to remove multiple nv variables.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
This is widely unused and in the way of subsequent cleanups. If you are
indeed using it please complain on the list, we'll find a solution to
add it back in a different way.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
The state framework is meant for storing persistent variables. To
make the state more persistent automatically save it on shutdown.
This is now the default behaviour, but can be disabled using a
'save_on_shutdown' variable attached to the state.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
dev_remove_param() is exactly for the purpose of removing a device
parameter, so use this function instead of open coding the
functionality.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
With this patch nv variables are automatically saved whenever barebox
shuts down (that is 'reset' is executed or a kernel is started). With
this the additional 'saveenv' step becomes unnecessary.
The nv variables are stored in the environment and the estasblished
behaviour is that files in the environment must be manually saved
using 'saveenv'. This behaviour shall be kept for now, so this patch
cannot just call 'saveenv' since that would save the modified
environment files aswell. Instead we read the environment from the
device, modifiy the nv variables and save the environment back.
Since this changes a long existing behaviour messages are printed the
first time a nv variable is modified and during shutdown when the
variables are actually saved.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
When reading nv variables from the storage in /env/nv we do
not need to write back the value to the file we just read from.
Optimize this a bit and make it unnecessary.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
The state framework grew organically over the time. Unfortunately the
architecture and abstractions disappeared during this period.
This patch refactors the framework to recreate the abstractions. The
main focus was the backend with its storage. The main use-case was to
offer better NAND support with less erase cycles and interchangeable
data formats (dtb,raw).
The general architecture now has a backend which consists of a data
format and storage. The storage consists of multiple storage buckets
each holding exactly one copy of the state data. A data format describes
a data serialization for the state framework. This can be either dtb or
raw. A storage bucket is a storage location which is used to store any
data. There is a (new) circular type which writes changes behind the
last written data and therefore reduces the number of erases. The other
type is a direct bucket which writes directly to a storage offset for
all non-erase storage.
Furthermore this patch splits up all classes into different files in a
subdirectory.
This is currently all in one patch as I can't see a good way to split
the changes up without having a non-working state framework in between.
The following diagram shows the new architecture roughly:
.----------.
| state |
'----------'
|
|
v
.----------------------------.
| state_backend |
|----------------------------|
| + state_load(*state); |
| + state_save(*state); |
| + state_backend_init(...); |
| |
| |
'----------------------------'
| | The format describes
| | how the state data
| '-------------> is serialized
| .--------------------------------------------.
| | state_backend_format <INTERFACE> |
| |--------------------------------------------|
| | + verify(*format, magic, *buf, len); |
| | + pack(*format, *state, **buf, len); |
| | + unpack(*format, *state, *buf, len); |
| | + get_packed_len(*format, *state); |
| | + free(*format); |
| '--------------------------------------------'
| ^ ^
| * *
| * *
| .--------------------. .--------------------.
| | backend_format_dtb | | backend_format_raw |
| '--------------------' '--------------------'
|
|
|
v
.----------------------------------------------------------.
| state_backend_storage |
|----------------------------------------------------------|
| + init(...); |
| + free(*storage); |
| + read(*storage, *format, magic, **buf, *len, len_hint); |
| + write(*storage, *buf, len); |
| + restore_consistency(*storage, *buf, len); |
'----------------------------------------------------------'
|
The backend storage is responsible to manage multiple
data copies and distribute them onto several buckets.
Read data is verified against the given format to
ensure that the read data is correct.
|
|
|
|
|
v
.------------------------------------------.
| state_backend_storage_bucket <INTERFACE> |
|------------------------------------------|
| + init(*bucket); |
| + write(*bucket, *buf, len); |
| + read(*bucket, **buf, len_hint); |
| + free(*bucket); |
'------------------------------------------'
^ ^ ^
* * *
* * *
A storage bucket represents*exactly one data copy at one
data location. A circular b*cket writes any new data to
the end of the bucket (for *educed erases on NAND). A
direct bucket directly writ*s at one location.
* * *
* * *
* * *
.-----------------------. * .-------------------------.
| backend_bucket_direct | * | backend_bucket_circular |
'-----------------------' * '-------------------------'
^ * ^
| * |
| * |
| * |
| .-----------------------. |
'--| backend_bucket_cached |---'
'-----------------------'
A backend_bucket_cached is a transparent
bucket that directly uses another bucket
as backend device and caches all accesses.
Signed-off-by: Markus Pargmann <mpa@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
bit_to_flip might be negative if any uncorrectable bitflips
occured. Use int instead of unsigned type in order to properly
propagate the error.
Signed-off-by: Lucas Stach <dev@lynxeye.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Non volatile device variables are used to make device parameters
persistent. They are like normal non volatile variables, but set
the values of the device parameters with the corresponding name.
Every nv variable beginning with nv.dev is a non volatile device
variable. They have the form nv.dev.<devname>.<paramname> and act
on the parameter <paramname> of the device named <devname>.
The non volatile device variables are designated for example for
video modes, ethernet device ip addresses or mtd partitioning.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
