diff options
author | Maxime Ripard <maxime.ripard@free-electrons.com> | 2016-07-05 10:26:45 +0200 |
---|---|---|
committer | Tom Rini <trini@konsulko.com> | 2016-08-20 11:35:05 -0400 |
commit | e6628ad7b99b285b25147366c68a7b956e362878 (patch) | |
tree | c815eff9dc136d99f0d6577e37f5c0571daefda8 /cmd/mem.c | |
parent | ddf67f71352be56d98f0e5bcf851146e54d764ad (diff) | |
download | u-boot-imx-e6628ad7b99b285b25147366c68a7b956e362878.zip u-boot-imx-e6628ad7b99b285b25147366c68a7b956e362878.tar.gz u-boot-imx-e6628ad7b99b285b25147366c68a7b956e362878.tar.bz2 |
cmd: fdt: add fdt overlay application subcommand
The device tree overlays are a good way to deal with user-modifyable
boards or boards with some kind of an expansion mechanism where we can
easily plug new board in (like the BBB or the raspberry pi).
However, so far, the usual mechanism to deal with it was to have in Linux
some driver detecting the expansion boards plugged in and then request
these overlays using the firmware interface.
That works in most cases, but in some cases, you might want to have the
overlays applied before the userspace comes in. Either because the new
board requires some kind of an early initialization, or because your root
filesystem is accessed through that expansion board.
The easiest solution in such a case is to simply have the component before
Linux applying that overlay, removing all these drawbacks.
Reviewed-by: Stefan Agner <stefan@agner.ch>
Acked-by: Pantelis Antoniou <pantelis.antoniou@konsulko.com>
Acked-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Diffstat (limited to 'cmd/mem.c')
0 files changed, 0 insertions, 0 deletions