| 54965b61 | 03-May-2013 |
Fabio Estevam <fabio.estevam@freescale.com> |
README: mxs: Introduce README.mxs
Create a README.mxs file that contains instructions on how to use U-boot for
both MX23 and MX28.
As boot from NAND has only been tested on mx28, make it clear that
README: mxs: Introduce README.mxs
Create a README.mxs file that contains instructions on how to use U-boot for
both MX23 and MX28.
As boot from NAND has only been tested on mx28, make it clear that it only
applies to MX28.
While at it, do some small cleanups for the sake of consistency:
- Use "MX28" instead of "i.MX28"
- Use "section" instead of "chapter" when referring to specific parts of the
reference manual chapters.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
show more ...
|
| 3f5e2e2a | 03-May-2013 |
Fabio Estevam <fabio.estevam@freescale.com> |
README: mx28_common: Do not hardcode the SSP port
MX28 can boot from SSP0 or SSP1, so it is better not to hardcode the SSP port
in the instructions.
Signed-off-by: Fabio Estevam <fabio.estevam@free
README: mx28_common: Do not hardcode the SSP port
MX28 can boot from SSP0 or SSP1, so it is better not to hardcode the SSP port
in the instructions.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
show more ...
|
| eeaef5e4 | 10-Jun-2013 |
Steven Stallion <sstallion@gmail.com> |
cmd_bootm: Add command line arguments to Plan 9
This patch introduces support for command line arguments to Plan 9.
Plan 9 generally dedicates a small region of kernel memory (known
as CONFADDR) for
cmd_bootm: Add command line arguments to Plan 9
This patch introduces support for command line arguments to Plan 9.
Plan 9 generally dedicates a small region of kernel memory (known
as CONFADDR) for runtime configuration. A new environment variable
named confaddr was introduced to indicate this location when copying
arguments.
Signed-off-by: Steven Stallion <sstallion@gmail.com>
[trini: Adapt for Simon's changes about correcting argc, no need to bump
by 2 now]
Signed-off-by: Tom Rini <trini@ti.com>
show more ...
|
| 041bca5b | 13-Jun-2013 |
Simon Glass <sjg@chromium.org> |
Add verified boot information and test
Add a description of how to implement verified boot using signed FIT images,
and a simple test which verifies operation on sandbox.
The test signs a FIT image
Add verified boot information and test
Add a description of how to implement verified boot using signed FIT images,
and a simple test which verifies operation on sandbox.
The test signs a FIT image and verifies it, then signs a FIT configuration
and verifies it. Then it corrupts the signature to check that this is
detected.
Signed-off-by: Simon Glass <sjg@chromium.org>
show more ...
|
| 4d098529 | 13-Jun-2013 |
Simon Glass <sjg@chromium.org> |
image: Add support for signing of FIT configurations
While signing images is useful, it does not provide complete protection
against several types of attack. For example, it it possible to create a
image: Add support for signing of FIT configurations
While signing images is useful, it does not provide complete protection
against several types of attack. For example, it it possible to create a
FIT with the same signed images, but with the configuration changed such
that a different one is selected (mix and match attack). It is also possible
to substitute a signed image from an older FIT version into a newer FIT
(roll-back attack).
Add support for signing of FIT configurations using the libfdt's region
support.
Please see doc/uImage.FIT/signature.txt for more information.
Signed-off-by: Simon Glass <sjg@chromium.org>
show more ...
|
| 399c744b | 13-Jun-2013 |
Simon Glass <sjg@chromium.org> |
mkimage: Add -r option to specify keys that must be verified
Normally, multiple public keys can be provided and U-Boot is not
required to use all of them for verification. This is because some
image
mkimage: Add -r option to specify keys that must be verified
Normally, multiple public keys can be provided and U-Boot is not
required to use all of them for verification. This is because some
images may not be signed, or may be optionally signed.
But we still need a mechanism to determine when a key must be used.
This feature cannot be implemented in the FIT itself, since anyone
could change it to mark a key as optional. The requirement for
key verification must go in with the public keys, in a place that
is protected from modification.
Add a -r option which tells mkimage to mark all keys that it uses
for signing as 'required'.
If some keys are optional and some are required, run mkimage several
times (perhaps with different key directories if some keys are very
secret) using the -F flag to update an existing FIT.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Marek Vasut <marex@denx.de>
show more ...
|