u-boot.git/doc, branch v2014.07-rc4 Unnamed repository; edit this file 'description' to name the repository. dm: Expand and improve the device lifecycle docs 2014-06-20T17:56:53+00:00 Simon Glass sjg@chromium.org 2014-06-12T05:29:55+00:00 22ec136325fdfc805b1e48e5ac8e17f23b4e9fc6 The lifecycle of a device is an important part of driver model. Add to the existing documentation and clarify it. Reported-by: Jon Loeliger <jdl@jdl.com> Signed-off-by: Simon Glass <sjg@chromium.org> 
The lifecycle of a device is an important part of driver model. Add to the
existing documentation and clarify it.

Reported-by: Jon Loeliger <jdl@jdl.com>

Signed-off-by: Simon Glass <sjg@chromium.org>
dm: Rename struct device_id to udevice_id 2014-06-20T17:55:18+00:00 Simon Glass sjg@chromium.org 2014-06-12T05:29:45+00:00 ae7f4513087e7f7996cebc9db642917dde9ea561 It is best to avoid having any occurence of 'struct device' in driver model, so rename to achieve this. Signed-off-by: Simon Glass <sjg@chromium.org> 
It is best to avoid having any occurence of 'struct device' in driver
model, so rename to achieve this.

Signed-off-by: Simon Glass <sjg@chromium.org>
Add documentation for verified boot on Beaglebone Black 2014-06-19T15:19:03+00:00 Simon Glass sjg@chromium.org 2014-06-12T13:24:54+00:00 c7320ed52f8e71eeadcf6b36c818b7b39321f8d4 As an example of an end-to-end process for using verified boot in U-Boot, add a detailed description of the steps to be used for a Beaglebone Black. Signed-off-by: Simon Glass <sjg@chromium.org> 
As an example of an end-to-end process for using verified boot in U-Boot,
add a detailed description of the steps to be used for a Beaglebone
Black.

Signed-off-by: Simon Glass <sjg@chromium.org>
Enhance fit_check_sign to check all images 2014-06-19T15:19:02+00:00 Simon Glass sjg@chromium.org 2014-06-12T13:24:53+00:00 ce1400f6949bbfec01fe381a844b14844cb3be12 At present this tool only checks the configuration signing. Have it also look at each of the images in the configuration and confirm that they verify. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Heiko Schocher <hs@denx.de> (v1) 
At present this tool only checks the configuration signing. Have it also
look at each of the images in the configuration and confirm that they
verify.

Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Heiko Schocher <hs@denx.de> (v1)
fdt: Rename the DEV_TREE_BIN Makefile flag to to EXT_DTB 2014-06-19T15:18:56+00:00 Simon Glass sjg@chromium.org 2014-06-12T13:24:43+00:00 d18926af30d111362c6262c356feb768d7a367a3 This seems like a better name. This is a patch-up to the earlier commit 63b4b5b, and also removes a redundant Makefile change. Signed-off-by: Simon Glass <sjg@chromium.org> 
This seems like a better name. This is a patch-up to the earlier commit
63b4b5b, and also removes a redundant Makefile change.

Signed-off-by: Simon Glass <sjg@chromium.org>
docs: driver-model: Fix spelling 2014-06-11T20:27:05+00:00 Chris Packham judge.packham@gmail.com 2014-06-06T22:35:55+00:00 34e4a2ec0ad95cea910094e33761bddf56ad7fc0 Signed-off-by: Chris Packham <judge.packham@gmail.com> 
Signed-off-by: Chris Packham <judge.packham@gmail.com>
fdt: Add DEV_TREE_BIN option to specify a device tree binary file 2014-06-11T20:25:46+00:00 Simon Glass sjg@chromium.org 2014-06-03T04:04:50+00:00 63b4b5bae52e48528876e13e858ef934ac2e4a3b In some cases, an externally-built device tree binary is required to be attached to U-Boot. An example is when using image signing, since in that case the .dtb file must include the public keys. Add a DEV_TREE_BIN option to the Makefile, and update the documentation. Usage is something like: make DEV_TREE_BIN=boot/am335x-boneblack-pubkey.dtb Signed-off-by: Simon Glass <sjg@chromium.org> 
In some cases, an externally-built device tree binary is required to be
attached to U-Boot. An example is when using image signing, since in that
case the .dtb file must include the public keys.

Add a DEV_TREE_BIN option to the Makefile, and update the documentation.

Usage is something like:

	make DEV_TREE_BIN=boot/am335x-boneblack-pubkey.dtb

Signed-off-by: Simon Glass <sjg@chromium.org>
Merge branch 'master' of git://git.denx.de/u-boot-arm 2014-06-08T11:58:41+00:00 Tom Rini trini@ti.com 2014-06-08T11:58:41+00:00 55e8250bd3cfd996d1caa04f520160a89ec04754 






am335x: update README for BCH16
2014-06-06T21:46:11+00:00

pekon gupta
pekon@ti.com

2014-06-02T11:44:43+00:00

867f03040f771a95323925b569eaf3b911b9eb14

updates documentation with explanation on how to select ECC schemes.

Signed-off-by: Pekon Gupta <pekon@ti.com>





updates documentation with explanation on how to select ECC schemes.

Signed-off-by: Pekon Gupta <pekon@ti.com>







mtd: nand: omap: add CONFIG_SYS_NAND_BUSWIDTH_16BIT to indicate NAND device bus-width
2014-06-06T21:46:06+00:00

pekon gupta
pekon@ti.com

2014-05-05T19:16:19+00:00

b80a66033856cc89c62886ae3e5ba54a7faf31ae

GPMC controller needs to be configured based on bus-width of the NAND device
connected to it. Also, dynamic detection of NAND bus-width from on-chip ONFI
parameters is not possible in following situations:
SPL:    SPL NAND drivers does not support ONFI parameter reading.
U-boot: GPMC controller iniitalization is done in omap_gpmc.c:board_nand_init()
        which is called before probing for devices, hence any ONFI parameter
        information is not available during GPMC initialization.

Thus, OMAP NAND driver expected board developers to explicitely write GPMC
configurations specific to NAND device attached on board in board files itself.
But this was troublesome for board manufacturers as they need to dive into
lengthy platform & SoC documents to find details of GPMC registers and
appropriate configurations to get NAND device working.

This patch instead adds existing CONFIG_SYS_NAND_BUSWIDTH_16BIT to board config
hich indicates that connected NAND device has x16 bus-width. And then based on
this config GPMC driver itself initializes itself based on NAND bus-width. This
keeps board developers free from knowing GPMC controller specific internals.

Signed-off-by: Pekon Gupta <pekon@ti.com>





GPMC controller needs to be configured based on bus-width of the NAND device
connected to it. Also, dynamic detection of NAND bus-width from on-chip ONFI
parameters is not possible in following situations:
SPL:    SPL NAND drivers does not support ONFI parameter reading.
U-boot: GPMC controller iniitalization is done in omap_gpmc.c:board_nand_init()
        which is called before probing for devices, hence any ONFI parameter
        information is not available during GPMC initialization.

Thus, OMAP NAND driver expected board developers to explicitely write GPMC
configurations specific to NAND device attached on board in board files itself.
But this was troublesome for board manufacturers as they need to dive into
lengthy platform & SoC documents to find details of GPMC registers and
appropriate configurations to get NAND device working.

This patch instead adds existing CONFIG_SYS_NAND_BUSWIDTH_16BIT to board config
hich indicates that connected NAND device has x16 bus-width. And then based on
this config GPMC driver itself initializes itself based on NAND bus-width. This
keeps board developers free from knowing GPMC controller specific internals.

Signed-off-by: Pekon Gupta <pekon@ti.com>