diff options
Diffstat (limited to 'doc')
| -rw-r--r-- | doc/README.PXA_CF | 56 | ||||
| -rw-r--r-- | doc/README.commands.spl | 31 | ||||
| -rw-r--r-- | doc/README.mx6qsabrelite | 12 | ||||
| -rw-r--r-- | doc/SPL/README.omap3 | 74 | ||||
| -rw-r--r-- | doc/device-tree-bindings/README | 17 | ||||
| -rw-r--r-- | doc/device-tree-bindings/clock/nvidia,tegra20-car.txt | 207 | ||||
| -rw-r--r-- | doc/device-tree-bindings/i2c/tegra20-i2c.txt | 23 | ||||
| -rw-r--r-- | doc/device-tree-bindings/usb/tegra-usb.txt | 25 |
8 files changed, 385 insertions, 60 deletions
diff --git a/doc/README.PXA_CF b/doc/README.PXA_CF deleted file mode 100644 index 1d76b32..0000000 --- a/doc/README.PXA_CF +++ /dev/null @@ -1,56 +0,0 @@ - -These are brief instructions on how to add support for CF adapters to -custom designed PXA boards. You need to set the parameters in the -config file. This should work for most implementations especially if you -follow the connections of the standard lubbock. Anyway just the block -marked memory configuration should be touched since the other parameters -are imposed by the PXA architecture. - -EDIT 2010-07-01: in common/cmd_ide.c, having CONFIG_PXA_PCMCIA defined -would cause looping on inw()/outw() rather than using insw()/outsw(), -thus making sure IDE / ATA bytes are properly swapped. This behaviour -is now controlled by CONFIG_IDE_SWAP_IO, therefore PXA boards with -PCMCIA should #define CONFIG_IDE_SWAP_IO. - -#define CONFIG_IDE_SWAP_IO - -#define CONFIG_PXA_PCMCIA 1 -#define CONFIG_PXA_IDE 1 - -#define CONFIG_PCMCIA_SLOT_A 1 -/* just to keep build system happy */ - -#define CONFIG_SYS_PCMCIA_MEM_ADDR 0x28000000 -#define CONFIG_SYS_PCMCIA_MEM_SIZE 0x10000000 - -#define CONFIG_SYS_MECR_VAL 0x00000000 -#define CONFIG_SYS_MCMEM0_VAL 0x00004204 -#define CONFIG_SYS_MCMEM1_VAL 0x00000000 -#define CONFIG_SYS_MCATT0_VAL 0x00010504 -#define CONFIG_SYS_MCATT1_VAL 0x00000000 -#define CONFIG_SYS_MCIO0_VAL 0x00008407 -#define CONFIG_SYS_MCIO1_VAL 0x00000000 -/* memory configuration */ - -#define CONFIG_SYS_IDE_MAXBUS 1 -/* max. 1 IDE bus */ -#define CONFIG_SYS_IDE_MAXDEVICE 1 -/* max. 1 drive per IDE bus */ - -#define CONFIG_SYS_ATA_IDE0_OFFSET 0x0000 - -#define CONFIG_SYS_ATA_BASE_ADDR 0x20000000 - -/* Offset for data I/O */ -#define CONFIG_SYS_ATA_DATA_OFFSET 0x1f0 - -/* Offset for normal register accesses */ -#define CONFIG_SYS_ATA_REG_OFFSET 0x1f0 - -/* Offset for alternate registers */ -#define CONFIG_SYS_ATA_ALT_OFFSET 0x3f0 - - -Another important point is that maybe you have to power the pcmcia -subsystem. This is very board specific, for an example on how to -do it please search for CONFIG_EXADRON1 in cmd_pcmcia.c diff --git a/doc/README.commands.spl b/doc/README.commands.spl new file mode 100644 index 0000000..ac33273 --- /dev/null +++ b/doc/README.commands.spl @@ -0,0 +1,31 @@ +The spl command is used to export a boot parameter image to RAM. Later +it may implement more functions connected to the SPL. + +SUBCOMMAND EXPORT +To execute the command everything has to be in place as if bootm should be +used. (kernel image, initrd-image, fdt-image etc.) + +export has two subcommands: + atags: exports the ATAGS + fdt: exports the FDT + +Call is: +spl export <ftd|atags> [kernel_addr] [initrd_addr] [fdt_addr if fdt] + + +TYPICAL CALL + +on OMAP3: +nandecc hw +nand read 0x82000000 0x280000 0x400000 /* Read kernel image from NAND*/ +spl export atags /* export ATAGS */ +nand erase 0x680000 0x20000 /* erase - one page */ +nand write 0x80000100 0x680000 0x20000 /* write the image - one page */ + +call with FDT: +nandecc hw +nand read 0x82000000 0x280000 0x400000 /* Read kernel image from NAND*/ +tftpboot 0x80000100 devkit8000.dtb /* Read fdt */ +spl export fdt 0x82000000 - 0x80000100 /* export FDT */ +nand erase 0x680000 0x20000 /* erase - one page */ +nand write <adress shown by spl export> 0x680000 0x20000 diff --git a/doc/README.mx6qsabrelite b/doc/README.mx6qsabrelite index 4add2bf..0498cba 100644 --- a/doc/README.mx6qsabrelite +++ b/doc/README.mx6qsabrelite @@ -7,20 +7,24 @@ i.MX6q SabreLite board. --------------------------------- The recent mainline U-Boot for the Freescale i.MX6q SabreLite board supports -boot from SD card only. However, by default, the early version of SabreLite +boot from SD card only. However, by default, the SabreLite boards boot from the SPI NOR flash. These boards need to be reflashed with a small SD card loader to support boot from SD card. This small SD card loader will be flashed into the SPI NOR. The board will still boot from SPI NOR, but the loader will in turn request the BootROM to load the U-Boot from SD card. -At the moment of writing, please check with Freescale on the availablity of -this small SD loader binary. + +The SD card loader is available from + +https://wiki.linaro.org/Boards/MX6QSabreLite + +under a open-source 3-clause BSD license. To update the SPI-NOR on the SabreLite board without the Freescale manufacturing tool use the following procedure: 1. Write this SD card loader onto a large SD card using: - sudo dd if=MX6_SPI_to_SD_loader.bin of=/dev/sXx + sudo dd if=iMX6DQ_SPI_to_uSDHC3.bin of=/dev/sXx Note: Replace sXx with the device representing the SD card in your system. diff --git a/doc/SPL/README.omap3 b/doc/SPL/README.omap3 new file mode 100644 index 0000000..cc5d5c0 --- /dev/null +++ b/doc/SPL/README.omap3 @@ -0,0 +1,74 @@ +Overview of SPL on OMAP3 devices +================================ + +Introduction +------------ + +This document provides an overview of how SPL functions on OMAP3 (and related +such as am35x and am37x) processors. + +Methodology +----------- + +On these platforms the ROM supports trying a sequence of boot devices. Once +one has been used successfully to load SPL this information is stored in memory +and the location stored in a register. We will read this to determine where to +read U-Boot from in turn. + +Memory Map +---------- + +This is an example of a typical setup. See top-level README for documentation +of which CONFIG variables control these values. For a given board and the +amount of DRAM available to it different values may need to be used. +Note that the size of the SPL text rodata and data is enforced with a CONFIG +option and growing over that size results in a link error. The SPL stack +starts at the top of SRAM (which is configurable) and grows downward. The +space between the top of SRAM and the enforced upper bound on the size of the +SPL text, data and rodata is considered the safe stack area. Details on +confirming this behavior are shown below. + +A portion of the system memory map looks as follows: +SRAM: 0x40200000 - 0x4020FFFF +DDR1: 0x80000000 - 0xBFFFFFFF + +Option 1 (SPL only): +0x40200800 - 0x4020BBFF: Area for SPL text, data and rodata +0x4020BC00 - 0x4020FFFC: Area for the SPL stack. +0x80000000 - 0x8007FFFF: Area for the SPL BSS. +0x80100000: CONFIG_SYS_TEXT_BASE of U-Boot +0x80208000 - 0x80307FFF: malloc() pool available to SPL. + +Option 2 (SPL or X-Loader): +0x40200800 - 0x4020BBFF: Area for SPL text, data and rodata +0x4020BC00 - 0x4020FFFC: Area for the SPL stack. +0x80008000: CONFIG_SYS_TEXT_BASE of U-Boot +0x87000000 - 0x8707FFFF: Area for the SPL BSS. +0x87080000 - 0x870FFFFF: malloc() pool available to SPL. + +For the areas that reside within DDR1 they must not be used prior to s_init() +completing. Note that CONFIG_SYS_TEXT_BASE must be clear of the areas that SPL +uses while running. This is why we have two versions of the memory map that +only vary in where the BSS and malloc pool reside. + +Estimating stack usage +---------------------- + +With gcc 4.6 (and later) and the use of GNU cflow it is possible to estimate +stack usage at various points in run sequence of SPL. The -fstack-usage option +to gcc will produce '.su' files (such as arch/arm/cpu/armv7/syslib.su) that +will give stack usage information and cflow can construct program flow. + +Must have gcc 4.6 or later, which supports -fstack-usage + +1) Build normally +2) Perform the following shell command to generate a list of C files used in +SPL: +$ find spl -name '*.su' | sed -e 's:^spl/::' -e 's:[.]su$:.c:' > used-spl.list +3) Execute cflow: +$ cflow --main=board_init_r `cat used-spl.list` 2>&1 | $PAGER + +cflow will spit out a number of warnings as it does not parse +the config files and picks functions based on #ifdef. Parsing the '.i' +files instead introduces another set of headaches. These warnings are +not usually important to understanding the flow, however. diff --git a/doc/device-tree-bindings/README b/doc/device-tree-bindings/README new file mode 100644 index 0000000..2ea3439 --- /dev/null +++ b/doc/device-tree-bindings/README @@ -0,0 +1,17 @@ +Device Tree Bindings Staging Area +================================= + +This directory contains device tree bindings for U-Boot. + +These follow along with Linux kernel bindings, with a few additions. By +adding the files here, U-Boot patches can clearly show thees additions. +This makes it easier for device tree people to review these additions in +patches sent to the U-Boot mailing list. + +The intent IS to commit these files to U-Boot. Hopefully at some point +the files will be stored in another repo (shared with Linux) which is +brought in as needed. Changes here are intended to mirror changes in the +Linux Documentation/devicetree/bindings/ directory. + +sjg@chromium.org +17-Jan-12 diff --git a/doc/device-tree-bindings/clock/nvidia,tegra20-car.txt b/doc/device-tree-bindings/clock/nvidia,tegra20-car.txt new file mode 100644 index 0000000..5c07fca --- /dev/null +++ b/doc/device-tree-bindings/clock/nvidia,tegra20-car.txt @@ -0,0 +1,207 @@ +NVIDIA Tegra20 Clock And Reset Controller + +This binding uses the common clock binding: +Documentation/devicetree/bindings/clock/clock-bindings.txt + +The CAR (Clock And Reset) Controller on Tegra is the HW module responsible +for muxing and gating Tegra's clocks, and setting their rates. + +Required properties : +- compatible : Should be "nvidia,tegra20-car" +- reg : Should contain CAR registers location and length +- clocks : Should contain phandle and clock specifiers for two clocks: + the 32 KHz "32k_in", and the board-specific oscillator "osc". +- #clock-cells : Should be 1. + In clock consumers, this cell represents the clock ID exposed by the CAR. + + The first 96 clocks are numbered to match the bits in the CAR's CLK_OUT_ENB + registers. These IDs often match those in the CAR's RST_DEVICES registers, + but not in all cases. Some bits in CLK_OUT_ENB affect multiple clocks. In + this case, those clocks are assigned IDs above 95 in order to highlight + this issue. Implementations that interpret these clock IDs as bit values + within the CLK_OUT_ENB or RST_DEVICES registers should be careful to + explicitly handle these special cases. + + The balance of the clocks controlled by the CAR are assigned IDs of 96 and + above. + + 0 cpu + 1 unassigned + 2 unassigned + 3 ac97 + 4 rtc + 5 tmr + 6 uart1 + 7 unassigned (register bit affects uart2 and vfir) + 8 gpio + 9 sdmmc2 + 10 unassigned (register bit affects spdif_in and spdif_out) + 11 i2s1 + 12 i2c1 + 13 ndflash + 14 sdmmc1 + 15 sdmmc4 + 16 twc + 17 pwm + 18 i2s2 + 19 epp + 20 unassigned (register bit affects vi and vi_sensor) + 21 2d + 22 usbd + 23 isp + 24 3d + 25 ide + 26 disp2 + 27 disp1 + 28 host1x + 29 vcp + 30 unassigned + 31 cache2 + + 32 mem + 33 ahbdma + 34 apbdma + 35 unassigned + 36 kbc + 37 stat_mon + 38 pmc + 39 fuse + 40 kfuse + 41 sbc1 + 42 snor + 43 spi1 + 44 sbc2 + 45 xio + 46 sbc3 + 47 dvc + 48 dsi + 49 unassigned (register bit affects tvo and cve) + 50 mipi + 51 hdmi + 52 csi + 53 tvdac + 54 i2c2 + 55 uart3 + 56 unassigned + 57 emc + 58 usb2 + 59 usb3 + 60 mpe + 61 vde + 62 bsea + 63 bsev + + 64 speedo + 65 uart4 + 66 uart5 + 67 i2c3 + 68 sbc4 + 69 sdmmc3 + 70 pcie + 71 owr + 72 afi + 73 csite + 74 unassigned + 75 avpucq + 76 la + 77 unassigned + 78 unassigned + 79 unassigned + 80 unassigned + 81 unassigned + 82 unassigned + 83 unassigned + 84 irama + 85 iramb + 86 iramc + 87 iramd + 88 cram2 + 89 audio_2x a/k/a audio_2x_sync_clk + 90 clk_d + 91 unassigned + 92 sus + 93 cdev1 + 94 cdev2 + 95 unassigned + + 96 uart2 + 97 vfir + 98 spdif_in + 99 spdif_out + 100 vi + 101 vi_sensor + 102 tvo + 103 cve + 104 osc + 105 clk_32k a/k/a clk_s + 106 clk_m + 107 sclk + 108 cclk + 109 hclk + 110 pclk + 111 blink + 112 pll_a + 113 pll_a_out0 + 114 pll_c + 115 pll_c_out1 + 116 pll_d + 117 pll_d_out0 + 118 pll_e + 119 pll_m + 120 pll_m_out1 + 121 pll_p + 122 pll_p_out1 + 123 pll_p_out2 + 124 pll_p_out3 + 125 pll_p_out4 + 126 pll_s + 127 pll_u + 128 pll_x + 129 cop a/k/a avp + 130 audio a/k/a audio_sync_clk + +Example SoC include file: + +/ { + tegra_car: clock@60006000 { + compatible = "nvidia,tegra20-car"; + reg = <0x60006000 0x1000>; + #clock-cells = <1>; + }; + + usb@c5004000 { + clocks = <&tegra_car 58>; /* usb2 */ + }; +}; + +Example board file: + +/ { + clocks { + #address-cells = <1>; + #size-cells = <0>; + + osc: clock { + compatible = "fixed-clock"; + #clock-cells = <0>; + clock-frequency = <12000000>; + }; + }; + + i2c@7000d000 { + pmic@34 { + compatible = "ti,tps6586x"; + reg = <0x34>; + + clk_32k: clock { + compatible = "fixed-clock"; + #clock-cells = <0>; + clock-frequency = <32768>; + }; + }; + }; + + &tegra_car { + clocks = <&clk_32k> <&osc>; + }; +}; diff --git a/doc/device-tree-bindings/i2c/tegra20-i2c.txt b/doc/device-tree-bindings/i2c/tegra20-i2c.txt new file mode 100644 index 0000000..d601c17 --- /dev/null +++ b/doc/device-tree-bindings/i2c/tegra20-i2c.txt @@ -0,0 +1,23 @@ +(Placeholder note while we locate the kernel Tegra20 bindings) + +Added in U-Boot: + +Required properties: + - clocks : Two clocks must be given, each as a phandle to the Tegra's + CAR node and the clock number as a parameter: + - the I2C clock to use for the peripheral + - the pll_p_out3 clock, which can be used for fast operation. This + does not change and is the same for all I2C nodes. + +Example: +(TODO: merge with existing example): + + i2c@7000c400 { + #address-cells = <1>; + #size-cells = <0>; + compatible = "nvidia,tegra20-i2c"; + reg = <0x7000C400 0x100>; + interrupts = < 116 >; + /* PERIPH_ID_I2C2, PLL_P_OUT3 */ + clocks = <&tegra_car 54>, <&tegra_car 124>; + }; diff --git a/doc/device-tree-bindings/usb/tegra-usb.txt b/doc/device-tree-bindings/usb/tegra-usb.txt new file mode 100644 index 0000000..5282d44 --- /dev/null +++ b/doc/device-tree-bindings/usb/tegra-usb.txt @@ -0,0 +1,25 @@ +Tegra SOC USB controllers + +The device node for a USB controller that is part of a Tegra +SOC is as described in the document "Open Firmware Recommended +Practice : Universal Serial Bus" with the following modifications +and additions : + +Required properties : + - compatible : Should be "nvidia,tegra20-ehci" for USB controllers + used in host mode. + - phy_type : Should be one of "ulpi" or "utmi". + - nvidia,vbus-gpio : If present, specifies a gpio that needs to be + activated for the bus to be powered. + +Optional properties: + - dr_mode : dual role mode. Indicates the working mode for + nvidia,tegra20-ehci compatible controllers. Can be "host", "peripheral", + or "otg". Default to "host" if not defined for backward compatibility. + host means this is a host controller + peripheral means it is device controller + otg means it can operate as either ("on the go") + - nvidia,has-legacy-mode : boolean indicates whether this controller can + operate in legacy mode (as APX 2500 / 2600). In legacy mode some + registers are accessed through the APB_MISC base address instead of + the USB controller. |