diff options
Diffstat (limited to 'doc')
| -rw-r--r-- | doc/README.SPL | 4 | ||||
| -rw-r--r-- | doc/README.hawkboard | 43 | ||||
| -rw-r--r-- | doc/README.imximage | 13 | ||||
| -rw-r--r-- | doc/README.menu | 10 | ||||
| -rw-r--r-- | doc/README.omap-ulpi-viewport | 27 |
5 files changed, 67 insertions, 30 deletions
diff --git a/doc/README.SPL b/doc/README.SPL index f01a8bd..0276953 100644 --- a/doc/README.SPL +++ b/doc/README.SPL @@ -42,8 +42,8 @@ The building of SPL images can be with: #define CONFIG_SPL -Because SPL images normally have a different text base, one have to be -configured by defining CONFIG_SPL_TEXT_BASE. The linker script have to be +Because SPL images normally have a different text base, one has to be +configured by defining CONFIG_SPL_TEXT_BASE. The linker script has to be defined with CONFIG_SPL_LDSCRIPT. To support generic U-Boot libraries and drivers in the SPL binary one can diff --git a/doc/README.hawkboard b/doc/README.hawkboard index b7afec4..d6ae02e 100644 --- a/doc/README.hawkboard +++ b/doc/README.hawkboard @@ -9,8 +9,8 @@ executes upon reset is the Rom Boot Loader(RBL) which sits in the internal ROM of the omap. The RBL initialises the memory and the nand controller, and copies the image stored at a predefined location(block 1) of the nand flash. The image loaded by the RBL to the memory is the -AIS signed nand_spl image. This, in turns copies the u-boot binary -from the nand flash to the memory and jumps to the u-boot entry point. +AIS signed spl image. This, in turns copies the u-boot binary from the +nand flash to the memory and jumps to the u-boot entry point. AIS is an image format defined by TI for the images that are to be loaded to memory by the RBL. The image is divided into a series of @@ -20,14 +20,14 @@ and the size of the section, which is used by the RBL to load the image. At the end of the image the RBL jumps to the image entry point. -The secondary stage bootloader(nand_spl) which is loaded by the RBL -then loads the u-boot from a predefined location in the nand to the -memory and jumps to the u-boot entry point. +The secondary stage bootloader(spl) which is loaded by the RBL then +loads the u-boot from a predefined location in the nand to the memory +and jumps to the u-boot entry point. The reason a secondary stage bootloader is used is because the ECC layout expected by the RBL is not the same as that used by -u-boot/linux. This also implies that for flashing the nand_spl image, -we need to use the u-boot which uses the ECC layout expected by the +u-boot/linux. This also implies that for flashing the spl image,we +need to use the u-boot which uses the ECC layout expected by the RBL[1]. Booting u-boot over UART(UART boot) is explained here[2]. @@ -35,20 +35,19 @@ Compilation =========== Three images might be needed -* nand_spl - This is the secondary bootloader which boots the u-boot +* spl - This is the secondary bootloader which boots the u-boot binary. - hawkboard_nand_config - - The nand_spl ELF gets generated under nand_spl/u-boot-spl. This - needs to be processed with the AISGen tool for generating the AIS - signed image to be flashed. Steps for generating the AIS image are - explained here[3]. - * u-boot binary - This is the image flashed to the nand and copied to - the memory by the nand_spl. + the memory by the spl. + + Both the images get compiled with hawkboard_config, with the TOPDIR + containing the u-boot images, and the spl image under the spl + directory. - hawkboard_config + The spl image needs to be processed with the AISGen tool for + generating the AIS signed image to be flashed. Steps for generating + the AIS image are explained here[3]. * u-boot for uart boot - This is same as the u-boot binary generated above, with the sole difference of the CONFIG_SYS_TEXT_BASE being @@ -59,17 +58,17 @@ Three images might be needed Flashing the images to Nand =========================== -The nand_spl AIS image needs to be flashed to the block 1 of the -Nand flash, as that is the location the RBL expects the image[4]. For -flashing the nand_spl, boot over the u-boot specified in [1], and -flash the image +The spl AIS image needs to be flashed to the block 1 of the Nand +flash, as that is the location the RBL expects the image[4]. For +flashing the spl, boot over the u-boot specified in [1], and flash the +image => tftpboot 0xc0700000 <nand_spl_ais.bin> => nand erase 0x20000 0x20000 => nand write.e 0xc0700000 0x20000 <nand_spl_size> The u-boot binary is flashed at location 0xe0000(block 6) of the nand -flash. The nand_spl loader expects the u-boot at this location. For +flash. The spl loader expects the u-boot at this location. For flashing the u-boot binary => tftpboot 0xc0700000 u-boot.bin diff --git a/doc/README.imximage b/doc/README.imximage index c74239d..073e3fc 100644 --- a/doc/README.imximage +++ b/doc/README.imximage @@ -2,12 +2,13 @@ Imximage Boot Image generation using mkimage --------------------------------------------- -This document describes how to set up a U-Boot image -that can be booted by Freescale MX25, MX35 and MX51 -processors via internal boot mode. +This document describes how to set up a U-Boot image that can be booted +by Freescale MX25, MX35, MX51, MX53 and MX6 processors via internal boot +mode. These processors can boot directly from NAND, SPI flash and SD card flash -using its internal boot ROM support. They can boot from an internal +using its internal boot ROM support. MX6 processors additionally support +boot from NOR flash and SATA disks. All processors can boot from an internal UART, if booting from device media fails. Booting from NOR flash does not require to use this image type. @@ -59,12 +60,12 @@ Configuration command line syntax: -------------- ----------- IMXIMAGE_VERSION 1/2 1 is for mx25/mx35/mx51 compatible, - 2 is for mx53 compatible, + 2 is for mx53/mx6 compatible, others is invalid and error is generated. This command need appear the fist before other valid commands in configuration file. - BOOT_FROM nand/spi/sd/onenand + BOOT_FROM nand/spi/sd/onenand/nor/sata Example: BOOT_FROM spi DATA type address value diff --git a/doc/README.menu b/doc/README.menu index 0dad6a2..6ce6bba 100644 --- a/doc/README.menu +++ b/doc/README.menu @@ -25,6 +25,11 @@ the interfaces should be available. Menus are composed of items. Each item has a key used to identify it in the menu, and an opaque pointer to data controlled by the consumer. +If you want to show a menu, instead starting the shell, define +CONFIG_MENU_SHOW. You have to code the int menu_show(int bootdelay) +function, which handle your menu. This function returns the remaining +bootdelay. + Interfaces ---------- #include "menu.h" @@ -69,6 +74,11 @@ int menu_get_choice(struct menu *m, void **choice); */ int menu_destroy(struct menu *m); +/* + * menu_display_statusline(struct menu *m); + * shows a statusline for every menu_display call. + */ +void menu_display_statusline(struct menu *m); Example Code ------------ diff --git a/doc/README.omap-ulpi-viewport b/doc/README.omap-ulpi-viewport new file mode 100644 index 0000000..a5240b9 --- /dev/null +++ b/doc/README.omap-ulpi-viewport @@ -0,0 +1,27 @@ +Reference code ""drivers/usb/ulpi/omap-ulpi-viewport.c" + +Contains the ulpi read write api's to perform +any ulpi phy port access on omap platform. + +On omap ehci reg map contains INSNREG05_ULPI +register which offers the ulpi phy access so +any ulpi phy commands should be passsed using this +register. + +omap-ulpi-viewport.c is a low level function +implementation of "drivers/usb/ulpi/ulpi.c" + +To enable and use omap-ulpi-viewport.c +we require CONFIG_USB_ULPI_VIEWPORT_OMAP and +CONFIG_USB_ULPI be enabled in config file. + +Any ulpi ops request can be done with ulpi.c +and soc specific binding and usage is done with +omap-ulpi-viewport implementation. + +Ex: scenario: +omap-ehci driver code requests for ulpi phy reset if +ehci is used in phy mode, which will call ulpi phy reset +the ulpi phy reset does ulpi_read/write from viewport +implementation which will do ulpi reset using the +INSNREG05_ULPI register. |